DMARC Analyzer

TL;DR

• Microsoft 365 senders need three DNS records: SPF with include:spf.protection.outlook.com, DKIM as two CNAME records at selector1._domainkey and selector2._domainkey pointing at your tenant's <tenant>.onmicrosoft.com key infrastructure, and DMARC at _dmarc.<your-domain> starting at p=none.
• Google's Feb 2024 bulk-sender requirements apply to M365 senders too: SPF + DKIM alignment, DMARC at minimum p=none (bulk senders strongly encouraged at p=quarantine or stronger), RFC 8058 one-click List-Unsubscribe, and spam-complaint rate under 0.3% for any domain sending >5000 messages/day to gmail.com or yahoo.com. Yahoo signed jointly with Google.
• SPF record: v=spf1 include:spf.protection.outlook.com ~all during rollout, harden to -all in production. Add additional include: for every third-party sender (SendGrid, Mailchimp, on-premises Exchange) - stay under the 10-DNS-lookup limit.
• DKIM workflow: Microsoft 365 Defender portal > Email & Collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. Publish the two CNAMEs the portal displays for selector1 and selector2, wait 24-48h for DNS propagation, then enable signing for the custom domain (UI toggle or Set-DkimSigningConfig -Identity your-domain.com -Enabled $true via Exchange Online PowerShell).
• The #1 M365 failure mode: mail signed under <tenant>.onmicrosoft.com instead of your custom domain. Cause: DKIM was never enabled for the custom accepted domain after CNAME publication. Fix: publish CNAMEs, wait for propagation, then enable. DMARC fails until DKIM signs under the aligned visible-From: domain.
• DMARC rollout: v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com first. Ingest reports for 2-6 weeks to inventory every sender. Advance to p=quarantine only after every legitimate sender is aligned. Never skip from p=none to p=reject.
• Defender for Office 365 Trusted ARC Sealers (security.microsoft.com > Email & Collaboration > Policies & rules > Threat policies > Email authentication settings > ARC) lets Exchange Online trust ARC signatures from specific intermediaries (Proofpoint, Mimecast, Cisco IronPort) so DMARC survives forwarding through security gateways. Configure each intermediary explicitly.
• DMARC Analyzer ingests Microsoft's daily aggregate reports via includes/DmarcParser.php and surfaces the per-sender / per-IP / per-day breakdown that drives the alignment fix-up phase.

1. What this guide covers

This is the operator-implementation walkthrough for deploying SPF, DKIM, and DMARC on a domain whose mail is sent by Microsoft 365 / Exchange Online (formerly Office 365). It assumes you are the administrator of an M365 tenant and have access to:

• The Microsoft 365 Defender portal at security.microsoft.com - the modern location for the DKIM and ARC management UI. Used to display the CNAME records for each custom accepted domain and to enable DKIM signing once the CNAMEs resolve.
• Optional but recommended: the Exchange Online PowerShell module for scripted DKIM configuration via Set-DkimSigningConfig and related cmdlets (faster than the UI for bulk operations across many accepted domains).
• Your domain's DNS provider (Cloudflare, Route 53, GoDaddy, etc.) - used to publish the SPF, DKIM CNAMEs, and DMARC TXT records.
• A working email mailbox on the domain to receive DMARC aggregate reports (or a third-party report-ingestion service - DMARC Analyzer is one option).

The guide is structured as five sequential deployment steps (SPF → DKIM → DMARC at p=none → alignment fix-up → enforcement) that mirror the canonical DMARC rollout with Microsoft-365-specific UI paths, syntax, and gotchas.

What this guide does not cover:

• On-premises Exchange Server - a separate product with its own DKIM story (typically via an external signer like Exchange Transport Rules + a third-party plugin). The CNAME-based DKIM workflow documented here is specific to Exchange Online / M365.
• Hybrid Exchange setups where mail flow splits between on-premises and Exchange Online - the DKIM strategy depends on which side handles outbound; if Exchange Online is the outbound boundary the M365 setup below applies, otherwise the on-premises signer governs.
• Microsoft 365 Defender's other anti-phishing features (anti-spoof policy, impersonation protection, Safe Links / Safe Attachments) - all valuable but separate from DMARC.

2. Why DMARC matters now: the Feb 2024 bulk-sender requirements

In February 2024 Google (jointly with Yahoo) introduced sender requirements that apply to any domain sending more than 5000 messages per day to gmail.com or yahoo.com combined - regardless of which mailbox provider sends the mail. The Feb 2024 cutover is the single largest DMARC-adoption driver in the industry to date and the proximate reason most M365 administrators are revisiting email authentication in 2024-2025. Microsoft publishes its own sender-best-practices but has not (as of this writing) introduced its own bulk-sender enforcement scheme - the Google/Yahoo requirements remain the industry-wide forcing function.

The five Feb 2024 requirements:

1. SPF must be set up and pass for the sending domain (RFC 7208).
2. DKIM must be set up and pass (RFC 6376). The domain in the visible From: header must also align with either the SPF domain or the DKIM domain — that is what DMARC identifier alignment requires; aligning both is good practice.
3. DMARC TXT record published with at minimum p=none - and bulk senders are strongly encouraged to advance to p=quarantine or p=reject over time.
4. RFC 8058 one-click List-Unsubscribe (List-Unsubscribe-Post header + List-Unsubscribe with both a mailto: and an https: URL) on every commercial / marketing message.
5. Spam complaint rate < 0.3% as measured at the receiver (with anything >0.1% as a yellow flag). Microsoft's equivalent telemetry is the Microsoft 365 Defender Email entity view; Google's equivalent is Postmaster Tools.

Bulk senders that fail one or more requirements have their mail delivered to spam at Gmail and Yahoo, or rejected entirely at the SMTP boundary. The 5000-messages-per-day threshold catches every commercial mailing-list operator, most B2B SaaS senders, and any organisation running marketing automation against the consumer-mailbox segment - regardless of whether their mail flows through M365, Workspace, or a self-hosted MTA.

Even non-bulk senders below the 5000 threshold should publish DMARC for two reasons:

• Spoofing protection. Without DMARC, attackers can forge messages with your domain in the From: header from anywhere on the internet. Microsoft's own SPF / DKIM on your outbound mail does nothing to stop a different sender at a different IP from spoofing your domain at another receiver. DMARC at enforcement is what closes that gap.
• Threshold drift. The 5000/day cutoff is the threshold today; Google's stated direction is universal enforcement. Deploying DMARC at p=quarantine now means you are not exposed when the threshold drops.

3. Prerequisites

• Microsoft 365 Global Administrator role, or one of the more-scoped admin roles that grants access to the Defender portal's Email authentication settings page (Security Administrator, Exchange Administrator). Required to view the CNAME records for each accepted domain and to toggle DKIM signing on/off.
• DNS edit access for the primary accepted domain. You will publish three records minimum: SPF TXT at apex, two DKIM CNAMEs at selector1._domainkey and selector2._domainkey, and a DMARC TXT at _dmarc.
• The custom domain registered as an accepted domain in the M365 tenant. The Defender portal's DKIM page will display "Status: Not configured" and the two CNAMEs to publish for each accepted domain. Domains that are not registered accepted domains do not appear.
• A monitored mailbox on the domain (or a third-party DMARC report ingestion service such as DMARC Analyzer). Reports arrive as gzip-compressed XML attachments - a typical setup uses a dedicated address like dmarc-reports@your-domain.com.
• Inventory of every legitimate sender for the domain. M365 is the obvious source, but the list usually also includes a marketing platform (Mailchimp, Klaviyo, Customer.io), a transactional relay (SendGrid, Mailgun, Amazon SES, Postmark), a CRM (Salesforce, HubSpot, Dynamics 365), helpdesk software (Zendesk, Intercom), on-premises servers relaying via M365 Direct Send, and potentially shadow-IT senders only the reports will surface.

4. Step 1: Configure SPF with spf.protection.outlook.com

Publish a single SPF TXT record at the domain apex (the root of your zone). Microsoft 365 publishes its sender IPs at spf.protection.outlook.com - a nested include that resolves to the union of every Exchange-Online-side mail source (Exchange Online Protection outbound, M365 Direct Send, Microsoft 365 Group mail, etc.). Microsoft updates the underlying IPs without operator intervention.

Minimum record for an M365-only sender:

your-domain.com.   IN TXT  "v=spf1 include:spf.protection.outlook.com ~all"

Production record once SPF passes are clean (note the -all hard fail):

your-domain.com.   IN TXT  "v=spf1 include:spf.protection.outlook.com -all"

If you also send via third-party providers, add each provider's include: in the same record (RFC 7208 §3.2 mandates a single SPF record per domain - multiple records cause a permerror):

your-domain.com.   IN TXT  "v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:mailgun.org -all"

Watch the 10-DNS-lookup limit (RFC 7208 §4.6.4). Every include:, a:, mx:, exists:, and redirect= counts toward the limit, and nested includes count for their full expansion. spf.protection.outlook.com consumes more than one lookup; if you have multiple senders the limit fills quickly. The DMARC Analyzer Domain Security Checker reports the live lookup count against any SPF record.

Verify the record with dig +short txt your-domain.com after publication, or via the Domain Security Checker.

5. Step 2: Configure DKIM via the Defender portal (CNAME delegation)

M365 DKIM differs from Google Workspace DKIM in a fundamental way: the private key lives in Microsoft's tenant infrastructure, not on your DNS. Operators publish two CNAME records that delegate the DKIM public-key resolution to <tenant>.onmicrosoft.com. Microsoft then publishes (and rotates) the actual public-key TXT records on the tenant side, transparent to operators.

1. Sign in to security.microsoft.com (the Microsoft 365 Defender portal) as a Global Administrator or Security Administrator.
2. Navigate to Email & Collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. The DKIM tab lists every accepted domain in the tenant. The status column shows "Sign messages for this domain with DKIM signatures" as enabled or disabled per domain.
3. Select the custom domain row (NOT the default <tenant>.onmicrosoft.com row - that one is already enabled and signs automatically).
4. The detail flyout displays the two CNAME records you must publish at your DNS provider:

   Host: selector1._domainkey.your-domain.com
   Type: CNAME
   Value: selector1-your-domain-com._domainkey.<tenant>.onmicrosoft.com
   
   Host: selector2._domainkey.your-domain.com
   Type: CNAME
   Value: selector2-your-domain-com._domainkey.<tenant>.onmicrosoft.com

   Note the dashed-domain transformation: your-domain.com becomes your-domain-com in the target hostname. Copy the exact values the portal displays - do NOT type them by hand because the tenant identifier and the dashed-domain transformation vary by domain.
5. At your DNS provider, publish both CNAMEs. Two records, one each for selector1._domainkey and selector2._domainkey. Most DNS providers append your domain automatically; the final FQDNs are selector1._domainkey.<your-domain> and selector2._domainkey.<your-domain>.
6. Wait 24-48 hours for DNS propagation. The Defender portal's "Enable" toggle will refuse to activate signing until Microsoft can resolve both published CNAMEs.
7. Return to the Defender portal DKIM page and click the Enable toggle for the custom domain. Exchange Online begins DKIM-signing all outbound mail under your custom domain immediately.
8. Optional PowerShell alternative: from the Exchange Online PowerShell module, run:

   Connect-ExchangeOnline
   Set-DkimSigningConfig -Identity your-domain.com -Enabled $true
   Get-DkimSigningConfig -Identity your-domain.com

   Faster than the UI for bulk operations across many accepted domains; the Get-DkimSigningConfig verifies the final state.
9. Verify by sending a test message to a Gmail or Yahoo address you control, opening the message source, and confirming the Authentication-Results header shows dkim=pass header.d=your-domain.com (NOT header.d=<tenant>.onmicrosoft.com).

Key rotation: Microsoft rotates DKIM keys automatically approximately every 6 months by alternating between selector1 and selector2 - one selector is "active" and signs new mail, the other is staged. Operators do not need to do anything. This is the primary operational advantage of the CNAME delegation design over Google Workspace's TXT-publication model.

6. Step 3: Publish DMARC at p=none

With SPF + DKIM working, publish a DMARC TXT record at _dmarc.<your-domain>:

_dmarc.your-domain.com.   IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com; fo=1"

Tags explained:

• v=DMARC1 - protocol version, always first.
• p=none - the reporting-only phase. Receivers will NOT change disposition based on DMARC outcomes; instead they will send daily aggregate reports describing every authentication result.
• rua=mailto:dmarc-reports@... - destination for daily aggregate (RUA) reports.
• fo=1 - request a forensic (RUF) report on any DMARC failure (most major receivers including Microsoft do not send forensic reports - see DMARC aggregate reports deep dive - but publishing fo=1 is the operator signal).

Confirm the record is live with dig +short txt _dmarc.your-domain.com or via DMARC Analyzer's Domain Security Checker.

Reports begin arriving within 24-48 hours. Microsoft's reports arrive daily on a UTC schedule. Other major receivers (Google, Yahoo, Comcast) send on similar cadences. Forward the rua= mailbox into DMARC Analyzer (via IMAP, Microsoft Graph, or manual upload through the dashboard) for parsing.

7. Step 4: Inventory legitimate senders and fix alignment

Read aggregate reports for 2-6 weeks. For each unique sending IP / sending domain combination, determine:

• Is this a legitimate sender? M365 itself is obvious; the marketing platform you set up two years ago may not be.
• Is the sender aligned? Either SPF must pass AND the envelope MAIL FROM domain match your visible From: header (organisational-domain match for relaxed alignment), OR DKIM must pass AND the d= in the signature match your visible From: header.
• If not aligned, what is the gap? Two M365-specific patterns dominate the alignment-failure surface: the onmicrosoft.com pattern (DKIM never enabled for the custom accepted domain - mail signs under tenant.onmicrosoft.com instead of your custom domain) and the SaaS-sender pattern (third-party platform uses its own bounce domain). Both have well-known fixes.

The #1 alignment failure for M365 senders is the onmicrosoft.com pattern: outbound mail from your custom domain is signed with the tenant's default <tenant>.onmicrosoft.com DKIM key (which is enabled automatically) but NOT with the custom domain's CNAME-delegated key (which was never enabled even though the CNAMEs were published). DMARC alignment fails because d=<tenant>.onmicrosoft.com does not match the visible From: user@your-domain.com. Fix: confirm both CNAMEs resolve via dig +short cname selector1._domainkey.your-domain.com then enable signing for the custom domain via the Defender portal toggle or Set-DkimSigningConfig -Identity your-domain.com -Enabled $true.

The #2 alignment failure for M365 senders is the SaaS-sender pattern: a third-party service (SendGrid, Mailgun, Customer.io, Mailchimp) sends on your behalf with the From: header set to marketing@your-domain.com but the envelope MAIL FROM domain pointing at the SaaS provider's bounce domain. SPF evaluates the bounce domain (passes) but doesn't align with your visible From: - DMARC fails. Fix: enable DKIM signing with d=your-domain.com in each SaaS provider's settings, typically via a CNAME-delegated subdomain selector like em1234._domainkey.your-domain.com CNAME em1234.sendgrid.net.

Continue iterating until every legitimate sender shows in reports as DMARC-pass. Note that some senders may take a full week to surface (cron-driven monthly billing emails, one-off campaign sends).

8. Step 5: Advance from p=quarantine to p=reject (with Trusted ARC Sealers)

Once every legitimate sender is aligned, advance the DMARC record to p=quarantine:

_dmarc.your-domain.com.   IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@your-domain.com; fo=1"

Receivers begin delivering DMARC-failing mail to spam (or the equivalent quarantine folder at Microsoft, the Junk Email folder at Outlook.com / Hotmail). Continue monitoring reports for unexpected failures. A common pattern: a monthly cron job sends from an unaligned legacy script the operator forgot about - the first month at p=quarantine surfaces it loudly.

After 1-3 months at p=quarantine without unexpected failures, advance to p=reject:

_dmarc.your-domain.com.   IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@your-domain.com; fo=1"

DMARC-failing mail is now bounced at the SMTP boundary. Spoofing of your domain at DMARC-honouring receivers is no longer possible. You have completed the rollout.

Never skip from p=none to p=reject. The p=quarantine intermediate phase exists specifically so failed mail goes to spam (recoverable) rather than bouncing (unrecoverable). The single most common self-inflicted email outage in DMARC rollouts is skipping this phase. See the DMARC policy rollout deep dive for the full rationale.

Trusted ARC Sealers - the M365-specific feature

M365 tenants using a security gateway (Proofpoint, Mimecast, Cisco IronPort) for inbound filtering have a unique problem: legitimate forwarded mail can fail DMARC at the Exchange Online boundary because the gateway modifies headers, breaking the original DKIM signature. Without intervention, rolling out p=reject on YOUR OWN domain may cause OTHER senders' aligned mail (forwarded through your gateway) to be rejected by your Exchange Online tenant.

Defender for Office 365 Trusted ARC Sealers (configured via the Defender portal Email authentication settings > ARC tab) tells Exchange Online to trust ARC signatures from specific named intermediaries when re-evaluating DMARC. The intermediary captures the original SPF/DKIM verdict in an ARC seal (RFC 8617); Exchange Online verifies the seal, consults the seal's chain cv= state, and re-applies the original DMARC verdict if the chain is intact. Configure each trusted intermediary by its DKIM signing-domain (the d= in the ARC-Message-Signature header):

# PowerShell example
Set-ArcConfig -Identity 'Default' -ArcTrustedSealers @{add='proofpoint.com','mimecast.com'}

Available to Defender for Office 365 Plan 1/2 tenants. See ARC explained for the protocol-level deep dive on how ARC preserves auth results across hops.

For granular ramping, use the pct= tag: p=quarantine; pct=5 applies the quarantine disposition to 5% of failing mail, leaving 95% at p=none. RFC 7489 §6.3 defines the semantics; note that the dmarcbis draft deprecates pct= so this is a transitional feature.

9. Microsoft 365-specific gotchas

• The default <tenant>.onmicrosoft.com domain. The tenant's initial Microsoft-provided domain is DKIM-signed automatically from day one - this is why M365 mail "appears to have DKIM" even when no operator configuration was done. The gotcha: that signature is under <tenant>.onmicrosoft.com, NOT your custom domain. DMARC for your custom domain still fails until you publish CNAMEs and enable DKIM for the custom accepted domain.
• Direct Send and M365 SMTP relay. On-premises servers and devices (copiers, line-of-business apps) that relay mail through M365 Direct Send must also be covered by your SPF record AND by an appropriate DKIM signing configuration. Mail relayed via the M365 SMTP relay connector inherits the M365 DKIM signature if the custom domain has DKIM enabled; mail sent via Direct Send may not - confirm by inspecting the Authentication-Results header on a test message.
• Shared mailboxes and group mail. Mail sent from a shared mailbox or Microsoft 365 Group inherits the tenant's DKIM configuration like any normal user message. No special handling needed.
• Hybrid Exchange with mail flow through on-premises. If your mail-flow connector routes outbound mail through an on-premises Exchange server (centralised mail flow), Exchange Online does NOT sign with DKIM - the on-premises path is the outbound boundary. In that topology you need a separate DKIM signer on-premises (third-party plugin or Exchange Transport Rule with an external signer), and the M365 CNAME-based DKIM is not in play.
• Exchange Online Protection anti-spoof policy. The Defender portal's anti-spoof settings are SEPARATE from DKIM and DMARC. Anti-spoof catches spoofed senders that DMARC misses (e.g. domains without DMARC published). Both layers should be configured; one is not a substitute for the other.
• The selector1/selector2 rotation is not visible to operators. Microsoft alternates which selector is "active" approximately every 6 months without notification. If you inspect a DKIM signature on outbound M365 mail you may see s=selector1 one month and s=selector2 the next - this is normal and intentional. Do NOT delete one of the CNAMEs.

10. Common Microsoft 365 + DMARC mistakes

1. Publishing CNAMEs but never enabling DKIM in the Defender portal. The Defender portal "DKIM" tab shows "Status: Not configured" even after both CNAMEs are live - the operator must explicitly click Enable (or run Set-DkimSigningConfig -Enabled $true). The mail signs under onmicrosoft.com until this step is completed. The single most common M365 DMARC failure mode.
2. Publishing only one of the two CNAMEs. Both selector1 and selector2 must resolve before the Defender portal will let you enable signing. The portal's pre-flight check rejects activation if either CNAME is missing.
3. Publishing the DKIM record as a TXT instead of a CNAME. M365 DKIM uses CNAME delegation (unlike Google Workspace which publishes the public key as a TXT record). The CNAME target points at Microsoft's tenant infrastructure. Publishing a TXT record at selector1._domainkey will break the CNAME chain.
4. Forgetting the dashed-domain transformation. Microsoft transforms your-domain.com into your-domain-com in the CNAME target. Manually constructing the CNAME target without copying it from the Defender portal usually fails because the operator forgets to swap dots for dashes. Always copy the exact value the portal displays.
5. Forgetting to advance past p=none. The reporting-only phase does NOT stop spoofing. Advance to enforcement after 2-6 weeks of clean reports.
6. Two SPF records on the same domain. RFC 7208 §3.2 mandates a single SPF record. Merge multiple records into one with concatenated include: directives.
7. SPF over 10 DNS lookups. spf.protection.outlook.com plus several third-party include: directives commonly blow the limit. Use Domain Security Checker to count lookups and flatten or remove unused providers.
8. Skipping SaaS-sender alignment. The marketing platform that sends from noreply@your-domain.com without DKIM-signing under your domain will fail DMARC even after M365 is clean. Configure CNAME-delegated DKIM in every SaaS provider's settings.
9. Publishing DMARC at p=reject without alignment fix-up. The fastest path to a self-inflicted email outage. Always ingest reports at p=none for 2-6 weeks first.
10. Treating DMARC as one-time work. New SaaS deployments, partner integrations, and acquired domains constantly surface new senders. Indefinite monitoring is the ongoing cost of DMARC enforcement.

11. Troubleshooting

• "Status: Not configured" in the Defender portal even after CNAME publication. Microsoft hasn't finished resolving both CNAMEs yet. DNS propagation can take 24-48 hours. Verify independently with dig +short cname selector1._domainkey.your-domain.com and dig +short cname selector2._domainkey.your-domain.com; both must return the Microsoft tenant targets. If they do but the portal still shows "Not configured", wait an additional 24 hours (Microsoft's portal cache lags published DNS by several hours) and retry.
• "My M365 mail goes to spam at Gmail despite DKIM pass". DKIM pass does not guarantee inbox delivery - Gmail's content-based spam filter operates downstream. Check Google Postmaster Tools for the reputation signal and spam-complaint rate. Anything >0.1% in Postmaster Tools is a warning; >0.3% triggers spam-folder delivery regardless of DMARC.
• "DMARC reports show DKIM header.d=onmicrosoft.com, not my custom domain". DKIM was never enabled for the custom accepted domain. The tenant's default onmicrosoft.com key is signing instead. Enable DKIM for the custom domain via the Defender portal toggle or Set-DkimSigningConfig -Identity your-domain.com -Enabled $true. This is the #1 M365 DMARC failure mode.
• "DMARC reports show DKIM pass + SPF pass but DMARC fail". An alignment failure. The SPF-passing domain or DKIM-signing domain does not match the visible From: header. See DMARC alignment explained for the deep dive - the SaaS-sender CNAME delegation pattern is the canonical fix.
• "My SPF record is failing with permerror". Almost always the 10-DNS-lookup limit. Run Domain Security Checker to see the live count.
• "Forwarded mail through our security gateway fails DMARC at the Exchange Online boundary". Configure Defender for Office 365 Trusted ARC Sealers for the gateway (Proofpoint / Mimecast / Cisco IronPort). See ARC explained for the protocol-level background.
• "How do I see my outbound DKIM signature in M365?" Send a test message to a Gmail or Yahoo address you control. Open the message source. The Authentication-Results header shows dkim=pass header.d=your-domain.com when signing is working correctly. If you see header.d=<tenant>.onmicrosoft.com instead, DKIM was never enabled for the custom domain - see the first troubleshooting entry.

12. Frequently asked questions

How do I set up DMARC for Microsoft 365?

Five steps. Publish SPF at the domain apex with include:spf.protection.outlook.com. Publish two CNAME records at selector1._domainkey and selector2._domainkey pointing at the Defender-portal-displayed tenant targets, wait for DNS propagation, and click Enable in the Defender portal (or run Set-DkimSigningConfig -Identity your-domain.com -Enabled $true). Publish DMARC at _dmarc starting at p=none with a rua= mailbox. Ingest reports for 2-6 weeks to align every legitimate sender. Advance through p=quarantine to p=reject.

What is the Microsoft 365 SPF include?

include:spf.protection.outlook.com. Minimum record: v=spf1 include:spf.protection.outlook.com ~all; production: v=spf1 include:spf.protection.outlook.com -all. Stay under the 10-DNS-lookup limit when adding third-party senders.

What DKIM selectors does Microsoft 365 use?

selector1 and selector2, both published as CNAMEs (not TXT) that delegate to <tenant>.onmicrosoft.com. Microsoft rotates keys automatically by alternating between the two selectors every 6 months.

Why is my Microsoft 365 mail signed under onmicrosoft.com instead of my custom domain?

DKIM was never enabled for the custom accepted domain. The tenant's default onmicrosoft.com key is signing instead. Enable DKIM via the Defender portal toggle or Set-DkimSigningConfig -Identity your-domain.com -Enabled $true. The #1 M365 DMARC failure mode.

What is the Defender for Office 365 Trusted ARC Sealers feature?

A Defender for Office 365 feature that lets Exchange Online accept ARC signatures from named trusted intermediaries (Proofpoint, Mimecast, Cisco IronPort) when re-evaluating DMARC on inbound mail. Makes p=reject coexist with security-gateway-forwarded mail. Configured at security.microsoft.com > Email authentication settings > ARC.

Why is my DMARC failing despite SPF and DKIM passing on Microsoft 365?

Alignment failure. Either the onmicrosoft.com pattern (DKIM never enabled for custom domain - see dedicated FAQ entry) or the SaaS-sender pattern (third-party platform uses its own bounce domain). Fix by enabling DKIM with d=your-domain.com in each path, most commonly via CNAME-delegated subdomain selectors for SaaS providers.

Do I need DMARC if I only use Microsoft 365?

Yes. Microsoft's outbound authentication does not stop attackers from spoofing your domain at other receivers - DMARC at enforcement is what closes that gap. The Feb 2024 Google/Yahoo bulk-sender requirements additionally demand DMARC for any high-volume M365 tenant.

Where do I see DMARC reports for Microsoft 365 mail?

Receivers (Microsoft, Google, Yahoo, and others) send daily aggregate reports to the rua= mailbox in your DMARC record. DMARC Analyzer ingests these via includes/DmarcParser.php and surfaces the per-sender breakdown. The Microsoft 365 Defender portal Email entity view provides per-message delivery telemetry for your own mail flow but is not a substitute for parsing DMARC aggregate reports.

13. Related guides

• Email authentication explained - the cluster-intro pillar covering the full ecosystem (SPF + DKIM + DMARC + BIMI + MTA-STS + TLS-RPT + CAA + ARC).
• DMARC explained - the DMARC primer for the broader ecosystem.
• DMARC reporting pipeline - RUA / RUF ingestion, parsing, and delivery (the M365-TENANT-PIPELINE-CONSUMER companion to this M365 deployment guide) - the M365-TENANT-PIPELINE-CONSUMER companion documenting the END-TO-END infrastructure path that puts the aggregate-report XML stream in front of the M365 tenant authoring the _dmarc.<domain> rua= tag THIS page documents. The M365 deployment workflow on this page produces the rua=mailto:dmarc-reports@<tenant>.com publication step in Phase-1, but THAT step only initiates the upstream half of the pipeline; the reporting-pipeline reference documents the FULL FIVE-STAGE flow from receiver-side report generation through publisher-side mailbox delivery: (1) receiver-side report generation cadence (Microsoft 365's own EOP RUA emission is hourly rolling-window, distinct from Gmail / Yahoo / Mail.ru's 24-hour UTC-aligned batch cadence, which means an M365 tenant sending mail to a mixed-receiver audience sees the first M365-from-M365 RUA report within an hour but the first Gmail-from-M365 RUA report not until the following day); (2) publisher-side rua= addressing rules (external-domain mailboxes — common for M365 tenants pointing rua= at a third-party DMARC SaaS on a non-tenant domain — require the _report._dmarc.<source-domain>.<mailbox-domain> delegation per RFC 7489 §7.1, a publication step the M365 Defender portal does NOT configure automatically); (3) mailbox-side ingestion via IMAP or Microsoft Graph (the latter the canonical M365-native path, documented in imap_fetch.php / GraphFetcher with the OAuth flow against the tenant's Azure AD app registration); (4) parser-side XML decode producing per-source_ip policy_evaluated.dkim/spf verdict rows; (5) delivery to the DMARC Analyzer dashboard the M365 tenant consumes for the Phase-2 advancement gate (the ~99% legitimate- mail policy_evaluated=pass criterion the canonical Microsoft-recommended ramp on this page references). Read THIS M365 deployment guide WITH the reporting- pipeline reference when an M365 operator reports "I published rua= two weeks ago but the dashboard shows zero reports" — the diagnostic flow starts at the M365-tenant-specific rua= publication step and walks the pipeline reference's stages in order until the break is located. Where THIS page documents the M365 DEPLOYMENT WORKFLOW that establishes the rua= publication, the reporting- pipeline spoke documents the FULL infrastructure path that turns that publication into the empirical evidence the M365 tenant's Phase-2 / Phase-4 advancement gates require.
• DMARC policy modes - p=none vs p=quarantine vs p=reject (the M365-TENANT-POLICY-MODE-CHOICE-INPUT companion to this M365 deployment guide) - the M365-TENANT-POLICY-MODE-CHOICE-INPUT companion documenting the head-to-head comparison of the three DMARC enforcement values p=none / p=quarantine / p=reject that the M365 deployment workflow on this page ramps through. Where THIS page documents the M365 deployment workflow end-to-end (the Exchange Online Protection (EOP) connector topology, the spf.protection.outlook.com include, the dual-selector CNAME-based DKIM signing, the _dmarc.<domain> TXT publication, the M365 Defender portal verification workflow, the Trusted ARC Sealers configuration, the Centralized Mail Transport / Direct-Delivery / Edge Transport hybrid topologies, the onmicrosoft.com default-signing trap), the policy-modes spoke documents the THREE policy-mode values themselves and the EOP-side enforcement contract each implies — the per-mode receiver behaviour Exchange Online Protection executes on inbound mail from non-aligned senders to the tenant's protected domains (p=none → EOP IGNORES the DMARC verdict and uses SCL + connection-filter heuristics alone, p=quarantine → EOP delivers to Junk Email folder with SCL=5, p=reject → EOP rejects at the connector with SMTP 550 5.7.1 / 5.7.26 codes). Critical precondition reference: every M365 deployment milestone in this guide is bounded by the policy-mode VALUE-CHOICE the operator publishes at the end of each deployment phase — the canonical Microsoft- recommended ramp is Phase-1 publish p=none to start RUA monitoring (Week 0), Phase-2 advance to p=quarantine; pct=10 after 4-week monitoring window proves ~99% legitimate-mail policy_evaluated=pass at EOP, Phase-3 ramp to p=quarantine; pct=100 after another 2-week window, Phase-4 advance to p=reject; pct=10 after sustained Phase-3 stability, Phase-5 terminal p=reject; pct=100 after the final ramp. Read the policy-modes spoke alongside this M365 deployment guide when authoring the _dmarc.<domain> TXT record's p= tag at each phase boundary - the spoke documents the per-mode EOP-side enforcement contract every phase change crosses.
• SPF explained - the protocol-level deep dive on Sender Policy Framework (RFC 7208). Covers the 10-lookup limit, mechanisms, qualifiers, and flattening.
• SPF 10 DNS lookup limit and SPF flattening - the dedicated deep dive M365 operators need most. Including spf.protection.outlook.com alone consumes 3 of the 10 budget slots before you add anything else; combine with a few SaaS senders (SendGrid, Mailchimp, HubSpot) and the budget burns through within minutes. Covers the per- provider include cost table, the flattening tradeoff, and the recommended remediation sequence.
• SPF for Microsoft 365 - the M365-specific SPF deep dive that complements this DMARC deployment guide. Covers the canonical v=spf1 include:spf.protection.outlook.com -all record, the onmicrosoft.com failure mode, the Centralized Mail Transport / Direct- Delivery / Edge Transport hybrid topologies, the third-party-sender catalogue with their canonical include: tokens, and the M365 Defender portal / Exchange Online PowerShell / message-trace verification playbook. Read alongside this guide when authoring the SPF record half of the M365 DMARC deployment.
• SPF for Google Workspace — the SIBLING-TENANT-WORKSPACE-SPF- AUTHORING-CROSS-REFERENCE companion to this M365 DMARC deployment guide. Where THIS page documents the M365-tenant DMARC deployment playbook (the canonical v=spf1 include:spf.protection.outlook.com -all baseline + DKIM-via-Exchange-Online CNAME delegation + DMARC record publication + EOP message-trace verification), the SPF- for-Google-Workspace spoke is the WORKSPACE-TENANT-SIBLING-DEPLOYMENT-CROSS- REFERENCE companion documenting the Workspace-equivalent SPF authoring discipline at four operationally-distinct cross-reference dimensions M365-tenant operators encounter in practice: (i) M365-to-Workspace migration scenarios where the apex domain is switching from spf.protection.outlook.com to _spf.google.com — the SPF-for-Workspace spoke documents the Workspace-tenant target-state SPF record + the dual-publication transition window pattern (publish both include:spf.protection.outlook.com AND include:_spf.google.com during the MX cutover) + the post-cutover cleanup discipline; (ii) cross- platform topologies where the organization runs M365 for primary mailboxes but Google Workspace for a department / acquired-subsidiary / brand- specific outbound flow — the SPF-for-Workspace spoke documents the per-domain-or-per-subdomain SPF publication discipline operators use to coordinate Workspace-tenant outbound against the M365-tenant apex policy (typically: per-subdomain workspace-subsidiary.example.com publishes the Workspace baseline while the apex example.com retains the M365 baseline + the per-subdomain delegated SPF survives the sp=-tag inherited DMARC policy); (iii) M365-tenant operators interoperating with Workspace- hosted partner organizations on shared domains via inbound-relay / outbound- relay / mail-forwarding-gateway configurations — the SPF-for- Workspace spoke documents the Workspace-egress IP attribution model the M365-tenant operator must reference when their aggregate-report stream surfaces source_ip rows belonging to Google-managed Workspace egress netblocks (recognizable via the _spf.google.com cascade catalogue); and (iv) M365- tenant operators evaluating Workspace as an alternative or supplementary mailbox platform for a future deployment decision — the SPF-for- Workspace spoke is the authoritative operator-empowerment reference for the Workspace SPF baseline + lookup-budget envelope + Google-Groups-mailing-list mediator effects + Gmail-recipient-side auto-forwarding density characteristics that determine whether the candidate mailbox-provider switch is operationally feasible for the M365-tenant organization's existing p=quarantine / p=reject DMARC posture. Read the SPF-for-Workspace spoke alongside this M365 DMARC deployment guide when the M365 organization is running cross-platform topologies, migrating between mailbox providers, or evaluating Workspace — the spoke is the STRUCTURALLY-PARALLEL-TO-M365-SPF- AUTHORING-DOCUMENT but at the Workspace- tenant cohort.
• SPF DNS-TXT-record byte syntax — the M365-TENANT-OUTBOUND-SPF-RECORD- AUTHORING-AT-EOP-INCLUDE-NESTING companion to this M365 DMARC deployment guide. Where THIS page documents the M365 DMARC deployment procedure end-to-end — the M365 Defender / Exchange Online / DKIM / RUA-redirect / Centralized-Mail- Transport / Direct-Delivery / Edge-Transport hybrid topologies — the SPF-DNS-syntax spoke is the BYTE-PRECISE RFC 7208 §3 GRAMMAR REFERENCE documenting the canonical SPF-record byte-syntax that the M365 tenant TYPES INTO the custom organizational-domain DNS zone-editor TXT-record field at the per-domain publication boundary. The M365-TENANT- AUTHORS-SPF-RECORD-AT-CUSTOM-DOMAIN cross- reference establishes FOUR structurally- distinct M365-specific byte-authoring dimensions whose correctness the tenant must verify before EOP-signed outbound messages produce spf=pass at receiver-side evaluation: (i) include:spf.protection.outlook.com literal-token byte-precise authoring — M365 tenants MUST publish this exact token byte-for-byte (case-insensitive but otherwise byte-exact); common typos (include: spf.protection.outlook.com with embedded space after the colon, include:spf.protection.outlook.COM with uppercase TLD which is valid but unconventional, include:spf- protection.outlook.com with hyphen instead of dot which is a completely different non-existent hostname) trigger receiver-side permerror or spf=fail verdicts despite EOP correctly signing the outbound message — the byte-syntax spoke documents the canonical RFC 7208 §5.2 include-mechanism byte-grammar that the M365 tenant must encode byte-correctly at zone-editor input time; (ii) per-tenant supplemental include-cascade byte-budget at RFC 7208 §4.6.4 10-DNS- lookup ceiling — M365 tenants commonly layer 3rd-party sender includes (SendGrid's include:sendgrid.net, Mailgun's include:mailgun.org, Mailchimp's include:servers.mcsv.net, HubSpot's include:_spf.hubspot.com) on top of the M365 base include which ALREADY consumes 3 of 10 budget slots — every supplemental include adds 1-3 more slots and the budget burns through within 2-3 third-party senders; the byte-syntax spoke documents the per-include cost accounting at byte-precise tokenization level so the tenant can measure each supplemental include's contribution BEFORE the flatten-vs-cascade-cleanup decision; (iii) onmicrosoft.com vs custom-domain SPF-publication-boundary byte-correctness — M365 tenants publishing the SPF record on the <tenant>.onmicrosoft.com mail-tenant alias INSTEAD OF on the custom organizational-domain produce alignment-failure even when the SPF record byte-syntax is correct (because DMARC alignment evaluates against the header-From domain, not the envelope-MAIL FROM); the byte-syntax spoke documents the per- organizational-domain SPF publication boundary as a byte-grammar concern — the tenant MUST type the TXT record bytes into the custom-domain zone-editor, not the onmicrosoft.com alias zone-editor; (iv) flatten-vs- cascade byte-decision at 255-byte single- string fragmentation boundary — M365 tenants near the 10-lookup ceiling must decide flatten-now (consolidate nested includes into a single SPF record of explicit ip4: / ip6: blocks) vs include- cascade-cleanup (audit the supplemental include cascade and remove unused 3rd- party sender includes); the flatten option crosses the RFC 1035 §3.3.14 255-byte per-string boundary nearly every time because the EOP IP range and the supplemental 3rd-party-sender IP ranges together exceed 255 bytes when expressed as ip4: blocks — the byte-syntax spoke documents the canonical RFC 7208 §3.3 multi-string concatenation rules so M365 tenants choosing the flatten option author the fragmentation byte-correctly at the per-string boundary without triggering DNS-resolver-truncation or per-resolver-handling divergence. Read the SPF-DNS-syntax spoke BEFORE the tenant publishes the SPF record on the custom organizational-domain — the byte- grammar reference is the canonical authoring prerequisite for every M365 tenant's per-organizational-domain SPF- record byte-literal input session.
• DKIM explained - the protocol-level deep dive on DomainKeys Identified Mail (RFC 6376). Covers selectors, canonicalization, key rotation, and CNAME delegation.
• DKIM cryptography basics — the PER-M365-TENANT-DKIM-CNAME- DELEGATION-CHAIN-RESOLVES-TO-MICROSOFT- MANAGED-RSA-PUBLIC-KEY-WHOSE-CRYPTOGRAPHIC- DISCIPLINE-IS-LOAD-BEARING-FOR-EVERY- OUTBOUND-EOP-SIGNED-MESSAGE companion to this M365 DMARC deployment guide. Where THIS page documents the per-M365-tenant DMARC-record publication discipline that depends on per-tenant DKIM-aligned-pass rate as the load-bearing cryptographic- verification input, the DKIM-cryptography- basics spoke is the per-publisher per- selector cryptographic-key-management operator-reference documenting the per- tenant RSA-key-pair generation, RFC 8301 RSA-2048-bit key-strength floor, RFC 6376 §3.6.1 per-selector public-key TXT-record publication grammar, and per-selector rotation-cadence operator-discipline at FOUR per-tenant DKIM-cryptography-vs-M365- DMARC coupling dimensions: (i) per- M365-tenant Microsoft-managed-vs-customer- managed RSA-key-pair ownership boundary as cryptographic-trust-anchor administrative contract — Microsoft generates and rotates the per-M365-tenant per-selector RSA-key-pair at the onmicrosoft.com leaf of the per-tenant CNAME-delegation chain; the per-tenant operator's responsibility is to publish the per- selector CNAME-delegation record pointing at the Microsoft-managed leaf and to commit to the per-tenant DMARC-policy- mode-progression this page documents only once the per-tenant DKIM-key-strength floor is met; (ii) per-M365-tenant per-selector dual-selector overlap-window rotation cadence as per-tenant cryptographic- operator-discipline — the selector1._domainkey / selector2._domainkey CNAME- delegation pair this page documents is the per-tenant manifestation of the per- selector overlap-window rotation pattern the DKIM-cryptography-basics spoke documents (per-publisher dual-selector publication discipline allowing per-key rotation without per-message verification- failure during the rotation-window); (iii) per-M365-tenant DKIM-aligned-pass- rate as load-bearing upstream input for per-tenant DMARC-policy-mode-progression commitment — the per-tenant commitment to per-tenant p=quarantine / p=reject DMARC-policy-mode this page documents depends on per-tenant per-receiver per-day DKIM-aligned-pass-rate floor, which in turn depends on per-tenant per-selector cryptographic-trust-anchor publication discipline the DKIM-cryptography-basics spoke documents (per-selector RSA-2048- bit-or-stronger key-strength, per-selector timely rotation, per-selector public-key TXT-record byte-grammar compliance); (iv) per-M365-tenant cryptographic- trust-anchor publication-discipline as per-tenant DMARC-aggregate-report DKIM- evaluation-result decode reference — the per-tenant per-receiver-organisation DMARC-aggregate-report per-row dkim=pass / dkim=fail / dkim=permerror verdict decode depends on the per-tenant per-selector cryptographic-trust-anchor publication discipline this DKIM-cryptography-basics spoke documents (per-selector public-key absence, per-selector key-too-small, per- selector key-revoked, per-selector TXT- record syntax-defect).
• DKIM DNS-TXT-record byte syntax — the M365-EOP-CNAME-DELEGATION-CHAIN- RESOLVES-TO-MICROSOFT-MAINTAINED-DKIM-TXT- RECORD-BYTE-LAYOUT-AT-ONMICROSOFT-COM-LEAF companion to this M365 DMARC deployment guide. Where THIS page documents the M365-tenant-specific DMARC publication path and the per-domain Defender DKIM signing enablement procedure (Set-DkimSigningConfig -Identity yourcompany.com -Enabled $true), the DKIM-DNS-syntax spoke is the UPSTREAM BYTE-GRAMMAR REFERENCE documenting the RFC 6376 §3.6.1 per-tag byte-layout that the M365-EOP-published CNAME chain's terminal Microsoft- maintained DKIM TXT record at selector1-<tenant-hash>._ domainkey.<initial-tenant>. onmicrosoft.com MUST conform to. The M365-EOP-CNAME-RESOLUTION-TO-DKIM- BYTE-LAYOUT cross-reference establishes FIVE M365-tenant-specific byte-grammar considerations: (i) EOP-published selector1-<hash> and selector2-<hash> terminal TXT records carry the Microsoft-managed 2048-bit RSA p=<base64-pubkey> payload whose RFC 6376 §3.6.1 byte- grammar compliance is opaque to the tenant — the tenant publishes only the CNAME pointers; Microsoft publishes the terminal byte-payload at the onmicrosoft.com zone leaf; (ii) tenant-side CNAME records selector1._domainkey.yourcompany. com CNAME selector1-<hash>._ domainkey.<tenant>.onmicrosoft. com must resolve through the recursive resolver to the terminal DKIM TXT record at the EOP leaf — a publisher-side typo in the CNAME target (most commonly truncating the <hash> suffix from the Defender portal) produces an NXDOMAIN at the terminal lookup and downstream signature-verification failure; (iii) byte-length overflow at the 512-byte UDP DNS response boundary — the 2048-bit RSA public-key payload Microsoft publishes is large enough that some recursive resolvers fail to gracefully fall back to TCP or EDNS0, producing truncated-response errors that the DKIM-DNS-syntax spoke documents as a canonical receiver-side verification- failure class; (iv) missing v=DKIM1 version sentinel in non-Microsoft selectors — tenants who attempt to add custom third-party-signer selectors (SendGrid, Mailgun, SES) alongside the EOP-managed selectors must publish a TXT record at the third-party selector that conforms to RFC 6376 §3.6.1; missing the v=DKIM1 sentinel causes receiver-side verifiers to reject the record AS NOT A DKIM KEY RECORD even when all other tags are well-formed; (v) Microsoft-managed key- rotation TXT-record byte-payload churn every ~6 months — the terminal DKIM TXT record's p= tag payload changes when Microsoft executes the automatic dual-selector rotation documented in the DKIM-key-rotation spoke; the DKIM-DNS-syntax spoke is the per-tag byte-grammar reference whose conformance Microsoft maintains across each rotation cycle. Pair this page (the M365-tenant DMARC deployment procedural reference) with the DKIM-DNS-syntax spoke (the per-tag RFC 6376 §3.6.1 byte-grammar compliance reference) when diagnosing a sudden EOP outbound-mail dkim=permerror spike that correlates with a Microsoft-side EOP rotation event — the spoke documents the canonical compliant byte-layout whose tenant-side CNAME-chain resolution-path-failure produces the receiver-side verification-failure class the M365 tenant observes in the RUA aggregate-report stream.
• DKIM best practices — the M365-DMARC-DEPLOYMENT-CONSUMES-DKIM- BEST-PRACTICES companion to this M365 DMARC deployment guide. Where THIS page documents the M365-tenant-specific DMARC deployment procedure (the _dmarc.<domain> TXT publication path, the p=none → p=quarantine → p=reject ramp, the onmicrosoft.com signing gotcha, the Defender portal workflow, Set-DkimSigningConfig, the EOP-CNAME-delegated selector model), the DKIM best-practices spoke is the SYNTHESIS LAYER documenting the 15-rule operator- discipline ruleset whose every rule the M365 tenant must SPECIALISE for the Microsoft 365 + Exchange Online + Defender for Office 365 platform constraints. The M365-DMARC-DEPLOYMENT-CONSUMES-DKIM-BEST- PRACTICES cross-reference establishes five M365-specific rule-specialisations the deployment workflow consumes: (i) "sign with d= matching the organisational domain" best-practices rule specialises to M365 as "enable Defender custom-domain DKIM via the security.microsoft.com → Email & collaboration → Policies & rules → Email authentication settings portal workflow OR Set-DkimSigningConfig -Identity yourcompany.com -Enabled $true — the onmicrosoft.com fallback signs with d=tenant.onmicrosoft.com which does NOT align with custom-domain From:" — the canonical onmicrosoft.com gotcha THIS page documents in detail; (ii) "use 2048-bit RSA keys at minimum" best-practices rule specialises to M365 as "Defender DKIM defaults to 2048-bit keys post-2024 platform update; legacy 1024-bit keys provisioned before the update must be rotated via Rotate-DkimSigningConfig"; (iii) "rotate selectors quarterly with 30-day publish-overlap window" best- practices rule specialises to M365 as "use the dual-selector EOP-CNAME pattern (selector1._domainkey + selector2._domainkey) where Rotate-DkimSigningConfig atomically swaps the active selector pair without DNS-record changes"; (iv) "sign all outbound messages, not just a sample" best-practices rule specialises to M365 as "Exchange Online Transport rules + Defender connectors must NOT bypass DKIM signing for any outbound path including direct-from-mailbox, hybrid- on-prem-via-Send-Connector, and 3P-app- relay routes"; (v) "sign the From: header in the h= tag" best-practices rule is enforced by the M365 platform's default signing template — the h= tag includes From / To / Subject / Date / MIME-Version / Content-Type at minimum with no operator override surface. Read THIS page for the M365-tenant-specific DMARC deployment procedure; read the DKIM best-practices spoke for the protocol- agnostic 15-rule operator-discipline synthesis whose rules every M365 tenant specialises during the deployment.
• DKIM for Microsoft 365 — the M365-specific DKIM deep dive that complements this DMARC deployment guide. The DMARC deployment guide on this page covers the _dmarc.<domain> TXT publication and the p=none → p=quarantine → p=reject ramp at the policy level; the DKIM-for-M365 spoke covers the upstream DKIM signing posture WITHOUT WHICH the DMARC enforcement cannot pass. Specifically: the Microsoft 365 Defender portal workflow (security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM), the two selector1._domainkey.<domain> and selector2._domainkey.<domain> CNAME records (NOT TXT — distinct from the Workspace TXT-publication model) pointing to selector1-<domain-dash-form>._domainkey.<tenant>.onmicrosoft.com and selector2-<domain-dash-form>._domainkey.<tenant>.onmicrosoft.com, the Microsoft-validated CNAME-existence gate (Microsoft refuses to let an admin click Enable until both CNAMEs resolve), the dual-selector ~6-month rotation Microsoft performs automatically by alternating between selector1 and selector2, the seven common M365 DKIM mistakes, and the onmicrosoft.com signing-domain gotcha — Exchange Online's default DKIM signing identity is <tenant>.onmicrosoft.com BEFORE custom DKIM is activated, which PASSES DKIM verification but does NOT align with the From-header organisation domain, therefore FAILS DMARC alignment despite a green DKIM verdict in Authentication-Results. The onmicrosoft.com trap is the SINGLE most common reason an Exchange Online tenant's p=reject rollout breaks legitimate mail: operators see dkim=pass in headers, assume alignment is satisfied, then discover post-enforcement that d=<tenant>.onmicrosoft.com does NOT align with From: user@<domain> under the organisational-domain rule. This is the FIRST M365 cross-protocol bridge from this DMARC-policy guide to the DKIM-side procedural sibling — operators landing here for DMARC enforcement need the DKIM-side procedural deep dive to complete the upstream signing-posture work BEFORE advancing p=none → p=quarantine.
• DKIM key rotation — the M365-EOP-DUAL-SELECTOR-AUTOMATIC- ROTATION-AS-PROVIDER-MANAGED-LIFECYCLE companion to this M365 DMARC deployment guide. Where THIS page documents the p=none → p=quarantine → p=reject ramp at the policy-publication layer, and where the dkim-for-microsoft-365 spoke listed above documents the M365-tenant DKIM signing-posture authoring, the dkim-key-rotation spoke documents the STRUCTURALLY-DISTINCT key-lifecycle management discipline that operates UNDERNEATH the M365-tenant DKIM signing posture and whose canonical procedure (publish-new-key → wait-N-TTL-cycles → sign-with-new-key → wait-M-TTL-cycles → retire-old-key) Microsoft has AUTOMATED on the EOP side via the dual-selector ~6-month alternating rotation pattern (selector1._domainkey → selector2._domainkey → selector1 → … alternation with Microsoft auto-publishing the non-active selector's TXT and auto- rotating the signing-side at the rotation epoch). The M365-tenant operator's responsibility surface during this Microsoft-managed rotation is REDUCED to the TENANT-SIDE CNAME-DELEGATION- MAINTENANCE work documented on the dkim-for-microsoft-365 spoke (publishing and never deleting the selector1._domainkey.<domain> and selector2._domainkey.<domain> CNAME records pointing to the <tenant>.onmicrosoft.com EOP-managed selector subdomains), but the dkim-key-rotation spoke documents the FAILURE-MODE CATALOGUE the M365 tenant operator encounters when EITHER the Microsoft-managed rotation epoch produces a transient verifier-side regression (tenant-side CNAME accidentally deleted right before Microsoft's rotation epoch, producing NXDOMAIN on the newly-active selector) OR the tenant transitions OFF the M365 EOP-managed rotation to a third-party gateway's separate DKIM signing infrastructure (Mimecast / Proofpoint / Barracuda outbound relay with that gateway's own rotation cadence) and inherits the FULL key- rotation operational responsibility the spoke documents. Pair this page (the M365 DMARC deployment ramp guide) with the dkim-key-rotation spoke (the key-lifecycle management discipline reference) when diagnosing M365-tenant transient DKIM- fail bursts that correlate with the ~6-month dual-selector rotation epoch OR when transitioning the M365-tenant DKIM signing posture off EOP-managed automation onto a third-party gateway's operator-managed rotation surface — the spoke documents the safe-rotation procedure whose phase-ordering eliminates the rotation-window DKIM-pause vector whose alignment-fail consequences would otherwise block the DMARC p=quarantine / p=reject ramp advancement THIS page documents.
• DKIM replay attacks (RFC 6376 §8.6) — the M365-DKIM-REPLAY-ATTACK-DEFENSE companion to this M365 DMARC deployment guide. Where THIS page documents the p=none → p=quarantine → p=reject ramp at the policy-publication layer, the replay-attacks spoke documents the RFC 6376 §8.6 REPLAY-ATTACK structural bypass-vector whose captured-and-re- injected legitimate M365-EOP-signed message replayed by an attacker from a different sending IP STILL produces a receiver-side dkim=pass verdict (because the cryptographic signature validates) AND dkim-alignment=pass verdict (because the per-M365-tenant selector1 / selector2 CNAME-delegated d= tag is preserved verbatim from the original M365-EOP- signed emission) AND DMARC-pass verdict (via the DKIM-side alignment leg the M365-EOP signing satisfies) — the per-message DMARC evaluation cannot distinguish replay from origin emission. The replay-attacks spoke documents the M365-tenant structural defenses at FOUR M365-tenant-DKIM- replay-defense dimensions: (i) per-M365-tenant Defender Rotate-DkimSigningConfig per-quarter rotation cadence shortens the per- key replay window — the M365 Defender PowerShell cmdlet Rotate-DkimSigningConfig per-tenant rotation discipline executed on a per-quarter cadence is the canonical per-key-lifetime structural defense every Exchange Online operator must apply as the M365-tenant per-key- lifetime closure of the attacker's replay-window exploitation; (ii) RFC 6376 x= tag signature-expiration discipline — operators publish per-message signature-expiration timestamps in the DKIM-Signature header limiting the replay-window attackers can exploit on captured legitimate M365-egress mail; (iii) narrow per-M365-tenant signing scope discipline — operators constrain the per-message signed- header scope (signed List-Unsubscribe URIs, signed Content-Type, signed Subject:) so replayed messages diverge from the originals in ways that break signature validity; (iv) receiver-side replay-detection signals — sophisticated receivers correlate per-Message-ID replay counts and downgrade-or- reject the replayed variants even when the per-M365-tenant DKIM-pass + DKIM-alignment=pass evaluation otherwise validates. Pair this M365 DMARC deployment guide (the per- policy-publication ramp reference) with the replay-attacks spoke (the per-key-lifetime structural defense reference) for the complete picture of when M365-tenant DKIM-pass + DKIM-alignment=pass + DMARC-pass actually means a legitimate M365-EOP- origin-emitted message vs a replayed attacker-injected variant.
• DKIM troubleshooting — the M365-EOP-DKIM-VERIFICATION-FAILURE- DIAGNOSTIC-INSTRUMENTATION-AND-PER-TENANT- AUDIT-TRAIL-PIPELINE companion to this M365 DMARC deployment guide. Where THIS page documents the _dmarc.<domain> policy publication and the p=none → p=quarantine → p=reject ramp and the adjacent DKIM-for-M365 spoke documents the M365-tenant-specific outbound DKIM signing posture, the dkim-troubleshooting spoke is the per-mail-stream OPERATIONAL DIAGNOSTIC PLAYBOOK M365 tenants execute when dkim=fail rows surface in the tenant's RUA aggregate-report stream on outbound mail or dkim=fail verdicts surface in inbound Authentication-Results headers on inbound mail. The seven-step diagnostic decision tree includes M365- tenant-specific sub-procedures: (1) the Defender Message Trace audit pipeline (security.microsoft.com → Email & collaboration → Exchange message trace with the DKIM-Signature header and Authentication-Results header surfaced as filterable columns), (2) the M365 Tenant Admin Audit Log search for DKIM-key-rotation events (Compliance Center → Audit → Search with DKIM-key- regeneration filter), (3) the selector1._domainkey / selector2._domainkey dual-selector CNAME-resolution audit (the M365-specific two-selector rotation pattern documented on this page produces verification failures during the rotation window when one selector's CNAME target hasn't yet rotated to the EOP- managed key target), (4) the Defender-managed Anti-Spoofing DKIM-validation-override audit (Defender's tenant-allow-list and connector-bypass rules can silently override DKIM verification verdicts producing dkim=pass-aligned-false rows on legitimate-but-misconfigured sender infrastructure that an unaware operator would misdiagnose as a DKIM-rotation issue), (5) the EOP-inbound-canonicaliza- tion edge-case catalogue (Microsoft has historically had specific body-hash- canonicalization-edge-case bugs with certain Unicode normalization scenarios and certain DKIM-Signature header-folding patterns that produce deterministic dkim=fail on legitimately-signed mail in specific time windows), (6) the Exchange-Online-Connector outbound-DKIM-signing-bypass-on-relay diagnostic (when an M365 tenant routes outbound mail through an upstream gateway like Mimecast / Proofpoint / Barracuda the gateway's DKIM-signing-bypass-on- relay setting produces unsigned outbound mail that surfaces as dkim=neutral or dkim=none in receivers' RUA streams), (7) the per-tenant Postmaster-Tools- equivalent telemetry comparison (Microsoft Postmaster doesn't exist for M365 the same way Gmail Postmaster Tools exists for Workspace, so the dkim-troubleshooting spoke documents the substitute Defender- Insights / Smart-Reports / Mail-Flow- Reports surface M365 tenants use for the same diagnostic instrumentation purpose). Pair this page (the M365 DMARC deployment policy guide) with the dkim-trouble- shooting spoke (the M365-EOP-specific DKIM-verification-failure diagnostic playbook) when an M365 tenant's DMARC ramp surfaces unexpected dkim=fail rows that need triage before the p=quarantine / p=reject advance.
• DKIM failures explained — the M365-TENANT-DKIM-FAILURE-MODE- CATALOGUE-AS-DMARC-RAMP-BLOCKING- CLASSIFICATION-INPUT companion to this M365 DMARC deployment guide, and the structural complement to the DKIM-troubleshooting spoke listed above. Where THIS page documents the p=none → p=quarantine → p=reject ramp and the M365-EOP-specific outbound- DKIM-signing posture (Exchange Online dual- selector selector1._domainkey / selector2._domainkey CNAME rotation, EOP-managed RSA-2048 key cryptography under the *-onmicrosoft.com initial domain, tenant-managed selector publication once the tenant's vanity domain replaces the *-onmicrosoft.com default), and where the DKIM-troubleshooting spoke is the SYMPTOM-DRIVEN OPERATIONAL DIAGNOSTIC PLAYBOOK (Defender Message Trace pipeline, Tenant Admin Audit Log search, dual- selector CNAME-resolution audit, Defender- managed Anti-Spoofing DKIM-validation- override audit, EOP-inbound-canonicalization edge-case catalogue), the DKIM-failures- explained spoke is the STRUCTURAL FAILURE- MODE TAXONOMY exhaustively enumerating the per-failure-mode CLASSES the M365 tenant's RUA aggregate-report stream's dkim=fail rows decompose into: body-hash mismatch (Exchange Online Connector body-modification injection, third-party-gateway header / footer- injection rewriting, journaling-rule body- modification side effects), signature-tag syntax invalidity (CNAME-target publisher- side authoring error at registrar / DNS provider, 255-byte TXT-character-string truncation on selector publication), header-list signature-scoping omission (publisher-side configuration drift when third-party gateway introduces or removes headers that should have been in the signed-header set), canonicalization mismatch (Exchange Online's simple-vs- relaxed default vs receiver-side expectation), public-key DNS-resolution failure (selector NXDOMAIN during the dual- selector rotation window where one selector's CNAME hasn't yet rotated, DNS- provider TXT-record publication failure on tenant-managed vanity-domain selector publication), RSA-key-too-small (legacy manually-published RSA-1024 selectors on pre-2018 M365 tenants, rejected by RFC 8301 BCP 18 / RFC 8463 modern-receiver floor), l= body-length-limit drift, multi-signature verifier-precedence ambiguity, expired-key x= timestamp drift, replay-protection signature-reuse rejection at modern Gmail / Yahoo receivers per the 2024 bulk-sender framework. The DKIM-troubleshooting spoke surfaces WHICH operational symptom is presenting in Defender Message Trace; the DKIM-failures-explained spoke surfaces WHICH structural failure-mode class is producing it; together they form the symptom→cause→remediation diagnostic ladder the M365 tenant's DMARC ramp blocks on before p=quarantine / p=reject advancement. Pair this page (the M365 DMARC deployment ramp guide) with BOTH the dkim-troubleshooting spoke (the symptom-driven Defender-Message- Trace-and-Audit-Log entry point) AND the DKIM-failures-explained spoke (the failure-mode-catalogue exhaustive enumeration) when M365 tenant DMARC ramps encounter dkim=fail populations requiring per-failure-mode triage before ramp advancement.
• Reverse DNS / PTR records for mail servers - the M365-TENANT-PTR-PROVIDER-MANAGED- BOUNDARY companion documenting the IN-ADDR.ARPA / IP6.ARPA reverse-zone PTR record discipline whose FCrDNS (Forward-Confirmed reverse DNS) outcome on an M365 tenant's outbound mail flow is NOT tenant-authored but Microsoft-managed at the EOP (Exchange Online Protection) infrastructure layer. Where THIS page documents the M365 DMARC deployment workflow at the _dmarc.<domain> policy level and the p=none → p=quarantine → p=reject ramp, the reverse-DNS-PTR spoke is the IP-IDENTITY-LAYER companion documenting the FCrDNS posture every M365 tenant INHERITS from EOP — a posture that surfaces in tenant-side aggregate-RUA reports under the source_ip column with the Microsoft-managed outbound IP ranges (40.92.0.0/15, 40.107.0.0/16, 52.100.0.0/14, 104.47.0.0/17, etc.) and whose mismatch CANNOT be tenant-remedied. The four-axis M365-TENANT-PTR-CONSTRAINT comparison exposes the structurally-distinct TENANT-VS-PROVIDER-MANAGED-PTR roles: (i) tenant-published SPF/DKIM/DMARC records are tenant-authored, EOP PTR records are Microsoft-authored — the tenant cannot modify the mail-pf-NN-NN.outbound.protection.outlook.com PTR records that EOP publishes for outbound mail; (ii) tenant-side debugging that an outbound IP's FCrDNS is misaligned can ONLY proceed by opening a Microsoft support case — the tenant has no DNS write authority on the protection.outlook.com zone; (iii) tenant-side detection of EOP PTR-related reputation issues surfaces in Microsoft SNDS (Smart Network Data Services) feedback and Gmail Postmaster Tools NOT in tenant-authored infrastructure — the operator debugging workflow MUST consult these receiver-side reputation aggregators that score FCrDNS as ONE input among many; (iv) tenant-side custom-domain MX receiving infrastructure (e.g., on-prem Exchange in a hybrid topology, third-party spam-filter pre-EOP) DOES require tenant- authored PTR records — for those IPs the FCrDNS responsibility is FULLY tenant-side and follows the standard PTR- record-publication discipline the reverse- DNS-PTR reference documents. Read THIS M365 DMARC deployment guide WITH the reverse-DNS-PTR reference when scoping the IP-identity-layer constraints that sit underneath the M365 tenant's DMARC posture: this page documents the application-layer DMARC deployment, the PTR spoke documents the IP-identity-layer FCrDNS context that EOP manages on the tenant's behalf.
• MX records explained - the M365-TENANT-MX-RR-PUBLICATION-AT- tenant-com-mail-protection-outlook-com- AS-EOP-RECEIVE-SIDE-ADDRESSING-LAYER- FOUNDATION companion to this M365 DMARC deployment reference. Where THIS page documents the M365 tenant's _dmarc.<domain> policy publication and the EOP-managed receive- side DMARC evaluation, the MX-records spoke documents the underlying ADDRESSING- LAYER FOUNDATION the M365 receive-side infrastructure publishes: (i) canonical M365 MX hostname pattern — the apex <tenant>-com.mail.protection.outlook.com MX RR (with preference 0 commonly used) is the M365-tenant-default publication the M365 Admin Center wizard provisions during tenant onboarding; (ii) EOP receive-side DMARC evaluator binding — the EOP receive-side DMARC evaluator is the per-message evaluator producing every dmarc=pass / dmarc=fail verdict the M365 tenant receives on inbound mail, and the MX RR is the addressing-layer binding that determines which Microsoft receive-side server population that evaluation runs on; (iii) rua- mailbox-domain MX prerequisite for Microsoft-originated aggregate reports — Microsoft's EOP outbound aggregate-report-emitter delivers rua=mailto: reports only when the publisher's <domain> apex publishes a valid MX RRset reachable from Microsoft's outbound IP ranges; an unreachable MX on the rua-mailbox domain produces the silent "no Microsoft aggregate reports arrive" operator- symptom; (iv) backup-MX preference ordering for M365 hybrid topologies — hybrid Exchange tenants publishing both on-prem MX (preference 10) and Exchange Online MX (preference 20) encounter the M365-tenant-specific per-MX-host evaluation pattern where the higher-preference on-prem MX receives the bulk of inbound mail with the lower-preference Exchange Online MX handling failover. M365 tenants deploying DMARC need the MX-records spoke's apex-MX byte-syntax + per-host preference-ordering semantics to understand the EOP receive-side addressing-layer foundation the DMARC evaluation operates on.
• Email deliverability - the M365-TENANT-EOP-RECEIVE-SIDE- DELIVERABILITY-POLICY-CONSUMER-FOR-DMARC- VERDICT-DRIVEN-SCL-BCL-PCL-SCORING-AND-INBOX- VS-JUNK-VS-QUARANTINE-ROUTING companion documenting the umbrella inbox-placement outcome the Exchange Online Protection (EOP) receive-side filter computes from the DMARC verdicts this M365 deployment guide produces. Where THIS page documents the M365 DMARC deployment workflow at the _dmarc.<domain> policy level and the p=none → p=quarantine → p=reject ramp, the email-deliverability spoke is the UMBRELLA-OUTCOME companion documenting WHY the M365 DMARC deployment matters at the Microsoft EOP receive-side deliverability boundary. The four-axis M365-TENANT-DMARC- DEPLOYMENT-VS-EOP-DELIVERABILITY-POLICY comparison exposes the structurally-distinct MAILBOX-PROVIDER-RECEIVE-SIDE-CONSUMER roles: (i) EOP computes SCL (Spam Confidence Level), BCL (Bulk Complaint Level), and PCL (Phishing Confidence Level) scores from a composite that includes the DMARC verdict as a load-bearing input — a tenant's outbound mail produces SCL 0-1 (clean) when DMARC-aligned-pass and SCL 5-9 (junk-folder) when DMARC-aligned-fail-then-reject-bypassed- by-attacker; inbound mail to the M365 tenant's mailboxes is junk-folder-routed at SCL ≥ 5 by default; the deliverability spoke documents the per-EOP-control SCL/BCL/PCL thresholds the DMARC deployment on this page is engineered to clear; (ii) EOP's Anti-Spam policy and Anti-Phishing policy (configurable via the Microsoft 365 Defender portal at Threat Policies / Anti-spam) gate the inbox-vs-junk-vs-quarantine routing decision through the HonorDmarcPolicy setting that determines whether the publisher's p=reject request is HONORED at the M365 tenant's receive-side or downgraded to a SafeList-bypass — the deliverability spoke documents the per- EOP-control deliverability outcomes this toggle produces; (iii) Microsoft Defender for Office 365 (the premium tier of the M365 receive-side filter) consumes the DMARC verdict as one input to its ZAP (Zero-hour Auto Purge) post-delivery message-removal decision — when a message is delivered to inbox at delivery time then later discovered to be attacker- bypass via the DMARC layer, ZAP retroactively removes the message from recipient mailboxes; the deliverability spoke documents the post-delivery deliverability outcomes the DMARC deployment on this page enables; (iv) EOP outbound deliverability (the mail the M365 tenant SENDS to other receivers) is bounded above by the tenant's FCrDNS-pass-rate on the EOP-managed outbound IP pool AND the DMARC-aligned-pass-rate on outbound mail at the receiver's side — the deliverability spoke documents the operator-side feedback loop (Microsoft SNDS for IP-reputation, Microsoft 365 Defender mail-flow reports for DMARC- aligned-pass-rate trends, Gmail Postmaster Tools for cross-receiver tenant-domain- reputation) the DMARC deployment on this page is engineered to optimise. Read THIS M365 DMARC deployment guide WITH the email- deliverability reference when scoping the umbrella inbox-placement outcome the DMARC deployment is engineered to drive at the Exchange Online Protection receive-side boundary, and when building the tenant-side deliverability-monitoring feedback loop that surfaces DMARC-deployment-related deliverability churn at the M365 EOP filter.
• DMARC record tags explained - every tag in the DMARC DNS record (v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri).
• DMARC alignment explained - identifier alignment (the SPF-or-DKIM-domain-matches-From: rule). The single concept that makes SaaS senders fail until they CNAME-delegate DKIM under your domain.
• DKIM alignment with DMARC — the DKIM-side alignment procedural deep dive (the M365-TENANT-DKIM-ALIGNMENT-DEPLOYMENT companion to this M365 deployment guide) - the M365-TENANT-DKIM-ALIGNMENT-DEPLOYMENT companion documenting the DKIM-side alignment procedural reference that every M365 tenant must validate during the DMARC-deployment workflow this page documents. Where THIS page is the M365-specific deployment guide (the onmicrosoft.com initial-domain DKIM signing, the selector1._domainkey / selector2._domainkey CNAME records pointing to Microsoft-hosted public keys, the Defender for Office 365 anti-spoof intelligence layer, the EOP inbound-flow rules interacting with received DMARC enforcement, the Set-DkimSigningConfig / Rotate-DkimSigningConfig PowerShell cmdlet workflow, the Microsoft-specific 550 5.7.509 rejection code), the DKIM-alignment-with-DMARC spoke is the DKIM-SIDE ALIGNMENT REFERENCE the M365 tenant operator MUST validate to advance the deployment from p=none through p=quarantine to p=reject. The M365 tenant has FIVE M365-specific DKIM-alignment-with-DMARC deployment validation points the cross-reference makes explicit: (i) onmicrosoft.com-vs-custom-domain signing alignment — by default M365 signs outbound with the onmicrosoft.com tenant initial domain which does NOT align with a custom From: domain; tenants MUST enable custom-domain DKIM signing via Set-DkimSigningConfig -DomainName customer.com -Enabled $true for DKIM-aligned-with-DMARC posture to even be possible; (ii) EOP CNAME-delegated selector model — Microsoft does NOT let tenants publish their own DKIM public keys; the selector1._domainkey.customer.com CNAME must point to Microsoft's selector1-customer-com._domainkey.tenant.onmicrosoft.com record (the canonical M365 CNAME-delegated DKIM pattern), and validation of this delegation is the DKIM-alignment-with-DMARC prerequisite; (iii) Defender-for-O365 anti-spoof rules interact with DKIM-aligned verdicts — even when DKIM-aligned-with-DMARC is passing, Defender's "User impersonation" and "Domain impersonation" policies can independently quarantine messages; tenants must understand the interaction; (iv) third-party-sender DKIM delegation via partner CNAMEs — for Mailchimp, Salesforce, Constant Contact senders to be DKIM-aligned-with-DMARC, the tenant publishes additional selector CNAMEs (e.g. k1._domainkey.customer.com → k1.dkim.salesforce.com) following the same CNAME-delegated pattern as the M365-1P selectors; (v) Microsoft 550 5.7.509 rejection occurs ONLY when DKIM-aligned-with-DMARC AND SPF-aligned-with-DMARC both fail at p=reject — operators debugging this M365-specific rejection code need the DKIM-alignment deep dive to identify which of the two alignment paths is breaking.
• DMARC policy rollout - the operational migration from p=none through p=quarantine to p=reject with a worked Week 0 -> Week 26 timeline.
• DMARC deployment checklist - the CROSS-PROVIDER canonical reference for the step-by-step DMARC deployment procedure. Where THIS page is the M365-specific deployment guide (covering Microsoft-specific gotchas: the onmicrosoft.com DKIM-domain pattern, the CNAME-delegated selector model unique to Exchange Online, the Defender for Office 365 anti-spoof intelligence layer, the EOP inbound-flow rules that interact with received-DMARC enforcement, and the Microsoft-specific 550 5.7.509 rejection code), the deployment-checklist spoke is the PROVIDER-AGNOSTIC procedural reference documenting the universal first-time DMARC deployment sequence applicable across any mailbox provider: pre-flight sender inventory, SPF + DKIM prerequisite verification, baseline RUA-stream instrumentation, initial p=none record construction, receiver-side propagation verification, and 30-60-day post-publication monitoring cadence. Read the deployment-checklist spoke ALONGSIDE this M365 page when an M365 customer is first deploying DMARC — the checklist is the cross-provider procedural scaffold, and this page documents the provider- specific exceptions and configuration details for the M365 deployment slot in the scaffold. The cross-link is symmetric: read this page first if the deployment is M365-only; read the checklist first if the organization has a mixed M365 + Google Workspace fleet.
• DMARC aggregate (RUA) reports - the daily XML stream receivers send back. The data behind every rollout decision.
• ARC (Authenticated Received Chain) explained - RFC 8617: preserves SPF / DKIM / DMARC results across forwarding hops (security gateways, mailing lists, .forward redirects). The protocol behind Defender for Office 365 Trusted ARC Sealers.
• Phishing protection - defense-in-depth stack (the M365-TENANT-PHISHING-DEFENSE-DEPLOYMENT companion to this M365 DMARC deployment guide) - the M365-TENANT-PHISHING-DEFENSE-DEPLOYMENT companion documenting the BROADER PHISHING- DEFENSE-IN-DEPTH STACK whose central protocol-layer mechanism is the DMARC-at-p=reject deployment THIS page documents step-by-step for Microsoft 365 tenants. Where THIS page documents the M365-SPECIFIC DMARC PUBLICATION WORKFLOW (the SPF-with- spf.protection.outlook.com include, the CNAME-delegated DKIM signing- key pair at selector1 / selector2 sub-domains, the _dmarc.<domain> TXT publication, the Defender-for-Office-365 trusted ARC sealer configuration, the Phase-1-through-Phase-5 ramp from p=none to p=reject), the phishing-protection umbrella documents the M365-TENANT PHISHING-DEFENSE STACK the operator must build AROUND the DMARC deployment: (i) M365 ANTI-IMPERSONATION POLICIES (the Defender-for-Office-365 anti-phishing policies that target display-name spoofing and lookalike-domain abuse the DMARC alignment computation STRUCTURALLY CANNOT see, the Microsoft Defender-for-Office-365 Mailbox Intelligence learning the tenant's legitimate-correspondent graph, the Spoof Intelligence Insight surfacing cross-tenant sender heuristics), (ii) SAFE-LINKS + SAFE-ATTACHMENTS (the URL-rewrite + sandbox-detonation defenses for the residual surface DMARC cannot protect — phishing links in messages that are themselves DMARC-aligned-but-malicious, e.g. compromised legitimate-sender accounts), (iii) M365 MTA-STS POLICY PUBLICATION (the transport-layer downgrade- attack prevention required for the complete defense-in-depth stack — the v=STSv1 policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt complemented by the _mta-sts TXT record), (iv) M365 BIMI VMC / CMC ENROLLMENT (the post-DMARC visual- indicator trust signal that encourages legitimate-sender alignment adoption and provides the user-facing distinguishing marker between legitimate-tenant mail and attacker-impersonation attempts), (v) M365 ATTACK-SIMULATION-TRAINING (the Defender-for-Office-365 attack-simulation campaigns that train M365 mailbox users to recognise the residual phishing surface the DMARC + DKIM + SPF protocol- layer stack cannot close). Read THIS M365 DMARC deployment guide WITH the phishing-protection umbrella when authoring an M365-tenant phishing-defense runbook: the DMARC deployment guide documents the protocol-layer foundation, the phishing-protection umbrella documents the M365-specific application-layer + transport-layer + user-training defense layers that surround the foundation.
• Business Email Compromise (BEC) — the FINANCIAL-IMPACT THREAT-SCENARIO companion to this M365 deployment guide. Where THIS page documents the EOP-specific DMARC publication workflow (the SPF-with-spf.protection.outlook.com include, the CNAME-delegated DKIM signing-key pair at selector1 / selector2 sub-domains, the _dmarc apex TXT publication, and the Defender-for-Office-365 trusted ARC sealer configuration), the BEC spoke documents the FINANCIAL-IMPACT THREAT SCENARIO Microsoft 365 customers are disproportionately targeted by per FBI IC3 reporting: (a) M365-hosted executive mailboxes are the #1 BEC target population because the global M365 enterprise deployment base concentrates high-value wire-transfer-authorising identities in a predictable identity-graph footprint attackers can enumerate via LinkedIn / public org charts; (b) Defender for Office 365 anti-phishing policies depend on the DMARC enforcement value documented on this page (the impersonation-protection feature requires p=quarantine minimum on the protected-sender domain list to escalate impersonation-suspect messages); (c) M365 user-level controls (mailbox-level "first-time external sender" warnings, Safe Links scan-on-click, Safe Attachments detonation sandbox) layer ON TOP of the DMARC enforcement this page configures rather than substituting for it; (d) the M365 Exchange Online Protection (EOP) anti-spoof intelligence explicitly references the DMARC verdict from the publishing domain documented on this page as one input to its CONFIDENCE-LEVEL spoof- score per the EOP documentation. The BEC spoke makes the M365-specific target-population framing EXPLICIT — critical operator knowledge when scoping the urgency of the DMARC deployment cadence on this page for a Microsoft 365 enterprise. Read the BEC spoke when building the executive case for an M365 DMARC project ("why should finance/legal/exec sponsor an M365 DMARC rollout right now"; the answer is the target-population concentration the BEC spoke catalogues plus the $50B FBI IC3 cumulative-loss figure that justifies the operational investment).
• Email spoofing explained — the M365-EOP-TENANT-DMARC-DEPLOYMENT- AS-PER-SPOOFING-TECHNIQUE-DEFENSE- PRIMITIVE companion to this Microsoft 365 DMARC deployment guide. Where THIS page documents the EOP-specific DMARC publication workflow (v=spf1 include:spf.protection.outlook.com -all SPF authoring, the selector1._domainkey / selector2._domainkey CNAME-delegated DKIM signing-key pair, the _dmarc apex TXT publication, and the Defender-for-Office-365 trusted-ARC- sealer configuration), the email-spoofing spoke documents the ADVERSARY-SIDE seven-spoofing- technique catalogue this M365 DMARC deployment structurally defends against. Concretely, the spoke documents FOUR M365-tenant-specific-spoofing- technique-mitigation dimensions: (i) exact-domain From-header forgery on the M365-tenant's protected domain (spoofing Technique #1) is DEFENDED END-TO-END by the EOP-enforced DMARC p=reject policy this guide ramps to — the canonical M365 attack vector the deployment workflow STRUCTURALLY ELIMINATES at terminal p=reject, with Defender for Office 365's impersonation-protection adding a secondary defense layer against From-header-similar messages that slip past the DMARC verdict; (ii) display-name-only attacks on M365 inboxes (spoofing Technique #4) is STRUCTURALLY INVISIBLE to the DMARC verdict (the attacker's From: address-domain is gmail.com / outlook.com / attacker-controlled.tld and DMARC alignment evaluates against the attacker's domain — passing) but is DEFENDED by the Defender for Office 365 anti-phishing policy's user-impersonation-protection feature (configurable per-protected- user-mailbox list at security.microsoft.com), which compares display-name strings against the M365 tenant's executive directory and applies confidence-scored quarantine actions — the M365-tenant-specific defense the DMARC trinity STRUCTURALLY CANNOT cover but Defender for Office 365 fills the gap on; (iii) cousin/lookalike domain registration with Punycode-confusable IDN homograph (spoofing Technique #5) targeting the M365 tenant's protected domain (typo-permutations of contoso.com → contoso-corp.com / cоntoso.com with Cyrillic 'о') is DEFENDED by Defender for Office 365's domain-impersonation-protection feature (configurable per-protected- domain list with internal-domain auto-population and external- domain operator-defined list) which detects From-domain-similar messages via Levenshtein distance scoring AND IDN homograph normalisation — the M365-tenant- specific defense for cousin-domain attacks the DMARC trinity STRUCTURALLY CANNOT cover; and (iv) compromised-account VEC of an M365 mailbox (spoofing Technique #7) with the attacker authenticating to the M365 mailbox via stolen credentials and sending mail through the legitimate-tenant's outbound path (producing valid DMARC alignment because the mail IS from the legitimate tenant's infrastructure) is DEFENDED by Microsoft Entra ID's conditional-access MFA policy + Defender for Cloud Apps anomalous- send-pattern detection + Defender for Office 365's account-compromise playbook in security.microsoft.com — the M365-tenant-specific identity-layer defense for VEC the DMARC trinity STRUCTURALLY CANNOT cover but the Microsoft 365 E5 / Microsoft Defender XDR identity- protection-stack fills the gap on. Read the email-spoofing spoke alongside THIS M365 deployment guide when scoping the M365 tenant's comprehensive anti-spoofing posture — the spoke's seven-technique catalogue is the AUTHORITATIVE threat-vector taxonomy the M365-tenant deployment must defend against across the DMARC + Defender for Office 365 + Microsoft Entra ID + Defender for Cloud Apps four-pillar stack — AND when building the M365-tenant executive case for budget allocation across the Microsoft 365 E3 (DMARC + EOP base) vs E5 (Defender for Office 365 + Defender XDR full stack) licensing tier decision the seven-technique coverage analysis directly informs.
• How attackers bypass DMARC - the M365-TENANT-ATTACKER-RESIDUAL companion to this Microsoft 365 DMARC deployment guide. Where THIS page documents the M365-tenant-specific protocol-deployment workflow (the Exchange Admin Center Authentication-Policy provisioning, Selector1/Selector2 CNAME-delegated DKIM, spf.protection.outlook.com SPF include, EOP transport-rule layering, p=none → p=quarantine → p=reject ramp aligned with Defender for Office 365 anti-spoof intelligence), the attacker-bypass spoke documents the M365-TENANT-SPECIFIC ATTACK SURFACE that remains AFTER the operator completes the full M365 deployment to p=reject: (i) M365 Direct-Send bypass — the M365 feature that allows unauthenticated SMTP submission to the tenant's tenant-com.mail.protection.outlook.com MX hostname for sending to internal recipients; attackers exploit Direct-Send to inject attacker-payloads into the tenant's OWN tenant.onmicrosoft.com recipients with no DMARC evaluation applied to internal-to-internal flow, (ii) tenant-impersonation via compromised-partner-tenant — when an attacker compromises an accepted-domain partner-tenant (the legitimate B2B partner the operator has whitelisted in EOP), the compromised partner's mail aligns to ITS d= signature, passes DMARC, and passes EOP's accepted-domain anti-spoof skip-list, (iii) display-name spoofing against M365 executive mailboxes (M365 OWA / Outlook for Windows / Outlook for Mac all display the From-header friendly-name prominently, with the from-address domain often elided in default mobile Outlook views; attackers exploit this UI surface against M365 executives — the canonical BEC attack vector the EOP anti-spoof intelligence catches only IF the executive's name has been seeded in the impersonation- protection allow-list), (iv) lookalike onmicrosoft.com tenant registration — attackers register acme‐bank.onmicrosoft.com (Unicode hyphen) or acmebank-corp.onmicrosoft.com (legitimate-looking suffix) and author valid DKIM / SPF / DMARC on the lookalike tenant; the lookalike passes DMARC and exploits the visual-similarity at the recipient, (v) DKIM-replay attacks against M365-signed mail (the legitimately-DKIM-signed Selector1/ Selector2 signature still verifies on replay), (vi) third-party-vendor compromise of M365-tenant-customised ESPs — when an attacker takes over a SendGrid / Marketo / Klaviyo / Mailchimp tenant the M365 operator has aligned via vendor custom-DKIM-CNAME-delegation, the compromised ESP signs with the operator's d= and passes alignment, (vii) hybrid Exchange on-prem-side compromise when the operator runs hybrid topology (covered in detail on the DMARC-for-Office-365-hybrid spoke). The attacker-bypass spoke is the load-bearing residual-attack-surface reference for any M365 operator who completes THIS page's deployment to p=reject and now needs to define the M365-specific complementary-defence stack: Defender for Office 365 impersonation- protection policy (executive name / display-name allow-list with Mailbox Intelligence), Anti-Spoof Transport Rules with custom user- impersonation rules, Safe Attachments / Safe Links, BIMI for post-p=reject brand- trust anchoring, accepted-domain partner-tenant validation discipline (regular review of EOP partner connector allow-lists), and Direct-Send connector restrictions (limiting Direct-Send to specific source IPs via inbound connector filters).
• DMARC for Google Workspace - the sibling per-mailbox-provider deployment guide. Compare the TXT-publication DKIM model (Workspace) with the CNAME-delegation DKIM model (M365) side by side.
• Multi-domain DMARC strategy - the operational playbook for the canonical M365 multi-domain topology where a single Exchange Online tenant hosts mail for several distinct sending domains: primary brand, acquired-company brands, regional / country brands, multi-line-of- business brands, parked / legacy non- sending domains, and the onmicrosoft.com tenant domain itself. M365 tenants are the single most common multi-domain operator class — virtually every enterprise M365 tenant runs at least 3 domains and many large enterprises run 50+. The page documents the four-pattern decision framework (single-org-many-brands, many-orgs-one-tenant, acquired-domain wind-down, parked-domain enforcement), the per-domain _dmarc.<domain> publication discipline (every active sending domain needs its own DMARC record — the apex DMARC record does NOT cover sibling brands), the organizational-domain boundary as defined by the Public Suffix List (PSL) and how it interacts with the sp= (subdomain policy) and np= (non-existent subdomain policy) tags, the canonical p=reject; sp=reject; aspf=s; adkim=s record for parked / never-sending domains, the brand-aware RUA aggregator configuration so each brand's DMARC reporting routes to the brand-team inbox (not the corporate IT inbox), and the per-domain DKIM selector inventory (selector1._domainkey.brand-a.com vs selector1._domainkey.brand-b.com — each brand domain gets independent CNAME delegation to the M365 tenant). Read once you understand the single-domain M365 deployment on this page and need the deployment pattern for the canonical enterprise multi-domain topology.
• DMARC for Hybrid Exchange (on-prem + M365) - the hybrid-topology companion to this cloud-only M365 guide. Read if your outbound mail flow is split between Exchange on-premises and Exchange Online. Covers the dual-signer DKIM problem, ARC sealing across the on-prem-to-cloud relay (RFC 8617 + Defender Trusted ARC Sealers via Set-ArcConfig), the Default Frontend Connector DKIM-strip pitfall, Send Connector relay loops (NDR 5.4.6), and the Centralized Mail Transport (CMT) migration path that eliminates the dual-signer problem.
• DMARC for cPanel & Shared Hosting - the SMB / shared-hosting sibling deployment guide. cPanel auto-generates SPF + DKIM but not DMARC, uses the default._domainkey selector (vs M365's selector1 / selector2), publishes DKIM as TXT (not CNAME), runs Exim (not Exchange Online), and has the shared-IP reputation ceiling problem that enterprise tenants on M365 do not face.
• DMARC for Shared Hosting: Plesk, DirectAdmin, ISPConfig - the shared-hosting deployment guide for platforms OTHER than cPanel. Covers Plesk (Postfix backend, DKIM toggle at Mail Settings > DKIM spam protection, default selector), DirectAdmin (Exim backend, DKIM at Email Manager > DKIM, single- character x selector), ISPConfig (Postfix + Dovecot), Webmin / Virtualmin, CentOS Web Panel, and the generic-no-control-panel population with a SaaS-relay CNAME-delegated DKIM escape hatch. Useful for evaluating whether a hybrid M365-cloud + on-prem- shared-hosting flow needs DMARC handled per-platform or via a unified relay.
• MTA-STS vs DANE for SMTP - the head-to-head COMPARISON of the two SMTP transport-security standards (RFC 8461 MTA-STS vs RFC 7672 DANE for SMTP). Read once authentication (SPF + DKIM + DMARC) is running and you turn to transport security: Exchange Online inbound supports MTA-STS and TLS-RPT, but Microsoft has stated no plans to support DANE on Exchange Online inbound (as of 2026). The comparison page documents the trust-model asymmetry (web-PKI vs DNSSEC), the RFC 7672 §1.3 coexistence rule, and the per-provider support matrix so M365 operators can pick the standard that actually deploys against their MX endpoints.
• MTA-STS for Microsoft 365 — the same-provider transport-security companion to this DMARC-side application-layer policy guide - DMARC publishes the _dmarc.<domain> TXT record that tells receivers "if SPF or DKIM does not pass + align, apply policy X and send aggregate reports to rua=" — but DMARC operates entirely at the application layer and does NOT pin the SMTP session carrying the message to TLS at the transport layer. An active downgrade attacker between the sender and Exchange Online can still strip the STARTTLS announcement, force the SMTP session into cleartext, harvest the message body + attachments + DKIM signatures verbatim, and replay or analyse the captured traffic offline — the DMARC policy this guide deploys does not see this attack at all because the message was delivered with a valid dmarc=pass verdict at the application layer. M365 operators reading this DMARC-side policy guide to complete the application-layer enforcement ramp (the p=none → p=quarantine → p=reject rollout this page describes alongside the pct= staging and rua= aggregate-report configuration) need the MTA-STS-for-Microsoft-365 spoke as the TRANSPORT-LAYER COMPLEMENTARY companion deployed against the same M365 tenant: the spoke documents where exactly to publish the _mta-sts.<domain> policy version-pointer TXT record (with the v=STSv1; id=<policy-version> format and the version-bump rotation protocol), where to stand up HTTPS hosting for the mta-sts.<domain> web origin on Azure (Blob Storage + CDN, Static Web Apps, App Service, Front Door), how to author the /.well-known/mta-sts.txt policy file with the Exchange-Online-specific mx: <tenant>-com.mail.protection.outlook.com directive, how to wire up TLS-RPT at _smtp._tls.<domain> for the JSON failure-report dwell-time feedback loop, and the testing-mode burn-in workflow that protects production mail during the deployment window. The sequencing matters operationally: complete the SPF + DKIM + DMARC application-layer deployment first (this page is the DMARC anchor of that work), then layer MTA-STS on top as the transport-layer companion — DMARC tells receivers WHAT TO DO when authentication fails, MTA-STS tells senders the message MUST go over enforced TLS to Exchange Online inbound and TLS-RPT gives a feedback loop telling you when the transport-layer enforcement is rejecting traffic. Read this spoke immediately after the DMARC p=quarantine ramp step from this guide — the application-layer policy alone leaves a structural transport-layer gap an active downgrade attacker exploits.
• MTA-STS for Google Workspace — the M365-TENANT-DMARC-ALIGNED-EGRESS- TO-WORKSPACE-MTA-STS-RECEIVE-BOUNDARY companion to this M365 DMARC deployment pillar. Where THIS page documents the M365-tenant DMARC record authoring + 4-phase rollout (the _dmarc.<tenant-domain> TXT-record publication with the v=DMARC1; p=none/quarantine/reject; rua=mailto:rua@<tenant-domain> record skeleton, the Phase 0 protective- registration + tenant-domain-coverage prerequisite, the Phase 1 monitor-mode + SPF/DKIM-authoring + RUA-aggregation burn-in, the Phase 2-3 pct=N gradual-ramp + p=quarantine consolidation with the M365-EOP-quarantine-DSN-path bound-buffer-period operator-discipline, and the Phase 4 terminal-p=reject with Friendly-From-header alignment-enforced-by- receivers contract) — i.e. the APPLICATION-LAYER-DMARC-AUTHENTICATION- AND-ENFORCEMENT side of M365-tenant mail- emission — the Workspace MTA-STS spoke is the CROSS-PROVIDER-WORKSPACE-RECEIVE-SIDE- TRANSPORT-LAYER-ENFORCEMENT-BOUNDARY companion documenting the Workspace- tenant-published MTA-STS policy that M365-tenant-Exchange-Online-outbound mail to Workspace-tenant-receiving-domains MUST respect at the SMTP-STARTTLS boundary regardless of the M365-DMARC-alignment verdict THIS page documents. Concretely, the spoke documents FOUR M365-DMARC-to- Workspace-MTA-STS-cross-provider- coordination dimensions: (i) M365- tenant-Exchange-Online-outbound-connector- delivered DMARC-aligned mail to Workspace- hosted recipient domains traverses the Workspace-tenant-published MTA-STS enforce- mode policy at the SMTP session boundary — the M365-tenant DMARC- alignment verdict THIS page documents at the Friendly-From-header is STRUCTURALLY INDEPENDENT of the Workspace-receiver-side MTA-STS STARTTLS-enforcement verdict the spoke documents; an M365-tenant terminal- p=reject DMARC posture combined with Workspace-receiver-side mode=enforce MTA- STS posture creates a CROSS-PROVIDER DOUBLE-LAYER ENFORCEMENT contract where BOTH the application-layer DMARC pass-with- alignment AND the transport-layer STARTTLS- certificate-validated TLS session MUST succeed simultaneously for an M365-tenant- outbound message to be delivered to a Workspace recipient; (ii) the M365- tenant-Exchange-Online-sending-MTA performs MTA-STS policy-cache lookup at the Workspace-receiving-domain boundary BEFORE the SMTP DATA phase carrying the DMARC-aligned message body — the cross-provider transport-layer lookup at the Workspace operator's https://mta-sts.<workspace- domain>/.well-known/mta-sts.txt endpoint runs BEFORE the M365-tenant Exchange Online sending MTA opens the SMTP DATA phase that carries the From: <m365-tenant-domain> Friendly-From header whose DMARC alignment THIS page documents; (iii) M365- tenant-Exchange-Online-outbound mail to Workspace recipients is envelope-encrypted by Workspace-receiver-side MTA-STS-enforced STARTTLS but the M365-tenant DMARC alignment is APPLICATION-LAYER ORTHOGONAL to the transport-layer encryption envelope — the Workspace MTA-STS spoke documents that the cross-provider SMTP session encryption is structurally SEPARATE from the M365-tenant-DMARC- Friendly-From-header-alignment-verdict at the application layer; (iv) cross- provider M365-to-Workspace TLS-RPT failure correlation requires per-Workspace-MX-host failure attribution coordinated with per-M365-tenant DMARC RUA aggregation coordination — the Workspace MTA- STS spoke documents the per-MX-host failure attribution discipline the Workspace operator runs on the receive side, and the M365-tenant operator coordinates the cross- provider RUA-aggregation correlation through the M365-tenant DMARC RUA pipeline THIS page documents to attribute Workspace- receiver-side transport-failure events to the corresponding M365-tenant-Friendly- From-header-domain-alignment context. Read the MTA-STS-for-Google-Workspace spoke alongside this M365 DMARC deployment pillar when planning M365-tenant DMARC deployment whose terminal-p=reject posture emits cross-provider outbound mail to Workspace-hosted recipient domains — the Workspace-receiver-side MTA-STS-enforced- STARTTLS-boundary is the load-bearing cross-provider transport-layer-receive-side- enforcement consumer-role whose Workspace- operator-published policy file the M365- tenant-Exchange-Online sending MTA must cache, validate, and respect at the SMTP boundary regardless of the M365-tenant- DMARC-alignment-verdict THIS page documents.
• BIMI Verified Mark Certificates (VMC and CMC) - the brand-logo-acquisition companion to this M365 DMARC deployment guide. Once this tenant reaches p=quarantine or p=reject per the rollout timeline on this page, the next commercial-value milestone is the Verified Mark Certificate that unlocks brand-logo display in Outlook.com and the Outlook web/mobile apps — Microsoft added BIMI logo rendering to Outlook in 2023 and the consumer Outlook surface is one of the four primary VMC-requiring inboxes (alongside Gmail, Apple Mail, Yahoo, Fastmail). The certificates page documents the VMC vs CMC distinction (Verified Mark Certificate requires a registered trademark; Common Mark Certificate accepts unregistered marks but only Gmail honours it), the two issuing CAs (DigiCert and Entrust), the trademark-evidence pack each CA validates, the PEM-bundle file format the BIMI record's a= URL must serve, the 12-month renewal cadence, and the pricing landscape (typically ~$1,500-$2,500 USD per year per domain). Read once the DMARC rollout on this page reaches enforce and the brand team asks "how do we get our logo to render in Outlook?"
• BIMI SVG file requirements (SVG Tiny PS profile) - the brand-logo-asset companion to the certificates spoke above, equally required for Outlook BIMI rendering. The Outlook consumer surface (added BIMI display in 2023) validates BOTH the a= certificate AND the l= SVG file before rendering — a profile-invalid SVG silently fails even with a valid VMC. This page documents the baseProfile="tiny-ps" root attribute that gates conformance (its omission is the #1 silent-rejection cause across Outlook and Gmail alike), the permitted/forbidden element whitelist (no <script>, no <animate>, no external raster <image> references — even though all three parse as valid SVG), the 1:1 square aspect ratio with safe central crop circle that survives Outlook's display crop in the contact-card and message-list surfaces, the HTTPS-only fetch contract with public-PKI trust chain (Outlook rejects self-signed and Let's Encrypt v0 chains for the SVG URL), the < 32 KB recommended file-size ceiling for inbox render latency, and the SVG-validator tooling published by the BIMI Group. Read alongside the certificates spoke once the DMARC rollout reaches enforce and the brand team is producing the SVG asset for the Outlook BIMI deployment.
• DMARC forensic reports (RUF) — the TENANT-SENDER-PROTECTED-DOMAIN- RUF-INBOUND-DESPITE-EXCHANGE-ONLINE- RECEIVER-NON-EMISSION companion reference. Where THIS page documents the M365 tenant's DMARC deployment (DKIM CNAME publication via Defender portal, Trusted ARC Sealers, BIMI certificate-anchored brand display, Exchange Online send/receive auth posture), the forensic-reports spoke is the COUNTER-INTUITIVE COVERAGE- ASYMMETRY companion documenting a subtlety every M365 tenant administrator must understand: M365's Exchange Online Protection (EOP) does NOT itself emit RUF forensic reports for inbound DMARC failures it observes (Microsoft does not implement RUF generation per documented platform policy — Exchange Online emits RUA aggregate reports only). HOWEVER, the M365 tenant's PROTECTED domain still receives RUF samples from OTHER receivers (Comcast, GMX, Yahoo historically, Mail.ru, boutique providers — the ~5% of the receiver population that does implement RUF emission) when those receivers detect DMARC failures against the tenant's From: domain. The correct M365 deployment posture is therefore: (i) configure ruf=mailto:dmarc- forensic@example.com in the tenant's DMARC TXT record EVEN THOUGH M365 itself won't be among the senders (the small population of RUF- emitting external receivers is the actual source of inbound samples); (ii) ensure the ruf= mailbox is sized for the long-tail volume from those external receivers (typically <1% of the RUA volume); (iii) set operator expectation that "Microsoft receivers won't send us RUF" is NOT equivalent to "we won't receive any RUF" — read this asymmetry on the forensic-reports spoke when scoping the M365 tenant's DMARC-monitoring infrastructure.
• TLS-RPT JSON report format — the PER-M365-TENANT-TLS-RPT-JSON- REPORT-INGESTION-AS-TRANSPORT-LAYER- OBSERVABILITY-COMPLEMENT-TO-PER-TENANT- DMARC-AGGREGATE-INGESTION companion to this M365-tenant DMARC-deployment reference. Where THIS page documents the per-M365-tenant DMARC-record publication discipline + per-tenant EOP outbound DKIM-signing + per-tenant rua aggregate-XML ingestion pipeline + per-tenant Exchange Online connector topology, the TLS-RPT JSON-report- format spoke is the TRANSPORT-LAYER- TELEMETRY-PUBLICATION-AND-INGESTION companion documenting the RFC 8460 §4 JSON report grammar whose per- failure-class catalogue is the load- bearing per-tenant transport-layer- TLS-failure observability primitive complementing the per-tenant message- layer DMARC aggregate-XML observability this M365 deployment guide documents. The four-axis M365-TENANT-DMARC-RUA- XML-VS-TLS-RPT-JSON comparison exposes the structurally-distinct per-M365-tenant cross-layer observability-publication-ingestion couplings: (i) per-M365- tenant rua aggregate-XML ingestion consumes RFC 7489 §7.2 aggregate- feedback-format XML grammar (per-source-IP DMARC verdict rows + per-record DKIM/SPF auth-result evidence + per-disposition counters); per-M365-tenant TLS-RPT JSON ingestion consumes RFC 8460 §4 JSON report grammar (per-failure-class attribution + per-receiving-mx identification + per-policy-host- cert validation-outcome) — both are per-tenant per-day-aggregated observability publications but at structurally-distinct layers (message- layer DMARC alignment outcomes vs transport-layer TLS handshake outcomes); (ii) per-M365- tenant rua aggregate-XML is emitted BY peer-receivers TO the M365 tenant's rua= mailbox via SMTP (mailto:); per- M365-tenant TLS-RPT JSON is emitted BY peer-receivers TO the M365 tenant's rua=mailto: or rua=https: endpoint per the per-tenant _smtp._tls.<tenant>.<tld> TXT-RR publication — both per-tenant observability pipelines require the M365 operator to publish the per-tenant report- ingestion endpoint AND maintain per-tenant report-aggregator infrastructure that parses the respective XML / JSON byte-grammars; (iii) per-M365-tenant TLS- RPT JSON reports surface every receiver-side STARTTLS-collapse event at the per-tenant tenant.mail.protection.outlook.com inbound MX boundary that the per- tenant DMARC rua aggregate-XML does NOT capture (rua reports the AUTHENTICATION outcome AFTER the TLS handshake succeeds; TLS-RPT reports the TRANSPORT outcome whether the authentication-layer ever runs) — per-M365- tenant operators auditing why a sender-side rua row shows zero delivery to the M365 tenant must cross-reference the per-tenant TLS- RPT JSON for the upstream STARTTLS- availability outcome; (iv) per-M365-tenant TLS-RPT JSON-report-format ingestion is the operationally-load-bearing observability primitive for the per-tenant _mta-sts.<tenant>.<tld> publication contract — operators publishing MTA-STS at the per-M365-tenant domain MUST ingest TLS-RPT JSON reports to observe whether peer-senders are successfully honouring the per- tenant TLS-enforcement contract, whether the per-tenant policy-host cert is correctly issued/rotated, and whether the per-tenant max-age/mode= publication is consistent with the per-tenant per-receiver TLS-handshake outcome. Read the TLS-RPT JSON-report-format spoke alongside this M365 DMARC- deployment reference when scoping the per-M365-tenant cross-layer observability stack — the spoke documents the per-failure-class JSON-report grammar that surfaces every per-M365-tenant transport- layer TLS-handshake outcome the per-tenant DMARC rua aggregate-XML observability layer this M365 page documents cannot directly capture.
• DMARC for transactional email — the M365-TENANT-PLUS-THIRD-PARTY- TRANSACTIONAL-ESP-DUAL-EGRESS-PUBLISHER- IDENTITY-ALIGNMENT-COORDINATION- COMPANION-AT-FOUR-PER-TENANT-PLUS-PER- ESP-STREAM-ALIGNMENT-COORDINATION- DIMENSIONS companion to this DMARC-for- Microsoft-365 reference. Where THIS page documents the per-M365-tenant DMARC deployment discipline at the per-tenant Exchange Online egress IP-pool boundary (per-tenant DMARC _dmarc.<tenant- domain> TXT-RR publication + per-tenant DKIM selector1 / selector2._domainkey. <tenant-domain> TXT-RR publication with Microsoft-operated per-tenant DKIM-signing-key custody + per-tenant SPF apex-domain include:spf.protection.outlook.com publication), the transactional-email spoke is the structural-parallel companion documenting the per-publisher per-transactional-ESP-stream DMARC alignment coordination discipline that runs ALONGSIDE the per-M365-tenant Exchange Online egress at four per- tenant per-stream alignment-coordination dimensions: (i) per-tenant per- ESP-stream DKIM-signing-key custody coordination — M365 tenants commonly integrate per-customer-stream transactional ESPs (SendGrid / Mailgun / Postmark / Amazon SES / SparkPost) for transactional traffic ALONGSIDE Exchange Online cloud-egress for staff traffic; each per-ESP-stream signs per-message DKIM headers via an ESP- managed <esp-selector>.<d-domain>. <esp-platform>.com CNAME-delegated key-publication target DISTINCT from the per-M365-tenant selector1._domainkey.<tenant- domain> key-custody THIS page documents; (ii) per- tenant SPF authority-list include- cascade vs 10-mechanism RFC 7208 §4.6.4 lookup-limit ceiling coordination — per-M365-tenant SPF records expanding include:spf.protection.outlook.com (Exchange Online egress) + include:sendgrid.net / include:mailgun.org / include:_spf.salesforce.com (per-customer-stream transactional ESP egress) face the SAME RFC 7208 §4.6.4 permerror ceiling — the per-tenant per-ESP-stream SPF-flattening / authoritative-delegation remediation pattern the transactional-email spoke documents is the cross-protocol per- publisher SPF-authority-list publication-discipline coordination ladder M365-tenants deploying multi- stream egress topology encounter; (iii) per-tenant per-stream DMARC-aligned-pass-rate observability via rua aggregate-XML per-source-IP attribution coordination — per-M365-tenant rua aggregate-XML evidence streams must distinguish Exchange Online cloud-egress shared- IP-pool members from per-customer- stream transactional-ESP egress shared-IP-pool members at the per- source-IP per-message DMARC-aligned- pass-rate-attribution boundary — the per-publisher per-stream attribution discipline the transactional-email spoke documents is the LOAD-BEARING per-tenant per-stream observability discipline every per-M365-tenant deployment with multi-stream egress topology depends on at the per-tenant rua aggregate-XML record-level boundary; (iv) per-tenant Trusted-ARC-Sealer-vs-transactional- ESP-relay-rewriting alignment-survival coordination — when an M365 tenant routes transactional traffic through a per-customer-stream transactional ESP that REWRITES message bodies (footers, unsubscribe links, ESP-tracking pixel injection), the per-ESP-stream DKIM-Signature publication must precede the body- rewriting boundary OR the per-ESP- stream must re-sign the rewritten message body — the per-tenant per- stream body-modification-survival coordination discipline the transactional-email spoke documents is the cross-publisher DKIM-Signature- survival contract every per-M365- tenant deployment integrating with body-rewriting transactional ESPs encounters at the per-tenant per- stream DKIM-Signature-publication boundary. Read the transactional-email spoke ALONGSIDE this DMARC-for- Microsoft-365 reference whenever a per-tenant per-stream alignment- coordination discipline question emerges that crosses publisher- identity boundaries between Exchange Online cloud-egress and per-customer- stream transactional ESP egress — THIS page gives the per-M365-tenant Exchange Online cloud-egress deployment discipline, the transactional-email spoke gives the per-publisher per-stream alignment- coordination reference the per-tenant multi-stream egress topology deployment ladder bottoms out on at the per-tenant per-stream DMARC- aligned-pass-rate-attribution boundary.
• Microsoft 365 Defender portal - the operator entry point for DKIM management and Trusted ARC Sealers configuration.
• Microsoft Learn: Use DKIM to validate outbound email - the canonical primary-source Microsoft documentation for the CNAME-based DKIM configuration on Exchange Online.
• Google: Email sender guidelines - the canonical Feb 2024 bulk-sender requirements document that applies to every sender regardless of mailbox provider.
• MTA-STS policy-file byte syntax (RFC 8461 §3.2 policy-file grammar) — the M365-TENANT-MTA-STS-POLICY-FILE-AUTHORING-AT-mta-sts-PERIOD-DOMAIN-WELL-KNOWN-PATH-PUBLICATION-CONSUMER-OF-POLICY-FILE-BYTE-LAYOUT companion documenting the per-field byte-level grammar (version: STSv1 / mode: enforce|testing|none / mx: <hostname> / max_age: <seconds>) of the MTA-STS policy file the M365 tenant authors and serves at https://mta-sts.<domain>/.well-known/mta-sts.txt when extending this DMARC-side M365 deployment with the transport-security-side MTA-STS layer, across FOUR M365-tenant MTA-STS policy-authoring dimensions: (1) M365 dual canonical MX (<tenant>-com.mail.protection.outlook.com + on-prem hybrid MX) enumeration as mx:-field byte-content prerequisite — the M365 Exchange Online tenant publishes one mx: line for the EOP canonical MX (<tenant>-com.mail.protection.outlook.com) AND additional mx: lines for any on-premises hybrid Exchange MX in Centralized Mail Transport topologies; the per-line byte-syntax MUST honor the RFC 8461 §3.2 hostname grammar — any byte-syntax error in the mx:-list produces receiver-side policy-parse-failure and defaults the SMTP session to opportunistic-TLS rather than enforced-TLS; (2) M365 policy-host LF line-ending discipline at Azure-Storage-Static-Website or Azure-Front-Door hosting — the /.well-known/mta-sts.txt file served from Azure Storage Static Website or Azure Front Door MUST use LF line endings per RFC 8461 §3.2; the Azure tooling defaults to LF when files are uploaded via az storage blob upload from Bash, but PowerShell-driven uploads can accidentally introduce CRLF that produces receiver-side parse failure at the policy-fetch step; (3) M365 hybrid topology mode:-token discipline as Exchange-Online-vs-on-prem-MX divergence gate — the M365 hybrid tenant ramps from mode: testing (TLS-RPT reports delivered but no actual blocking) to mode: enforce ONLY after verifying both the EOP MX AND the on-prem hybrid Exchange MX support enforced-TLS to the same TLS-version-floor (TLS 1.2 minimum); the per-policy mode:-field byte-token is the load-bearing ramp-control signal; (4) M365 per-policy max_age: seconds-byte-value rotation-cadence discipline at tenant- offboarding or MX-renaming — the M365 tenant typically publishes max_age: 604800 (7 days) during burn-in and max_age: 1209600 (14 days) or max_age: 2419200 (28 days) at steady state; the per-policy max_age:-field byte-value controls cache duration which directly affects the rotation cadence when the M365 tenant changes the id=-tag on the _mta-sts.<domain> TXT-record (e.g., during tenant-rename or EOP-MX-rebrand events). Byte-syntax correctness across these four M365 MTA-STS policy-authoring dimensions is the load-bearing prerequisite for the transport-security closure complementing THIS DMARC-side M365 deployment.
• TLS-RPT record syntax deep dive - the M365-TENANT-TRANSPORT- LAYER-HARDENING-PUBLISHER-SIDE- DEPLOYMENT-PAIR companion reference. Where THIS page documents the M365 tenant's DMARC publication and SPF / DKIM / Exchange-Online receive- boundary configuration that protects message-layer sender identity-alignment for the tenant's mail-flow, the TLS-RPT record-syntax spoke is the authoritative reference for the publisher-side authoring step that produces receiver-side reports of the SMTP TLS handshake failures and MTA-STS policy-compliance outcomes a M365 tenant otherwise has ZERO visibility into. M365 tenant publishers SHOULD deploy TLS-RPT alongside MTA-STS as the transport-layer-hardening publisher-side observability pair — mta-sts.<domain> policy file at /.well-known/mta-sts.txt with version: STSv1 + mode: enforce|testing|none + mx: M365-EOP- allow-list + max_age:, plus the _mta-sts.<domain> TXT-record with v=STSv1 + id=, plus the _smtp._tls.<domain> TXT-record with v=TLSRPTv1 + rua=mailto:/ rua=https: report-endpoint declaration. The TLS-RPT record-syntax spoke documents the publisher-side authoring step (the v=TLSRPTv1 version-tag mandatory-first, the rua=mailto: and rua=https: endpoint forms with multiple- comma-separated semantics, the trailing-; terminator-not-separator semantics per RFC 8460 §3.2, the canonical publication- pre-MTA-STS-deployment ordering — publish TLS-RPT FIRST as a 1-week baseline observability tier BEFORE publishing the MTA-STS policy file with mode: testing → mode: enforce transition) that gives the M365 tenant publisher SILENT- TRANSPORT-FAILURE OBSERVABILITY the M365 admin console alone does not provide — receiver- side failure-class JSON reports arrive daily at the publisher's rua= endpoint cataloguing per-receiver SMTP TLS handshake failures (starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, validation-failure, sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid), each of which the M365 admin would otherwise NEVER SEE (failed-TLS messages get bounced or downgraded silently without surfacing in the tenant message-trace UI). Read the TLS-RPT record-syntax spoke alongside this M365 DMARC deployment page when authoring the tenant's full DNS-record inventory and publisher-side observability runbook — DMARC publication on _dmarc.<domain> gives message-layer alignment observability, TLS-RPT publication on _smtp._tls.<domain> gives transport-layer encryption-and-policy observability, and joint deployment is the defensible defense-in-depth posture for any M365 tenant whose threat model includes silent- downgrade or man-in-the- middle attacker scenarios at the SMTP transport layer below the message- authentication layer this page configures.
• DKIM canonicalization — the M365-TENANT-EOP-POST-SIGNING-BODY- MODIFICATION-PIPELINE-CANONICALIZATION- CHOICE companion to this M365 DMARC deployment reference. Where THIS page documents the Exchange Online tenant's canonical `include:spf.protection.outlook.com` SPF publication + selector1/selector2 CNAME-delegated DKIM publication + the EOP-mediated outbound signing pipeline, the DKIM-canonicalization spoke is the PER-MESSAGE BODY-AND-HEADER CANONICALIZATION choice whose `c=` tag value (the four RFC 6376 §3.4 combinations: `simple/simple`, `simple/relaxed`, `relaxed/simple`, `relaxed/relaxed`) is the load-bearing DKIM-signature SURVIVAL primitive at FOUR Exchange Online Protection mutation classes the M365-signed outbound message traverses before reaching the receiver: (i) EOP DISCLAIMER + LEGAL-FOOTER INJECTION at the tenant-configured Exchange transport-rule layer modifies the message body POST-DKIM-SIGNING — when the M365 tenant configures Exchange transport rules to append a corporate legal disclaimer or compliance footer to outbound mail, EOP's body modification happens AFTER the outbound DKIM signing — `c=simple/simple` body canonicalization will FAIL bh= body- hash verification at the receiver because the byte sequence has changed; only `c=*/relaxed` body canonicalization (which applies the §3.4.4 whitespace + trailing- line normalization rules) survives certain footer-injection patterns; (ii) EOP SAFE LINKS rewrites HTTP/HTTPS URLs in the message body to `https://<tenant>.safelinks.protection.outlook.com/...` wrapped redirector URLs POST-DKIM-SIGNING — Safe Links rewriting is a tenant- configurable feature that modifies the message body AFTER outbound DKIM signing for inbound mail and AFTER inbound DKIM verification for outbound mail; the canonicalization choice determines whether the receiver's DKIM-Signature verification survives the per-URL rewrite — `c=*/simple` body canonicalization treats every byte as signed, while `c=*/relaxed` body canonicalization is also defeated by URL rewrites because the rewrite changes meaningful (non-whitespace) bytes; (iii) EOP HEADER REWRITING at the connector boundary (Received: header addition, X-MS-Exchange-* header insertion, Authentication-Results stamping) MODIFIES THE HEADER BLOCK POST-DKIM- SIGNING — the canonicalization choice on the HEADER half of the `c=` tag value determines whether header modifications survive: `c=relaxed/*` header canonicalization (§3.4.2) applies header- name lowercasing + whitespace folding + trailing whitespace strip, surviving most EOP header insertions because EOP-added headers are NOT in the signed `h=` list; `c=simple/*` header canonicalization (§3.4.1) preserves header bytes verbatim but ALSO only verifies the `h=`-listed headers, so header additions also survive — the canonicalization choice difference manifests only when EOP REWRITES an existing signed header (rare but possible with certain transport rules); (iv) HYBRID EXCHANGE TOPOLOGY ON-PREM- EXCHANGE-OUTBOUND-VIA-EOP-CONNECTOR INTRODUCES A SECOND POST-SIGNING MUTATION HOP — when the M365 tenant runs hybrid Exchange (on-prem Exchange routing outbound mail through Exchange Online's outbound connector to the internet), the on-prem Exchange's DKIM signing happens FIRST, then EOP's outbound connector hop applies a SECOND round of potential body/header modification before the message reaches the internet receiver — the canonicalization choice must survive BOTH the EOP connector mutation AND any post-EOP receiver-side intermediary modification (mailing-list rewrites, SaaS-tenant inbound filtering, ARC- sealing chain modifications). Read the DKIM-canonicalization spoke alongside this M365 DMARC deployment reference when authoring the tenant's outbound DKIM-signing configuration — the spoke is the canonical RFC 6376 §3.4 reference whose four canonicalization combinations determine the M365-tenant-signed message's per-receiver DKIM-pass rate against the EOP-mediated post-signing body and header modification pipeline the tenant's Exchange transport rules + Safe Links + connector topology together produce.
• DMARC for SaaS senders — the per-M365-tenant-as-SaaS-customer- of-external-marketing-and-transactional- ESP-platforms-downstream-consumer companion to this Microsoft-365-tenant DMARC deployment reference. Where THIS page documents the M365-TENANT-AS-CLOUD- MAILBOX-PROVIDER deployment topology (the canonical include:spf.protection.outlook.com SPF mechanism + the EOP-managed selector1._domainkey / selector2._domainkey DKIM CNAME publication + the M365 Admin Center-driven _dmarc publication + connector configuration workflow), the SaaS-senders spoke documents the structurally-distinct PER-SAAS-PROVIDER-AS-MULTI-TENANT-ESP- PLATFORM deployment shape in which the per-M365-tenant is the per-customer consumer of one or more external marketing-ESP / transactional-ESP / notification-platform SaaS providers (Mailchimp / SendGrid / Mailgun / Klaviyo / Brevo / Twilio / Stripe- billing-emails / GitHub-notifications) whose per-customer SPF-include cascade + per-customer-CNAME-delegated DKIM signing + per-customer subdomain delegation must be coordinated WITH the per-M365-tenant include:spf.protection.outlook.com cascade and the EOP-managed DKIM selectors. Read the SaaS-senders spoke alongside this M365-tenant deployment reference when the per-tenant outbound mail-flow includes external SaaS- platform-relayed mail (marketing newsletters, transactional notifications, billing receipts) — the per-M365-tenant SPF-include budget under RFC 7208 §4.6.4 10-DNS-lookup cap is the load- bearing budget every per-SaaS-customer additional include: token consumes, the per-M365-tenant _dmarc publication is the load-bearing per-tenant alignment- verdict surface every per-SaaS-sender per-customer-CNAME-delegated DKIM signature must produce dkim=pass + dkim-aligned=true against, and the per-M365-tenant subdomain-policy sp= publication is the load-bearing subdomain-scoped policy every per- SaaS-customer delegated subdomain (mail.<tenant>, news.<tenant>, billing.<tenant>) inherits when the per-SaaS-platform per-customer-onboarding workflow publishes the per-customer dedicated sending subdomain.
• DMARC monitoring — the M365-TENANT-AS-BIDIRECTIONAL- PER-EOP-RECEIVE-SIDE-AND-EXCHANGE-ONLINE- OUTBOUND-SIDE-DMARC-MONITORING-CONSUMER- AND-PRODUCER companion documenting how the per-M365-tenant DMARC publication discipline this deployment guide documents BOTH emits per-message DMARC-aggregate-XML rows the per-domain monitoring KPI dashboard ingests for the tenant's outbound-from-Exchange-Online mail-stream AND consumes per-message DMARC-aggregate-XML rows from external receivers (Gmail, Yahoo, Comcast, GMX, Mail.ru) for the tenant's outbound-from- third-party-ESPs mail-stream that doesn't flow through Exchange Online. Where THIS M365 deployment guide documents the per- tenant _dmarc.<onmicrosoft- verified-domain> TXT-RR publication discipline, the per-tenant Exchange Online inbound-EOP DMARC evaluator behaviour, the per-tenant Exchange Online outbound DKIM-signing infrastructure with rotating selector1 / selector2 CNAME publication, and the per-tenant rua=-mailbox publication for aggregate-XML ingestion, the DMARC monitoring spoke is the per-domain AGGREGATE-VIEW reference whose KPI cohort consumes the per-tenant per-message verdict catalogue this M365 deployment guide produces at four M365-tenant- deployment-to-monitoring-KPI-aggregation coupling dimensions: (i) per- Exchange-Online-Protection receive-side per-message verdict → per-domain receive-side DMARC-pass-rate KPI as load-bearing M365-tenant inbound-mail- flow observability contract — every per-message inbound-EOP DMARC evaluation outcome (Authentication-Results emitted by Exchange Online Protection's inbound-DMARC-evaluator for mail delivered to a per-M365-tenant inbox) contributes a per-message verdict row the per-domain DMARC monitoring KPI dashboard surfaces; the per-Exchange- Online-Protection-receive-side per- sender-domain verdict distribution surfaces external senders sending DMARC-fail mail to the M365 tenant's recipients at the operationally- observable boundary; (ii) per- Exchange-Online outbound per-message verdict (as seen from external receivers) → per-domain outbound DMARC-pass- rate KPI as load-bearing M365-tenant outbound-mail-flow observability contract — every per-message outbound DMARC verdict an external receiver (Gmail, Yahoo, Mail.ru, GMX) emits for mail originating from the M365 tenant's Exchange Online infrastructure produces a per-message verdict row in the external-receiver's per-recipient-domain aggregate-XML report the per-tenant rua=-mailbox ingests; the per-recipient-receiver per-source-IP verdict distribution is the canonical KPI the monitoring spoke surfaces for per-tenant Exchange-Online-outbound DKIM-signing-infrastructure health (per-source-IP DKIM-aligned-pass-rate against the per-tenant selector1 / selector2 CNAME chain) and for SPF authorisation publication completeness (per-source-IP SPF-pass- rate against the per-tenant include:spf.protection.outlook.com publication); (iii) per-third- party-ESP outbound per-message verdict → per-third-party-source-IP DMARC- alignment-rate KPI as load-bearing per- M365-tenant third-party-sender-inventory completeness regression detector — the per-M365-tenant rua=- mailbox-ingested aggregate-XML stream catalogues per-third-party-ESP source-IP space (Salesforce Marketing Cloud, SendGrid, Mailchimp, HubSpot, Adobe Campaign, Marketo) the M365-tenant's per-domain DMARC publication must authorise via include:- cascade additions; the per-third-party- source-IP DMARC-alignment-rate distribution is the canonical signal the monitoring spoke surfaces for per- third-party-sender onboarding completeness — every M365-tenant adding a new third- party ESP MUST audit the per-source-IP DMARC-alignment-rate convergence in the monitoring KPI dashboard before committing to the next enforcement- policy tightening; (iv) per- message DMARC verdict series → 90-day per-M365-tenant DMARC-pass-rate trend as load-bearing enforcement- readiness gate — the per-M365- tenant 90-day DMARC-pass-rate trend the monitoring spoke tracks across the rolling window is the load-bearing enforcement-readiness gate the per- M365-tenant rollout discipline (p=none → p=quarantine → p=reject with pct= ramp) consumes to determine whether the per-tenant outbound-from-Exchange-Online + outbound-from-third-party-ESPs authentication infrastructure is stable enough — across every legitimate- sender's source-IP space — to commit to the next enforcement-policy tightening; the per-tenant 90-day DMARC-pass-rate convergence pattern is the canonical signal the monitoring spoke surfaces to M365-tenant operators evaluating the per-tenant readiness for the Feb 2024 Gmail/Yahoo bulk-sender enforcement-deadline-compliance posture and the next p=-stage commitment. Read the DMARC monitoring spoke alongside this M365 deployment guide when scoping per-M365-tenant per- domain bidirectional (receive-side + outbound-side) observability, per-third- party-ESP source-IP DMARC-alignment- rate surveillance, per-Exchange-Online infrastructure regression detection, and 90-day per-M365-tenant DMARC-pass-rate convergence analysis for the per-tenant DMARC enforcement-ramp gate.
• DKIM for Google Workspace — the GOOGLE-WORKSPACE-TENANT-DKIM-AT- google-DOMAINKEY-DIRECT-TXT-RR-PUBLICATION- VS-M365-TENANT-DKIM-AT-selector1-AND- selector2-DOMAINKEY-CNAME-POINTER-PUBLICATION- CROSS-CLOUD-PUBLICATION-TOPOLOGY-ASYMMETRY companion reference. Where THIS page documents the M365-tenant DMARC deployment topology (per-tenant selector1._domainkey.<d> and selector2._domainkey.<d> CNAME pointers to Microsoft-managed selector1-<tenant>._domainkey.<tenant>.onmicrosoft.com / selector2-<tenant>._domainkey.<tenant>.onmicrosoft.com hostnames, the Microsoft 365 Defender portal DKIM-enablement workflow, the PowerShell Rotate-DkimSigningConfig -KeySize 2048 rotation orchestration), the dkim-for-google-workspace spoke is the STRUCTURALLY-PARALLEL Workspace-tenant publication-topology reference whose WORKSPACE-tenant DKIM-publication primitives are STRUCTURALLY-DISTINCT from the M365-tenant DKIM-publication primitives THIS page documents — the cross-cloud publication-topology asymmetry across four Workspace-vs-M365 publication-topology coupling dimensions every cross-cloud DMARC-deployment-architect must understand: (i) Publication topology primitive asymmetry — M365 CNAME-pointer publication vs Workspace direct TXT-RR publication — M365 publishes DKIM keys via per-tenant CNAMEs pointing at Microsoft-managed onmicrosoft.com hostnames (the actual public-key TXT-RR lives at the Microsoft-managed hostname the operator's CNAME dereferences to), whereas Workspace publishes DKIM keys DIRECTLY as a TXT record at google._domainkey.<d> in the publisher's own DNS zone (no CNAME indirection; the public-key lives at the operator's apex zone) — the per-tenant DNS-zone-management cost-and-control boundary is materially different across the two clouds; (ii) Default d=-tag emission asymmetry — M365 onmicrosoft.com default-emission DEFEATS adkim=r vs Workspace vanity-domain default-emission PASSES adkim=r — M365's default out-of-box DKIM-Signature emission uses <tenant>.onmicrosoft.com as the d=-tag value (which DEFEATS the adkim=r relaxed- mode alignment evaluation THIS page documents); Workspace's default emission uses the vanity domain as the d=-tag value at the Gmail outbound DKIM-signer (which PASSES adkim=r out-of-box); the operator-side enablement workflow is therefore STRUCTURALLY DIFFERENT across the two clouds (M365 requires the Defender portal DKIM-management panel toggle for the protected vanity domain; Workspace requires only the Admin Console "Authenticate email" wizard); (iii) Key-strength upgrade discipline asymmetry — M365 PowerShell Rotate- DkimSigningConfig vs Workspace Admin Console "Generate new record" — both clouds ship 1024-bit RSA as the out-of-box default (deprecated per RFC 8301 §3); the per-tenant operator upgrade-to-2048-bit RSA discipline is executed via STRUCTURALLY-DIFFERENT operator interfaces (M365: PowerShell Rotate-DkimSigningConfig -KeySize 2048 cmdlet; Workspace: Admin Console > Apps > Google Workspace > Gmail > Authenticate email > Generate new record with 2048-bit option explicitly selected); (iv) Rotation orchestration interface asymmetry — M365 Defender portal + PowerShell vs Workspace Admin Console-only — M365 dual- selector rotation orchestration uses the Rotate-DkimSigningConfig PowerShell cmdlet for the selector1-to- selector2 cutover at the Microsoft-managed signing infrastructure, whereas Workspace per-selector rotation uses the Admin Console's per-selector-namespace rotation (google → google2 → google3 per-rotation-cycle selector-name increment); the cross-cloud operator-skillset overlap is the dual- selector overlap-window discipline both clouds materialise (M365 via fixed selector1/selector2 dual-selector emission pattern; Workspace via per-rotation selector-namespace increment). Read the dkim-for-google-workspace spoke ALONGSIDE this M365-tenant DMARC reference whenever the cross-cloud DMARC deployment architecture must coordinate per-tenant per-cloud DKIM-publication-topology choices — most commonly when a protected vanity domain has BOTH M365 Exchange Online and Google Workspace tenants signing outbound mail at the SAME author-domain From: header (the dual-cloud signing-deployment topology surfaced in cross-cloud DMARC- aligned-pass-rate variance at the rua aggregate-XML row-level granularity).
• Email Header Analyzer - paste any email's headers and see SPF, DKIM, DMARC, and ARC results.
• Domain Security Checker - live DNS lookups for every email- authentication record on a domain. Surfaces the live SPF lookup count, the published DKIM selectors (including selector1 / selector2 CNAMEs), and the DMARC policy state.
• DNS Record Generator - SPF / DKIM / DMARC / TLS-RPT / MTA-STS / CAA / BIMI record wizards.
• DMARC Analyzer Dashboard - ingests M365-receiver aggregate reports and surfaces the per-sender / per-IP / per-day breakdown via includes/DmarcParser.php.
• DMARC troubleshooting — the M365-TENANT-DMARC-FAILURE-PATTERN- DIAGNOSTIC-LADDER-CONSUMER companion to this M365-tenant deployment reference. Where THIS page documents the per-M365- tenant deployment workflow (selector1 / selector2 CNAME-publication discipline + Defender-portal DKIM-enablement + Rotate-DkimSigningConfig PowerShell rotation discipline + per-tenant SPF include:spf.protection.outlook.com publication + per-tenant _dmarc.<d> record with rua= + adkim/aspf tag publication), the dmarc- troubleshooting spoke is the OPERATOR- FACING DIAGNOSTIC-LADDER reference whose four canonical Pattern-1-through-Pattern-4 ladders intersect with M365-tenant-specific deployment surfaces at four diagnostic- ladder-intersection dimensions: (i) Pattern 1 SPF-aligned-pass- regression diagnostic ladder × M365-tenant spf.protection.outlook.com include cascade — when a per-M365-tenant per-domain rua aggregate-XML stream surfaces a per-source-IP cohort with policy_evaluated.spf=fail, the Pattern-1 ladder walks the M365 operator through the include:spf.protection. outlook.com cascade evaluation, the 10-lookup budget consumed by the Microsoft-published include cascade, and the per-tenant SPF record's residual budget for vendor includes (the M365-tenant-specific cascade depth differs from on-prem-Exchange-publisher tenants and requires the operator to scope the SPF flattening discipline accordingly); (ii) Pattern 2 forwarder-hop-alignment-loss diagnostic ladder × M365-tenant inbound Exchange Online ARC trust list — when the Pattern-2 ladder surfaces a per-forwarder- hop alignment-loss, the M365-tenant-side Exchange Online Trusted ARC Sealers configuration (Set-ArcConfig PowerShell cmdlet, the per-tenant trusted-sealer-list operational discipline) is the load-bearing receiver-side remedy primitive; the troubleshooting spoke walks the operator through the per-forwarder-class catalogue (mailing-list expanders, .forward / Sieve forwarders, vacation-redirect rules) and the per-class trust-list-extension decision; (iii) Pattern 3 DKIM-alignment- pass-failure diagnostic ladder × M365- tenant selector1/selector2 + Defender- portal enablement — when the Pattern-3 ladder walks the operator through the DKIM-alignment-failure root cause catalogue (selector-publication gap, Defender-portal-not-yet-enabled, key- rotation-mid-flight cutover gap, d=-tag emission-default-onmicrosoft.com vs vanity-domain divergence), the diagnostic- ladder reference cross-links back to THIS page's selector1/selector2 CNAME-publication + Defender-portal enablement + 2048-bit RSA Rotate-DkimSigningConfig PowerShell rotation discipline as the per-M365-tenant DKIM-publication primitives the diagnostic ladder evaluates against; (iv) Pattern 4 per-source-IP-cohort-attribution diagnostic ladder × M365-tenant EOP-hourly-rolling- window rua-emission cadence — when the Pattern-4 ladder walks the operator through the per-source-IP-cohort attribution boundaries, the M365-tenant-specific EOP hourly-rolling-window rua-emission cadence (distinct from Gmail / Yahoo / Mail.ru's 24-hour UTC-aligned batch cadence) is the cadence-disambiguator the operator consumes when scoping per-day vs per-hour evidence-row attribution windows for per-M365-tenant per-source-IP cohort attribution. Read the troubleshooting spoke ALONGSIDE this M365- tenant deployment reference whenever the per-M365-tenant rua aggregate-XML stream surfaces an unexpected per-source-IP-cohort disposition shift — the M365-tenant deployment surfaces THIS page documents are the publication primitives, the diagnostic ladders the troubleshooting spoke documents are the operator-facing ladders that walk from observed regression to publication- primitive root cause in this M365-tenant deployment reference.
• TLS-RPT explained — every M365 accepted domain publishes a _smtp._tls.<domain> TXT record advertising the rua=mailto: endpoint where downstream MTAs deliver per-day aggregate JSON reports describing TLS negotiation outcomes against *.mail.protection.outlook.com inbound MX. The transport-layer observability stream is a peer to the application-layer DMARC RUA stream the M365 deployment guide already documents — joint adoption gives per-tenant per-domain dual-leg evidence for both authentication-and-encryption posture against silent TLS downgrade and certificate-mismatch regressions across the tenant's hybrid or cloud-only egress topology.
• DANE explained — the PER-M365-TENANT-DANE-TLSA-RR-PUBLICATION companion to this M365-tenant DMARC deployment reference. Where THIS page documents the per- M365-tenant per-domain DMARC enforcement and the per-tenant MTA-STS PKIX-chain validation publication, the DANE-explained spoke is the DNSSEC-backed per-MX cryptographic-fingerprint transport-layer authentication peer protocol whose per-M365-tenant inbound MX-side TLSA RR publication (_25._tcp.<mx>. <tenant>) provides the cryptographic chain-of-trust attestation per-sending peer receivers consult on every per-message inbound SMTP TLS handshake. Joint per-M365-tenant MTA- STS + DANE deployment forms the per-publisher per-domain DUAL-LEG transport-layer authentication posture (MTA-STS = WebPKI-anchored CA-allowlist + max-age policy; DANE = DNSSEC-anchored per- MX cryptographic-fingerprint binding) that defeats per-receiver opportunistic-TLS downgrade and per-MX certificate-substitution attacks at the per-tenant transport-layer attack-surface boundary the application-layer DMARC composite verdict THIS page documents STRUCTURALLY DEPENDS on as the per-message transport-layer integrity floor.
• SPF PermError vs TempError Four per-M365-tenant SPF-error-mode root-cause dimensions: (i) per-M365-tenant include:spf.protection.outlook.com + supplementary third-party-ESP include: tokens producing permerror from RFC 7208 §4.6.4 ten-DNS-query budget exhaustion — every M365 tenant publishes include:spf.protection.outlook.com as the foundational Exchange Online outbound-authorisation token, which consumes 3-4 DNS queries depending on the per-region M365-tenant SPF-cascade expansion (typical: 3 DNS queries for `spf.protection.outlook.com` + per-region nested includes), leaving 6-7 DNS queries for supplementary per-tenant third-party-ESP include: tokens (SendGrid / Mailgun / Amazon SES / Postmark / Salesforce / Marketo / Pardot) before per-receiver evaluation produces spf=permerror — the #1 SPF=permerror root-cause class in M365 deployments observed in production-scale RUA streams; (ii) per-M365-tenant hybrid-Exchange dual-egress (on-prem ETA + Exchange Online cloud) requiring concurrent SPF authoring discipline across both egress paths producing permerror from RFC 7208 §3.2 one-SPF-record-per-domain constraint violation — the per-M365-hybrid-tenant operator must publish a SINGLE SPF record at the per-customer-domain apex that authorises BOTH the on-prem ETA outbound IP-pool (per-tenant supplementary ip4:<on-prem-CIDR>) AND the Exchange Online cloud egress (include:spf.protection.outlook.com), and a per-tenant authoring-discipline lapse that produces TWO SPF records (one published by the on-prem Exchange admin, one published by the M365 admin) is interpreted by per-receiver evaluators as RFC 7208 §3.2 violation producing permerror; (iii) per-M365-tenant onmicrosoft.com tenant-default-domain producing spf=pass + dmarc=fail evidence pattern requiring per-tenant primary-domain configuration discipline — when per-M365-tenant operators leave the per-tenant default-egress domain at <tenant>.onmicrosoft.com instead of configuring the per-customer-domain as the accepted-domain default, outbound messages SPF-pass at the onmicrosoft.com envelope-MAIL-FROM boundary while the per-message From: header carries the per-customer-domain producing dmarc=fail — a per-tenant SPF=pass-but-DMARC=fail RUA-row evidence class the per-M365-tenant operator must diagnose using the SPF-permerror-vs-temperror operator-side-vs-receiver-side root-cause attribution discipline; (iv) per-M365-tenant DMARC ramp gating on per-source-IP spf=permerror/temperror RUA-row attribution discipline — the per-M365-tenant DMARC ramp (p=none → p=quarantine pct=10/25 → p=reject) gating on per-tenant per-receiver per-source-IP RUA evidence requires per-row attribution of spf=permerror rows (operator-side investigation required — typically multi-ESP include-chain over budget) vs spf=temperror rows (transient receiver-side DNS-resolver outage, likely self-resolving) to avoid stalling the per-tenant ramp on per-row evidence that does not require per-tenant operator-side remediation. Read the SPF-permerror-vs-temperror spoke alongside this DMARC-for-M365 reference when investigating per-M365-tenant per-customer-domain RUA-attributed spf=permerror rows, when planning the per-M365-tenant SPF include-chain expansion against the RFC 7208 §4.6.4 ten-DNS-query budget (typically requiring per-tenant SPF flattening / subdomain-delegation / sender-consolidation remediation), or when authoring the per-M365-tenant DMARC-ramp playbook with concurrent SPF-error-mode RUA-row attribution discipline.
• SPF qualifiers (+ Four per-M365-tenant qualifier-ramp coupling dimensions: (i) per-M365-tenant SPF Phase 1 monitoring publication with ~all-soft terminal qualifier as DMARC p=none observation-only coordination — when the per-M365-tenant operator begins Phase 1 observability deployment (rua=mailto: publication + p=none + per-source-IP RUA evidence collection), the per-tenant SPF posture publishes v=spf1 include:spf.protection.outlook.com ~all as the soft per-message envelope-authorization declaration that allows downstream receivers to quarantine SPF-fail messages without hard-rejection — a per-tenant per-customer-domain authentication-publication-strength-floor that minimizes per-message deliverability disruption during the observation window; (ii) per-M365-tenant SPF Phase 3 partial-enforcement with ~all-soft retained during DMARC p=quarantine pct=10/25 ramp — through Phase 3 the per-M365-tenant SPF terminal qualifier remains ~all-soft to avoid per-message envelope-authorization hard-rejection at receivers that pre-evaluate SPF strictly BEFORE consulting the per-message DMARC composite verdict; the per-message DMARC composite verdict gating per-publisher per-domain quarantine-disposition takes precedence over per-message SPF-fail-strict at the per-receiver evaluator; (iii) per-M365-tenant SPF Phase 5 terminal upgrade from ~all-soft to -all-strict concurrent with DMARC p=reject pct=100 — the per-M365-tenant operator coordinates the per-message envelope-authorization-strictness terminal upgrade from ~all SoftFail to -all Fail concurrent with the per-publisher per-domain DMARC terminal upgrade to p=reject pct=100, declaring per-tenant per-customer-domain terminal authentication-publication strictness at both per-protocol enforcement boundaries simultaneously; (iv) per-M365-tenant onmicrosoft.com-default-domain SPF posture vs per-customer-domain SPF qualifier-strictness divergence — when the per-M365-tenant operator retains the onmicrosoft.com-default-egress posture, the per-tenant SPF strictness at <tenant>.onmicrosoft.com is governed by Microsoft's per-tenant defaults (not user-controlled), while per-customer-domain SPF strictness is per-tenant-operator-controlled — the per-tenant operator must coordinate per-customer-domain qualifier-strictness ramp to align with per-tenant DMARC enforcement-posture, with the per-tenant default-egress posture as the floor. Read the SPF-qualifiers spoke alongside this DMARC-for-M365 reference when planning the per-M365-tenant SPF qualifier-strictness ramp progression concurrent with the per-M365-tenant DMARC policy ramp, when authoring per-M365-tenant runbooks coordinating per-customer-domain SPF qualifier strictness with per-customer-domain DMARC p=/pct= settings, or when investigating per-M365-tenant per-customer-domain authentication-publication strictness divergence between per-tenant default-egress posture and per-customer-domain user-published posture.
• RFC 7489 - DMARC
• RFC 7208 - SPF
• RFC 6376 - DKIM
• RFC 8617 - ARC (Authenticated Received Chain) - the protocol Trusted ARC Sealers implements.
• RFC 8058 - One-Click List-Unsubscribe - required by the Feb 2024 bulk-sender rules.
• SPF forwarding issues — the canonical operator-side SPF-forwarding-issue remediation reference whose per-forwarder envelope-rewrite + SRS + ARC-rescue remediation playbook is the load- bearing downstream-of-Exchange- Online-recipient-forwarding-rule evaluation reference THIS M365- tenant deployment page documents depends on at four M365-tenant-to- SPF-forwarding-remediation resolution dimensions: (i) the per-M365-recipient inbox-rule "Forward to external address" evaluation discipline is the canonical load-bearing per-tenant downstream producer of the per- forwarder envelope-rewrite diagnostic — Exchange Online's per-recipient inbox-forward rule re-emits the message from Exchange Online's per-region outbound IP pool (the spf.protection.outlook.com include-cascade authorised range) but preserves the upstream publisher's envelope MAIL FROM, which the downstream third-party receiver evaluates against the UPSTREAM publisher's apex SPF (NOT Microsoft's) and emits spf=fail; (ii) the per-M365-tenant Sender Rewriting Scheme (SRS) discipline — Exchange Online activates per-recipient forwarding-rule SRS rewrite when the per-tenant "OutboundConnector with SenderRewritingEnabled" or the per-tenant transport rule's modify-recipient action is in effect — is the load-bearing per-tenant remediation discipline the SPF-forwarding-issues reference documents as the canonical Exchange-Online-side SRS-rewrite-attribution path; (iii) the per-M365-tenant Trusted ARC Sealer publication discipline is the canonical M365-side ARC-chain- rescue mechanism — Exchange Online consumes Trusted ARC Sealer signatures from the per-tenant- published trusted-sealer-list when an upstream forwarder ARC-seals the per-message Authentication- Results, rescuing dkim-pass + spf-pass verdicts that would otherwise emit spf=fail-with- aligned=false the SPF-forwarding- issues reference catalogues; and (iv) the per-M365-tenant bidirectional forwarding-scenario coverage discipline (per-tenant outbound-direction forwarding to third-party receivers + per-tenant inbound-direction reception of forwarded mail from upstream forwarders + per-tenant intra- organisational mailbox-forwarding- rule cascade) is the load-bearing per-tenant operations-coordination framework the SPF-forwarding- issues reference documents at full bidirectional coverage — from per-tenant Exchange Online egress SPF-authorisation to per-tenant Exchange Online inbound Authentication-Results-emission for ARC-rescued forwarded mail. Read the SPF-forwarding-issues spoke ALONGSIDE this M365-tenant deployment reference whenever the per-tenant admin scopes a per- tenant forwarding-scenario operations playbook — the per- tenant Exchange Online inbox-rule + Connector + Trusted ARC Sealer publication discipline THIS page documents IS the canonical M365- side load-bearing producer infrastructure the per-forwarder envelope-rewrite + SRS + ARC- rescue remediation playbook the SPF-forwarding-issues reference structurally consumes.
• DKIM-Signature header tag anatomy — the per-message HEADER companion to this M365-tenant DKIM CNAME-delegated signing deployment guide. Where THIS page documents the per-tenant CNAME delegation cascade (selector1._domainkey / selector2._domainkey at the customer-domain pointing at the Microsoft-managed key-zone), the DKIM-Signature-header anatomy reference documents the per-message header EOP actually emits at signing-time — the v= / a= / c= / d= / s= / h= / bh= / b= tag layout, the canonicalization choice EOP applies (relaxed/relaxed by default), and the signed-header-list EOP commits to. Read the DKIM-Signature-header anatomy reference whenever a per-M365- tenant operator needs to decode a specific message's DKIM-Signature header from the Authentication- Results header or a captured AFRF forensic payload — the per-tenant CNAME-delegated deployment workflow THIS page documents IS the upstream publication discipline that produces the per-message DKIM-Signature headers the anatomy reference decodes.
• BIMI explained — the M365-TENANT-BIMI-DEPLOYMENT- WITH-OUTLOOK-LIGHT-BIMI-RECEIVER-AS- DOWNSTREAM-CONSUMER-OF-M365-TENANT- DMARC-ENFORCEMENT-BASELINE companion documenting the per-M365-tenant BIMI deployment workflow at the per-tenant per-accepted-domain default._bimi.<domain> IN TXT "v=BIMI1; l=<logo-URL>; a=<VMC-URL>" publication boundary across four M365-tenant-BIMI- deployment-coupling dimensions: (i) per-M365-tenant-per-accepted- domain-DMARC-enforcement-baseline-as- per-M365-tenant-BIMI-eligibility- precondition — BIMI logo- display eligibility at Outlook / Outlook.com / Microsoft 365 BIMI- consuming receivers requires per- M365-tenant per-accepted-domain DMARC enforcement at p=quarantine or p=reject with pct=100 per BIMI draft §5; the per-M365-tenant DMARC deployment workflow THIS page documents (the per-tenant per- accepted-domain _dmarc.<accepted-domain> IN TXT "v=DMARC1; p=...; rua=...; sp=...; adkim=...; aspf=..." publication at the per-tenant DNS zone-editor boundary) IS the per- M365-tenant per-accepted-domain BIMI eligibility precondition; (ii) per-M365-tenant-per-accepted- domain-DKIM-CNAME-delegation-pattern- as-load-bearing-per-M365-tenant-per- message-DKIM-aligned-pass-rate-floor- determinant-of-BIMI-eligibility — per-M365-tenant per-accepted-domain DKIM publication via Microsoft-managed per-tenant CNAME-delegated DKIM- signing selectors (the per-tenant Microsoft-managed selectors selector1._domainkey.<accepted- domain> / selector2._domainkey.<accepted- domain> CNAME-redirected to Microsoft-managed selectorN-<tenant-id>._domainkey.<tenant-onmicrosoft-com> public-key publication endpoints) IS the per-M365-tenant per-message DKIM- aligned-pass-rate floor determinant whose green-state baseline IS the per- M365-tenant per-accepted-domain DMARC- aligned-pass-rate baseline IS the per- M365-tenant per-accepted-domain BIMI eligibility baseline; (iii) per-M365-tenant-per-accepted- domain-BIMI-TXT-RR-publication-at-the- per-tenant-DNS-zone-editor-boundary- as-per-tenant-BIMI-record-publication- discipline — per-M365-tenant per-accepted-domain BIMI TXT-RR publication requires per-tenant DNS zone-editor coordination at the per- tenant per-accepted-domain authoritative DNS zone publication boundary (typically GoDaddy / Route 53 / Cloudflare / Microsoft-managed Azure DNS zones the per-tenant per- accepted-domain authoritative DNS zone is hosted at); per-M365-tenant per-accepted-domain default._bimi.<accepted- domain> TXT-RR publication IS coordinated WITH the per-tenant per-accepted-domain SVG-Tiny-PS-logo publication at the l=-URL HTTPS endpoint AND with the per-tenant per-accepted- domain VMC publication at the a=-URL HTTPS endpoint; (iv) per-M365-tenant-per- accepted-domain-Outlook-BIMI-logo- display-as-load-bearing-per-tenant- BIMI-deployment-validation-primitive — per-M365-tenant per-accepted-domain Outlook / Outlook.com / Microsoft 365 BIMI-logo-display at the receiver-side is the per-tenant per- accepted-domain BIMI deployment validation primitive operators consume to confirm per-tenant per- accepted-domain BIMI logo-publication operational correctness; per-M365- tenant per-accepted-domain BIMI- logo-display absence at Outlook receivers signals per-tenant per- accepted-domain BIMI publication discipline defect (per-tenant per- accepted-domain BIMI TXT-RR byte- grammar defect, per-tenant per- accepted-domain SVG-Tiny-PS-logo non-conformance, per-tenant per- accepted-domain VMC trust-chain defect, per-tenant per-accepted- domain DMARC-enforcement baseline regression). Read THIS page when DEPLOYING per-M365-tenant per- accepted-domain DMARC enforcement; read the BIMI-explained spoke when EXTENDING the per-M365-tenant per- accepted-domain DMARC-enforcement baseline to per-M365-tenant per- accepted-domain BIMI logo-publication eligibility at the Outlook BIMI- consuming receiver boundary.
• DKIM selectors explained (RFC 6376 §3.1) — the PER-M365-TENANT-DKIM-SELECTOR- IDENTIFIER companion to this M365 deployment guide. Where THIS page documents the per-M365-tenant per-accepted-domain DKIM enablement workflow (Microsoft Defender XDR > Email & collaboration > Policies & rules > Threat policies > DKIM activation that surfaces the per-tenant CNAME pair selector1._domainkey.<domain> → selector1-<domain-with- hyphens>._domainkey.<tenant>.onmicrosoft.com AND selector2._domainkey.<domain> → selector2-<domain-with- hyphens>._domainkey.<tenant>.onmicrosoft.com, the per-tenant key-rotation-cadence discipline that alternates outbound signing between selector1 and selector2), the DKIM-selectors-explained spoke is the per-publisher per-selector identifier- scheme reference documenting the RFC 6376 §3.1 selector._domainkey.<domain> naming convention, the per-selector public-key TXT-RR byte format with v=DKIM1 + k=rsa + p=<base64> tag-value structure, and the canonical per-vendor selector-naming convention (M365's selector1 / selector2 pair, Google Workspace's google selector, Mailchimp's k1 selector, SendGrid's s1 / s2 per-sub-user selectors). Read THIS page when ENABLING per-M365- tenant DKIM via Defender XDR; read the DKIM-selectors-explained spoke when UNDERSTANDING the per-selector identifier scheme that allows the per-M365-tenant primary selector1 + rotation- secondary selector2 pair to coexist at the per-accepted-domain authoritative DNS zone boundary alongside per-third-party-sender per-vendor selectors for M365-hybrid third-party senders.
• DMARC myths and misconceptions debunked — the 18-myth operator-mental-model correction catalogue covering recurring DMARC misconceptions whose protocol- layer refutations the per-protocol-pillar reference pages provide. The M365-tenant myth class this page directly engages with covers Myth 7 ("M365 SPF include is just 'add spf.protection.outlook.com'") — that single include consumes 3 of the 10 budget slots before any third-party- sender include is added; the "M365 auto-enables DKIM on every accepted domain" misconception (DKIM is per-accepted-domain opt-in via the Defender XDR DKIM-config blade and requires per-domain CNAME publication at selector1._domainkey and selector2._domainkey); and the "M365's DMARC policy applies to all our domains" misconception (DMARC publication is per-accepted- domain at the publisher's authoritative DNS zone, not Microsoft's). Read THIS M365 deployment guide alongside the myths catalogue when planning the per- accepted-domain Defender-XDR DKIM- activation + per-accepted-domain SPF- budget-management + per-accepted-domain DMARC-publication workflow.
• SPF mechanisms explained — the SPF-MECHANISM-VOCABULARY-AS-PUBLISHER- SIDE-AUTHORIZATION-VOCABULARY-PRIMITIVE companion to this Microsoft 365 tenant DMARC deployment reference. Where THIS page documents the per-M365-tenant DMARC publication discipline (the per-accepted-domain canonical v=spf1 include:spf.protection.outlook.com -all SPF baseline, the per-tenant Exchange Online Protection (EOP) receive-side DMARC evaluation, the Defender XDR DKIM- config blade auto-rotation and CNAME- delegation discipline, the per-accepted- domain organisational-domain onmicrosoft.com tenant-default- domain SPF-pass + DMARC-fail prerequisite, the hybrid Exchange on-premises ETA + EXO cloud signing coordination), the SPF-mechanisms spoke is the PUBLISHER-SIDE-AUTHORIZATION- VOCABULARY-PRIMITIVE companion documenting the per-publisher per-domain SPF mechanism authorization-scope vocabulary whose per- accepted-domain composition determines whether the per-tenant canonical M365 SPF baseline publishes correctly at the receiver-side SPF evaluator first-hop boundary. The M365-DMARC- vs-SPF-mechanisms relationship is per-tenant- deployment-discipline-anchored-on-per-mechanism- authorization-vocabulary: the per-tenant canonical M365 include:spf.protection.outlook.com baseline IS itself a per-publisher SPF include:-mechanism-class publication; the per-tenant supplementary third-party-ESP includes / per-tenant ip4: literals / per-tenant a: A-RR-host / per-tenant mx: MX-RR-host authorizations each consume per-mechanism-class authorization- vocabulary publication discipline. Four per- mechanism-vs-M365-tenant-deployment coupling dimensions matter at the per-M365-tenant per- accepted-domain authorization-vocabulary boundary: (i) per-tenant include:spf.protection.outlook.com canonical baseline as load-bearing include:-mechanism-class publication — this single per-tenant publication consumes ~3-5 receiver-side recursive DNS lookups by itself, leaving per-tenant residual budget for ~5-7 supplementary include: / ip4: / a: / mx: per-tenant supplementary authorizations under the RFC 7208 §4.6.4 10-DNS-lookup ceiling; (ii) per-tenant supplementary include:-mechanism publication discipline for per-accepted-domain ESP coverage — third-party transactional ESPs (SendGrid / Mailgun / Postmark) require per- tenant include:-mechanism authorization at the per-accepted-domain v=spf1 TXT-record publication boundary; (iii) per-tenant -all hardfail default-disposition qualifier as M365-tenant baseline — the per-accepted-domain canonical -all default-disposition publication discipline produces the per- receiver-side spf=fail verdict on every spoofing-attempt from an unauthorized source-IP, gating the per-M365-tenant per- accepted-domain DMARC-aligned-pass leg correctly; (iv) per-tenant hybrid-Exchange dual-egress SPF mechanism composition — when the per- tenant deployment maintains on-premises Exchange Transport Agent + Exchange Online cloud-signer dual-egress, the per-accepted- domain SPF publication MUST authorize BOTH egress-IP-pools via include: +/ip4: composition at the per- accepted-domain publication boundary. Read THIS page when AUTHORING the per-M365-tenant DMARC publication discipline at the per- accepted-domain authoritative-zone boundary; read the SPF-mechanisms spoke when COMPOSING the per-accepted-domain SPF authorization- vocabulary publication discipline whose per- mechanism-class composition determines whether the per-tenant canonical M365 SPF baseline publishes correctly at the receiver-side SPF- evaluation first-hop boundary.
• SPF mechanism-choice decision matrix
• CAA records explained — the per-publisher per-domain DNS-based CA- authorization publication-discipline pre- condition companion to this M365-tenant DMARC deployment reference.
• DNS propagation — the PER-M365-TENANT-PER-ACCEPTED-DOMAIN-DNS-PUBLICATION-DISCIPLINE-AS-LOAD-BEARING-PROPAGATION-DEPENDENT-PRECONDITION-FOR-EVERY-PER-TENANT-PER-ACCEPTED-DOMAIN-AUTHENTICATION-PUBLICATION-DEPLOYMENT-WINDOW companion at four per-M365-tenant per-accepted-domain DNS-propagation-vs-DMARC-deployment coupling dimensions: (i) per-M365-tenant per-accepted-domain DMARC TXT-RR publication at _dmarc.<tenant-accepted-domain> per RFC 7489 §6.1 IS the load-bearing per-tenant per-accepted-domain receiver-side composite-verdict-evaluation precondition whose per-receiver per-day per-source-IP policy_evaluated attribution depends on the per-zone authoritative-NS-to-recursive-resolver TTL-driven propagation-window having CLOSED at every receiver-side recursive-resolver before the per-tenant operator can audit per-receiver per-day RUA aggregate-report stream for per-tenant per-accepted-domain DMARC-aligned-pass-rate floor preservation — per-tenant per-accepted-domain operator-side DMARC publication-cutover IS gated on per-zone DMARC TXT-RR TTL-driven propagation-window closure at the per-receiver per-recursive-resolver cache-coherence boundary; (ii) per-M365-tenant per-accepted-domain DKIM dual-selector CNAME publication at selector1._domainkey.<tenant-accepted-domain> + selector2._domainkey.<tenant-accepted-domain> per RFC 6376 §3.6.1 IS per-tenant per-accepted-domain receiver-side DKIM-Signature public-key-retrieval precondition whose per-receiver per-message DKIM-verdict-evaluation depends on per-zone CNAME-target-resolution propagation-window closure at the per-receiver-side recursive-resolver — per-tenant per-accepted-domain DKIM CNAME-delegation cutover discipline operationally requires per-zone CNAME-RR TTL-driven propagation-window closure before per-receiver per-day DKIM-aligned-pass attribution can be audited against per-tenant per-accepted-domain DKIM-aligned-pass-rate floor; (iii) per-M365-tenant per-accepted-domain SPF TXT-RR publication at apex domain per RFC 7208 §3 IS per-tenant per-accepted-domain receiver-side envelope-MAIL-FROM-authorization-evaluation precondition whose per-receiver per-message SPF-verdict-evaluation depends on per-zone SPF TXT-RR + per-`include`-chain-target-zone-resolution multi-hop propagation-window closure at the per-receiver-side recursive-resolver — per-tenant per-accepted-domain SPF publication-cutover IS gated on per-zone SPF TXT-RR + per-`include:spf.protection.outlook.com`-target-zone-resolution multi-hop propagation-window closure under RFC 7208 §4.6.4 10-DNS-lookup-cap discipline; (iv) per-M365-tenant per-accepted-domain MTA-STS _mta-sts.<tenant-accepted-domain> TXT-RR `id=` rotation publication + per-tenant TLS-RPT _smtp._tls.<tenant-accepted-domain> TXT-RR publication per RFC 8460 §3.1 BOTH per-receiver per-day per-MX-host transport-layer-policy-evaluation preconditions whose per-receiver per-day per-MX-host TLS-RPT aggregate-report stream attribution depends on per-zone TXT-RR TTL-driven propagation-window closure at the per-receiver-side recursive-resolver — per-tenant per-accepted-domain MTA-STS policy-`id`-rotation cutover discipline + TLS-RPT publication cutover discipline operationally require per-zone TXT-RR TTL-driven propagation-window closure before per-receiver per-day per-MX-host TLS-RPT aggregate-report attribution can be audited for per-tenant per-accepted-domain transport-layer publication-discipline-floor preservation. Read the DNS-propagation spoke alongside this M365 DMARC deployment reference when planning per-tenant per-accepted-domain DMARC TXT-RR publication-cutover-window, when coordinating per-tenant DKIM CNAME-delegation cutover-readiness audit against per-zone TTL-driven propagation-window closure, when investigating per-tenant per-accepted-domain per-receiver per-day RUA-aggregate-report attribution gap during the propagation-window before per-receiver-side recursive-resolver cache-coherence stabilises on the post-cutover state, or when authoring per-tenant per-accepted-domain authentication-publication-portfolio cutover-runbook discipline that coordinates DMARC + DKIM + SPF + MTA-STS + TLS-RPT TXT-RR-and-CNAME-RR publication-cutover-windows against the per-zone-driven per-RR-TTL propagation-cadence floor.
• Email authentication glossary
• MTA-STS explained — the transport-layer companion an Exchange Online tenant publishes alongside the DMARC deployment on this page. Microsoft 365 supports inbound MTA-STS, so the same operator who sets up _dmarc aggregate reporting also publishes the _mta-sts.<accepted-domain> TXT-RR and HTTPS policy enforcing TLS on the path to Exchange Online's MX — read the MTA-STS primer to add the transport leg to the full message-layer posture this guide stands up.
• Microsoft SNDS + JMRP monitoring — the consumer-network half of the Microsoft story: authentication can be perfect and Outlook.com/Hotmail will still junk-folder mail from an IP with a degraded SNDS filter verdict; SNDS grades every sending IP GREEN/YELLOW/RED and JMRP streams each Junk click back as an ARF complaint report.

Deploy DMARC for your Microsoft 365 tenant now

DMARC Analyzer parses the daily aggregate reports Microsoft and other receivers send to your rua= mailbox, deduplicates by report_id + org_name, and surfaces the per-sender / per-IP / per-day breakdown needed to drive the alignment fix-up phase. Live DNS verification for every SPF / DKIM / DMARC record on your domain runs through includes/DnsChecker.php; the Email Header Analyzer at header_analyzer.php diagnoses individual message failures by parsing the full Authentication-Results stack via includes/EmailHeaderParser.php.

Sign up — Free plan Check my Microsoft 365 domain