Office 365 SPF, DKIM, and DMARC Setup

Office 365 email authentication setup

Office 365, now Microsoft 365, can send trusted mail from your custom domain only when SPF, DKIM, and DMARC are set up together.

The goal is not just to have three DNS records. The goal is for real outbound mail from Exchange Online, apps, support tools, billing systems, and marketing platforms to pass authentication with a domain aligned to the visible From address. Gmail, Outlook, Yahoo, and other mailbox providers use those results as trust signals, then combine them with reputation, complaints, engagement, blocklists, content, and local policy before deciding whether mail goes to inbox, spam, junk, or rejection.

Start by running a free InboxRadar domain check. It reads your live SPF, DKIM, DMARC, MX, and blocklist signals so you can see whether the issue is a missing record, a broken record, weak enforcement, or DNS drift.

• Confirm the custom domain is verified in Microsoft 365.
• List every service that sends mail using your domain, not only Exchange Online.
• Publish one SPF record that includes Microsoft 365 and every legitimate sender.
• Enable DKIM signing for the custom domain and publish the selector CNAMEs Microsoft gives you.
• Publish DMARC at monitoring first, review reports, then move toward enforcement.

Step 1: fix SPF for Office 365

SPF is the DNS TXT record that tells receivers which servers are allowed to send mail for your domain.

For a Microsoft 365 custom domain where Exchange Online is the only sender, Microsoft documents the common SPF value as v=spf1 include:spf.protection.outlook.com -all. Government, DoD, and 21Vianet tenants use different Microsoft include domains, so copy the value from Microsoft's official SPF setup page for your tenant. If your domain also sends from a website server, CRM, help desk, billing app, newsletter platform, or cold outreach tool, those sources must be added to the same SPF record. Do not publish a second v=spf1 record at the same DNS name.

The ending matters. ~all is a soft fail, meaning unlisted senders are probably not authorized. -all is a hard fail, meaning unlisted senders are not authorized. Microsoft recommends -all for Microsoft 365 domains when the sender list is complete and DKIM and DMARC are also configured. If you are still discovering senders, ~all can be a temporary audit posture, but it is not a substitute for a complete record.

Stay under the SPF lookup limit. RFC 7208 limits SPF evaluation to 10 DNS-querying mechanisms and modifiers, counted across the whole evaluation, including nested include, a, mx, ptr, exists, and redirect. Too many vendor includes can cause SPF permerror, which gives mailbox providers another reason to distrust the message.

• Keep exactly one SPF TXT record for each sending domain or subdomain.
• Use include:spf.protection.outlook.com for normal Exchange Online commercial tenants.
• Add other legitimate senders only from their official setup instructions.
• Remove old vendors when they stop sending for you.
• Never use +all, because it authorizes everyone.

Step 2: turn on DKIM for your custom domain

DKIM signs outbound messages so receivers can verify that a domain took responsibility for the mail and that signed parts were not changed in transit.

Microsoft 365 does not finish DKIM for a custom domain just because the domain is verified. You need to publish the two DKIM CNAME records shown in the Microsoft Defender portal or returned by Exchange Online PowerShell, then enable signing for that domain. The hostnames use selectors such as selector1._domainkey and selector2._domainkey, but the target values are tenant and domain specific. Use Microsoft's exact values, because Microsoft 365 manages the DKIM keys and rotation behind those CNAMEs.

After DNS propagates, send a fresh test message and inspect the headers. You want dkim=pass and a DKIM d= domain that aligns with the visible From domain. If the only passing signature is from an onmicrosoft.com domain or a vendor-owned domain while your From address uses your brand domain, DMARC may still fail.

DKIM is especially important because forwarding and security gateways can break SPF by changing the sending path. A DKIM signature can survive normal forwarding if the signed headers and body are not changed in a way that invalidates the signature.

• Open the Microsoft Defender DKIM page or run Get-DkimSigningConfig in Exchange Online PowerShell.
• Copy both selector CNAME records exactly as Microsoft provides them.
• Publish those CNAMEs at your DNS host for the custom domain.
• Enable DKIM signing for the custom domain after DNS resolves.
• Repeat this for each custom domain or sending subdomain that uses Microsoft 365.

Step 3: publish DMARC safely

DMARC ties SPF and DKIM to the visible From domain, then tells receivers what the domain owner wants done with failures.

A safe first record is v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com published as a TXT record at _dmarc.yourdomain.com. p=none is monitoring mode. It lets you collect aggregate reports without asking receivers to quarantine or reject mail. The rua address receives reports that show which IPs and services are sending as your domain and whether SPF, DKIM, and DMARC passed.

DMARC passes when SPF passes and aligns, or DKIM passes and aligns. SPF alignment compares the envelope sender domain with the visible From domain. DKIM alignment compares the DKIM d= signing domain with the visible From domain. This is why a message can show spf=pass and still show dmarc=fail if SPF passed for a vendor return-path domain that does not align with your From address.

Move from p=none to p=quarantine, then p=reject only after reports show every legitimate sender has aligned SPF or aligned DKIM. p=quarantine asks receivers to treat failures as suspicious, often by placing them in spam or junk. p=reject asks receivers to reject failing mail. Receivers still apply their own local policy, but a stricter DMARC policy gives them a clearer instruction.

DMARC was originally published as RFC 7489 and is now updated by RFC 9989, with aggregate and failure reporting split into RFC 9990 and RFC 9991. If a provider guide still cites RFC 7489, use the provider's current sender guidelines together with the current DMARC RFCs.

• Start with p=none and a monitored rua mailbox or reporting service.
• Review reports for Exchange Online, apps, support tools, billing systems, and marketing platforms.
• Fix each legitimate source until SPF or DKIM passes with alignment.
• Move to p=quarantine before p=reject unless the domain is unused.
• For unused domains, publish defensive SPF and DMARC records so legitimate mail should not originate from them.

Step 4: check MX, blocklists, and spam signals

SPF, DKIM, and DMARC prove sender identity, but they do not guarantee inbox placement.

Check MX records next. MX records tell the internet where inbound mail for your domain goes. In Microsoft 365, the correct inbound MX target is supplied in the admin center and commonly points under mail.protection.outlook.com. Broken MX does not always stop outbound mail, but it can break replies, verification loops, abuse contacts, and trust checks around the domain.

Then check blocklists and reputation. If a Microsoft 365 mailbox was compromised, a campaign hit stale addresses, or a sending IP or domain appears on a blocklist, Gmail and Outlook can route mail to spam even when authentication passes. Google's sender guidelines also call out PTR and forward DNS for sending servers, spam complaint rates, unwanted mail, and list quality. Microsoft's guidance treats SPF, DKIM, and DMARC as part of a broader authentication and filtering system, not the whole filter.

If headers show authentication passing but mail still lands in spam, the next likely causes are recipient complaints, low engagement, poor list quality, suspicious links, malware, sudden volume changes, shared IP reputation, or a blocklist listing. Fix the root cause before asking for delisting, or the listing may return.

• Confirm MX records match the provider that should receive mail for the domain.
• Check Authentication-Results headers for spf=, dkim=, dmarc=, and Microsoft compauth= results.
• Review Microsoft 365 sign-in and sending activity for compromised accounts.
• Check major blocklists when spam placement changes suddenly.
• For bulk or promotional mail, keep unsubscribe easy and stop mailing people who do not want the mail.

Office 365 setup checklist

Use this order when setting up a new domain or repairing an existing Office 365 domain.

• Verify the domain in Microsoft 365 and confirm the DNS host you actually control.
• Publish SPF once, with Microsoft 365 plus every other legitimate sender.
• Keep SPF below 10 DNS lookups and remove duplicate SPF records.
• Publish the DKIM selector CNAMEs Microsoft provides, then enable DKIM signing.
• Send a test and confirm DKIM signs with your custom domain or an aligned domain.
• Publish DMARC with p=none and rua reporting.
• Use reports and headers to fix SPF or DKIM alignment for every real sender.
• Move DMARC toward p=quarantine and p=reject after real mail passes.
• Check MX, blocklists, account compromise, complaints, and list quality if spam placement continues.

Use official sources for exact provider details: Microsoft SPF setup, Microsoft DKIM setup, Microsoft DMARC setup, Google sender guidelines, RFC 7208 for SPF, RFC 6376 for DKIM, RFC 7489 for original DMARC, and RFC 9989 for current DMARC.

For a quick live audit, run the InboxRadar scorecard. If authentication passes but delivery still looks weak, read the related spam placement guide.