This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.
You added your domain to Microsoft 365, mail works, and then a customer says your order confirmations land in spam. Or a checker tells you “no DMARC record found”. Microsoft will happily run your mailboxes, but it will not publish your SPF, DKIM or DMARC records for you. Those three records live at whoever hosts your DNS, and you add them by hand.
This guide covers the setup in the order that avoids lockouts, then deals with the problem most Microsoft 365 guides skip: your website also sends email, and that second sender is what usually breaks authentication. If SPF is new to you, SPF Records and Subdomains: How to Stay Under the 10-Lookup Limit explains the lookup limit in more depth, and What Is a DKIM Selector and How Do You Find Yours? covers the DKIM naming. Everything below was checked against Microsoft’s own documentation, last updated in July and August 2026, and against live DNS on 6 October 2026.
Do it in this order: SPF, then DKIM, then DMARC
DMARC passes when SPF or DKIM passes and the domain that passed lines up with the domain in the visible From address. If you publish a strict DMARC policy before the other two are right, you tell the world to reject your own mail. Microsoft says the same: set up SPF and DKIM for every domain and subdomain you send from, then add DMARC. Start DMARC in monitoring mode and tighten it later.
Step 1: the SPF record
There is no SPF setting inside Microsoft 365. You create one TXT record at your registrar or DNS host, on the root of the domain (host name @). If Microsoft 365 is the only thing that sends mail for your domain, Microsoft’s documented value is:
v=spf1 include:spf.protection.outlook.com -all
Three details trip people up:
- One SPF record per domain. Two TXT records that both start with
v=spf1make SPF return a permanent error. If your registrar pre-filled one, edit it instead of adding a second. - Syntax typos fail silently. Microsoft lists three mistakes it sees often: a trailing dot after the domain, an equals sign instead of a colon after
include, and a space after the colon. - Hard fail or soft fail. Microsoft recommends
-allfor Microsoft 365 domains, because DMARC and DKIM sit behind it. It also notes that with~allthe DMARC policy is effectively ignored for SPF failures when a message carries no DKIM signature. If you are still discovering your senders,~allis a reasonable temporary choice, but plan to move to-all.
Domains you own but never send from deserve a record too. The value v=spf1 -all says nobody may send mail as that domain.
Step 2: where your website breaks it
Here is the situation that causes most “my mail is going to spam” tickets for site owners. Your mailboxes run on Microsoft 365. Your contact form, WooCommerce order emails and password resets are sent by WordPress, usually from the web server, using an address at your domain. Those messages do not come from Microsoft’s servers, so the Microsoft include does not cover them. Unless something else vouches for them, they fail SPF, they carry no DKIM signature from your domain, and DMARC fails once you enforce it.
You have two clean fixes. Pick one.
- Send site mail through a proper mail service. Use an SMTP plugin pointed at a transactional provider, add that provider’s
include:to your SPF record, and turn on its DKIM signing for your domain. - Give the website its own subdomain, for example
shop.yourdomain.com, with its own SPF record. Microsoft recommends this for any service you do not directly control, because a problem with that sender then does not hurt the reputation of your main domain. Each subdomain has its own set of 10 lookups, and each one needs its own SPF record, because the root record does not cover subdomains.
The lookup budget, measured
SPF allows ten DNS lookups in total. Every include: costs one lookup plus whatever sits inside it. On 6 October 2026 I resolved these records and counted what each include costs:
| Include | Lookups it costs |
|---|---|
| spf.protection.outlook.com (Microsoft 365) | 1 |
| _spf.google.com (Google Workspace) | 1 |
| servers.mcsv.net (Mailchimp) | 1 |
| amazonses.com (Amazon SES) | 1 |
| sendgrid.net (SendGrid) | 2 |
| _spf.mail.hostinger.com (Hostinger mail, which also runs the mailboxes for this site) | 3 |
| mailgun.org (Mailgun) | 5 |
Microsoft’s own record is flat, meaning it lists IP ranges directly, which is why it costs only one. So Microsoft 365 plus Mailchimp plus SendGrid plus a Hostinger-hosted site adds up to 1 + 1 + 2 + 3 = 7 lookups, with three to spare. Add Mailgun on top and you are at 12, which fails. These numbers change when providers edit their records, so count yours again before you rely on mine. Microsoft also warns against flattening its own include into raw IP addresses, because its sending addresses change often.
Step 3: DKIM, two CNAME records
DKIM signing is off for a custom domain until you switch it on. Microsoft generates two key pairs and uses two selectors named selector1 and selector2. You publish two CNAME records, not TXT records, that point to Microsoft’s copies of the public keys:
Host: selector1._domainkey
Points to: selector1-yourdomain-com._domainkey.yourtenant.n-v1.dkim.mail.microsoft
Host: selector2._domainkey
Points to: selector2-yourdomain-com._domainkey.yourtenant.n-v1.dkim.mail.microsoft
Do not copy the targets from this page. The part after the first dot, including a one-letter code before -v1, is specific to your tenant, and Microsoft’s documentation says the older onmicrosoft.com format and the newer one cannot be mixed for the same selector. Get your exact values from the Defender portal (Email & collaboration, Policies & rules, Threat policies, Email authentication settings, DKIM tab), or run this in Exchange Online PowerShell:
Get-DkimSigningConfig -Identity yourdomain.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
Create both CNAME records at your DNS host, wait until they resolve, then switch signing on for the domain in the same DKIM page. If the toggle complains, Microsoft has simply not detected the records yet, and the usual cause is propagation time.
One setting is worth a look: the key size. Microsoft’s New-DkimSigningConfig documentation lists 1024 bits as the default and 2048 as the option. You can move to 2048 with Rotate-DkimSigningConfig -Identity yourdomain.com -KeySize 2048. Microsoft notes the new size applies to the next active selector first, and the other selector follows only on the second rotation, so do not expect both to change at once.
Step 4: a DMARC record you can tighten later
DMARC is one TXT record at host _dmarc. Start in monitoring mode:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
The rua address receives a daily summary from the mailbox providers that check your mail, listing which servers sent as your domain and whether they passed. Microsoft recommends a shared mailbox or group for this, not a personal inbox, because the reports are XML attachments and arrive in volume. Read them for a few weeks. Any legitimate sender that shows up failing, such as your contact form, is something to fix with the options in step 2.
When the reports are clean, Microsoft’s rollout is p=none, then p=quarantine, then p=reject, and you can use pct= to apply a policy to a growing share of failing mail while you watch (10, 25, 50, 75, then 100). Two facts worth knowing before you enforce:
- A DMARC record on the root domain also covers every subdomain that has no DMARC record of its own, including ones that do not exist. SPF and DKIM do not work that way.
- Once a domain is on
p=quarantineorp=reject, Microsoft routes outbound mail that fails DMARC through its high-risk delivery pool, with no override. That is a good reason to find your failing senders first.
Check that it worked
Send a message from the mailbox and from the website to a Gmail address you control. Open each one, choose Show original, and read the summary at the top. You want SPF, DKIM and DMARC all marked PASS for both. If the mailbox passes and the website mail does not, you are back at step 2. In the raw headers, look at smtp.mailfrom and header.d in the Authentication-Results line. For DMARC to pass, at least one of them has to share your From domain.
A message can pass SPF and still fail DMARC. If the envelope sender belongs to a mail service’s own domain and the DKIM signature also uses the service’s domain, both checks pass on their own terms, but neither lines up with your From address. The fix is custom DKIM at that service, so it signs with your domain.
The short checklist
- One SPF record on the root domain, ending in
-allonce you know all your senders. - Every extra sender counted against the 10-lookup limit, or moved to its own subdomain.
- Two DKIM CNAME records copied from your own Defender portal, with signing enabled.
- A DMARC record starting at
p=none, with reports going to a shared mailbox. - A test message from the website, not only from the mailbox.
Checked for accuracy on 6 October 2026 against Microsoft Learn’s SPF, DKIM and DMARC articles for Microsoft 365 and live DNS lookups.

Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.