Setting up SPF, DKIM and DMARC on Microsoft 365
Microsoft 365 handles a huge share of Danish business mail, and its authentication defaults are only half-done: SPF works out of the box, but DKIM for your custom domain must be enabled by hand, and DMARC is entirely up to you.
The three records
SPF: v=spf1 include:spf.protection.outlook.com -all (add other services' includes before the all). DKIM: in Defender portal → Email authentication settings → DKIM, select your domain and enable — Microsoft shows two CNAME records (selector1/selector2._domainkey → …onmicrosoft.com) to add in your DNS first. Until you do this, Microsoft signs with the onmicrosoft.com domain, which does NOT align with your From address. DMARC: start with v=DMARC1; p=none; rua=mailto:reports@yourdomain.dk and step up per our enforcement guide.
The pitfalls specific to Microsoft 365
The onmicrosoft.com trap: everything "passes DKIM" in headers, but for the wrong domain — alignment fails and DMARC with it. Enabling custom-domain DKIM (the two CNAMEs) is the fix; verify the selector1/selector2 keys resolve with our DKIM Inspector.
Hybrid and relays: on-premises Exchange, multifunction printers and line-of-business apps that relay via your smart host often bypass DKIM signing. Route them through Microsoft 365 (or give them their own authenticated subdomain) or they will fail DMARC at enforcement.
Forwarding: Microsoft rewrites less than it used to (ARC helps), but distribution lists can still break SPF alignment — another reason DKIM must be aligned, since it survives forwarding.
Once enabled, run a full check: SPF tree under 10 lookups, both selectors serving 2048-bit keys, DMARC parsed and graded — the free scan covers all of it.
Free tools that help
- DKIM Inspector: Find published DKIM keys across common selectors and analyze key strength.
- DMARC Inspector: Parse and grade your DMARC policy, reporting addresses and alignment settings.