Office365: How To Setup SPF DKIM DMARC (Step-by-Step Guide)

You'd need:

• Global admin access to your Microsoft 365 tenant.
• Access to your domain’s DNS configuration (via registrar or DNS host, like Cloudflare, GoDaddy, or Route 53).
• Your custom domain must already be added and verified in Microsoft 365.
• An email address set up to receive DMARC reports (e.g., dmarc@yourdomain.com).
• Be prepared to allow time for DNS propagation; changes can take minutes to hours.

Step 1: Map your real sending sources

Start by making sure you don’t accidentally block your own emails. List every platform or application that sends mail using your domain, including Microsoft 365, helpdesk tools, billing apps, and notification services.

Ask each vendor for their precise SPF and DKIM setup instructions, most reputable services provide documentation. If a provider can’t offer clear guidance, hold off on adding them until they can. Modifying your DNS without a clear map of senders often leads to unexpected failures.

Tip: Make sure you keep track of which senders are meant to send what, such as news@ from Microsoft 365, receipts from your billing app, and tickets from your helpdesk. This will help you ensure that you correctly authorize each sender in your SPF records later.

Step 2: Publish a correct SPF record

SPF (Sender Policy Framework) tells receiving mail servers which servers are authorized to send mail for your domain. If you only send email from Microsoft 365, publish this TXT record at your domain’s root:

For US Government tenants, use include:spf.protection.office365.us, and for 21Vianet use include:spf.protection.partner.outlook.cn. (learn.microsoft.com)

If you also use other services, add those mechanisms before -all. Always keep a single SPF record per domain, merge new information instead of creating duplicates. Stay within the SPF limit of 10 DNS lookups (per RFC 7208): mechanisms like include, mx, a, exists, and redirect all count toward this limit.

If you’re unsure about whether to use -all or ~all: if you are still discovering all the systems that send mail as your domain, start with ~all (soft fail). Once you have your list complete and everything is working as expected, change to -all for strict enforcement. Always document changes for easy troubleshooting later.

Step 3: Enable DKIM for your domain

DKIM adds cryptographic signatures to your emails so receivers can confirm the messages came from you. In Microsoft 365, you’ll create two CNAME records in your DNS, then activate DKIM through the Defender portal.

Go to Microsoft 365 Defender portal: Email & collaboration > Policies & rules > Email authentication settings > DKIM. Select your domain and activate “Sign messages for this domain with DKIM signatures.” The Defender portal will show you two required CNAME records. Microsoft now uses CNAME targets ending with n‑v1.dkim.mail.microsoft for many tenants. (learn.microsoft.com)

Add two CNAME records in your DNS with hosts selector1._domainkey and selector2._domainkey, pointing to the exact values provided (e.g., selector1-yourdomain-com._domainkey.yourinitial.onmicrosoft.com or the newer ...n-v1.dkim.mail.microsoft versions). Be aware: some DNS providers auto-append the domain name. Only enter selector1._domainkey and selector2._domainkey as the host.

Wait for DNS to propagate (this may take up to 48 hours, and you can verify this via several free online DNS propagation checkers). After verifying propagation, return to the Defender portal and enable DKIM. You should see the status change to “Signing DKIM signatures for this domain.” Some DNS providers require extra time, so be patient.

In the future, you’ll rotate keys from this same DKIM page. Microsoft keeps two selectors for smooth rotation. Where available, use 2048-bit keys for stronger security.

Step 4: Publish a DMARC policy and roll it out in stages

DMARC lets you tell receiving servers how to handle emails that fail SPF and DKIM alignment checks. Start in a monitoring-only mode, then gradually add enforcement as you confirm your legitimate emails are passing authentication.

Create a TXT record at host _dmarc with the following values:

This sets your DMARC to monitoring mode (p=none); applies the policy to all messages (pct=100); and directs aggregate (rua) and forensic (ruf) reports to the specified email addresses. After a suitable observation period, you can change the policy to p=quarantine and ultimately to p=reject. Use the pct= parameter to gradually increase enforcement (25, 50, 75, 100) to ensure there are no surprises. (learn.microsoft.com)

If your inbound mail is routed through a gateway before reaching Microsoft 365, enable Enhanced Filtering for Connectors to make sure Microsoft 365 can correctly interpret DMARC. Also, check that “Honor DMARC record policy” is enabled in your anti-phishing settings.

Step 5: Validate, monitor, and keep it tidy

Test your setup: send an email from your Microsoft 365 mailbox to a test inbox you can check. Look at the email headers for the Authentication-Results line. You want to see spf=pass, dkim=pass, and dmarc=pass, all showing alignment with your domain.

Monitor the DMARC aggregate reports (rua) you receive. These reports show who is sending as your domain, and whether each sender passes or fails authentication. Address any unauthorized senders, then gradually tighten your DMARC policy from monitoring to quarantine and finally to reject.

Brand-new or cold domains may struggle to achieve inbox placement even with technical setup perfect. To build a clean sender reputation, consider warming your mailbox first. Tools like Mailwarm slowly exchange real emails with live inboxes, these opens, replies, and spam removals help establish your authenticity before you start real outreach. It’s not a marketing workflow, but a technical warm-up to lower spam risk.

Troubleshooting and common pitfalls

• DKIM toggle says “CNAME record does not exist.” Double-check that your CNAME hosts are exactly selector1._domainkey and selector2._domainkey, not the full domain. Many DNS panels append the domain automatically. Allow enough time for DNS to update, then retry in the Defender portal.
• SPF “PermError: too many DNS lookups.” You’ve run into the 10-lookup limit. Remove obsolete vendors, consolidate include statements, or ask service providers for SPF-flattened options. Test after every change.
• Legitimate mail is quarantined after raising DMARC. Revert your policy to p=none or decrease pct= coverage. Fix sender alignment and ramp your policy again. Microsoft recommends gradual rollout to avoid disruptions. (learn.microsoft.com)
• Some receivers don’t honor your DMARC policy. In some cases, certain receiving servers may not respect your DMARC policy. Microsoft 365, however, can be configured to honor senders' DMARC for inbound mail through anti-phishing policies. Remember to verify these settings.

Conclusion

You’ve now set up SPF, DKIM, and DMARC in Microsoft 365. The core process is: publish SPF with authorized senders, set up DKIM by adding two CNAMEs, launch DMARC in monitoring mode, and then move to quarantine and reject as the reports look clean. Keep track of any changes to your email stack to ensure your DNS records remain up to date.

If you’re launching a new domain or starting up with cold outreach, allow a warm-up period. A gradual warm-up can reduce the chance of emails landing in spam folders, especially for fresh inboxes. If you’d like an expert review of your DNS or policy setup, you can consult with deliverability specialists at mailadept for low-stress guidance and rollout support.