DMARC Analyzer

TL;DR

• "Weak DMARC" means any of: missing DMARC, stuck at p=none, pct<100, sp= unset on a non-sending parent, or apex-only deployment with abandoned subdomains — each gap is a documented attacker entry point.
• Display-name spoofing bypasses DMARC entirely. DMARC anchors against the From: ADDRESS not the display name; an attacker can put "CEO Name" in the display and a random Gmail address as the From: — DMARC passes Gmail's policy with zero alignment to the targeted brand.
• Lookalike domain registration (typosquats and IDN homographs) is the single most common DMARC bypass. The attacker registers a confusable lookalike (vvise.example or Cyrillic-а wise.example), publishes their own DMARC, and every check passes for THEIR domain.
• Subdomain takeover bypasses DMARC when sp= is unset or sp=none. Attackers re-register orphaned CNAMEs (S3 buckets, Azure resources, Heroku apps) and publish their own SPF + DKIM on the takenover subdomain to send DMARC-passing phishing.
• p=none provides zero enforcement. Receivers deliver normally and the only signal is the RUA aggregate stream. Domains stuck at p=none for years are essentially undefended against direct spoofing.
• pct=10 leaves 90% of attacker spoofing un-rejected — attackers know this sampling gap and prefer targets they observe sitting at low pct= values during long rollouts.
• DKIM with 1024-bit keys is offline- factorable at modern compute prices. Rotate to 2048-bit minimum; treat any leaked DKIM key as a credential compromise (revoke, rotate, audit the signature history for replay).
• DKIM replay attacks bypass DMARC by design. Replayed bytes still validate; DMARC alignment still passes. Defence is short DKIM key rotation, tight per-recipient outbound rate limits at the original sender, and the body-length-restricted-replay mitigation drafts.
• ARC chain abuse requires the attacker to operate from a trusted-sealer intermediary — but receivers do trust named intermediaries by configuration. Keep Set-ArcConfig trusted-sealer lists short and treat ARC trust as a privileged identity.
• Compromised legitimate accounts (BEC) send DMARC-passing phishing by design. DMARC authenticates infrastructure, not user intent. Pair DMARC with MFA / FIDO2, conditional-access policies, and anomaly-detection on outbound mail.

1. What "weak DMARC" means — and what attackers look for

Attackers do not need to break the DMARC standard to spoof your domain. They only need a single configuration gap in your deployment — and most real-world domains have several. A weak DMARC deployment is one where any of the following holds:

• The apex domain has NO DMARC record at all (the highest-value attacker target — direct spoofing with zero receiver-side defence).
• The apex domain has DMARC but is stuck at p=none indefinitely (the single most common state — receivers deliver failing mail normally).
• The policy is at p=quarantine or p=reject but pct= is set to a value below 100 (a sampling gap leaves the remaining percentage un-rejected).
• The apex DMARC omits sp= and defaults to inheriting p=, but the operator never published per- subdomain DMARC records — subdomain takeover then provides an attacker- controlled child of the apex.
• sp=none is explicitly set on a parent whose subdomains have no DMARC of their own — every subdomain becomes an attacker entry point.
• SPF includes are overly broad (include:_spf.shared-hoster.example or wildcard mechanisms) that authorise third-party sender pools the operator does not control.
• DKIM keys are short (1024-bit), rotated rarely (years), or operate without a revocation playbook for leaked keys.
• The reporting mailbox at rua=mailto:... bounces, is unmonitored, or routes to an inbox the operator never reviews — the operator is blind to attacker activity even when DMARC enforces correctly.
• Trusted-sealer lists for Defender for Office 365 or equivalent ARC implementations include vendors the operator no longer has a relationship with.
• BIMI is deployed but the underlying DMARC is at p=none (silently ignored by receivers) or the BIMI logo certificate trust chain is unmonitored.

Attackers fingerprint these gaps via public DNS lookups — every weakness above is visible in the open without authentication. A typical reconnaissance loop performs dig TXT _dmarc.your-domain.example, parses the policy, looks up the SPF record and follows includes, checks for sp= subdomain inheritance, and probes common subdomains (mail., newsletter., status., dev., test., api., cdn.) for missing DMARC. The output is a target selection list ranked by exploitability.

The rest of this page enumerates the 22 concrete attacks that map onto these gaps. Each attack section names the technique, describes the attacker's mechanics, references the MITRE ATT&CK technique number where applicable, and prescribes the defender countermeasure.

2. The DMARC threat model — what DMARC is and is NOT designed to defend against

Understanding what DMARC was designed to block is the foundation of any threat model. Per RFC 7489 §3, DMARC binds the SPF-passing or DKIM-signing domain to the visible From: header (RFC 5322) so receivers can detect when a message claims a domain identity it cannot authenticate. This is surgically narrow: DMARC defends against direct spoofing of the visible From: domain and nothing else.

The DMARC threat model therefore has two distinct zones:

• In-scope: An attacker attempts to send mail with a From: header that literally claims to be from your domain (From: ceo@your-company.example). DMARC at p=reject with functioning SPF + DKIM blocks this with near-perfect accuracy at every major receiver (Google, Microsoft, Yahoo, Comcast, Mail.ru, ProtonMail, Fastmail, Zoho).
• Out-of-scope: Every other attack vector against email — lookalike domains, display-name spoofing, IDN homographs, compromised internal accounts, brand impersonation from unrelated domains, transport interception, content-layer phishing without spoofed identifiers, social-engineering pretexts that do not involve email at all.

Attackers respond rationally to this scope. When DMARC enforcement closes the in-scope attack surface, they pivot to the out-of-scope surface — every section below documents one of those pivots. Operators who model DMARC as "anti-phishing" rather than "anti-spoofing" mis-allocate defensive investment; this page corrects that model.

3. Attack-class coverage map

This map summarises the entire attacker taxonomy against the email channel and where DMARC fits. Use it as the entry point for the threat-model review.

Every "No" row in the table is a documented attacker bypass. The sections that follow detail each one — what the attacker does, why DMARC does not stop it, and what does.

4. Direct attacks on the visible From: identity

The most common attacker bypass class targets the visible From: identity directly without spoofing the protected domain. DMARC has no opinion on these attacks because the From: address does not claim to be your domain.

4.1 Attack: Display-name spoofing

Attack: the attacker sends mail with a From: ADDRESS that belongs to a free webmail provider, but sets the DISPLAY NAME to the targeted brand's name.

From: "Customer Support — Wise" <random-account-1473@gmail.com>
Subject: Action required: verify your account

How it works: Most email clients (Gmail web, Outlook desktop, iPhone Mail) display the display name prominently and hide the From: address by default. A recipient skimming their inbox sees "Customer Support — Wise" without ever seeing the gmail.com address. DMARC passes against gmail.com because the From: address legitimately is gmail.com — there is nothing for the targeted brand's DMARC to act on. MITRE ATT&CK technique T1566.002 Spearphishing Link via display-name spoofing.

Defender perspective: deploy anti-phishing gateways with display-name policies (allowlist of executive display names, then alert on any external From: matching one of those names); train recipients to inspect the actual From: address before clicking; consider executive display-name allowlists at the receiver MTA. DMARC alone provides zero defence.

4.2 Attack: RFC 5322 "comment" abuse and From-line trickery

Attack: the attacker exploits RFC 5322 grammar quirks to construct a From: line that looks legitimate to humans but parses differently to mail receivers.

From: support@your-bank.example <attacker@attacker.example>
From: "your-bank.example" <legit-name@attacker.example>
From: =?utf-8?B?...?= <attacker@attacker.example>

How it works: RFC 5322 §3.4 allows comments in the From: header inside parentheses; the display-name field is a free-text quoted string with no semantic relationship to the address; the encoded-word syntax (RFC 2047) lets the attacker embed arbitrary text including target-domain strings that the recipient sees but the DMARC receiver parses as just a display name. DMARC anchors against the parsed addr-spec inside the angle brackets, not the cosmetic surface that the recipient sees. The targeted domain's DMARC cannot trigger because the addr-spec is the attacker's domain.

Defender perspective: anti- phishing gateways that normalise display-name fields, strip RFC 2047 encoded-word obfuscation before display, and alert on any visible string in the From: line that matches a protected brand name. The Email Header Analyzer surfaces the raw From: parse so operators can validate gateway behaviour.

4.3 Attack: Lookalike-domain registration (typosquatting)

Attack: the attacker registers a domain that visually or phonetically resembles the target — vvise.example (double-v for w), your-bank-secure.example (added word), your-banc.example (substituted letter), your-bank.co (alternate TLD), your-bank-support.example (added suffix).

How it works: the attacker publishes a valid SPF + DKIM + DMARC record on the lookalike domain, sends mail with From: support@vvise.example, and every authentication check passes for the attacker's domain. Recipient receivers see a DMARC-pass message and deliver it normally. The targeted brand's DMARC has no opinion because the lookalike domain is not the targeted domain. MITRE ATT&CK technique T1583.001 Acquire Infrastructure: Domains.

Defender perspective: proactive defensive registration of common lookalikes (the typosquat list: every single-letter substitution, every double-letter, common TLD alternates); brand-monitoring services with automated takedown workflows (MarkMonitor, Brand Protection Online, ZeroFox); anti-phishing gateways that detect inbound mail from edit-distance-close domains; CAA records on the real domain to prevent attacker certificate issuance (which would enable HTTPS phishing sites). DMARC provides no defence against this class.

4.4 Attack: IDN homograph attacks (Unicode confusables)

Attack: the attacker registers an Internationalised Domain Name (IDN) using non-Latin Unicode codepoints that visually resemble ASCII Latin letters.

Target:    wise.example      (w-i-s-e, all Latin)
Homograph: wіse.example      (w + Cyrillic і U+0456 + s + e)
Punycode:  xn--wse-xnc.example

How it works: the Unicode character set includes script-mixed glyphs that are visually identical or near-identical to ASCII letters — Cyrillic а (U+0430) vs Latin a (U+0061); Greek ο (U+03BF) vs Latin o (U+006F); Cherokee Ꭺ (U+13AA) vs Latin A (U+0041). Every browser and email client renders these correctly as their Unicode glyph; the recipient sees what looks identical to the target. The attacker registers the punycode (xn--) form, publishes their own DMARC on it, and sends DMARC-passing mail. DMARC has no IDN-confusability awareness.

Defender perspective: gateway homograph detection (flag any From: domain containing non-ASCII codepoints when the protected brand uses ASCII-only); proactive IDN-variant registration via brand-monitoring services; browser-level IDN-script-mixing protection (Chrome's IDN handling rules limit confusable rendering); recipient training to inspect suspicious domain glyphs. DMARC provides zero defence; this attack class is one of the most technically effective bypasses because the rendering is genuinely indistinguishable.

4.5 Attack: Brand impersonation via unrelated domains

Attack: the attacker sends mail from a domain that has no orthographic relationship to the target but whose name suggests authority — security-team-alert.example, fraud-notification-center.example, account-verification-required.example.

How it works: the attacker domain is a fresh registration with its own SPF + DKIM + DMARC — every authentication check passes for the attacker. The recipient sees a domain that sounds official and a subject like "Urgent: verify your your-bank.example account" — the body references the targeted brand by name. There is no DMARC contract to enforce because the From: domain is not the targeted brand. MITRE ATT&CK technique T1566 Phishing via brand impersonation.

Defender perspective: brand-monitoring services that scan registration feeds for newly-registered domains containing target-brand-related keywords; anti-phishing gateways with brand-name-in-body detection; recipient training on the "official-sounding unrelated domain" pattern. DMARC provides zero defence.

5. Attacks exploiting weak DMARC configurations

This class differs from §4 in that the targeted domain itself has a DMARC record, but the record is mis-configured in a way an attacker can exploit. These are the attacks the Domain Security Checker is designed to surface.

5.1 Attack: p=none — observation but no enforcement

Attack: the targeted domain has v=DMARC1; p=none; rua=mailto:... and has been there for months or years. The attacker spoofs the domain directly knowing receivers will deliver normally.

How it works: RFC 7489 §6.3 defines p=none as the "monitoring mode" — receivers MUST take no DMARC-based enforcement action. The only artefact p=none produces is the RUA aggregate report flow. An attacker spoofs the From: header to claim the targeted domain, sends from any IP they control, and the message reaches every recipient inbox at Gmail, Microsoft 365, Yahoo, and every other receiver. The operator eventually sees the spoofing in the next RUA aggregate report — but after the campaign has already landed.

Defender perspective: advance through the phased rollout playbook in DMARC policy rollout. p=none is the starting line, not the destination. Cap the p=none observation window at 30-60 days for established domains (longer for complex multi-sender environments), then advance to p=quarantine + pct=10, ramp pct monotonically to 100, then p=reject. The Feb 2024 Google/Yahoo bulk-sender requirements raised the industry floor by requiring at least p=none for senders to 5000+ recipients/day — but compliance with the floor is not security.

5.2 Attack: pct<100 — sampling gap leaves percentage un-rejected

Attack: the targeted domain has v=DMARC1; p=reject; pct=10; rua=mailto:... or similar. The attacker spoofs the domain repeatedly; 90% of attempts receive the next-weakest action (p=quarantine = delivery to spam) and reach the recipient with a recoverable delivery.

How it works: RFC 7489 §6.3 defines pct= as the percentage of failing mail that receives the policy action; the remainder receives the next-weakest action (p=reject falls back to p=quarantine, p=quarantine falls back to p=none). An organisation at pct=10 / p=reject only rejects 1-in-10 spoofed messages; the other 9 reach the spam folder. Users who routinely rescue messages from spam (a normal behaviour) will see attacker mail.

Defender perspective: pct= is a rollout dial, not a permanent setting. Ramp monotonically over weeks: pct=10 for a week, pct=25 for a week, pct=50 for a week, pct=100 for a week, then remove the pct= tag entirely (defaults to 100). Operators who set pct=10 as a permanent "safety net" leave a documented attacker window. Use the DMARC dashboard to track legitimate-sender alignment percentage before each pct advancement.

5.3 Attack: sp= unset or sp=none — subdomain free-for-all

Attack: the targeted domain has p=reject on the apex but no sp= tag (defaults to inherit) and a weak or missing DMARC on a subdomain, OR has sp=none explicitly. The attacker sends mail with From: support@unused-subdomain.your-bank.example; receivers look up _dmarc.unused-subdomain, find nothing, fall back to the apex per RFC 7489 §6.6.3, apply sp= (defaults to p= but the operator set sp=none explicitly), and deliver normally.

How it works: RFC 7489 §6.6.3 documents the receiver's policy-discovery algorithm: try _dmarc.<full-domain> first; if no record, fall back to _dmarc.<organizational-domain> (the PSL-derived registered domain) and apply sp=. If the parent omits sp=, the receiver applies p=. An apex p=reject record with no sp= therefore protects subdomains automatically. But if the operator explicitly sets sp=none on the apex — a common pattern when one subdomain has legitimate-but-misaligned mail — attackers gain apex-level reach via any non-sending subdomain.

Defender perspective: default to sp=reject on the apex DMARC for any non-sending parent. If a subdomain legitimately needs a weaker policy (e.g. marketing.example during initial rollout), publish a per-subdomain DMARC record on that subdomain explicitly rather than weakening the apex sp=. Use the Domain Security Checker to enumerate subdomains and verify each has explicit or inherited p=reject coverage.

5.4 Attack: Missing apex DMARC — bare-domain spoofing

Attack: the targeted domain has no DMARC record at all. The attacker sends mail directly from any IP, receivers find nothing at _dmarc, take no DMARC-based action, and the message delivers normally.

How it works: without a DMARC record, receivers default to legacy SPF + DKIM behaviour: an unauthenticated message gets a spam-score penalty but is not rejected at the SMTP layer. Attackers operate confidently from high-reputation IP pools (compromised cloud accounts, residential proxies, hijacked email infrastructure) where the spam-score penalty is not enough to land the message in the spam folder. Pre-DMARC defences are insufficient.

Defender perspective: publish DMARC on every domain you own, including domains you never send mail from (v=DMARC1; p=reject; rua=mailto:dmarc@your-domain.example; aspf=s; adkim=s on a non-sending parking domain). The Feb 2024 Google/Yahoo bulk-sender requirements make this compulsory for any sender to 5000+ recipients/day — but every domain you own is an attacker target regardless of send volume.

5.5 Attack: SPF +all or oversized include — third-party server abuse

Attack: the targeted domain's SPF record includes a third-party sender's record (include:_spf.shared-hoster.example) that authorises a large shared-IP pool. The attacker rents space at the same shared hoster, sends mail with From: support@your-bank.example from a shared IP, SPF passes (the IP is in the included pool), DMARC passes alignment because SPF aligned, and the message delivers normally.

v=spf1 include:_spf.shared-hoster.example include:_spf.legacy-saas.example +all

How it works: SPF mechanisms authorise IPs, not domains. An include: mechanism delegates authorisation to whatever IPs the included record names. Shared-hoster includes often span thousands of IPs — every paying customer of the hoster is implicitly authorised to send From: your-domain.example. The qualifier +all is the maximum-permissive form: every IP on the internet is authorised. RFC 7208 §5.6 defines +all as a legitimate (but almost always misguided) construction.

Defender perspective: audit every SPF include chain via the Domain Security Checker; replace oversized shared-hoster includes with the specific IPs you actually use (ip4: / ip6:); never use +all; cap the lookup chain at 8-9 to stay under the RFC 7208 §4.6.4 10-DNS-lookup limit; consider SPF flattening services for legitimate complex setups.

5.6 Attack: Subdomain takeover via abandoned DNS records

Attack: the targeted domain has a DNS CNAME pointing at a cloud-resource name (status.your-bank.example CNAME your-bank-status.heroku.com) that has been decommissioned. The attacker re-registers the orphaned cloud resource under the same name, gaining control of the subdomain. They publish their own SPF + DKIM (on the takenover subdomain's effective DNS pointer), send mail with From: notifications@status.your-bank.example, DMARC passes if sp= permits, and the message delivers.

How it works: the MITRE ATT&CK T1584 Compromise Infrastructure technique covers this class. Cloud providers (AWS S3 buckets, Azure Storage accounts, Heroku apps, GitHub Pages sites, Shopify stores) allow customers to claim any name not currently registered. Abandoned CNAMEs in DNS create permanent attacker opportunities — the attacker waits for an organisation to drop a subdomain without removing the CNAME, then re-registers the cloud resource. The DNS pointer is owned by the domain operator; the resource it points to is now owned by the attacker.

Defender perspective: DNS hygiene — remove CNAMEs to decommissioned resources immediately; deploy sp=reject on the apex DMARC for any non-sending parent so any attacker takeover still cannot send DMARC-passing mail; use subdomain-takeover monitoring tools (Detectify, SecurityTrails, Subjack) that scan your DNS for dangling pointers; enable CAA records on the apex to prevent attacker certificate issuance on the takenover subdomain (which would enable HTTPS phishing sites). The takeover-prevention layer is DNS hygiene; the bypass-prevention layer is sp=reject.

6. Attacks exploiting authentication-mechanism weaknesses

This class targets weaknesses in the SPF, DKIM, and ARC authentication mechanisms that DMARC relies on. DMARC alignment passes by design once one of these mechanisms is subverted.

6.1 Attack: DKIM with 1024-bit keys — offline factoring

Attack: the targeted domain publishes a DKIM public key with a 1024-bit RSA modulus (default._domainkey.your-bank.example IN TXT "v=DKIM1; k=rsa; p=MIGfMA0..." where the base64-decoded modulus is 1024 bits). The attacker performs offline factoring of the public modulus, recovers the private key, and signs arbitrary mail with valid DKIM signatures that DMARC aligns against.

How it works: the Number Field Sieve algorithm factors 1024-bit RSA moduli for less than a few thousand US dollars of cloud compute time at 2026 prices. Historical academic results (Zachary Newman et al, 2012; the original Google DKIM disclosure circa 2012) demonstrated the attack against major brands. Once the private key is recovered, DKIM signatures the attacker produces validate identically to legitimate signatures; DMARC alignment passes because the d= signing domain is the targeted domain.

Defender perspective: publish 2048-bit DKIM keys minimum; rotate keys at least annually (quarterly for high-risk targets); monitor for unexpected DKIM signature volume suggesting key compromise; use the DNS Record Generator to produce 2048-bit DKIM records; treat any leaked key as a credential incident — revoke, rotate, audit the signature history. RFC 8301 explicitly deprecates DKIM keys smaller than 1024 bits and recommends 2048+.

6.2 Attack: DKIM replay attack

Attack: the attacker obtains a legitimate DKIM-signed message from a high- reputation sender — for example, a marketing email from a Fortune-500 brand or a transactional notification from a major bank. The attacker re-sends that exact byte-for-byte message to large numbers of unrelated recipients. The DKIM signature validates because the message bytes are unchanged; DMARC alignment passes because the From: aligns with d=.

How it works: DKIM signatures sign message bytes, not the recipient or the sending IP. A replayed message preserves every signed field — the signature is mathematically valid wherever the bytes reach. Receivers see a DMARC-pass message from a trusted sender and deliver it without skepticism. The recipient list is the attacker's, but the high reputation of the From: domain bypasses spam scoring. The 2024 gmail/yahoo bulk-sender requirements (RFC 8058 one-click List-Unsubscribe, the 5000/day threshold, the 0.3% spam cap) were partly a response to DKIM replay being weaponised at scale against legitimate senders.

Defender perspective: short DKIM key rotation cycles (weekly for high-volume senders); tight per-recipient outbound rate limits at the original sender (an unrecognised recipient list signals the message has been replayed); the IETF's DKIM Replay Problem draft explores body-length-restricted-replay mitigations and the "DKIM2" effort; abuse-feedback signals from the receiver (RFC 6650 Complaint Feedback Loop) help detect replayed campaigns. DMARC itself cannot detect or prevent this attack.

6.3 Attack: DKIM l= length-limited body-hash abuse

Attack: the targeted sender's DKIM signature carries an l=<length> tag that limits the body hash to the first N bytes. The attacker appends arbitrary content (a phishing payload, misleading instructions, attacker links) after the signed prefix; the DKIM signature still validates because only the prefix is signed.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=your-bank.example;
  l=512; bh=...; b=...

[first 512 bytes — legitimate body signed]
[arbitrary attacker payload appended — not signed but renders]

How it works: RFC 6376 §3.5 defines the l= tag as the optional body-length count: only the first l= bytes are included in the body hash. The mechanism was intended to tolerate mailing-list-appended footers without breaking signatures, but it creates a documented bypass — anything past byte N is signed by nobody yet renders to the recipient. Email clients display the entire message body including the attacker's appended payload.

Defender perspective: never use l= when signing your own mail; configure DKIM signing software (Postfix opendkim, Exchange Online, M365 DKIM, Workspace DKIM) to omit the l= tag (the default for every major implementation); audit inbound mail for suspicious l= values that suggest the original sender is mis-configured. The Email Header Analyzer surfaces the DKIM l= tag when present.

6.4 Attack: ARC chain abuse via compromised or mis-trusted sealer

Attack: the attacker controls an intermediary the receiver trusts as an ARC sealer (either through compromise of a legitimate sealer's infrastructure or by tricking an administrator into adding their domain to the trusted-sealer list). The attacker forges an ARC-Authentication-Results header claiming cv=pass on a DMARC-failing message, signs it with a valid ARC-Message-Signature from the trusted- sealer domain, and the receiver trusts the forged verdict over the local DMARC failure.

How it works: RFC 8617 defines ARC as a chain of signed headers (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) that intermediaries add to preserve upstream authentication results across hops where the message would otherwise break DMARC (mailing lists, .forward redirects, security-gateway forwards). RFC 8617 §5.2 documents the trust model: the receiver MUST verify each ARC header in the chain and decide whether to trust the chain based on the signer's reputation. Microsoft 365 Defender, Gmail, and Yahoo apply ARC trust to named intermediaries (Proofpoint, Mimecast, Cisco IronPort, etc.); administrators add additional sealers via Set-ArcConfig or equivalent. An attacker who compromises a trusted sealer's signing infrastructure — or persuades an administrator to add a malicious sealer — can bypass DMARC enforcement for any sender.

Defender perspective: conservative trusted-sealer lists (only add intermediaries you contractually trust at the privileged-identity tier); audit Set-ArcConfig changes via M365 audit logs or equivalent; monitor for unexpected ARC-Authentication-Results headers in inbound mail (the EmailHeaderParser surfaces them); treat the trusted-sealer list as a privileged-identity registry subject to change- management approvals; consider routing high-risk inbound mail (executive accounts, finance, treasury) through a secondary verification path that ignores ARC.

6.5 Attack: SPF macro and void-lookup abuse

Attack: the targeted domain's SPF record uses macros (RFC 7208 §7) that the attacker exploits to expand evaluation paths that pass for attacker-controlled IPs, OR triggers SPF void-lookups that produce permerror (which receivers historically treat as neutral, allowing the message to deliver).

v=spf1 include:%{i}.your-bank.example.spf-host.example ~all

How it works: SPF macros expand at evaluation time with the connecting IP, helo-domain, and sender-domain values, allowing DNS-based dispatch by sender attribute. A mis-designed macro can create infinite expansion paths or paths the attacker controls; void lookups (queries that return NXDOMAIN) count against the 10-DNS-lookup limit and produce permerror once exceeded. Some receivers historically treated permerror as neutral (delivered the message); RFC 7208 §8.4 clarifies that permerror SHOULD be treated as fail but compliance is incomplete.

Defender perspective: avoid SPF macros except for the specific patterns required by SES, SendGrid, or other documented use cases; audit the SPF lookup-chain via the Domain Security Checker; cap chain depth at 8-9; ensure DMARC is your enforcement layer rather than relying on SPF alone (DMARC's aspf= requires alignment, not just SPF pass — closing this particular gap).

7. Infrastructure and identity-level attacks DMARC cannot stop

The final attacker bypass class exploits legitimate infrastructure to send DMARC-passing mail. DMARC authenticates the channel; these attacks abuse that authenticated channel.

7.1 Attack: Compromised legitimate accounts (Business Email Compromise, BEC)

Attack: the attacker compromises a legitimate user account at the targeted organisation (via credential phishing, password- spray, password-database leaks, MFA-fatigue attacks, or session-cookie theft). They send phishing through legitimate authenticated mail infrastructure — Microsoft 365, Google Workspace, a customer-bound IMAP/SMTP server — with valid SPF, DKIM, and DMARC alignment.

How it works: DMARC authenticates the channel (the message was sent by an authorised sender), not the user's intent. A compromised cfo@your-bank.example mailbox is indistinguishable from a legitimate one at the DMARC layer — every authentication check passes because the message is, in fact, being sent by cfo@your-bank.example's authenticated session. MITRE ATT&CK technique T1078 Valid Accounts; the FBI IC3 BEC category accounted for $2.9B in reported US losses in 2023.

Defender perspective: defence- in-depth at the identity layer — MFA on every account (FIDO2 preferred over OTP); conditional- access policies that restrict mail-send from unfamiliar geographies, devices, or times; anomaly detection on outbound mail patterns (sudden spike, unusual recipient list, unusual subject vocabulary); user training on credential phishing and MFA-fatigue attacks. DMARC provides zero defence and is not designed to.

7.2 Attack: Compromised ESP or SaaS sender

Attack: the attacker compromises an Email Service Provider (Mailchimp, SendGrid, Mailgun, Constant Contact, HubSpot) that the targeted domain has authorised via SPF include and CNAME-delegated DKIM. They send mail from the compromised tenant; SPF passes (the IP is in the ESP's authorised pool), DKIM signs with the CNAME-delegated key that points to the ESP's key store, DMARC alignment passes.

How it works: the Mailchimp / Mailgun / SendGrid / SES delegation model places the DKIM private key under the ESP's control; the targeted domain publishes a CNAME pointing at the ESP's key store. Any breach of the ESP, mis-configuration of the ESP's tenant isolation, or compromise of an ESP-customer account can result in DMARC-passing mail being sent under the targeted domain's identity. The 2024 disclosures of multiple ESP customer-list leaks have made this an increasingly relevant threat. See DMARC for SaaS senders for the deployment-side context.

Defender perspective: minimise the ESP authorisation surface — use dedicated sub-domains for ESP-sent mail (marketing.your-bank.example via Mailchimp, not the apex); monitor RUA reports for unexpected per-IP volume changes; configure ESP-side log forwarding to your SIEM; use ESPs that publish security audit reports (SOC 2, ISO 27001); consider DKIM key rotation cadence that exceeds the ESP's default.

7.3 Attack: Mail-flow rule abuse and forwarding hijack

Attack: the attacker compromises a privileged administrator account at M365 / Workspace and creates a mail-flow rule (M365) or Routing setting (Workspace) that exfiltrates, rewrites, or redirects outbound mail. The attacker can also create a hidden Inbox forwarding rule on a single compromised mailbox to silently redirect specific messages to attacker infrastructure.

How it works: mail-flow rules are an administrator-tier capability that operates inside the trusted boundary of the organisation's mail tenant. DMARC has no role at this layer — every message produced by the rule is sent with valid SPF + DKIM + DMARC alignment. The administrator-control plane is the privileged identity attackers target after BEC. MITRE ATT&CK technique T1114.003 Email Forwarding Rule.

Defender perspective: administrative-tier MFA + privileged-identity management (PIM) policies + change-management workflows for mail-flow rule creation; auditing of forwarding-rule creation events (M365 Unified Audit Log: New-InboxRule, Set-InboxRule, New-TransportRule); periodic review of mail-flow rules against an approved baseline; alerting on the creation of any external-forward rule. DMARC provides zero defence; the entire attack happens above the DMARC layer.

7.4 Attack: BIMI logo abuse and VMC fraud

Attack: the attacker obtains a BIMI Verified Mark Certificate (VMC) for a lookalike domain or compromises the BIMI logo URL of the targeted domain to substitute their own logo. The receiver displays the attacker's logo or a logo that is the targeted brand's logo against an attacker-controlled identity.

How it works: BIMI (draft-brand-indicators-for-message-identification) displays a brand logo in the receiver inbox alongside DMARC-passing mail from the targeted domain. The logo URL is published in the BIMI record at default._bimi.<domain>; receivers fetch the SVG and optionally verify a VMC certificate chain. If the targeted domain points its BIMI record at an HTTP URL the attacker can intercept, or hosts the SVG on infrastructure the attacker compromises, the inbox displays the attacker's logo. Misissued VMCs (rare but historically documented) similarly enable lookalike-brand logo display.

Defender perspective: host the BIMI logo on HTTPS infrastructure under tight access control; cache-control headers that prevent replacement; deploy a VMC from a reputable CA (DigiCert, Entrust) following BIMI explained guidance; monitor BIMI display status across receivers; treat BIMI as a brand-display enhancement rather than an authentication primitive (it relies on DMARC being correctly deployed). The attack vector is narrow but real.

8. Attack frequency by class

Not every attack class is equally common. The table below estimates the relative frequency of each bypass class against typical mid-to-large enterprises in 2026, based on industry incident reports (Verizon DBIR, FBI IC3, Coveware ransomware reports, vendor threat intelligence). Use it as the prioritisation reference when allocating defensive investment.

The pattern is clear: the highest- frequency attacks (display-name spoofing, BEC, lookalike domains, p=none gaps) are the lowest- sophistication attacks — exactly because they bypass DMARC trivially. Defensive investment should follow frequency, not sophistication.

9. Operator countermeasures matrix

The matrix maps each attack class to the countermeasure stack a defender deploys. Read left-to-right: if you are vulnerable to attack X, deploy controls Y, Z, and W. No single control covers more than a fraction of the bypass surface — defence-in-depth is the only sustainable posture.

10. Indicators of an in-progress DMARC bypass attempt

The DMARC Analyzer dashboard and the underlying includes/DmarcParser.php + includes/ForensicReportParser.php surfaces are designed to expose the indicators below in RUA aggregate report data. Wire each indicator to an alerting rule (PagerDuty / Splunk / Sentinel) with a 15-minute response SLA for high-severity cases.

1. Sudden spike in DMARC-failing messages from a single sending IP block. Attacker infrastructure performing a campaign from a previously-unseen IP range. Threshold: any new sending IP with >100 messages/day and zero historical reputation. Defender action: investigate the IP block (whois, reputation feeds), correlate with internal incident tickets, advance to p=reject if still at p=quarantine.
2. DMARC-passing messages from sending IPs you never inventoried. Could be a compromised ESP, a third-party sender abusing your include:, a forgotten internal sender, or an early-stage account takeover sending through legitimate infrastructure. Defender action: cross-check the IP against your sender inventory, contact the apparent owner, validate via the Email Header Analyzer with a sample message.
3. NXDOMAIN bounces from your monitoring mailbox spike. Receivers cannot deliver RUA reports — suggests a DNS-spoofing attack against your reporting endpoint or a legitimate outage of the report mailbox host. Defender action: verify the rua=mailto: address resolves correctly via independent DNS resolvers; verify the mailbox accepts mail with a synthetic test from report-validator services.
4. BIMI logo display drops on Gmail or Yahoo. DMARC policy regression (dropped from p=quarantine to p=none) or a BIMI selector mismatch attackers exploit (compromised logo URL, expired VMC). Defender action: verify DMARC policy via the Domain Security Checker, verify BIMI record + VMC chain.
5. User reports of recipient confusion involving lookalike domains. The lookalike attack class DMARC does not block, but human reporting surfaces the campaign. Defender action: capture the lookalike domain in the threat-intel feed, initiate takedown via brand-monitoring service, alert email gateways to score messages from the lookalike more aggressively.
6. New trusted-sealer added to ARC configuration without change-management ticket. M365 Set-ArcConfig change or Workspace equivalent that did not flow through the privileged-identity-management workflow. Defender action: revoke the change, audit the administrator account that initiated it, rotate credentials.
7. Unexpected DKIM signature volume on a public key suggesting key compromise. Volume that exceeds your sender's known send rate, or signatures from IPs you never used. Defender action: rotate the DKIM key immediately, audit the signature history, treat as a credential incident.

11. FAQ

Can attackers bypass DMARC at p=reject?

Direct domain spoofing of the visible From: header is blocked once DMARC reaches p=reject with full SPF and DKIM alignment. Attackers therefore pivot to bypass classes that DMARC was never designed to block: lookalike-domain phishing (vvise.example vs wise.example), IDN homograph attacks (Cyrillic а vs Latin a), 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 the targeted domain, and brand impersonation from unrelated domains. RFC 7489 §3 anchors DMARC against the visible From: header (RFC 5322); any attack that changes the From: address rather than spoofs it is out of scope.

What is a DMARC homograph attack and how does it bypass DMARC?

A homograph attack registers a domain that visually resembles the target by substituting Unicode characters from non-Latin scripts that share glyph shapes with ASCII Latin letters — Cyrillic а (U+0430) for Latin a (U+0061), Greek ο (U+03BF) for Latin o (U+006F), Latin small letter g with stroke ǥ (U+01E5) for ASCII g. The attacker registers the resulting IDN punycode domain (xn--... form), publishes their own DMARC record on it, sends DMARC-passing mail from it, and recipients see what looks identical to the target domain in the From: header. DMARC has no opinion on IDN or homograph relationships — every authentication check passes for the attacker domain. Defence is brand-monitoring services that proactively register confusable IDNs, gateway homograph detection that flags non-ASCII From: domains, and DNSSEC-signed CAA records that prevent attacker certificate issuance on the lookalike.

What is a DKIM replay attack and what does it have to do with DMARC bypass?

In a DKIM replay attack, an attacker obtains a legitimate DKIM-signed message from a high-reputation sender (gmail.com, microsoft.com, paypal.com), then re-sends that exact byte-for-byte message to large numbers of unrelated recipients. The DKIM signature still validates because the message bytes are unchanged; DMARC alignment still passes because the original From: still aligns with the original d=. Recipient receivers see a DMARC-pass message from a trusted sender and deliver it without skepticism — but the recipient list is the attackers, not the original senders. The 2024 gmail/yahoo bulk-sender requirements (RFC 8058 one-click List-Unsubscribe + 5000/day threshold + 0.3% spam cap) were partly a response to DKIM replay being weaponised at scale. Defence is short DKIM key rotation cycles, the "RFC 6376bis" body-length-restricted-replay mitigation drafts, and tight per-recipient rate-limiting on outbound mail at the original sender.

How does subdomain takeover bypass DMARC?

An attacker identifies a subdomain of the target whose DNS still points at a cloud provider (S3 bucket, Azure resource, Heroku app, GitHub Pages site) that has been decommissioned or moved without removing the CNAME. The attacker re-registers the orphaned cloud resource under the same name and now controls a subdomain of the target. If the apex DMARC record lacks sp= protection, the inherited policy applies but the subdomain has no DKIM or SPF that would prevent the attacker — so they publish their own SPF + DKIM, host a phishing site at the takenover subdomain, and send DMARC-passing mail from notifications@takenover-subdomain.target.example. Defence is sp=reject on the apex DMARC for non-sending parents, DNS hygiene to remove abandoned CNAMEs, and Subdomain takeover monitoring tools that detect dangling DNS records.

Why does p=none provide zero protection against attackers?

p=none instructs receivers to take no enforcement action on DMARC-failing messages — they deliver normally. The only signal p=none generates is the aggregate report (RUA) flow back to the operator. Attackers know this: spoofing a domain at p=none reaches the inbox at the same rate as legitimate mail. Many large brands are stuck at p=none for years during rollout because the operator never advances through p=quarantine to p=reject — leaving an indefinite window in which attackers spoof the domain with no consequence. The corrective action is the phased rollout playbook in help_dmarc_policy_rollout.php: p=none for 30-60 days of inventory, p=quarantine + pct=10 ramping to pct=100 over 30-60 days, then p=reject. The Feb 2024 Google/Yahoo bulk-sender requirements raised the floor by requiring at least p=none from any sender to 5000+ recipients/day — but p=none is still only the minimum starting position, never the destination.

How do attackers exploit the pct= tag during DMARC rollout?

pct= specifies the percentage of failing mail that receives the enforcement action; the remaining 1-pct percentage receives the next-weakest action. An organisation at p=reject; pct=10 only rejects 10% of failing mail; the other 90% receives p=quarantine treatment (delivered to spam). Attackers therefore have a 90% chance their spoofing reaches the spam folder (where users still recover false-positives from time to time) instead of being rejected at the SMTP layer. Operators who set pct=10 as a "safety net" and forget to ramp it up leave a permanent attacker window. The corrective action is monotonic advancement: pct=10 → 25 → 50 → 100 over 4-8 weeks, observing RUA reports for legitimate-sender breakage at each step, then removing the pct= tag entirely (equivalent to pct=100) once stable. RFC 7489 §6.3 defines pct= explicitly as a rollout dial, not a permanent setting.

Can ARC be abused to bypass DMARC enforcement?

In principle, yes — but the attack requires the attacker to operate from infrastructure the receiver explicitly trusts as a "trusted ARC sealer". Defender for Office 365 (Microsoft 365) lets administrators name trusted ARC sealers via Set-ArcConfig; Gmail and Yahoo apply ARC trust to a fixed set of large intermediaries (Proofpoint, Mimecast, Cisco IronPort). An attacker who compromises one of these intermediaries — or who tricks an administrator into adding their domain to the trusted-sealer list — can forge an ARC-Authentication-Results header claiming cv=pass, sign it with a valid ARC-Message-Signature from the trusted-sealer domain, and the receiver will trust the forged verdict over the local DMARC failure. Defence is conservative trusted-sealer lists (only add intermediaries you contractually trust), monitoring Set-ArcConfig changes, and treating ARC trust as a privileged identity equivalent to a CA. RFC 8617 §5.2 documents the trust model explicitly and warns against permissive trusted-sealer configuration.

What indicates an in-progress DMARC bypass attempt against my domain?

Five canonical indicators from RUA aggregate reports: (1) a sudden spike in DMARC-failing messages from a single sending IP block you did not authorise — typically attacker infrastructure performing a campaign; (2) DMARC-passing messages from sending IPs you never inventoried — could be a compromised ESP or a third-party sender abusing your include:; (3) NXDOMAIN bounces from your monitoring mailbox spiking — receivers cannot deliver RUA reports, suggesting a DNS-spoofing attack on your reporting endpoint; (4) BIMI logo display dropping suddenly on Gmail / Yahoo — DMARC policy regression or a BIMI selector mismatch attackers exploit; (5) reports of recipient confusion involving lookalike domains — the lookalike attack class DMARC does not block, but which the abuse signal still surfaces in user feedback. Operationalise these via the monitoring playbook in help_dmarc_monitoring.php with weekly RUA review and PagerDuty alerts on threshold breaches.

12. 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.
• SPF 10-DNS-lookup limit (RFC 7208 §4.6.4) — the ATTACKER-EXPLOITS-SPF-PERMERROR companion to this attacker-bypass catalogue. Where THIS page documents 22 application-layer attacker techniques that bypass a DMARC deployment by manipulating the From: header organisational domain at the application layer (display-name spoof, cousin-domain registration, ARC trust-chain abuse, DKIM replay, vendor compromise, BEC), the SPF-lookup-limit spoke documents a STRUCTURALLY-DISTINCT bypass technique class — the attacker EXPLOITS the receiver- side `permerror` enforcement contract by engineering conditions that force the VICTIM domain's SPF record to saturate the 10-lookup budget, causing receiver-side SPF-fail across the entire victim outbound surface. The ATTACKER-TECHNIQUE- VS-SPF-LOOKUP-LIMIT cross-reference establishes FOUR structurally-distinct bypass dimensions complementing the 22 on-page techniques: (i) per- include-sub-record COMPROMISE as supply- chain attack — when an attacker compromises a third-party ESP's authorisation-SPF sub-record (the include:<esp>.com cascade target), the attacker can either ADD authorised egress IPs (creating an attacker-side egress channel from the victim's domain) OR REMOVE authorised IPs (forcing legitimate-flow SPF-fail across the entire victim outbound surface) — the SPF-lookup-limit spoke documents the per-include-cascade recursive-resolution algorithm receivers apply, exposing the attacker-observability surface a victim domain's apex SPF record creates through its include-cascade; (ii) per- evaluation void-lookup DoS — an attacker with control over an authoritative DNS server in the victim's include-cascade sub-zone can engineer SERVFAIL or intermittent-NXDOMAIN responses that the receiver counts against the §4.6.4 void-lookup cap of 2 — the SPF- lookup-limit spoke documents the void- lookup cap enforcement contract receivers apply at evaluation time; a sustained attack against a victim's authoritative- DNS-server availability accumulates void- lookups receiver-side and produces `permerror` cascading into DMARC-fail across the entire victim outbound surface (a particularly insidious bypass because the attacker NEVER NEEDS TO REACH the victim's apex DNS to break SPF — only the sub-zone DNS that include: traversal queries); (iii) per- operator slow-creep accumulation as attacker-amplification surface — every legacy include: token the victim operator never retires (a former ESP that has retired its authorisation-SPF sub-record) silently accumulates void- lookups against the §4.6.4 cap; the SPF-lookup-limit spoke documents the operator-side hygiene discipline (per- quarterly include-cascade audit, dig +short txt _spf.<esp>.com verification, retire-on-zero-traffic rule) that closes this slow-creep attacker-amplification surface BEFORE the 2-cap saturates and produces the same catastrophic legitimate-flow SPF-fail an active attacker would otherwise need to engineer; (iv) per-victim apex- domain +all qualifier misconfiguration as attacker-EXPANSION surface — when an attacker discovers a victim's apex SPF record terminates with +all (rather than -all / ~all), the entire IPv4+IPv6 space is treated as authorised egress for the victim's domain; the SPF-lookup-limit spoke documents the per-qualifier receiver-side evaluation semantics and the canonical operator-side audit pattern (terminating -all required for DMARC p=reject effectiveness — the p=reject posture documented across the 22 on-page techniques DOES NOT defeat +all-terminated apex SPF records because attacker traffic from any IP receives SPF-pass). Pair this page (the application-layer attacker-technique catalogue) with the SPF-lookup-limit spoke (the receiver-side enforcement- contract and attacker-observability- surface reference) when assessing the complete bypass-technique attack surface a domain's deployed posture exposes — the 22 application-layer techniques on this page document the From:-header-spoof bypass class; the SPF-lookup-limit attacker-bypass dimensions document a STRUCTURALLY-DISTINCT bypass class targeting the supply-chain and the receiver-side enforcement contract itself.
• MTA-STS policy file byte-syntax — the TRANSPORT-LAYER-PARALLEL-DEFENSE- LAYER-BYTE-SYNTAX-REFERENCE companion to this attacker-bypass catalogue. Where THIS page documents the 22 attacker techniques that bypass a DMARC deployment at the APPLICATION LAYER (display-name spoofing, lookalike-domain registration, ARC trust-chain abuse, DKIM replay, third-party-vendor compromise, BEC via compromised legitimate accounts, etc.), the MTA-STS-policy-syntax spoke documents the TRANSPORT-LAYER PARALLEL DEFENSE LAYER — the byte-syntax of the policy file published at https://mta-sts.<domain>/.well-known/mta-sts.txt whose version: STSv1 / mode: enforce / mx: <pattern> / max_age: <seconds> tag grammar instructs sending MTAs to refuse to downgrade an SMTP session to cleartext when the receiver-side TLS handshake fails or the certificate does not match the policy-file's MX hostname patterns. The four-axis APPLICATION-LAYER-ATTACK-VS-TRANSPORT-LAYER- DEFENSE comparison exposes the structurally- distinct ATTACK-SURFACE-COVERAGE roles: (i) none of the 22 DMARC-layer attack techniques on this page are defended by MTA-STS at all — DMARC operates on the From: header organisational domain at the application layer; MTA-STS operates on the SMTP-receive TLS handshake at the transport layer; the two protocol layers defend ORTHOGONAL attack classes, not overlapping ones; (ii) the STARTTLS-stripping / network-MITM / downgrade-to-cleartext attack class — which is NOT in the 22 DMARC-layer techniques on this page — is defended by an mode: enforce MTA-STS policy file whose byte-syntax the spoke documents; an attacker positioned on the path between sender and receiver who would otherwise downgrade the SMTP session to cleartext and exfiltrate the message body (including credentials, sensitive PII, password-reset tokens) is blocked at the mode: enforce contract; (iii) publishing the MTA-STS policy file with byte-syntax-correct version / mode / mx / max_age tags is INDEPENDENT of the DMARC posture — a domain at p=reject can still leak in cleartext if it does NOT publish an mode: enforce MTA-STS policy; the spoke documents the byte-syntax contract operators MUST get right to close the transport-layer gap the attacker-bypass page does not address; (iv) the MTA-STS policy-file byte-syntax spoke is the operational complement to this attacker-bypass catalogue — a complete defender's posture requires BOTH the application-layer DMARC enforcement at p=reject documented on this page AND the transport-layer MTA-STS enforcement at mode: enforce documented by the spoke. Read the MTA-STS-policy-syntax spoke when designing a complete attacker-defense posture: the attacker-bypass catalogue documents WHICH DMARC-LAYER attack techniques remain exploitable, and the MTA-STS-policy- syntax spoke documents the TRANSPORT- LAYER PARALLEL defense that closes the STARTTLS-stripping / network-MITM gap the DMARC layer cannot defend.
• DMARC myths and misconceptions — the defender-perspective dual to this page; corrects 18 common mental-model errors about what DMARC does and does not do.
• DMARC policy modes — p=none vs p=quarantine vs p=reject (the ATTACKER-DEFEAT-POLICY-CHOICE-INPUT companion to this attacker-bypass taxonomy) — the ATTACKER-DEFEAT-POLICY-CHOICE-INPUT companion documenting the head-to-head comparison of the three DMARC enforcement values p=none / p=quarantine / p=reject whose VALUE-CHOICE determines WHICH of the 22 attack techniques catalogued on this page the receiver actually blocks. Where THIS page documents the 22 attacker techniques that bypass a DMARC deployment regardless of policy mode (display-name spoofing, lookalike-domain registration, ARC trust-chain abuse, DKIM replay, third-party-vendor compromise, etc.), the policy-modes spoke documents the THREE policy-mode values themselves and the receiver- side enforcement contract each implies — the VALUE-CHOICE that determines whether DMARC ENFORCES at all (p=none means receivers IGNORE the DMARC verdict and deliver-to-inbox even on policy_evaluated=fail rows, p=quarantine means receivers DELIVER-TO-JUNK on fail rows, p=reject means receivers SMTP-REJECT-AT-RCPT or DROP on fail rows). Every one of the 22 attack techniques on this page is structurally orthogonal to the policy-mode choice (none of them CAUSE a policy_evaluated=fail row — they all pass DMARC's check), but the policy-mode choice determines whether the OTHER ~98% of incoming spoof attempts (the ones that DO produce policy_evaluated=fail rows) get blocked at the receiver. Read the policy-modes spoke when designing the cross-layer defence posture documented here — the 22 bypass techniques require the LAYERED defences this page catalogues (SEG controls, anti-impersonation rules, BIMI logo display, user-training), but the broader bypass-attempt surface that produces explicit DMARC-fail rows is closed only when the operator advances to p=reject. The 22 techniques here are the RESIDUAL surface AFTER policy=reject — the policy-modes spoke is the PRE-CONDITION reference documenting how to GET to p=reject in the first place.
• Phishing protection — the operational defender's playbook for the broader phishing-and-credential-theft threat class that every §4 / §5 / §6 / §7 bypass on this page feeds into. Where this page enumerates 22 attacker techniques against the DMARC layer specifically, the phishing-protection page covers the layered defense stack above and below DMARC: SEG / secure email gateway 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. Pair this page (the threat-model / red-team analysis) with the phishing-protection page (the blue-team / control-design playbook) for the complete attack-and-defense view.
• Email spoofing — the technique-level deep dive on 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 underpin §4 (direct From-identity attacks) and §6 (authentication-mechanism attacks) on this page. Where this page enumerates the bypass techniques at the DMARC layer, the spoofing page documents the underlying RFC 5321 / 5322 mechanics each technique depends on plus the operator-side protections (RFC 5322 From: validation, Display-Name policy, IDN/Punycode normalisation, Reply-To allowlisting, Received-chain anomaly detection). Pair for the complete protocol-mechanic-to- bypass-technique chain.
• DANE for SMTP (RFC 7672) explained — the THREAT-CATALOGUE-CONSUMER transport- layer-MITM-defense companion documenting the RFC 7672 DNSSEC-anchored TLSA-based certificate-pinning mechanism that closes the transport-layer-MITM / SMTP-STARTTLS- downgrade / on-path-MTA-impersonation attack class structurally distinct from the 22 message-identity-layer techniques this page catalogues. Where THIS page enumerates 22 attacker techniques against the DMARC message-identity-layer specifically (display- name spoofing, lookalike-domain registration, ARC trust-chain abuse, DKIM replay, third- party-vendor compromise, l= tag abuse, etc.), the DANE-for-SMTP spoke is the TRANSPORT- LAYER-MITM-DEFENSE companion documenting how a network-position attacker (BGP-hijacker, on-path ISP, hostile DNS resolver, AiTM- SMTP-proxy) impersonates the receiving MTA by stripping STARTTLS or presenting a forged certificate — a class of attack the 22 DMARC- layer techniques cannot reach because they target the message-identity layer above the transport. The four-axis BYPASS-CATALOGUE-VS- DANE-DEFENSE comparison exposes the structurally- distinct THREAT-LAYER boundaries: (i) 22 techniques target message-identity layer, DANE protects transport layer — the 22 techniques produce messages whose From-header / DKIM-signature / SPF-result bypasses DMARC's identifier-alignment check; DANE protects against attackers who intercept the SMTP delivery channel BEFORE the message identity becomes a concern; the two attack surfaces are ORTHOGONAL; (ii) DANE defeats transport-layer-MITM-impersonation even when the message-identity is legitimate — an attacker who hijacks SMTP delivery to Acme Bank's MX server can capture and manipulate the legitimately-DKIM-aligned-from- bank message; DANE's TLSA-pinning prevents this interception by requiring the sending MTA to validate the receiver-MTA's cert against the DANE TLSA hash; (iii) operator deploying DMARC at p=reject who has NOT deployed DANE or MTA-STS still has transport-layer residual — the bypass catalogue on this page focuses on message-identity- layer residual, but the FULL bypass surface includes the transport layer DANE addresses; operators reading this catalogue MUST also evaluate transport-layer-defense posture; (iv) DANE failure mode is TLS-RPT-reported sts-webpki-invalid / certificate-host-mismatch / starttls-not- supported — the bypass-catalogue on this page does not include transport- layer failure modes because those surface in TLS-RPT not in DMARC-aggregate-RUA; the operator-side detection mechanism is a SEPARATE reporting channel from the DMARC reporting channel. Read the DANE-for-SMTP page alongside this bypass catalogue when scoping the FULL attacker-surface posture: this page documents the 22 message-identity- layer techniques, DANE documents the transport-layer-MITM-defense, and the two together name the complete attacker-surface DMARC + DANE deployment closes.
• Reverse DNS / PTR records for mail servers — the BOT-NET-IMPERSONATION-DEFENSE-AND- COMPROMISED-OUTBOUND-IP-FORENSIC-ATTRIBUTION- VIA-FCRDNS-AT-INBOUND-MX-RECEIVER-BOUNDARY companion to this attacker-bypass taxonomy. Where THIS page documents the 22 attacker techniques against the DMARC message- identity-layer (alignment-evasion class, authentication-evasion class, policy- evasion class, infrastructure-evasion class), the reverse-DNS-PTR spoke documents the IN-ADDR.ARPA / IP6.ARPA PTR-RR publication discipline whose receiver-side FCrDNS (Forward-Confirmed reverse DNS) verification — RFC 1912 §2.1 + RFC 5321 §4.1.1.9 — is the IP-IDENTITY- VALIDATION gate that closes the FIVE structurally-distinct PTR-FCrDNS-relevant attacker-bypass classes the threat-actor TTP catalogue surfaces: (i) BOT-NET- COMPROMISED-RESIDENTIAL-IP-AS-OUTBOUND- RELAY (T1584.005 compromise-infrastructure botnet) where the attacker pivots through a compromised residential IP whose residential-ISP PTR pattern is structurally distinct from any legitimate enterprise- outbound-MTA PTR pattern — the receiver- side FCrDNS check at inbound MX produces an absent-or-residential-PTR verdict that the receiver's anti-spoofing layer weights as bot-net-signal; (ii) COMPROMISED-CLOUD-VM-AS-OUTBOUND-RELAY (T1078.004 valid-accounts cloud) where the attacker pivots through a cloud-VM whose default cloud-provider auto- assigned PTR (e.g., default ec2-203-0-113-1.compute-1.amazonaws.com for unconfigured AWS EC2) is STRUCTURALLY-DISTINCT from any tenant- custom-PTR-published enterprise-outbound- MTA — the receiver-side FCrDNS check produces a generic-cloud-provider-PTR verdict the receiver's anti-spoofing layer weights down; (iii) DANGLING-PTR- AT-DECOMMISSIONED-IP-RANGE-AS-LATERAL- IP-IDENTITY-HIJACK (T1583.004 acquire- infrastructure IP-takeover) where the attacker acquires an IP range whose previous legitimate owner's PTR records remain published with the OLD owner's FQDN, allowing the attacker to impersonate the previous owner's outbound-mail PTR pattern until the previous-owner's PTR is rotated; (iv) ABUSE-OF-SHARED-OUTBOUND-IP-WITHOUT- TENANT-SPECIFIC-PTR-CONFIGURATION at ESP / SMTP-relay platforms where the attacker's compromised-tenant-account emits outbound mail through the shared- outbound-IP-pool whose PTR is the ESP's master FQDN rather than the compromised tenant's identity — the FCrDNS check passes the ESP-master-FQDN but the per-tenant identity attribution is structurally LOST at the PTR layer (mitigation: ESP-supplier tenant- specific-PTR configuration where available); (v) FORENSIC-ATTRIBUTION- FAILURE-VIA-NXDOMAIN-PTR at misconfigured-or-malicious outbound-IP where the attacker EXPLICITLY publishes NO PTR record so post-incident forensic attribution back to the IP-block-owning organization is structurally impossible (mitigation: receiver-side no-PTR-verdict = treat as untrusted- outbound-IP weight class). Read the reverse-DNS-PTR spoke when constructing the threat-model treatment of compromised- outbound-IP attacker bypass classes catalogued in §6 of this taxonomy — the spoke documents the in-addr.arpa PTR-publication discipline and the receiver-side FCrDNS verification protocol that EVERY major mailbox- provider receiver (Gmail, Outlook.com, Yahoo, Apple iCloud, ProtonMail) enforces at inbound MX to produce the IP-identity verdict that the anti-spoofing layer composes with the message-identity-layer DMARC verdict this page treats.
• MX records explained — the THREAT-CATALOGUE-CONSUMER MX-TAKEOVER- PUNYCODE-CONFUSABLE-DELEGATION-DANGLING-MX- AS-ATTACK-VECTOR-CLASS companion documenting the authoritative-DNS MX record object whose misconfiguration / registrar-compromise / dangling-MX / Punycode-confusable-subdomain- delegation surfaces an attack vector class structurally distinct from the 22 message- identity-layer techniques this page catalogues. Where THIS page enumerates 22 attacker techniques against the DMARC message-identity- layer specifically (display-name spoofing, lookalike-domain registration, ARC trust-chain abuse, DKIM replay, third-party-vendor compromise, l= tag abuse, etc.), the MX-records spoke is the AUTHORITATIVE-DNS-OBJECT-TAKEOVER companion documenting how an attacker who controls the authoritative MX publication for the receiver domain (via registrar account compromise, nameserver-account compromise, dangling-CNAME to abandoned hostname, Punycode-confusable sibling-subdomain MX publication) redirects ALL inbound mail flow to an attacker-controlled SMTP receiver — a class of attack the 22 DMARC-layer techniques cannot reach because they operate above the SMTP-receive boundary. The four-axis BYPASS-CATALOGUE-VS-MX-TAKEOVER- DEFENSE comparison exposes the structurally- distinct THREAT-LAYER boundaries: (i) 22 techniques target message-identity layer, MX-takeover redirects the entire SMTP-delivery target — the 22 techniques produce messages whose identifier-alignment bypasses DMARC; MX-takeover captures every legitimately-DMARC-aligned inbound message at the receiver before message-identity even comes into play; the two attack surfaces are ORTHOGONAL; (ii) dangling-MX delegation (an MX pointing to a hostname that no longer exists or has been abandoned at the cloud provider) lets the attacker register the abandoned host and receive ALL future mail for the publisher's domain — a documented class against decommissioned mail-hosting subdomains and recycled cloud-instance hostnames; (iii) Punycode-confusable- MX-subdomain attacks publish MX records for a homoglyph variant of the publisher's domain (аcme.example with Cyrillic а vs acme.example with Latin a) and intercept mail from senders who typo or paste the confusable name — the message-identity-layer DMARC defense cannot detect this because the confusable-subdomain's DMARC posture is independently authored by the attacker; (iv) registrar-account or authoritative-nameserver-account compromise replaces the publisher's MX records wholesale with attacker-controlled hosts — a catastrophic-but-temporary attack window during which every inbound mail is intercepted; the defense is registrar-side MFA + DNSSEC + monitoring of MX-record-change-event notifications, not a DMARC-layer control. Read the MX-records spoke alongside this bypass catalogue when scoping the FULL attacker-surface posture: this page documents the 22 message-identity-layer techniques, MX-records documents the authoritative-DNS- object-takeover threat class, and the two together name the SMTP-receive-side attacker- surface boundary that DMARC + MX-record- publication-hardening together close.
• MTA-STS for Microsoft 365 — the DMARC-ATTACKER-BYPASS-STRIPTLS- OPPORTUNISTIC-TLS-DOWNGRADE-CA-FORGERY- DEFENSE-AT-EXCHANGE-ONLINE-MX-RECEIVE- BOUNDARY companion reference. Where THIS page enumerates 22 attacker techniques against the DMARC message-identity-layer specifically (display-name spoofing, lookalike-domain registration, ARC trust- chain abuse, DKIM replay, third-party- vendor compromise, l= tag abuse, etc.), the MTA-STS-for-Microsoft- 365 spoke is the TRANSPORT-LAYER-MITM- DEFENSE companion documenting how the M365-tenant operator publishes an MTA-STS policy whose enforced-mode TLS-policy prevents the SUBSET of §7 transport- layer-MITM attackers that target the sending-MTA-to-Exchange-Online-MX-receive path — specifically StripTLS attackers who downgrade opportunistic TLS to plaintext SMTP at the Exchange-Online MX boundary, BGP-hijack attackers who reroute SMTP delivery to a forged-cert MTA impersonating <customer-vanity-domain>-com.mail. protection.outlook.com / <tenant>.mail.protection.outlook.com, and AiTM-SMTP-proxy attackers operating on the network segment between sending MTA and the Exchange-Online tier'd MX inventory. The Microsoft-365 MTA-STS spoke documents the OPERATOR-PUBLISHED _mta-sts.<customer-vanity- domain> TXT-record + HTTPS-hosted policy file at https://mta-sts.<customer-vanity- domain>/.well-known/mta-sts.txt with version: STSv1, mode: enforce, the M365 Exchange-Online MX allow-list (the *.mail.protection.outlook.com wildcard or tenant-specific <customer-vanity-domain>-com.mail.protection.outlook.com A-record-terminating MX-host inventory), and an appropriate max_age: cache lifetime — DISTINCT from the Workspace MTA-STS deployment spoke covered below (different MX inventory, different propagation characteristics, different M365 Defender-portal + Exchange-Admin-Center configuration UI surface). The five-axis BYPASS-CATALOGUE- VS-M365-MTA-STS-DEFENSE comparison exposes the structurally-distinct THREAT-LAYER boundaries M365-MTA-STS-enforce-mode closes against the 22 message-identity- layer techniques: (i) 22 techniques target message-identity layer, M365 MTA- STS-enforce-mode constrains the transport- layer delivery channel — the 22 techniques produce messages whose From- header / DKIM-signature / SPF-result bypasses DMARC's identifier-alignment check; the M365 spoke's mode:enforce + mx: *.mail.protection.outlook.com constrains the transport-layer delivery channel REGARDLESS of any application- layer identifier-alignment outcome the receiver computes; (ii) M365 MTA-STS defeats §7 transport-layer-MITM- impersonation even when the message- identity is fully attacker-crafted — an attacker who hijacks SMTP delivery to impersonate the Exchange-Online MX can capture and manipulate ANY inbound message destined for the M365 tenant regardless of the message's DMARC verdict; M365 MTA-STS-enforce-mode prevents this interception by requiring the sending MTA to validate the receiver- MTA's cert against the M365-tenant operator-published policy's MX allow-list AND CA-authorization chain; (iii) operator deploying DMARC at p=reject on an M365-hosted domain who has NOT deployed M365 MTA-STS still has the transport-layer residual attack surface this page's §7 catalogues as a structurally-distinct attack class — DMARC alone closes the application-layer-identifier-alignment- bypass surface (the 21 of 22 non-transport techniques) but the §7 transport-layer- MITM residual requires the M365 MTA-STS- for-Microsoft-365 spoke's mode:enforce publication discipline as the load-bearing operator- side closure; (iv) M365 MTA-STS failure mode is TLS-RPT-reported sts-webpki-invalid / sts-policy-fetch-error / sts-policy-invalid / certificate-host-mismatch at the customer-vanity-domain TLS-RPT subscriber endpoint — providing the operator with primary forensic evidence for the silently-failing M365-tenant transport-layer defense posture; (v) M365 MTA-STS rotation cadence aligns with the Exchange-Online tier'd MX inventory Microsoft refreshes on a Microsoft- managed schedule — the operator- side max_age: selection must accommodate Microsoft's tier'd MX-host refresh cadence; the spoke documents this cadence and the operator-side rotation discipline that bounds the max-cache-validity window for the operator's published mx: allow-list. Read the Microsoft-365 MTA- STS spoke alongside this bypass catalogue when scoping transport-layer-MITM defense for an M365-hosted protected domain — the Exchange-Online-MX-receive-side StripTLS / BGP-hijack / forged-cert / AiTM-SMTP- proxy attack subset is structurally distinct from the Workspace-MX-receive- side equivalent class and requires its own M365-specific MTA-STS publication discipline.
• MTA-STS for Google Workspace — the DMARC-ATTACKER-BYPASS-STRIPTLS- OPPORTUNISTIC-TLS-DOWNGRADE-CA-FORGERY- DEFENSE-AT-WORKSPACE-MX-RECEIVE-BOUNDARY companion reference. Where THIS page enumerates 22 attacker techniques against the DMARC message-identity-layer specifically (display-name spoofing, lookalike-domain registration, ARC trust-chain abuse, DKIM replay, third- party-vendor compromise, l= tag abuse, etc.), the MTA-STS-for-Google-Workspace spoke is the TRANSPORT-LAYER-MITM-DEFENSE companion documenting how the Workspace- tenant operator publishes an MTA-STS policy whose enforced-mode TLS-policy prevents the SUBSET of §7 transport- layer-MITM attackers that target the sending-MTA-to-Workspace-MX-receive path — specifically StripTLS attackers who downgrade opportunistic TLS to plaintext SMTP at the Workspace MX boundary, BGP-hijack attackers who reroute SMTP delivery to a forged-cert MTA impersonating aspmx.l.google.com / alt1.aspmx.l.google.com / alt2.aspmx.l.google.com / alt3.aspmx.l.google.com / alt4.aspmx.l.google.com, and AiTM-SMTP-proxy attackers operating on the network segment between sending MTA and the Workspace tier'd MX inventory. The Workspace MTA-STS spoke documents the OPERATOR-PUBLISHED _mta-sts.<domain> TXT-record + HTTPS-hosted policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt with version: STSv1, mode: enforce, the Workspace MX allow-list (the 5-MX tier'd aspmx.l.google.com + alt{1,2,3,4}.aspmx.l.google.com inventory), and an appropriate max_age: cache lifetime — DISTINCT from the M365 MTA-STS deployment spoke covered above (different MX inventory, different propagation characteristics, different Workspace Admin Console configuration UI). Read the Workspace MTA-STS spoke alongside this bypass catalogue when scoping transport-layer-MITM defense for a Workspace-hosted protected domain — the Workspace-MX-receive-side StripTLS / BGP-hijack / forged-cert / AiTM-SMTP- proxy attack subset is structurally distinct from the M365-EOP-receive-side equivalent class and requires its own Workspace-specific MTA-STS publication discipline.
• 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 that bypass §5 references.
• DMARC alignment explained — the identifier-alignment mechanism every bypass in §4 and §5 routes around.
• DMARC policy rollout — the phased playbook that closes the p=none and pct<100 gaps documented in §5.1 and §5.2.
• DMARC multi-domain strategy — the WEAKEST-LINK-IN-MULTI-BRAND-PORTFOLIO companion documenting the per-org-domain rollout discipline required to eliminate the lateral attacker-impersonation surface that this bypass taxonomy's §4.3 (lookalike-domain registration) and §4.4 (cousin-domain-from-the-same-portfolio- spoofing) attack subset exploits when an organisation publishes p=reject on its PRIMARY brand domain but leaves SECONDARY brand domains / PARKED domains / LEGACY- ACQUISITION domains / REDIRECTOR domains / SUB-BRAND SaaS domains at p=none / no-DMARC / no-SPF / no-DKIM. Where THIS page catalogues 22 attacker techniques against a single protected domain's DMARC layer specifically (display-name spoofing, lookalike- domain registration, ARC trust-chain abuse, DKIM replay, third-party-vendor compromise, l= tag abuse, etc.), the multi- domain-strategy spoke is the PORTFOLIO-LEVEL-DEFENCE-COMPLETENESS companion documenting the org-wide rollout posture that prevents the attacker from PIVOTING to a weaker portfolio sibling — the attacker economics shift dramatically when ALL portfolio domains are at p=reject with full SPF + DKIM + DMARC alignment (no portfolio-sibling weak link left to impersonate), but when even ONE portfolio sibling remains unhardened the entire portfolio's brand-trust surface remains exploitable. The four-axis SINGLE-DOMAIN-BYPASS-VS-PORTFOLIO-WEAK-LINK comparison exposes the structurally-distinct attacker-economics axes: (i) BYPASS-PRIMITIVE axis — single-domain bypass requires per- technique attacker tradecraft (display-name construction, IDN homograph registration, ARC seal forgery, DKIM key compromise, vendor- relay exploitation), portfolio-weak-link bypass requires zero attacker tradecraft (just impersonate the un-hardened sibling), (ii) DEFENDER-EFFORT axis — single-domain hardening is bounded effort per domain, portfolio-weak- link hardening is N-times the effort across N portfolio siblings, (iii) ATTACKER-ECONOMICS axis — single-domain bypass has high attacker cost per attempt, portfolio-weak-link bypass has zero marginal cost (free pivot to weaker sibling), (iv) DEFENSIVE-COMPLETENESS axis — single-domain hardening protects only THAT domain's brand-trust surface, portfolio hardening protects the entire brand portfolio's cross-sibling-trust-cascade. Read the multi- domain-strategy spoke when scoping the threat model documented here — the 22 techniques on THIS page enumerate the PRIMARY-DOMAIN bypass surface AFTER policy=reject is in place; the multi-domain-strategy spoke documents the PORTFOLIO-COMPLETENESS pre-condition without which the attacker simply pivots to the un-hardened sibling and the THIS-page attacker-bypass surface becomes irrelevant because the attacker never needs to attempt it.
• DMARC aggregate (RUA) reports — the operational data stream that surfaces the indicators in §10.
• DMARC forensic (RUF) reports — the niche per-message failure samples useful for investigating §10 indicators.
• DMARC reporting pipeline (RUA/RUF end-to-end flow) — the ATTACKER-BYPASS-TECHNIQUE- DETECTION-AS-PIPELINE-CONSUMER companion to this 22-technique attacker-bypass threat catalogue. Where THIS page catalogues the application- layer attacker-bypass techniques the publisher defends against via DMARC enforcement and surfaces in §10 as the "attacker-bypass-attempt indicator" catalogue (§4.X DKIM-replay subclass, §5.X SPF-mechanism-misconfiguration subclass, §6.X include-cascade-stale- token subclass, §7.X forwarder-second- hop-break subclass, §8.X lookalike- domain subclass), the DMARC-reporting-pipeline spoke is the END-TO-END-AGGREGATE-REPORT-FLOW companion documenting FIVE detection- and-forensic-capture surfaces where the attacker-bypass threat catalogue materializes as concrete per-source- IP-and-disposition row signatures the operator's RUA analytics surface ingests from the pipeline: (i) §4.X DKIM-replay detection at the per-source-IP row — a DKIM-replay attack produces a HIGH- concentration of spf=fail + dkim=pass rows from a SINGLE attacker-controlled source IP (the attacker replays a stolen signed message via their own SMTP infrastructure, so SPF fails at the attacker IP but DKIM passes because the original signature is still cryptographically valid) — the canonical attack signature in the aggregate-report pipeline; (ii) §5.X SPF-mechanism- misconfiguration permerror surge — apex tag-misuse (extra space, invalid mechanism, byte-budget overrun, multi-record violation) drives a UNIFORM spf=permerror surge across ALL legitimate canonical source IPs at once in the rua window, distinguishable from genuine permerror by the temporal-clustering signature; (iii) §6.X include-cascade-stale-token attack surface — a stale third- party SaaS include token (e.g. a legacy SendGrid include that the operator decommissioned but did not unregister from the include cascade) creates a §6.X exit-loop surface where the original SaaS still owns the token's authorized IP space and could egress mail with the operator's domain authority — the per-third-party-source-IP RUA row is the detection point; (iv) §7.X forwarder-second-hop- break distinguishability via dkim=pass cross-reference — a §7.X legitimate forwarder produces spf=fail + dkim=pass at the forwarder IP (the original DKIM signature is preserved); an attacker spoofing the operator's domain produces spf=fail + dkim=fail at the attacker IP — the dkim= verdict distinguishes legitimate-forwarder from attacker-forge in the same RUA row class; (v) §10 operator analytics surface — the operator's RUA-ingestion analytics tool surfaces all FOUR above row signatures in the per-source-IP-and-disposition timeline, anchoring the per- incident triage workflow rooted in the RUA pipeline's time-series and in the per-incident RUF AFRF-format redacted-header capture that the operator uses to validate the attack hypothesis against the actual failed-message evidence. Read the reporting- pipeline spoke alongside this attacker-bypass threat catalogue when designing operator-facing analytics dashboards that must surface each of the 22 attacker- bypass-technique signatures from the RUA aggregate-report stream into the security-incident response workflow — the reporting-pipeline spoke is the canonical end-to-end aggregate- report-flow reference; THIS page is the canonical attacker-bypass- threat-catalogue companion documenting the 22 techniques whose RUA-row signatures the reporting pipeline surfaces.
• DMARC troubleshooting — failure-diagnosis sibling: SPF permerror, DKIM body-hash mismatch, alignment-vs- authentication, forwarding breakage.
• DMARC deployment checklist — the BYPASS-CLASS-AWARE-PHASED-ENFORCEMENT- RAMP-AS-PRIMARY-OPERATOR-DEFENSE-DISCIPLINE companion to this 22-technique attacker-bypass catalogue. Where THIS page documents the APPLICATION-LAYER attacker-bypass techniques the publisher defends against via DMARC enforcement (the §4.X DKIM-replay subclass, the §5.X signature-forgery subclass, the §6.X ARC-abuse subclass, the §7.X transport- downgrade subclass, the §8.X look-alike-domain / display-name / homoglyph spoofing subclass), the deployment-checklist spoke documents the OPERATOR-SIDE PHASED ENFORCEMENT RAMP that is the ONLY operator-side mechanism that converts a published DMARC record from "p=none monitor-only — every one of the 22 attacker-bypass techniques on this page is successful at the receiver-side delivery boundary because there is no quarantine / reject disposition to enforce" to "p=reject pct=100 — the §4.X / §5.X / §6.X / §8.X attacker-bypass techniques on this page that fail alignment / authentication are blocked at the receiver-side SMTP-time 5xx bounce; only the §7.X transport-downgrade / §9.X infrastructure / §10.X infrastructure- DNS attack subclasses remain exploitable, and those require the COMPANION MTA-STS / DANE / DNSSEC / CAA controls documented elsewhere in this Related Guides section". Four BYPASS- CLASS-VS-DEPLOYMENT-PHASE axes the deployment-checklist documents that converge on the attacker-bypass-defense story: (i) Phase 1 Discovery (p=none) as the ATTACKER-BYPASS-TECHNIQUE-DETECTION- VISIBILITY-ESTABLISHMENT-PHASE — the Phase 1 checklist gates (publish v=DMARC1; p=none; rua=mailto:dmarc- rua@example.com, ingest 30 days of aggregate reports, classify every source IP as aligned / misaligned / suspicious / attacker) directly produces the empirical evidence stream THIS attacker-bypass page's §10 "Indicators of an in-progress DMARC bypass attempt" section documents as the operator-facing detection-of-record; (ii) Phase 2 Triage (alignment-fixing) as the LEGITIMATE-MAIL-VS-ATTACKER-TRAFFIC- DISCRIMINATION-PREREQUISITE-PHASE — the Phase 2 checklist gates (fix every Phase 1-discovered misaligned legitimate sender by enrolling them in the publisher's SPF include cascade or delegating a DKIM selector with the third-party signing key) directly closes the attacker-vs-legitimate- sender false-positive surface that would otherwise convert a Phase 3 / Phase 4 enforcement decision into self-inflicted legitimate-mail-loss — the operator MUST complete Phase 2 before ramping Phase 3 or the §5.X attacker-bypass technique on THIS page would block legitimate mail alongside the attacker traffic; (iii) Phase 3 Quarantine (p=quarantine) as the SOFT-ENFORCEMENT-WITH-RECOVERABLE- SPAM-FOLDER-FOR-FALSE-POSITIVE-MITIGATION- PHASE — the Phase 3 checklist gates (start at p=quarantine pct=10, ramp to pct=25 / pct=50 / pct=100 on a per-week cadence, only advance when the alignment-rate KPI on legitimate traffic exceeds 99 percent) directly blocks the §4.X / §5.X / §8.X attacker-bypass techniques on THIS page at the receiver-side spam-folder routing disposition while preserving recoverable false-positive mitigation — the Phase 3 contract is the operator-side risk-mitigation layer that protects the publisher from the §11.X "legitimate-sender-misclassified- as-attacker" anti-defense pitfall this bypass taxonomy implicitly documents by contrast; (iv) Phase 4 Enforcement (p=reject) as the HARD- ENFORCEMENT-WITH-SMTP-TIME-5xx-BOUNCE- ACROSS-EVERY-ATTACKER-BYPASS-TECHNIQUE- ALIGNMENT-FAILURE-PHASE — the Phase 4 checklist gates (start at p=reject pct=10, keep DNS TTL at 300-3600 seconds for fast rollback, ramp to pct=100 only after Phase 3 quarantine-disposition count on legitimate sources is zero for two consecutive weeks) directly blocks the §4.X / §5.X / §6.X / §8.X attacker- bypass techniques on THIS page at the receiver-side SMTP-time 5xx bounce — the Phase 4 contract is the operator-side terminal-enforcement layer that closes every alignment-failure-class attacker- bypass technique documented on this page. Pair this attacker-bypass page (the WHICH attacker techniques to defend against) with the deployment-checklist page (the HOW to ramp DMARC enforcement safely from p=none to p=reject without self- inflicted legitimate-mail-loss) for the complete attacker-defense-AND-operator- execution-discipline posture every defender must implement to convert a published DMARC record from a monitor- only-observation tool into a working SMTP-time attacker-bypass-blocking enforcement contract.
• DKIM key rotation — the DKIM-PRIVATE-KEY-COMPROMISE-AS- ATTACKER-BYPASS-CLASS-WITH-ROTATION-AS- PRIMARY-DEFENSE companion to this 22- technique attacker-bypass taxonomy. Where THIS page catalogues the application-layer attacker-bypass techniques the publisher defends against via DMARC enforcement (the §4.X DKIM-replay subclass, the §5.X signature-forgery subclass, the §6.X ARC-abuse subclass, the §7.X transport- downgrade subclass, the §8.X look-alike- domain / display-name / homoglyph spoofing subclass), the dkim-key-rotation spoke documents the PUBLISHER-SIDE KEY- LIFECYCLE DISCIPLINE whose cadence determines the publisher's WINDOW-OF- EXPOSURE to TWO STRUCTURALLY-DISTINCT attacker-bypass classes that originate from the DKIM-private-key-side of the publisher's signing infrastructure: (i) stolen-DKIM-private-key-as-forge- vector — when an attacker exfiltrates the publisher's DKIM private key (cloud-IAM-misconfiguration in the ESP / marketing-platform's key-vault, an on-prem-Exchange-Online-Connector outbound-signing-keystore breach, a third-party-DKIM-signing-service provider's infrastructure compromise), the attacker retains the ability to generate SIGNATURE-VALID forged messages from the publisher's organisational-domain identifier UNTIL the publisher rotates the DKIM key and retires the compromised selector's TXT record; (ii) DKIM-replay-attack per RFC 6376 §8.6 — when an attacker harvests a single legitimately-signed message carrying a long-lived DKIM signature (because the publisher's x= timestamp expiry is far in the future and no message-id- deduplication is enforced at receivers), the attacker can REPLAY that message at scale to attack-recipient mailboxes with the receiver-side DKIM verification signalling dkim=pass. The dkim-key-rotation spoke documents the SAFE-ROTATION canonical procedure (publish-new-key → wait-N-TTL-cycles → sign-with-new-key → wait-M-TTL-cycles → retire-old-key) whose 6-month or 12-month rotation cadence is the PRIMARY DEFENSE against both DKIM-private-key- compromise-class attacks AND the derivative DKIM-replay-attack class: rotating retires the compromised key and exponentially shrinks the future forgery-impact-window, and rotating retires the long-lived signature whose public-key the replay relies on for verification. Pair this page (the 22-technique attacker-bypass taxonomy) with the dkim-key-rotation spoke (the key-lifecycle discipline reference) when scoping the publisher-side cryptographic- material lifecycle whose 6-month or 12-month cadence is the canonical defense against the DKIM-private-key-compromise- class and DKIM-replay-class attacker- bypass techniques.
• DMARC monitoring & reporting analysis — operational discipline that converts the §10 indicators into alerting rules.
• ARC (Authenticated Received Chain) explained — the standard whose abuse §6.4 documents; trusted-sealer mechanics and chain validation.
• SPF explained — RFC 7208; the envelope-MAIL-FROM authentication every §5.5 and §6.5 attack exploits weakness in.
• SPF forwarding issues (the second-hop break) — the FORWARDING-FAILURE-AS-LEGITIMATE-MAIL- COLLATERAL-DAMAGE-CHANNEL-DISTINCT-FROM- ATTACKER-BYPASS companion documenting the forwarder-hop SPF-fail scenario (mailing-list expansion, support-ticket relay, corporate- to-personal vacation forwarder, recipient- mailbox-rule auto-forwarding) that produces SPF-aligned-fail rows in the publisher's RUA aggregate-report stream that look structurally similar to the §5.5 and §6.5 attacker-bypass techniques catalogued on this page but require the OPPOSITE operator response (architect DKIM-aligned-pass + ARC-trust-anchoring to PRESERVE the legitimate mail, not BLOCK it). Where THIS page enumerates 22 attacker techniques against the DMARC message-identity layer specifically (display-name spoofing, lookalike-domain registration, ARC trust-chain abuse, DKIM replay, third-party-vendor compromise, l= tag abuse, etc.), the SPF- forwarding-issues spoke is the LEGITIMATE-MAIL-COLLATERAL-DAMAGE- DISAMBIGUATION companion documenting the structurally-distinct legitimate-mail-loss category that the operator MUST learn to distinguish from attacker-bypass during aggregate-report triage. The four-axis BYPASS-CATALOGUE-VS-FORWARDING-FAILURE comparison exposes the structurally-distinct SPF-FAIL-CAUSATION roles: (i) attacker- bypass SPF-fail rows in RUA originate from non-authorised source IPs running attacker- controlled MTAs — the legitimate publisher's envelope-MAIL-FROM identity is being abused by an attacker who cannot authenticate against the publisher's SPF policy — the operator response is HARDEN the policy (-all, p=reject); (ii) forwarder-hop SPF-fail rows in RUA originate from legitimate intermediary forwarder IPs (mailing-list servers, Outlook Web Access vacation-rule egress, Gmail's forwarder pool, corporate-relay forwarders) that are NOT in the publisher's SPF policy but ARE legitimately re-mailing the publisher's mail — the operator response is PRESERVE the legitimate-mail path via DKIM-aligned-pass survival + ARC- trust-anchoring + selective forwarder allowlisting, not HARDEN; (iii) aggregate-report triage discipline must distinguish the two SPF-fail causation classes by source-IP attribution, mailing- list-header inspection (List-Id:, List-Unsubscribe:), and intermediary-MTA-reputation lookup — the forwarding-issues spoke catalogues the per-forwarder-class identification heuristics operators apply during incident-response triage; (iv) p=reject rollout decision must independently account for BOTH attacker-bypass residual AND forwarder-hop legitimate-mail loss rates — the bypass catalogue on this page documents the attacker-residual surface the rollout decision MUST close, while the forwarding-issues spoke documents the legitimate-mail-collateral-damage surface the rollout decision MUST NOT exceed; the two rates are INDEPENDENT operator-relevant gating criteria with structurally-distinct observability mechanisms. Read the SPF- forwarding-issues spoke alongside this bypass catalogue when scoping the FULL aggregate- report triage discipline: this page documents the 22 attacker-bypass techniques producing ATTACK-CAUSED SPF-fail rows, forwarding-issues documents the parallel LEGITIMATE-MAIL-LOSS SPF-fail-row category, and the two together name the complete RUA SPF-fail-row taxonomy operators must navigate.
• SPF for Google Workspace — the WORKSPACE-SPF-ATTACK-SURFACE-AUTHORING-INPUT companion to this DMARC attacker-bypass threat-vector taxonomy. Where THIS page is the OFFENSIVE catalogue of the 20+ canonical attacker techniques for defeating weak DMARC postures, the SPF-for-Workspace spoke is the DEFENSIVE Workspace-tenant-SPECIFIC SPF-AUTHORING reference for the operator population that controls THE INPUT to the §5 SPF-mechanism-misconfiguration attacks the bypass-taxonomy catalogues. Workspace-tenant operators directly author the SPF record characteristics the §5 attack catalogue exploits: (i) a Workspace operator publishing +all on the Workspace baseline SPF record creates the §5.1 universal-pass attack surface across the entire Workspace-tenant outbound envelope; (ii) a Workspace operator publishing an over-broad ip4:0.0.0.0/0 wildcard creates the §5.6 wildcard-pass attack surface; (iii) a Workspace operator bolting on third-party include: chains that cumulative-cost over the 10-lookup ceiling creates the permerror-on-overlimit failure that attackers can exploit because some receivers treat permerror as none for alignment purposes; (iv) a Workspace operator failing to enumerate on-prem outbound hostnames in the SPF record creates §5.5 hybrid-misalignment surface where on-prem-routed legitimate mail produces SPF=fail, and operators chasing the false-positive surface frequently loosen the SPF record (downgrade -all → ~all) to suppress the noise, permanently weakening the SPF anti-spoofing guarantee; (v) a Workspace operator failing to promptly remove decommissioned secondary-SaaS-sender include: tokens leaves §6.4 stale-include attack surface available to attackers who later compromise the decommissioned third-party SaaS sender's SPF record. Read the SPF-for-Workspace spoke when triaging the Workspace-tenant SPF-record HARDENING decisions that close the §5 and §6 attack surfaces this bypass-taxonomy catalogues — the spoke is the per-platform AUTHORING-DEFENSE reference for the Workspace operator population whose authoring choices directly determine which attacker bypasses are or are not exploitable against the Workspace tenant.
• SPF for Microsoft 365 — the M365-TENANT-SPF-ATTACK-SURFACE- AUTHORING-INPUT companion to this DMARC attacker-bypass threat-vector taxonomy. Where THIS page is the OFFENSIVE catalogue of the 22 canonical attacker techniques for defeating weak DMARC postures, the SPF-for-Microsoft-365 spoke is the DEFENSIVE M365-tenant- SPECIFIC SPF-AUTHORING reference for the operator population that controls THE INPUT to the §5 SPF-mechanism- misconfiguration and §6 SPF-include- cascade-stale-token attacks the bypass- taxonomy catalogues. M365-tenant operators directly author the SPF record characteristics the §5 + §6 attack catalogue exploits at FOUR M365-tenant-specific surfaces: (i) a M365 operator weakening the canonical v=spf1 include:spf.protection.outlook.com -all baseline by downgrading -all → ~all → ?all → +all opens the §5.1 universal-pass attack surface across the entire EOP-outbound envelope, exposing every M365-tenant outbound mail-stream to receiver-side SPF-permit-by-default at attacker- controlled originating IPs; (ii) a M365 operator adding third-party SaaS-sender include: tokens past the ~3-5-lookup EOP-baseline cumulative cost crosses the 10-lookup §4.6.4 ceiling and produces permerror at the receiver — exploitable by §5.7 permerror-as-none treatment at receivers who downgrade permerror to none for alignment purposes, defeating the M365-tenant's §3 alignment-driven DMARC enforcement; (iii) a M365 operator running a hybrid Exchange topology (on-prem Edge Transport + Exchange Online) failing to enumerate on-prem outbound IPs in the SPF record creates §5.5 hybrid-egress- misalignment surface where on-prem- routed legitimate mail produces SPF=fail rows in RUA aggregate evidence, and operators chasing the false-positive noise frequently loosen the SPF record (downgrade -all → ~all or add an over-broad ip4:0.0.0.0/0 wildcard) permanently weakening the M365-tenant anti-spoofing guarantee, and (iv) a M365 operator failing to promptly remove decommissioned secondary-SaaS- sender include: tokens leaves §6.4 stale-include attack surface available to attackers who later compromise the decommissioned third-party SaaS sender's SPF record — a particular risk at M365 tenants because the higher ~5-7 lookups of headroom (substantially more than Workspace's ~6 lookups) tempts operators into more aggressive secondary-sender enrollment that accumulates more stale-include surface over the tenant's lifetime. Read the SPF-for-Microsoft-365 spoke when triaging the M365-tenant SPF-record HARDENING decisions that close the §5 and §6 attack surfaces this bypass- taxonomy catalogues — the spoke is the per-platform AUTHORING-DEFENSE reference for the M365 operator population whose authoring choices directly determine which attacker bypasses are or are not exploitable against the M365 tenant.
• SPF mechanisms explained — the per-mechanism reference for the specific mechanism-misconfiguration patterns §5 and §6 attacks exploit — the SPF-MECHANISM-VULNERABILITY-MAP companion to this DMARC attacker-bypass threat-vector taxonomy. Where THIS page is the OFFENSIVE catalogue of the 20+ canonical attacker techniques for defeating weak DMARC postures, the SPF-mechanisms spoke is the per-mechanism reference identifying EXACTLY which mechanism-misconfiguration each §5 and §6 attack exploits: (i) the +all qualifier override attack (§5.1) — exploits a deployment mistake on the all mechanism (§5.1); (ii) the broad ip4:0.0.0.0/0 wildcard attack — exploits a deployment mistake on the ip4 mechanism (§5.6); (iii) the ptr-mechanism abuse attack — exploits the deprecated ptr mechanism's (§5.5) reliance on attacker-controlled reverse DNS; (iv) the macro-include injection attack (§5.5) — exploits the include: mechanism's (§5.2) recursive lookup that fetches the target's-controlled SPF record; (v) the forwarder-IP-break attack — exploits the SPF MAIL FROM check's per-mechanism IP-match algorithm not surviving any envelope-IP rewrite. Read the mechanisms spoke alongside this attacker-bypass page when authoring a defender-side SPF record and you need the per-mechanism reference to identify which mechanism choices in your current record map to the canonical attacker exploits documented on this page, then re-author the record to close those mechanism- level vulnerabilities before they appear in your DMARC aggregate-report threat-source ranking.
• include vs ip4 vs a vs mx — the THREAT-CATALOGUE-SPF-MECHANISM- CHOICE-AS-AUTHENTICATION-EVASION-DETECTION- LEG companion to this attacker-bypass taxonomy. Where THIS page catalogues 22 attacker techniques across the four canonical bypass classes (alignment- evasion, authentication-evasion, policy- evasion, infrastructure-evasion), the include-vs-ip4-vs-a-vs-mx spoke documents the DEFENDER-SIDE FOUR-IP-PROVIDING- MECHANISM CHOICE — include: recursive sub-record consultation vs ip4: literal IP-CIDR publication vs a: A/AAAA-RR consultation vs mx: MX-RR- then-A/AAAA chain consultation — that ITSELF constitutes an authentication- evasion DETECTION leg: each mechanism choice creates a structurally-distinct attacker-bypass surface that the per- receiver DMARC RUA-aggregate-report's spf_domain + spf_result + source_ip column triangle materialises differently. include: attacks (sub-record co-tenancy enrolment, attacker-controlled sub-tree provisioning, ESP sub-record poisoning) surface as Pass-from-unexpected-source-IP rows attributable via the per-receiver per-day source-IP attribution column; ip4: attacks (stale CIDR retention after IP-block decommission, ASN-hijack-induced IP-reuse, CIDR-too-broad over-publication) surface as Pass-from- previously-unseen-IP rows; a: attacks (A-RR-substitution via DNS- registrar compromise, A-RR-fronting-by- CDN-tenant-co-occupancy) surface as Pass- from-CDN-shared-IP rows; mx: attacks (MX-RR-substitution, MX-RR-priority- downgrade-to-attacker-controlled-MX) surface as Pass-from-MX-co-tenant-IP rows. Without the include-vs-ip4-vs-a-vs-mx spoke a defender reading THIS attacker-bypass taxonomy knows WHICH 22 attacks exist, but not WHICH of the four SPF mechanism choices in their own SPF record creates the attacker-exploitable surface for each class — this link closes that per-mechanism- to-attack-surface mapping gap at the defender-side mechanism-choice authoring- decision layer.
• SPF DNS record syntax (byte-level TXT-record reference) — the THREAT-CATALOGUE-SPF-TXT-RECORD- BYTE-LEVEL-PUBLICATION-FAULT companion to this attacker-bypass taxonomy. Where THIS page catalogues 22 attacker techniques against the DMARC layer specifically (display-name spoofing, lookalike-domain registration, ARC trust-chain abuse, DKIM replay, third- party-vendor compromise, l= tag abuse, etc.) plus the §5 SPF-mechanism-grammar deployment-mistake subset (+all, broad ip4:0.0.0.0/0, ptr abuse, macro-include injection, forwarder-IP-break), the SPF-dns-syntax spoke is the STRUCTURALLY-DISTINCT SPF-RECORD- PUBLICATION-BYTE-LEVEL-FAULT catalogue documenting the SPF-record- publication-LAYER attacker-exploitable surface that exists ORTHOGONALLY to the §5 mechanism-grammar deployment mistakes: (i) DUPLICATE-V=SPF1-RECORD-PERMERROR-AS- ATTACKER-INPUT (an operator who publishes TWO v=spf1 records — typically via a registrar UI that silently appended the new record without deleting the previous one, or via a DNS-template- consolidation rollout that copied the previous record forward without removing the legacy one — produces spf=permerror at every receiver; the attacker exploits the permerror-treated-as-no-policy receiver-side behaviour by spoofing the From: domain confident that the SPF-aligned-fail path is permerror-bypass-permitted on weak- DMARC receivers), (ii) MULTI-STRING-CONCATENATION-BREAKAGE- AS-ATTACKER-INPUT (a registrar UI that incorrectly publishes "v=spf1 " "include:…" as a literal concatenated record with embedded quote characters breaks SPF parsing entirely; the attacker exploits the resulting permerror identically to (i)), (iii) MECHANISM-ORDERING-PRECEDENCE-AS- ATTACKER-INPUT (the SPF first-match-wins evaluator semantics means an operator who places +all as a debugging leftover after the explicit-pass mechanisms produces a permissive SPF evaluation where the attacker's spoofed-source IP matches the fallthrough +all before the explicit-fail mechanisms catch it), (iv) REDIRECT-VS-INCLUDE-SEMANTIC- CONFUSION-AS-ATTACKER-INPUT (an operator who uses redirect= when intending include: delegates SPF evaluation entirely to the redirect target, which means a compromise of the redirect target becomes a complete SPF bypass for the operator's domain), (v) BYTE-BUDGET-OVERRUN-AS-ATTACKER-INPUT (an SPF record exceeding the EDNS0 4096-byte ceiling forces UDP-fallback- to-TCP retry behaviour on receiver SPF evaluators that may not gracefully handle TCP-fallback, producing a temperror that attacker-controlled flood-traffic can amplify into receiver-side SPF-evaluation-disabling). Read the SPF-dns-syntax spoke alongside this attacker-bypass page when authoring a defender-side SPF record and verifying the operator's SPF-record- publication layer is itself free of byte-level publication faults that the §5 mechanism-grammar deployment-mistake audit does NOT catch — the SPF-record-publication layer is structurally orthogonal to the SPF-mechanism-grammar layer and requires its own dedicated audit pass.
• Why SPF alone is insufficient — the defender-side companion that catalogues exactly the six structural SPF-only blindspots this page's §5 and §6 attack variants exploit. Where this attacker-bypass page is the OFFENSIVE threat-vector taxonomy ("here are the 20+ canonical patterns attackers use to defeat weak DMARC postures"), the SPF-insufficiency spoke is the DEFENSIVE inverse — the structural-limitation map of what an SPF-only posture leaves uncovered. Concrete attacker→defender mapping: (i) §5.5 forwarder-mediated SPF break attacks (the attacker delivers from a forwarder whose IP the target's SPF doesn't authorise) exploit SPF-limitation #3 (the forwarder break per RFC 7208 §11.4) — closed only by DKIM alignment + DMARC enforcement, (ii) §6.5 header-From-spoof-with-aligned-MAIL-FROM attacks exploit SPF-limitation #2 (no header-From coverage — SPF authenticates only the envelope-MAIL-FROM, leaving the visible From: domain unauthenticated) — closed only by DMARC's identifier-alignment requirement, (iii) §6.2 selector-stripping / body-modification attacks exploit SPF-limitation #4 (no message-integrity coverage) — closed only by DKIM's body-hash signature, (iv) §5.7 SPF-overrun attacks (the attacker causes the SPF chain to exceed the 10-lookup cap, returning permerror which many receivers accept as "did not fail") exploit SPF-limitation #6 (the RFC 7208 §4.6.4 10-DNS-lookup ceiling) — closed only by SPF flattening AND the DMARC contract that rejects regardless of SPF result. Read the SPF-insufficiency spoke when an operator asks "why does this attacker-bypass scenario succeed against my SPF-only domain in the first place" — every §5 and §6 attack variant maps to one of the six structural SPF gaps the spoke documents, and the spoke's closing-the-gap remedy is the same DMARC enforcement contract this page demonstrates attackers probing.
• DKIM explained — RFC 6376; the cryptographic signing that §6.1 through §6.3 attack.
• DKIM alignment with DMARC — the alignment-bypass defense reference for §5 alignment-exploit attack patterns — the AUTHORITATIVE DEFENSE REFERENCE for the alignment-bypass attack patterns this page catalogues in §5 (alignment-exploit variants) and §6 (DKIM-side bypass paths). Where this attacker-bypass page is the OFFENSIVE threat-vector taxonomy ("here are the 20+ canonical patterns attackers use to defeat weak DMARC postures"), the DKIM-alignment-with-DMARC spoke is the DEFENSIVE inverse — the authoritative reference for the DKIM-half of the identifier-alignment evaluation every attacker probe in §5 attempts to route around. Concrete attacker→defender mapping for the alignment-bypass family: (i) §5 relaxed-alignment-PSL- boundary-shifting attacks (where the attacker exploits a Public Suffix List misclassification — a registrar-managed DNS zone that should be treated as a PSL boundary but isn't, allowing attacker.tenant-A.shared-host.com to align with tenant-B.shared-host.com under adkim=r relaxed evaluation) exploit the relaxed- organizational-domain alignment rule the DKIM-alignment spoke documents as RFC 7489 §3.1.1 — closed by the spoke's adkim=s strict FQDN-equality recommendation for publishers whose organizational boundary is ambiguous, (ii) §5 ESP- shared-domain-signing alignment- misroute attacks (where the attacker compromises an ESP account on the same shared sending domain and sends DKIM-aligned-to-ESP-shared-domain mail impersonating the customer's apex From: which fails alignment but succeeds at SPF-aligned acceptance downstream) exploit the SendGrid / Mailchimp / Postmark / Mandrill / Amazon SES shared-signing pattern the DKIM-alignment spoke documents as one of the three canonical DKIM-pass-but-DMARC-fail provenance patterns — closed by the spoke's per-ESP CNAME-delegated authenticated- domain-DKIM provisioning procedure, (iii) §5 M365 onmicrosoft.com gotcha-exploit attacks (where the attacker uses the well-known default- signing alignment gap to defeat a BIMI-eligible operator's nominal- enforce posture) exploit the Microsoft 365 default-signing- misalignment pattern the DKIM- alignment spoke documents — closed by the spoke's Defender DKIM blade customer-domain-DKIM provisioning procedure. Read the DKIM-alignment spoke when investigating a §5 attacker-bypass scenario: every alignment-exploit attack maps to a SPECIFIC defender configuration the spoke documents as the closing-the-gap remedy.
• DKIM failures explained — the canonical DKIM verification-failure taxonomy. Attacker-bypass scenarios in this page (§6) routinely exploit operationally- accepted DKIM failure modes that operators treat as benign forwarder noise — until an attacker uses the same failure surface as a bypass vector. Two attack-vs-noise confusion classes the failures-explained spoke clarifies: (1) recurring bodyhash-mismatch on a legitimate forwarder (mailing list, Sieve/.forward) trains operators to ignore DKIM-fail signals on RUA rows from that forwarder IP — but the same RUA row pattern from a NEW sending IP block is the exact signature of an attacker spoofing the signed domain at p=none with malformed DKIM-Signature headers; (2) selector-key- mismatch signature failures spike legitimately during operator key- rotation overlap windows — attackers deliberately time spoofing campaigns to rotation windows because the elevated DKIM-fail baseline masks attack traffic in the RUA stream. Read failures-explained when calibrating the recurring-noise vs attack-traffic discrimination heuristics documented in §10 of this page — the spoke is the authoritative per-failure- class diagnostic reference for separating the two patterns in DMARC monitoring.
• DKIM DNS TXT-record byte syntax (RFC 6376 §3.6.1 tag-list grammar) — the ATTACKER-BYPASS-CATALOGUE-AS-PER-DKIM- TXT-RECORD-PUBLICATION-DEFECT-EXPLOITATION- SURFACE companion to this DMARC attacker- bypass 22-technique catalogue. Where THIS page documents the 22-technique attacker- bypass catalogue grouped by per-bypass-class exploit pattern (alignment-bypass / identifier-substitution / signature-replay / forwarder-induced-fail / header-injection), the DKIM-DNS-syntax spoke documents the PUBLISHER-SIDE TXT-RECORD BYTE-LEVEL AUTHORING REFERENCE that every per-bypass- technique mitigation in this catalogue structurally depends on. The PER-DKIM-TXT- RECORD-TAG-VS-BYPASS-TECHNIQUE cross-reference establishes FOUR structurally-distinct per- publisher-side-DKIM-TXT-record-tag-to- attacker-bypass-class coupling dimensions: (i) t=y testing-flag publication past the burn-in window as LOAD-BEARING UPSTREAM ENABLER of the DECEPTIVELY-SILENT DMARC-via-DKIM-DISABLE bypass class — the §3.6.1 t=y testing-flag semantics cause every receiver to disregard the DKIM verdict for DMARC-alignment evaluation purposes; an attacker who discovers a published selector with stale t=y can produce forged messages with a deliberately-broken DKIM-Signature header whose receiver-side verdict is dkim=fail (testing flag set), but the per-message DMARC-alignment evaluation SILENTLY treats the verdict as dkim=none rather than dkim=fail — producing a DECEPTIVELY-SILENT DMARC-pass outcome at every receiver evaluating the publisher's From-domain; the DKIM-DNS-syntax spoke documents the t=y tag-semantics as the canonical publisher-side defect whose pre-emptive cleanup forecloses this bypass class; (ii) 1024-bit RSA p= public-key publication on legacy selectors as LOAD-BEARING UPSTREAM ENABLER of the OFFLINE-PRIVATE-KEY-FACTORING bypass class — selectors publishing pre-2018 1024-bit RSA p= public-key material expose the operator to the offline-factoring class of attacker bypass (where an attacker with access to sufficient computational resources can derive the publisher's private key from the published 1024-bit public key, then emit attacker-controlled messages with valid dkim=pass signatures under the publisher's d-tag identity); the DKIM-DNS-syntax spoke documents the RFC 8301 §3 RSA-2048 floor as the publisher-side publication discipline whose enforcement forecloses this bypass class; (iii) multi-string TXT chunking discipline per RFC 1035 §3.3.14 as LOAD-BEARING PUBLISHER-SIDE PUBLICATION DISCIPLINE against the SELECTOR-PERMERROR-AS-DMARC-NONE- FAILOPEN bypass class — selectors publishing 2048-bit RSA p= public-key material exceeding the 255-octet per-TXT-character-string boundary that are published WITHOUT correct multi-string chunking produce dkim=permerror (key syntax) at every receiver per §6.1.2; an attacker who discovers a published selector emitting dkim=permerror can produce unsigned messages from the publisher's From-domain knowing the receiver-side DKIM verdict will be dkim=permerror — which per RFC 7489 §3.2 SHOULD be treated as a DKIM evaluation failure but at some receivers is treated as dkim=none, producing a fail-open DMARC outcome; the DKIM-DNS-syntax spoke documents the multi- string chunking discipline as the canonical publisher-side publication discipline whose correct execution forecloses this bypass class; (iv) selector-revocation via record-deletion as LOAD-BEARING UPSTREAM ENABLER of the IN-FLIGHT-MESSAGE-COLLAPSE-TO- permerror bypass class — a publisher responding to private-key compromise by DELETING the selector TXT record (rather than publishing the canonical empty- p= revocation per RFC 6376 §3.6.1) causes every in-flight message signed under the revoked selector to collapse to dkim=permerror (selector NXDOMAIN) at every receiver — which produces the fail-open DMARC outcome described in (iii); the DKIM-DNS-syntax spoke documents the canonical empty- p= revocation pattern as the load-bearing incident-response operational- discipline whose correct execution distinguishes a controlled revocation outcome from this bypass-class-enabling self-inflicted defect. Read THIS attacker-bypass 22-technique catalogue WITH the DKIM-DNS-syntax spoke when the per-bypass-class mitigation identification step arrives: the bypass catalogue documents the PER-TECHNIQUE EXPLOITATION pattern, the DKIM-DNS-syntax spoke documents the PER-TAG PUBLISHER-SIDE TXT-RECORD AUTHORING discipline whose byte-correct execution forecloses every publisher-side-publication-defect-exploitation attacker bypass this catalogue enumerates.
• DKIM-Signature header anatomy — the ATTACKER-BYPASS-CATALOGUE-AS-PER- DKIM-SIGNATURE-TAG-EXPLOITATION-SURFACE companion to this DMARC attacker-bypass 22-technique catalogue. Where THIS page documents the 22-technique attacker-bypass catalogue grouped by per-bypass-class exploit pattern (alignment-bypass / identifier-substitution / signature-replay / forwarder-induced-fail / header-injection / canonicalization-evasion / l=-tag-truncation / selector-NXDOMAIN-as-no-signature / relaxed-mode-cross-subdomain-substitution), the DKIM-signatures-explained spoke is the per-tag BYTE-LEVEL HEADER ANATOMY canonical reference documenting the FOUR DKIM-Signature header tag-vs-bypass-technique coupling dimensions every attacker-bypass technique in this catalogue exploits at the per-message DKIM-Signature byte-syntax granularity: (i) h= signed-header-list tag as header-injection bypass vector — the h=From:To:Subject:Date:Message- Id publication choice determines which per-message headers participate in the signature math; per-message header-injection attacks (RFC 6376 §3.5 h=-tag omission exploitation) inject additional author-controlled headers (X-Original-From, From-Display-Name spoof) below the signed- header floor that PASS DKIM verification because they sit outside the h= coverage scope — the §6 attacker-bypass technique catalogue documents this exact pattern; (ii) bh= body-hash tag + l= body-length- limit tag as body-modification bypass vector — the per-publisher l=-tag publication choice (when present) limits the per-message body-hash coverage to N bytes; attackers append arbitrary phishing payload below the l=-tag-bounded coverage that PASSES DKIM verification because the appended payload sits outside the body- hash coverage scope — the §7 attacker-bypass technique catalogue documents this as the canonical l=-tag truncation exploit; (iii) b= signature- value tag as replay-attack vector — the per-message b=-tag RSA-PKCS#1-v1_5 (or Ed25519) signature value is reusable across per-message replay attacks where the attacker re-emits an already-signed message verbatim from a different envelope-source-IP — the §8 attacker-bypass technique catalogue documents this as the RFC 6376 §8.6 canonical DKIM replay-attack exploit class against which the operationally- mature publisher mitigates via per- message x=-tag expiration + per-recipient receiver-side dedup; (iv) d= signing-domain tag as alignment-bypass vector — the per-message d=-tag publication choice (sub-domain vs organisational-domain) determines which per-message DKIM-Signature header produces the DKIM-aligned-pass verdict under DMARC's relaxed-mode evaluation; the §5 attacker-bypass technique catalogue documents the relaxed-mode- cross-subdomain-substitution exploit whose root-cause is a misconfigured d=-tag-substitution between a compromised subdomain and the protected From-author-domain. Read DKIM-signatures-explained as the per- tag byte-anatomy reference when this page's 22-technique catalogue traces a specific bypass technique through a per-tag DKIM-Signature header manipulation pattern.
• DKIM troubleshooting (symptom-driven debugging) — the ATTACKER-BYPASS-CATALOGUE-AS- PER-VERDICT-DKIM-TROUBLESHOOTING- DIFFERENTIAL-DIAGNOSIS companion to this DMARC attacker-bypass 22- technique catalogue. Where THIS page documents the 22-technique attacker-bypass catalogue grouped into 4 classes (alignment-evasion, authentication-evasion, policy- evasion, infrastructure-evasion), the DKIM-troubleshooting spoke documents the SYMPTOM-DRIVEN DEBUGGING PLAYBOOK whose per- verdict-classification flow becomes a PER-ATTACK-CLASS DIFFERENTIAL DIAGNOSIS framework when the operator decodes each dkim=X verdict simultaneously as an authentication- outcome AND as a per-attack-class bypass-attempt classifier. FOUR structurally-distinct DKIM-VERDICT- VS-BYPASS-TECHNIQUE DIAGNOSTIC dimensions emerge from cross-mapping the troubleshooting playbook against the bypass-catalogue: (1) dkim=none verdict as authentication-evasion-class- unsigned-bypass differential diagnosis at the per-message DKIM- Signature-header-absent vs publisher-DKIM-record-published joint-evidence-row boundary — the troubleshooting-spoke documents the per-message dkim=none triage flow where the operator differentiates between LEGITIMATE-PUBLISHER-SENT- BUT-DKIM-INFRASTRUCTURE-BROKEN (publisher's DKIM signer is misconfigured, dropped the message, or the message routed through a non-DKIM-signing path) vs AUTHENTICATION-EVASION-ATTACKER- BYPASS where the attacker simply omits the DKIM-Signature header entirely and exploits a p=none or p=quarantine pct=<100 publisher policy. The troubleshooting playbook's differential-diagnosis question is whether the unsigned-message bypass is a SYMPTOM of publisher- side DKIM-infrastructure breakage OR a SYMPTOM of attacker- controlled message-emission. THIS page's authentication-evasion- class technique #4 is the security- research catalogue entry the troubleshooting playbook must encode at the dkim=none decision point. (2) dkim=fail bodyhash- mismatch verdict as DKIM-replay- and-tamper-class attacker-bypass differential diagnosis at the per-message body-hash-mismatch vs forwarder-modification joint-evidence-row boundary — the troubleshooting-spoke documents the per-message dkim=fail bodyhash-mismatch triage flow where the operator differentiates between LEGITIMATE- FORWARDER-MODIFICATION (mailing- list footer injection, anti- phishing-warning-banner header injection, ESP-driven URL rewriting for click-tracking) vs DKIM-REPLAY-WITH-MODIFIED- BODY attacker-bypass where the attacker has captured a legitimately-signed message and modified the body bytes (cookie-substitution, URL- substitution, body-hash-attack- via-l=-tag-truncation per RFC 6376 §3.5). The differential diagnostic test is the per- source_ip cohort attribution (forwarder IPs vs unknown-attacker IPs). THIS page's authentication- evasion-class technique #9 (DKIM replay) is the security-research catalogue entry the troubleshooting playbook must encode at the dkim=fail bodyhash-mismatch decision point. (3) dkim=permerror verdict as infrastructure- evasion-class DNS-record- misconfiguration-exploitation attacker-bypass differential diagnosis at the per-message DKIM-record-DNS-lookup-failure vs publisher-DKIM-record-state joint-evidence-row boundary — the troubleshooting-spoke documents the per-message dkim=permerror triage flow where the operator differentiates between OPERATIONAL-MISCONFIGURATION (publisher's DKIM TXT record has syntax errors, exceeds the 255-byte continuation boundary, lacks v=DKIM1 tag, has a malformed p= field) vs INFRASTRUCTURE-EVASION- ATTACKER-EXPLOITATION where the attacker observed the publisher's UNTIL-FIXED window with a broken DKIM record and sent attack messages precisely during the window knowing the receiver would emit dkim=permerror and the publisher's RUA stream would record the verdict without distinguishing legitimate-publisher misconfig from attacker exploitation. THIS page's infrastructure- evasion-class technique #18 (DNS-record exploitation) is the security-research catalogue entry the troubleshooting playbook must encode at the dkim=permerror decision point. (4) Multi-tenant ESP shared-pool cohabitant attacker-bypass differential diagnosis at the per-source_ip ESP-pool-IP-vs- per-tenant-DKIM-d= joint- evidence-row boundary — the troubleshooting-spoke documents the per-ESP cohabitant- IP triage flow where the operator differentiates between LEGITIMATE-TENANT-DKIM-SIGNING from the publisher's own ESP relationship vs ATTACKER- TENANT-DKIM-SIGNING from a cohabitant ESP customer whose attacker-controlled DKIM domain is aligned-relaxed to the publisher's organisational domain via subdomain-extension. The differential diagnostic test is the per-message DKIM-d= attribute vs the publisher's authorised-d=- inventory cross-reference at the ESP-cohabitant boundary. THIS page's alignment-evasion- class technique #1 (subdomain- alignment-relaxed exploitation) is the security-research catalogue entry the troubleshooting playbook must encode at the per-ESP-source_ip decision point. Read the troubleshooting-spoke alongside THIS page when the operator's DKIM-debugging playbook is being extended to handle attacker-bypass differential diagnosis: this page tells you WHAT THE 22 TECHNIQUES ARE at the threat-catalogue level, the troubleshooting- spoke tells you WHICH VERDICT-SIGNATURE each technique-class produces in the receiver-side per-message evidence stream AND WHY the per-symptom playbook must encode each technique-class as a structurally-distinct differential-diagnosis branch.
• DKIM replay attacks explained — the dedicated deep dive on the DKIM-replay attack class summarised in §6.3 of this page. The replay-attack page covers the capture-and-rebroadcast technique in detail: an attacker captures a legitimately-signed message from a high-reputation sender (often a transactional notification or a marketing-list message) and replays it to millions of new recipients with the original DKIM signature still validating, because the signature binds only the signed headers and body — not the recipient list, the envelope sender, or the sending IP. The page documents the four mitigations attackers route around (short rotation cadence, RFC 9103 x= expiration tag, recipient-binding via DKIM i= AUID, and receiver-side rate-limiting on replayed-signature detection) plus the operational indicators an analyst sees in DMARC aggregate reports when a replay campaign is in flight (sudden spike in DKIM-pass-from-attacker-IPs against a single signed domain, often from unusual ASNs). Pair with §10 of this page for the operational detection patterns.
• BIMI explained — the brand-display standard §7.4 abuses; DMARC enforcement prerequisite, SVG Tiny PS, VMC certificates.
• BIMI Verified Mark Certificates (VMC and CMC) — the BRAND-IMPERSONATION-DEFENSE-VIA- MVA-TRADEMARK-VERIFICATION-GATE companion reference to this bypass catalogue's §7.4 BIMI-impersonation discussion. Where THIS page catalogues the BIMI-layer impersonation attack-class at the protocol surface (attacker publishes a BIMI record on a cousin-domain or registered-but-unprotected sibling, then sends DMARC-passing mail with a victim's logo-likeness in the MUA's brand-display slot), the BIMI-VMC- certificates spoke documents the STRUCTURAL DEFENSE that closes that attack-class at issuance time: the VMC's Mark Verifying Authority (MVA) trademark- evidence-validation gate is the SINGLE cross-domain check that prevents an attacker from procuring a VMC for a trademark they do not legally own — the MVA's 3-6-week validation walks the attacker's claimed mark through USPTO / EUIPO / IPO / WIPO trademark-registry cross-reference, chain-of-title corporate- documents validation, and a domain- ownership-evidence pack — every one of which the §7.4 attacker FAILS by construction (they don't own the trademark). The implication: even if an attacker on a cousin-domain achieves DMARC=pass, they CANNOT obtain a VMC for the victim's logo, so Gmail / Apple Mail / Yahoo / Fastmail / Yahoo's MUA-side brand-display logic will refuse to render the attacker's logo from the attacker's spoofed BIMI record — the attacker can spoof the domain (the §1-§7 bypasses on this page) but cannot spoof the brand at the visual-recognition layer the end-user actually consumes. AND the VMC SVG-hash-binding mechanism (the cert embeds a hash of the SVG bytes the BIMI l= tag points to, validated at MUA render time) closes the secondary cross-domain-logo-substitution attack-surface where an attacker who procured a VMC for their OWN trademark attempts to point at a victim-brand SVG URL. Read the BIMI-VMC-certificates spoke alongside §7.4 of this page when scoping the brand-impersonation-defense posture — the VMC's MVA gate is the out-of-band trademark-law check that in-band SPF / DKIM / DMARC cryptographic authentication cannot provide, and is the structural reason BIMI's brand- display layer is more spoof-resistant than the email-authentication layer it composes with.
• CAA records explained — the CAA-RECORDS-AS-DIRECT-DEFENSE- AGAINST-CA-COMPROMISE-ATTACKER-BYPASS companion reference to this bypass catalogue's transport-layer and BIMI- layer cert-dependent attack-classes. Where THIS page catalogues 22 attacker- bypass techniques against the DMARC- layer authentication-decision pipeline, the CAA-records-explained spoke documents the STRUCTURAL DEFENSE that closes the historically-realised CA- compromise attacker-bypass class at the PKI-trust-root layer every cert- dependent email-security protocol implicitly depends on, across four compromise-defense dimensions: (i) historical CA compromise constitutes a realised attacker-bypass class for any cert-based email-security protocol composed with DMARC — DigiNotar (2011, Comodo (2011, the Iranian-attacker attempt against Google / Yahoo / Skype), Symantec/Google distrust (2017, forced re-issuance of millions of certs), and TÜRKTRUST (2013, Google intermediate mis-issuance) each produced attacker-controlled publicly-trusted certs that any MTA-STS-honouring receiver, BIMI- rendering MUA, or TLS-RPT-submitting client would chain-validate as valid, STRUCTURALLY BYPASSING the trust guarantees those protocols claim to provide downstream of DMARC, (ii) the CAA issue "<ca-domain>" and issuewild "<ca-domain>" directives lock down the per-domain set of CAs authorised to issue, mitigating the cross-CA-compromise leakage where a breach at any of the ~150 publicly- trusted CAs would otherwise enable attacker-procured cert issuance for the victim domain, (iii) the iodef "mailto:…" / "https://…" URI directive enables operator notification of CA-side issuance attempts violating the publisher's authorisation set — paralleling DMARC rua=mailto: aggregate- report alerting at the PKI-issuance layer rather than at the application- authentication layer, surfacing attacker reconnaissance of cert- issuance prior to actual cert delivery, and (iv) RFC 8657 sub-CA issuance- scope tightening (issue "ca.example.com; account=12345; validationmethods=dns-01") narrows the issuance-authorisation scope to a specific CA account + a specific ACME validation method, paralleling DKIM s= service-type-flag tightening at the application-authentication layer for analogous attacker-bypass narrowing discipline. Read the CAA-records- explained spoke alongside this page's §7.4 BIMI-impersonation and transport- layer bypass-classes when scoping the publisher-side PKI-issuance- authorisation defense posture — a domain with strong DMARC enforcement but absent or permissive CAA records remains exposed to the CA-compromise attacker-bypass class at the trust- root layer the DMARC-layer authentication-decision pipeline this page catalogues cannot reach.
• DMARC for SaaS senders — the ESP-side context for §7.2 compromised ESP / SaaS sender attacks.
• DMARC for transactional email — per-ESP attack-surface defensive authoring for SendGrid / Mailgun / SES / Postmark / SparkPost — the PER-ESP-ATTACK-SURFACE-DEFENSIVE- AUTHORING companion to this bypass catalogue for the operator population controlling THE PER-ESP AUTHENTICATION- PLANE that determines which §5 SPF bypasses, §6 sophisticated bypasses, and §7 sender-side bypasses are exploitable against their transactional-mail flow. Where this page catalogues 22 bypass techniques at the DMARC layer, the transactional-email spoke catalogues the per-ESP-specific authoring decisions that determine whether those bypasses succeed or fail against a domain delegating outbound transactional mail to a third- party ESP: §5.4 sub-account-takeover attack surfaces are determined by whether the operator has enumerated only the ESP's main-account SPF macros or the sub-account-specific Return-Path subdomains; §5.5 shared-IP-pool attack surfaces are determined by whether the operator's SPF authorises a shared ESP pool (where co-tenants can send as the operator's domain) vs. a dedicated pool (where only the operator's mail can pass SPF); §6.2 DKIM-replay attack surfaces are determined by whether the operator's ESP has activated DKIM key rotation past the 12-month cryptographic-hygiene threshold; §7.1 compromised-ESP-account attack surfaces are determined by whether the operator has dedicated SaaS-sender subdomain isolation that limits the radius of a compromised ESP API key; §6.4 stale-ESP-decommissioning attack surfaces are determined by whether the operator has prompt-removal-on-vendor-churn DNS hygiene for the ESP's CNAME-delegated DKIM keys and Return-Path subdomain after the operator off-boards from one ESP onto another. Pair this bypass catalogue (the attack-surface inventory) with the transactional-email spoke (the per-ESP defensive-authoring catalogue) for the complete red-team-to-blue-team workflow on any domain whose outbound mail is wholly or partly delegated to a transactional-email ESP.
• Email deliverability — the ATTACKER-DAMAGE-TO-LEGITIMATE-DOMAIN- REPUTATION-COLLATERAL-CONSEQUENCE-FOR-INBOX- PLACEMENT-AT-MAILBOX-PROVIDER-RECEIVE-SIDE companion documenting the umbrella inbox- placement outcome (Gmail / Yahoo / Outlook / AOL / Apple iCloud / Fastmail mailbox-provider inbox-vs-junk-folder routing decisions) each successful attacker-bypass technique on this page collaterally damages even AFTER the attack is detected and stopped. Where THIS page enumerates 22 attacker techniques against the DMARC message-identity layer (display-name spoofing, lookalike-domain registration, ARC trust-chain abuse, DKIM replay, third-party-vendor compromise, l= tag abuse, etc.), the email- deliverability spoke is the REPUTATION-COLLATERAL-DAMAGE companion documenting WHY each successful bypass leaves a measurable inbox-placement residue at the legitimate publisher's domain reputation EVEN WHEN the attack is detected, contained, and stopped. The four-axis BYPASS-CATALOGUE- VS-DELIVERABILITY-COLLATERAL-DAMAGE comparison exposes the structurally-distinct ATTACKER-DAMAGE-TO-DELIVERABILITY roles: (i) successful attacker-bypass mail delivered to recipient mailboxes enters the receiver-side spam-classifier training corpus labelled as legitimate publisher mail because the DMARC layer admitted it — the labelling pollutes the publisher's per-domain spam-classifier weights for weeks-to-months after the attack is stopped; the deliverability spoke documents the operator remediation workflow (Gmail Postmaster Tools "Domain reputation" recovery cadence, Microsoft SNDS IP-reputation re-evaluation, escalation paths through Yahoo Sender Hub) attacker-bypass-driven reputation damage requires; (ii) recipient complaint and spam-report rates from attacker- bypass mail directly downgrade the legitimate publisher's mailbox-provider deliverability score — recipients who report attacker-bypass mail as spam (without recognizing it's attacker-driven, not publisher-driven) generate per-domain complaint signals that feed into the publisher's "complaint rate" metric at every major receiver; the deliverability spoke documents the complaint-rate thresholds beyond which mailbox providers junk-folder ALL mail from the publisher; (iii) BIMI logo display gating produces a binary brand-visibility deliverability outcome attacker-bypass can collapse — if an attacker-bypass technique succeeds and recipients see attacker-driven mail WITHOUT the publisher's brand logo, recipient trust in the brand identity degrades; the deliverability spoke documents the BIMI-as- deliverability-signal feedback loop the bypass catalogue's §7.4 BIMI-impersonation attack class threatens; (iv) p=reject rollout (the defensive deployment THIS page's bypass catalogue motivates) MUST account for legitimate-mail deliverability churn independently from attacker-bypass residual closure — rolling out p=reject to defeat the 22 bypass techniques on this page produces measurable legitimate-mail false-positive deliverability churn at mailbox-provider receive boundaries; the deliverability spoke documents the per- provider monitoring tools (Gmail Postmaster "Authenticated mail" dashboard, Microsoft SNDS "Filter result" trends) that detect rollout-driven deliverability churn ORTHOGONAL TO the attacker-residual closure the bypass catalogue is engineered to deliver. Read the email-deliverability spoke alongside this bypass catalogue when scoping the FULL operator-relevant attack-and-defense posture: this page documents the 22 attacker- bypass techniques against the DMARC message- identity layer, email-deliverability documents the collateral-damage-to-domain-reputation consequence each successful bypass produces at the mailbox-provider receive boundary, and the two together name the complete attacker- damage-to-publisher-deliverability surface the bypass-catalogue defenses are engineered to close.
• Business Email Compromise (BEC) explained — the financial-fraud outcome class that the §4 lookalike, §6 sophisticated, and §7 sender-side attacks on this page ultimately deliver. Where this page catalogues 22 bypass techniques at the DMARC layer, the BEC page documents the six canonical BEC variants (CEO fraud / executive impersonation, vendor / supplier-invoice fraud, payroll- redirect, attorney impersonation, data / W-2 theft, account-compromise BEC) plus the five-stage BEC kill chain (reconnaissance → infrastructure-staging → social-engineering message → wire / payroll / data-exfiltration request → cover-up). Cross- referenced anchors: §7.1 compromised- legitimate-account attacks on this page map directly to BEC variant 6 (account-compromise BEC); §4.3 lookalike-domain attacks map to the BEC infrastructure-staging stage; §6.3 DKIM replay maps to the rare BEC pivot used against high-reputation senders. The BEC page closes with the FBI IC3 statistics (USD 2.9B reported loss in 2023, cumulative USD 55B+ since 2013), an incident-response playbook for treasury / finance teams, and the full defense-in-depth control stack the §10 indicators on this page feed into. Pair the bypass catalogue (the red-team technique inventory) with the BEC page (the blue-team outcome and defense-program design) for the complete attack-to-financial-loss chain.
• Email authentication glossary — canonical definitions for every term-of-art the attacks reference: alignment, organizational domain, PSL, envelope MAIL FROM, ARC chain, and more.
• Email security glossary — the threat-and-defense vocabulary companion to the protocol glossary; defines every adversary-side term this bypass catalogue uses but does not stop to define: APT (the well-resourced adversary class behind the §6 sophisticated attacks), BEC / CEO fraud (the §7 high-loss attack family the FBI IC3 ranks as the highest-loss email crime category at USD 2.9 billion in 2023), spear phishing / whaling (the targeted- social-engineering classes the §4 look-alike and §5.6 subdomain-takeover attacks deliver), smishing / vishing / quishing (the SMS / voice / QR-code phishing variants that route around DMARC entirely), clone phishing (the §7.2 compromised-ESP attack variant), pharming (the DNS-cache- poisoning variant that bypasses look-alike- domain defences), homograph and typosquatting (the §4.3 lookalike-domain registration techniques), OSINT / WHOIS / Shodan / Censys (the §3 reconnaissance toolkit attackers use to enumerate signing infrastructure), the cyber kill chain / MITRE ATT&CK / diamond model (the threat-modelling frameworks this page maps the bypass classes onto), the NIST IR lifecycle / indicators of compromise / dwell time (the incident-response vocabulary the §10 detection patterns surface in), and the SOC / SIEM / SOAR / EDR / XDR operations vocabulary every defender consumes the §10 indicators through. Read the security glossary first if any term in this catalogue is unfamiliar; the catalogue assumes the reader understands the vocabulary.
• 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 surfaces the §10 indicators.
• SPF permerror vs temperror — the ATTACKER-EXPLOITATION-OF-SPF- PERMERROR-AS-DMARC-BYPASS-VECTOR companion to this DMARC-attacker-bypass threat catalogue. Where THIS page documents the 22 catalogued attacker techniques across four classes (direct From-identity, weak-configuration, authentication-mechanism, infrastructure) the attacker uses to defeat DMARC, the permerror-vs-temperror spoke is the AUTHENTICATION-MECHANISM-ATTACK- SUB-CLASS companion documenting the specific SPF-evaluator-outcome an attacker can engineer to collapse the SPF-half of the DMARC OR-conjunction (RFC 7489 §6.6.2 — DMARC enforcement requires EITHER SPF alignment OR DKIM alignment): an attacker engineering the victim's SPF record into permerror state through (a) include- cascade poisoning — convincing the victim's IT team to add one more SaaS-include to a record already at the 9-lookup ceiling, tipping it into the 10-lookup permerror state across all outbound mail, (b) void- lookup engineering — registering a domain referenced by the victim's SPF record and pointing it to a non-existent zone so the lookup triggers the void-lookup secondary cap (per RFC 7208 §4.6.4), (c) nameserver-amplification attack — DDoS'ing the authoritative nameserver of a hosted include token in the victim's SPF record so every receiver-side evaluation produces spf=temperror which the receiver may treat as non-fatal but the DMARC engine's engine-specific temperror-handling becomes a fuzzy attack-surface. Once the victim's SPF evaluates to permerror at every receiver, RFC 7489 §6.6.1 treats it as alignment-fail — the SPF-half of the DMARC OR-conjunction collapses permanently, leaving only the DKIM-aligned half as the viable path to DMARC pass. A victim relying on SPF-alignment for DMARC pass (rather than DKIM-alignment) becomes wholly bypassable for any sender path that produces SPF-aligned-but- DKIM-unaligned mail (the canonical case for unforwarded direct-domain sends via SaaS senders that sign with the platform's d=, not the customer's). Read the permerror-vs- temperror spoke alongside this page when authoring the SPF-INFRASTRUCTURE section of an organisation's DMARC- attacker-hardening posture, and when designing the DKIM-PRIMARY alignment strategy that survives an attacker-engineered permerror state on the SPF half of the disjunction.
• TLS-RPT explained — the THREAT-CATALOGUE-TRANSPORT-LAYER- ATTACKER-BYPASS-PROTOCOL-OBSERVABILITY- OVERVIEW companion reference. Where THIS page documents the 22-technique DMARC- attacker-bypass threat catalogue (alignment- evasion, authentication-evasion, policy- evasion, infrastructure-evasion classes operating at the application/header/DNS layers), the TLS-RPT-explained spoke is the TRANSPORT-LAYER-ATTACKER-OBSERVABILITY- PROTOCOL-CHARTER reference documenting the RFC 8460 protocol-level model that closes the attacker-observability gap at the SMTP delivery boundary — the layer immediately below the application/DKIM/DMARC layers where ORTHOGONAL attacker-bypass paths operate invisibly to the DMARC observability plane. FOUR structurally-distinct PROTOCOL- LAYER-ATTACKER-BYPASS-OBSERVABILITY dimensions the TLS-RPT charter defines that THIS attacker-bypass threat-catalogue structurally consumes for transport-layer defense-posture framing: (i) RFC 8460 §1 protocol charter — closes the per-receiver per-day opportunistic-TLS attacker-observability gap as the FOUNDATIONAL transport-layer-attacker- bypass detection prerequisite — prior to TLS-RPT (pre-2018), neither the sender's operator nor the recipient's operator had per-receiver per-day evidence to distinguish a StripTLS/MITM/BGP-hijack attacker-bypass path on the SMTP delivery boundary from natural per-receiver opportunistic-TLS failure (clock skew, intermediate-CA chain weakness, STARTTLS-cap heuristic failure); the TLS-RPT charter establishes the per-domain aggregate evidence stream that surfaces the four major bypass classes catalogued in §7-§9 of THIS page (StripTLS, MTA-MITM forged-CA, BGP-hijack /24 reroute, intermediate-CA mis-issuance) as detectable signals — without TLS-RPT-protocol deployment, the 22-technique catalogue's §7-§9 transport-layer techniques would be undetectable; (ii) RFC 8460 §2 operator deployment model — TXT-record publication at _smtp._tls.<domain> + RUA-mailbox per-day aggregate ingestion + per-receiver per-day-per-domain aggregation cadence — establishes the OPERATOR-SIDE PREREQUISITE every transport-layer attacker-bypass detection depends on — the protocol-overview spoke documents the deployment-model operators inherit when publishing TLS-RPT (RUA-mailbox subscriber selection, per-receiver aggregate-report cadence expectations, per-day aggregation boundary) that the byte-syntax (tls_rpt_record_syntax) and JSON-format (tls_rpt_report_format) spokes operationalize — without the deployment-model context THIS attacker- bypass page documents, the operator cannot author a transport-layer-attacker- observability program (per-receiver baseline establishment, per-receiver-per- day anomaly thresholds, per-domain receiver- population coverage expectations); (iii) RFC 8460 §5 privacy constraints — per-day-per-domain aggregation strictly excludes per-message PII as the ATTACKER- UNUSABLE-AS-EXFIL-CHANNEL invariant defining the per-receiver aggregate cardinality boundary — the TLS-RPT-explained spoke documents the §5 privacy-by-design protocol invariant that TLS-RPT aggregates exclude per-message envelope-sender, per-message message-id, per-message recipient (in contrast to RFC 7489 §7.2 forensic/failure reports under DMARC ruf=), as the per-domain aggregate cardinality boundary an attacker who compromises a victim's RUA-mailbox CANNOT exploit for per-message PII exfiltration — closes one transport-layer-bypass- defense-program risk class (the compromised-RUA-subscriber attack on the observability infrastructure) that THIS catalogue's attacker-infrastructure- evasion class would otherwise need to document; (iv) RFC 8460 §6 reporter-side trust model — cross-receiver consistency analysis as the operator-side defense pattern surfacing a compromised reporter inserting fabricated aggregate- success entries — the protocol- overview spoke documents the receiver- trust model under which receivers themselves are attacker-targetable (an attacker who compromises one major receiver's TLS-RPT reporting pipeline can fabricate "TLS-success" aggregate rows to suppress detection of an ongoing StripTLS/MITM attack); the operator-side defense pattern is per-day cross-receiver consistency analysis (if N-1 receivers report a per-day TLS-pass-rate anomaly AND 1 receiver reports a per-day TLS-pass- rate baseline, that 1 receiver is the compromised reporter and a SECOND-ORDER attacker-bypass signal). Read the TLS- RPT-protocol-overview spoke alongside the record-syntax (tls_rpt_record_syntax) and JSON-format (tls_rpt_report_format) spokes when authoring the TRANSPORT-LAYER section of an organisation's DMARC-attacker- hardening posture — the protocol-overview is the CHARTER + DEPLOYMENT-MODEL + PRIVACY-INVARIANT + REPORTER-TRUST-MODEL canonical reference; the byte-syntax and JSON-format spokes are the operational downstream-publication and downstream- ingestion references that build on the protocol-overview's foundation. Every domain deploying DMARC at p=reject should co-publish TLS-RPT (per the protocol- overview's §2 operator-deployment-model) to receive the per-receiver transport- failure aggregate stream that surfaces the four orthogonal attacker-bypass classes operating below the DMARC layer.
• TLS-RPT record syntax — the THREAT-CATALOGUE-TLS-DOWNGRADE- AND-MITM-DETECTION-VIA-TLS-RPT-RUA- AGGREGATE-REPORTING companion reference. Where THIS page documents the DMARC-ATTACKER-BYPASS threat catalogue (DKIM 1024-bit factoring, DKIM-l= tag abuse, ARC chain abuse, BIMI exploitation, SPF lookup-limit attacker-engineering, From: header forgery, lookalike-domain registration), the TLS-RPT-record- syntax spoke is the TRANSPORT-LAYER- ATTACK-DETECTION INFRASTRUCTURE REFERENCE documenting the byte-syntax of the operator's transport-failure aggregate reporting channel — the infrastructure DMARC-aware operators use to detect ORTHOGONAL transport- layer attack vectors the DMARC protocol does not see: (i) StripTLS / opportunistic-TLS downgrade — attacker-in-the- middle MTA strips the STARTTLS capability from the EHLO response, forcing the sending MTA to deliver cleartext where it would otherwise encrypt; TLS-RPT aggregate reports capture the per-receiver starttls-not-supported and negotiation-failure result-type rows that surface the attack; (ii) MTA-MITM downgrade via forged CA cert — attacker presents a TLS certificate for the victim domain (CAA mitigates if published — see CAA spoke); TLS-RPT captures the certificate-not-trusted or certificate-host-mismatch result-type row when MTA-STS is deployed alongside; (iii) BGP hijack rerouting SMTP traffic — attacker hijacks a /24 covering the victim MX IP space and intercepts SMTP; TLS-RPT surfaces the resulting tls-error spike as the sending MTA fails to establish TLS with the hijacker's MTA. The byte- syntax reference is therefore the OPERATOR-SIDE DETECTION-INFRASTRUCTURE ENTRY POINT for the threat-catalogue this page documents — every domain deploying DMARC at p=reject should co-publish TLS-RPT _smtp._tls.<domain> per the byte-syntax spoke to receive the per-receiver transport-failure aggregate stream that surfaces these ORTHOGONAL attacker-bypass paths operating below the DMARC layer.
• TLS-RPT report format (RFC 8460 §4 JSON schema) — the THREAT-CATALOGUE-TRANSPORT-LAYER- ATTACKER-BYPASS-DETECTION-VIA-TLS-RPT- JSON-FAILURE-CLASS-CATALOGUE companion reference. Where THIS page documents the 22-technique DMARC-attacker-bypass threat- catalogue (alignment-evasion, authentication- evasion, policy-evasion, infrastructure- evasion classes) AND the tls_rpt_record_syntax spoke documents the TXT-record DNS-byte-syntax that publishes the operator's transport-failure aggregate- reporting channel, the TLS-RPT-report- format spoke documents the JSON-payload byte-schema of THAT channel — the RFC 8460 §4 JSON-schema that the receiver-side per-day aggregate report uses to encode the per-receiver transport-failure evidence rows. FOUR structurally-distinct TRANSPORT-LAYER-ATTACKER-BYPASS-VS-TLS- RPT-JSON-RESULT-TYPE operational classes the JSON schema enumerates that THIS threat-catalogue cross-references but does not byte-schema enumerate: (i) StripTLS / opportunistic-TLS- downgrade detection via starttls-not-supported and negotiation-failure result- type rows — the JSON schema's per-day per-receiver row encodes receiver-MTA's observation that the sending MTA either did not advertise STARTTLS (suggesting the sending MTA's cleartext-fallback path was attacker- manipulated upstream) or attempted but could not complete STARTTLS handshake, and the operator's per-receiver-per- day-time-series of these row-counts IS the detection signal for the StripTLS attacker-bypass class; (ii) MTA-MITM-via-forged-CA-cert detection via certificate-not-trusted, certificate-host-mismatch, and certificate-expired result-type rows — the JSON schema's per-receiver per-day rows encode the receiver-MTA's TLS- certificate-chain-verification failure classes, and the operator's per- receiver per-day spike in these row- counts IS the detection signal for attacker-presented-rogue-certificate- chain bypass attempts; (iii) BGP-hijack-rerouting detection via tls-error and dane-invalid result-type rows with associated source-IP attribution — the JSON schema's per-receiver per-day rows encode the receiver-side TLS-handshake failure observed against unexpected peer-MTA infrastructure, which when joined against the per-day source-IP per-receiver attribution allows the operator to detect BGP-hijack-rerouting attacker activity targeting the publisher's MX IP-space; (iv) per-receiver per-day aggregate-pipeline ingestion of TLS- RPT JSON-payload-byte-stream alongside DMARC RUA XML-payload-byte-stream as cross-protocol attacker-bypass- detection input — the operator's seven-stage DMARC-RUA pipeline architecture documented in dmarc_reporting_pipeline reuses Stages 1-4 (ingestion, format-detection, decompression, schema-validation) identically for TLS-RPT JSON payloads, parameterising Stage 5 on application/tlsrpt+gzip vs application/zip Content-Type to produce a unified transport-layer + application-layer attacker-bypass-detection feed the security team's incident-response runbook consumes. The byte-schema reference is therefore the OPERATOR- SIDE BYTE-LEVEL DETECTION-EVIDENCE- FORMAT REFERENCE for the threat- catalogue this page documents — every domain deploying DMARC at p=reject AND co-publishing TLS-RPT _smtp._tls.<domain> per the byte-syntax spoke ingests per-receiver per-day JSON aggregate reports whose byte-schema is what THIS reference documents.
• SPF qualifiers explained — the THREAT-CATALOGUE-SPF-SOFTFAIL-VS- HARDFAIL-QUALIFIER-CHOICE-AS-ATTACKER- EXPLOITATION-SURFACE companion reference. Where THIS page documents the 22 attacker-bypass techniques operating above and around the SPF/ DKIM/DMARC layers (display-name spoofing, lookalike-domain registration, ARC trust-chain abuse, DKIM replay, DKIM-l= tag abuse, third-party-vendor compromise, BIMI exploitation), the SPF-qualifiers spoke documents the FOUR QUALIFIER PREFIXES (+ Pass / - Fail / ~ SoftFail / ? Neutral) whose VALUE-CHOICE on the all mechanism determines the receiver-side SMTP-time enforcement contract for non-authorised IPs. The choice between ~all (SoftFail — receivers SHOULD NOT reject solely on this result, message delivered to inbox with spf=softfail Authentication-Results disposition) and -all (Fail — receiver MAY reject, discard, or quarantine per RFC 7208 §4.7) is itself part of the attacker-bypass surface this page catalogues. An attacker delivering from a non- authorised IP to a domain published with ~all wins inbox delivery at most receivers regardless of policy mode, because the SoftFail signal is conventionally treated as monitoring-mode and receivers do not act on it at SMTP time. The -all qualifier gives receivers explicit authority to REJECT at the SMTP layer (before DMARC evaluation even runs against the alignment disjunction), shrinking the attacker-exploitable inbox- delivery window. Read the qualifier spoke alongside this page when authoring the SPF-INFRASTRUCTURE section of an organisation's DMARC- attacker-hardening posture — the choice of ~all vs -all is an explicit decision in the attacker-defeat playbook the threat-catalogue operationalises.
• DKIM best practices — the THREAT-CATALOGUE-DKIM-BEST- PRACTICES-AS-PRIMARY-DEFENSE-DISCIPLINE companion reference. Where THIS page documents the 22-technique attacker- bypass catalogue across 4 attack classes (alignment-evasion, authentication-evasion, policy-evasion, infrastructure-evasion) including multiple DKIM-class attack vectors (key-too-short brute-force, weak- canonicalization body-modification forging, single-selector-no-rotation replay-window-expansion, DKIM l=-tag body-truncation abuse, oversign-omission header- replay, t=y testing-mode publication mis-discipline, per-stream selector-cross-contamination), the DKIM-best-practices spoke documents the OPERATOR-PUBLICATION-DISCIPLINE RULESET whose collective satisfaction structurally closes SEVEN of those 22 techniques at the publisher-side defense layer across SEVEN per-rule per-technique mitigation contracts: (1) key-length-floor RSA-2048+ rule closes the key-too-short brute-force bypass class (technique §3.X of the 22-catalogue); (2) algorithm-choice k=rsa or k=ed25519 publication discipline closes the deprecated- algorithm receiver-side-acceptance bypass class; (3) selector-cadence dual-selector-overlap rotation rule closes the single-selector-no-rotation replay-window-expansion bypass class; (4) canonicalization-choice c=relaxed/relaxed rule closes the weak-c=simple/simple body-modification forging bypass class; (5) oversign-discipline h=From:From:From:Subject:To:Date rule closes the oversign-omission header-replay bypass class; (6) l=-tag-avoidance rule closes the body-length-limit truncation-abuse bypass class; (7) t=y testing-mode-window discipline (limit to first 24-48-hour publication-verify window) closes the t=y-as-permanent-publication receiver-side-non-authoritative bypass class. Read the DKIM-best-practices spoke alongside THIS page when scoping the publisher-side defense ruleset against the DKIM-class attacker-bypass techniques this catalogue enumerates — the seven-rule discipline is the canonical PUBLISHER-SIDE primary defense layer against the DKIM-class subset of the 22 techniques and a complete attacker-defeat audit must verify all seven rules are in place before treating the residual catalogue as the operative threat surface.
• DKIM cryptography basics — the THREAT-CATALOGUE-WEAK-DKIM- CRYPTOGRAPHIC-FOUNDATIONS-AS-ATTACKER- EXPLOITATION-SURFACE companion reference. Where THIS page documents the 22 attacker-bypass techniques operating ABOVE and AROUND the SPF/DKIM/ DMARC layers (display-name spoofing, lookalike-domain registration, ARC trust-chain abuse, DKIM replay, DKIM-l= tag abuse, third-party-vendor compromise, BIMI exploitation), the DKIM-cryptography-basics spoke documents the FIVE CRYPTOGRAPHIC-PRIMITIVE-LEVEL ATTACKER-EXPLOITATION DIMENSIONS at the DKIM signing-and-verification layer whose WEAK-POSTURE CHOICE creates attacker-bypass opportunities BELOW the per-technique surface this page catalogues: (i) RSA key-size factorability bypass — an attacker who factors a publisher's RSA-1024 DKIM key (factorable within commercial-cloud-compute budget per 2009 RSA-768 Kleinjung et al. factoring + NIST SP 800-57 Part 1 Rev 5 §5.6.2 2014 RSA-1024 deprecation) can sign ARBITRARY messages with the publisher's d= aligned domain, defeating EVERY downstream alignment check the attacker-catalogue describes; the spoke explains WHY RSA-2048 is the defensible floor (NIST 2030 transition-target), RSA-3072 the 2031-2050 defensible-floor, RSA-4096 the defense-in-depth ceiling. (ii) rsa-sha1 deprecated- algorithm bypass — RFC 8301 deprecates rsa-sha1 (a= tag value rsa-sha1) but per-receiver-vendor variance in rsa-sha1 rejection posture leaves attacker-controlled signing keys usable against receivers that have not upgraded to the rsa-sha1-reject default; the spoke documents WHICH receivers have upgraded and which still accept rsa-sha1 (load-bearing for threat-modeling). (iii) no-selector-rotation compromised-key indefinite-reuse bypass — DKIM has NO REVOCATION mechanism analogous to TLS CRL/OCSP / only DELETE selector TXT or PUBLISH null-key v=DKIM1; p=; / compromised-key without rotation discipline remains attacker-usable for remaining lifetime of publisher's domain / attacker's signed messages pass every authentication check by construction; the spoke explains the quarterly-selector-rotation cadence bounding compromised-key attack-window duration. (iv) private-key exfiltration via insufficient storage discipline bypass — publisher- private-key checked into source control / stored in plaintext on application servers / exported from cloud-KMS for local-developer debugging / shared across tenant in shared-hosting platform / not isolated to HSM-backed signing infrastructure — each violates the no- export attribute discipline and creates attacker-extractable signing-key surface independent of every per-technique bypass in the catalogue; the spoke explains HSM-backed signing infrastructure / per-customer key isolation / no-checkout-to-developer- laptop discipline. (v) Ed25519 receiver-compatibility-floor exploited as DKIM-required-but-not-validated receiver-vendor bypass — publisher who deploys Ed25519-only signing (RFC 8463 a=ed25519-sha256) without RSA fallback exposes messages to receivers that have not implemented Ed25519 validation as dkim=neutral result — DMARC alignment treats neutral as no- DKIM-policy-applicable, falling back to SPF-only evaluation, exposing the message to every SPF-only attacker- exploitation dimension in this page's catalogue. The DKIM-cryptography-basics spoke is essential reading for THREAT- MODELING SECTION of an organisation's DMARC-attacker-hardening posture — the per-technique bypass catalogue this page documents operates IN PARALLEL with the cryptographic-primitive-level weak- posture surface the spoke documents, not in place of it; defensible DMARC- attacker-hardening posture requires closing BOTH the per-technique surface (this page) AND the cryptographic- primitive surface (the spoke).
• DKIM canonicalization - the THREAT-CATALOGUE-c=RELAXED-EXPANDED- ATTACKER-EXPLOITABLE-MUTATION-SURFACE companion reference. Where THIS page documents the 22 attacker-bypass techniques operating ABOVE and AROUND the SPF/DKIM/ DMARC layers (display-name spoofing, lookalike-domain registration, ARC trust-chain abuse, DKIM replay, DKIM-l= tag abuse, third-party-vendor compromise, BEC pretext-engineering, etc.), the dedicated DKIM-canonicalization spoke documents the STRUCTURALLY-LOAD-BEARING publisher-side c=header/body- tag pair selection whose four canonicalization-algorithm-vs-attacker- mutation-class coordination dimensions identify a distinct attacker-bypass surface that the 22-technique catalogue on this page references as a publisher-side-choice-induced expansion of the attacker mutation-tolerance surface: (i) c=relaxed header canonicalization tolerates header field- name case-folding (FROM: vs From: vs from: treated as bit-identical per RFC 6376 §3.4.2) which is operationally REQUIRED to survive MTA header re-canonicalization but simultaneously expands the surface for header-injection attack classes that rely on case-variant header smuggling; the DKIM-canonicalization spoke documents the relaxed-header case- folding tolerance and the per-receiver- implementation header-parser variation that determines whether the attacker can exploit the canonicalization tolerance to forge a header-smuggled signature- passing message; (ii) c=relaxed body canonicalization tolerates trailing whitespace + CR-LF normalisation + trailing empty-line collapse per RFC 6376 §3.4.4 which is operationally REQUIRED to survive MTA whitespace mutation but simultaneously expands the attacker-mutation-tolerance surface for body-mutation attack classes that operate within the relaxed-body whitespace-normalisation tolerance window; the DKIM-canonicalization spoke documents the relaxed-body whitespace-collapse contract and the per-attacker-mutation-class taxonomy identifying which body-mutation classes the relaxed-algorithm tolerates (and therefore expands the attacker surface for) versus which mutation classes exceed the tolerance scope and produce bh=-invalidation regardless; (iii) c=relaxed combined with DKIM-l= tag length-limit signing (a 22-technique catalogue attack class) compounds the attacker-exploitable surface multi- plicatively - the l=-tag attack permits APPEND of attacker-controlled body bytes BEYOND the signed-length boundary, and the relaxed-body canonicalization tolerance permits attacker-controlled whitespace mutation WITHIN the signed- length boundary, producing a combined attacker-mutation surface significantly larger than either attack class independently exposes; the DKIM- canonicalization spoke documents the c=relaxed-with-l=-tag compound-attack surface and the operator-decision framework for closing the compound surface via l=-tag elimination at the publisher signing configuration; and (iv) c=simple algorithm-pair choice closes some attacker-mutation-tolerance surfaces (case-folding tolerance, whitespace- collapse tolerance) but at the cost of breaking on essentially every MLM/forwarder traffic path - the publisher's c=-tag choice is itself a SECURITY-VS-DELIVERABILITY operator-decision trade-off the attacker-bypass-catalogue threat model rests on at the publisher-policy-choice layer; the DKIM-canonicalization spoke documents the simple-algorithm attacker-mutation-tolerance closure contract and the operator-decision framework for choosing the algorithm- pair appropriate to the mail-stream's threat-model-vs-deliverability profile.
• BIMI SVG-Tiny-PS image authoring requirements — the THREAT-CATALOGUE-BIMI-DISPLAY- INDICATOR-SVG-PARSE-EXPLOITATION-AS- ATTACKER-EXPLOITATION-SURFACE companion reference. Where THIS page documents the 22 attacker-bypass techniques operating ABOVE and AROUND the SPF/DKIM/DMARC layers (display-name spoofing, lookalike- domain registration, ARC trust-chain abuse, DKIM replay, DKIM-l= tag abuse, third-party-vendor compromise), the BIMI-SVG-Tiny-PS-image-authoring spoke documents the FIVE BIMI-IMAGE-AUTHORING- LAYER ATTACKER-EXPLOITATION DIMENSIONS at the publisher's branded-inbox-indicator layer whose WEAK-POSTURE AUTHORING-RULE CHOICES create attacker-bypass opportunities BELOW the per-technique surface this page catalogues: (i) SVG-script-injection-via-author- ing-rule-violation bypass — an attacker who induces the publisher to deploy a non-SVG-Tiny-PS-conformant SVG (eg containing <script> / event handlers / xlink:href references forbidden by the BIMI Working Group authoring-rules-draft §6) can stage XSS / SSRF / data-exfiltration payloads delivered through the branded-inbox- display channel at receiver-side clients that do not strictly enforce the Tiny-PS subset; (ii) VMC-procurement-trademark-fraud bypass — an attacker who successfully procures a VMC against a FRAUDULENTLY-REGISTERED LOOKALIKE-MARK (combining the lookalike-domain attacker-bypass technique this page documents with a CA/Browser-Forum BR §3.2.2.8 trademark-validation bypass) delivers a verified-branded-display indicator on a lookalike domain — a higher-trust signal than the unbranded lookalike alone; (iii) SVG-MIME- Content-Type-confusion bypass — an attacker who induces the publisher to serve the SVG with a non- image/svg+xml Content-Type (text/html / application/xml / application/octet-stream) defeats receiver-side strict-MIME-enforcement, forcing fallback-to-unbranded display and surfacing a credibility signal an attacker-controlled lookalike domain does not have to defeat; (iv) baseProfile-attribute-spoofing bypass — an attacker who manipulates a non-strict receiver into accepting a non-Tiny-PS profile claiming a Tiny-PS baseProfile attribute can deliver post-display-time runtime- feature exploitation; (v) 32-KB- envelope-overflow bypass — an attacker who induces the publisher to deploy an over-32-KB-after-base64 SVG defeats receiver-side load-budget enforcement and surfaces a silent-no- branded-indicator across the receiver population, defeating publisher-side brand-recognition signalling. The BIMI-SVG-Tiny-PS-image-authoring per-technique bypass surface this page documents operates IN PARALLEL with the publisher-side display-indicator- authoring weak-posture surface the spoke documents, not in place of it; defensible DMARC-attacker-hardening posture requires closing BOTH the per-technique surface (this page) AND the BIMI-display-indicator-authoring surface (the spoke).
• DMARC for Microsoft 365 — the M365-TENANT-DEPLOYMENT-CONTEXT- AS-ATTACKER-BYPASS-CATALOGUE-DEFENSE- SURFACE companion to this 22-technique attacker-bypass catalogue reference. Where THIS page documents the OFFENSIVE-PERSPECTIVE 22-technique attacker-bypass catalogue (four classes: alignment-evasion, authentication-evasion, policy- evasion, infrastructure-evasion) whose structural attribution framework every defensive primitive maps each per-message verdict onto, the M365- deployment spoke is the M365-TENANT- DEFENSIVE-DEPLOYMENT-CONFIGURATION REFERENCE documenting how each per- M365-tenant deployment-time configuration primitive defends against a structurally-distinct attacker-bypass class. Concretely the spoke documents FOUR per-M365-tenant- configuration-vs-attacker-bypass- class-defense-coverage dimensions: (i) alignment-evasion class — per-M365-tenant adkim=s-strict-mode publication discipline defends against cousin-domain DKIM-signing bypass technique #4 — the M365-deployment spoke documents the per-M365-tenant _dmarc.<org-domain> TXT-RR adkim=s-strict- mode publication discipline every Exchange Online operator must apply as the M365-tenant per-organisational- domain structural defense against the cousin-domain-DKIM-signing-with- attacker-controlled-key bypass technique adkim=r- relaxed-mode false-accepts under Public-Suffix-List rules; (ii) authentication-evasion class — per-M365-tenant Defender Rotate-DkimSigningConfig automation cadence defends against DKIM-replay- attack bypass technique #10 — the M365-deployment spoke documents the per-tenant Rotate-DkimSigningConfig per-quarter rotation cadence every Exchange Online operator must apply as the M365-tenant per-key-lifetime structural defense against the DKIM-replay-attack bypass technique from compromised-cryptographic-key windows; (iii) policy- evasion class — per-M365-tenant sp=reject per-subdomain publication discipline defends against parked-subdomain-traversal bypass technique #14 — the M365-deployment spoke documents the per-M365-tenant _dmarc.<org-domain> TXT-RR sp=reject publication discipline every Exchange Online operator must apply as the M365-tenant per-subdomain structural defense against the parked-subdomain-traversal bypass technique that sp=none default-inheritance under p=reject-apex permits; and (iv) infrastructure- evasion class — per-M365-tenant Exchange Online Protection cloud- egress IP-pool DKIM-signing- infrastructure-stability dependency is the per-M365-tenant infrastructure-evasion exposure surface — the M365- deployment spoke documents how the per-tenant EOP-cloud-egress IP-pool DKIM-signing availability is the per-M365-tenant infrastructure- evasion exposure surface every Exchange Online operator must monitor via aggregate-report stream because per-tenant transient EOP- side signing-infrastructure outage opens a transient bypass-window the infrastructure-evasion class of attacker-bypass techniques exploits. Read the M365-deployment spoke ALONGSIDE this attacker-bypass catalogue reference when authoring the per-M365-tenant defensive deployment configuration — the spoke documents how each per-M365-tenant deployment-time configuration primitive maps onto the four attacker-bypass classes this page catalogues.
• DMARC for Hybrid Exchange (on-prem + Microsoft 365) — the HYBRID-COEXISTENCE-RELAY-BYPASS- SURFACE companion to this 22-technique attacker-bypass catalogue. Where THIS page documents the OFFENSIVE-PERSPECTIVE 22-technique catalogue (alignment- evasion, authentication-evasion, policy- evasion, infrastructure-evasion), the hybrid-coexistence spoke is the HYBRID- TOPOLOGY-DEFENSIVE-DEPLOYMENT REFERENCE documenting that the on-prem-to-cloud relay introduces a structurally NEW bypass-surface tuple every hybrid- deployment operator must defend against on top of the cloud-only catalogue: (i) authentication-evasion class — Trusted ARC Sealer inheritance from on-prem relay — attackers spoof inbound mail through the on-prem edge so the EXO side inherits ARC-trusted-sealer trust on the relayed envelope, and the hybrid-coexistence spoke documents the per-on-prem-Trusted-ARC-Sealer scope- tightening discipline (RFC 8617 chain validation, per-relay ARC-Authentication- Results header preservation, per-tenant Trusted ARC Sealer allowlist scope) the hybrid operator MUST apply as the structural defense against this bypass class; (ii) infrastructure- evasion class — dual-signer ambiguity from unresolved hybrid signing topology — when the operator has BOTH on-prem and EXO signing the same domain, attackers exploit per- message signing-identity ambiguity to replay valid signatures from one signing path under a forged envelope traversing the other path; the hybrid- coexistence spoke documents the recommended cloud-only-signing pattern and the avoid-this dual-signer pattern as the structural defense against this bypass class. Pair this 22-technique catalogue (the offensive bypass taxonomy) with the hybrid-coexistence spoke (the hybrid-topology defensive deployment reference) for any operator running hybrid Exchange.
• MTA-STS vs DANE comparison — the MTA-STS-VS-DANE-CHOICE-AS- LOAD-BEARING-TRANSPORT-LAYER-DEFENSE- PUBLICATION-AGAINST-EVERY-ATTACKER- BYPASS-CLASS-EXPLOITING-IN-FLIGHT- TLS-STRIPPING-OR-DNS-MX-REDIRECTION companion to THIS DMARC attacker- bypass catalogue. Where THIS page documents the attacker-bypass technique-classes against DMARC (alignment-evasion, signing- infrastructure evasion, forwarder- path exploitation, weak-configuration exploitation, in-flight TLS- stripping, DNS-MX-redirection / cousin-MX exploitation, transport- layer-mail-flow injection-at-MX), the MTA-STS-vs-DANE spoke is the TRANSPORT-LAYER-DEFENSE-PUBLICATION- CHOICE REFERENCE documenting the publisher-side per-domain transport- layer TLS-enforcement-publication choice whose every per-publisher publication-discipline is the load-bearing defense against the in-flight TLS-stripping / DNS-MX- redirection attacker-bypass classes THIS page catalogues at FOUR per- attacker-bypass-class-to-transport- layer-defense-publication-coupling dimensions: (i) in-flight TLS-stripping attacker-bypass class (attacker MITM-strips STARTTLS offering from the SMTP greeting causing receiver-MTA to fall back to cleartext SMTP) defeated by MTA-STS mode:enforce or DANE TLSA-RR publication — the MTA-STS-vs-DANE spoke documents the per-publisher transport-layer TLS-enforcement- publication choice (MTA-STS mode:enforce publication commits the publisher to refuse cleartext fallback for every MTA-STS-aware sender-MTA; DANE TLSA-RR DNSSEC-anchored publication commits the publisher to refuse non-DANE-validating TLS-cert presentation) whose per-publisher transport-layer defense-publication is the load- bearing closure of the in-flight TLS-stripping attacker-bypass class THIS page documents; (ii) DNS-MX-redirection / cousin-MX attacker-bypass class (attacker hijacks DNS resolution or publishes look-alike-MX records causing receiver-MTA to deliver to attacker-controlled MX) defeated by DANE TLSA-RR DNSSEC-anchored per-MX cryptographic- attestation or MTA-STS HTTPS- policy-host MX-pattern-list publication — the MTA-STS-vs-DANE spoke documents the per-publisher per-MX transport-layer publication- discipline (DANE cryptographically anchors the per-MX TLSA-RR via DNSSEC-signed zone; MTA-STS publishes the per-policy-id MX-pattern-list at the HTTPS-CA- anchored policy-host) whose per-publisher publication- attestation defeats the DNS-MX- redirection attacker-bypass class THIS page documents; (iii) transport-layer-mail-flow injection-at-MX attacker-bypass class (attacker injects mail directly at the recipient MX without first authenticating against the publisher's transport- layer enforcement-publication) defeated by MTA-STS mode:enforce or DANE-validating SMTP-recipient-MTA — the MTA-STS-vs-DANE spoke documents how the publisher's per-domain transport-layer enforcement-publication choice (MTA-STS-aware-MTA enforces per-MX-pattern + HTTPS-CA-trust; DANE-validating-MTA enforces per- MX-TLSA-RR cryptographic-anchor) is the publisher-side defense- publication the receiver-MTA consumes to refuse the transport-layer-injection attacker-bypass class THIS page catalogues; (iv) per- publisher per-domain transport- layer-defense-publication-AS- COMPLEMENT-TO-DMARC-MESSAGE- LAYER-DEFENSE-PUBLICATION: DMARC's p=reject publication closes the message- layer attacker-bypass classes (alignment-evasion, signing- infrastructure evasion, weak- configuration exploitation) THIS page catalogues, BUT cannot close the transport-layer attacker-bypass classes that MTA-STS-or-DANE closes — the MTA- STS-vs-DANE spoke documents the per-publisher transport- layer defense-publication choice whose per-publisher publication-discipline is the load-bearing complement to the DMARC message-layer publication-discipline, closing the transport-layer-half of the cross-layer attacker-bypass defense surface THIS page catalogues. Read THIS page when ENUMERATING the attacker- bypass classes against a publisher's per-domain DMARC deployment; read the MTA-STS- vs-DANE spoke when AUTHORING the per-publisher per-domain transport-layer-defense- publication choice that closes the transport-layer-half of the cross-layer attacker- bypass defense surface this page enumerates.
• MTA-STS explained — the transport-layer SMTP-TLS-policy-enforcement companion — the per-publisher transport-layer attacker-bypass-closure companion to this DMARC attacker-bypass catalogue. Where THIS page enumerates the application-layer attacker-bypass classes a publisher's DMARC + SPF + DKIM stack still leaves open (lookalike domains, homograph attacks, DKIM l= body-length-tag exploits, ARC-chain forgery, subdomain takeover, compromised legitimate-sender accounts), the MTA-STS pillar documents the per- publisher transport-layer-defense publication discipline (RFC 8461 mode=enforce policy file + _mta-sts TXT version pointer + per-MX-host allow- list) that CLOSES the in-transit TLS- stripping + MITM-downgrade + lookalike- MX-host attacker-bypass classes the message-layer DMARC stack THIS page catalogues CANNOT close. Read THIS page when enumerating the application- layer attacker-bypass classes against a publisher's DMARC deployment; read the MTA-STS pillar when authoring the transport-layer attacker-bypass closure primitive that complements the message- layer enforcement the bypass classes catalogued here exploit gaps in.
• DMARC for shared hosting — the PER-TENANT-SHARED- INFRASTRUCTURE-ATTACK-SURFACE- AMPLIFICATION companion to this DMARC-attacker-bypass operator reference. Where THIS page catalogues the canonical DMARC- bypass class taxonomy (§4 lookalike domain registration, §5 configuration weakness exploitation, §6 protocol- level evasion, §7 compromised-account BEC), the shared-hosting spoke is the per-provider-deployment-execution companion documenting FOUR shared- hosting-attacker-bypass coordination dimensions whose per-tenant satisfaction gates the per-tenant exposure to the bypass classes THIS page catalogues: (i) per-tenant subdomain- enumeration attack surface is STRUCTURALLY AMPLIFIED across the per-provider shared DNS zone topology — Plesk's, DirectAdmin's, ISPConfig's, Webmin / Virtualmin's, and CentOS Web Panel's per-panel control over shared DNS zones creates a per-provider per-tenant per-subdomain attack-surface enumeration target whose §5 configuration-weakness exposure scales with the number of tenants the provider hosts; the shared- hosting spoke documents the per- panel subdomain policy-publication discipline (per-tenant explicit _dmarc.<subdomain> publication, organizational sp= tag inheritance discipline) that bounds the attacker's per-tenant subdomain-enumeration return; (ii) per-tenant cross-tenant compromised-account exploitation via the shared outbound MTA is the per-provider-amplified §7 BEC vector — when an attacker compromises one tenant's webmail credentials on a shared- hosting deployment, the per-tenant outbound MTA's shared-relay boundary lets the attacker authenticate as the compromised tenant AND impersonate other tenants' From-domains (the §7 BEC class) by exploiting per- tenant DKIM-signing-key sharing; the shared-hosting spoke documents the per-panel per-tenant DKIM- signing-key isolation discipline that bounds the §7 BEC blast radius; (iii) per-tenant dangling-DNS subdomain-takeover attack-surface via abandoned per-tenant subdomains amplifies §5.6 subdomain-takeover — when a per-tenant CNAME at the provider-managed shared zone points to a no-longer-provisioned per-tenant resource (abandoned Plesk subscription, deleted DirectAdmin user, paused ISPConfig account), the dangling CNAME exposes the §5.6 subdomain- takeover bypass class catalogued on THIS page; the shared-hosting spoke documents the per-panel per-tenant lifecycle-cleanup discipline (the per-panel zone- record-purge cadence on account deletion) that prevents the per-tenant CNAME from becoming the §5.6 takeover target; (iv) per- tenant policy-publication gaps where unauthored subdomains inherit relaxed parent posture weaken the per-tenant DMARC enforcement contract — when a per-tenant operator publishes _dmarc.<domain> TXT at p=reject but leaves the organisational sp= tag at the default sp=none, every unauthored per-tenant subdomain inherits the relaxed posture and exposes the §5 configuration- weakness bypass class; the shared- hosting spoke documents the per- panel per-tenant sp=-tag publication discipline that closes the unauthored-subdomain bypass gap. Read the shared-hosting spoke ALONGSIDE this attacker-bypass reference whenever the operator scopes the per-tenant DMARC- bypass exposure attribution on Plesk / DirectAdmin / ISPConfig / Webmin-Virtualmin / CWP — the bypass class taxonomy THIS page catalogues IS the per-tenant per- message attack-vector primitive the shared-hosting deployment guide encodes the per-provider per-tenant mitigation execution discipline for.
• DMARC for Google Workspace — the WORKSPACE-TENANT-DMARC- DEPLOYMENT-DISCIPLINE companion to this 22-class per-publisher per- domain DMARC-evaluation-bypass classification framework. Where THIS page documents the 22-technique per- publisher per-domain attacker-bypass class catalogue (§4 lookalike-domain registration, §5 configuration- weakness inheritance, §6 alignment- edge exploitation, §7 BEC-via-valid- accounts), the Workspace-deployment spoke is the WORKSPACE-TENANT EXECUTION-SURFACE COMPANION documenting how each per-publisher per-domain bypass class instantiates concretely on per-tenant Google Workspace at FOUR per-Workspace- tenant-Admin-Console-configuration-vs- DMARC-bypass-class-execution-surface dimensions: (i) per-Workspace- tenant per-domain DMARC publication at the Admin Console DMARC-authoring boundary is the per-Workspace-tenant execution surface for §5 configuration- weakness bypass class — the Workspace-deployment spoke documents how the per-tenant Admin Console DMARC- authoring UI exposes the p=, sp=, pct=, adkim=, aspf= tags whose publication discipline determines whether the per-tenant per-domain publication exhibits the §5 configuration-weakness bypass class (default sp=none inheritance, relaxed-alignment-mode exploitation, pct<100 partial-enforcement bypass); (ii) per-Workspace-tenant per- organisational-domain sp=-tag publication is the per-Workspace-tenant execution surface for the unauthored-subdomain- inheritance bypass class — the Workspace-deployment spoke documents how the per-tenant per- organisational-domain sp=-tag authoring at the Admin Console publishes-or-omits the per-organisational-domain subdomain- policy discipline THIS page catalogues as the unauthored-subdomain-inheritance bypass primitive every per-publisher per-domain operator must explicitly author to close; (iii) per- Workspace-tenant per-domain ramp discipline at the Admin Console is the per-Workspace-tenant execution surface for the partial-enforcement attacker- bypass exploitation window — the Workspace-deployment spoke documents how the per-tenant ramp discipline (p=none → p=quarantine → p=reject at incremental pct= stages) creates the per-publisher per-domain partial- enforcement window THIS page catalogues as the timing-window bypass primitive attackers exploit during prolonged p=none / p=quarantine deployments; and (iv) per-Workspace-tenant per-domain rua/ruf telemetry authoring is the per-Workspace-tenant execution surface for the per-class bypass detection-and-attribution discipline — the Workspace- deployment spoke documents how the per-tenant rua/ruf authoring at the Admin Console produces the per- publisher per-domain aggregate- evidence stream the per-tenant operator uses to detect each of the 22 bypass classes THIS page catalogues in operational practice (per-source- IP per-day per-class signature attribution). Read the Workspace- deployment spoke ALONGSIDE this attacker-bypass reference whenever the per-Workspace-tenant operator scopes the per-tenant per-domain DMARC-deployment posture against the 22-class bypass-class catalogue — the bypass-class catalogue THIS page documents is the per-publisher per- domain ATTACKER-PRIMITIVE; the per- Workspace-tenant Admin Console DMARC-deployment posture is the per- publisher per-domain DEFENDER- EXECUTION primitive that closes the per-class bypass-class exposure.
• Email Header Analyzer — paste any email's headers and see the per-message SPF, DKIM, DMARC, and alignment results; surfaces DKIM l= tag, ARC chain, and homograph From: domains.
• Domain Security Checker — live DNS lookups for SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT, CAA, and DNSSEC via includes/DnsChecker.php; surfaces every §5 configuration weakness.
• DNS Record Generator — wizards for DMARC, SPF, DKIM, BIMI, MTA-STS, TLS-RPT, and CAA records that produce records free of the §5 and §6 weakness classes.
• MITRE ATT&CK T1566 — Phishing — the canonical attacker taxonomy this page maps onto.
• DKIM selectors explained — the PER-SELECTOR-DKIM-PUBLICATION-AND- ROTATION-DISCIPLINE-AS-LOAD-BEARING- ANTI-REPLAY-AND-ANTI-COMPROMISED-KEY- ATTACKER-BYPASS-MITIGATION companion to this attacker-bypass catalogue. Where THIS page documents the §6 DKIM-replay attacker-bypass technique (the attacker captures a legitimate per-publisher per- message DKIM-signed envelope, harvests the DKIM-Signature header, and replays the captured envelope through an attacker-controlled relay) AND the §5 compromised-signing-key attacker-bypass technique (the attacker extracts the per- publisher per-selector private key from a compromised egress host and signs arbitrary envelope content from attacker-controlled infrastructure), the DKIM-selectors spoke documents the per-publisher per-domain per-selector publication discipline that STRUCTURALLY MITIGATES BOTH attacker- bypass technique sub-classes — the per- selector overlap-window rotation cadence BOUNDS the per-message DKIM-replay window to the per-selector key-rotation cycle time, the per-selector revocation-via- empty-p= primitive WITHDRAWS a leaked or compromised per-selector private key within DNS-propagation latency, and the per-selector key-material isolation across sender-cohorts BOUNDS the per-publisher per-domain per-selector compromised-key blast-radius to the per-cohort signing scope. Pair THIS attacker-bypass catalogue WITH the DKIM-selectors spoke when AUTHORING the per-publisher per-domain per-selector publication-and-rotation runbook whose cadence integrity is the LOAD-BEARING anti-replay-and-anti- compromised-key control surface every per-publisher per-domain DMARC enforcement ramp STRUCTURALLY DEPENDS on for the per- message DKIM-aligned-pass-rate floor that gates the §6 / §5 attacker-bypass technique mitigation outcomes THIS page catalogues.
• DMARC for cPanel — the PER-CPANEL-TENANT-PER-DOMAIN-DMARC- DEPLOYMENT-AS-LOAD-BEARING-ATTACKER- BYPASS-MITIGATION-CONTROL-SURFACE companion to this attacker-bypass catalogue. Where THIS page catalogues the §4 lookalike-domain registration, §5 compromised-signing-key, §6 DKIM- replay, §7 valid-account-compromise BEC attacker-bypass technique sub-classes, the cPanel deployment guide documents the control-panel-operator-facing instantiation of the per-tenant per- domain authentication-and-enforcement discipline that STRUCTURALLY MITIGATES each catalogued attacker-bypass technique at the per-cPanel-tenant per-domain deployment boundary — the per-cPanel- tenant per-domain SPF authorisation of the cPanel-server outbound IP bounds the per-tenant per-domain SPF spoofing surface at the cPanel-server egress scope, the cPanel-managed default._domainkey selector publication discipline bounds the per- tenant per-domain DKIM-replay window to the cPanel-emitted per-selector rotation cadence, and the per-tenant per-domain DMARC TXT publication at _dmarc.<tenant-domain> through the WHM/cPanel Email Deliverability UI's p=quarantine / p=reject commitment is the LOAD-BEARING per-tenant per-domain attacker-bypass enforcement primitive every catalogued attacker-bypass technique mitigation outcome at the per-cPanel-tenant per-domain scope STRUCTURALLY DEPENDS on. Pair THIS attacker-bypass catalogue WITH the cPanel deployment guide when AUTHORING per-cPanel-tenant per-domain attacker- bypass-mitigation runbooks whose per- tenant per-domain authentication-and- enforcement discipline must execute through the WHM/cPanel Email Deliverability control-panel UI's operator-facing workflow surface.
• DNS propagation timelines — the TTL-bounded publish-and-verify-cycle primitive whose four DNS-propagation-vs- DMARC-attacker-bypass-technique-class coupling dimensions THIS attacker-bypass defender's red-team catalogue materially depends on: (i) §5.6 subdomain- takeover (dangling CNAME against a deprovisioned per-publisher per-subdomain cloud-platform endpoint AzureWebsites / Heroku / S3 / GitHub Pages target) STRUCTURALLY REQUIRES the per-publisher per-subdomain CNAME-record TTL window for the attacker to register the released third-party identifier AND for per-receiver per-resolver caches to converge on the attacker-controlled resolution before the attacker can emit spoofed mail aligned to the takeover target — the per- publisher per-subdomain CNAME-record TTL directly governs the per-subdomain attacker-takeover-window the defender's per-publisher per-domain subdomain- inventory-audit runbook must enumerate against every per-publisher per-subdomain CNAME-record published in the per-publisher per-domain authoritative zone; (ii) §4.3 lookalike-domain registration + §4.4 typo-squat-domain registration (MITRE ATT&CK T1583.001 Acquire Infrastructure: Domains) STRUCTURALLY REQUIRES the attacker to publish SPF + DKIM + DMARC records on the registered lookalike- domain AND wait for the publication-domain- side propagation tail before initiating the spoofing campaign — the attacker's per-publisher per-domain publication- propagation-tail latency is a load-bearing attacker-side operational-tempo constraint the defender's per-publisher per-domain lookalike-domain-monitoring runbook can exploit by detecting the lookalike-domain's SPF + DKIM + DMARC TXT-record publication BEFORE the propagation-tail completes; (iii) §7.1 MITRE ATT&CK T1078 Valid Accounts (BEC compromised legitimate account) post-detection per-publisher per- domain DKIM emergency key-rotation via empty-p= revocation propagation cycle STRUCTURALLY CONSUMES the RFC 2308 negative-cache window before per-receiver per-resolver caches expire the revoked public-key TXT record — the per- publisher per-domain incident-response runbook's emergency DKIM-revocation cycle latency is directly bounded by the per- receiver per-resolver negative-cache TTL the per-publisher per-domain authoritative- zone-owner publishes, defining a per- publisher per-domain incident-response- latency floor against the BEC attacker's compromised-private-key replay window; (iv) §3.x CACHE-POISONING-AS- ATTACKER-BYPASS (DNS cache-poisoning against a per-receiver per-resolver caching layer injecting attacker-controlled SPF + DMARC TXT-record values into per-receiver per-message authentication-verdict computation) STRUCTURALLY EXPLOITS the per-receiver per-resolver cache TTL window across which the poisoned record persists in the resolver cache — DNSSEC-validation gate on the per- publisher per-domain authoritative zone is the structurally-canonical cache- poisoning defense, but the per-receiver per-resolver caching-layer DNSSEC- validation enablement state is OUTSIDE the per-publisher per-domain operator's control — defining a per-publisher per-domain attacker-side cache-poisoning-attack-window the defender's per-publisher per-domain DNSSEC-publication-discipline runbook narrows but cannot fully close. Read the DNS-propagation timelines spoke alongside this attacker-bypass defender's red-team catalogue when authoring the per-publisher per-domain subdomain-takeover-audit runbook (§5.6), when monitoring the per-publisher per-domain lookalike-domain-registration propagation-tail attacker-side operational- tempo signal (§4.3 + §4.4), when planning the per-publisher per-domain BEC-incident- response DKIM-emergency-revocation cycle latency budget (§7.1), or when authoring the per-publisher per-domain DNSSEC- publication-discipline runbook against the per-receiver per-resolver cache-poisoning- attack-window (§3.x).
• DKIM for Microsoft 365
• DKIM for Google Workspace
• MITRE ATT&CK T1583.001 — Acquire Infrastructure: Domains — lookalike domain registration referenced in §4.3.
• MITRE ATT&CK T1584 — Compromise Infrastructure — subdomain takeover referenced in §5.6.
• MITRE ATT&CK T1078 — Valid Accounts — compromised legitimate accounts (BEC) referenced in §7.1.
• RFC 7489 — DMARC — the canonical DMARC specification.
• RFC 7208 — SPF
• RFC 6376 — DKIM
• RFC 8617 — ARC
• RFC 8301 — DKIM crypto update — deprecates DKIM keys smaller than 1024 bits, recommends 2048+.
• RFC 5322 — Internet Message Format (From: header)
• Microsoft SNDS + JMRP monitoring — outbound abuse from compromised accounts or infrastructure surfaces first as spam-trap hits and Junk-click complaints: Microsoft's SNDS filter verdicts and JMRP ARF stream are an early-warning channel for your own sending IPs.

13. Audit your DMARC deployment against the attacker bypass surface

DMARC Analyzer is the operator console for surfacing the §10 indicators and §5 configuration weaknesses documented above. The dashboard ingests DMARC aggregate (RUA) and forensic (RUF) reports via includes/DmarcParser.php and includes/ForensicReportParser.php, rendering per-sender / per-IP / per-day authentication breakdowns that surface attacker activity. The Domain Security Checker runs live DNS lookups across SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT, CAA, and DNSSEC through includes/DnsChecker.php so every §5 configuration weakness can be verified record-by-record. The Email Header Analyzer at header_analyzer.php diagnoses individual message failures including DKIM l= tag presence, ARC chain validation, and homograph From: domains.

Sign up — Free plan Audit my DMARC against the bypass surface