SPF, DKIM and DMARC for Microsoft 365: The Setup Order, the Mistakes That Break Deliverability, and Defender for Office 365 Plan 1 vs Plan 2

Microsoft's email authentication overview describes the three standards as interdependent and says plainly that anything less than all of them results in substandard protection. Each closes a gap the previous one leaves.

SPF lists the servers allowed to send for your domain, but it validates only the MAIL FROM (envelope) domain, not the From address a person sees, and it breaks whenever a message is forwarded by another server. DKIM signs the message with a key published under your domain; the signature survives forwarding. DMARC then does what neither does alone: it requires the domain in the From address to align with the domain that passed SPF or the domain that signed with DKIM, tells receivers what to do when both fail, and asks them to send reports.

That dependency sets the order. DMARC can only be enforced once every legitimate source of mail from the domain passes at least one aligned check, and you only know that after SPF is correct, DKIM is signing and the reports have been read. Two starting facts from Microsoft's guides: outbound mail from your initial onmicrosoft.com domain is DKIM-signed automatically, but custom domains are not signed until you configure them; and even the onmicrosoft.com domain needs its own DMARC record, which you add in the Microsoft 365 admin center. Our DMARC, DKIM and SPF Email Authentication Implementation service runs the full sequence for every domain in the tenant.

For most tenants the SPF record is one line, v=spf1 include:spf.protection.outlook.com -all, with ip4: entries added only for on-premises servers that send as the domain. Microsoft recommends the hard-fail -all for Microsoft 365 domains and gives the reason: DMARC effectively ignores a soft-fail ~all result when the message also lacks a DKIM signature, so ~all leaves a hole until DKIM is done.

Two mistakes produce a permanent error rather than a warning.

• Multiple SPF records. Only one SPF TXT record is allowed per domain or subdomain. A second one, typically left behind by a previous email host or added for a marketing platform, makes receivers return permerror because they cannot decide which record to evaluate. Merge them.
• More than 10 DNS lookups. Every include: costs at least one lookup, and an include: that points to a record with three more inside costs four. IP addresses cost none. Past ten, the message fails SPF with a permanent error and is bounced. Microsoft's fixes are the ones we use: replace a vendor include: with its documented IP ranges where they are stable, and move services you do not control (bulk mail, ticketing, marketing) to subdomains, each with its own ten-lookup budget and its own reputation.

Three smaller ones: a trailing period after the domain, include= instead of include:, and a space after the colon each invalidate the record. Every defined domain and subdomain needs its own SPF record, undefined subdomains are handled by DMARC, and parked domains that never send should publish v=spf1 -all.

Enabling DKIM for a custom domain in Microsoft 365 means creating two CNAME records, selector1._domainkey and selector2._domainkey, that point at the public keys Microsoft hosts, then switching signing on in the Defender portal. Only one selector is active at a time; the second exists so keys can be rotated without a gap. Microsoft changed the CNAME target format for custom domains added from May 2025, and the two formats cannot coexist for the same selector, so do not copy values from an old runbook: read them from the portal or from Get-DkimSigningConfig in Exchange Online PowerShell.

The third-party mistake lives here. DKIM passes DMARC only if the domain that signed the message aligns with the From domain. A ticketing system or a mailing platform that signs with its own domain passes DKIM but does not pass DMARC for you; it must be configured to sign with your domain or a subdomain of it. Until that is done the service depends on SPF alignment alone, and SPF alignment is exactly what forwarding breaks. Microsoft's advice is to put such services on a subdomain in any case, to keep vendor problems away from your main domain's reputation.

The DMARC record sits at _dmarc.yourdomain and, in Microsoft's example form, reads v=DMARC1; p=reject; pct=100; rua=mailto:.... Microsoft recommends a gradual rollout: start at p=none and read the aggregate reports; move to p=quarantine, optionally stepping pct= through 10, 25, 50, 75 and 100; then move to p=reject. Two report facts shape the monitoring: Microsoft 365 sends aggregate reports only when the domain's MX record points directly to Microsoft 365, and it does not send forensic (ruf=) reports at all.

The common failure is p=none forever. The record satisfies a checklist, the reports land in a mailbox nobody reads, and the domain is no better protected than before. Treat p=none as a tuning state with an exit date. Our Managed DMARC and Email Deliverability Monitoring service exists to read the reports and move the policy.

Three more rules from the guide. A DMARC record covers every subdomain that lacks its own, including subdomains that do not exist, but each subdomain that sends still needs its own SPF and DKIM. Parked domains and an unused onmicrosoft.com domain should carry p=reject. And once your policy is p=quarantine or p=reject, outbound mail from the tenant that fails DMARC at the destination is routed through Microsoft's high-risk delivery pool, which is why the records must be right before the policy is tightened. On the inbound side, the anti-phishing policy's "Honor DMARC record policy" setting decides what happens to spoofed mail, and services that legitimately modify your inbound mail can be registered as trusted ARC sealers so they stop failing.

With authentication in place, filtering has something to work with. Microsoft describes a three-rung ladder.

Built-in protection for all cloud mailboxes ships with every subscription that includes Exchange Online: connection filtering, anti-malware, anti-spam with bulk handling, anti-phishing spoof intelligence, outbound spam control, quarantine, zero-hour auto purge and the Tenant Allow/Block List, with Standard and Strict preset policies you should turn on. Our Additional Spam and Phishing Protection service tunes this layer.

Defender for Office 365 Plan 1 adds prevention and detection: impersonation protection for users and domains, mailbox-intelligence impersonation checks, phishing thresholds, Safe Attachments for email and for SharePoint, OneDrive and Teams files, Safe Links, Real-time detections, priority-account tags, the email entity page and Teams-message protection. Microsoft lists it as included in Microsoft 365 E3 and Business Premium; the service plan reference confirms both.

Plan 2 adds investigation, response and automation: Threat Explorer in place of Real-time detections, Threat Trackers, Campaigns, Automated Investigation and Response, advanced hunting and incidents in Defender XDR, Attack simulation training and priority-account protection. It is included in Microsoft 365 E5.

Business Basic, Business Standard and Office 365 E1 sit on the built-in rung; the Defender for Office 365 (Plan 1) and Defender for Office 365 (Plan 2) add-ons are how they move up, and Microsoft offers a 90-day trial of Plan 2 where the subscription does not include it.

Do I need DMARC if I only use the onmicrosoft.com domain?

Yes. SPF and DKIM are pre-configured for it, but the DMARC record is not; add it in the Microsoft 365 admin center, and use p=reject if you never send from it.

Why does my SPF record fail with permerror?

Either there are two SPF records on the domain or the record needs more than 10 DNS lookups. Merge the records, replace stable vendor includes with IP ranges, and move third-party services to subdomains.

Should I use ~all or -all?

Microsoft recommends -all for Microsoft 365 domains, because DMARC is effectively ignored for ~all failures on messages that carry no DKIM signature.

My third-party sender passes DKIM; why does DMARC still fail?

It is signing with its own domain. Alignment needs the signing domain to match your From domain, so configure the service to sign with your domain or a subdomain of it.

Does Business Premium include Defender for Office 365?

Plan 1, as does Microsoft 365 E3. Plan 2 comes with Microsoft 365 E5 or as an add-on.

• Microsoft Learn: Email authentication in cloud organizations
• Microsoft Learn: Set up SPF to identify valid email sources for your custom cloud domains
• Microsoft Learn: Set up DKIM to sign mail from your cloud domain
• Microsoft Learn: Set up DMARC to validate the From address domain for cloud senders
• Microsoft Learn: Microsoft Defender for Office 365 overview
• Microsoft Learn: Built-in security features for all cloud mailboxes
• Microsoft Learn: Product names and service plan identifiers for licensing
• IT Partner: Microsoft Defender for Office 365 (Plan 1) and (Plan 2) subscription pages