Setting up SPF, DKIM and DMARC on Microsoft 365

Microsoft DKIM-signs all outbound mail by default, including before you have configured anything. That is a good thing, and it is also what misleads everyone: the signature carries your tenant domain, yourcompany.onmicrosoft.com, not your own.

The result is a mail test proudly reporting “DKIM: PASS” while DMARC fails. The reason is alignment: the domain that signed must be the one your recipient sees in the From field. onmicrosoft.com aligns with nothing.

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

One include, flattened by Microsoft, so it costs a single lookup (checked 22 August 2026). Add the other services sending in your name to the same record, and watch the ten-lookup limit: a Microsoft estate with a CRM, an invoicing package and an e-signature platform exceeds it sooner than you would expect.

1. 01

   Find your tenant name

   It ends in .onmicrosoft.com and is shown in the Microsoft 365 admin centre under Settings then Domains. You need it to compose the two CNAMEs.

2. 02

   Publish both CNAMEs

   Two records, not one. The second exists for key rotation: Microsoft switches between them without mail ever going unsigned. The pattern is fixed; only your domain and tenant change. Take the exact values shown in the portal rather than reconstructing them: one misplaced hyphen and nothing resolves.

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

3. 03

   Wait for propagation

   Fifteen minutes is often enough, but allow a few hours depending on your zone's TTL. The next step will fail while either CNAME does not resolve.

   dig +short CNAME selector1._domainkey.example.com
   dig +short CNAME selector2._domainkey.example.com

4. 04

   Enable signing in the Defender portal

   Go to security.microsoft.com, then Email & collaboration, Policies & rules, Threat policies, Email authentication settings, DKIM tab. Select your domain and turn on “Sign messages for this domain with DKIM signatures”.

5. 05

   Publish DMARC

   Microsoft does not manage your DNS zone: the DMARC record is published at your host, as everywhere else. Start in monitoring, then follow the rollout.

   _dmarc.example.com.  IN  TXT
     "v=DMARC1; p=none; rua=mailto:reports@example.com"

Since 5 May 2025, Microsoft rejects mail from high-volume senders without SPF, DKIM and DMARC. If you send more than 5,000 messages a day to Outlook.com, Hotmail or Live, this is the message you will see.

The domain named in brackets is the one to fix, and it is not always the one you would expect: it is the Header-From domain. If you send on a client's behalf, it is their domain that has to be authenticated, not yours.

Microsoft filters what arrives in your mailboxes remarkably well, and none of the above concerns inbound mail. The subject is the opposite direction: messages going out with your name on them, from servers belonging neither to you nor to Microsoft, addressed to your clients. Microsoft has no way of stopping those.

And once all three records are live, cousin domains and misleading display names still go through: see what DMARC does not stop.