DMARC Analyzer

TL;DR

• DMARC at p=reject blocks direct domain spoofing only — it does NOT block lookalike domains, display-name spoofing, compromised legitimate accounts, or brand impersonation from unrelated domains.
• DMARC does not encrypt email. It is an authentication standard. Transport encryption is the separate job of STARTTLS + MTA-STS (RFC 8461).
• SPF + DKIM without DMARC is not enough. SPF and DKIM authenticate identifiers the recipient never sees (envelope MAIL FROM, DKIM d=). Only DMARC binds those results to the visible From: header (RFC 7489 §3.1, identifier alignment).
• pct= samples your own mail, not attackers. pct=10 with p=reject means 10% of failing mail gets rejected and 90% gets the next-weakest action — including attacker spoofing.
• Subdomains inherit the parent policy via RFC 7489 §6.6.3 organizational-domain lookup, but the parent can override via sp=. Use sp=reject on non-sending parents to lock down unused subdomains.
• BIMI requires DMARC at p=quarantine or p=reject. A BIMI record at p=none is silently ignored by every receiver.
• RUA aggregate reports are the operational workhorse, not RUF. Most receivers do not send RUF at all. Configure rua= first; configure ruf= only if you specifically need per-message failure samples and accept the privacy implications.
• p=quarantine and p=reject are not interchangeable. Quarantine delivers to spam / junk where the user can recover the message; reject refuses delivery at the SMTP layer with a 5xx response. Skipping quarantine is the single most common self-inflicted email outage.
• DMARC failures are not always attackers. Forwarding, mailing lists, and forgotten-but-legitimate senders cause most failures during initial rollout. The report-driven inventory phase exists to separate legit-but-misaligned from attacker.
• DMARC monitoring is permanent. Reaching p=reject is the start of operational DMARC discipline, not the end — new sending services, ESP changes, DKIM key rotations, and SPF include drift constantly threaten regressions.

1. What is a DMARC myth and why this page exists

A DMARC myth is a widely-repeated claim about DMARC that does not match what receiving mail servers actually do when an inbound message arrives. Myths typically arise from one of three places: vendor marketing copy that oversells DMARC as "anti-phishing"; oversimplified explanations that drop the alignment distinction or the subdomain-inheritance rule; or folklore from outdated tutorials that predate ARC, the Google / Yahoo February 2024 bulk-sender requirements, and the wide-scale rollout of strict policies among major receivers.

The cost of believing a DMARC myth is rarely technical — it is operational. An organization that believes "p=reject blocks phishing" deploys DMARC and stops investing in anti-phishing training; when the next campaign uses a lookalike domain, no defence engages. An organization that believes "DMARC encrypts email" never deploys MTA-STS and ships every message over plaintext SMTP whenever the receiver does not advertise STARTTLS. An organization that believes "subdomains automatically inherit the parent policy" ships a v=DMARC1; p=reject record on the apex but leaves unused subdomains (newsletter.example, dev.example, test.example) open for attacker registration-and-spoof.

This page lists the 18 myths we see most often in support tickets, public Q&A sites, and the DMARC reports submitted to DMARC Analyzer by operators who have followed bad advice and need to course-correct. Each entry names the myth verbatim, cites the receiver behaviour or RFC paragraph that proves it wrong, describes the operational consequence, and prescribes the corrective action.

2. What DMARC does — and does not — protect

Most DMARC myths are coverage-confusion myths: the operator believes DMARC protects against something it does not. The keystone reference is therefore the explicit coverage map below.

The pattern is clear: DMARC closes one specific attack class — direct domain spoofing — with surgical precision. Every other attack on the email channel needs a different defence. Operators who believe DMARC is the whole defence ship single-layer security and get breached through the gaps.

3. The 18 myths debunked

Each myth is named verbatim followed by the receiver behaviour or RFC paragraph that proves it wrong. Skim by sub-heading; deep-link to any individual myth via the anchor IDs below.

3.1 Myth: "DMARC at p=reject stops all phishing"

Reality: DMARC at p=reject stops direct domain spoofing — messages whose From: header literally claims to be from your domain. It does NOT stop the rest of the phishing taxonomy. Lookalike domains (your-bank.example vs your-bank-secure.example), display-name spoofing (From: "CEO Name" <random@gmail.com>), compromised legitimate accounts that send authenticated phishing from inside your own domain, and brand impersonation via unrelated domains all evade DMARC entirely.

Operational consequence: organizations that conflate "DMARC deployed" with "phishing solved" defund anti-phishing training, gateway investments, and brand-monitoring services — leaving the broader phishing surface exposed.

Corrective action: deploy DMARC as one layer of email security. Pair it with anti-phishing email-security gateways (display-name spoof detection, link scanning, sandboxing), employee training, brand-monitoring for lookalike domains, and account-takeover monitoring for compromised legitimate accounts.

3.2 Myth: "DMARC encrypts email"

Reality: DMARC is an authentication standard, not an encryption standard. It tells the receiving mail server how to verify a message claims to be from your domain (via SPF and DKIM alignment per RFC 7489) and what disposition to apply when authentication fails (p=none, p=quarantine, p=reject). DMARC has no opinion on whether the SMTP session was encrypted in transit.

Operational consequence: operators who believe DMARC encrypts email skip MTA-STS (RFC 8461) and TLS-RPT (RFC 8460) deployment. Mail then delivers over plaintext SMTP whenever a man-in-the-middle strips STARTTLS, and no reporting stream surfaces the failure.

Corrective action: deploy MTA-STS in enforce mode for transport security AND DMARC for authentication AND TLS-RPT for transport reporting. They are complementary, not interchangeable. See MTA-STS explained and TLS-RPT explained.

3.3 Myth: "I have SPF and DKIM so I do not need DMARC"

Reality: SPF and DKIM individually authenticate identifiers that are NOT the visible From: header. SPF (RFC 7208) authenticates the RFC 5321 envelope MAIL FROM domain (the bounce-address domain); DKIM (RFC 6376) authenticates the d= signing domain in the DKIM-Signature header. Neither one binds to the visible From: header the recipient sees.

An attacker can publish a valid SPF record at their own attacker.example domain, set MAIL FROM=bounces@attacker.example (SPF passes), sign with their own DKIM key on attacker.example (DKIM passes), and place From: ceo@your-company.example in the visible header. Without DMARC, both SPF and DKIM signatures pass yet the recipient sees a spoofed From: address. DMARC closes this loophole via RFC 7489 §3.1 identifier alignment: AT LEAST ONE of the SPF-passing or DKIM-signing domain must align (relaxed or strict) with the visible From: domain.

Operational consequence: SPF + DKIM without DMARC authenticates identifiers the user never sees. Spoofing the visible From: is trivial.

Corrective action: publish a DMARC record at _dmarc.your-domain.example starting at p=none with rua=mailto:dmarc@your-domain.example to receive aggregate reports, then advance through p=quarantine and ultimately p=reject. See DMARC alignment explained and DMARC policy rollout.

3.4 Myth: "DMARC alone is enough — no need for MTA-STS"

Reality: DMARC and MTA-STS solve different problems at different layers. DMARC authenticates the sender so the recipient knows the message is genuine (or rejects it if not). MTA-STS (RFC 8461) hardens the transport between mail servers so the SMTP session cannot be downgraded to plaintext by a man-in-the-middle. A domain with DMARC at p=reject but no MTA-STS can still leak message content over plaintext SMTP whenever a receiver falls back to unencrypted delivery.

Operational consequence: confidential message bodies are exposed to network-layer interception even though the sender is cryptographically authenticated.

Corrective action: publish MTA-STS in mode: enforce and TLS-RPT once DMARC is at enforcement.

3.5 Myth: "p=quarantine and p=reject are interchangeable"

Reality: They produce different receiver behaviour with different operational consequences. p=quarantine delivers the failing message to the recipient's spam / junk folder where the recipient can still recover it. p=reject refuses delivery at the SMTP layer with a 5xx response, and the message is gone — bounced back to the sender with no way for the recipient to recover.

The canonical safety guardrail: never skip from p=none to p=reject without a quarantine bake-in phase. The quarantine phase surfaces alignment problems via recipient recovery and spam-folder review; the reject phase is immediately destructive. The single most common self-inflicted email outage in DMARC rollouts is skipping quarantine on the assumption that quarantine and reject are equivalent.

Corrective action: advance p=none → p=quarantine pct=10 → quarantine pct=100 → reject pct=10 → reject pct=100 over the rollout window. See DMARC policy rollout.

3.6 Myth: "Subdomains do not get protected because the DMARC record is at the apex"

Reality: Subdomains inherit the parent policy via RFC 7489 §6.6.3 organizational-domain lookup. The receiver's lookup algorithm tries _dmarc.<full subdomain> first; if no record exists, it falls back to _dmarc.<organizational domain> (the registered domain per the Public Suffix List) and applies that record's policy. The fallback policy is controlled by the parent record's sp= tag (subdomain policy); if sp= is absent, it defaults to whatever p= is set to.

So a parent record of v=DMARC1; p=reject with no sp= means subdomains also get p=reject. To EXEMPT a subdomain that needs a softer policy (e.g. a marketing-mail subdomain still in rollout), set sp=none in the parent record OR publish a per-subdomain _dmarc.<subdomain> record with its own policy. To LOCK DOWN unused subdomains against takeover-and-spoof, explicitly set sp=reject on the parent.

Operational consequence: operators who believe subdomains are unprotected publish redundant per-subdomain records or, worse, skip publishing a per-subdomain record where one is actually needed because the parent inheritance already covers them. Operators who believe the opposite — that subdomains are automatically protected without thinking about sp= — leave unused subdomains open to attacker registration.

Corrective action: read DMARC record tags explained for the full sp= semantics. Audit your apex record now: if you have p=reject but no sp=, your subdomains already inherit reject. If you have unused subdomains, set sp=reject explicitly to lock them down.

3.7 Myth: "Going straight to p=reject is fine if my records look right"

Reality: "Looks right" is a static check; "passes alignment for every legitimate sender in production" is a dynamic check that requires aggregate-report data over several weeks. Most domains have forgotten senders — a third-party payroll provider, an old ticket-system mailer, a corporate-wellness SaaS that sends quarterly — that pass static DNS checks but fail real-world alignment because they were configured years ago with the wrong DKIM selector or an outdated SPF include.

Operational consequence: going straight to p=reject silently blocks all legitimate-but-misaligned mail. Recipients see silent message loss (no bounce visible to the intended human reader); senders see 5xx rejections at the SMTP layer that may or may not surface to operations staff.

Corrective action: deploy p=none with rua=mailto:... for aggregate reporting, observe for 2-6 weeks, inventory every sender from the reports, fix alignment for each one, then advance through p=quarantine to p=reject. See DMARC policy rollout and DMARC aggregate (RUA) reports.

3.8 Myth: "pct=10 means 10% of attackers get blocked"

Reality: The pct= tag controls what percentage of YOUR DOMAIN'S OWN failing mail receives the enforcement action — it does NOT sample attackers. RFC 7489 §6.3 defines pct= as the operator's rollout-safety dial: at pct=10 with p=reject, receivers reject 10% of messages that fail DMARC and apply the next-weakest action (p=quarantine in this case) to the remaining 90%. Used responsibly, it ramps an organization gradually from p=none to p=reject by incrementing pct from 10 to 25 to 50 to 100 over weeks.

Used carelessly, it leaves 90% of the spoofing problem unblocked — an attacker spoofing your domain has a 90% chance their message gets the weaker quarantine treatment instead of reject at pct=10.

Corrective action: use pct= only during rollout, advance it monotonically (never decrement), and remove it (equivalent to pct=100) once the policy is stable.

3.9 Myth: "DMARC at p=reject blocks lookalike-domain phishing"

Reality: DMARC anchors against the literal From: domain. A lookalike domain (your-bank.example vs your-bank-secure.example, vvise.example vs wise.example, your-company.co vs your-company.com) is a separate domain that the attacker registered, configured, and controls. The attacker publishes their own SPF + DKIM + DMARC on the lookalike domain — every authentication check passes for the lookalike, and DMARC has no semantic understanding of visual confusability.

Operational consequence: organizations that deploy DMARC and stop investing in lookalike-domain monitoring leave one of the highest-value phishing vectors open. Business Email Compromise (BEC) campaigns overwhelmingly use lookalike domains, not direct spoofing.

Corrective action: pair DMARC with brand-monitoring services that detect confusable-domain registrations, employee training that highlights the visual-spoofing risk, and gateway policies that warn on first-time-seen sender domains.

3.10 Myth: "BIMI works at p=none"

Reality: BIMI specifically requires DMARC at p=quarantine or p=reject with pct=100. A BIMI record published while DMARC is at p=none is silently ignored by every receiver — no logo renders, no error surfaces. The BIMI specification (currently draft-brand-indicators-for-message-identification) is explicit: BIMI is the consumer-facing payoff for organizations that have completed DMARC enforcement.

Operational consequence: teams that publish BIMI before DMARC enforcement see no logo in the inbox, blame "BIMI is broken", and abandon the deployment. The real cause is the missing prerequisite.

Corrective action: finish DMARC rollout to p=quarantine or p=reject at pct=100 first, then publish BIMI. See BIMI explained.

3.11 Myth: "Deploying DMARC will break my mailing lists"

Reality: Only ARC-unaware mailing lists break, and only when the operator's domain has no mitigation for the rewrite case. Modern mailing-list software (Mailman 3 since 3.1, Google Groups since 2018, Microsoft 365 Groups, Discourse) implements ARC (RFC 8617): the list adds ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal headers that preserve the original DMARC-passing verdict across the relay, and recipient receivers (Gmail, Yahoo, Microsoft 365) trust those ARC seals to override the local DMARC failure. Lists that rewrite the From: header to <list-name@list-host.example> (the address-rewriting mitigation specified by RFC 7489 §A.4) also bypass DMARC failure entirely.

The breakage cases are: (a) ARC-unaware lists that simply forward a body-modified message unchanged, AND (b) the operator publishes DMARC at p=reject without first ensuring the lists they participate in either ARC-sign or rewrite.

Corrective action: verify the mailing lists you participate in support ARC or From-rewriting before advancing to p=reject. See ARC explained.

3.12 Myth: "I only need DMARC on domains I send mail from"

Reality: Non-sending domains are the highest-value spoof targets precisely BECAUSE they have no email-authentication posture. An attacker who spoofs support@your-company-corporate.example (a parking domain you registered defensively years ago and never deployed mail from) faces no DMARC check, no SPF check, no DKIM signature — every authenticator returns "none", and many receivers default to delivery. The recipient sees a "your-company" From: address with no security warnings.

Operational consequence: every domain in the organization's portfolio that lacks email authentication is a free spoof vector for attackers.

Corrective action: publish "null SPF" + "null MX" + "DMARC at p=reject" on every non-sending domain to explicitly signal "no mail comes from here, reject everything claiming to":

; null SPF — no IPs authorized
your-domain.example.   IN TXT "v=spf1 -all"

; null MX — no mail accepted (RFC 7505)
your-domain.example.   IN MX  0 .

; DMARC reject — visible-From spoofing locked out
_dmarc.your-domain.example.  IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@active-domain.example"

3.13 Myth: "DMARC reports tell me who is being phished"

Reality: DMARC reports tell you which IP addresses are sending mail claiming to be from your domain — they say nothing about who received the mail or whether it was a phishing campaign or a legitimate forgotten sender. RUA aggregate reports list per-IP authentication outcomes (RFC 7489 §7.2). RUF forensic reports (where sent) include redacted message-level samples but not recipient identifiers.

DMARC reports tell you about the SENDER side of the channel. To investigate the RECIPIENT side — who clicked, who entered credentials, who was tricked — you need recipient-side telemetry: gateway logs, anti-phishing detonation results, employee phishing-report button data.

Corrective action: use DMARC reports for sender inventory and authentication health. Use mail-flow gateway logs and user-reported-phishing data for recipient-side investigation.

3.14 Myth: "RUF (forensic) reports are the most useful kind"

Reality: RUA aggregate reports are the operational workhorse; RUF forensic reports are niche and rarely sent. RUA reports (RFC 7489 §7.2) are sent daily by every major receiver (Google, Microsoft, Yahoo, Mail.ru, Comcast, hundreds of others) and contain aggregated per-IP authentication outcomes — they are how an operator inventories every sender claiming the domain and tracks compliance over time. RUF reports (RFC 7489 §7.3) deliver per-message failure samples including (often heavily redacted) headers and sometimes the body of failing messages — they are sent by very few large receivers because of privacy / GDPR concerns about forwarding third-party email content.

Operational consequence: operators who configure only ruf= and not rua= see near-zero traffic and conclude DMARC is not working. The aggregate data was where the actual signal lived.

Corrective action: configure rua=mailto:... as the primary monitoring stream. Configure ruf=mailto:... only if you specifically want to investigate per-message failures, accept the volume will be near-zero, and accept the privacy / data-residency implications of receiving partial copies of third-party email content.

3.15 Myth: "DMARC failures always mean an attacker"

Reality: Most DMARC failures during the rollout phase are legitimate-but- misaligned senders — a forgotten payroll provider, an old ticketing-system mailer, a third-party SaaS configured with the wrong DKIM selector. Treating every failure as an attacker floods the security team with false positives and burns through DMARC budget on chasing legitimate senders.

Corrective action: use the p=none rollout phase specifically to separate legitimate-but-misaligned from attacker. Read the aggregate reports, identify each non-aligned IP, classify it (legitimate-known, legitimate-forgotten, suspicious-unknown, attacker-confirmed), then either fix alignment (legitimate cases) or maintain the failure classification (attacker cases) before advancing policy. See DMARC aggregate reports for the classification workflow.

3.16 Myth: "rua= can be any address on any domain"

Reality: RFC 7489 §7.1 requires an external rua= address to have an explicit authorization record on the RECEIVING side. To send DMARC reports for your-domain.example to dmarc-reports@third-party-vendor.example, the vendor must publish a TXT record at your-domain.example._report._dmarc.third-party-vendor.example containing v=DMARC1;. Without that authorization record, every receiver that implements §7.1 (notably Google, Microsoft, Yahoo) refuses to send reports to the cross-domain address — silently.

Operational consequence: operators who configure rua=mailto:reports@third-party.example without the authorization record see near-zero inbound report volume and conclude their domain has no DMARC activity (when in reality reports are being silently suppressed).

Corrective action: if you use a DMARC processing vendor or a third-party inbox, publish the external authorization record on the third-party domain. If you self- host, use rua=mailto:dmarc@your-own-domain.example where no §7.1 authorization is needed.

3.17 Myth: "DMARC blocks attackers spoofing my employees' Gmail addresses"

Reality: DMARC protects YOUR domain, not your employees' personal Gmail / Yahoo / Outlook.com addresses. An attacker spoofing From: your-employee@gmail.com triggers Gmail's DMARC policy on gmail.com (which is at p=reject for direct gmail.com spoofs), not your organization's DMARC policy. Your domain's DMARC record only governs messages claiming to be from your domain.

Corrective action: rely on each webmail provider's DMARC posture for employee personal addresses. Where employees must use personal addresses for legitimate business reasons (rare), pair with anti- phishing gateway policies that flag executive- name display spoofing regardless of authentication result.

3.18 Myth: "Once DMARC is at p=reject I can stop monitoring"

Reality: DMARC monitoring is permanent. Reaching p=reject is the start of operational DMARC discipline, not the end. Regression vectors include: new sending services added by other teams (procurement, HR, marketing) without security review; ESP changes that swap DKIM selectors or SPF includes; DKIM key rotations that fail to update DNS; SPF flattener tools producing over-10-lookup records that flip to permerror; third-party SaaS providers changing their sending infrastructure without notice; organizational acquisitions adding new domains; certificate expiries that break BIMI or MTA-STS. Any one of these regressions can drop a major sender below alignment and trigger silent message loss at p=reject.

Corrective action: establish permanent DMARC monitoring discipline. Ingest aggregate reports daily, alert on compliance drops >5%, review the per-sender breakdown weekly during business hours and immediately after every change to mail infrastructure. See DMARC monitoring & reporting analysis.

4. Myth categories at a glance

The 18 myths above sort into four error-pattern categories. Recognising the pattern is the fastest way to spot future myths not on this list.

5. Where the myths come from

Understanding the source of a myth helps inoculate teams against the next one. The 18 myths above trace back to four origin sources:

• Vendor marketing copy. Email-security vendors compress complex defence-in-depth narratives into one-line promises ("DMARC stops phishing", "DMARC protects your brand") because nuance does not fit on a feature comparison slide. The nuance is what matters operationally.
• Outdated tutorials. Tutorials written before ARC (RFC 8617, 2019), before the February 2024 Google / Yahoo bulk-sender requirements, or before the wide-scale receiver rollout of strict DMARC enforcement carry assumptions that no longer hold. The mailing-list-breakage myth is the canonical example: ARC closes the gap, but a 2017 tutorial does not mention ARC at all.
• Oversimplified explanations. "DMARC is SPF + DKIM" is technically wrong but conceptually close enough for an executive briefing. The error compounds when an operator who only ever heard the executive briefing version tries to deploy DMARC and skips the alignment, sp=, pct=, and rua= subtleties.
• Cargo-cult deployments. Copying a competitor's published DMARC record without understanding what each tag does — including tags that were appropriate for the competitor's deployment state but not yours.

The remediation is the same in every case: read RFC 7489 directly for the canonical definitions, read your aggregate reports for the canonical truth about what is happening on your domain, and treat vendor copy as marketing not specification.

6. Operator remediation checklist

If any of the myths above match your current mental model or deployment, work the corresponding remediation item below. Items are ordered by typical risk impact.

1. Audit the policy ladder. Confirm your domain is at p=quarantine pct=100 or p=reject pct=100. If you are at p=none more than 12 weeks after deployment, the rollout has stalled — surface the blockers and advance.
2. Audit the sp= inheritance. On every apex DMARC record, decide explicitly whether sp= should be reject (for non-sending or fully-aligned subdomains) or a softer value (for subdomains in rollout). Implicit defaults are fine if you have verified the implication.
3. Inventory non-sending domains. Every domain in your portfolio that does not send mail needs null SPF + null MX + DMARC p=reject sp=reject. This is the single highest-ROI defensive posture for organizations with many parking domains.
4. Verify rua= reception. Confirm aggregate reports are arriving daily from at least Google, Microsoft, and Yahoo. If volume is near-zero, suspect the external-authorization record (myth 16) or a misconfigured rua= address.
5. Deploy MTA-STS in enforce mode. Once DMARC is at enforcement, layer MTA-STS + TLS-RPT for transport-layer hardening.
6. Cross-check the BIMI prerequisite. If BIMI is published, confirm DMARC is at p=quarantine or p=reject with pct=100. If you are below that bar, BIMI is silently ignored.
7. Establish permanent monitoring. Daily aggregate-report ingestion, weekly review, alerting on >5% compliance drops. Treat DMARC monitoring as a permanent operational discipline, not a one-time project.
8. Pair DMARC with the rest of the stack. Anti-phishing gateway, lookalike-domain monitoring, employee training, MFA / FIDO2, ARC-aware mailing lists. DMARC is one layer.

7. FAQ

Does DMARC at p=reject stop all phishing attacks against my organization?

No. DMARC at p=reject stops direct domain spoofing — messages whose visible From: header literally claims to be from your domain — but it does NOT stop the rest of the phishing taxonomy. Lookalike domains (your-bank.example vs your-bank-secure.example), display-name spoofing where the From: address belongs to a free webmail provider but the display name reads "CEO Name", compromised legitimate accounts that send authenticated phishing from inside your own domain, and brand impersonation via unrelated domains all evade DMARC entirely. RFC 7489 §3 is explicit that DMARC anchors against the visible From: header (RFC 5322), so attacks that change the From: address rather than spoof it are outside DMARC's scope. Pair DMARC with anti-phishing email-security gateways, employee training, and impersonation-domain monitoring.

Does DMARC encrypt email in transit?

No. DMARC is an authentication standard, not an encryption standard. It tells the receiving mail server how to verify a message claims to be from your domain (via SPF and DKIM alignment) and what to do when authentication fails (p=none, p=quarantine, p=reject). Email-transport encryption is the separate responsibility of SMTP STARTTLS (opportunistic) and MTA-STS (RFC 8461, enforced STARTTLS). Deploy DMARC for authentication AND MTA-STS for transport-encryption hardening — they are complementary, not interchangeable.

I already have SPF and DKIM published. Do I still need DMARC?

Yes. SPF and DKIM individually authenticate identifiers that are NOT the visible From: header the recipient sees. SPF authenticates the RFC 5321 envelope MAIL FROM (the bounce-address domain); DKIM authenticates the d= signing domain in the DKIM-Signature header. Neither one inherently binds to the visible From: header. An attacker can publish a valid SPF record on attacker.example, set MAIL FROM=bounces@attacker.example (SPF passes), and put From: ceo@your-company.example in the header — both SPF and DKIM signatures can pass while the recipient sees a spoofed From:. DMARC closes this loophole by demanding that the SPF-passing OR DKIM-signing domain ALIGN with the visible From: header (RFC 7489 §3.1, "Identifier Alignment"). Without DMARC, SPF and DKIM authenticate identifiers the user never sees.

Is DMARC alone enough for email security?

No. DMARC closes one specific gap — domain-impersonation spoofing — but it leaves several others open. (1) Transport security: a man-in-the-middle can still strip STARTTLS and read or modify plaintext SMTP — MTA-STS (RFC 8461) and TLS-RPT (RFC 8460) close this. (2) Forwarding survival: mailing lists, .forward redirects, and corporate mail-flow rewrites break SPF unconditionally and can break DKIM via body-modification — ARC (RFC 8617) preserves the original authentication result across the hop. (3) Lookalike domains: DMARC anchors against the literal From: domain; an attacker who buys a confusable lookalike domain (vvise.example vs wise.example) and publishes their own DMARC bypasses every check while looking identical to the human eye. (4) Compromised internal accounts: any attacker who steals legitimate credentials can send DMARC-passing phishing from your own infrastructure. Deploy DMARC AS PART OF the full email-authentication stack (SPF + DKIM + DMARC + MTA-STS + TLS-RPT + ARC + BIMI + CAA), plus anti-phishing gateways, plus employee training.

Will deploying DMARC at p=reject break legitimate mailing lists?

Only if the mailing list is not ARC-aware AND your domain has no policy for the mailing-list rewrite case. Modern mailing-list software (Mailman 3 since 3.1, Google Groups since 2018, Microsoft 365 Groups, Discourse) implements ARC (RFC 8617): the list adds ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal headers that preserve the original DMARC-passing verdict across the relay, and recipient receivers (Gmail, Yahoo, Microsoft 365) trust those ARC seals to override the local DMARC failure. Lists that rewrite the From: header to <list-name@list-host.example> (the "address rewriting" mitigation specified by RFC 7489 §A.4) also bypass DMARC failure entirely. The breakage cases are: (a) ARC-unaware lists that simply forward a body-modified message unchanged, AND (b) the operator publishes DMARC at p=reject without first ensuring the lists they participate in either ARC-sign or rewrite. The remediation is ARC-aware list software, not staying at p=none forever.

Do subdomains automatically inherit the parent domain's DMARC policy?

Yes for organizational-domain lookup, but the inherited policy can be overridden by the sp= tag. RFC 7489 §6.6.3 defines the receiver's lookup algorithm: try _dmarc.<full domain>; if no record, fall back to _dmarc.<organizational domain> (the PSL-derived registered domain) and apply the parent's policy. Within that parent record, the sp= tag (subdomain policy) specifies the policy for subdomains; if absent, sp= defaults to whatever p= is set to. So a parent record of v=DMARC1; p=reject with no sp= means subdomains also get p=reject. To EXEMPT a subdomain that needs a softer policy (e.g. a marketing-mail subdomain still in rollout), explicitly set sp=none in the parent record, OR publish a per-subdomain _dmarc.<subdomain> record with its own policy. To LOCK DOWN unused subdomains against takeover-and-spoof, explicitly set sp=reject on the parent.

What is pct= and does pct=10 mean 10% of attackers get blocked?

No. pct= controls what percentage of YOUR DOMAIN'S OWN failing mail receives the enforcement action — it does NOT sample attackers. RFC 7489 §6.3 defines pct= as the operator's rollout-safety dial: at pct=10 with p=reject, receivers reject 10% of messages that fail DMARC and apply the next-weakest action (p=quarantine, in this case) to the remaining 90%. Used responsibly, it ramps an organization gradually from p=none to p=reject by incrementing pct from 10 to 25 to 50 to 100 over weeks. Used carelessly, it leaves 90% of the spoofing problem unblocked — an attacker spoofing your domain has a 90% chance their message gets the weaker quarantine treatment instead of reject at pct=10. Use pct= only during rollout, advance it monotonically, and remove it (which is equivalent to pct=100) once the policy is stable.

Are DMARC RUF (forensic) reports the most useful kind to enable?

No. RUA aggregate reports are the operational workhorse; RUF forensic reports are niche and rarely sent. RUA reports (RFC 7489 §7.2) are sent daily by every major receiver (Google, Microsoft, Yahoo, Mail.ru, Comcast, hundreds of others) and contain aggregated per-IP authentication outcomes — they are how an operator inventories every sender claiming the domain and tracks compliance over time. RUF reports (RFC 7489 §7.3) deliver per-message failure samples including the (often heavily-redacted) headers and sometimes body of failing messages — they are sent by very few large receivers because of privacy / GDPR concerns about forwarding third-party email content. Most operators only ever receive RUA. Configure rua= as the primary monitoring stream. Configure ruf= only if you specifically want to investigate per-message failures, accept that the volume will be near-zero, and accept the privacy / data-residency implications of receiving partial copies of third-party email content.

8. Related guides

• DMARC primer — what DMARC is and how it fits in the broader email-authentication stack.
• Email authentication explained — the cluster-intro pillar covering SPF + DKIM + DMARC + BIMI + MTA-STS + TLS-RPT + CAA + ARC and how the standards interlock.
• DMARC record tags explained — canonical reference for every tag (v=, p=, sp=, pct=, rua=, ruf=, adkim=, aspf=, fo=, ri=, rf=) with the RFC 7489 paragraph anchors.
• DMARC alignment explained — the identifier-alignment mechanism that myth 3 hinges on; strict vs relaxed; SPF alignment vs DKIM alignment; worked examples.
• Why SPF alone is insufficient — the WHY-SPF-CANNOT-PROTECT-A-DOMAIN-ALONE deep dive that this myths-page references in compact form when correcting the myth-cluster around "we already have an SPF record so we are fine". Where the myths-page corrects the mental-model error in two-or-three sentences (SPF authorises ENVELOPE MAIL FROM not the visible From: header, SPF breaks under forwarding and mailing-list redistribution because envelope rewrites are routine, SPF publishes no remediation policy of its own and depends on DMARC for the p=reject enforcement contract), the why-SPF-alone spoke catalogues the FOUR STRUCTURAL FAILURE MODES that motivate the full DMARC + DKIM + alignment stack: (i) FORWARDING-STRIP (mailing-list / .forward / partner-handoff rewrites the envelope MAIL FROM so the ip4 / include match on the original sender's SPF record stops matching the retransmitting infrastructure), (ii) ENVELOPE-VS-HEADER-DOMAIN DECOUPLING (the legitimate ESP-tenant pattern where envelope MAIL FROM points at a bounce subdomain different from the visible From: header organisational domain — SPF passes for the bounce subdomain but DMARC alignment requires aspf=r relaxed-mode organisational-domain inheritance to produce SPF-aligned-pass), (iii) DIRECT-DOMAIN SPOOFING WITHOUT SPF EVALUATION (when the attacker connects directly to the receiver, sending mail from attacker-owned infrastructure that has nothing to do with the victim's SPF record — SPF Fails, but at p=none the message still reaches the inbox), and (iv) DKIM-ALIGNMENT-ALONE-PASSES UNDER ARC- FORWARDED FLOWS (where mailing-list redistribution preserves the DKIM signature's body-hash through ARC chain- of-custody preservation, allowing DKIM-aligned-pass to compensate for the broken SPF-aligned-pass that envelope-rewriting forwarding produces). Read the why-SPF-alone spoke WITH this myths-page when an operator pushes back on the DKIM-key-generation discipline with "but we already publish SPF" — the why-SPF-alone spoke is the full protocol- layer rebuttal whose summary appears as myth 1 / myth 8 on this myths-page.
• DMARC policy rollout — the phased playbook that myths 5, 7, 8, and 18 prescribe; p=none → quarantine → reject with pct ramps and observation windows.
• DMARC policy modes — the MYTH-DEBUNK-RESOLVES-TO-DMARC- POLICY-TAG-TIER-SEMANTICS companion documenting the canonical RFC 7489 §6.3 p= tag three-tier enforcement semantics (monitor-only / quarantine / reject) that the policy-tier-related MISCONCEPTIONS in THIS page (myth 4 "p=none is good enough", myth 5 "p=quarantine means the email gets rejected", myth 7 "p=reject blocks all legitimate forwarders too", myth 8 "DMARC enforcement starts the moment you publish a record", myth 18 "pct=10 means 10 percent of failing messages get quarantined") all REBUT at the per-tier byte-shape contract layer. Where THIS page debunks the SUBJECTIVE MENTAL-MODEL ERROR per myth in single- paragraph form (e.g., "p=none provides zero enforcement and ZERO protection against impersonation, only observation visibility"), the DMARC-policy-modes spoke documents the OBJECTIVE PROTOCOL CONTRACT each tier publishes: per-tier At-Receiver disposition semantics (none = pass-through, quarantine = junk-folder / hold-queue / spam-folder, reject = SMTP 550 5.7.1 reject), per-tier RUA- aggregate-report visibility budget (which messages appear in which disposition row), per-tier sender- side rollout-risk profile (per-tier false-positive blast-radius), and the canonical ramp ladder (p=none → p=quarantine pct=10 → p=quarantine pct=100 → p=reject pct=10 → p=reject pct=100) that the rollout playbook in MYTH 5 / 7 / 8 prescribes. Without the policy-modes spoke a reader knows WHICH tier RESOLVES the myth, but not WHAT contract the tier publishes at the on-the-wire byte-shape level — this link closes that resolution gap.
• DMARC multi-domain strategy — the MULTI-DOMAIN-MYTHOLOGY-DEBUNK companion to this DMARC misconception catalogue. Where THIS page debunks misconceptions about DMARC mechanics on a SINGLE-DOMAIN basis (myth 1 "SPF alone protects my domain", myth 6 "DMARC stops all phishing", myth 8 "DKIM is optional once SPF is published"), the multi-domain- strategy spoke debunks the SEPARATE STRUCTURALLY-DISTINCT multi-domain mythology cluster operators routinely bring to the multi-domain estate: (i) "ONE DMARC RECORD COVERS ALL OUR DOMAINS" — refuted because each organizational domain (per the Public Suffix List organizational-domain definition RFC 7489 §3.2 references) MUST publish ITS OWN _dmarc.<org-domain> TXT record; mail with Header-From: aligned to a DIFFERENT org-domain consults THAT org-domain's DMARC record, NOT the parent corporate-domain's record; (ii) "SUBDOMAIN INHERITS PARENT POLICY AUTOMATICALLY" — partially refuted because the parent's sp= tag governs subdomain policy ONLY when the subdomain has NO ITS-OWN _dmarc.<subdomain> record; once a subdomain publishes ITS OWN DMARC record, the subdomain-record OVERRIDES the parent's sp= completely; (iii) "PARKED DOMAINS DON'T NEED DMARC" — refuted because parked domains are PRIMARY-VALUE spoofing targets (a domain registered by the operator with NO outbound mail is the ATTACKER'S DREAM impersonation surface); the correct multi-domain-strategy treatment is p=reject; sp=reject; adkim=s; aspf=s on every parked domain with no active senders; (iv) "OUR ACQUISITION DOMAIN IS FINE BECAUSE THE PARENT HAS p=reject" — refuted because the acquisition-domain's DMARC posture is INDEPENDENT of the parent corporation's apex-domain DMARC posture; the acquisition-domain MUST go through ITS OWN p=none → quarantine → reject rollout WITH ITS OWN aggregate-reporting observation window; (v) "SEND-ONLY SUBDOMAINS DON'T NEED THEIR OWN DMARC" — refuted because the send-only subdomain (mailer.example.com, bounce.example.com) typically has a BOUNDED-CARDINALITY known-sender inventory that allows faster policy advancement than the receive-also primary — publishing the send-only-domain's own DMARC record EXPLOITS the smaller-sender- surface advantage. Read the multi-domain- strategy spoke when operators in a multi-brand / multi-acquisition / multi- send-only-domain estate REPEAT any of these five myths during multi-domain rollout conversations — the spoke provides the per-myth refutation grounded in RFC 7489 §3.2 Public-Suffix-List organizational-domain semantics and the sp= / np= tag composition rules the single-domain myths-page references in passing without the full multi-domain matrix.
• DMARC for cPanel - the CPANEL-SHARED-HOSTING-OPERATOR- MINDSET-ERROR-CATALOGUE companion to this DMARC misconception catalogue. Where THIS page debunks UNIVERSAL DMARC misconceptions applying to ALL deployment topologies (myth 1 "SPF alone protects my domain", myth 6 "DMARC stops all phishing", myth 8 "DKIM is optional once SPF is published", myth 13 "RUA reports tell me who is being phished") and the sibling multi-domain-strategy spoke above debunks the multi-domain mythology cluster, the dedicated cPanel spoke debunks the SEPARATE STRUCTURALLY-DISTINCT cPanel- shared-hosting-operator mythology cluster operators routinely bring to cPanel-hosted DMARC rollout that NEITHER the universal myths catalogue NOR the multi-domain- strategy spoke covers: (i) "CPANEL EMAIL DELIVERABILITY FEATURE AUTO-GENERATES THE DKIM KEY, SO MY DKIM SIGNING IS CORRECT BY DEFAULT" — refuted because the cPanel "Email Deliverability" UI's auto- generated default._domainkey TXT is PUBLISHED to the cPanel-managed DNS zone but the cPanel-Exim outbound MTA only signs mail sent through the cPanel SMTP relay with the matching private key — mail sent through ANY OTHER egress path (a WordPress plugin using direct SMTP-AUTH to a third-party ESP, a CRM platform sending via API on behalf of @cpanel- domain, the user's Outlook client sending via a third-party SMTP relay) is SIGNED BY THE THIRD-PARTY's key with a DIFFERENT d=-tag and produces DKIM-unaligned-pass outcomes, defeating the operator's assumption that cPanel-Email- Deliverability is sufficient; (ii) "MY SHARED-HOSTING CPANEL DOMAIN IS TOO SMALL TO BE A SPOOFING TARGET, SO I DON'T NEED DMARC" — refuted because attacker workflow for low-cardinality SMB domain impersonation specifically targets cPanel-hosted SMB domains (because the SMB IS the trust anchor in B2B counterparty communications, and the SMB's lack of DMARC publication means the attacker can impersonate the SMB with zero authentication-mechanism deflection at the recipient's mailbox provider) — cPanel-tenant SMB domains are OVER-REPRESENTED in BEC impersonation attempts at the recipient-mailbox layer, making cPanel-tenant DMARC publication operationally LOAD-BEARING for SMB counterparty trust rather than optional; (iii) "THE CPANEL DMARC WIZARD'S DEFAULT p=quarantine pct=50 IS A SAFE STARTING POSITION" — refuted because the operator-correct DMARC rollout pattern is p=none rua=mailbox-monitoring- first to enumerate ALL legitimate cPanel- outbound + third-party-sender egress paths BEFORE any enforcement, and the cPanel Wizard's pct=50 default starts QUARANTINING 50% of legitimate mail (including legitimate third-party-vendor signed-from-other-d= mail the operator hasn't yet inventoried) before the operator has the per-source_ip aggregate report evidence to safely advance — the cPanel Wizard's pct=50 default is itself the cause of the recurring "DMARC quarantined my legitimate mail" incident class at cPanel SMB tenants; (iv) "BECAUSE I'M ON SHARED HOSTING WITH NO ROOT ACCESS, ENFORCING p=reject WILL REJECT MY OWN MAIL THROUGH THE SHARED MTA" — refuted because the SHARED MTA's outbound mail is signed with the CPANEL-GENERATED-FOR- @cpanel-domain DKIM key and sent from the SHARED-HOST IP block that the cPanel-managed SPF record includes via include:shared-host-provider- spf.example, so the SHARED MTA's own mail passes DMARC alignment normally — the operator's intuition that "shared hosting can't reach p=reject" is mistaken because the alignment-passing path is already in place at the shared-host level; what BLOCKS p=reject readiness at cPanel- tenants is the third-party-ESP-egress inventory the operator hasn't catalogued, NOT the shared-hosting MTA itself. Read the dedicated cPanel spoke when operators running cPanel-hosted SMB domains REPEAT any of these four cPanel-specific myths during DMARC-rollout conversations — the spoke provides the per-myth refutation grounded in cPanel's specific UI surfaces (Email Deliverability feature, DMARC Wizard, Zone Editor, Email Routing) and the cPanel-Exim outbound MTA configuration the universal myths-page references in passing without the full cPanel-specific operator-empowerment-ceiling matrix.
• DMARC for shared hosting — the NON-CPANEL-SHARED-HOSTING-OPERATOR- MINDSET-ERROR-CATALOGUE companion to this DMARC misconception catalogue. Where the sibling cPanel spoke above debunks the cPanel-specific operator-mythology cluster grounded in cPanel's "Email Deliverability" UI surface and the cPanel-Exim outbound MTA's per-tenant signer convention, the shared-hosting spoke debunks the SEPARATE STRUCTURALLY-DISTINCT operator-mythology cluster the FIVE non-cPanel control panels (Plesk, DirectAdmin, ISPConfig, Webmin/Virtualmin, CentOS-Web-Panel) impose on tenant-customer-domain DMARC deployment: (i) "MY PROVIDER DOESN'T OFFER A DMARC WIZARD, SO I CAN'T DEPLOY DMARC ON THIS PANEL" — refuted because every non-cPanel control panel exposes raw DNS-zone editing (Plesk Domains → DNS-Settings, DirectAdmin DNS-management, ISPConfig Sites → Domain DNS tab, Webmin/Virtualmin BIND-zone editor, CWP DNS-zone-editor plugin) which is OPERATIONALLY SUFFICIENT for publishing the _dmarc.<domain> TXT record manually — the absence of a wizard is a UI affordance gap not a capability gap; (ii) "THE PROVIDER-MANAGED DEFAULT DKIM SIGNER MAKES THE TENANT-SIDE SELECTOR ROTATION UNNECESSARY" — refuted because provider-managed default signers (the default._domainkey.<provider>.com leaf the provider publishes on the provider-managed zone, not the tenant-customer zone) frequently use long-lived RSA-1024 keys and never rotate, exposing the tenant to the DKIM-replay-attack class the sibling DKIM-replay-attacks spoke documents and producing dkim-fail aggregate-row clusters when the provider's signer infrastructure has outages; (iii) "SHARED-HOSTING TENANTS CAN'T REACH p=reject BECAUSE THE PROVIDER SHARES THE OUTBOUND-IP POOL" — refuted because per-message DMARC evaluation is per-message-identifier- alignment-driven not per-source-IP- attribution-driven; the shared-IP-pool reputation question is a DELIVERABILITY question orthogonal to the DMARC verdict-evaluation question, and tenant-customer domains routinely reach p=reject on shared hosting once the per-tenant SPF include-cascade and per-tenant DKIM selector publication are correctly aligned; (iv) "THE PROVIDER WILL HANDLE DMARC ON MY BEHALF AS PART OF THE HOSTING PLAN" — refuted because hosting providers publish DMARC for THEIR organizational domain not for each tenant-customer domain; the tenant must publish _dmarc.<tenant-domain> themselves regardless of the provider's own DMARC posture, and provider-side DMARC has no inheritance relationship with tenant-side DMARC. Read the shared-hosting spoke when debunking the per-tenant operator mythology cluster on non-cPanel control-panel deployments, when composing per-panel DMARC-rollout runbooks that span the heterogeneous non-cPanel control-panel footprint, or when refuting per-myth pushback grounded in the structural differences between provider-managed and operator-managed MTA-signer infrastructure across the five non-cPanel control panels.
• DMARC for Office 365 hybrid — the HYBRID-DEPLOYMENT-MYTH-CATALOGUE companion to this DMARC misconception catalogue. Where THIS page debunks UNIVERSAL DMARC misconceptions that apply to ALL deployment topologies, the hybrid-Exchange spoke debunks the SEPARATE STRUCTURALLY-DISTINCT hybrid- coexistence mythology cluster operators routinely bring to an on-prem-Exchange- plus-Exchange-Online deployment: (i) "EXO INHERITS ON-PREM DKIM SIGNING AUTOMATICALLY" — refuted because EXO applies its OWN DKIM signing using the tenant's selector1._domainkey and selector2._domainkey CNAMEs to Microsoft's per-tenant key infrastructure, INDEPENDENT of any on-prem Exchange Server DKIM signing infrastructure; messages routed via EXO carry the EXO selector signature, NOT the on-prem selector signature, and DKIM alignment with the visible Header-From: depends on WHICH path the message traversed; (ii) "HYBRID FLOWS DON'T NEED A SEPARATE DMARC ALIGNMENT AUDIT" — refuted because a single author-domain may legitimately send via the on-prem Exchange Server outbound path, via the EXO outbound send- connector path, via a centralized mail transport relay path, AND via a direct path — each producing DISTINCT DKIM signatures, DISTINCT SPF authority records, and DISTINCT envelope Return-Path: domains. The per-path DMARC alignment outcomes DIVERGE and MUST be observed independently via per-source-IP RUA- aggregate-report row attribution BEFORE Phase-3 p=reject ramp; (iii) "ON-PREM EXCHANGE SERVER IS EXEMPT FROM DMARC COMPLIANCE" — refuted because the on-prem Exchange Server is one of SEVERAL parallel outbound paths for a hybrid tenant's author-domain, and ANY path that produces messages that FAIL the receiver's DMARC alignment evaluation triggers the published policy disposition (p=quarantine, p=reject) at the receiver side — the receiver evaluates DMARC alignment per-message irrespective of which on-prem-vs-EXO path the message traversed; the on-prem path MUST achieve the SAME per-message DKIM-OR-SPF alignment baseline as the EXO path; (iv) "EXO SEND CONNECTOR ROUTES INHERIT ON-PREM SPF" — refuted because EXO- outbound messages traverse Microsoft's spf.protection.outlook.com IP set, NOT the on-prem Exchange Server IP set; an author-domain SPF record that lists ONLY on-prem IPs without an include:spf.protection.outlook.com WILL produce SPF-fail outcomes for ALL EXO-outbound traffic, and SPF alignment with the visible Header-From: will fail receiver-side — the hybrid SPF record MUST list BOTH the on-prem IP set AND the EXO include; (v) "MIGRATING A MAILBOX FROM ON-PREM TO EXO PRESERVES THE OUTBOUND-AUTH SIGNATURE PATTERN" — refuted because the mailbox migration shifts the outbound-authentication path from the on-prem-signed DKIM selector + on-prem- published SPF source IP to the EXO- signed DKIM selector + EXO-published SPF source IP, and the per-recipient receiver-side reputation model observes the path-shift as a discontinuity in the per-source-IP reputation history. Read the hybrid spoke when operators in a coexistence-mode Exchange estate REPEAT any of these five myths during hybrid mailflow conversations — the spoke provides the per-myth refutation grounded in the coexistence-mode connector taxonomy, per-path authentication signature, and the per-path DMARC alignment audit prerequisite that the single-deployment- topology myths-page references in passing without the full hybrid connector matrix.
• DMARC for Microsoft 365 — the SINGLE-TOPOLOGY-M365-DEPLOYMENT- MYTH-CATALOGUE companion to this DMARC misconception catalogue. Where THIS page debunks UNIVERSAL DMARC misconceptions that apply to ALL deployment topologies (Myth 1 "DMARC stops all phishing", Myth 2 "DMARC encrypts email", Myth 3 "p=none is permanently safe", Myth 6 "DMARC protects against all email impersonation", etc.), the DMARC-for- M365 spoke debunks the STRUCTURALLY- DISTINCT M365-CLOUD-ONLY DEPLOYMENT MYTHOLOGY cluster operators routinely bring to a pure-cloud EXO tenant (separate from the hybrid mythology the Office-365-hybrid spoke above catalogues): (i) "EXO HANDLES DMARC PUBLICATION AUTOMATICALLY" — refuted because Microsoft 365 / EOP does NOT publish the per-tenant _dmarc.<tenant-domain> TXT record on the tenant's behalf; the operator MUST author and publish the per-tenant DMARC TXT record at the author-domain DNS zone manually, even on a pure-cloud EXO tenant where SPF / DKIM CNAMEs come pre-configured via the Defender portal toggle; (ii) "ENABLING DKIM IN THE DEFENDER PORTAL SATISFIES DMARC ALIGNMENT AUTOMATICALLY" — refuted because the Defender-portal DKIM-signing toggle signs with d=<tenant-domain> IF AND ONLY IF the operator has FIRST published the selector1._domainkey and selector2._domainkey CNAME records delegating to selector1-<tenant>._domainkey.<tenant>.onmicrosoft.com; absent the CNAMEs, the Defender toggle CANNOT signal DKIM at the per-tenant domain and DMARC DKIM- alignment fails by construction even with the toggle "ON"; (iii) "M365 TENANT DMARC PROTECTS ALL onmicrosoft.com SUB- TENANT SENDERS" — refuted because the per-tenant DMARC TXT record at _dmarc.<tenant-domain> applies to that specific author-domain only; mail emitted under the default <tenant>.onmicrosoft.com substrate is governed by Microsoft's own _dmarc.onmicrosoft.com policy, NOT the per-tenant DMARC publication — DMARC publishers MUST register every custom author-domain with a SEPARATE per-domain DMARC publication; (iv) "DEFENDER FOR OFFICE 365 TRUSTED ARC SEALERS BYPASS REQUIRES NO DMARC CONFIGURATION" — refuted because the Defender for Office 365 Trusted ARC Sealers list (the per-tenant receiver-side ARC-chain-honour-policy configuration that recognises specific forwarder ARC seals as authoritative for surviving forwarder-second-hop SPF/DKIM breakage) is a SEPARATE per-tenant configuration alongside the per-tenant DMARC TXT publication — BOTH must be configured at the author-domain DNS zone AND the Defender admin centre for legitimate forwarded mail to survive the M365- tenant's DMARC enforcement at p=reject; (v) "M365 TENANTS UNDER 5000 MESSAGES/DAY ARE EXEMPT FROM DMARC" — refuted because the Feb 2024 Google/Yahoo bulk-sender threshold is a DELIVERABILITY-GATE threshold, NOT a DMARC-publication threshold; receiver-side DMARC evaluation per RFC 7489 applies to every message regardless of per- tenant volume, and the absence of a per-tenant DMARC publication produces policy_evaluated.disposition= none with no attacker-deterrent enforcement at any volume. Read the DMARC-for-M365 spoke when operators on a pure-cloud EXO tenant REPEAT any of these five M365-specific myths during pre- deployment conversations — the spoke provides the per-myth refutation grounded in the EOP outbound-MX topology, the Defender-portal DKIM- signing CNAME-delegation requirement, the per-author-domain DMARC publication baseline, and the Defender for Office 365 Trusted ARC Sealers configuration that the single-deployment-topology myths-page references in passing without the full M365-cloud-only connector matrix.
• DMARC attacker bypass — the RESIDUAL-ATTACK-SURFACE catalogue companion that this myths-page references in compact form when correcting the myth-cluster around "DMARC at p=reject closes the phishing attack surface". Where this myths-page corrects the mental-model error in one-or-two sentences (myth 1 / myth 6 explicitly enumerate that DMARC alignment is evaluated against the From-header addr-spec domain, not the display-name phrase, not the Reply-To, not lookalike domains, and not compromised legitimate senders), the attacker-bypass spoke catalogues the EIGHT STRUCTURALLY- DISTINCT BYPASS TECHNIQUES that produce NO DMARC-fail evidence in the RUA stream at all because they NEVER trigger DMARC evaluation against the victim domain: (i) lookalike-domain registration (IDN homograph or near-miss ASCII variant — DMARC evaluates the LOOKALIKE policy), (ii) display-name spoofing (visible "From: CEO <attacker@gmail.com>" — DMARC evaluates attacker's gmail.com identifier which passes), (iii) compromised legitimate sender (attacker takes over an ESP-tenant / partner-domain account already aligned at p=reject), (iv) subdomain takeover (dangling CNAME pointing at deprovisioned cloud resource), (v) Reply-To injection (visible From: passes; Reply-To routes to attacker), (vi) ARC-Authentication-Results chain-of- custody trust forgery (intermediate- trusted forwarder forges ARC seal compensating for broken SPF / DKIM — no fail row), (vii) mailing-list amplification attack (list strips and re-signs with its own DKIM — passes DMARC against LIST domain), (viii) third-party-vendor compromise (attacker compromises ESP-tenant the victim authorises via include: / DKIM key delegation and inherits the ESP's alignment authority). Read the attacker-bypass spoke WITH this myths- page when a defender pushes back on post-p=reject phishing complaints with "but we are at p=reject, this should not be possible" — the attacker-bypass spoke is the full eight-technique catalogue whose summary appears as myth 1 / myth 6 on this myths-page.
• Phishing protection — the operational defender's playbook that the most-corrected myth on this page ("DMARC stops all phishing") points to. Where this myths page corrects the mental-model error, the phishing- protection page documents what actually closes the phishing-defense gap DMARC leaves open: layered SEG controls, URL rewriting, attachment sandboxing, anti-impersonation rules, AiTM-proxy-aware detection (Evilginx2 / Modlishka / Muraena), MFA-resistant identity controls (FIDO2 / WebAuthn / phishing-resistant credentials), user-training program design, and the organisational response framework. Read after this myths page to translate the corrected mental model into an actual defense program.
• Email spoofing — the protocol-level technique reference that the alignment-centred myths on this page (myth 3 "SPF or DKIM passing means the email is legitimate", myth 6 "DMARC protects against all email impersonation") depend on. The spoofing page enumerates the seven concrete spoofing mechanisms (direct-domain spoofing, display-name spoofing, lookalike-domain attacks via Punycode / IDN homographs, Reply-To injection, envelope-MAIL-FROM forgery, Received-chain tampering, header-folding tricks) that the corrected mental model on this page identifies as still attacker-accessible at p=reject. Read after this myths page to translate the "DMARC does not block X" corrections into the actual technique vocabulary attackers and defenders use to describe each X.
• Business Email Compromise (BEC) explained — the standalone deep dive on the financial-fraud attack family that myth 6 ("DMARC stops BEC") is most often invoked about. Where this myths page corrects the mental-model error in one paragraph, the BEC page enumerates the six canonical BEC variants (CEO fraud / executive impersonation, vendor / supplier-invoice fraud, payroll-redirect, attorney impersonation, data / W-2 theft, account- compromise BEC), the five-stage BEC kill chain (reconnaissance → infrastructure- staging → social-engineering message → wire / payroll / data-exfiltration request → cover-up), and the precise reason DMARC at p=reject only closes ONE variant (direct-domain spoofing of the executive's own mailbox) while the other five route around DMARC entirely via lookalike domains, display-name spoofing, or compromised legitimate accounts. The BEC page also documents the full defense-in- depth control stack (secure email gateway anti-impersonation rules, wire-transfer out-of-band verification protocols, payroll-change verification protocols, finance / treasury team incident-response playbook, FBI IC3 reporting workflow) plus the statistics underpinning the urgency (USD 2.9B reported loss in 2023, USD 55B+ cumulative since 2013). Read after this myths page to convert the "DMARC stops BEC" myth correction into the actual financial- fraud defense program.
• DMARC aggregate (RUA) reports — the operational workhorse referenced by myths 13, 14, and 15; how to read and classify per-sender per-IP data.
• DMARC reporting pipeline (RUA/RUF end-to-end flow) — the END-TO-END-REPORTING-PIPELINE-AS- CANONICAL-REFUTATION-OF-DMARC-REPORTING- SCOPE-MYTHS companion to this DMARC myths catalogue. Where THIS page catalogues the 18 distinct DMARC misconceptions that recur in operator rollout-blocker decision-making (with myths 13, 14, 16, and 18 directly targeting the DMARC-reporting-pipeline scope), the DMARC-reporting-pipeline spoke is the END-TO-END-AGGREGATE-AND-FORENSIC- REPORT-FLOW reference documenting the protocol-mechanics-level refutations for each reporting-scope myth: (i) Myth 13 ("DMARC reports tell me who is being phished") — refuted at the protocol-mechanic level by the reporting-pipeline's per-source- IP-and-disposition aggregation: RUA reports tell the operator about OUTBOUND mail purporting to come from the operator's OWN domain that fails DMARC at receiver-side evaluation, NOT about INBOUND mail received by the operator's own users (the operator's users being phished is OBSERVED IN THE ATTACKER'S TARGET-DOMAIN's RUA stream, not in the operator's own); (ii) Myth 14 ("RUF (forensic) reports are the most useful kind") — refuted at the protocol-mechanic level by the reporting-pipeline's RUA-vs-RUF receiver-support comparison: most major receivers (Gmail, Outlook.com, Yahoo) DO NOT send RUF reports at all due to GDPR / CCPA / privacy concerns about per-failed-message redacted-header dispatch, so the operator's RUF stream is FUNDAMENTALLY sparse and unrepresentative; RUA aggregate reports from the major receivers ARE THE PRIMARY observability surface; (iii) Myth 16 ("rua= can be any address on any domain") — refuted at the protocol-mechanic level by the reporting-pipeline's cross-organization external- destination opt-in dance: RFC 7489 §7.1 requires that if the rua=mailto: domain differs from the DMARC record's organisational domain, the receiving domain MUST publish a <orgdomain>._report. _dmarc.<rua-domain> authorization record to opt-in; (iv) Myth 18 ("Once DMARC is at p=reject I can stop monitoring") — refuted at the protocol-mechanic level by the reporting-pipeline's continuous- ingestion role: post-p=reject the RUA stream is the OPERATOR'S canonical observability channel for detecting attacker-bypass attempts (the §10 indicator catalogue on the attacker-bypass page surfaces through this RUA stream), legitimate-but-uncovered third- party senders (newly-onboarded SaaS ESPs), forwarder-chain breakage (ARC adoption gaps), and DKIM-key-rotation drift — post-rollout monitoring is more important not less. Read the reporting-pipeline spoke alongside this myths catalogue when designing operator-facing rollout documentation that must overcome the four reporting-scope misconceptions operators raise when questioning what DMARC reports do and do not contain — the myths catalogue is the canonical misconception-correction substrate; this DMARC reporting- pipeline reference is the canonical end-to-end-aggregate-and-forensic- report-flow refutation source for the FOUR myths whose root cause is confusion about what the DMARC reporting pipeline actually observes, dispatches, and surfaces to the operator analytics surface.
• DMARC forensic (RUF) reports — the niche per-message failure samples referenced by myth 14; privacy implications, receiver support, when to enable.
• DMARC troubleshooting — failure-diagnosis sibling: SPF permerror, DKIM body-hash mismatch, alignment-vs- authentication, forwarding breakage.
• DMARC monitoring & reporting analysis — the operational discipline referenced by myth 18; KPIs, alert thresholds, review cadence, regression detection.
• ARC (Authenticated Received Chain) explained — the forwarding-survival standard referenced by myth 11; three ARC headers, chain validation, receiver support.
• SPF explained — RFC 7208; envelope-MAIL-FROM authentication that myth 3 hinges on.
• DKIM explained — RFC 6376; cryptographic signing that myth 3 hinges on.
• DKIM cryptography basics — the PER-PUBLISHER-DKIM- CRYPTOGRAPHIC-KEY-STRENGTH-AND-ROTATION- DISCIPLINE-AS-LOAD-BEARING-REBUTTAL- EVIDENCE-FOR-DKIM-IS-OPTIONAL-AND-DKIM- IS-TRIVIAL-MYTH-CLUSTER companion to this DMARC myths-and-misconceptions catalogue. Where THIS page rebuts the myth-cluster around "DKIM is just signing, easy to add" (myth 3) and "DKIM is optional once SPF is published" (myth 8) in compact myths-page form, the DKIM-cryptography- basics spoke is the per-publisher per- selector cryptographic-discipline operator- reference documenting the LOAD-BEARING per-publisher cryptographic-discipline rebuttal-evidence at FOUR cryptographic- discipline-vs-myth-rebuttal dimensions: (i) per-publisher RSA-2048-bit key-strength floor as cryptographic- modernity-discipline rebutting "DKIM is trivial" myth — per-publisher per-selector RFC 8301 RSA-2048-bit-or- stronger key-strength is NON-NEGOTIABLE per modern receiver-side enforcement (Gmail / Outlook / Yahoo all reject per- publisher per-selector RSA-1024-bit-or- weaker keys as cryptographically obsolete); per-publisher operator commitment to DKIM REQUIRES per-publisher operator commitment to per-selector cryptographic-modernity discipline — NOT a trivial one-time setup; (ii) per-publisher per- selector key-rotation cadence as per- publisher operational-discipline rebutting "DKIM is one-time setup" myth — per-publisher per-selector RFC 6376 §3.6.1 overlap-window rotation pattern REQUIRES per-publisher operator commitment to periodic per-selector rotation (recommended 6-12 month cadence per per-receiver per- selector compromise-window bounding); per- publisher operator skipping per-selector rotation accumulates per-selector compromise-risk exposure and per-publisher per-selector cryptographic-key-leakage attack surface; (iii) per-publisher per-selector private-key custody-isolation as per-publisher operational-discipline rebutting "DKIM is automatic" myth — per-publisher per-selector private-key custody REQUIRES per-publisher operator commitment to HSM-or-equivalent per- selector private-key storage discipline (per-selector private-key exfiltration materializes as per-attacker per-message legitimately-signed payload that per- receiver evaluator credentials as per- publisher-authentic); per-publisher operator delegation of per-selector key- management to per-third-party ESP requires per-publisher operator audit of per-ESP per-selector key-custody-discipline; (iv) per-publisher DKIM-aligned-pass- rate floor as load-bearing input for DMARC-enforcement-mode credibility rebutting "SPF-alone-is-sufficient" myth — per-publisher p=quarantine / p=reject commitment depends on per-publisher per-receiver per-day DKIM-aligned-pass-rate floor (SPF-aligned- pass-rate alone is insufficient because SPF breaks under forwarding per RFC 7208 §10.4); per-publisher operator commitment to DMARC enforcement REQUIRES per-publisher per-selector cryptographic-discipline this spoke documents.
• BIMI explained — the brand-display standard referenced by myth 10; DMARC enforcement prerequisite, SVG Tiny PS, VMC certificates.
• BIMI SVG Tiny PS asset-format requirements — the BIMI-LOGO-FORMAT-MYTH-DEBUNKING companion to this DMARC myths-and- misconceptions reference. Where THIS page documents the 18 DMARC-protocol- layer myths every operator brings to the deployment workflow (myth 10 addresses BIMI in summary as "DMARC is sufficient for BIMI" — debunked by the additional VMC-cert + SVG-format prerequisites), the BIMI-SVG-Tiny-PS- requirements spoke is the BIMI-LOGO- FORMAT-MYTH-CATALOGUE expansion documenting FIVE structurally-distinct BIMI-format misconceptions the operator population repeatedly trips over when moving from DMARC enforcement to BIMI deployment. Concretely, the spoke documents FOUR BIMI-SVG-format-myth- debunking dimensions: (i) "Any SVG works for BIMI" is FALSE — the BIMI spec mandates SVG-Tiny-Portable-Secure profile with explicit baseProfile="tiny-ps" declaration; a standard SVG 1.1 document (the default any modern vector editor exports) is REJECTED by the receiver-side BIMI-eligibility evaluator, and the receiver-side parser is strict about the baseProfile attribute presence AND value — operators commonly publish a standard SVG and observe NO BIMI display at Outlook / Gmail / Yahoo without surfacing any explicit error because the receiver-side BIMI-display- loss is silent; (ii) "PNG works for BIMI" is FALSE — BIMI is SVG-only — operators publishing a PNG-format logo at the BIMI l=-tag URL observe NO BIMI display regardless of the PNG's quality / dimensions, the receiver-side parser does NOT fall back to raster formats; (iii) "Base64 encoding is optional for BIMI" is FALSE — inline base64-encoded SVG is the canonical BIMI publication format — the SVG asset must be base64-encoded for inline embedding in receiver-side rendering pipelines (most receivers cache the SVG as base64-encoded inline payload rather than fetching the external URL per-message), and an SVG published at the l=-URL without base64-encodable inline-render compatibility produces inconsistent receiver-side BIMI display; and (iv) "Rectangular logos work for BIMI" is FALSE — BIMI mandates strictly square 1:1 aspect ratio via viewBox — the SVG's viewBox attribute must declare a square coordinate system (e.g. viewBox="0 0 100 100"), and any non-square aspect ratio causes the receiver-side BIMI-eligibility evaluator to reject the asset; the BIMI spec further restricts the asset to RGB-only color (no CMYK / no ICC color profiles), 32KB ceiling, no embedded scripts / animation / external resources, and no <foreignObject> or <use>-external-href constructs — each restriction surfacing as silent BIMI-display-loss at receivers when violated. Read the BIMI-SVG-Tiny- PS-requirements spoke alongside this myths-and-misconceptions reference when the operator's BIMI deployment moves from "DMARC enforcement achieved" to "BIMI logo publication" — myth 10's debunking is the procedural starting point, but the SVG-Tiny-PS format- conformance catalogue the spoke documents is the operational checklist the operator must satisfy to actually achieve receiver-side BIMI display.
• MTA-STS explained — RFC 8461; transport-encryption hardening referenced by myths 2 and 4.
• TLS-RPT explained — RFC 8460; transport-failure reporting referenced by myths 2 and 4.
• Email authentication glossary — canonical definitions for every term-of-art the myths reference: alignment, organizational domain, PSL, envelope MAIL FROM, identifier alignment, ARC chain validation, and more.
• Email security glossary — the threat-and-defense vocabulary companion to the protocol glossary; defines the adversary-side terms multiple myths reference but do not stop to define. Myth 1 ("DMARC stops all phishing") depends on understanding the phishing taxonomy (spear phishing, whaling, smishing, vishing, quishing, clone phishing, pharming) the glossary catalogues — DMARC at enforcement blocks the direct-domain- spoof subset only, not the look-alike, display-name, compromised-account, or out-of-channel subsets. Myth 6 ("DMARC stops BEC") depends on understanding the BEC / CEO fraud attack-family taxonomy the glossary defines — modern BEC uses look-alike domains, display-name spoofing, and compromised legitimate accounts because direct spoofing is already blocked. Myths 9 and 16 ("our SOC will catch it") depend on understanding the SOC / SIEM / SOAR / EDR / XDR security-operations vocabulary and the NIST IR lifecycle / indicators of compromise / dwell time incident-response vocabulary. Myth 17 ("look-alike domains are someone else's problem") depends on understanding the typosquatting / homograph / cousin domain / brand impersonation registration patterns the glossary catalogues. Read the security glossary alongside this myths page to convert each myth's adversary-side framing into a precise vocabulary anchor for further operator research and threat-model analysis.
• SPF permerror vs temperror — the MYTH-DEBUNK-FOR-PERMERROR-AS- DMARC-PASS-MISCONCEPTION companion to this DMARC myths-and-misconceptions catalogue. Where THIS page catalogues the canonical operator-misconception anti-patterns (SoftFail-equals-Fail, ~all-equals-rejection, p=quarantine-is- always-safe, DMARC-removes-spam, all-IPs-in-SPF-are-good-IPs, monitoring- is-optional), the SPF permerror-vs- temperror spoke is the RFC 7208 §2.6 SPF result-code companion whose receiver-side semantics this myths-page catalogues as a specific operator- misconception class about SPF leg behavior under publisher-side budget exceedance. The PERMERROR-MISCONCEPTION cross-reference establishes FOUR structurally-distinct permerror- misinterpretation dimensions whose operator-side mythology this page's debunking discipline targets: (i) "SPF permerror is a temporary problem and resolves on retry" myth — operators often misclassify permerror as a transient DNS failure and assume time will fix it; the spoke documents permerror as the canonical PUBLISHER-SIDE-PERMANENT failure class (10-DNS-lookup budget exceedance, void- lookup cap exceedance, malformed publisher record syntax) that DOES NOT self-resolve without publisher intervention — only temperror is the retry-friendly RFC 1035 DNS-rcode-2 SERVFAIL transient class; THIS page's catalogue of operator-side ignorance anti-patterns specifically targets the permerror-is-transient misconception; (ii) "SPF permerror still produces SPF pass at DMARC layer" myth — operators often misclassify DMARC RFC 7489 §4.2's treatment of SPF permerror as a degenerate-pass when DMARC §4.2 normatively treats permerror AS the "no policy applicable" verdict for the SPF leg, structurally collapsing the publisher's INTENDED SPF authentication contract; the spoke documents this DMARC-evaluator-of- permerror semantic as the canonical STRUCTURAL spoofing-bypass window THIS page's myth-debunking discipline must target; (iii) "SPF permerror cannot be debunked without re-publishing the publisher record" myth — operators often misclassify permerror as requiring full re-publication of the publisher record; the spoke documents the operator-side fix workflow (SPF budget recovery via flattening, nested-include cascade analysis, void- lookup audit) as the canonical publisher-side-resolution discipline that does NOT require re-publication — only the specific budget-exceedance fix; THIS page's myth-debunking catalogue must target operator-side ignorance about this fix-discipline complexity; (iv) "SPF temperror and permerror are interchangeable receiver-side outcomes" myth — operators often misclassify temperror and permerror as identical receiver-side outcomes when RFC 7208 §2.6 normatively distinguishes them AND DMARC §4.2 normatively distinguishes their receiver-side leg-attribution semantics; the spoke documents the canonical temperror-vs-permerror distinction (temperror = retry-friendly DNS-rcode-2 SERVFAIL; permerror = publisher-side permanent budget/syntax error) AND the DMARC-evaluator- treatment-distinction (temperror → "evaluation deferred"; permerror → "no policy applicable") that this myth-page's debunking discipline targets. Pair this page (the DMARC myth-debunking catalogue) with the SPF permerror-vs-temperror spoke (the SPF result-code RFC-7208-§2.6 reference) when an operator new to SPF/DMARC encounters a permerror verdict and operates under any of the FOUR myth- classes the cross-reference identifies — the spoke documents the canonical compliant per-result-code receiver-side evaluation that the myth-debunking discipline targets.
• SPF qualifiers explained — the MYTH-DEBUNK companion reference for the canonical SoftFail-equals-Fail / ~all-equals-rejection misconception. Where THIS page catalogues operationally-dangerous DMARC and email-authentication misconceptions (the "p=none protects" myth, the "p=quarantine is interim-safe" myth, the "SPF-alone-is-sufficient" myth, the "BEC-is-someone-else's-problem" myth), the SPF-qualifiers spoke is the authoritative reference for one of the most common SPF-specific misconceptions OPERATORS HOLD: the belief that the ~all SoftFail qualifier provides receiver-side REJECTION enforcement equivalent to the -all Fail qualifier. The misconception arises because the SoftFail name SOUNDS LIKE a partial- rejection (cf. HTTP 4xx soft errors) but the RFC 7208 §8 Authentication- Results disposition table prescribes that ~ SoftFail produces an Authentication-Results header value of spf=softfail that receivers SHOULD NOT REJECT solely on that signal, while - Fail produces spf=fail that receivers MAY REJECT at the SMTP layer before DMARC evaluation runs. Operators holding the misconception ship SPF records ending in ~all in the belief they are providing receiver-side rejection of unauthorised IPs, then encounter ATTACKER MESSAGES DELIVERED TO INBOX from non-authorised IPs because the receiver treats SoftFail as monitoring-mode by RFC prescription. The misconception is especially load-bearing because the major getting-started SPF documentation from SendGrid / Mailgun / Postmark / Amazon SES / Google Workspace / Microsoft 365 recommends ~all AS THE DEFAULT deployment-day-1 posture (rationally hedging against the misconfigured--all customer-support cost) — operators following the getting-started documentation INHERIT the ~all default and never revisit the qualifier choice as the sender-inventory stabilises and the deployment matures. The qualifier spoke also documents the SECOND misconception class — the "?all Neutral is observability-only" myth where operators believe Neutral provides post-deployment observability signal but receivers actually treat Neutral as no-policy-applicable (DMARC alignment falls back to DKIM- only evaluation, structurally identical to the absence-of-SPF case) — and the THIRD misconception class — the "+all Pass is harmless" myth where operators believe the explicit-pass qualifier on the all mechanism provides no enforcement either way but actually structurally AUTHORISES ALL IPs on the IPv4 + IPv6 public-internet, rendering the SPF record useless as a sender- authorisation policy assertion. Read the qualifier spoke alongside this myths page when authoring an organisation's MISCONCEPTION-AUDIT operational reference — the all-mechanism qualifier misconception class is one of the most frequently-encountered misconceptions OPERATORS HOLD that is NOT covered in this myths page's DMARC-policy-mode-focused catalogue.
• DMARC Analyzer dashboard — ingests DMARC aggregate (RUA) and forensic (RUF) reports via includes/DmarcParser.php and includes/ForensicReportParser.php, rendering the per-sender / per-IP / per-day breakdown that the remediation checklist references.
• Email Header Analyzer — paste any email's headers and see the per-message SPF, DKIM, DMARC, and alignment results.
• Domain Security Checker — live DNS lookups for SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT, CAA, and DNSSEC via includes/DnsChecker.php.
• DNS Record Generator — wizards for DMARC, SPF, DKIM, BIMI, MTA-STS, TLS-RPT, and CAA records.
• DKIM troubleshooting (symptom-driven diagnostic ladder) — the PERSISTENT-DKIM-MYTH-CLUSTER-RESOLVES- TO-PER-SYMPTOM-DIAGNOSTIC-LADDER-BRANCHES companion to this DMARC-myths catalogue. Where THIS page debunks the SUBJECTIVE MENTAL-MODEL ERRORS around DKIM in single- paragraph form (myth 8 "DKIM is optional once SPF is published", myth 9 "DKIM key rotations break mail", myth 12 "DKIM signatures last forever", myth 14 "DKIM fails are always the signer's fault"), the DKIM-troubleshooting spoke is the OPERATOR-SIDE PER-SYMPTOM DIAGNOSTIC LADDER each myth-class resolves to at the per-receiver per-message verification boundary at FOUR DKIM-myth-to-diagnostic- ladder dimensions: (i) the "DKIM is optional" myth-class resolves to the per-receiver dkim=none verdict branch the troubleshooting spoke documents — where the absence of a DKIM signature on the message produces dkim=none at the receiver, collapses DKIM-alignment to fail under any DMARC policy, and removes the only forwarding-resilient identifier-alignment channel from the operator's authentication posture; the troubleshooting spoke documents the receiver-side dkim=none verdict the operator must investigate; (ii) the "key rotation breaks mail" myth-class resolves to the per- receiver dkim=temperror / dkim=permerror branches the troubleshooting spoke documents during the rotation cutover window — where premature retirement of the old selector before the new selector's CNAME-delegation chain propagates produces a dkim=temperror surge at receivers still resolving the old selector; the spoke's per-symptom decision tree is the canonical operator- side debugging reference rebutting the "rotation breaks mail" myth at the per-symptom evidence layer; (iii) the "DKIM signatures last forever" myth-class resolves to the per-receiver dkim=fail body-hash-mismatch branch the troubleshooting spoke documents — where the publisher's selector public-key TXT record is retired or rotated without dual-key overlap, in-flight messages signed with the now-retired selector produce dkim=fail at receivers; the spoke documents the canonical per-symptom recovery the rotation myth ignores; (iv) the "DKIM fails are always the signer's fault" myth-class resolves to the per-receiver dkim=fail-via-intermediary-modification branch the troubleshooting spoke documents — where mailing-list / forwarder body-modification or footer- injection invalidates the signed body-hash AFTER the legitimate signer's signing operation; the spoke's diagnostic ladder attributes the dkim=fail to the intermediary's body-modification rather than the publisher's signing infrastructure, rebutting the "always the signer's fault" myth at the per-receiver per-message evidence layer. Read the troubleshooting spoke ALONGSIDE this myths-catalogue when an operator pushes back on DKIM deployment discipline with one of the DKIM-related myth-cluster items — the spoke is the per-symptom diagnostic-ladder reference each myth resolves to at the per-receiver per-message verification boundary.
• DKIM replay attacks — the per-message AUTHENTICATED-REPLAY threat-model counter-myth-catalogue companion to this DMARC misconceptions reference. Where THIS page catalogues the persistent operator- facing DMARC myths (including the per-message "DMARC pass means the message is safe" myth and the per-publisher "DMARC blocks all impersonation" myth) and resolves each at the per-myth canonical-rebuttal tier, the DKIM- replay-attacks spoke is the per-message AUTHENTICATED-REPLAY-AS-DMARC-PASS-WITH-NO- ENFORCEMENT-BYPASS deep-dive reference documenting the specific attack class in which a sophisticated attacker captures a legitimately DKIM-signed message from a high-reputation per-publisher per-domain sender (gmail.com, microsoft.com, paypal.com, a major bank or SaaS) and re-broadcasts the byte-for-byte signed message to an attacker- chosen recipient set: because the per-message DKIM signature still cryptographically verifies and the original From: still aligns with the original d=, the per- message DMARC verdict is pass — DMARC applies NO protective enforcement even when the per-publisher per-domain p=reject policy is operationally committed. Three per-myth-to-canonical- rebuttal dimensions the DKIM-replay-attacks spoke supplies the per-myth canonical rebuttal each persistent DMARC-coverage myth this page catalogues at: (i) per-message "DMARC pass means the message is legitimate" myth rebuttal at the per-message authenticated- replay vs unauthenticated-forgery attack- class boundary — the DKIM-replay- attacks spoke documents the per-message verdict-stamping discipline at which an authenticated-replay message DOES produce a per-message DMARC pass verdict despite the per-message recipient set being attacker-controlled, supplying the per-message threat-model boundary rebuttal the "DMARC pass means safe" myth requires at the per-message verdict-interpretation boundary; (ii) per-publisher per- domain "DMARC blocks all impersonation" myth rebuttal at the per-publisher per- domain threat-model coverage boundary — the DKIM-replay-attacks spoke documents the per-publisher per-domain RFC 7489 §2.4 + §11 DMARC threat-model scope (DMARC covers per-message unauthenticated-forgery but NOT per-message authenticated-replay), supplying the per-publisher per-domain threat-model boundary rebuttal the "DMARC blocks all impersonation" myth requires at the per-publisher per-domain coverage- boundary tier; (iii) per-publisher per-domain "p=reject is sufficient" myth rebuttal at the per-publisher per-domain enforcement-coverage-gap boundary — the DKIM-replay-attacks spoke documents the per-publisher per-domain residual- threat-class p=reject does NOT cover (the per-message authenticated- replay class) and the OUT-OF-BAND per- publisher per-selector DKIM-key-rotation cadence (documented in help_dkim_key_rotation.php) + per-publisher per-message receiver-side replay-cache defence + per-message IETF DKIM-bis body-length-restricted-replay future-protocol-extension that bound the per-publisher per-domain residual replay attack surface, supplying the per-publisher per-domain residual-threat-class rebuttal the "p=reject is sufficient" myth requires at the per-publisher per- domain enforcement-completeness boundary. Read the DKIM-replay-attacks spoke ALONGSIDE this myths catalogue when an operator pushes back on the per-publisher per-domain DMARC threat-model boundary with one of the DMARC-coverage myth- cluster items — the spoke is the per- message authenticated-replay deep-dive reference each myth resolves to at the per-publisher per-domain DMARC threat- model-coverage boundary.
• DKIM alignment with DMARC — the DKIM-identifier-alignment-discipline deep-dive (the RFC 6376 d=-tag signing-domain match against the RFC 5322 From: header organisational domain per RFC 7489 §3.1.1, the per-tenant relaxed vs strict adkim= mode toggle, the per-message multi-signature composition rule for distinct signer domains, the third-party-ESP DKIM-aligned-pass escape hatches via per-domain CNAME-delegated DKIM publication) whose per-message DKIM- ALIGNMENT verdict is the LOAD-BEARING per-message rebuttal evidence for FOUR persistent DKIM-vs-DMARC myths THIS page catalogues: (i) "DKIM-Signature presence means DMARC pass" myth — the canonical DMARC composite-verdict rule REQUIRES the DKIM signature to be ALIGNED (the signing d= domain matching the From: organisational domain) per RFC 7489 §6.6.2, not merely cryptographically valid; a per-message DKIM-Signature with unaligned d= (e.g., d=mailgun.org for a From: alice@example.com message) is per-message DKIM-VALID-BUT- DKIM-MISALIGNED and contributes ZERO to the DMARC composite verdict regardless of signature cryptographic integrity; (ii) "Relaxed alignment is dangerous" myth — the canonical DMARC relaxed alignment mode treats organisational- domain match (d=mail.example.com ≈ From: alice@example.com) as aligned via Public Suffix List organisational-boundary resolution per RFC 7489 §3.1.1, which is the DEFAULT operationally-safe choice for most publishers; the DKIM-alignment-with- DMARC spoke documents WHEN strict mode (adkim=s requiring exact domain match) is operationally appropriate vs WHEN it breaks legitimate third-party-ESP DKIM publication; (iii) "Adding DKIM to an existing SPF setup instantly gives DMARC enforcement" myth — the canonical DMARC composite- verdict-construction rule requires at least one of SPF-ALIGNED-pass OR DKIM- ALIGNED-pass per RFC 7489 §6.6.2, not merely DKIM-cryptographically-valid; publishers who add DKIM via a third- party ESP signing with a non-aligned d= domain (e.g., the ESP's bounce-tracking subdomain) discover their DMARC alignment-fail rate UNCHANGED because the new DKIM signature is DKIM-VALID-BUT-DKIM- MISALIGNED; the DKIM-alignment-with- DMARC spoke documents the per-third- party-ESP CNAME-delegated DKIM publication discipline that achieves per-message DKIM-ALIGNED-pass; (iv) "p=quarantine and p=reject are equivalent in practice" myth — the per-message DKIM-aligned-pass-rate floor is the LOAD-BEARING per- publisher per-domain ramp-advancement gate distinguishing operationally-safe p=quarantine from operationally-risky p=reject progression; publishers with a low per-day DKIM-aligned-pass-rate floor MUST NOT ramp to p=reject regardless of catalogue-mythology certainty, because the per-receiver per-day legitimate-mail-loss rate directly tracks the per-receiver per- day DKIM-aligned-pass-rate gap. Read the DKIM-alignment-with-DMARC spoke ALONGSIDE this myth catalogue when operators raise "but DKIM is signed, why doesn't DMARC pass?" — the spoke is the per-message DKIM-alignment- mechanic deep-dive each catalogue- myth resolves to at the per-publisher per-domain DMARC composite-verdict construction boundary.
• DKIM selectors explained — the PER-PUBLISHER-PER-DOMAIN-PER- SELECTOR-DKIM-PUBLICATION-DISCIPLINE-MYTH- CLARIFICATION companion to this DMARC myth catalogue. Where THIS page debunks the 18 recurring per-publisher per-domain DMARC mental-model ERRORS, the DKIM- selectors spoke documents the per- publisher per-domain per-selector DKIM- signing-key namespace discipline that CLARIFIES three DKIM-selector-specific mental-model errors orthogonal to the 18 DMARC-level myths: (i) "one selector is enough" — operators publish a single per-domain selector and assume the per-domain per-selector signing-key never needs replacement; the spoke clarifies that the per-publisher per- domain per-selector overlap-window rotation cadence is the operationally- grounded anti-compromised-key discipline every per-publisher per-domain DKIM infrastructure STRUCTURALLY DEPENDS on; (ii) "DKIM keys never need rotating" — operators treat the per- selector signing-key as a one-time publication artifact; the spoke clarifies that per-selector rotation cadence integrity is the per-publisher per-domain anti-replay-and-anti- compromised-key control surface every per-publisher per-domain DMARC-aligned- pass-rate floor STRUCTURALLY DEPENDS on; (iii) "multiple selectors mean multiple domains" — operators misread the per-publisher per-domain per-selector namespace partition as a per-domain partition; the spoke clarifies that per-selector partitioning is the per-publisher per-domain per-sender-cohort signing-scope isolation primitive, not a per-domain identity primitive. Pair THIS myth catalogue WITH the DKIM-selectors spoke when ONBOARDING per-publisher per-domain operators whose DKIM mental-model ERRORS interfere with the per-publisher per-domain per-selector DKIM-publication- and-rotation discipline every per- publisher per-domain DMARC enforcement ramp STRUCTURALLY DEPENDS on.
• DMARC for SaaS senders — the SaaS-multi-tenant-relay companion catalogue to this cluster-spanning DMARC myths-and-misconceptions reference. Where THIS page documents the per-myth empirical-counterexample catalogue (myths like "SaaS-relay cannot do DMARC", "shared-IP-pool makes DMARC impossible", "DKIM CNAME-delegation breaks alignment", "per-customer p=reject is unsafe at SaaS-scale"), the SaaS-senders spoke documents the canonical per-SaaS-vendor per-customer-domain DMARC publication discipline whose continuous operation ACROSS THE MAJOR SAAS-VENDOR-RELAY- ECOSYSTEM is the load-bearing per-myth empirical-counterexample for the SaaS- DMARC subset of the myth catalogue THIS page refutes. The DMARC-MYTHS-VS- SAAS-RELAY cross-reference establishes FOUR coupling dimensions: (i) "SaaS-relay cannot do DMARC" myth empirically refuted by per-SaaS- vendor per-customer-domain CNAME- delegation discipline at scale — Mailchimp, SendGrid, Klaviyo, Postmark, and per-vendor production deployments continuously emit per-customer-domain DMARC-aligned mail at per-vendor scale; the SaaS spoke documents the empirical per-vendor per-customer deployment discipline whose continuous operation is the per-myth empirical-counterexample evidence; (ii) "shared-IP-pool makes DMARC impossible" myth empirically refuted by per-customer-domain DKIM- CNAME-delegation publication discipline — DMARC alignment runs on the From-header organisational domain, NOT the per-SaaS-vendor shared- IP pool's PTR; the SaaS spoke documents the per-customer DKIM-CNAME publication-substrate that makes per- customer DMARC alignment achievable regardless of shared-IP-pool topology; (iii) "DKIM CNAME-delegation breaks alignment" myth empirically refuted by per-customer per-SaaS-vendor d= tag binding — when the per-customer-domain CNAME at <selector>._domainkey.<customer-domain> delegates to a SaaS-vendor-controlled target, the resulting DKIM-Signature d=<customer-domain> binds to the From-header organisational domain perfectly; the SaaS spoke documents the per-customer per-vendor CNAME-delegation publication contract this empirical refutation evidence anchors; (iv) "per-customer p=reject is unsafe at SaaS-scale" myth empirically refuted by per-SaaS-vendor per-customer-domain ramp-as-a-service discipline — major SaaS-vendor DMARC-as-a-service offerings provide per-customer-domain p=none → p=quarantine → p=reject ramps with per-customer aggregate-report consumption and per- customer per-vendor staged-rollout safety; the SaaS spoke documents the per-customer per-vendor ramp-as-a- service discipline whose per-customer operational safety is the per-myth empirical-counterexample for the SaaS- scale-safety subset of the myth catalogue. Read the SaaS-senders spoke when refuting the SaaS-DMARC subset of the myth catalogue via empirical evidence from production per-SaaS-vendor per-customer-domain DMARC deployment operation.
• DMARC for transactional email — the LITERAL-MYTH-CLASS-REBUTTAL-VIA- TRANSACTIONAL-ESP-EVIDENCE companion to this DMARC-myths reference. Where THIS page debunks the universal DMARC misconceptions and the sibling SaaS- senders spoke above debunks the SaaS- multi-tenant subset, the transactional- email spoke debunks the STRUCTURALLY-DISTINCT transactional-ESP myth subset operators routinely bring to DMARC rollout when the per-domain sender-inventory includes one or more of the eight canonical transactional-ESP platforms (SendGrid, Mailgun, Postmark, Amazon SES, SparkPost, Mailjet, Mandrill, Resend): (i) "TRANSACTIONAL ESPs CAN'T BE DMARC-ALIGNED BECAUSE THEY SHARE OUTBOUND IPs WITH OTHER TENANTS" — refuted because per-message DMARC evaluation is per-message-identifier- alignment-driven not per-source-IP- attribution-driven; every transactional ESP supports per-tenant DKIM d=<customer-domain> signing via CNAME-delegated selectors that produce dkim-aligned-pass at the receiver regardless of the shared-IP pool's contribution to the SPF leg; (ii) "I CAN'T MOVE TO p=reject WHILE USING A TRANSACTIONAL ESP BECAUSE THE ESP MIGHT FORGET TO SIGN" — refuted because the per-tenant per-ESP-account dkim-aligned-pass-rate on the production-traffic baseline (visible in RUA aggregate-report rows with the ESP's per-tenant d=<customer-domain> and the per-ESP-specific selector) is the operationally-correct gate for p=reject cutover — operators routinely confirm 99.9%+ dkim-aligned-pass-rate at the ESP before cutover; (iii) "THE ESP'S FROM-HEADER REWRITE BREAKS DMARC ALIGNMENT" — refuted because modern ESPs let the tenant author the per-message From: header at the customer-domain organisational domain (the rewrite-on-send antipattern is legacy and deprecated); the per-tenant per-ESP-account configuration toggle to suppress From-header-rewrite is well-documented across all eight canonical platforms; (iv) "THE BOUNCE-DOMAIN ON A TRANSACTIONAL ESP CAN'T BE ALIGNED TO MY CUSTOMER-DOMAIN, SO SPF-ALIGNED-PASS IS IMPOSSIBLE" — refuted because SPF alignment with aspf=r relaxed-mode (the canonical RFC 7489 default) produces SPF-aligned-pass on every bounce-domain that is a subdomain of the customer-domain organisational domain; ESPs offer per-tenant bounce-subdomain customization that makes bounce.<customer-domain> the operational standard, achieving SPF-aligned-pass under aspf=r trivially. Read the transactional-email spoke when refuting the per-tenant transactional-ESP-DMARC-impossibility myth subset, when defending the rollout plan to p=reject on a customer- domain that uses one or more transactional ESPs, or when composing transactional-ESP-specific DMARC-rollout runbooks that operationally rebut the per-myth pushback grounded in shared-IP misconception.
• DKIM key rotation — the LITERAL-MYTH-CLASS-REBUTTAL-VIA-DKIM- KEY-ROTATION-EVIDENCE companion to this DMARC-myths reference. Where THIS page catalogues the per-publisher per-domain DMARC deployment myth-class taxonomy (the "DMARC breaks legitimate email" / "DMARC is only for enterprise senders" / "`p=none` provides protection" / "one DKIM key lasts forever" / "DKIM keys never need rotating" myth subsets and their empirical-evidence- based rebuttals), the DKIM-key-rotation spoke is the LITERAL PROTOCOL EVIDENCE primitive whose per-publisher per-selector 90-180-day rotation cadence + dual-selector overlap discipline + per-key revocation- via-empty-`p=` publication discipline DIRECTLY REFUTES the DKIM-key-rotation myth subset. FOUR DKIM-rotation-myth rebuttal dimensions: (i) myth: "DKIM keys never need rotating" — REBUTTED by RFC 8301-recommended 90-180-day rotation cadence as load-bearing per-publisher per-selector operator- discipline floor — the DKIM-key- rotation spoke documents the RFC 8301- recommended 90-180-day rotation cadence as the LITERAL PROTOCOL EVIDENCE refuting the "DKIM keys never need rotating" myth class, catalogues the per-publisher per-selector key-compromise window the per-publisher operator-discipline floor bounds, and documents the per-publisher per-selector post-rotation propagation-window-floor coordination discipline the per-publisher per-domain operator MUST author for per- receiver propagation-window-floor compliance; (ii) myth: "one DKIM key lasts forever" — REBUTTED by per-publisher per- selector dual-selector overlap-window rotation cadence as canonical per-publisher per-selector key-lifetime bounded-window discipline — the DKIM-key-rotation spoke documents the per-publisher per- selector dual-selector overlap-window rotation cadence (concurrent publication of `selector1._domainkey` + `selector2._domainkey` across the per-receiver per-resolver-cache eviction window) as the LITERAL PROTOCOL EVIDENCE refuting the "one DKIM key lasts forever" myth class, and catalogues the per- publisher per-selector key-lifetime bounded- window operator-discipline whose regression produces per-receiver dkim=permerror verdicts; (iii) myth: "DKIM key compromise does not require incident response" — REBUTTED by per-publisher per-selector revocation-via-empty-`p=` publication + emergency rotation as canonical per- publisher per-selector key-compromise incident-response discipline — the DKIM-key-rotation spoke documents the per-publisher per-selector revocation-via- empty-`p=` publication (`v=DKIM1; p=;` empty-public-key) PLUS emergency rotation to a new per-selector key as the LITERAL PROTOCOL EVIDENCE refuting the "DKIM key compromise does not require incident response" myth class, catalogues the per- publisher per-selector RFC 2308 negative- cache window the per-publisher per-selector revocation-effective-latency floor bounds, and documents the per-publisher per-domain incident-response runbook the per-publisher operator MUST author at the per-DNS-zone- management boundary; (iv) myth: "RSA-1024-bit DKIM keys are sufficient" — REBUTTED by RFC 8301 RSA-2048-bit key-strength minimum enforcement at Gmail / Outlook.com / Yahoo Mail as canonical per-publisher per-selector key-strength-floor operator-discipline — the DKIM-key-rotation spoke documents the RFC 8301 RSA-2048-bit key-strength minimum as the LITERAL PROTOCOL EVIDENCE refuting the "RSA-1024-bit DKIM keys are sufficient" myth class, catalogues the per-receiver Gmail / Outlook.com / Yahoo Mail per- publisher per-selector dkim=neutral verdict enforcement at the RFC 8301 key-strength minimum, and documents the per-publisher per-selector legacy-RSA-1024-to-RSA-2048 remediation through per-selector rotation as the per-publisher per-domain operator- discipline-floor remediation discipline. Read the DKIM-key-rotation spoke alongside this DMARC-myths reference when REFUTING the DKIM-rotation myth subset via empirical evidence from per-publisher per-selector production DKIM-rotation operation, when AUTHORING per-publisher per-domain DKIM- rotation runbooks that DIRECTLY REBUT the "DKIM keys never need rotating" + "one DKIM key lasts forever" + "DKIM key compromise does not require incident response" + "RSA-1024-bit DKIM keys are sufficient" myth-class subset, or when AUDITING the per-publisher per-selector DKIM-key-lifetime posture for RFC 8301 90-180-day rotation cadence compliance.
• SPF DNS record syntax — the PER-PUBLISHER-PER-DOMAIN-SPF- RECORD-BYTE-LEVEL-PUBLICATION-DISCIPLINE-AS- CANONICAL-REBUTTAL-EVIDENCE companion to this DMARC-myth catalogue. Where THIS page documents the per-publisher DMARC-myth catalogue (myths spanning SPF + DKIM + DMARC + ARC + MTA-STS + TLS-RPT), the SPF-DNS- record-syntax spoke is the per-publisher-per- domain SPF-side byte-level publication reference that DIRECTLY REBUTS the SPF-myth- class subset at FOUR per-myth-category refutation-evidence dimensions: (i) per-publisher "SPF alone is sufficient" myth as PER-MESSAGE-FORWARDER-BREAKS-SPF-AT- SECOND-HOP rebuttal-evidence — the per-publisher per-domain SPF DNS record syntax reference documents that v=spf1 validates the per-source-IP envelope-MAIL- FROM at the per-message ingress receiver BUT cannot survive per-message forwarder rewrites that change the per-source-IP at the second-hop (per RFC 7208 §10.4), so the per-publisher "SPF alone is sufficient" myth is REFUTED by the per-source-IP- forwarder-rewrite semantics encoded in the v=spf1 record syntax itself; (ii) per-publisher "+all is fine" myth as PER- SOURCE-IP-OPEN-RELAY rebuttal-evidence — the per-publisher SPF DNS record's +all qualifier explicitly authorises EVERY per-source-IP on the internet to send mail from the per- publisher domain (an open-relay authorisation that per-source-IP-spoof attackers can per-source-IP-trivially exploit), so the per-publisher "+all is fine" myth is REFUTED by the per-source- IP-qualifier semantics encoded in the SPF record syntax: ~all (softfail) is the per-publisher transition qualifier; -all (hardfail) is the per-publisher production-discipline terminal qualifier; +all is the per-publisher per-source-IP- open-relay-publication antipattern; (iii) per-publisher "SPF lookup limit is just a suggestion" myth as PER-MESSAGE- SPF-PERMERROR rebuttal-evidence — the per-publisher per-domain SPF DNS record's 10-DNS-lookup limit (RFC 7208 §4.6.4) is a per-receiver per-message evaluation HARD STOP — per-publisher SPF records that exceed 10 nested DNS lookups produce per-message spf=permerror at the per-receiver evaluation step, downgrading per-publisher per-message DMARC alignment to DKIM-only and breaking per-receiver- side per-publisher deliverability — so the per-publisher "SPF lookup limit is just a suggestion" myth is REFUTED by the per-publisher per-receiver per- message permerror cascade the SPF DNS record syntax reference documents the operational consequence of; (iv) per-publisher "macro syntax is exotic and unsafe" myth as PER-RECEIVER-PER- MESSAGE-MACRO-EXPANSION-IS-NORMATIVE rebuttal-evidence — the per- publisher SPF DNS record syntax reference documents that RFC 7208 §7 macro-expansion (per-receiver per-message %{i} sender-IP, %{s} sender-address, %{h} sender-HELO, %{d} sender-domain substitution) is a NORMATIVE per- receiver-evaluator-mandatory feature, not an exotic optional extension — so the per-publisher "macro syntax is exotic and unsafe" myth is REFUTED by the per-publisher per-receiver-mandatory per-message macro-expansion semantics encoded in the SPF record syntax normative reference. Read the SPF DNS record syntax spoke alongside this DMARC-myth catalogue when REFUTING the SPF-myth-class subset via per-publisher per-domain v=spf1 record byte-level publication-discipline evidence, when AUTHORING per-publisher per-domain SPF- myth refutation runbooks that DIRECTLY REBUT the "SPF alone is sufficient" + "+all is fine" + "SPF lookup limit is just a suggestion" + "macro syntax is exotic and unsafe" myth-class subset, or when AUDITING the per-publisher per- domain SPF DNS record's per-source-IP envelope-MAIL-FROM authorisation publication discipline against the per-mechanism per-qualifier byte-level syntax-conformance reference.
• RFC 7489 — DMARC — the canonical DMARC specification referenced throughout this page.
• RFC 9091 — DMARC Reporting (errata) — IANA DMARC reporting registry.
• RFC 7208 — SPF
• RFC 6376 — DKIM
• RFC 8617 — ARC
• RFC 8461 — MTA-STS
• RFC 8460 — TLS-RPT
• RFC 5321 — SMTP (envelope MAIL FROM)
• RFC 5322 — Internet Message Format (From: header)
• DKIM best practices — the CANONICAL-DEPLOYMENT-DISCIPLINE- COUNTER-CATALOGUE-TO-EVERY-DKIM-MYTH companion to this DMARC-myths reference. Where THIS page debunks the persistent misconceptions around DMARC, SPF, and DKIM (1024-bit-is-fine, key-rotation-is- overkill, c=simple-survives-mailing- lists, single-selector-forever), the DKIM-best-practices spoke documents the canonical DKIM publication-and-rotation discipline that DIRECTLY COUNTERS each persistent DKIM myth catalogued here. Concretely, the spoke documents FOUR per-DKIM-myth-to-canonical-best-practice rebuttal dimensions: (i) 2048- bit RSA key-strength floor as the canonical counter to the 1024-bit-is- adequate myth — the spoke documents why the 1024-bit RSA legacy floor cited in many older operations playbooks (this page's §4 DKIM-myth cluster) is no longer adequate for modern receiver-side DKIM-strength scoring; the canonical best-practice is 2048-bit RSA minimum with Ed25519 as the alternative for organisations constrained by the 512-byte single- TXT-RR limit; (ii) periodic selector-rotation cadence as the canonical counter to the publish-once- forget myth — the spoke documents the 90-day-to-12-month selector-rotation cadence that directly counters the persistent publish-once-and-forget DKIM myth this page's §5 DKIM-rotation cluster addresses, with the overlap-window dual-selector publication discipline as the canonical zero-downtime rotation primitive; (iii) c=relaxed/ relaxed canonicalisation as the canonical counter to the c=simple-is- safer myth — the spoke documents why c=relaxed/relaxed is the canonical mailing-list- and-forwarder-survivable default that directly counters the c=simple-is- body-integrity-safer myth this page's §6 catalogues — c=simple body- canonicalisation rarely survives forwarder line-wrap normalisation and produces high false-positive dkim=fail rates; and (iv) per-tenant selector partitioning as the canonical counter to the single-selector-forever myth — the spoke documents the per-tenant / per-service selector partitioning discipline (each sending service / business unit publishing under its own selector) that directly counters the single-selector-for-the- whole-organisation myth this page's §7 addresses — per-tenant selectors enable independent rotation cadences, per-tenant key-compromise blast-radius containment, and per-tenant accountability. Read the DKIM-best- practices spoke alongside this DMARC- myths reference when the operations team is rebuilding the DKIM deployment discipline against the canonical best-practice catalogue this page's DKIM-myth cluster recommends replacing.
• DKIM-Signature header anatomy — the DKIM-SIGNATURE-HEADER-TAG-BYTE- ANATOMY-AS-CANONICAL-REFUTATION-OF-FOUR- PERSISTENT-DKIM-SIGNATURE-PRESENCE-AND- DKIM-IDENTITY-AND-DKIM-MAIL-INTEGRITY-AND- DKIM-AUTHOR-IDENTITY-MISCONCEPTIONS companion to this DMARC-myths reference. Where THIS page debunks the persistent misconceptions around DMARC, SPF, and DKIM — including the canonical-DKIM-signature- presence-equals-authentic-sender false equivalence, the DKIM-d=tag-equals-RFC5322- From-author-domain false identity claim, the DKIM-bh=tag-protects-against-all-body- modification overreach, and the DKIM-i=tag- proves-individual-author overreach — the DKIM-signatures-explained spoke is the per- tag BYTE-LEVEL HEADER ANATOMY canonical refutation reference documenting the FOUR per-DKIM-Signature-tag-vs-misconception- rebuttal dimensions: (i) b= signature-value tag is per-message cryptographic proof of the publisher's d=-tag domain authorising the message — NOT proof of the RFC 5322 From: author-domain authenticity — the canonical refutation of the "DKIM-Signature presence equals authentic sender" myth catalogued on this page is that d=-tag and From:-author-domain can differ (the entire DMARC identifier- alignment evaluation algorithm exists to evaluate that gap); a DKIM-Signature with d=esp.example.com validates the ESP's signature but says NOTHING about the From: marketing@your-company.com author- domain unless DMARC alignment passes; (ii) h= signed-header-list tag delimits per-message signature coverage to the listed headers — additional author-controlled headers below the coverage floor PASS DKIM verification without being cryptographically protected — the canonical refutation of the "DKIM protects against all header forgery" overreach catalogued on this page is that any header NOT in the h= tag (X-Original-From, From-Display-Name override, additional Reply-To) sits OUTSIDE the signature math and can be attacker-injected without affecting the DKIM-pass verdict; (iii) bh= body-hash tag + l= body-length-limit tag constrain per-message body-coverage to N bytes — body bytes BEYOND the l=-bounded coverage floor PASS DKIM verification even when modified — the canonical refutation of the "DKIM-bh proves entire body integrity" overreach catalogued on this page is that the l=-tag (when published) creates a body-coverage truncation surface that attackers exploit by appending arbitrary payload below the l=-bounded floor — the per- publisher canonical best-practice is to OMIT the l=-tag entirely, forcing whole-body coverage; (iv) i= identity tag is per-publisher-internal sub-identity marker — NOT proof of individual author identity — the canonical refutation of the "DKIM-i=tag proves the individual author" overreach catalogued on this page is that the i=- tag is publisher-controlled (the publisher can populate it with any sub-identity it chooses) and provides no end-to-end author identity guarantee — DKIM authenticates the SIGNER, not the AUTHOR. Read DKIM- signatures-explained as the per-tag byte- anatomy reference when debunking the DKIM-signature-presence-equals-authentic- sender misconception cluster this page catalogues — the spoke's per-tag rebuttal catalogue is the canonical operator education surface for re-grounding the DKIM-Signature header's actual semantic scope.
• DMARC deployment checklist — the PHASE-1-THROUGH-PHASE-5-DMARC- DEPLOYMENT-CHECKLIST-AS-LOAD-BEARING- REBUTTAL-OF-DEPLOYMENT-ROADBLOCK-MYTH- CLUSTER companion to this DMARC-myths-and- misconceptions reference. Where THIS page catalogues the per-publisher per-domain DMARC-deployment myth-and-misconception cluster (the "DMARC will block my legitimate mail" deployment-anxiety myth + the "p=reject is the only safe target" all- or-nothing deployment-target myth + the "set-and-forget no ongoing monitoring required" abandonment-pattern myth + the "DMARC=fail at receiver guarantees rejection" deterministic-disposition- misreading myth + the misconceptions around DKIM-signature-presence, SPF-pass-equals- DMARC-pass, and pct= semantics), the DMARC- deployment-checklist spoke is the canonical 5-phase deployment-discipline reference whose Phase 1 baseline-publication + Phase 2 testing-mode-with-observability + Phase 3 pct=-ramp enforcement-transition + Phase 4 full-quarantine-enforcement + Phase 5 full- reject-enforcement-with-cross-layer- transport-hardening checklist directly rebuts the four canonical deployment- roadblock myth-classes THIS page catalogues at four myth-class-to-deployment-phase coupling dimensions: (i) the "DMARC will block my legitimate mail" deployment- anxiety myth is rebutted by Phase 2's canonical p=none + rua=mailto: testing-mode + observability-baseline checklist step — Phase 2 publishes p=none with rua=mailto: collecting per-publisher per-source-IP DMARC-aligned-pass-rate data for typically 30-90 days BEFORE any receiver-side enforcement disposition change; the per-publisher per-domain operations team observes every per-source- IP per-message DMARC-aligned-pass-rate emergence in the per-publisher per-domain rua aggregate-XML stream and remediates per-source-IP DMARC-aligned-pass-rate gaps BEFORE flipping the per-publisher per- domain p= tag to quarantine or reject; (ii) the "p=reject is the only safe target" all-or-nothing deployment-target myth is rebutted by Phase 3's canonical pct=10/25/50/75/100 ramp-enforcement- transition checklist step — Phase 3 ramps the per-publisher per-domain pct= tag from 0% to 100% in incremental steps, each step held for sufficient observability- window time to verify no per-publisher per- source-IP DMARC-aligned-pass-rate regression emerges at the per-step ramp boundary BEFORE advancing the pct=-tag to the next ramp step; (iii) the "set-and- forget no ongoing monitoring required" abandonment-pattern myth is rebutted by Phase 4/Phase 5's canonical ongoing- observability + per-source-IP DMARC- aligned-pass-rate-trend-detection + per-source-IP forensic-investigation ongoing-discipline checklist step — Phase 4/Phase 5 specify ongoing per-publisher per-domain operations-team rua aggregate-XML stream ingestion + per- source-IP DMARC-aligned-pass-rate-trend- detection KPI + per-publisher per-source- IP forensic-investigation per-failure- class-attribution discipline at the per- publisher per-domain operational steady- state boundary; (iv) the "DMARC=fail at receiver guarantees rejection" deterministic-disposition- misreading myth is rebutted by Phase 5's canonical receiver-discretionary- disposition + ARC-trusted-sealer-override + receiver-side-bypass-list discipline- documentation checklist step — Phase 5 documents the canonical per- receiver-cohort discretionary-disposition behavior (Microsoft Defender quarantine- bias vs Google Workspace reject-bias vs consumer-Gmail spam-folder-bias vs Yahoo bulk-folder-bias) + per-receiver Trusted- ARC-Sealer-override behavior + per- receiver canonical-sender-bypass-list behavior that EVERY per-publisher per- domain DMARC=reject publication actually encounters at the per-receiver per- message disposition-evaluation boundary. Read the DMARC-deployment-checklist spoke ALONGSIDE this myths-and-misconceptions reference whenever an operator encountering deployment-anxiety myth- cluster pushback from per-publisher per- domain stakeholders needs the canonical 5-phase deployment-discipline reference whose phased-rollout checklist is the load-bearing operational-discipline rebuttal of every deployment-roadblock myth-class catalogued on THIS page.
• MTA-STS vs DANE for SMTP — the TRANSPORT-SECURITY- PROTOCOL-CHOICE-AND- INTERCHANGEABILITY-MYTH-CLUSTER- REBUTTAL companion to this DMARC- myths-and-misconceptions reference. Where THIS page catalogues the canonical DMARC myth taxonomy (deployment- anxiety, alignment confusion, reporting-pipeline-overestimation, and the transport-security- protocol-conflation cluster), the mta_sts_vs_dane spoke documents the RFC-8461-vs-RFC-7672 trust- anchor decision matrix that EMPIRICALLY REBUTS the four recurring transport-security- protocol-conflation myths operators carry into the DMARC rollout conversation. FOUR structurally-distinct PER- TRANSPORT-LAYER-MYTH-VS-DECISION- MATRIX-COUPLING-DIMENSIONS the mta_sts_vs_dane comparison spoke operationally rebuts: (i) "DMARC implies TLS encryption / publishing DMARC automatically secures the SMTP path" myth-class — REBUTTED via the orthogonal-protocol-layer decision-matrix — the myth conflates DMARC's application-layer authentication (SPF + DKIM + alignment per RFC 7489) with transport-layer confidentiality (TLS-encrypted SMTP per RFC 3207 STARTTLS); the mta_sts_vs_dane spoke documents the RFC 8461 (MTA-STS) and RFC 7672 (DANE for SMTP) protocol choices that PUBLISHERS MUST separately deploy to enforce SMTP-path TLS — DMARC publication alone does NOT touch the SMTP- path TLS-enforcement layer; (ii) "MTA-STS and DANE are interchangeable / pick one" myth- class — REBUTTED via the RFC 7672 §1.3 coexistence rule and the per-trust-anchor support matrix — the myth assumes the two TLS-enforcement protocols are functionally equivalent; the mta_sts_vs_dane spoke documents the structurally- distinct trust-anchor models (RFC 8461 anchors trust in the public Web-PKI HTTPS-fetched policy file; RFC 7672 anchors trust in DNSSEC-signed TLSA records) and the per-receiver support matrix (Gmail / Yahoo / Microsoft are MTA-STS-only; major German / Dutch / Scandinavian ISP-mailbox operators are DANE-only; some publishers must publish BOTH per the RFC 7672 §1.3 coexistence rule) that empirically rebuts the interchangeability assumption; (iii) "Deploying both MTA-STS and DANE creates protocol conflicts / breaks mail flow" myth-class — REBUTTED via the RFC 7672 §1.3 sender-side preference order specification — the myth assumes dual-publication is operationally risky; the mta_sts_vs_dane spoke documents the RFC 7672 §1.3 deterministic sender-side preference order (DANE-aware senders MUST prefer TLSA when both are published; senders without DANE support MUST fall back to the MTA-STS HTTPS-PKI policy file) that empirically rebuts the dual-publication- conflict assumption; (iv) "DANE requires zone-wide DNSSEC and is too risky to deploy" myth-class — REBUTTED via the scoped DNSSEC chain-of- trust requirement per RFC 7672 §3.1 — the myth overestimates the DNSSEC deployment surface; the mta_sts _vs_dane spoke documents the precise scope of the DNSSEC requirement (every ancestor zone from the root down to the TLSA- publishing zone MUST be DNSSEC- signed — but the requirement is SCOPED to the TLSA-publishing zone hierarchy, not to every zone the publisher operates) and the per-protocol-choice deployment-risk matrix that empirically rebuts the overstated DANE-deployment-risk assumption. Read the mta_sts_vs_dane comparison spoke ALONGSIDE this myths-and-misconceptions reference whenever an operator encountering transport-security- protocol-conflation myth-cluster pushback from per-publisher per- domain stakeholders needs the canonical RFC-8461-vs-RFC-7672 decision-matrix rebuttal whose operationally-grounded per-myth coupling-dimension catalogue is the load-bearing protocol- choice-clarity rebuttal of every transport-security-protocol- conflation myth-class operators bring into the DMARC rollout conversation.
• DKIM failures explained — the OPERATIONAL-EVIDENCE REBUTTAL-EVIDENCE-STREAM companion to this DMARC myths-and- misconceptions catalogue. Where THIS page refutes the DMARC-as-a- whole myth-classes operators bring into the DMARC rollout conversation, the DKIM-failures-explained spoke documents the four-class verdict-failure taxonomy (bodyhash-mismatch, signature-mismatch, permerror, temperror) whose per-class operational diagnostic-attribution discipline is the load-bearing evidence stream this myths catalogue's DKIM-specific myth rebuttals depend on for operationally- grounded refutation. Read THIS page when DECONSTRUCTING DKIM-failure myths against operationally-grounded evidence; read the DKIM-failures spoke when DECODING the per-class evidence-stream rows that anchor the myth rebuttals THIS catalogue publishes.
• SPF forwarding issues — the per-message forwarder-induced envelope-MAIL-FROM-IP-rewrite as operationally- grounded refutation evidence companion to this myths catalogue. Where THIS page deconstructs the SPF-alone-is-sufficient / SPF-protects-against-spoofing / DMARC- inherits-SPF-guarantees myth class against operationally-grounded evidence, the SPF- forwarding-issues spoke documents the per-message FORWARDER-INDUCED upstream mechanic that is the LOAD-BEARING evidence stream the myth rebuttals reach for to operationally-ground their refutation. Four MYTH-CLASS-VS-FORWARDING-FAILURE-MECHANIC cross-correlation axes the SPF-forwarding- issues spoke documents: (i) the "SPF alone is sufficient" myth class is REFUTED by the per-message second-hop SPF break — whenever a recipient-side auto- forwarder, mailing list, or vacation-rule rewrites the envelope to its own infrastructure IP, the second-hop receiver evaluates the rewritten IP against the original publisher's SPF record and produces spf=fail on a legitimate message, demonstrating that SPF alone cannot survive the forwarding scenario operators encounter at scale; (ii) the "SPF protects against spoofing" myth class is REFUTED by the per-source-IP attribution observation operators read in the RUA stream — forwarder- induced spf=fail rows are STRUCTURALLY INDISTINGUISHABLE from spoofing-induced spf=fail rows WITHOUT cross-correlation against DKIM-pass attribution, ARC trust-chain attribution, and per-source-IP ASN attribution, demonstrating that SPF alone cannot operationally distinguish a benign forwarder from a spoofing actor; (iii) the "DMARC inherits SPF's guarantees" myth class is REFUTED by the per-message DKIM-aligned-pass + SPF-fail rescue pattern — when a forwarder rewrites the envelope but PRESERVES the From-header- aligned DKIM signature, the DMARC engine evaluates spf=fail + dkim=pass + dkim_aligned=yes as a DMARC- aligned-pass under relaxed mode, demonstrating that DMARC's per-message disposition is STRUCTURALLY INDEPENDENT of SPF's per-message verdict; (iv) the "we don't need ARC because we have SPF" myth class is REFUTED by the per-message ARC-trust-anchored rescue path documented in help_arc_explained.php — when BOTH SPF AND DKIM fail at the second- hop receiver (the body-mutating mailing-list intermediary pattern), only the ARC trust- chain anchored to a known-trustworthy ARC sealer can rescue the legitimate-message verdict, demonstrating that SPF-alone- thinking cannot survive the dual-failure forwarding scenario at scale. Read THIS page when DECONSTRUCTING SPF-alone-is- sufficient myths against operationally- grounded evidence; read the SPF-forwarding- issues spoke when DECODING the per-message forwarder-induced second-hop SPF break that is the load-bearing operational evidence stream the myth rebuttals THIS catalogue publishes reach for.
• BIMI Verified Mark Certificates — the per-publisher per-domain BIMI VMC as operationally-grounded refutation evidence companion to this myths catalogue. Where THIS page deconstructs the BIMI- does-not-need-VMC / DMARC-enforcement-is- enough-for-BIMI / BIMI-works-without-DMARC- quarantine-or-reject myth class against operationally-grounded evidence, the BIMI- VMC spoke documents the per-publisher per- domain VMC-issuance-readiness gate at Mark Verifying Authorities that is the LOAD- BEARING operational evidence stream the myth rebuttals reach for to operationally- ground their refutation. Four MYTH-CLASS- VS-BIMI-VMC-OPERATIONAL-EVIDENCE cross- correlation axes the BIMI-VMC spoke documents: (i) the "BIMI does not need VMC" myth class is REFUTED by the per-receiver Yahoo / Gmail / Apple Mail / Fastmail BIMI logo-render gate that REQUIRES a Mark Verifying Authority- issued Verified Mark Certificate to bind the per-publisher per-domain logo SVG to the per-publisher per-domain identity — the per-receiver BIMI display gate SUPPRESSES the logo render at every receiver that does not validate the VMC trust-chain; (ii) the "DMARC enforcement is enough for BIMI" myth class is REFUTED by the per-publisher per-domain VMC-issuance-readiness gate that REQUIRES the X.509 trust-chain anchored to the Mark Verifying Authority in ADDITION to sustained per-publisher per-domain DMARC-enforcement — the per- publisher per-domain DMARC-enforcement baseline is the NECESSARY but NOT SUFFICIENT precondition for BIMI display; (iii) the "BIMI works without DMARC quarantine/reject" myth class is REFUTED by the per-receiver BIMI logo- render gate that REQUIRES per-publisher per-domain p=quarantine-or-stronger enforcement BEFORE the receiver evaluates the per-VMC trust-chain — a per-publisher per-domain p=none publication-discipline cannot satisfy the per-receiver BIMI display gate regardless of per-VMC issuance readiness; (iv) the "BIMI is purely cosmetic / non-functional" myth class is REFUTED by the per-publisher per-domain BIMI display-rate KPI that STRUCTURALLY COUPLES per-publisher per- domain DMARC-enforcement baseline with per-receiver receiver-side trust-signaling — the per-publisher per-domain BIMI display-rate is a per-publisher per-domain OPERATIONAL KPI that measurably affects per-receiver per-publisher per-domain inbox-placement trust-signal weighting. Read THIS page when DECONSTRUCTING BIMI- does-not-need-VMC myths against operationally- grounded evidence; read the BIMI-VMC spoke when DECODING the per-publisher per-domain VMC-issuance-readiness gate at Mark Verifying Authorities that is the load- bearing operational evidence stream the myth rebuttals THIS catalogue publishes reach for.
• DKIM canonicalization — the per-message DKIM canonicalization- mode as load-bearing per-intermediary- mutation-footprint-vs-DKIM-pass myth refutation evidence companion to this DMARC myth-rebuttal catalogue. Where THIS page documents the per-publisher per-domain DMARC myth-rebuttal catalogue against operationally-grounded evidence, the DKIM canonicalization spoke documents the per- message RFC 6376 §3.4 simple-vs-relaxed body-and-header canonicalization-mode byte-normalization grammar whose per- message canonicalization-discipline is the LOAD-BEARING per-receiver verifier- side body-hash recomputation primitive every per-intermediary-mutation-footprint myth rebuttal STRUCTURALLY DEPENDS on as the operationally-grounded refutation- evidence stream. Four DKIM- CANONICALIZATION-VS-DMARC-MYTH-REFUTATION cross-correlation axes the canonicalization spoke documents: (i) "DKIM survives all intermediaries" myth REFUTED by per- message body-mutation under c=simple body-hash mismatch — under c=simple body canonicalization mode the per-message body is byte-for-byte hashed including all whitespace and line-ending bytes; per- intermediary footer injection by mailing- list software (LISTSERV, Mailman, Google Groups), per-intermediary trailing-newline normalization, or per-intermediary CRLF-to- LF conversion produces per-message body- hash mismatches that the per-receiver verifier-side bh=-recomputation emits as dkim=fail verdicts even when the per-publisher per-domain identifier is correct — operationally refutes the "DKIM survives all intermediaries" myth with per-receiver per-day body-hash-mismatch attribution evidence; (ii) "relaxed mode is always safe" myth REFUTED by per-message body-mutation footprint divergence under c=relaxed — under c=relaxed body canonicalization mode the per-message body excludes trailing empty lines and normalizes per-line whitespace, but per-intermediary footer- injection that adds NON-EMPTY content (List- Unsubscribe footer, archive-link footer, legal-disclaimer body-text) still produces per-message body-hash mismatch because the per-intermediary inserted content is byte- for-byte hashed; the c=relaxed choice mitigates ONLY per-whitespace and per-line-ending mutation, not per- intermediary content-injection mutation — operationally refutes the "relaxed mode is always safe" myth with per-intermediary content-injection attribution evidence; (iii) "DKIM canonicalization choice is cosmetic" myth REFUTED by per-receiver per-message body-hash recomputation consequence — the per-message c= tag is NOT cosmetic — it is the per-message instruction the receiver-side verifier reads to know which canonicalization algorithm to apply BEFORE recomputing the per-message body-hash; per-publisher per-domain c=simple/simple publication for a mailing-list-routed audience emits per-receiver per-day dkim-fail-row cliffs that the per-publisher per-domain operator MUST distinguish from genuine spoofing-attribution; operationally refutes the "DKIM canonicalization choice is cosmetic" myth with per-receiver per- day per-source attribution evidence; (iv) "DKIM body-hash is tamper- proof" myth REFUTED by per-intermediary footer-injection canonicalization-mode- dependent body-hash mismatch — the per-message bh= body- hash field is SHA-256 cryptographically bound to the canonicalized message body AT THE PUBLISHER, but receiver-side verification recomputes the bh= against the in-transit body; per-intermediary footer-injection breaks the per-receiver bh= recomputation under either canonicalization mode (whitespace-only mutation under c=simple / non-empty content-injection under c=relaxed) — operationally refutes the "DKIM body-hash is tamper- proof" myth with per-intermediary per- receiver per-day body-mutation attribution evidence. Read THIS page when DECONSTRUCTING per-publisher per-domain DMARC myths against operationally-grounded evidence; read the DKIM canonicalization spoke when DECODING the per-message canonicalization-mode byte-normalization grammar whose per-message body-hash recomputation primitive is the LOAD- BEARING operationally-grounded refutation- evidence stream every per-intermediary- mutation-footprint myth rebuttal THIS catalogue publishes structurally requires.
• SPF 10-DNS-lookup limit — the RFC-7208-§4.6.4-10-DNS-LOOKUP-CEILING-AS- LOAD-BEARING-MYTH-REFUTATION-AUTHORITY companion to this DMARC-myths-and-misconceptions catalogue. Where THIS page catalogues the per-publisher per- domain DMARC-myth catalogue and per-myth canonical refutations, the SPF-lookup-limit spoke is the SPF-SIDE-MYTH-REFUTATION-AUTHORITY companion documenting the RFC 7208 §4.6.4 10-DNS-lookup ceiling whose canonical understanding refutes FOUR major SPF-cluster myths the catalogue documents. The myths-vs-SPF-lookup-limit relationship is per-myth-canonical-refutation- authority: this myths catalogue documents the per-publisher per-domain misconception per RFC- 7208-§4.6.4 chapter; the SPF-lookup-limit spoke is the canonical SPF-side reference whose authority is invoked when each per-myth refutation requires SPF-budget-cost authoritative citation. Four per- myth-vs-SPF-lookup-limit refutation dimensions matter at the myths-catalogue-refutation-authority layer: (i) "SPF works on subdomains automatically" myth refutation — RFC 7208 has NO subdomain inheritance semantics; each subdomain requires its own v=spf1 TXT-record publication, each independently subject to the 10-DNS-lookup ceiling, and the publisher-side per-subdomain publication discipline is the load-bearing refutation evidence; (ii) "I can add as many ESPs to SPF as I want" myth refutation — RFC 7208 §4.6.4 explicitly caps the cumulative DNS-lookup cost at 10, with include:, a:, mx:, exists:, redirect= each consuming budget; cumulative supplier-ESP enumeration that exceeds the budget produces spf=permerror which propagates to DMARC composite-fail irrespective of the per-publisher per-ESP business relationship; (iii) "SPF permerror is a DNS problem not an SPF problem" myth refutation — spf=permerror is the canonical publisher-side budget-violation outcome per RFC 7208 §11.1.1, requiring publisher-side SPF-flattening / per-ESP include-consolidation / per-zone TXT-record splitting remediation rather than DNS-provider escalation; (iv) "SPF -all hardfail blocks legitimate forwarded mail" myth refutation — while forwarder-induced envelope- rewriting DOES break first-hop SPF, the publisher- side budget-discipline determines whether the original first-hop SPF verdict was spf=pass in the first place; the myths catalogue refutes the per-publisher per- domain misconceptions while the SPF-lookup-limit spoke documents the operational discipline whose observance keeps the publisher-side SPF leg valid. Read THIS page when DECONSTRUCTING per- publisher per-domain DMARC myths against operationally-grounded refutation evidence; read the SPF-lookup-limit spoke when CITING the canonical SPF-side authority that backs each per- myth refutation in the SPF-cluster myth class.
• SPF mechanism-choice decision matrix
• DKIM DNS record syntax — the per-publisher per-selector DKIM DNS-record byte-grammar reference companion to this DMARC myth-deconstruction catalogue.
• Email deliverability
• SPF for Microsoft 365 — per-M365-tenant per-accepted- domain SPF authorisation publication- discipline IS the canonical per-tenant envelope-MAIL-FROM-layer authentication- leg deployment surface where the most common per-M365-tenant DMARC myths land (the "include:spf.protection.outlook.com alone is enough for M365 deliverability" myth IS directly counterfactual to the per-tenant per-accepted-domain composite DMARC-aligned-pass-rate floor requirement; the "per-tenant SPF 10-DNS-lookup-cap doesn't matter for M365" myth IS directly counterfactual to RFC 7208 §4.6.4 compliance gating per-tenant SPF-aligned- pass verdict-stability; the "per-tenant DKIM dual-selector publication is optional for M365" myth IS directly counterfactual to per-tenant per- accepted-domain DMARC-aligned-pass-rate floor requirement requiring at least one aligned-pass leg per RFC 7489 §6.6.2) the per-publisher per-domain DMARC myth- and-misconception rebuttal catalogue THIS page documents the per-publisher per-domain composite myth-deconstruction publication-discipline of materially applies at the per-M365-tenant per- accepted-domain composite myth-rebuttal- and-SPF-authorisation-publication coordination boundary.
• SPF for Google Workspace — per-Workspace-tenant per-custom- domain SPF authorisation publication- discipline IS the per-tenant Google- Workspace cross-cloud-peer COUNTERPART to the per-M365-tenant SPF authorisation publication-discipline this myths-page already cross-links above (line 4184), forming the canonical cross-cloud-tenant SPF-application-layer peer-pair at four per-Workspace-tenant per-custom-domain DMARC-myth-vs-Workspace-SPF-publication coupling dimensions: (i) the per-Workspace- tenant per-custom-domain "include:_spf.google.com alone is enough for Workspace deliverability" myth IS directly counterfactual to the per-Workspace-tenant per-custom-domain composite DMARC-aligned- pass-rate floor requirement requiring at least one aligned-pass leg per RFC 7489 §6.6.2 (SPF-aligned-pass OR DKIM-aligned- pass) gating per-mailbox-provider inbox- placement at the per-Workspace-tenant per-custom-domain composite authentication- leg coordination boundary; (ii) the per-Workspace-tenant per-custom-domain "per-tenant SPF 10-DNS-lookup-cap doesn't matter for Workspace" myth IS directly counterfactual to RFC 7208 §4.6.4 compliance gating per-Workspace-tenant SPF-aligned-pass verdict-stability when the per-tenant SPF record composes include:_spf.google.com + per-tenant marketing-platform includes + per-tenant transactional-platform includes + per-tenant CRM-platform includes against the 10-lookup budget cliff; (iii) the per-Workspace-tenant per-custom-domain "per-tenant DKIM single-selector publication is optional for Workspace" myth IS directly counterfactual to per- Workspace-tenant per-custom-domain DMARC- aligned-pass-rate floor requirement when per-Workspace-tenant Google-managed DKIM signature emission at the google._domainkey.<workspace-domain> TXT-RR publication leaf depends on the operator-published per-tenant DKIM record actually existing (operators who skip the DKIM publication leaf rely on per-tenant SPF-aligned-pass exclusively, forfeiting the OR-conjunction safety-net the second authentication leg provides for second-hop forwarding scenarios that break SPF- alignment); (iv) the per-Workspace-tenant per-custom-domain "per-tenant DMARC RUA aggregate-report observability doesn't matter for Workspace deliverability" myth IS directly counterfactual to the per- receiver per-day DMARC RUA aggregate- report observability pipeline being the load-bearing per-Workspace-tenant per- custom-domain operator-side visibility- into-aligned-pass-rate-floor evidence- stream gating per-tenant per-custom-domain enforcement-mode ramp progression which underpins per-mailbox-provider reputation- floor signal-stream — the per-publisher per-domain DMARC myth-and-misconception rebuttal catalogue THIS page documents materially applies at the per-Workspace- tenant per-custom-domain composite myth- rebuttal-and-SPF-authorisation-publication coordination boundary, completing the cross-cloud-tenant SPF-application-layer peer-pair (M365 ↔ Workspace) initiated by the immediately-preceding M365 entry.
• TLS-RPT TXT-RR record-syntax — the per-publisher per-policy-domain TLS-RPT TXT-RR byte-grammar publication- discipline reference whose _smtp._tls.<domain> underscore-prefixed TXT-RR publication per RFC 8460 §3.1 IS structurally parallel underscore-prefixed-TXT-RR publication-discipline to per-publisher per-domain DMARC _dmarc.<domain> TXT-RR publication per RFC 7489 §6.1 the per-publisher per-domain DMARC myth-and-misconception rebuttal catalogue THIS page documents the per-publisher per-domain composite-verdict publication- discipline of — both per-publisher per-domain underscore-prefixed-TXT-RR publication-discipline references are operator-side per-publisher per-domain DNS-published aggregate-observability-and- composite-verdict-publication primitives whose authoritative-zone-file commit-to- recursive-resolver cache-coherence boundary the per-publisher per-domain composite application-and-transport-layer aggregate- observability-publication-discipline coordinates publication-cadence across. The per-publisher per-policy-domain TLS-RPT rua=mailto:/rua=https: aggregate-report-URI publication-discipline IS structurally parallel aggregate-report- URI publication-decision to per-publisher per-domain DMARC rua=mailto: aggregate-XML-report-URI publication- discipline — both are per-publisher per-domain operator-side aggregate-report- destination-publication primitives whose per-publisher per-day per-aggregate-report mailbox-receiving-capacity readiness floor the per-publisher per-domain composite application-and-transport-layer aggregate- observability-pipeline operational- discipline depends on. The myth-and- misconception rebuttal catalogue THIS page documents the per-publisher per-domain composite-verdict-publication-discipline- rebuttal of materially extends across the per-publisher per-policy-domain transport- layer-aggregate-observability publication- discipline boundary the TLS-RPT-record- syntax spoke documents the per-publisher per-policy-domain underscore-prefixed- TXT-RR byte-grammar publication-discipline of — together the DMARC myth-and- misconception rebuttal catalogue AND the TLS-RPT TXT-RR record-syntax primer compose the per-publisher per-domain composite cross-layer underscore-prefixed-TXT-RR publication-discipline-and-rebuttal- coordination floor at the per-publisher per-domain composite application-and- transport-layer aggregate-observability publication-discipline coordination boundary.
• MTA-STS policy file syntax — the PER-PUBLISHER-PER-POLICY-DOMAIN-MTA-STS-POLICY-FILE-BYTE-GRAMMAR-PUBLICATION-DISCIPLINE-AS-LOAD-BEARING-TRANSPORT-LAYER-REBUTTAL-OF-DMARC-ALONE-CLOSES-EVERYTHING-MISCONCEPTION companion at four per-publisher per-domain MTA-STS-policy-file-byte-grammar-vs-DMARC-myths-rebuttal-discipline coupling dimensions: (i) per-publisher per-policy-domain MTA-STS policy-file byte-grammar publication-discipline per RFC 8461 §3.2 (mandatory version: STSv1 declaration + mode:/mx:/max_age: tag-vocabulary) IS the load-bearing per-publisher per-policy-domain transport-layer rebuttal-evidence-discipline closing the per-publisher per-domain “DMARC-alone-closes-transport-layer-MITM-downgrade-attack-class” misconception that THIS DMARC-myths page documents the rebuttal-discipline of — DMARC application-layer composite-aligned-pass verdict per RFC 7489 §6.6 does NOT structurally address per-receiver per-MX-host STARTTLS-strip MITM downgrade-attack-class which per-publisher per-policy-domain MTA-STS-enforce policy-file publication-discipline per RFC 8461 §5 closes; (ii) per-publisher per-policy-domain MTA-STS policy-file mode: enforce transport-layer enforcement-mode publication-decision IS structurally parallel transport-layer enforcement-mode publication-decision to per-publisher per-domain DMARC p=quarantine/p=reject application-layer enforcement-mode publication-decision per RFC 7489 §6.3 — the misconception that per-publisher per-domain DMARC application-layer enforcement-mode publication-decision alone closes the per-receiver per-MX-host envelope-byte-stream-integrity-floor is rebutted by per-publisher per-policy-domain MTA-STS-enforced transport-layer per-MX-host STARTTLS-required-or-fail enforcement THIS MTA-STS-policy-syntax primer documents the per-publisher per-policy-domain transport-layer byte-grammar publication-discipline of; (iii) per-publisher per-policy-domain MTA-STS policy-file max_age: cache-lifetime publication-decision per RFC 8461 §3.2 (max 31557600 seconds = 1 year) IS the load-bearing per-publisher per-policy-domain transport-layer policy-cache-stability publication-discipline whose per-receiver-side policy-cache-coherence cadence the misconception that “per-publisher per-policy-domain transport-layer publication-discipline is immediately responsive” is rebutted against — per-publisher per-policy-domain MTA-STS policy-cache-lifetime publication-discipline IS structurally parallel cross-layer publication-cache-stability primitive to per-publisher per-domain DNS TTL publication-discipline whose DMARC-myths misconceptions about immediate publication-effect THIS DMARC-myths page documents the rebuttal-discipline of; (iv) per-publisher per-policy-domain MTA-STS policy-file byte-grammar publication-discipline drift (BOM-prefix mis-publication / inline-comment mis-publication / wildcard-label crossing single-label-budget / max_age: exceeding 31557600-second ceiling / Content-Type mis-publication) surfacing in per-publisher per-policy-domain TLS-RPT JSON-aggregate-report failure-type: sts-policy-invalid attribution per RFC 8460 §4.3 IS structurally parallel cross-protocol per-leg publication-discipline-drift class to per-publisher per-domain DMARC TXT-RR publication-discipline drift the DMARC-myths page documents the rebuttal-discipline of — both per-publisher per-domain per-day per-receiver per-leg aggregate-evidence-channel publication-discipline-drift references jointly underpin per-publisher per-domain operator-actionable per-day per-leg cross-protocol cross-layer drift-closure observability at the per-publisher per-domain composite cross-protocol cross-layer publication-discipline-and-rebuttal-coordination floor.
• DMARC for Google Workspace — the Google-Workspace-tenant deployment guide. Directly rebuts the common myth that “Google Workspace handles DMARC for you”: Workspace signs outbound mail with DKIM but does NOT publish your _dmarc policy record — the tenant operator must publish the SPF (include:_spf.google.com) and DMARC records themselves, as this guide details.
• TLS-RPT report format — the SEPARATE-TRANSPORT-LAYER-EVIDENCE-STREAM companion that disarms a common conflation myth: the TLS-RPT JSON aggregate report is NOT the same thing as the DMARC RUA aggregate XML, even though both arrive on the same per-day per-receiver aggregate cadence — DMARC RUA reports per-message authentication (SPF/DKIM alignment) verdicts, while TLS-RPT reports per-session transport-encryption (STARTTLS / certificate) outcomes, and “my mail is encrypted so it is authenticated” is exactly the layer-confusion this myths catalogue exists to rebut. Read the TLS-RPT-report-format spoke to see the structural parallel between the two aggregate report bodies and why publishing one does not substitute for the other.
• CAA records explained — another DNS-record-layer-confusion myth this catalogue rebuts: a CAA record constrains which certificate authority may issue TLS certificates for your domain — it does NOT authorize or restrict who may send email, which is the job of SPF, DKIM and DMARC. Read the CAA primer to keep the certificate-issuance control and the email-authentication controls straight.
• Microsoft SNDS + JMRP monitoring — DMARC reporting shows who fails authentication; Microsoft SNDS + JMRP shows how Outlook.com's filter and its users judge the mail that passes — the per-IP reputation signal aggregate reports cannot see.

9. Audit your DMARC mental model against your actual deployment

DMARC Analyzer is the operator console for verifying the corrective actions in §6 of this page. The dashboard ingests DMARC aggregate (RUA) and forensic (RUF) reports via includes/DmarcParser.php and includes/ForensicReportParser.php, surfacing per-sender / per-IP / per-day authentication breakdowns so myths about coverage (1, 9, 13, 17) and reporting (14, 16) can be cross-checked against live data. The Domain Security Checker runs live DNS lookups across SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT, and CAA through includes/DnsChecker.php so deployment myths (3, 4, 6, 10, 12) can be verified record-by-record. The email header analyser at header_analyzer.php diagnoses individual message failures.

Sign up — Free plan Check my DMARC record