SPF, DKIM and DMARC on Microsoft 365: the records and the order

When you added your domain to Microsoft 365, the set-up asked you to publish an SPF record. Microsoft's own example for a domain that sends only through Microsoft 365 is v=spf1 include:spf.protection.outlook.com -all. That much is usually in place.

DKIM is the part that is usually missing. Microsoft signs every message, but for a custom domain it signs with your tenant's built-in name (yourcompany.onmicrosoft.com) until you switch on signing with your own. Microsoft's alignment table is plain about the result: a message from you@yourcompany.ie signed as yourcompany.onmicrosoft.com does not align, so for DMARC it counts as unsigned.

Microsoft's own advice is that SPF alone is not enough, and that DKIM and DMARC should follow.

Look up the TXT record at the root of your domain, or run the free email security check. You want exactly one record beginning v=spf1, with include:spf.protection.outlook.com in it and an include: for each other service that sends as you.

Microsoft recommends ending it -all for Microsoft 365 domains. Two records, or a record over ten DNS lookups, both make SPF return an error; our guide to the lookup limit covers that fix, including Microsoft's warning never to replace its own include: with addresses.

In the Microsoft Defender portal, go to Email & collaboration, then Policies & rules, then Threat policies, then the Email authentication settings page, and open its DKIM tab. Your custom domain is listed there with its signing switched off.

DMARC is a TXT record named _dmarc at your domain. Microsoft's first step is a policy that changes nothing and asks for reports: v=DMARC1; p=none; rua=mailto: followed by a mailbox you will read. Microsoft suggests a shared mailbox or a Microsoft 365 group for the reports, not one person's inbox.

Microsoft describes the reports as XML attachments, usually compressed and usually sent once a day by each mail system that sends them. They list the servers that sent mail as your domain and whether each passed. Microsoft points to reporting services that turn the XML into something readable, and says Microsoft 365 itself does not send the per-message failure reports (ruf).

When the reports show your own mail passing, from every service that sends it, Microsoft's next step is p=quarantine, and then p=reject. Its guidance is to start with a domain or subdomain that sends little mail, go slowly, and save the main domain for last.

At reject, a receiving server is told to refuse mail that fails, which is the setting that stops invoices being sent in your name. Microsoft 365 applies the same rule to mail coming in: a message from a domain at p=reject that fails is refused with a 550 5.7.1 error, where the anti-phishing policy's "honour DMARC" setting is on, which Microsoft recommends.

Send a message to a Gmail or Outlook.com address and open the headers. The Authentication-Results line should read spf=pass, dkim=pass with header.d= your own domain, and dmarc=pass. Then run the email security check again: it should show DKIM found under selector1 and selector2, and DMARC enforced.

Keep reading the reports. A new service added next year sends as you and fails until somebody adds it, and at p=reject that failure is a bounced email.