SPF, DKIM and DMARC for Microsoft 365: the complete email authentication setup guide

Almost every business email compromise attack starts the same way: an email that looks like it came from your domain, but didn't. Email authentication is the set of DNS records that lets a receiving mail server check whether a message claiming to be from your organisation was actually sent by a source you authorised. Configured properly on a Microsoft 365 domain, it does two jobs at once, it makes your domain much harder to spoof, and it improves the deliverability of your legitimate mail because receivers trust an authenticated sender.

There are three records that work together: SPF, DKIM and DMARC. Frontrow configures all three on every managed Microsoft 365 tenant, and this guide covers the exact records, the Microsoft Defender portal steps, and the staged rollout that gets a domain to full enforcement without blocking a single legitimate email. The record values here are illustrative, the DKIM selector values in particular are unique to each tenant and must be read from your own Defender portal, but the structure applies to every Microsoft 365 domain.

Why email authentication matters

The design of internet email lets any server claim to be sending from any domain. Nothing in the base protocol stops an attacker addressing a message as coming from your chief executive. This is the mechanism behind business email compromise, the invoice-redirection and gift-card scams that the Australian Signals Directorate consistently reports as one of the highest-cost cybercrime categories for Australian businesses. Email authentication closes the gap by giving receiving servers a way to verify the sender against records only the real domain owner can publish.

• Spoofing and impersonation: without an enforced DMARC policy, an attacker can send mail as your domain and most receivers will deliver it, because there is no published instruction to reject it.
• Business email compromise: fraudulent payment and invoice changes are far more convincing when the From address is a genuine match for a real staff member or supplier domain.
• Deliverability: major providers, including Google and Yahoo, now require authenticated mail for bulk senders. A domain without SPF, DKIM and DMARC increasingly lands in Junk or is rejected outright, even for legitimate mail.

What SPF, DKIM and DMARC each do

The three records are often discussed as if they were interchangeable. They are not. Each checks a different thing, and DMARC only works once the other two are in place.

SPF: which servers are allowed to send

Sender Policy Framework is a DNS TXT record that lists the authorised sources of mail for your domain. When a receiving server gets a message, it checks the sending server's address against the SPF record for the domain in the envelope sender (the MAIL FROM address used during transmission). If the source isn't listed, the message fails SPF. SPF validates the transmission-level sender, not the From address a person sees in their inbox, which is why it can't stand alone.

DKIM: a signature that proves the message wasn't forged

DomainKeys Identified Mail adds a cryptographic signature to the header of every outbound message. Microsoft 365 signs the message with a private key that never leaves Microsoft's infrastructure, and the matching public key is published in your DNS. A receiving server retrieves the public key, verifies the signature, and confirms the message genuinely came from your domain and wasn't altered in transit. Because the signature travels with the message, DKIM survives some forwarding scenarios that break SPF.

DMARC: the policy that ties them together and reports back

Domain-based Message Authentication, Reporting and Conformance is the record that turns SPF and DKIM into enforcement. DMARC does two things SPF and DKIM cannot. First, it checks alignment, that the domain the recipient actually sees in the From address matches the domain that passed SPF or DKIM, which is what stops a spoofer passing SPF on their own domain while displaying yours. Second, it tells receivers what to do with mail that fails (nothing, quarantine, or reject) and asks them to send you reports. A message passes DMARC if either SPF or DKIM passes with alignment; it only fails if both fail.

Step 1: publish the SPF record

Microsoft 365 provides no admin portal or PowerShell command for SPF. The record is created at your domain registrar or DNS hosting service, wherever your domain's DNS is managed. For a domain that sends mail only through Microsoft 365, the complete record is a single DNS TXT entry:

Reading it left to right: v=spf1 identifies the record as SPF; include:spf.protection.outlook.com authorises Microsoft 365's sending infrastructure; and -all is the enforcement rule, a hard fail that tells receivers any source not listed is not authorised. Microsoft recommends -all (hard fail) rather than ~all (soft fail) for Microsoft 365 domains, because DMARC then has a clear failure to act on. The record is published as a TXT record at the root of the domain (the host is the domain itself, often entered as @).

Two rules cause most SPF problems, and both are worth committing to memory:

1. 1One SPF record per domain. A domain or subdomain may have exactly one SPF TXT record. If a second record exists, receivers return a permanent error and SPF fails entirely. When you add a new sending service, you edit the single existing record, you never publish a second one.
2. 2The 10 DNS lookup limit. When a receiver evaluates SPF, every include: statement triggers at least one DNS lookup, and nested includes add more. If evaluation requires more than 10 lookups, SPF fails with a permanent error. Microsoft's own include: counts as one; the trouble starts when several third-party services are stacked into the same record. Individual ip4: and ip6: addresses do not count toward the limit.

If a domain also sends from an on-premises Exchange server, add its public IP: v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all. Adding third-party marketing or CRM senders is covered further down, because that is where most records break.

Step 2: enable DKIM in the Microsoft Defender portal

Unlike SPF, DKIM for a custom domain is enabled through the Microsoft Defender portal, which then tells you the two CNAME records to publish. The default *.onmicrosoft.com domain is already DKIM-signed automatically; the work here is enabling DKIM for the custom domain your people actually send from.

1. 1Go to the Microsoft Defender portal at security.microsoft.com and open the Email authentication settings page, DKIM tab (security.microsoft.com/authentication?viewid=DKIM).
2. 2Select your custom domain from the list. Because DKIM isn't enabled yet, the portal shows the two CNAME values you need to publish in a Publish CNAMEs section, use the copy option to capture them exactly.
3. 3At your DNS host, create the two CNAME records using those values.
4. 4Return to the DKIM tab and slide the toggle for the domain to Enabled. Microsoft 365 checks that the CNAME records resolve; once detected, the status shows the domain as signing and the option to rotate keys becomes available.

The two CNAME records follow this structure. The host names are the same for every Microsoft 365 organisation, but the target values are unique to your tenant and must be taken from your own portal:

For a domain contoso.com enrolled under contoso.onmicrosoft.com, the first record's target reads like selector1-contoso-com._domainkey.contoso.onmicrosoft.com or, in the current format, includes a tenant-specific partition character such as selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft. This is why the values must be copied from the portal and never guessed, the partition character differs between tenants. Microsoft 365 generates two selectors so that DKIM keys can be rotated without an outage: one selector stays live while the other is rotated. If PowerShell is preferred, Get-DkimSigningConfig returns the same Selector1CNAME and Selector2CNAME values.

Step 3: publish DMARC and roll it out in stages

With SPF published and DKIM confirmed as signing, DMARC ties them together. The DMARC record is a TXT record published at the host _dmarc for the domain (so _dmarc.contoso.com). The single most important discipline with DMARC is a staged rollout: the goal is p=reject, but you get there gradually, watching the reports at each stage so you never block legitimate mail.

Start in monitoring mode. This publishes a policy that takes no action on failures but asks receivers to send you aggregate reports:

The tags: v=DMARC1 identifies the record; p=none is the policy (monitor only, take no action); pct=100 applies the policy to all failing mail (the default if omitted); and rua=mailto: is the address that receives the daily aggregate reports. Leave this in place long enough to see the full picture of who sends mail as your domain, typically two to four weeks for a normal business, longer if your sending is seasonal or spread across many services.

Once the reports show your legitimate sources are passing, move to quarantine, which sends failing mail to Junk at the receiver. You can ramp the percentage to limit exposure while you watch, for example pct=25 then pct=50 then pct=100:

When quarantine has run cleanly with no legitimate mail affected, move to full enforcement. This is the record that actually protects your domain, it instructs receivers to reject mail that fails authentication:

A DMARC record on a parent domain automatically covers subdomains that don't have their own record, but each subdomain still needs its own SPF and DKIM to actually pass. If you run several sending subdomains, roll each one out separately, starting with the lowest-volume domain and saving the main domain for last.

Reading the DMARC aggregate reports

The rua address receives one report per day per reporting provider, as a compressed XML attachment. Raw XML is difficult to read by hand, and the practical answer for most organisations is a DMARC reporting service that turns the reports into a dashboard, several are listed in Microsoft's Intelligent Security Association catalogue. Whether read raw or through a service, the reports answer the questions that make a safe rollout possible:

• Which IP addresses and services are sending mail as your domain, including sources you may have forgotten, an old CRM, a finance system, a mail-merge tool.
• Whether each source is passing SPF, DKIM, both or neither, and critically whether it is passing with alignment (the domain the recipient sees matching the authenticated domain).
• The volume of mail from unknown or unauthorised sources, which is where spoofing and phishing campaigns show up.

The pattern to watch for before tightening the policy is a legitimate service that passes SPF or DKIM on its own domain but fails alignment against yours, that is the signal to fix the sender's configuration before moving to quarantine or reject, not after. Send the reports to a dedicated shared mailbox or Microsoft 365 group, never an individual's inbox, so the security team has shared visibility and the reports survive staff changes.

Handling third-party senders without breaking their mail

Most domains send through more than Microsoft 365: an email marketing platform, a CRM, an accounting system, a helpdesk, a survey tool. Each is a source of mail as your domain, and each has to be authenticated or DMARC will reject its mail once you reach p=reject. This is exactly what the monitoring phase is for, the aggregate reports reveal every one of these senders before enforcement can hurt them.

1. 1For each third-party sender, follow the vendor's own instructions. Typically this means adding their include: to your SPF record and setting up DKIM signing so they sign with your domain, which is what produces alignment.
2. 2Where a service lets you set a custom sending domain, use a subdomain dedicated to it, for example news.yourdomain.com.au for a marketing platform. The subdomain gets its own SPF and DKIM, keeping bulk or automated mail off the reputation of your primary domain.
3. 3Watch the SPF lookup count as you add senders. Because every include: consumes at least one of your 10 lookups, a handful of third-party services can push a single root-domain SPF record over the limit. Moving services onto subdomains gives each its own lookup budget and is the cleanest fix.

Common mistakes that break email authentication

• Two SPF records. Publishing a second SPF record when adding a service, rather than editing the one that exists, causes a permanent error and SPF fails completely. There must be exactly one SPF record per domain.
• Using +all or ?all. An SPF record ending in +all authorises the entire internet to send as your domain, the opposite of protection. Use -all. ?all (neutral) is for testing only and gives no protection in production.
• Jumping straight to p=reject. Publishing an enforcing DMARC policy before monitoring will silently bin legitimate mail from services you forgot about. Always run p=none first and read the reports.
• Forgetting subdomains. A parent-domain DMARC record covers subdomains for policy, but each subdomain still needs its own SPF and DKIM to pass. A marketing subdomain with no DKIM will fail once the parent policy reaches reject.
• Guessing DKIM CNAME values. The selector targets are tenant-specific, including a partition character that differs between tenants. Copy them from the Defender portal; a hand-typed value leaves DKIM in a permanent CnameMissing state.
• Exceeding the SPF 10-lookup limit. Stacking every third-party include: into the root domain quietly breaks SPF once the eleventh lookup is required. Move services to subdomains or replace stable senders with their published IP ranges.