Your Microsoft 365 tenant does not set up SPF, DKIM and DMARC for you

Microsoft’s documentation is clear on this, but it is spread across three separate pages and the answer differs for each of the three records. Put side by side, the picture is uneven in a way that catches people out.

• SPF, initial domain. Configured for you. Microsoft owns the onmicrosoft.com namespace, and its documentation states you “don’t need to do anything”. You cannot modify that record either.
• SPF, custom domain. Partly done. Adding your domain to Microsoft 365 required an SPF record, so one exists. Microsoft’s own words are that you “still have more work to do for maximum email protection”, because that record probably does not list your CRM, your marketing platform, your accounting system or your on-premises scanner.
• DKIM, initial domain. Configured for you. Outbound mail from senders in contoso.onmicrosoft.com is automatically signed.
• DKIM, custom domain. Not configured. Microsoft’s documentation is blunt: “Currently, no DKIM signing occurs for outbound mail from custom domains.” Nothing happens until you publish two CNAME records.
• DMARC, any domain. Not configured, anywhere. Even for the initial domain, you have to create the TXT record yourself in the Microsoft 365 admin centre.

The practical consequence is that a tenant which has never been touched since setup has one and a half of the three controls in place, on the domain that matters. That is enough to look fine in a casual check and nowhere near enough to satisfy a receiving mail server that has been told to be strict.

It helps to be precise about the division of labour, because the three are routinely described as if they were interchangeable and they are not.

• SPF publishes the list of servers allowed to send for your domain. Critically, it validates the envelope sender, the MAIL FROM address, and not the From address your recipient actually sees. Microsoft states this directly: SPF “doesn’t consider the domain in the From address”.
• DKIM adds a cryptographic signature to the message so the recipient can verify it has not been altered in transit and that the signing domain vouches for it. Because the signature travels with the message, DKIM survives forwarding, where SPF does not.
• DMARC is the piece that ties the other two to the From address the human reads, and tells receiving servers what to do when that link fails. It is also the only one of the three that sends you a report.

The rule that matters is simple to state and easy to miss. A message passes DMARC if the From domain aligns with the SPF domain or with the DKIM signing domain. It fails only if both checks fail. That “or” is why DKIM is worth more than SPF on a Microsoft 365 tenant, and why the next section is where most estates come unstuck.

This is the fault we would look for first on any tenant, before touching a single record.

Microsoft publishes an alignment table, and one row in it explains more support tickets than the rest combined. A message with a From address of user@contoso.com, signed by contoso.onmicrosoft.com, fails DMARC alignment in relaxed mode and in strict mode. Not “usually passes”. Fails, in both modes.

The NCSC says the same thing in plainer language: “If you are using ‘example.co.uk’ in the Header From address, but using ‘onmicrosoft.com’ to DKIM sign your emails, then DKIM alignment will fail in all situations.”

So a tenant where nobody has configured custom-domain DKIM is not merely unsigned. It is signed by a domain that can never align, which means DMARC is resting entirely on SPF. And SPF, on its own, breaks the moment a message is forwarded, relayed through a third party or sent by a platform using its own bounce domain.

Fix the DKIM CNAMEs and that single change usually moves a domain from “passes when the wind is in the right direction” to “passes reliably”. It is the highest-value hour in the whole job.

Everyone agrees on the destination. The NCSC states that “having a DMARC policy of ‘reject’ on all of your domains is the best way to prevent spoofing of your email”, and Microsoft’s stated goal is “to get to a p=reject DMARC policy for all of your custom domains and subdomains”.

Where the two diverge is timing, and the difference is worth knowing. Microsoft tells you to allow “enough time” at each stage and never once says how long. The NCSC does, and its figures are the most useful thing in the whole collection:

• Monitor p=none reports for at least two weeks before drawing any conclusions.
• Many organisations move on from p=none after about six to eight weeks.
• At p=quarantine with pct=100, monitor for at least four weeks.
• Many organisations move from p=quarantine to p=reject after about three months.
• After switching to p=reject, monitor closely for at least a further two weeks.

That adds up to somewhere near five months for a domain with a reasonable spread of sending systems, and the NCSC is explicit that you can roll back to p=quarantine if something breaks. Anyone promising you p=reject in a fortnight is either working with a very simple estate or is about to quarantine your payroll notifications.

One consequence of publishing an enforcing policy deserves more attention than it gets. Microsoft states that outbound mail from your Microsoft 365 domain which fails DMARC at the destination is routed through the high-risk delivery pool if your own policy is p=reject or p=quarantine, and adds: “There’s no override for this behavior.” Publishing an enforcing policy therefore raises the stakes on your own outbound hygiene, not just on impersonators.

This is the part vendor content tends to skip, and it is the part worth reading twice. The three records are genuinely valuable and they solve a narrower problem than most people assume.

• They protect other people from you, not you from other people. The NCSC’s phishing guidance puts it exactly this way: setting up DMARC “stops phishers from spoofing your domain”. That matters, but it is not the thing hurting you. Phishing was the most prevalent breach or attack type by some distance in the government’s 2025/2026 breaches survey, hitting 38% of UK businesses, and none of those messages were stopped by the victim’s own DMARC record. Inbound protection is a different job, done by Microsoft Defender for Office 365 and by your identity controls.
• They do nothing about lookalike domains. A message from vantage365-support.com can pass its own SPF, DKIM and DMARC perfectly, because the attacker owns that domain and configured it properly. Authentication confirms the sender is who the headers say. It does not confirm the sender is who you thought.
• They do nothing about display-name spoofing. A free webmail account with the display name set to your finance director will authenticate flawlessly against its own provider.
• They do nothing about a compromised account. Thread hijacking and invoice fraud usually arrive from a real, licensed, fully authenticated mailbox belonging to a real supplier. Every check passes, because nothing is being faked. Our post on the Microsoft 365 password spray attack covers how those accounts get taken in the first place.
• Forwarding and mailing lists break them. SPF fails on relay. DKIM fails if anything modifies the message, which includes a well-meaning outbound scanner appending a disclaimer after signing. The NCSC is specific here: a DKIM signature “should be the last addition to a message before it is released by an email server”.
• Reporting has a large blind spot on Microsoft 365. Microsoft sends DMARC aggregate reports only if your MX record points directly at Microsoft 365. If you route inbound mail through a third-party gateway first, or run hybrid with delivery to on-premises, you get nothing. Microsoft also never sends forensic reports at all, even if you publish a valid ruf= address.

None of that is an argument against doing the work. It is an argument against treating it as a security programme rather than as basic hygiene that happens to be visible to everyone you email.

Here is the thing most content on this topic currently gets wrong, and it is worth checking for yourself.

Mail Check, the NCSC’s free service for assessing SPF, DKIM, DMARC and TLS, was retired on 31 March 2026 along with Web Check. The NCSC announced it in November 2025 and now recommends a commercial external attack surface management product, alongside its “Check your cyber security” service. Early Warning and DNS Check were not affected.

What makes this awkward is that the guidance pointing at Mail Check was never updated. As at the time of writing, the NCSC’s own email security collection still carries a section headed “The NCSC Mail Check service” describing it as a free platform open to “any UK organisation”. GOV.UK’s Securing government email guidance still tells departments to sign up to it. The Government Security MTA-STS guidance still assumes TLS reports are pointing at it. Three separate official pages, all still recommending a service that no longer exists, roughly six months on.

So if a checklist tells you to sign up to Mail Check, it is out of date, and the question of where your DMARC aggregate reports now go is one you have to answer deliberately rather than by following the guidance.

Most of what goes wrong is mundane. These are the ones that recur.

• Publishing two SPF records. Only one SPF record is permitted per domain. Two produces a permerror, and a permerror is a hard failure, not a warning. It happens when a new platform’s setup wizard tells you to “add this record” and nobody merges it into the existing one.
• Blowing the 10-lookup limit. include:, a, mx, exists and redirect each cost a lookup, and nested includes count towards your total. A handful of SaaS platforms will do it. The NCSC’s fix is better than flattening: give each third-party sender its own subdomain, because each subdomain gets its own lookup budget.
• Flattening include:spf.protection.outlook.com into IP addresses. Do not. Microsoft states its sending infrastructure uses dynamic addresses that change frequently. If you flatten anything else, Microsoft advises reviewing the entries at least quarterly.
• Leaving ~all in place and assuming DMARC will cover it. Microsoft’s own note is easy to miss: the DMARC policy is effectively ignored for SPF soft-fail results if the message also lacks a DKIM signature. Get to -all once you know your sources.
• Forgetting parked domains, and then treating them all the same. Microsoft gives three different instructions here, deliberately. For a domain you never send from, publish SPF as v=spf1 -all and DMARC as v=DMARC1; p=reject;, and publish no DKIM record at all. The absence of a public key is what prevents validation of a forged signature.
• Expecting a key rotation to take effect immediately. It takes four days, 96 hours, before a rotated DKIM key starts signing. Microsoft’s documented default key size is still 1024-bit, and because the size only updates on the next active selector, it takes two rotations before both selectors reach 2048-bit. The NCSC recommends 2048-bit and suggests rotating roughly every 12 months.
• Sending DMARC reports to a person. They arrive daily as gzipped XML attachments. Microsoft’s own advice is to use a dedicated mailbox or Microsoft 365 group rather than an individual’s inbox, and to name someone responsible for reading them.

The pro tip underneath all of these is that the technical work is the small half. The real task is building an honest list of every system that sends mail as you, and that list is almost always longer than the person maintaining DNS believes it to be.