SPF, DKIM and DMARC for Microsoft 365: the complete setup, domain by domain
A domain without an enforced DMARC policy can be spoofed by anyone, and your partners have no way of knowing. The setup is not complex, but it has to be done in the right order and on all your domains, including those that never send email.
Three complementary mechanisms
SPF declares which servers may send for a domain. DKIM signs each message with a key whose public half is published in DNS. DMARC requires one of the two to pass and align with the domain shown in the From header, tells the receiver what to do on failure and sends you reports. None of the three is sufficient on its own.
SPF: one complete record
For a domain that only sends through Exchange Online:
contoso.com. TXT "v=spf1 include:spf.protection.outlook.com -all"
Add the other legitimate senders (marketing platform, business application, printer relay) while staying within SPF's limit of ten DNS lookups. A domain must have only one SPF record; two records make the result invalid. Whether to end with -all or ~all is debated; with DMARC enforced, what matters most is that the list is complete.
DKIM: enable the selectors
The initial onmicrosoft.com domain is signed by default, but your custom domains are not until DKIM is enabled for them. In the Defender portal (Email authentication settings > DKIM), each domain shows two CNAME records, selector1._domainkey and selector2._domainkey, to publish in your DNS before enabling signing. Copy the exact values shown by the portal: their format has changed over time and differs depending on when the domain was added. Key rotation is then done from the same page.
DMARC: a controlled progression
- p=none with aggregate reports: observation only, no impact on delivery;
- analyse the reports over several weeks to identify every legitimate sender and fix its alignment;
- p=quarantine, optionally using
pctfor a gradual rollout; - p=reject once the reports are clean.
_dmarc.contoso.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@contoso.com"
Aggregate reports are XML files that are hard to read at volume; a DMARC reporting service or tool saves a lot of time.
Common mistake. Staying at p=none indefinitely. That value protects nobody; it only exists to prepare for enforcement.
Parked domains
Domains that are registered but unused (old brands, variants, defensive registrations) are prime targets, because nobody monitors them. For each one, publish:
parked.example. TXT "v=spf1 -all" _dmarc.parked.example. TXT "v=DMARC1; p=reject" parked.example. MX 0 .
The last record is a "null MX", stating that the domain does not accept mail.
Requirements from large mailbox providers
Since 2024, several large consumer mailbox providers have tightened their requirements for bulk senders: SPF and DKIM authentication, a published DMARC policy and easy unsubscribe for commercial mail. Thresholds and details vary by provider and continue to change, so check the current conditions if you send high volumes, particularly through third-party platforms that sign on behalf of your domain.
What an audit checks
- a single valid SPF record on every accepted domain;
- DKIM signing enabled for every custom sending domain;
- a DMARC policy at quarantine or reject, with reports actually reviewed;
- protection of parked domains.