Microsoft 365 DNS Setup
Publish the SPF, DKIM and DMARC records a Microsoft 365 domain needs, then let DDMARC verify them and monitor the result.
What this page is
This is a DNS setup guide, not a tenant connection. DDMARC does not connect to Microsoft Graph, does not enumerate your mailboxes or users, and does not write DNS records for you. Signing in to DDMARC with a Microsoft account is single sign-on only — it asks for your name and email address, nothing more. You make the changes below in the Microsoft admin centre and your DNS host; DDMARC reads the public result.
What DDMARC Does For You
Recognises Microsoft as a sender
Microsoft sending IPs in your DMARC reports are labelled as Microsoft 365 rather than left as bare addresses, so you can tell your own mail from everything else.
Probes the right DKIM selectors
DDMARC knows Microsoft 365 signs with selector1 and selector2, and looks those up rather than guessing.
Validates what is published
Each DNS check reads your live SPF, DKIM and DMARC records and reports errors and warnings against them.
Watches for drift
On paid plans, scheduled monitoring re-checks these records and raises an alert if one changes or disappears.
Before you start
- • The domain is added and verified in the Microsoft 365 admin centre
- • You can edit DNS for the domain, at whichever host holds the zone
- • For the DKIM step, a Global Administrator or Exchange Administrator account (needed by Microsoft, not by DDMARC)
- • The domain is added in DDMARC, so you have its reporting address
1. Publish SPF
Microsoft 365 sends from a shared pool, authorised through a single include. Add it to the domain's existing SPF record — do not create a second one, since a domain may only publish one SPF record.
If anything else sends as this domain — a CRM, a helpdesk, a billing system — its include goes in the same record, before the all mechanism. SPF permits at most 10 DNS lookups, and DDMARC will warn you when you approach that limit.
2. Enable DKIM
Microsoft 365 uses CNAMErecords for DKIM, not TXT. You publish two CNAMEs that point at Microsoft, and Microsoft serves the actual keys behind them — which is what lets it rotate keys without you touching DNS again.
In the Microsoft 365 Defender portal
- 1Open the Microsoft 365 Defender portal
- 2Go to Policies & rules → Threat policies → Email authentication settings
- 3Select your domain under DKIM
- 4Click Create DKIM keys
- 5Microsoft shows the two CNAME records to publish
Replace example.com with your domain, and example.onmicrosoft.com with your tenant's initial domain. In the target, dots in your domain become dashes — mail.example.com becomes selector1-mail-example-com. Copy the exact values Microsoft shows rather than composing them by hand. Once the CNAMEs resolve, return to the portal and turn DKIM signing on.
3. Publish DMARC
Point the reporting address at the mailbox token DDMARC issued for this domain. Each domain has its own token; there is no shared address, and a generic one will not route.
Start at p=none so nothing is rejected while you find every legitimate sender, then move to quarantine and rejectonce your reports are clean. DDMARC's policy rollouts walk that progression for you.
4. Verify in DDMARC
Once the records are live, run a DNS check on the domain. DDMARC resolves SPF, DKIM and DMARC, validates each one and returns an overall status.
GET /api/v1/domains/{domain_id}/dns-checkcurl -X GET "https://api.ddmarc.com/api/v1/domains/42/dns-check?refresh=true" \
-H "X-API-Key: $DDMARC_API_KEY"Or just open the domain in the dashboard and use the DNS check there. Records can take up to 48 hours to propagate, though most hosts are far quicker.
Troubleshooting
DKIM will not enable in the Defender portal
Microsoft refuses to switch signing on until both CNAMEs resolve. Confirm they are published at the exact hostnames Microsoft gave, then retry.
DDMARC reports DKIM as missing
Check the CNAMEs are CNAMEs and not TXT records, and that your DNS host has not appended the domain twice, producing selector1._domainkey.example.com.example.com.
SPF fails for mail that clearly came from Microsoft
Usually a second SPF record on the domain, or a forwarder rewriting the envelope sender. Check the DNS check output for a duplicate-record warning, and look at whether DKIM still aligns for those messages.
No reports are arriving
Confirm the rua address in your DMARC record uses this domain's own token. A DMARC record copied from another domain sends its reports somewhere else.
Records were correct, and now are not
Something re-wrote the zone. Enable scheduled DNS monitoring so the next change raises an alert instead of being discovered weeks later.
Done when
- SPF includes spf.protection.outlook.com and stays under 10 lookups
- Both DKIM CNAMEs resolve and signing is switched on in the Defender portal
- A DMARC record exists at _dmarc with this domain's own rua token
- The DDMARC DNS check comes back pass
- Aggregate reports are arriving in DDMARC