Set up SPF, DKIM, and DMARC on Microsoft 365
Microsoft 365 is the email host: it generates DKIM keys in the Defender portal and tells you the exact SPF, DKIM (CNAME), and DMARC records to publish, but those records are added at your domain's actual DNS host/registrar, not inside Microsoft (unless your DNS is delegated to Microsoft).
Where to add records on Microsoft 365
Two different consoles. (1) The required-records list lives in the Microsoft 365 admin center at admin.microsoft.com > Settings > Domains > click your domain > DNS records tab ('Manage DNS' launches the add-records wizard). (2) DKIM keys are generated and enabled in the Microsoft Defender portal at security.microsoft.com > Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM tab (direct link security.microsoft.com/authentication?viewid=DKIM; the older security.microsoft.com/dkimv2 link redirects here). Microsoft only writes DNS for you if your domain's nameservers are delegated to Microsoft, or if your registrar supports Domain Connect; otherwise these consoles just SHOW the values and you publish them at your DNS host (e.g. GoDaddy, Cloudflare, Namecheap, your registrar).
- Sign in to the Microsoft 365 admin center (admin.microsoft.com) as a Global admin or Domain Name admin, go to Settings > Domains, click your custom domain, and open the DNS records tab to see the exact records Microsoft requires (MX, the SPF TXT, and the two DKIM CNAMEs).
- For SPF and DMARC, go to your actual DNS host / registrar's DNS management page (not Microsoft, unless Microsoft hosts your DNS) and choose Add record, then select TXT as the type.
- Add the SPF TXT record: Host/Name = @ (root), Value = v=spf1 include:spf.protection.outlook.com -all, TTL 1 hour (3600). Keep just ONE SPF record for the domain.
- Add the DMARC TXT record: Host/Name = _dmarc, Value = v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com (start at p=none to monitor, then tighten to p=quarantine, then p=reject).
- For DKIM, in the Microsoft Defender portal go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM tab (security.microsoft.com/authentication?viewid=DKIM), select your domain, and slide its toggle toward Enabled — it reports CnameMissing and reveals the two CNAME values (hosts selector1._domainkey and selector2._domainkey). Publish those two as CNAME records at your DNS host using the EXACT targets Microsoft shows.
- Use TTL 1 hour (3600 seconds) and save each record; wait for the CNAMEs to propagate, then return to the domain's details flyout on the Defender DKIM tab and switch 'Sign messages for this domain with DKIM signatures' to On.
The three records on Microsoft 365
SPF Sender Policy Framework
SPF is a single TXT record at the domain root. There is no Microsoft tool to manage SPF for a custom domain — you publish it at your DNS host. Use host/name = @ (or blank/root, per your DNS host's convention) and value v=spf1 include:spf.protection.outlook.com -all. Publish only one SPF record per domain; if you send through other services too, merge their includes into this single record (and stay under the SPF 10 DNS-lookup limit) rather than creating a second SPF record.
DKIM DomainKeys Identified Mail
DKIM keys are GENERATED by Microsoft, not by you. In the Microsoft Defender portal go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM tab (security.microsoft.com/authentication?viewid=DKIM), select your custom domain, and slide its toggle toward Enabled to reveal the two CNAME values Microsoft assigns. The hosts are always selector1._domainkey and selector2._domainkey. IMPORTANT: the targets changed — for NEW custom domains (the updated format Microsoft rolled out in May 2025) they look like selector1-<domain-with-dashes>._domainkey.<tenant>.<char>-v1.dkim.mail.microsoft (ending in .dkim.mail.microsoft), while domains enrolled before that still use the older selector1-<domain>._domainkey.<tenant>.onmicrosoft.com form. Microsoft 365 uses CNAMEs that point at Microsoft-hosted keys (NOT a TXT key like Google Workspace), so Microsoft can rotate keys without you touching DNS. Always copy the exact target strings the portal shows rather than reusing examples. Publish both CNAMEs at your DNS host, wait for propagation, then switch the 'Sign messages for this domain with DKIM signatures' toggle to On.
DMARC reporting and policy
DMARC is a TXT record you publish at your DNS host with host/name = _dmarc. For a CUSTOM domain, Microsoft has no admin UI or PowerShell cmdlet to manage DMARC — you create it at your registrar/DNS host (the admin center can only add a DMARC record for your *.onmicrosoft.com domain, whose DNS Microsoft hosts). Value e.g. v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Start with p=none to collect aggregate reports, confirm SPF and DKIM are passing and aligned for Microsoft 365 mail, then move to p=quarantine and eventually p=reject. One DMARC record at _dmarc automatically covers all subdomains that don't have their own _dmarc record.
Need the record values? Generate a valid SPF and DMARC record with the record generator, then learn what each one does: SPF, DKIM, DMARC.
Microsoft 365 gotchas
- Sliding the Defender DKIM toggle before both CNAMEs are published shows Status = CnameMissing (older tenants pop a 'No DKIM keys saved for this domain' dialog) — publish the two CNAMEs first, wait for propagation, then enable signing from the domain's details flyout.
- DKIM here is CNAME, not TXT — never paste a CNAME target into a TXT record, and if your DNS host auto-appends your domain to CNAME values, don't double up the trailing domain. Copy Microsoft's exact targets; the May-2025 format ends in .dkim.mail.microsoft and differs from the old selector1-<domain>._domainkey...onmicrosoft.com examples.
- Only one SPF record is allowed per domain. A second SPF TXT record (e.g. left over from a previous provider) makes SPF permerror/invalid — merge all includes into a single v=spf1 ... -all record.
- If Microsoft does NOT host your DNS, the admin center can't write records for you — it only displays them; you add them at your real DNS host/registrar. Conversely, if you delegate DNS to Microsoft (or use Domain Connect), records you edit elsewhere can be overwritten.
- Microsoft's record tables specify TTL 1 hour (3600s) for SPF/DKIM/MX — TTL controls DNS caching, not 'lookup timeouts' (the SPF concern is the 10-DNS-lookup limit, not TTL), and Exchange Online doesn't support a TTL of 6 hours or more. After publishing the DKIM CNAMEs, allow a few minutes up to ~an hour for Microsoft to detect them before the signing toggle will turn On.
Records set. Now make sure you actually land.
SPF, DKIM, and DMARC on Microsoft 365 get you authenticated, but inbox placement also needs sender reputation and domain warmup. Scheduler Zero handles both so your cold email reaches the inbox.