In the Microsoft 365 tenants I work with, SPF, DKIM and DMARC for Exchange Online have suddenly become a topic again. Early this year Google and Yahoo raised the bar for bulk senders. Starting February 2024 they expect authenticated email (SPF, DKIM, DMARC) with proper policies. Otherwise messages may land in spam or not get delivered at all. As a result, many organisations are rushing to check their DNS records and mail flows, some for the first time in years. If all you ever set up was an SPF record with include:spf.protection.outlook.com, now is a good moment to sort out the rest.

SPF and DKIM in Exchange Online still trip up many tenants

SPF, DKIM and DMARC are the basis of modern email authentication. Nothing new there. In Exchange Online, SPF is usually simple, and a DNS TXT record like v=spf1 include:spf.protection.outlook.com -all covers pure Microsoft 365 mailboxes. It gets messy once third-party senders come into the picture, such as newsletters, ticketing systems or marketing tools. I've seen plenty of tenants hit the SPF limit of 10 DNS lookups, forget to update records after a migration, or keep old entries around for no good reason. Microsoft's SPF/DKIM/DMARC backgrounder is a useful reference if you want to go over the details again.

DKIM is easier in Exchange Online than it used to be. The Defender portal generates two CNAMEs per custom domain (selector1 and selector2), which you add to your DNS. Once DNS has propagated, you enable DKIM signing in the portal. In practice I still run into missing CNAMEs, steps that got skipped after a domain move, and teams who don't know that enabling DKIM is a manual task. One mistake I see often is setting up DMARC before DKIM is enabled. SPF is then your only line of defence, and that falls short of best practice.

DMARC should start with a soft policy and get stricter later

DMARC tells the receiving server what to do with emails that fail SPF and/or DKIM. Most organisations begin with the relaxed "none" policy and collect reports before enforcing anything. That means adding a DNS TXT record like this:

_dmarc.mydomain.com.   IN   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]"

The RUA reports show you how the major providers judge your emails. Only once you've gone through them should you think about moving to "quarantine" or "reject", and only after you've made sure every legitimate sender authenticates properly. Microsoft's DMARC setup guide describes the process well. If you switch to "reject" too early, legitimate mail can vanish, for instance when a legacy ticketing system sends messages in your name without proper authentication.

Third-party senders cause most of the trouble

Third-party services make all of this harder. Marketing platforms, helpdesks and booking tools often still send email as your domain, but through their own servers. Each of them has to be included in SPF (without going over the 10-lookup limit) or, better, DKIM-sign with your domain's keys. Very few organisations actually have a complete and current list of these systems, and it's easy to miss one or two.

Practical tip: I always recommend reviewing every system that sends mail for your domain once a quarter, and keeping a clean record of all SPF/DKIM settings in your documentation. Otherwise a new tool or provider will catch you out sooner or later.

The missteps I come across most often:

  • SPF lookup limit exceeded (too many includes)
  • DKIM records missing or misconfigured
  • DMARC set to "reject" but third-party senders not covered

This takes process discipline. That's why I insist on building SPF, DKIM and DMARC checks into every change and rollout process.

A diagram shows how the checks fit together

With several systems involved, a diagram makes things much clearer. The Mermaid chart below shows mail from Exchange Online and from third-party sources travelling to the recipient and passing through the SPF, DKIM and DMARC checks:

flowchart LR
    MailClient["Sender (Exchange Online)"] --> MTASend["SMTP Server (Microsoft)"]
    ThirdPartySender["Third-Party Sender"] --> ExternalMTA["SMTP Server (Third Party)"]
    MTASend --> RecipientMTA["Recipient Mail Server"]
    ExternalMTA --> RecipientMTA
    RecipientMTA --> SPFCheck["SPF Check"]
    RecipientMTA --> DKIMCheck["DKIM Check"]
    RecipientMTA --> DMARCCheck["DMARC Check"]
    SPFCheck --> Decision["Decision (Accept, Quarantine, Reject)"]
    DKIMCheck --> Decision
    DMARCCheck --> Decision

Figure: SPF, DKIM and DMARC checks on incoming mail

Laid out like this, you can quickly see where things can break or slip through, especially when not all outbound mail goes through Exchange Online.

DNS hygiene only works as an ongoing process

Getting the technical setup right is only part of the job. The organisations that stay out of trouble regularly check who is sending mail in their name and keep their SPF, DKIM and DMARC records current. If you treat mail authentication as a one-off task, it will probably come back to bite you, especially as you add other security controls such as Conditional Access (see /blog/conditional-access-entra-id-getting-started). My advice is to start gently with DMARC and DKIM, act on the failure reports, and tighten the policies only when you're confident that all legitimate mail flows are covered. That way your mailboxes stay clean and your mail keeps reaching people reliably in 2024.