If you’re sending email from Microsoft 365 and noticing your messages landing in spam or junk folders, this guide is for you. I’ll walk you through setting up SPF, DKIM, and DMARC for a custom domain in Microsoft 365, step by step. By the end, you'll have the correct DNS records in place and a clear plan to keep things working reliably.
This tutorial is ideal for founders, operations managers, IT admins, or anyone managing outbound email for a new or recently rebranded domain. If you need a quick primer on the basics, check out this straightforward overview: SPF, DKIM, and DMARC simply explained.
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.
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:
v=spf1 include:spf.protection.outlook.com -allFor 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.
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.
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:
v=DMARC1; p=none; pct=100; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.comThis 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.
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.
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.include statements, or ask service providers for SPF-flattened options. Test after every change.p=none or decrease pct= coverage. Fix sender alignment and ramp your policy again. Microsoft recommends gradual rollout to avoid disruptions. (learn.microsoft.com)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.
Exceeding the 10 DNS lookup limit can cause an SPF 'PermError' leading your emails to fail SPF checks and potentially land in spam folders. Consolidate records and remove unnecessary services to avoid this pitfall. This isn't a suggestion; it's a technical constraint that'll trip up your email delivery.
Starting with a 'none' policy allows you to observe email authentication issues without immediate risk. Jumping straight to full enforcement can result in legitimate emails being quarantined or rejected. Assess your reports first to avoid unexpected headaches.
No, DNS access is non-negotiable for setting up these protocols. Without it, configuration is impossible, leaving your email domain susceptible to spoofing and phishing attacks. Enlist someone with the right access if you're locked out.
Not documenting changes is a rookie move, leading to blind troubleshooting when issues arise later. Treat your DNS records like a living document: failing to keep track could result in conflicting or obsolete configurations, harming your email deliverability.
New domains often struggle with deliverability because they lack reputation. Warming up by gradually sending emails and building engagement with authentic interactions helps establish credibility. Skip this step, and you're courting the spam folder.
Prematurely tightening DMARC policies without verifying email sources can trap legitimate messages. It's not a question of competence but process; nail down alignment first and enforce later to prevent accidental email purges.
Yes, using static DKIM keys over time can make your domain more vulnerable to cryptographic attacks. Regular key rotation strengthens security, minimizing chances of compromised signatures. Think of it as changing locks to keep intruders guessing.
Don't guess or improvise here; inadequate guidance can leave holes in your email authentication, risking unauthorized spoofing. Push for documentation or reconsider the provider; half-baked SPF/DKIM setups are a liability, not an oversight.
Faulty DKIM setup due to propagation delays can lead to unauthenticated emails failing checks. Often overlooked, but propagation confirmation ensures integrity in signing and prevents a cascade of email delivery issues.
No, the DMARC policy is advisory and not all servers comply strictly. Relying solely on receivers to enforce your policy is a flawed strategy; configure your own receiving filters to compensate where others don't.


