SPF, DKIM and DMARC on Microsoft 365: Stop Email Spoofing

Anyone with an internet connection can send an email that claims to come from your domain. No password, no hacking, no access to your tenant. The protocol that moves email was designed in the early 1980s and accepts whatever sender address it's given. SPF, DKIM and DMARC on Microsoft 365 close that gap. These three DNS-based standards let receiving mail servers verify that a message claiming to come from contoso.com actually left a server you authorized, and they tell those servers what to do when it didn't.

For a small or mid-sized business, the stakes are concrete. Criminals send fake invoices to your clients using your exact domain, not a lookalike. Suppliers receive "updated banking details" that appear to come from your accounting inbox. And since Google and Yahoo tightened their sender rules in 2024, unauthenticated mail increasingly lands in spam or gets rejected before anyone reads it, even when it's perfectly legitimate.

The good news: the initial setup takes an afternoon, and a careful rollout to full enforcement takes about a month. This guide walks through each step with exact portal paths and DNS records, using contoso.com as the placeholder domain.

Key Takeaways

• SPF, DKIM and DMARC let receiving servers verify email that claims to come from your domain.
• Microsoft 365 needs one SPF TXT record and two DKIM CNAME records in your public DNS.
• Always start DMARC at p=none, read the reports, then tighten to quarantine and reject.
• Google and Yahoo require authentication from bulk senders, so deliverability now depends on these records.
• A four week rollout gets most SMBs to p=reject without blocking legitimate mail.

Why Spoofed Email Costs Real Money

Email spoofing is the raw material of business fraud. The classic scenario: a criminal watches your industry, learns who your clients are, then sends them an invoice from billing@contoso.com with one small change, the banking details. The client pays. You find out weeks later when you chase the receivable; by then the money is gone. Your firm did nothing wrong, but the email carried your name.

Brand damage compounds the direct losses. When a phishing wave goes out under your domain, recipients report it, filters learn to distrust your name, and your domain's reputation takes the hit. Some of your legitimate mail starts landing in junk at exactly the clients you need most.

Then there's deliverability. Since 2024, Google and Yahoo require SPF or DKIM from every sender and full DMARC from anyone sending bulk mail to their users, and Microsoft announced similar requirements for outlook.com mailboxes in 2025. An unauthenticated domain now competes for the inbox with one hand tied behind its back: quotes and invoices drift into spam, and nobody tells you.

We covered the receiving side of this problem in our visual guide to spotting phishing emails. This tutorial handles the other direction: making sure nobody can convincingly send as you.

How SPF, DKIM and DMARC Work Together on Microsoft 365

Each standard answers a different question, and you need all three.

SPF (Sender Policy Framework) is a guest list. You publish a DNS record naming the servers allowed to send email for your domain, and receiving servers check the connecting server against that list. Simple, but fragile: SPF breaks when a message is forwarded, and it says nothing about what to do on failure.

DKIM (DomainKeys Identified Mail) is a tamper-evident seal. Microsoft 365 signs each outgoing message with a private key, and receivers verify the signature using the public key you publish in DNS. The signature survives forwarding and proves the message wasn't altered in transit.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer that ties them together. It tells receivers what to do when a message fails both checks (deliver it anyway, quarantine it, or reject it), and it sends you reports listing every server claiming to send as your domain. DMARC also enforces alignment: the domain your recipients see in the From line must match the domain that passed SPF or DKIM, which is exactly what blocks spoofing.

Keep in mind that these records protect your domain, not your user accounts. Sign-in protection is a separate job, and our free Conditional Access baseline covers that side of the house.

Step 1: Publish Your SPF Record

SPF is a single TXT record at the root of your domain. Here's the process:

1. Inventory your senders. List every service that sends email as your domain: Microsoft 365 itself, your marketing platform, your CRM or PSA, website contact forms, scan-to-email printers, monitoring tools. Don't panic about missing one, the DMARC reports in Step 3 will catch stragglers.
2. Build the record. If everything goes through Microsoft 365, the record is short:

contoso.com    TXT    "v=spf1 include:spf.protection.outlook.com -all"

1. Add third-party services with the include value from their documentation, for example a marketing platform:

contoso.com    TXT    "v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all"

1. Publish it at your DNS host, meaning the registrar or DNS provider that manages your zone. One SPF record per domain, never two. If a record already exists, merge the new includes into it.
2. Verify. Run nslookup -type=txt contoso.com from any terminal, or use a free online SPF checker, and confirm the record resolves as published.

Two details deserve attention. The final -all means "reject anything not on this list" and is what you want once your inventory is solid; the softer ~all is acceptable during the first weeks. And SPF allows a maximum of 10 DNS lookups per check, so avoid stacking includes you don't need.

Step 2: Enable DKIM in Defender for Office 365

Microsoft 365 signs your onmicrosoft.com domain automatically, but your custom domain has to be enabled by hand. That's this step.

1. Sign in to the Microsoft Defender portal at security.microsoft.com.
2. Go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings.
3. Open the DKIM tab and select your custom domain, contoso.com in our example.
4. Turn on Sign messages for this domain with DKIM signatures. If the DNS records don't exist yet, the portal shows an error containing the two CNAME values you need. Copy them.
5. Create both CNAME records at your DNS host. They follow this pattern, with your tenant name in place of contoso:

selector1._domainkey.contoso.com    CNAME    selector1-contoso-com._domainkey.contoso.onmicrosoft.com
selector2._domainkey.contoso.com    CNAME    selector2-contoso-com._domainkey.contoso.onmicrosoft.com

1. Wait for DNS propagation, anywhere from minutes to a few hours, then return to the portal and flip the toggle on again. It should confirm without errors.
2. Test it. Send a message to an external mailbox (a Gmail account works well), open the message headers and look for dkim=pass with your domain in the signature.

Two selectors let Microsoft rotate signing keys without interrupting mail flow. Leave both CNAMEs in place permanently, and use the Rotate DKIM keys button once a year as basic hygiene.

Step 3: Deploy DMARC From Monitoring to Reject

DMARC is one more TXT record, published at _dmarc.contoso.com. The starting version looks like this:

_dmarc.contoso.com    TXT    "v=DMARC1; p=none; rua=mailto:dmarc@contoso.com; fo=1"

What the tags mean:

• p=none tells receivers to deliver mail normally even on failure, while still sending you reports. This is monitoring mode.
• rua=mailto: is where aggregate reports get delivered. Create a dedicated mailbox or alias for this, because the volume adds up.
• fo=1 requests a failure report when either SPF or DKIM fails, which gives you more diagnostic detail.
• Later you'll change p to quarantine (deliver to junk) and finally reject (refuse delivery). An optional pct tag applies the policy to a percentage of mail, useful for easing in.

Never start at p=reject. You'll almost certainly discover legitimate senders you forgot about, and at reject their mail silently disappears.

The Four Week Rollout Plan

• Week 1, monitor. Publish the record with p=none. Confirm reports start arriving within a day or two. Nothing changes for your users.
• Week 2, fix what the reports reveal. Add missing services to SPF and enable DKIM on third-party platforms; most marketing and CRM tools have a domain authentication page in their settings. Flag the sources that are plainly not yours.
• Week 3, quarantine. Change to p=quarantine, optionally starting with pct=25 and raising it over the week. Failing mail now goes to recipients' junk folders instead of their inboxes, so a genuine mistake is recoverable.
• Week 4, reject. Once reports show your legitimate sources passing and aligned, move to p=reject. Mail spoofing your domain is now refused outright by every major provider.

Keep the monitoring mailbox alive after week four. Every new tool your team adopts is a potential new sender, and the reports are how you'll notice.

Reading DMARC Reports Without the Headache

Aggregate reports arrive as XML attachments, roughly one per receiving provider per day. They list each source IP that sent mail using your domain, message volumes, and whether SPF and DKIM passed and aligned. Raw XML is technically readable and practically miserable, so most teams feed the reports into a DMARC analyzer service (several offer free tiers for a single domain) and get dashboards instead.

Three patterns to watch for:

• A legitimate service failing alignment. Your marketing platform shows high volume with DKIM failures: turn on its domain authentication feature or add its include to SPF.
• Forwarders. Mailing lists and auto-forwarding often break SPF while DKIM still passes. That's expected and harmless under DMARC's rule that either check can align.
• Unknown sources. Servers in countries you've never done business with, sending thousands of messages as contoso.com. That's the spoofing DMARC exists to stop, and once you reach p=reject, those messages die at the door.

The reports carry a side benefit: they surface shadow IT. A department that quietly signed up for its own mail-sending tool will show up in the data within days. And if you'd rather not babysit XML files or chase alignment failures yourself, our managed IT services include DMARC monitoring as part of the standard security stack.

FAQ

Does Microsoft 365 configure SPF, DKIM and DMARC automatically?

Only partially. Your onmicrosoft.com address is DKIM-signed out of the box, but custom domains are not. SPF requires a TXT record you publish yourself when you add your domain, and DMARC is never created automatically. Assume nothing is enforced until you've checked your DNS.

Will DMARC break my newsletter or CRM emails?

Not if you respect the monitoring phase. Start at p=none and the aggregate reports will show exactly which platforms fail authentication. Nearly every serious marketing and CRM tool has a domain authentication page where you add their DKIM records, and fixing those before you move to quarantine keeps legitimate mail flowing.

How long does it take to reach p=reject safely?

Plan on about four weeks for a typical SMB: one to two weeks monitoring at p=none, a week at quarantine, then reject once the reports run clean. A small organization that only sends through Microsoft 365 can move faster. A company with many third-party senders should extend the quarantine phase rather than rush it.

What's the difference between p=quarantine and p=reject?

Quarantine asks receiving servers to deliver failing mail to the junk folder, so a mistake is still recoverable by the recipient. Reject refuses delivery entirely and the message never reaches anyone. Quarantine is the safety net phase of a rollout; reject is the destination, because spoofed invoices that land in junk can still get clicked.

Do I still need DMARC if I already have spam filtering?

Yes, because they solve opposite problems. Spam filtering protects mail coming into your organization. DMARC protects everyone else who receives mail claiming to come from your domain: your clients, suppliers and partners. It also improves the deliverability of your own outgoing mail, which no inbound filter can do.

Most tenants we assess have an SPF record and nothing else, which leaves the door half open. Two short DNS sessions and a month of report watching will close it completely. If you'd rather hand the whole thing off, we configure and monitor email authentication as part of our cybersecurity services, and a quick IT assessment will show you exactly where your domain stands today.