DMARC Analyzer

TL;DR

• Email spoofing is the protocol-level forgery of one or more sender-identity fields in an email envelope or message header. It is the TECHNIQUE; phishing and Business Email Compromise (BEC) are downstream USES of the technique.
• Email is inherently spoofable because RFC 5321 (SMTP) and RFC 5322 (Internet Message Format) were designed in 1982 without sender authentication. SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) are bolted-on countermeasures added decades later.
• The seven canonical spoofing techniques are: direct domain spoofing (RFC 5322 From: forgery), envelope MAIL FROM spoofing (RFC 5321), display-name spoofing, lookalike-domain registration, IDN homograph (Unicode confusables), cousin-domain registration, and subdomain takeover via abandoned DNS.
• DMARC at p=reject blocks exactly ONE technique — direct domain spoofing. It does NOT block lookalike domains, display-name spoofing, IDN homographs, cousin domains, subdomain takeover, or any variant that originates from a domain technically distinct from yours.
• SPF authenticates the envelope From (RFC 5321 MAIL FROM) via SPF DNS records. DKIM authenticates the signing domain (RFC 6376 d= tag) via a cryptographic signature. DMARC enforces alignment between the visible From: header (RFC 5322) and the SPF or DKIM authenticated domain.
• The visible From: header is the field DMARC defends. Mail clients render this field as the "From" line; everything else (envelope sender, Reply-To, Sender: header, X-* headers) is invisible by default and not anchored by DMARC.
• The Authentication-Results header (RFC 8601) is the canonical forensic artifact for detecting spoofed mail at the receiver. Inspect the dmarc=, spf=, and dkim= fields and confirm header.from matches the visible From: domain.
• IDN homograph attacks use Unicode-confusable characters like Cyrillic а (U+0430) substituted for Latin a (U+0061). The on-wire DNS form is Punycode (xn--) but mail clients render the Unicode glyph indistinguishable from Latin in most fonts. Documented in Unicode Technical Standard 39 (UTS #39).
• Spoofing maps to MITRE ATT&CK techniques T1566 (Phishing), T1583.001 (Acquire Infrastructure: Domains), and T1036 (Masquerading) depending on the variant and downstream use.
• Defense-in-depth beyond DMARC requires brand-monitoring lookalike detection, secure-email-gateway anti-impersonation rules, display-name policies, external-sender tagging, recipient training, and phishing-resistant MFA on the recipient end to limit damage when spoofing succeeds.

1. What email spoofing is

Email spoofing is the protocol-level forgery of one or more sender-identity fields in an email message — typically the RFC 5322 From: header (the field your mail client renders as the "From" line) or the RFC 5321 MAIL FROM envelope sender (the field used for bounce delivery). The attacker takes advantage of the fact that the original Simple Mail Transfer Protocol (SMTP) — first standardised as RFC 821 in August 1982, currently in force as RFC 5321 — never required the sending MTA to prove that it was authorised to send mail on behalf of the domain it claimed. Likewise the Internet Message Format (RFC 5322, descended from RFC 822 from August 1982) defines the From: header as a freely- settable text field with no protocol-level verification.

Email spoofing is NOT the same as phishing or Business Email Compromise. Spoofing is the TECHNIQUE; phishing and BEC are downstream USES of the technique:

• Spoofing forges the apparent sender. A spoofed message may carry no malicious payload at all — pen-test exercises, spam, joke emails, and some forms of social activism use spoofing without phishing.
• Phishing uses social engineering against the recipient to extract credentials, financial data, or trigger malicious action. Phishing often (not always) uses spoofing to make the sender appear trustworthy. See help_dmarc_attacker_bypass.php for the 22-technique attacker catalogue.
• BEC uses spoofing or compromised accounts to commit financial fraud. See help_business_email_compromise.php for the standalone BEC operational playbook.

In MITRE ATT&CK T1036 (Masquerading) taxonomy email spoofing is one Masquerading technique among many. In T1566 (Phishing) it is the canonical delivery mechanism. In T1583.001 (Acquire Infrastructure: Domains) the lookalike / cousin / IDN-homograph variants are explicitly enumerated.

2. Why email is inherently spoofable

Email is inherently spoofable because the original protocols were designed without sender authentication. Every authentication mechanism in use today is bolted onto the original specification decades after the fact:

• 1982 — RFC 821 SMTP defines the MAIL FROM command. There is no verification step; any MTA can claim any envelope sender it likes.
• 1982 — RFC 822 Internet Message Format defines the From: header as a freely-settable text field. No verification.
• 2002 — Sender ID / SPF introduces DNS-based envelope-sender verification (current revision RFC 7208). Adoption was gradual; SPF alone is insufficient because it does not protect the visible From: header.
• 2007 — DKIM adds cryptographic message signing (RFC 6376). DKIM proves a message was signed by the domain in the d= tag of the signature, but nothing in the protocol requires that domain to match the visible From: header.
• 2008 — RFC 5321 / RFC 5322 updated SMTP and IMF without changing the underlying lack of authentication.
• 2012 — Authentication-Results header (RFC 7001, current revision RFC 8601) standardises how the receiver records its SPF / DKIM verdict for downstream consumers (filters, users, forwarders). This is the canonical forensic artifact for spoofing detection — see section 8.
• 2015 — DMARC (RFC 7489) ties SPF and DKIM to the visible From: header by requiring alignment, finally giving domain owners a way to assert policy over the From: header rendering.

The cumulative result: any sending MTA can construct an SMTP transaction claiming an arbitrary From: header and an arbitrary envelope sender. The receiving MTA decides whether to accept the message based on SPF, DKIM, and DMARC verification AGAINST DNS records published by the claimed sender — but those records are voluntary; a domain owner who publishes no SPF / DKIM / DMARC records has no protocol-level defense against spoofing.

Publishing DMARC at p=reject with aligned SPF and DKIM is the foundational defense against direct domain spoofing. See help_dmarc_records_explained.php for the tag-by-tag DMARC record reference and help_dmarc_policy_rollout.php for the operational rollout playbook from p=none through p=quarantine to p=reject.

3. The seven canonical spoofing techniques

Email spoofing decomposes into seven canonical techniques. Each technique forges a different identity field or exploits a different DNS-level weakness. Defenses differ per technique — DMARC defeats only direct domain spoofing; the other six require additional controls.

3.1 Direct domain spoofing (RFC 5322 From: header forgery)

Technique: The attacker forges the RFC 5322 From: header to read an address at the victim's domain without controlling the victim's domain.

How it works: The attacker controls a sending MTA (e.g. an open relay, a compromised host, a self-hosted Postfix instance on a residential IP, or a bulletproof- hosted SMTP service). The attacker constructs an SMTP transaction that sets the From: header to ceo@victim.example. If the victim has not published SPF or DMARC, the receiving MTA has no protocol-level reason to reject the message — it lands in the recipient inbox as if sent from the victim domain.

What it forges: The RFC 5322 From: header (the visible "From" line in the mail client).

Defender countermeasure: DMARC at p=reject with aligned SPF or DKIM blocks this technique completely. The receiver looks up the victim domain's DMARC record (_dmarc.victim.example), confirms p=reject, then verifies that either SPF or DKIM authentication passes AND aligns with the victim domain. If both fail or neither aligns, the receiver rejects the message at the SMTP transaction (or quarantines it under p=quarantine). This is the ONE spoofing technique DMARC stops.

3.2 Envelope MAIL FROM spoofing (RFC 5321)

Technique: The attacker spoofs the RFC 5321 envelope sender (MAIL FROM) — the bounce-handling address used during SMTP.

How it works: The attacker issues an SMTP command MAIL FROM:<arbitrary@victim.example> before the DATA phase. The envelope sender is used for bounce delivery — if the message bounces, the bounce goes to that address. The envelope sender is invisible to the recipient (most mail clients show only the From: header from the DATA phase, not the envelope From).

What it forges: The RFC 5321 5321.MailFrom envelope sender.

Defender countermeasure: SPF authenticates the envelope From against the SPF DNS record published by the claimed envelope-From domain. If the sending IP is not authorised by the SPF record, the receiver may reject the message (per RFC 7208 Section 8 — the SPF record's -all / ~all / ?all qualifier dictates the receiver action). Note: SPF protects the envelope sender, not the visible From: header. An attacker can pass SPF with an envelope-From at attacker.example while setting the visible From: header to ceo@victim.example — DMARC's job is to require alignment between the two so that this divergence trips DMARC rejection.

3.3 Display-name spoofing

Technique: The attacker puts the impersonated person's name in the display-name portion of the From: header while using a free-webmail or attacker- controlled From: address.

How it works: The From: header has the syntax "Display Name" <email@example.com>. The attacker constructs From: "CEO Name" <ceoname.urgent2024@gmail.com>. Most mail clients render the display name prominently and hide the full email address by default — particularly on mobile clients where screen real-estate is limited. The recipient sees "CEO Name" in their inbox and rarely expands to inspect the underlying address.

What it forges: The display-name portion of the From: header (a free- text field with no protocol-level verification).

Defender countermeasure: NOT blocked by SPF / DKIM / DMARC because the From: domain is technically attacker-controlled (gmail.com, in the example) and legitimately passes its own DMARC. Defense layers: secure-email-gateway display-name impersonation rules (alert when display name matches a VIP roster but sender address is external), executive-name watchlists, mandatory "External Sender" tagging on inbound mail, and recipient training to verify the full From: address before acting on a message. See section 10 for the defense-in-depth stack.

3.4 Lookalike-domain registration

Technique: The attacker registers a domain that LOOKS like the victim domain but is technically distinct (different characters, different TLD, or different word combination), then sends from that attacker-controlled domain.

How it works: The attacker registers victim-corp.example, vvictim.example, v1ctim.example (numeric 1 substituted for letter i), victim.com.fr, or similar typosquat / cousin variants. The attacker publishes valid SPF, DKIM, and DMARC for the attacker-controlled domain so the message passes authentication with green checkmarks. The visible From: address looks legitimate at a glance because the rendered domain is visually similar to the target.

What it forges: The visible From: address by EXPLOITING visual similarity rather than forging anything at the protocol level — the attacker domain is real, owned by the attacker, and properly authenticated.

Defender countermeasure: NOT blocked by victim-domain DMARC because the attacker controls a genuinely distinct domain. Defense layers: brand-monitoring services (Cybercrime Information Center, Spamhaus DBL, PhishTank, or commercial vendors like Recorded Future / DomainTools / RiskIQ), defensive registrations of high-risk variants (paypal.com owners typically register paypa1.com, paypl.com, and major TLD variants), secure-email-gateway anti-impersonation rules that flag inbound mail from domains within a configurable edit-distance of the victim's domain, and recipient training to read the From: domain character-by-character. MITRE ATT&CK technique T1583.001 (Acquire Infrastructure: Domains).

3.5 IDN homograph (Unicode confusables)

Technique: The attacker registers an Internationalised Domain Name (IDN) using Unicode characters from non-Latin scripts that are visually confusable with Latin characters.

How it works: The attacker registers vіctim.example using Cyrillic і (U+0456) instead of Latin i (U+0069). At the DNS level the domain serialises to Punycode form (xn--vctim-eog.example) but mail clients render the Unicode form and the rendered glyphs are visually indistinguishable in most sans-serif fonts. Canonical Unicode confusables documented in Unicode Technical Standard 39 (UTS #39: Unicode Security Mechanisms):

• Cyrillic а (U+0430) vs Latin a (U+0061)
• Cyrillic е (U+0435) vs Latin e (U+0065)
• Cyrillic о (U+043E) vs Latin o (U+006F)
• Cyrillic р (U+0440) vs Latin p (U+0070)
• Cyrillic с (U+0441) vs Latin c (U+0063)
• Cyrillic у (U+0443) vs Latin y (U+0079)
• Greek ο (omicron, U+03BF) vs Latin o (U+006F)
• Greek ν (nu, U+03BD) vs Latin v (U+0076)

What it forges: Visual similarity at the rendered-glyph layer, not the protocol layer. The IDN domain is real and properly registered.

Defender countermeasure: NOT blocked by victim-domain DMARC because the spoof domain is technically distinct. Defense layers: brand-monitoring services that specifically watch for IDN-confusable registrations against the victim's trademark, secure-email-gateway rules that flag inbound mail with non-ASCII characters in the From: domain or with Punycode (xn--) in the raw From: header, recipient training that includes the canonical confusables list, and (where feasible) defensive registration of the highest-risk IDN variants. Modern browsers implement Punycode- display rules that show xn-- in the address bar for suspected IDN spoofs; few mail clients implement the equivalent rule. The DMARC Analyzer Email Header Analyzer (header_analyzer.php) surfaces Punycode-form domain names in the raw header inspection.

3.6 Cousin-domain registration

Technique: The attacker registers a domain that combines the victim brand with an additional legitimate-sounding word or different TLD.

How it works: Common cousin-domain patterns: paypal-security.com, paypal-support.com, paypal- login.com, paypal-verify.com, microsoft-account.com, amazon-prime.support, brand.online, brand.help. The attacker chooses words operators and customers expect to see in the victim's legitimate domain ecosystem (support, security, login, billing, account). The attacker publishes valid SPF / DKIM / DMARC for the cousin domain so authentication passes cleanly.

What it forges: Brand association at the semantic layer. The cousin domain is real, owned by the attacker, and properly authenticated.

Defender countermeasure: NOT blocked by victim-domain DMARC. Defense layers: same as lookalike-domain registration (3.4) PLUS specifically monitor for trademark-plus-word permutations across all TLDs. The search space is much wider than pure typosquat detection — a brand like "paypal" has dozens of plausible cousin combinations (paypal-X, paypalX, X-paypal, paypal.TLD) across thousands of TLDs. Commercial brand-monitoring vendors specialise in this scan.

3.7 Subdomain takeover via abandoned DNS

Technique: The attacker claims an orphaned subdomain CNAME pointing to a cloud-service hostname that the victim has abandoned, then sends mail from the now-attacker-controlled subdomain of the victim's real domain.

How it works: The victim creates marketing.victim.example as a CNAME pointing to victim-prod.cloudservice.example.com. Later the victim cancels the cloud-service subscription but does NOT remove the CNAME from DNS. The cloud service eventually releases the hostname for reuse. An attacker re-registers victim-prod.cloudservice.example.com at the same cloud service, gains control of any content served at the hostname, AND now controls marketing. victim.example for the purposes of inbound HTTP, outbound email (if the abandoned CNAME pointed at a transactional-email service), and SSL/TLS certificate issuance (because most ACME challenges resolve via HTTP).

What it forges: Nothing — the attacker legitimately controls a real subdomain of the victim's domain via DNS misconfiguration on the victim's side. The subdomain's mail passes ANY victim-domain DMARC (sp= or default inheritance) because it IS a real subdomain of the victim.

Defender countermeasure: NOT blocked by DMARC because the spoofed sender IS a real subdomain of the victim domain. Defense layers: DNS hygiene (automated audits of CNAMEs that resolve to dangling third-party hostnames), explicit DMARC sp=reject at the apex to deny p=none inheritance for subdomains, and the sp=reject DMARC tag for any orphaned subdomain. See help_dmarc_records_explained.php for the sp= tag definition and help_dmarc_attacker_bypass.php §5.6 for the canonical subdomain-takeover attack catalog entry.

4. How SPF defends against spoofing

Sender Policy Framework (SPF) defined by RFC 7208 authenticates the RFC 5321 envelope From (MAIL FROM) by publishing a list of authorised sending IPs in a DNS TXT record. The receiver looks up the SPF record of the envelope- From domain, walks its mechanisms (ip4, ip6, a, mx, include, exists, ptr), and authorises the sending IP if any mechanism matches.

What SPF defends: envelope MAIL FROM spoofing (technique 3.2). A sender connecting from an unauthorised IP and claiming MAIL FROM:<sender@spf-protected.example> is rejected by the receiver under -all / ~all qualifiers.

What SPF does NOT defend: Direct domain spoofing of the visible From: header (technique 3.1). SPF authenticates the ENVELOPE From, not the visible From: header — an attacker can pass SPF for an envelope-From at attacker.example while setting the visible From: header to ceo@victim.example. DMARC's alignment requirement closes this gap by demanding that the SPF-authenticated envelope-From domain match the visible From: header domain (under either strict or relaxed alignment per RFC 7489 §3.1).

SPF gotchas: the RFC 7208 §4.6.4 10-DNS-lookup limit (permerror if exceeded) is the canonical operational pitfall — see help_spf_lookup_limit.php for the deep dive on flattening, SPF macro abuse, and the void-lookup limit. Forwarding breaks SPF because the forwarder's IP is not in the original sender's SPF record; ARC (RFC 8617) is the forwarding-survival workaround — see help_arc_explained.php.

For the full SPF deep dive see help_spf_explained.php.

5. How DKIM defends against spoofing

DomainKeys Identified Mail (DKIM) defined by RFC 6376 cryptographically signs selected message headers and (optionally) the message body using a private key held by the signing domain. The signing domain is identified by the d= tag in the DKIM-Signature header. The receiver looks up the public key in DNS at selector._domainkey.signing-domain.example and verifies the signature over the canonicalised headers and body.

What DKIM defends: message integrity AND sender-domain attribution. DKIM proves the message was signed by an entity controlling the private key for the d= domain — an attacker cannot forge a valid DKIM signature without the private key (typically 2048-bit RSA per RFC 8301; deprecated 1024-bit keys are factorable per the canonical DUH attack). Properly-rotated DKIM keys defeat replay attacks on old signatures (see help_dkim_replay_attacks.php).

What DKIM does NOT defend: direct domain spoofing of the visible From: header. DKIM authenticates the d= signing domain, not the From: header — an attacker can sign with a key for attacker.example and set the From: header to ceo@victim.example. DMARC's alignment requirement closes this gap by demanding that the d= signing domain match the visible From: header domain.

DKIM gotchas: body-hash mismatches break DKIM when a forwarder or mailing-list adds a footer; the l= tag (length-limited body hash) creates an attacker window where the attacker can append content after the signed prefix. See help_dkim_explained.php for the canonical DKIM pillar and help_dkim_cryptography_basics.php for the cryptographic-primitives deep dive.

6. How DMARC defends against spoofing

Domain-based Message Authentication, Reporting, and Conformance (DMARC) defined by RFC 7489 ties SPF and DKIM to the visible From: header by requiring alignment: the domain of the visible From: header must match either the SPF-authenticated envelope-From domain (SPF alignment) or the DKIM-authenticated d= domain (DKIM alignment). DMARC defines two alignment modes (strict and relaxed) and a policy (none / quarantine / reject) that the receiver applies when both SPF and DKIM fail to align.

What DMARC defends: direct domain spoofing of the visible From: header (technique 3.1). With DMARC at p=reject and properly published SPF + DKIM, the receiver rejects any message whose visible From: header claims your domain but whose SPF and DKIM do not align. This is the protocol-level victory DMARC was designed to deliver.

What DMARC does NOT defend: any spoofing variant where the visible From: header is at a DIFFERENT domain than yours — lookalike, IDN homograph, cousin domain, display-name, subdomain takeover, BEC via compromised legitimate accounts, and any variant that originates from a properly-authenticated attacker-controlled domain. DMARC's scope is narrow by design: it asserts policy over your domain's From: header rendering, not over the universe of spoofable identity fields. The five-variant DMARC gap is documented in detail in section 7.

The DMARC alignment subtleties: strict vs relaxed alignment, the organizational-domain inheritance per RFC 7489 §3.2, the sp= tag for subdomains, and the pct= sampling for rollout — see help_dmarc_alignment.php and help_dmarc_records_explained.php.

For the operational rollout from p=none through p=quarantine to p=reject without breaking legitimate sending, see help_dmarc_policy_rollout.php.

7. What DMARC does NOT prevent

DMARC at p=reject — even with full SPF and DKIM alignment, perfect DNS hygiene, and 100% reporting coverage — does NOT prevent the following spoofing variants. Operators deploying DMARC must understand these gaps to size additional control layers appropriately.

• Lookalike-domain spoofing. Attacker registers victim-corp.example and sends with valid DMARC for the attacker domain. Defense: brand-monitoring + SEG anti-impersonation. See technique 3.4.
• Display-name spoofing. Attacker sends from ceoname.urgent@gmail.com with display name "CEO Name". DMARC passes for gmail.com. Defense: SEG display-name impersonation rules + executive-name watchlists. See technique 3.3.
• IDN homograph attacks. Attacker registers vіctim.example using Cyrillic і. Defense: brand-monitoring for IDN confusables + Punycode-form inspection. See technique 3.5.
• Cousin-domain spoofing. Attacker registers paypal-security.com. Defense: trademark-plus-word permutation monitoring + recipient training. See technique 3.6.
• Subdomain takeover via abandoned DNS. Attacker claims an orphaned CNAME pointing to an abandoned cloud-service hostname. The takeover happens via DNS misconfiguration on the victim's side; the attacker now controls a real subdomain of the victim. Defense: DNS hygiene audits + sp=reject at the apex. See technique 3.7.
• BEC via compromised legitimate accounts. Attacker steals credentials of a real employee and sends mail from inside the organisation; DMARC, SPF, and DKIM all pass cleanly. Defense: phishing-resistant MFA + anomalous-login detection + payment-process out-of-band verification. See help_business_email_compromise.php.
• Vendor Email Compromise (VEC). Attacker compromises a real mailbox at one of the victim's vendors; mail comes from the real vendor with valid authentication. Defense: bank-account-change out-of-band verification + supplier- master-data tight-change controls. See help_business_email_compromise.php §2.6.
• Out-of-band channels. The attacker bypasses email entirely — SMS, voice calls, Microsoft Teams chat, WhatsApp, LinkedIn DMs. DMARC has no role. Defense: same-channel verification policies + payment-process controls.

For the defender-perspective debunking of "DMARC stops phishing" and other common DMARC myths see help_dmarc_myths_and_misconceptions.php. For the attacker-perspective catalog of 22 concrete bypass techniques see help_dmarc_attacker_bypass.php.

8. Detecting a spoofed email

The forensic detection workflow uses the Authentication-Results header (RFC 8601) plus visual inspection of the rendered message. The Authentication-Results header is inserted by the receiving MTA recording its SPF / DKIM / DMARC verdict on the message; downstream filters and users consume the verdict without re-running the verification.

Step 1 — View raw headers

The mail client must reveal the raw message headers. Per-client steps:

• Outlook (desktop): Open the message in its own window (double-click). File > Properties > Internet headers.
• Outlook (web): Open the message. ... menu (top right) > View > View message source.
• Gmail: Open the message. ... menu (top right of the message) > Show original. The resulting tab shows headers and the raw message body.
• Apple Mail: Open the message. View > Message > Raw Source (Option+Cmd+U).
• Thunderbird: Open the message. View > Message Source (Ctrl+U).

Step 2 — Find the Authentication-Results header

The header looks like this (whitespace varies; the header may span multiple lines via RFC 5322 folding):

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=20240101 header.b=AbCdEfGh;
       spf=pass (google.com: domain of bounce-handling@example.com designates 198.51.100.1 as permitted sender) smtp.mailfrom=bounce-handling@example.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Read the three verdict fields and the header.from field:

• spf= records the SPF result: pass / fail / softfail / neutral / none / temperror / permerror per RFC 7208 Section 8. The smtp.mailfrom field shows the envelope sender that was checked.
• dkim= records the DKIM result: pass / fail / none. The header.d field shows the signing domain.
• dmarc= records the DMARC verdict combining SPF and DKIM with alignment. The header.from field shows the visible From: domain that the verdict applies to.

Step 3 — Cross-check header.from against visible From:

The header.from domain in the dmarc= field MUST match the visible From: address you expected. Mismatch is the canonical spoofing signature. Examples:

• Visible From: CEO <ceo@example.com> with header.from= example.com and dmarc=pass → legitimate (or successful spoof bypass via misconfigured DMARC).
• Visible From: CEO <ceo@example.com> with header.from= example.com and dmarc=fail → spoof detected at the receiver, message should have been quarantined or rejected; investigate why it landed in the inbox.
• Visible From: CEO <ceo@example.com> with header.from= evil.example (note the mismatch) → likely a malformed rendering or a post-DMARC tampering attempt.

Step 4 — Visual inspection for IDN homographs

Inspect the raw From: header byte-by-byte for non-ASCII characters. IDN-form domains appear as Punycode (xn--) in the raw header. Render the bytes in a hex editor or use the DMARC Analyzer Email Header Analyzer (header_analyzer.php) which surfaces IDN domains explicitly.

Step 5 — Inspect the Received: chain

The Received: headers chain (RFC 5322 §3.6.7) records each relay hop the message passed through. Anomalies to flag: unexpected geographic origin (compare HELO/EHLO hostname and IP against the claimed sender's known infrastructure), missing Received: headers from inside the sender's domain (suggesting the message did not originate from the claimed sender's MTA), and chains of relays through bulletproof-hosted MTAs.

Step 6 — Inspect Reply-To and Return-Path

A common spoofing tell is a Reply-To: header pointing to an attacker-controlled mailbox while the From: header reads as the impersonated sender. Mail clients send replies to Reply-To if present, hiding the discrepancy from the user. Similarly the Return-Path (set by the receiving MTA from the envelope From) reveals the bounce destination — mismatches with the visible From: are not necessarily malicious (third-party senders legitimately use distinct bounce domains) but warrant scrutiny on suspicious messages.

The DMARC Analyzer header_analyzer.php automates steps 1-6 against a pasted raw-header dump and produces a per-step verdict.

9. Real-world spoofing examples

The following examples are drawn from publicly-documented incidents and the canonical threat-intelligence reporting. They are presented for educational purposes — to help operators recognise the patterns in the wild, not to enable replication. Each example maps onto one or more techniques from section 3 and one or more MITRE ATT&CK sub-techniques.

• IRS / HMRC / CRA tax-refund scams. Direct domain spoofing (technique 3.1) of the visible From: header to refunds@irs.gov, refunds@hmrc.gov.uk, or cra-arc.gc.ca. Volume peaks in the weeks preceding national tax-filing deadlines. Defense: the tax authorities publish DMARC at p=reject, blocking the direct-spoof variant — the residual attack volume is via lookalike domains (irs-refunds.online) and cousin-domain registrations (irs-payments.support).
• DHL / FedEx / UPS / Royal Mail parcel-delivery scams. Mix of direct domain spoofing (technique 3.1) where the parcel carrier has weak DMARC, lookalike domains (dhl-tracking.online, fedex-delivery.help, royal-mail.express), and IDN homographs against the carrier brand. Message body asks recipient to click a tracking-update link or pay a small customs fee to release the parcel — credential harvest or card fraud at the landing page.
• DocuSign / Adobe Sign / HelloSign impersonation. Display-name spoofing (technique 3.3) with From: address at a free-webmail provider or a cousin domain (docusign-secure.email). Message body asks recipient to click an "open document" link that leads to a credential-harvest page. Common target: anyone whose legitimate workflow involves signing contracts via DocuSign — finance, legal, M&A teams.
• Microsoft 365 password-expiration / account-suspended scams. Display-name spoofing of Microsoft, lookalike domains (microsoft-account.support), and direct domain spoofing of microsoft.com against organisations whose Microsoft DMARC alignment is broken. Message body asks recipient to log in to "confirm your account" via an attacker-controlled link.
• Executive impersonation / CEO fraud. Display-name spoofing (technique 3.3) of the CEO/CFO with From: at a free-webmail provider, OR lookalike-domain registration of the victim domain. Goal: wire transfer authorisation from a finance employee. See help_business_email_compromise.php §2.1 for the operational deep dive.
• Vendor wire-redirect / invoice fraud. Combination of compromised- account spoofing (the attacker has access to the real vendor mailbox) or lookalike-domain registration. Goal: redirect a legitimate vendor payment to attacker-controlled bank accounts. See help_business_email_compromise.php §2.2 and §2.6 (VEC).
• Recruitment / HR scams (W-2 phishing). CEO-impersonation display-name spoofing targeting HR or payroll asking for a copy of all employee W-2 forms. Volume peaks in February — March around U.S. tax-form-filing season.
• Government-agency takedown notices. Lookalike-domain spoofing of national CERTs, the FBI, NCSC, or BSI. Often combined with attached "subpoena" files containing malware. Target: senior counsel and IT teams who would recognise the agencies but might not verify the From: domain character-by-character.

For a more comprehensive threat-research catalogue see help_dmarc_attacker_bypass.php §4-§7.

10. Defense-in-depth recommendations

Email-authentication (SPF + DKIM + DMARC) is the foundational defense against direct domain spoofing, but it leaves five spoofing classes uncovered (section 7). The defense-in-depth stack adds six additional layers, each addressing a specific gap:

• Layer 1 — Email authentication (DMARC + SPF + DKIM). Publish DMARC at p=reject for your apex domain AND every active subdomain. Publish SPF with -all qualifier (not ~all). Publish DKIM for every legitimate sender. Audit alignment. See help_dmarc_deployment_checklist.php for the 24-item deployment checklist.
• Layer 2 — Secure Email Gateway (SEG) anti-impersonation rules. Deploy a SEG (Proofpoint, Mimecast, Microsoft Defender for Office 365, Google Workspace Advanced Email Security) and configure rules for: display-name impersonation (flag mail whose display name matches a VIP roster but sender domain is external), lookalike-domain detection (flag inbound mail from domains within an edit-distance threshold of your domain), IDN/Punycode detection (flag any non-ASCII characters in From: domains), and external-sender tagging (mandatory "External" prefix on inbound mail).
• Layer 3 — Brand monitoring. Enroll in a brand-monitoring service that watches for: typosquat registrations (single-character substitutions), cousin-domain registrations (trademark-plus-word permutations), IDN-confusable registrations (UTS #39 confusables against your trademark), and certificate- transparency logs (HTTPS certificates issued for variants of your domain). Commercial vendors include DomainTools, RiskIQ, Recorded Future, ZeroFOX. Free sources include the Cybercrime Information Center, PhishTank, and Spamhaus DBL.
• Layer 4 — Defensive registrations. Register your highest-risk typosquat variants (single-character substitutions, common-misspelling variants, major TLD variants .net / .org / .co / .info / .online / .support / .help). Park them on a parking page that redirects to your real domain. The defensive- registration cost is a one-time per-domain registration fee (~USD 10-15 per domain per year for most TLDs); the alternative is paying for an aftermarket domain after an attacker registers it.
• Layer 5 — DNS hygiene. Audit DNS records quarterly for: orphaned CNAMEs pointing to abandoned cloud services (subdomain-takeover risk), expired SPF includes pointing at decommissioned third-party senders, missing sp=reject at the DMARC apex (which leaves subdomains unprotected by default).
• Layer 6 — Recipient training and process controls. Train staff to: verify the full From: address before acting on a message (not just the display name), hover over links to inspect the destination URL, use out-of-band channels for any payment-process change request (call the requester on a known phone number, never the number in the email), and require dual-authorisation for any wire transfer above a threshold. See help_business_email_compromise.php §6.4 (Layer 4: Finance-team payment-process controls) and §6.6 (Layer 6: Continuous training and BEC simulation).

For the operational discipline of monitoring DMARC aggregate reports (RUA) to detect spoofing attempts against your domain in real-time, see help_dmarc_monitoring.php and help_dmarc_aggregate_reports.php.

11. FAQ

What is email spoofing in simple terms?

Email spoofing is the protocol-level forgery of one or more sender-identity fields in an email message — typically the RFC 5322 From: header (the field your mail client renders as the "From" line) or the RFC 5321 MAIL FROM envelope sender (the field used for bounce delivery). Because the original SMTP protocol (RFC 5321, descended from RFC 821 in 1982) and the Internet Message Format (RFC 5322, descended from RFC 822 in 1982) were never designed with sender authentication, every email-authentication mechanism in use today (SPF, DKIM, DMARC, ARC, BIMI) is bolted on top decades later. Email spoofing is NOT the same as phishing or BEC: spoofing is the TECHNIQUE that forges the apparent sender; phishing and BEC are downstream USES of spoofing to harvest credentials or commit fraud. A spoofed email may carry malicious content (phishing) or commercial fraud (BEC) or neither (some pen-test exercises spoof emails to test detection without payload).

How does email spoofing work?

Email spoofing works by exploiting the asymmetry between the email protocols (SMTP, IMF) and the visible sender shown to the recipient. There are seven canonical techniques: (1) Direct domain spoofing — the attacker forges the RFC 5322 From: header to read CEO@victim.example without controlling victim.example; defeated by DMARC at p=reject when SPF or DKIM are properly published. (2) Envelope MAIL FROM spoofing — the attacker uses an arbitrary envelope sender in the SMTP MAIL FROM command; defeated by SPF when the receiver enforces. (3) Display-name spoofing — the attacker puts "CEO Name" in the display name preceding a free-webmail From: address (CEO Name <attacker@gmail.com>); not defeated by SPF/DKIM/DMARC because the From: domain is legitimately attacker-controlled. (4) Lookalike-domain registration — the attacker registers victim-corp.example or victim.com.fr and sends from that valid attacker-controlled domain with proper DMARC; not defeated by victim-domain DMARC. (5) IDN homograph — the attacker registers vіctim.example using Cyrillic і (U+0456) instead of Latin i (U+0069); not defeated by victim-domain DMARC because the spoof domain is technically distinct. (6) Cousin-domain registration — similar but different TLD or word (victim.co instead of victim.com). (7) Subdomain takeover — the attacker claims an orphaned CNAME pointing to a cloud service abandoned by the victim, then sends from the now-attacker-controlled subdomain.

Does DMARC stop email spoofing?

DMARC at p=reject with full SPF and DKIM alignment stops DIRECT DOMAIN spoofing — the variant where the attacker forges the From: header to read your domain. DMARC does NOT stop the other six canonical spoofing techniques: lookalike-domain spoofing (the attacker registers victim-corp.example, a different valid domain), display-name spoofing (the attacker puts "CEO Name" in the display name with a free-webmail From: address), IDN homograph attacks (the attacker registers a Unicode- confusable domain), cousin-domain registration (different TLD or word), subdomain takeover (the attacker claims an abandoned CNAME), or envelope-only spoofing under specific configurations. DMARC is necessary but insufficient for spoofing prevention; the defense-in-depth stack pairs DMARC with brand-monitoring lookalike-domain detection, display-name policies, secure-email-gateway anti- impersonation rules, and recipient training. The "DMARC stops spoofing" simplification is the single most-common misconception about DMARC and the reason this page exists.

What is the difference between email spoofing and phishing?

Email spoofing is the TECHNIQUE that forges the apparent sender of an email message; phishing is one possible USE of spoofing in which the message attempts to extract credentials, financial data, or other sensitive information from the recipient. Phishing always involves social engineering against the recipient; spoofing may or may not. Not all phishing uses spoofing (some phishing comes from genuinely attacker-controlled lookalike domains with valid DMARC for the attacker domain), and not all spoofing is phishing (some spoofing is used for spam, jokes, pen-test exercises, or wire-fraud BEC). In MITRE ATT&CK taxonomy, spoofing is part of T1036 Masquerading and T1583.001 Acquire Infrastructure: Domains, while phishing is T1566 with three sub-techniques (T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1566.003 Spearphishing via Service). The cleanest mental model: spoofing forges the sender, phishing exploits the message body and call-to-action.

What is the difference between the RFC 5321 envelope From and the RFC 5322 From header?

The RFC 5321 envelope From (also called MAIL FROM, Return-Path, or 5321.MailFrom) is the bounce address used during the SMTP transaction: when the sending MTA opens a connection to the receiving MTA, it issues the SMTP command MAIL FROM:<sender@example.com>. The envelope sender is used to deliver bounce messages back to the sender if the recipient is unreachable. It is NOT typically visible to the recipient. The RFC 5322 From header (also called 5322.From or RFC5322.From) is the message header line your mail client renders as the "From" line: From: "CEO Name" <ceo@example.com>. These two fields can — and often do — differ legitimately: a mail-merge service sends on behalf of brand@example.com but uses bounce-handling@brand.mail-merge-vendor.com as the envelope From. SPF authenticates the envelope From (5321.MailFrom). DKIM authenticates the signing domain (the d= tag in the DKIM signature). DMARC authenticates the From: header (5322.From) by requiring alignment — the 5322.From domain must match the SPF-authenticated 5321.MailFrom domain OR the DKIM-authenticated d= domain. This is the alignment concept central to DMARC.

How do I detect a spoofed email forensically?

The forensic detection workflow uses the Authentication-Results header (RFC 8601) and a visual inspection of the rendered message. Step 1: View the raw message headers (in Outlook: File > Properties > Internet headers; in Gmail: ... menu > Show original; in Apple Mail: View > Message > Raw Source). Step 2: Find the Authentication-Results header — it documents the receiver-side verdict for SPF, DKIM, and DMARC: Authentication-Results: mx.google.com; spf=pass / fail / softfail / neutral; dkim=pass / fail / none header.d=signing-domain.example; dmarc=pass / fail / quarantine / reject header.from=visible-from-domain.example. Step 3: Cross-check the header.from domain in the dmarc= field against the displayed From: address you expected. Mismatch is the canonical spoofing signature. Step 4: Visually inspect the From: address character-by-character for IDN homograph attacks (Cyrillic а vs Latin a, Greek ο vs Latin o) — Punycode-form IDN domains render as xn-- in the raw header. Step 5: Check the SPF Received-SPF header for the envelope From: domain mismatch with the visible From: domain. Step 6: Inspect the Received: headers chain for unexpected relay hops. The DMARC Analyzer Email Header Analyzer (header_analyzer.php) automates steps 1-6 against a pasted raw-header dump.

What is an IDN homograph attack?

An IDN homograph attack is a spoofing technique in which the attacker registers a domain name that LOOKS identical to a target domain but contains Unicode characters from non-Latin scripts that are visually confusable with Latin characters. Canonical example: a domain using Cyrillic а (U+0430) instead of Latin a (U+0061) — the rendered glyphs are visually indistinguishable in most fonts. The Unicode Consortium documents this attack class in UTS #39 (Unicode Technical Standard 39: Security Mechanisms). Common confusables: Cyrillic а vs Latin a, Cyrillic е vs Latin e, Cyrillic о vs Latin o, Cyrillic р vs Latin p, Cyrillic с vs Latin c, Greek ο (omicron, U+03BF) vs Latin o. IDN domains serialize to Punycode form starting with xn-- in DNS records and in the raw email headers, so technically- savvy users can detect them in the raw From: header — but the rendered From: line in the mail client shows the Unicode glyphs. Most modern browsers (Chrome, Firefox, Safari) implement Punycode-display rules that show xn-- in the address bar for suspected IDN homograph domains, but few mail clients implement the equivalent rule. Defense: enroll in a brand-monitoring service that watches for IDN- confusable registrations against your trademark; train users to hover over From: addresses; require external-mail tagging at the secure email gateway.

What is a lookalike domain and how is it different from a cousin domain?

A lookalike domain is any attacker-controlled domain registered specifically to resemble a legitimate target domain. The class subdivides into two main types: (1) Typosquats / pure-lookalikes that exploit visual similarity — single-character substitutions (paypa1.com for paypal.com), character omissions (paypl.com), character transpositions (papyal.com), homograph variants using Latin-script characters that look similar (gooogle.com with three Os). (2) Cousin domains that combine the target brand with an additional legitimate-sounding word or different TLD — paypal-security.com, paypal-support.com, paypal-login.com, paypal.co (instead of paypal.com), paypal.support, paypal.online. The distinction matters operationally because typosquats are caught by spell-check-style brand- monitoring services (the canonical regex-similarity scan), while cousin domains require monitoring for trademark- plus-word permutations across all TLDs (a much wider search space). The MITRE ATT&CK technique T1583.001 (Acquire Infrastructure: Domains) covers both classes. DMARC at p=reject for your real domain does NOT defend against either — the attacker controls a technically distinct domain. Defense: brand-monitoring services (e.g. via the Cybercrime Information Center, Spamhaus DBL, PhishTank, or commercial vendors), defensive registrations of high-risk variants in your name, and recipient training to verify the domain character-by-character.

12. Related guides

• Business Email Compromise (BEC) explained — the standalone operational playbook for the financial-fraud outcome enabled by spoofing. Covers the six canonical BEC variants (CEO fraud, invoice fraud, payroll diversion, gift-card scam, M&A fraud, VEC), the BEC kill chain, exactly where DMARC defends and where it does not, the six-layer defense-in-depth stack, employee red-flag indicators, the FBI Financial Fraud Kill Chain incident-response playbook, and BEC vs ransomware cost statistics for executive sponsorship.
• DKIM failures explained — the SPOOFING-ATTACK-DKIM-VERDICT- FAILURE-SIGNAL-AS-RECEIVER-SIDE- DETECTION-LAYER companion to this email-spoofing technique-taxonomy reference. Where THIS page documents the seven canonical spoofing-delivery techniques (display-name spoofing, lookalike-domain registration, header- From-vs-envelope-From disjunction, third-party-vendor compromise, ARC- trust-chain abuse, BEC-pretext- engineering, STARTTLS-strip-and- cleartext-delivery), the DKIM-failures- explained spoke documents the receiver-side DKIM-verdict-failure- signal class catalogue that surfaces in Authentication-Results headers AND in per-row RUA aggregate-report XML as the EARLIEST observable telemetry of spoofing attempts targeting the protected author-domain. Concretely, the spoke documents FOUR DKIM-failure- as-spoofing-detection-signal dimensions: (i) dkim=fail signature mismatch as the canonical author-domain-impersonation signal without a valid signing key — when an attacker emits mail with a forged From: ceo@<victim-domain> header but cannot produce a valid DKIM signature matching any published key under <selector>._domainkey.<victim-domain>, the receiver-side cryptographic verification returns dkim=fail (signature did not verify) — the spoofing-attempt leaves a per-message detection signal the spoke documents as the canonical cryptographic-mismatch class; (ii) dkim=none unsigned-author- domain as the lookalike-domain or unauthorized-sender spoofing signal class — when an attacker sends from a lookalike domain (example-corp.com instead of example.com) and the attacker's domain has no DKIM infrastructure, the receiver surfaces dkim=none — DISTINCT from dkim=fail and recognised by spam filters as a strong spoofing signal when combined with header-From display-name impersonation of a known executive; (iii) body-hash- mismatch under in-flight content- tampering as the man-in-the-middle message-modification spoofing signal class — when a hostile relay modifies message body content (e.g., substituting wire-transfer routing numbers, swapping legitimate URLs for phishing links, rewriting attachment references), the receiver-side body- hash recomputation of the canonicalized body diverges from the original- signer's bh= tag and produces dkim=fail (body hash did not verify) — the spoke documents this body-hash-mismatch class as a structurally-distinct spoofing-detection signal from the signature-mismatch class (the forensic-analysis remediation differs: body-hash-mismatch indicates active in-flight tampering, signature- mismatch indicates header-From forgery without key access); and (iv) dkim=permerror selector NXDOMAIN as the attacker-DNS- manipulation signal class — when an attacker attempts to subvert DKIM verification by hijacking the victim-domain's DNS to inject NXDOMAIN responses for legitimate selector lookups (DNS-cache poisoning, BGP hijack against the victim's authoritative nameservers), receivers surface dkim=permerror (no key for signature) on legitimate signed mail — distinct from dkim=fail because the forensic-analysis attribution points to DNS infrastructure compromise rather than message-content tampering. Read the DKIM-failures-explained spoke alongside this spoofing-taxonomy reference when the receiver-side Authentication-Results inventory or per-row RUA aggregate-report XML surfaces unexpected DKIM verdicts — the spoke provides the verdict-class taxonomy distinguishing genuine sender-configuration faults from active spoofing-attack telemetry that warrants SOC escalation under the defense-in-depth stack this spoofing- taxonomy reference enumerates.
• MTA-STS explained - the MTA-STS-AS-DOWNGRADE-ATTACK- PREVENTION-COMPLEMENT-TO-DMARC-ANTI- SPOOFING companion to this email- spoofing technique-taxonomy reference. Where THIS page documents the seven canonical spoofing-delivery techniques (display-name spoofing, lookalike-domain registration, header-From-vs-envelope- From disjunction, third-party-vendor compromise, ARC-trust-chain abuse, BEC-pretext-engineering, STARTTLS-strip- and-cleartext-delivery), the dedicated MTA-STS-explained pillar documents the STRUCTURALLY-LOAD-BEARING publisher-side transport-layer TLS-enforcement-policy mechanism whose four cross-layer coordination dimensions identify the publisher-publishable defense against the SEVENTH spoofing-delivery technique class this page operationalises on: (i) STARTTLS-strip spoofing- delivery operates at the SMTP-session TLS-negotiation layer where a man-in- the-middle attacker strips the receiver- MX's STARTTLS opportunistic-encryption advertisement before the sending MTA receives it, forcing cleartext SMTP delivery that bypasses application- layer encryption - MTA-STS publisher's mode: enforce commitment instructs sending MTAs to REQUIRE STARTTLS-with-cert-validation at the publisher-pinned MX-allow-list and REJECT delivery when the receiver-MX cannot present a valid leaf cert - STARTTLS-strip attacks structurally FAIL because the sending MTA does not fall back to cleartext when MTA-STS enforce is active; the MTA-STS- explained pillar documents the STARTTLS-enforce contract that closes the STARTTLS-strip spoofing-delivery attack surface; (ii) MTA-STS publisher-pinned MX-allow-list at the mx: <hostname-glob> policy line defends against the MX-impersonation spoofing-delivery sub-class where a man-in-the-middle attacker redirects sending MTA's MX- resolution to an attacker-controlled MX that accepts the message - sending MTAs honoring MTA-STS REJECT delivery to any MX not matching the publisher's MX-allow-list glob pattern - the MX-impersonation spoofing-delivery sub-class structurally FAILS; the MTA-STS-explained pillar documents the MX-allow-list publisher-pinning contract that closes the MX-impersonation spoofing-delivery attack surface; (iii) MTA-STS is OPERATIONALLY DEPLOYABLE AT THE PUBLISHER ALONE without requiring per-receiver coordination - the publisher's MTA-STS policy publication causes ANY sending MTA implementing RFC 8461 to enforce TLS to the publisher's MX-allow- list at delivery time, providing immediate cross-receiver downgrade- attack defense from the publisher's unilateral publication - this UNILATERAL- PUBLISHER-PUBLICATION DEPLOYABILITY contrasts with application-layer SPF/DKIM/DMARC mechanisms that require per-receiver opt-in for honoring the publisher's enforcement directive; the MTA-STS-explained pillar documents the unilateral-publisher-publication deployability contract that this email- spoofing technique-taxonomy frames as the operator-actionable defense closure for the STARTTLS-strip technique sub-class; and (iv) MTA-STS publisher-side observability via TLS-RPT JSON aggregate reports at the publisher's rua=-mailbox surfaces per-receiver per-day STARTTLS- validation-failure rate - publisher's TLS-RPT stream reveals when sending MTAs have rejected delivery to receiver-MX endpoints under MTA-STS enforce due to TLS-validation failures, providing operational evidence that the STARTTLS-strip spoofing-delivery attack-class is being defended against at receivers honoring the publisher's MTA-STS policy; the MTA-STS- explained pillar documents the TLS-RPT-as-publisher-side-MTA-STS- enforcement-observability reporting layer that this email-spoofing technique-taxonomy frames as the publisher-side evidence-stream consumer for STARTTLS-strip-defense operational-effectiveness measurement.
• MTA-STS policy file byte-syntax — the SPOOFING-VS-TRANSPORT-LAYER- DOWNGRADE-DEFENSE-COMPLEMENT companion to the seven-mechanism spoofing surface area documented on this page. Where THIS page documents the protocol-level technique deep dive on spoofing — direct-domain spoofing (RFC 5322 From: forgery), display-name spoofing (Reply-To / Display-Name mismatch attacks), lookalike- domain attacks (Punycode / IDN homographs / typo-squatting), Reply-To injection, envelope-MAIL-FROM forgery, and the Received-chain anomalies an analyst sees when investigating spoofing — at the APPLICATION LAYER (the SMTP-message headers and envelope identifiers the receiver parses), the MTA-STS-policy- syntax spoke documents the TRANSPORT-LAYER DOWNGRADE-DEFENSE byte-syntax — the policy file 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 the 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 SPOOFING-LAYER-VS- TRANSPORT-LAYER comparison exposes the structurally-distinct ATTACK-LAYER-COVERAGE roles: (i) NONE of the seven spoofing techniques on this page are defended by MTA-STS — spoofing is application-layer authentication forgery the RECEIVER consumes via DKIM / SPF / DMARC verdict; MTA-STS protects the SMTP TLS handshake the sender uses to TRANSPORT the (already-application-layer- spoofed-or-not) message — the two protocol layers defend ORTHOGONAL attack classes; (ii) a domain publishing DKIM-aligned p=reject DMARC (closing application-layer spoofing) without publishing an mode: enforce MTA-STS policy STILL leaks message bodies in cleartext to any network-positioned attacker capable of STARTTLS-stripping the sending MTA's outbound session; the MTA-STS-policy-syntax spoke documents the byte-syntax contract that closes this transport-layer leak; (iii) spoofed credential-phishing campaigns that successfully reach a recipient's mailbox via application- layer DMARC bypass (compromised account, third-party-vendor compromise) still rely on the recipient's mailbox-provider accepting transport-layer TLS — a misconfigured MTA-STS policy at the recipient's domain could allow an attacker to inject DOWNGRADED cleartext responses (e.g. fake password-reset confirmations) back into the campaign; the spoke documents the byte-syntax contract recipient domains MUST publish to close this back-channel; (iv) the MTA-STS policy file's mx: tag lists the recipient domain's authoritative MX hostnames in wildcard or exact-match form (per RFC 8461 §3.2 the patterns mx: *.example.com / mx: mail.example.com) — each mx: entry MUST match a corresponding TLS certificate Subject Alternative Name on the receiver's MX-published host or the sender's mode: enforce session fails closed (TLS-refused to cleartext); the spoke documents the byte-syntax precision required to prevent transport- layer downgrade attacks against recipient-side mail flow. Read the MTA-STS-policy-syntax spoke when designing a complete spoofing-and- downgrade-resistance posture: the spoofing techniques on this page are defended at the application layer by DMARC + DKIM + SPF, but the transport-layer gap requires the byte-syntax-correct MTA-STS policy file the spoke documents.
• MTA-STS vs DANE for SMTP — the STARTTLS-STRIP-DOWNGRADE-AS- SPOOFING-DELIVERY-VECTOR-TRANSPORT- LAYER-DEFENSE-MECHANISM-CHOICE companion documenting the operator-side trust- model decision between MTA-STS and DANE for closing the transport-layer- downgrade attack class that delivers spoofed mail through cleartext SMTP. Where THIS page documents the seven- mechanism spoofing technique catalogue at the protocol layer (direct-domain From: forgery, display-name mismatch attacks, Punycode / IDN homograph lookalike-domain attacks, Reply-To injection, envelope-MAIL-FROM forgery, Received-chain anomaly forensics, and the STARTTLS-strip / opportunistic-TLS- downgrade transport-layer delivery vector that depends on the receiver MX accepting cleartext SMTP sessions), the MTA-STS-vs-DANE comparison spoke documents the OPERATOR-FACING MECHANISM-CHOICE for closing the STARTTLS-strip / downgrade transport- layer attack vector: MTA-STS (X.509- PKI-trust-model) deploys the policy file behind a public-CA-issued certificate at the mta-sts.<domain>/.well-known/mta-sts.txt endpoint and enforces per-MX-host STARTTLS at SMTP-connection time regardless of whether the connecting MTA prefers cleartext, deployable on any DNS zone with no DNSSEC prerequisite; DANE (DNSSEC-trust- model) places a TLSA RR at _25._tcp.<mx-host> carrying the certificate-or-public-key fingerprint that the connecting receiver validates via a DNSSEC-signed DNS path, requires the publisher's authoritative DNS zone to be DNSSEC- signed end-to-end, and offers stronger trust-model guarantees (no public-CA-compromise attack surface, no per-CA-trust-store divergence between receivers). The spoofing- defense program owner reads the MTA-STS-vs-DANE comparison spoke to scope which of the two transport- layer-security mechanisms is the right fit for the organisation's DNS- infrastructure-maturity posture, and which of the STARTTLS-strip / downgrade attack-variants enumerated in THIS page's transport-layer- delivery-vector section each mechanism actually closes at the SMTP-transport layer. Read the MTA-STS-vs-DANE comparison spoke alongside this spoofing-technique catalogue when scoping the transport-layer-security component of the anti-spoofing program — the comparison spoke is the OPERATOR-FACING DECISION REFERENCE for closing the STARTTLS-strip / downgrade transport-layer attack vector that delivers spoofed mail through cleartext SMTP. Closes the threat-catalogue ↔ MTA-STS-cluster bridge whereby the STARTTLS-strip / downgrade transport-layer attack vector THIS page enumerates is the OPERATOR-FACING THREAT-CLASS whose defense-mechanism choice the MTA-STS-vs-DANE comparison spoke documents.
• DANE for SMTP — the DANE-AS-DNSSEC-TRUST-MODEL- TRANSPORT-LAYER-DEFENSE-AGAINST-SPOOFING- DELIVERY-VECTORS companion documenting the DNSSEC-anchored TLSA-validation mechanism whose per-receiver-MX cryptographic-identity-binding defends against the seventh spoofing-delivery technique class (the transport-layer STARTTLS-strip / opportunistic-TLS- downgrade attack vector). Documents FOUR DANE-transport-layer-defense dimensions (DANE TLSA validation at _25._tcp.<mx-host> owner-name in a DNSSEC-signed zone provides per-MX cert-hash pinning the sending MTA validates BEFORE STARTTLS handshake — when an attacker injects a man-in-the-middle MTA to deliver spoofed mail, the DANE TLSA validation catches the cert-hash mismatch and rejects the connection BEFORE message body transfer, defeating the STARTTLS-strip subset of the transport-layer spoofing-delivery attack class; DANE's DNSSEC-trust-model anchor at the IANA root-zone DS chain provides INDEPENDENT trust evidence from the X.509-PKI Web-CA infrastructure — an attacker who compromises a single Web-PKI CA to issue a fraudulent cert for the spoofed-domain MX is STILL blocked by DANE TLSA validation, because the TLSA hash binds the legitimate- operator-published cert key NOT the Web-CA's signature on the attacker- procured cert — defeating the CA- compromise subset of the transport-layer spoofing-delivery attack class that MTA-STS (X.509-PKI-trust) cannot defend against; DANE TLSA records at the receiver-MX owner-name defend against the DNS-cache-poisoning subset of the transport-layer spoofing-delivery attack class — an attacker who poisons a recursive resolver's DNS cache to redirect the receiver-MX A/AAAA records to attacker- controlled infrastructure is blocked by the validating sender's DNSSEC-aware resolver when the TLSA-validation lookup falls back to the upstream-signed zone rather than the cache-poisoned recursive, whereas MTA-STS-only deployments without DNSSEC are vulnerable to the cache- poisoning subset; DANE TLSA per-message validation outcomes surface in the per-day TLS-RPT JSON aggregate-report result-type enumeration (dane-required, tlsa-invalid, dnssec-invalid) providing per-receiver per-day transport-layer- spoofing-attack visibility the receiver- side defender consumes to attribute per-attack-vector frequency and per- attacker-infrastructure persistence — the operator-facing TLSA-failure stream is the EVIDENCE-CHANNEL for the seventh spoofing-delivery technique class this taxonomy enumerates). Read the DANE explainer spoke alongside the MTA-STS-vs-DANE decision-tree spoke when authoring spoofing-defense operational documentation that covers the transport-layer-spoofing subset of the spoofing-delivery technique catalogue — the DANE spoke documents the DNSSEC- trust-model half of the per-MX cert- pinning defense the operator selects when DNSSEC-signing infrastructure is operationally feasible.
• TLS-RPT report format (RFC 8460 §4 JSON schema) — the TRANSPORT-LAYER-SPOOFING- DELIVERY-DETECTION-VIA-TLS-RPT-JSON- RESULT-TYPE-ENUMERATION companion to this spoofing-technique taxonomy. Where THIS page documents the seven- mechanism spoofing-attack catalogue (direct-domain From: forgery, display- name mismatch, Punycode / IDN homograph lookalike-domain, Reply-To injection, envelope-MAIL-FROM forgery, Received- chain anomaly forensics, and the STARTTLS-strip transport-layer delivery vector) AND the mta_sts_vs_dane spoke documents the OPERATOR-FACING MECHANISM-CHOICE for closing the transport-layer delivery vector at publication time, the TLS-RPT-report- format spoke documents the RECEIVER- SIDE EVIDENCE-PAYLOAD BYTE-SCHEMA the operator ingests to detect that the STARTTLS-strip attack was attempted AGAINST the publisher's mail-flow. FIVE structurally-distinct SPOOFING- DELIVERY-VECTOR-VS-TLS-RPT-JSON-RESULT- TYPE detection classes the JSON schema encodes that THIS spoofing taxonomy cross-references but does not byte- schema enumerate: (i) STARTTLS- strip attack detection via starttls-not-supported result-type rows — an active attacker who strips the STARTTLS EHLO response from the receiver-MX's banner produces a per-receiver per-day spike in this result-type, identifying the active-attacker-induced cleartext- delivery channel; (ii) STARTTLS- negotiation-failure detection via negotiation-failure result-type rows — the attacker-induced TLS handshake abort (downgrade-injected protocol-version mismatch / cipher-suite-stripping) produces this distinct result-type, complementing the STARTTLS-strip detection axis; (iii) rogue- MX-substitution / cousin-MX- registration attack detection via certificate-host-mismatch result-type rows — when an attacker registers a typosquat MX hostname or BGP-hijacks the MX IP- space, the per-receiver per-day spike in this result-type identifies the attacker-controlled rogue-MX delivery channel; (iv) rogue-CA-mis- issuance attack detection via certificate-not-trusted result-type rows — when an attacker procures a fraudulent certificate from a non-CAA-authorized CA, the per-receiver per-day spike in this result-type AT MTA-STS-deploying publishers identifies the attacker's attempt; (v) per-receiver per- day aggregate-report row joined against the source-IP attribution produces the unified spoofing-delivery- channel observability matrix — the JSON schema's per-row source-MTA- IP attribution combined with the per- receiver per-day spoofing-attempt- attribution this spoofing taxonomy's per-row RUA-aggregate-report joins against, produces the per-attacker- infrastructure observability matrix the incident-response team's retrospective consumes. Read the TLS-RPT-report-format spoke alongside this spoofing-technique taxonomy when constructing the security-team's transport-layer-spoofing-delivery- detection workflow — the JSON schema is the byte-level evidence format that surfaces the STARTTLS-strip attack-delivery channel after the attempted spoofing-delivery occurs, producing the per-attack-attempt forensic-evidence-row record the retrospective consumes alongside the DMARC RUA application-layer rows this spoofing taxonomy's other Related Guide entries reference.
• Phishing protection — the operational defense playbook for the broader phishing-and-credential-theft threat class. Spoofing is the protocol-level technique attackers use against the envelope / From / Reply-To / Display-Name surface area documented on this page; phishing is the umbrella attack class that weaponises spoofing (plus lookalike domains, IDN homographs, hijacked legitimate senders, OAuth-consent abuse, MFA push-bombing, AiTM proxy kits like Evilginx2 / Modlishka / Muraena) into credential theft, payload delivery, MFA bypass, and post-compromise mail-flow tampering. Pair this spoofing page (the technique mechanics + protocol-level defense surfaces) with the phishing-protection page (the layered defense stack + user-training program + organisational response framework) for the complete attack-and-defense view across the technique and the campaign.
• DMARC for transactional email — the TRANSACTIONAL-EMAIL-AS-PRIMARY-SPOOFING- TARGET-SURFACE companion to THIS spoofing seven-technique catalogue. Where THIS page documents the seven protocol-level spoofing techniques (direct-domain From: forgery, display-name spoofing, lookalike-domain attacks via Punycode / IDN homographs / typo- squatting, Reply-To injection, envelope-MAIL- FROM forgery, hijacked-legitimate-sender attacks, and the Received-chain anomalies an analyst sees when investigating spoofing), the dmarc_for_transactional_email spoke documents the TRANSACTIONAL-EMAIL-AS-PRIMARY- SPOOFING-TARGET surface — every password- reset / order-receipt / invoice / shipping- notification / 2FA-code / account- verification / billing-receipt / appointment-reminder message is a high-impersonation-value target for the attacker-side techniques this page catalogues. Four structurally-distinct transactional-class spoofing-amplifier operational classes the spoke covers that THIS spoofing-technique catalogue intentionally elides: (i) password- reset-and-account-verification spoofing as the credential-phishing kill-chain entry point — attackers spoof legitimate transactional senders (banks, social platforms, e-commerce sites, SaaS tools) at the password-reset / account-verification / login-notification surface because end-users EXPECT such messages and click reflexively; (ii) invoice / billing-receipt / order-confirmation spoofing as the Business-Email-Compromise invoice-fraud delivery vector — every BEC invoice- fraud campaign documented in the BEC playbook delivers via a spoofed transactional sender (forged supplier invoice, forged customer payment, forged wire-transfer confirmation); (iii) shipping- notification / delivery-tracking spoofing as the consumer-fraud package-delivery scam delivery vector — UPS / FedEx / DHL / Amazon delivery-notification spoofing is the canonical entry point for fake- package-delivery-fee scams; (iv) 2FA-code / one-time-passcode spoofing as the MFA-bypass kill-chain step — attackers spoof legitimate 2FA-code senders (Twilio / Authy / Microsoft Authenticator email- fallback / Google 2-Step email-fallback) to convince users to relay codes back to the attacker via reply. Required reading once an operator running a transactional- email program (e-commerce / SaaS / banking / healthcare / hospitality) needs to cross-reference the spoofing protocol-level techniques on this page against the per- transactional-class amplification surface that makes the techniques operationally valuable.
• How attackers bypass weak DMARC — security-research-flavoured catalogue of 22 concrete attacker techniques across four classes: direct From-identity attacks (including the spoofing techniques on this page), weak-configuration attacks, authentication-mechanism attacks, and infrastructure attacks DMARC cannot stop. The threat-modelling companion to this page.
• DMARC myths and misconceptions debunked — the defender-perspective dual to the attacker-bypass page. Debunks 18 common DMARC myths including "DMARC stops phishing" (no — only direct domain spoofing), "DMARC protects against all email impersonation" (no — see this page's section 7), and "DMARC is set-and-forget" (no — see help_dmarc_monitoring.php).
• DMARC multi-domain strategy — the MULTI-DOMAIN-IMPERSONATION-ATTACK- SURFACE-VS-PER-ORG-DOMAIN-DMARC-COVERAGE companion to this seven-technique email- spoofing taxonomy. Where THIS page catalogues the SEVEN structurally-distinct spoofing techniques (1. direct domain spoofing, 2. cousin-domain typosquatting, 3. display-name spoofing, 4. legitimate- domain-compromised, 5. legitimate-vendor- compromised, 6. reply-chain hijacking, 7. homoglyph attacks) attackers use to deliver spoofed mail against a single target domain, the multi-domain-strategy spoke documents the PER-ORGANIZATIONAL-DOMAIN DMARC COVERAGE DISCIPLINE the operator managing a multi-domain estate MUST maintain so EACH organizational domain in the estate is INDEPENDENTLY DEFENDED against the seven spoofing techniques. The FIVE structurally-distinct multi- domain operator cohorts each surface a DIFFERENT spoofing-attack-surface manifestation: (i) MULTI-BRAND ESTATES where each brand-domain is an INDEPENDENT spoofing target — attacker researches THE WEAKEST-DMARC sibling brand-domain to impersonate (brand-A's p=reject doesn't defend brand-C's p=none against direct-domain-spoofing technique 1); (ii) ACQUISITION DOMAINS recently acquired through M&A are HIGH-VALUE spoofing targets in the post-acquisition transition window when employees are receiving legitimate corporate-communications- from-the-new-parent emails — attackers weaponize this confusion via direct- domain-spoofing technique 1 against the acquisition-domain in the first 90 days following announcement; (iii) PARKED DOMAINS the operator owns but does not send mail from are the ATTACKER'S DREAM impersonation surface (any mail with Header-From: parked-brand.com is unambiguous spoofing — the parked- domain's correct posture is p=reject; sp=reject; adkim=s; aspf=s with NO active senders); (iv) SEND-ONLY SUBDOMAINS (mailer.example.com, bounce.example.com) attackers target as spoofing surfaces WHEN the send-only subdomain lacks its own DMARC record AND the parent's sp= is permissive (the cousin-domain-typosquatting technique 2 is most successful against send-only subdomain naming conventions); (v) COUSIN-DOMAIN TYPOSQUATS the attacker REGISTERS as new domains designed to impersonate the operator's multi-domain portfolio (paypal-secure.com, amazon-payments.net) — these are NOT within the operator's multi-domain estate but the operator's defensive registration discipline (defensive-registration of cousin-domain variants and publishing p=reject; sp=reject; adkim=s; aspf=s on each defensive registration to prevent legitimate- looking sender-identity hijacking by a third-party who later acquires the domain) IS the multi-domain-strategy defense against technique 2 at the estate level. Read the multi-domain- strategy spoke when constructing the comprehensive impersonation-threat- model for the multi-domain portfolio — the spoke documents the per-organizational- domain DMARC publication discipline whose ABSENCE on any single domain in the estate leaves THAT specific domain uncovered as a spoofing target regardless of the parent-corporate-domain's p=reject posture (attackers are SOPHISTICATED about researching the weakest-DMARC sibling domain in a corporate portfolio and weaponizing exactly that domain for spoofing operations).
• DMARC record tags explained — tag-by-tag reference for v=DMARC1, p=, sp=, rua=, ruf=, fo=, adkim=, aspf=, pct=. The DMARC record reference cited from every section of this page.
• DMARC forensic reports (RUF / AFRF) — the per-message spoofing-incident-feed channel paired to the ruf= / fo= tag-grammar — the per-message-failure RUF channel that originally gave defenders a real-time per-incident feed of the spoofed-message headers + envelope authentication results documented in detail throughout THIS spoofing page. Where THIS page documents the seven spoofing techniques (envelope MAIL FROM, From:, Reply-To:, Display-Name, Punycode/IDN homograph, cousin-domain, hijacked legitimate sender) and the protocol-level defenses that block each, the forensic-reports spoke documents the receiver-side per-message feedback channel that historically allowed defenders to SEE the actual spoofing attempt — the original message headers (redacted in the message/rfc822-headers body-part), the failed auth_results verdicts in machine-readable form, and the spoofed envelope vs From-header mismatch evidence per RFC 6591 AFRF byte-grammar. Critical historical context for defenders: the spoke documents WHY the RUF channel is now largely deprecated across major receivers (Gmail does not send RUF; Microsoft sends only on explicit opt-in) — the PII / GDPR exposure of message-body content in early RUF deployments drove receivers to retire the real-time per-incident feed and push defenders onto aggregate-only RUA consumption. Read the forensic-reports spoke when an operator is designing the spoofing- incident-response feedback loop and weighing whether ruf= publication is worth the GDPR-review cost vs the information-yield from the modern receiver- side policy matrix (where most major receivers no longer send RUF at all).
• DMARC alignment explained — strict vs relaxed alignment, the organizational-domain inheritance per RFC 7489 §3.2, and the implications for subdomain spoofing.
• DKIM alignment with DMARC — the DKIM-ALIGNMENT-AS-PRIMARY- CRYPTOGRAPHIC-DEFENSE-AGAINST-FROM- HEADER-SPOOFING companion to this spoofing-techniques catalogue. Where THIS page catalogues the seven canonical spoofing techniques (envelope MAIL FROM spoofing, header-From: spoofing, Reply-To spoofing, Display-Name spoofing, Punycode/IDN homograph attacks, cousin- domain spoofing, lookalike-domain attacks), the DKIM-alignment spoke is the CRYPTOGRAPHIC-DEFENSE-EVALUATION reference documenting the per-message receiver-side decision rule whose verdict (dkim- alignment=pass / dkim-alignment=fail) is the LOAD-BEARING defense each spoofing technique must defeat. The DKIM-ALIGNMENT- VS-SPOOFING-TECHNIQUE-DEFENSE-MATRIX cross-reference establishes FOUR structurally-distinct per-spoofing-technique defense dimensions where DKIM-alignment is the load-bearing cryptographic gate: (i) header-From: spoofing defense — DKIM-alignment requires the DKIM-Signature d= domain match the spoofed From-header domain organizationally — an attacker spoofing the header-From: as ceo@victim.com must ALSO produce a DKIM-Signature with d=victim.com (or an organizational-domain-aligned subdomain) whose private signing key the attacker does NOT possess; without the private key, the attacker can only produce dkim= none verdict at the receiver, which produces dkim-alignment=fail (no DKIM signer-domain to align), which under DMARC p=reject blocks the spoofed message — the spoke documents why this defense holds at the cryptographic-key-possession boundary; (ii) Display-Name spoofing defense — DKIM-alignment unaffected by Display-Name but the header-From: address-form still must align — Display-Name spoofing (attacker emits "PayPal Support" <random@attacker.com> with a misleading display label prepended to an attacker-controlled address) does NOT defeat DKIM-alignment — the receiver evaluates DKIM-alignment against the addr-spec of the header-From, not the Display-Name; the spoke documents this scope-narrowing rule that explains why Display-Name spoofing succeeds at user-deception but FAILS at DKIM-alignment defeat; (iii) cousin-domain spoofing defense — DKIM-alignment evaluates against organizational domain, NOT full hostname — when attacker registers victim-support.com (a cousin domain) and signs messages from that domain, the DKIM-Signature d=victim-support.com aligns with header-From support@victim-support.com — the spoke documents how this is TECHNICALLY DMARC-aligned at the organizational-domain level but OPERATIONALLY a defense gap requiring per-recipient brand-monitoring + DMARC alignment alone is insufficient against this technique; receiver-side BIMI + brand-verification is the complementary defense; (iv) Punycode/IDN homograph attack defense — DKIM-alignment evaluates at byte level of A-label form, NOT at Unicode display form — when attacker registers victim.com's Unicode lookalike (victim.com with replaced Cyrillic 'а' char → xn--victm-... A-label form), the DKIM-alignment evaluator operates on the byte-level A-label form, which DIFFERS from the visually-identical Unicode form — the spoke documents this byte-level evaluation rule that explains why Punycode/IDN homograph attacks achieve user-deception via Unicode rendering but typically FAIL at DKIM-alignment defeat (the A-label bytes don't match the spoofed-brand's A-label). Read the DKIM-alignment- with-DMARC spoke alongside this spoofing-techniques catalogue when building per-technique defense coverage matrices — the spoke documents the receiver-side evaluation rule whose per-spoofing- technique defense behaviour determines which techniques DMARC p=reject blocks at the SMTP transaction layer vs which techniques require complementary defenses (BIMI brand-verification, receiver-side anti-phishing display warnings).
• DMARC policy rollout playbook — operational deployment from p=none through p=quarantine to p=reject without breaking legitimate sending. The path from "spoofing detected, not blocked" to "spoofing rejected at the SMTP transaction".
• BIMI Verified Mark Certificates (VMC and CMC) — the anti-spoofing brand-trust signal that an attacker cannot forge — the seven spoofing techniques catalogued on this page (envelope MAIL FROM, From:, Reply-To:, Display-Name, Punycode/IDN homograph, cousin-domain, hijacked legitimate sender) are all attacks on the message HEADER surface area; even when DMARC blocks them at the SMTP transaction, the residual attacker variants (cousin- domain spoofing, display-name spoofing, IDN-homograph spoofing) still arrive in the user's inbox with a From: header that LOOKS legitimate at a glance. The Verified-Mark-Certificate workflow introduces a STRUCTURAL DEFENSIVE PRIMITIVE the attacker cannot forge: the brand logo rendered next to the From: header in supporting mailbox providers (Gmail, Apple Mail, Yahoo, Fastmail, Outlook) is gated on a trademark-attested X.509 certificate chain that the attacker cannot replicate without the registered-trademark evidence pack the VMC issuance process (DigiCert or Entrust) validates — so a cousin-domain spoof of paypa1.com or n3tflix.com will arrive WITHOUT the brand logo while a legitimate message from the real domain renders the logo, giving the user a visual anti-spoof signal even on the residual attack variants this page's section 7 catalogues as DMARC-untouchable. The BIMI-certificates spoke documents the operational acquisition workflow (DigiCert vs Entrust CA selection, registered-trademark vs unregistered-mark evidence pack differences for VMC vs CMC, the byte-level PEM-bundle file format the BIMI record's a= URL must serve, the 12-month renewal cadence, the mailbox-provider-specific rendering coverage matrix where VMC is supported by Gmail + Apple Mail + Yahoo + Fastmail + Outlook but CMC is currently only honoured by Gmail, and the canonical rendering- failure-pattern taxonomy) operators need to deploy this anti-spoofing primitive AFTER the DMARC policy ramp this page treats as the foundational anti-spoofing gate. Read this spoke when stakeholders ask "what closes the residual cousin- domain / display-name / IDN-homograph spoofing gap DMARC does not address" — the answer is the brand-logo visual signal gated on the VMC the BIMI-certificates spoke documents.
• BIMI SVG Tiny PS logo requirements — the BRAND-SPOOFING-DEFENSE-VIA- VERIFIED-LOGO-PRESENCE-VS-ABSENCE-AS- USER-VISIBLE-SIGNAL companion reference. Where THIS page catalogues the seven spoofing techniques (envelope MAIL FROM, From:, Reply-To:, Display-Name, Punycode/IDN homograph, cousin-domain, hijacked legitimate sender) and the BIMI-certificates companion above documents the VMC certificate's MVA-trademark-validation gate that prevents an attacker from procuring a brand's logo certificate, the BIMI-SVG-requirements spoke documents what the brand-logo SVG bytes are that ACTUALLY RENDER at the MUA's inbox display surface when the certificate-validation, DMARC-pass, and SVG-byte-compliance gates all align. The SVG Tiny PS profile (a strict subset of SVG 1.1 + SVG 2 forbidding <script>, <foreignObject>, external references, raster image embeds, animation elements, and non-presentation namespaces; requiring a square viewBox, the baseProfile="tiny-ps" root attribute, a <title> element immediately after the <svg> root, and a 32KB Gmail ceiling) is the precise byte-level contract the brand-logo SVG must satisfy or the BIMI display gate FAILS at the MUA's silent non-render path — at which point the spoofing-defense user-visible signal the operator was relying on EVAPORATES even on perfectly DMARC-passing mail with a properly issued VMC. The implication: the residual spoofing techniques on this page that DMARC cannot block (cousin- domain, display-name, IDN-homograph, hijacked legitimate sender) and that the BIMI brand-logo signal is the out-of-band-trademark-anchored backstop for ARE ONLY defended by the brand-logo signal if the SVG-byte- compliance gate this requirements spoke documents is independently satisfied — otherwise the legitimate mail renders WITHOUT the brand logo too (because the SVG bytes are not Tiny-PS conformant), at which point the user CANNOT distinguish the legitimate mail from the cousin- domain spoof at the visual layer. Read the BIMI-SVG-requirements spoke alongside this page and the BIMI-certificates spoke when scoping the brand-spoofing-defense posture — the SVG byte compliance is the load-bearing rendering prerequisite the certificate validation and the DMARC enforcement gate compose with at the MUA inbox-display surface.
• DMARC deployment checklist — 24-item operator quick-reference covering SPF + DKIM + DMARC publication, ARC, BIMI prerequisites, monitoring, and post-rollout verification.
• SPF explained — the canonical SPF pillar. Covers mechanism types (ip4, ip6, a, mx, include, exists, ptr), qualifiers (+, -, ~, ?), the 10-DNS-lookup limit, and the forwarding-breaks-SPF gotcha.
• Why SPF alone is insufficient — the THREAT-CATALOGUE-OF-SPF- INSUFFICIENCY-VS-SEVEN-TECHNIQUE- SPOOFING-TAXONOMY companion to this email-spoofing seven-technique reference. Where THIS page catalogues the seven canonical email-spoofing techniques (display-name spoofing / header-From spoofing / lookalike-domain spoofing / Reply-To spoofing / via-redirect spoofing / cousin-domain typosquat / compromised- legitimate-account spoofing), the why- SPF-alone-is-insufficient spoke is the FOUNDATIONAL why-DMARC-exists reference whose 4-class SPF-insufficiency catalogue explains WHY each of these seven spoofing techniques remains OPEN when the operator deploys SPF alone without the DKIM + DMARC + BIMI authentication-stack complement. The THREAT-CATALOGUE-OF-SPF-INSUFFICIENCY- VS-SEVEN-TECHNIQUE-SPOOFING-TAXONOMY cross-reference establishes FOUR structurally-distinct SPF-only-leaves- spoofing-path-open dimensions: (i) SPF-only-leaves-header-From- spoofing-OPEN dimension — SPF authentication per RFC 7208 §5 produces a verdict ONLY against the RFC5321.MailFrom envelope domain; the RFC5322.From header- displayed domain (what mail clients present to end-users as the apparent sender) is NEVER authenticated by SPF alone; attackers exploit this gap via techniques #2 (header-From spoofing) and #4 (Reply-To spoofing) on THIS page — an attacker can publish a permissive SPF policy for an attacker-controlled envelope-domain ( attacker.example +all) and forge a victim-domain in the RFC5322.From header; SPF passes for the attacker's envelope, but the displayed identity is the victim. The why-SPF- alone-is-insufficient spoke documents WHY this gap exists at the protocol layer and WHY DMARC alignment is the structural closure; (ii) SPF- only-leaves-lookalike-and-cousin-domain- spoofing-OPEN dimension — SPF authentication is publisher-domain- scoped; it provides NO defense against lookalike-domain (technique #3) or cousin-domain-typosquat (technique #6) spoofing where the attacker publishes a valid SPF record for their OWN lookalike domain (g00gle.com / microsoftupdates.com / amaz0n.com); SPF passes legitimately for the attacker's lookalike domain because the attacker controls it; the end-user sees the lookalike-domain in the RFC5322.From header and is deceived. The why-SPF- alone-is-insufficient spoke documents WHY this gap requires the BIMI brand- indicator-mark visual confirmation layer (which lookalike domains CANNOT achieve because BIMI requires a VMC certificate the lookalike-domain attacker cannot obtain); (iii) SPF-only-leaves- forwarder-amplified-spoofing-OPEN dimension — SPF authentication collapses when legitimate mail traverses forwarders (mailing-list-managers / .forward / corporate-gateway / Office- 365-routed-rule); receivers observe spf=fail verdicts for legitimate forwarded mail and either bypass SPF entirely (defeating the protection) OR drop legitimate mail (deliverability damage); attackers exploit this via technique #5 (via-redirect spoofing) where they intentionally route through known-permissive forwarders to weaponise the receiver-side SPF-bypass heuristics; the why-SPF-alone-is- insufficient spoke documents WHY this gap requires the DKIM cryptographic- signature complement (DKIM signatures SURVIVE forwarders that don't modify the signed headers or body, structurally closing the forwarder-induced SPF- insufficiency gap); (iv) SPF- only-leaves-compromised-account-spoofing- DETECTABLE-ONLY-WITH-DKIM-REPLAY- ANALYSIS dimension — SPF authentication produces spf=pass verdicts for compromised-legitimate-account spoofing (technique #7) because the attacker is sending FROM the legitimate publisher's infrastructure with valid SPF configuration; SPF alone provides NO signal to distinguish legitimate sender from compromised-account-controlled attacker; DKIM cryptographic signatures paired with DMARC forensic reports per RFC 7489 §A.3 (RUF channel) surface per-message forensic evidence — DKIM- replay-attack analysis (see help_dkim_ replay_attacks.php on this page's sibling list) is the structural detection layer that SPF alone CANNOT provide. The why-SPF-alone-is- insufficient spoke documents WHY this gap requires the DKIM + DMARC + forensic- report stack complement. Pair this page (the seven-technique email-spoofing taxonomy reference) with the why-SPF- alone-is-insufficient spoke (the foundational why-DMARC-exists reference) when an operator authors the anti- spoofing defense posture and needs to apply the same four-class SPF- insufficiency-vs-seven-technique-spoofing- taxonomy structural-mapping discipline to prioritise the SPF + DKIM + DMARC + BIMI authentication-stack rollout that closes each of the seven spoofing techniques SPF alone cannot block.
• SPF for Google Workspace — the WORKSPACE-TENANT-SPF-AUTHORING-AS- CANONICAL-DEFENSE-PRIMITIVE companion to this spoofing-technique taxonomy. Where THIS page documents the seven canonical spoofing techniques (display-name spoofing, lookalike-domain registration, header-from spoofing, IDN/Punycode confusables, MIME- From injection, reply-to manipulation, MIME-multipart From masking) and the layered SPF + DKIM + DMARC defensive stack that neutralises each, the SPF-for- Google-Workspace spoke is the WORKSPACE- TENANT-DEPLOYMENT-AS-DEFENSE-PRIMITIVE companion documenting the four operationally-distinct dimensions at which Workspace-tenant SPF authoring is the load-bearing FIRST-LINE defense primitive against the spoofing techniques this page catalogues: (i) Workspace tenants publishing the canonical v=spf1 include:_spf.google.com ~all baseline authorise ONLY the Google-managed outbound netblock for envelope-MAIL-FROM authentication — every spoofing-attempt message originating from a non-Workspace- managed source IP fails SPF on the publisher's domain — the SPF- for-Workspace spoke documents this baseline as the canonical defense primitive at the largest cloud-mailbox- provider tenant population (the single most-deployed SPF record on the internet by tenant count); (ii) Workspace- tenant SPF + DKIM-via-Google + DMARC layered defense neutralises display-name spoofing + header-from spoofing + reply- to manipulation when the publisher has published all three at the apex — the SPF-for-Workspace spoke documents the per-Workspace-tenant SPF-publication step that is the FIRST of the three layered defenses and the load-bearing prerequisite for the DKIM + DMARC publication steps to provide defense-in- depth; (iii) Workspace-tenant SPF qualifier choice (~all softfail vs -all fail) is the operationally-consequential decision determining whether spoofing-attempt rejection is firm (SPF-fail with -all produces SMTP-time rejection at most receivers) or permissive (SPF-softfail with ~all produces tag-and- deliver at most receivers, relying on DMARC alignment to enforce rejection) — the SPF-for- Workspace spoke documents this qualifier- selection decision tree at the Workspace- tenant cohort with its Google-Groups- mediated outbound + Gmail-recipient- auto-forwarding density operational constraints; (iv) Workspace- tenant operators investigating a suspected spoofing incident in their aggregate-report stream MUST reference the Workspace-tenant baseline SPF publication to disambiguate legitimate- Workspace-egress source_ip rows from attacker-driven spoofing rows — the SPF-for-Workspace spoke documents the Google-managed outbound IP attribution model + the _spf.google.com cascade catalogue that the Workspace-tenant operator's incident-response triage depends on to identify attacker-driven spoofing rows as ENTIRELY OUTSIDE the published _spf.google.com netblock envelope. Pair this spoofing-technique taxonomy with the SPF-for-Workspace spoke when the targeted publisher is a Workspace tenant — the spoke is the AUTHORITATIVE Workspace-tenant SPF- publication reference operators reach for to verify that their published baseline is operationally sufficient as the FIRST-LINE defense primitive against the seven spoofing techniques this page catalogues, STRUCTURALLY- PARALLEL to the SPF-for-Microsoft-365 Workspace-equivalent at the M365 tenant cohort.
• SPF forwarding issues (the second-hop break) — the FORWARDING-FAILURE-VS-ACTUAL-SPOOFING- DISAMBIGUATION-IN-AGGREGATE-REPORT-ANALYSIS companion documenting the forwarder-hop SPF- fail pattern (mailing-list expansion, support- ticket relay, corporate-to-personal vacation forwarder, recipient-mailbox-rule auto- forwarding) that produces RUA aggregate-report SPF-aligned-fail rows VISUALLY INDISTINGUISHABLE in row-shape from the actual-spoofing-attempt rows this spoofing technique taxonomy catalogues — without disambiguation discipline, operators MISCLASSIFY legitimate forwarder- broken mail as attacker-driven spoofing and either over-harden their policy (legitimate-mail collateral damage) or misallocate incident-response effort. Where THIS page documents the seven canonical spoofing techniques (display-name spoofing, lookalike-domain registration, header-from spoofing, IDN/Punycode confusables, MIME-From injection, reply-to manipulation, MIME-multipart From masking), the SPF-forwarding-issues spoke is the LEGITIMATE-FORWARDER-FAILURE- DISAMBIGUATION companion documenting the structurally-distinct SPF-fail causation class operators MUST learn to distinguish from actual spoofing during aggregate-report triage. The four-axis SPOOFING-TECHNIQUE-VS- LEGITIMATE-FORWARDER-FAILURE comparison exposes the structurally-distinct AGGREGATE-REPORT- ROW-INTERPRETATION roles: (i) actual spoofing-attempt rows in RUA originate from attacker-controlled source IPs running attacker MTAs that impersonate the legitimate publisher's identity at the envelope-MAIL-FROM or RFC-5322-From layer — the source IP is not in the publisher's authorised sending infrastructure AND has no plausible legitimate- forwarder explanation; (ii) legitimate- forwarder SPF-fail rows in RUA originate from well-known intermediary forwarder IPs (Mailman/Sympa/Listserv mailing-list servers, Gmail forwarder pool, Outlook Web Access vacation-rule egress, university-alumni permanent-forward catch-all-mailbox forwarders) that are NOT in the publisher's SPF policy but ARE legitimately re-mailing the publisher's mail — the source IP is a recognized intermediary with mailing-list-header signatures (List-Id:, List-Unsubscribe:), MAY have ARC-Authentication-Results capturing the upstream pre-forwarder DKIM-aligned verdict, and produces SPF-fail-but-DKIM-pass-or-ARC- pass rather than SPF-fail-and-DKIM-fail; (iii) RUA-row triage must look beyond the boolean SPF-aligned-pass-vs-fail verdict and consume the source-IP-attribution, intermediary-MTA-reputation, ARC-Authentication- Results header chain, and mailing-list-header presence to disambiguate the two causation classes — the forwarding-issues spoke catalogues the per-forwarder-class identification heuristics operators apply during this triage; (iv) display-name spoofing and lookalike-domain spoofing (techniques §1 and §2 of this taxonomy) do NOT produce SPF-aligned-fail rows in the legitimate publisher's RUA at all, because the attacker is sending FROM AN ATTACKER-CONTROLLED DOMAIN whose RUA the legitimate publisher never sees — these techniques are OBSERVED at the receiver-side spam-filter or the recipient's own DMARC-monitoring tooling, not in the legitimate publisher's RUA stream; confusing the four causation classes (attacker- from-publisher's-domain SPF-fail vs forwarder- broken SPF-fail vs display-name spoofing not in publisher's RUA vs lookalike-domain not in publisher's RUA) is the single most common operator error in RUA-driven incident response. Read the SPF-forwarding-issues spoke alongside this spoofing taxonomy when triaging RUA-aggregate-report SPF-fail rows and when authoring the operator-side rules- of-engagement for distinguishing attacker-driven from forwarder-broken legitimate-mail-loss patterns.
• SPF qualifiers explained — the per-character prefix grammar that decides whether SPF actually blocks spoofing — the focused per-qualifier deep dive on the single-character prefix grammar (+ Pass / - Fail / ~ SoftFail / ? Neutral) whose final-token -all / ~all / ?all / +all choice directly determines whether the SPF defenses on THIS spoofing page actually enforce against unauthorised sending IPs at all. The +all anti-pattern (which the qualifiers spoke calls out as a well-known operator footgun) renders SPF meaningless — every IP on the public Internet receives an SPF-pass verdict, neutralising the envelope-MAIL-FROM-authorisation contract this page treats as the first spoofing-defense line. The ?all Neutral choice and the ~all SoftFail choice are similarly receiver-no-op verdicts that leave envelope spoofing unblocked (Gmail and Microsoft both treat ~-match and ?-match as "no action — flow through to other authentication layers"). Read the qualifiers spoke when an operator surveys the defended domains' SPF records and discovers a non--all tail or a deliberately- permissive per-mechanism prefix (?include: for low-trust partner SPF trees) — the qualifiers grammar is the gating layer that decides whether ANY of this page's other SPF-side spoofing defenses actually execute at the receiver. The 4 SPF-prefix characters and the 4 catch-all tail tokens form the smallest part of the SPF spec but carry the largest operator-impact when misconfigured against a spoofing threat.
• SPF lookup limit and flattening — the RFC 7208 §4.6.4 10-DNS-lookup limit deep dive, including SPF flattening and macro abuse.
• SPF DNS record syntax (byte-level TXT-record reference) — the SPOOFING-DEFENSE-ENVELOPE-MAIL- FROM-AUTHORISATION-PUBLICATION- PREREQUISITE-AT-THE-BYTE-LAYER companion to this spoofing taxonomy. Where THIS page documents the seven canonical spoofing techniques operating on RFC 5322 message-body headers (envelope MAIL FROM forgery, From: header spoofing, display-name spoofing, Reply-To: injection, lookalike-domain attacks, Received-chain tampering, header-folding tricks) and the six defender countermeasures (envelope-authorisation via SPF, cryptographic-signing via DKIM, policy- and-reporting via DMARC, transport- security via TLS / MTA-STS / DANE, visual-brand-verification via BIMI, organisation-level controls via SEG / anti-impersonation rules), the SPF-dns-syntax spoke is the BYTE-LEVEL-TXT-RECORD-PUBLICATION upstream prerequisite documenting the canonical v=spf1 … TXT-record byte layout that determines whether the SPF envelope-MAIL-FROM authorisation contract this spoofing- defense page treats as the FIRST spoofing-defense line is even correctly-publishable in the first place. The structural relationship is publication-prerequisite-and-runtime: SPF-dns-syntax controls the byte-level publication of the SPF TXT record at the operator's signer; the spoofing defenses documented here depend on the published record actually parsing-and-evaluating correctly at every receiver. The SPF-dns-syntax publication faults documented in the spoke (duplicate v=spf1 records producing spf=permerror at every receiver, multi-string concatenation breakage destroying SPF parsing, mechanism-ordering precedence errors producing unintended Pass verdicts, redirect-vs-include semantic confusion delegating SPF evaluation to attacker- controlled trees, byte-budget overrun forcing UDP-fallback-to-TCP receiver-side handling) each break the envelope-MAIL-FROM authorisation in distinct ways that allow envelope spoofing through the receiver's SPF check. Read the SPF-dns-syntax spoke when the operator is auditing the publication-layer correctness of every SPF record in the org-wide signer inventory before relying on the envelope-MAIL-FROM spoofing-defense documented in §1 of THIS spoofing taxonomy — the SPF-record-publication layer at the BYTE LEVEL is structurally orthogonal to the SPF-mechanism-grammar layer and the SPF-qualifier-prefix layer documented in the adjacent SPF spokes; all three layers must be independently audited for the envelope-MAIL-FROM spoofing-defense to actually enforce at every receiver.
• Reverse DNS / PTR records for mail servers — the SMTP-connection-layer companion to the From-header spoofing defenses documented on this page. Where the seven spoofing techniques above operate on the RFC 5322 message-body headers (envelope MAIL FROM, From:, Reply-To:, Display-Name, Punycode/IDN homograph From-domain), FCrDNS (Forward-Confirmed reverse DNS) operates one layer down at the SMTP-connection IP: the receiver runs gethostbyaddr(connecting_ip), then gethostbyname(returned_ptr), and confirms the original IP appears in the forward-lookup result per RFC 1912 §2.1. Spoofers routing through bulletproof hosting, residential proxies, or compromised IoT botnets fail FCrDNS by construction — the PTR is either missing (NXDOMAIN), generic (87-156-77-23.dyn.example.net), or mismatched against the HELO/EHLO domain. Reputation systems (Spamhaus, Cloudmark, Microsoft Smartscreen, Google Postmaster Tools) consult the FCrDNS result BEFORE any SPF / DKIM / DMARC evaluation runs; a clean PTR is the cheapest fix that closes whole-class spoofing routes the DMARC pipeline never sees because the spoofed connection is dropped at the trust-baseline gate beneath the Authentication-Results layer. Pair this page (the header-layer spoofing technique catalogue) with the reverse-DNS page (the connection-layer identity check that gates header-layer evaluation entirely) for the full attack surface from SMTP handshake through to RFC 5322 envelope tampering.
• DKIM explained — the canonical DKIM pillar. Covers selectors, canonicalization, signature algorithms (RSA, Ed25519), key sizes, and the d= signing domain.
• DKIM-Signature header anatomy — the SPOOFING-DEFENSE-PER-MESSAGE- CRYPTOGRAPHIC-SIGNATURE-HEADER companion to this email-spoofing seven-technique catalogue. Where THIS page documents the canonical seven-mechanism spoofing taxonomy (From: header rewrite, Reply-To injection, IDN homograph, display-name spoofing, look-alike domain registration, ARC-trust forgery, compromised legitimate sender), the DKIM-Signatures-explained spoke documents the FOUR per-tag byte- shape dimensions of the RFC 6376 §3.5 DKIM-Signature header whose per-message cryptographic-binding contract structurally defends against FOUR of those seven spoofing variants at the message-in- transit byte-shape layer: (i) From: header rewrite defense via h= signed-header-list tag — the DKIM-Signature header's h=From:Date:Subject:To:… tag cryptographically commits to the exact byte-sequence of the named headers, meaning any attacker-rewrite of the From: header in transit invalidates the signature and produces dkim=fail at the receiver — the per-message cryptographic answer to the most common spoofing technique; (ii) body-modification defense via bh= body-hash + c= canonicalization tags — the bh= body-hash tag commits cryptographically to the canonicalized body content determined by the c= canonicalization-pair, meaning any attacker-modification of the message body in transit invalidates the signature and produces dkim=fail at the receiver — the per-message answer to body-tampering attacks; (iii) identifier-binding defense via d= signing-domain tag — the d= tag identifies the organisation that signed the message cryptographically, which the DMARC alignment computation compares against the visible From: header's organisational domain — defending against display-name spoofing variants where the attacker controls attacker.example but the visible From: is rewritten to ceo@victim.example; (iv) selector-isolation defense via s= selector-binding tag — the s= selector sublabel binds the per-tenant DKIM verification key publication at <s>._domainkey.<d>, meaning a compromised vendor key under one selector cannot impersonate messages signed under another selector — the per-tenant isolation answer to the third-party-vendor-compromise spoofing variant. Read the DKIM-Signatures- explained spoke WITH this email-spoofing catalogue when triaging WHICH per-message cryptographic-binding component fails for a given spoofing-attempt sample: the DKIM-Signature anatomy is the per-tag forensic reference for understanding WHY a particular spoofed message produces dkim=fail (or, in attacker- relay scenarios, dkim=pass with d= attacker.example which then fails DMARC alignment).
• DKIM canonicalization — the SPOOFING-DEFENSE-CANONICALIZATION-AS-BYTE-FOR-BYTE-IMMUTABILITY-CONTRACT- BOUNDING-ATTACKER-BODY-MODIFICATION-SURFACE companion to this email-spoofing seven-technique catalogue. Where THIS page documents the canonical seven- mechanism spoofing taxonomy (From: header rewrite, Reply-To injection, IDN homograph, display-name impersonation, lookalike-domain registration, subdomain-takeover, third-party-vendor-key-compromise), the DKIM- canonicalization spoke is the BYTE-IMMUTABILITY-CONTRACT companion documenting the FOUR canonicalization-pair choices whose per-pair byte- immutability profile structurally bounds the attacker's body-modification surface across the spoofing taxonomy: (i) c=simple/simple is the STRICTEST byte-immutability contract — ANY byte change to the signed header set OR the body breaks the signature, leaving the attacker with NO BODY-MUTATION-ATTACK SURFACE downstream of signing (an attacker who intercepts and re-injects a signed message cannot append a payload, add a phishing-URL, or modify the visible text without breaking the b= bytes); (ii) c=relaxed/relaxed is the WEAKEST byte-immutability contract — whitespace-noise and case-noise in headers are normalised before hashing, and trailing whitespace + empty trailing lines in the body are normalised before hashing — this admits a NARROW BUT NON- ZERO ATTACKER MODIFICATION SURFACE (a malicious intermediary that introduces only whitespace-noise modifications does NOT break the signature, so the spoofing-defense posture under c=relaxed/relaxed must treat whitespace-only mutations as in-bound for the verified-DKIM channel); (iii) the third-party-vendor-key-compromise spoofing variant (Technique #7 in THIS page) is structurally INDEPENDENT of canonicalization choice — a compromised vendor key produces spoofed messages with FULL canonicalization-survival under any c= pair (the attacker holds the signing key, so the bodyhash they emit is valid regardless of which canonicalization the spoof uses), making canonicalization-choice NOT a defense against this specific variant (selector-isolation is the relevant defense — see the dkim_selectors_explained spoke this page already cross-references); (iv) the DKIM-replay sub-class of attack (a malicious actor re-sends an already-signed message to a different recipient) is structurally INDEPENDENT of canonicalization choice — the replayed bytes are byte-identical to the originally-signed bytes, so canonicalization of either pair produces the same hash. Read the DKIM-canonicalization spoke alongside this email-spoofing seven-technique catalogue when the operator faces an investigation of "did the attacker modify the body or re-sign with a compromised key" — the canonicalization-pair choice the sender authored AND the Auth-Failure: bodyhash vs Auth-Failure: signature vs no-failure-at-all evidence from any RUF forensic report together attribute the attack to a specific spoofing-technique sub-class in the catalogue THIS page documents.
• DKIM selectors explained — the THIRD-PARTY-VENDOR-COMPROMISE-AS-SELECTOR-ISOLATION-DEFENSE-VECTOR companion to this email-spoofing seven-technique catalogue. Where THIS page documents the canonical seven-mechanism spoofing taxonomy (the From: header rewrite, the Reply-To injection, the IDN homograph attack, the display-name impersonation, the lookalike-domain registration, the subdomain-takeover attack, the third-party-vendor-key-compromise variant), the DKIM-selectors spoke documents the SELECTOR-IDENTITY-PUBLICATION- ISOLATION-DISCIPLINE companion specifying the per-vendor s=-tag publication mechanics whose per-key isolation is the operator-side structural defense against the seventh spoofing variant. The four-axis SPOOFING-VS-SELECTOR-ISOLATION comparison exposes the structurally-distinct VENDOR-COMPROMISE-DEFENSE-VECTOR roles: (i) each third-party ESP (SendGrid, Mailchimp, Mailgun, HubSpot, Postmark, SparkPost, Salesforce Marketing Cloud, Amazon SES) gets its OWN dedicated selector under the publisher's <selector>._domainkey.<domain> namespace — a SendGrid s1._domainkey compromise does NOT produce spoofed messages cryptographically indistinguishable from Mailchimp k1._domainkey traffic because the receiver-side DKIM verifier independently fetches the per-vendor selector's public key and validates against the per-vendor private key; the selectors spoke documents the per-vendor selector-namespacing pattern that structurally bounds the blast radius of any single-vendor compromise to only that vendor's signed traffic; (ii) per-vendor selector ROTATION enables the operator to surgically retire a compromised vendor's DKIM-signing relationship by un-publishing only THAT vendor's selector without affecting any other vendor's signed traffic — the selectors spoke documents the per-vendor rotation cadence operators coordinate to bound the compromise-window to the rotation period plus the maximum receiver-side public-key cache TTL; (iii) per-vendor selector ALGORITHM ISOLATION protects against cryptographic-degradation attacks where one vendor's compromised 1024-bit RSA key cannot be substituted for another vendor's 2048-bit or Ed25519 key — the selectors spoke documents the per-vendor algorithm-selection discipline operators publish to prevent the algorithm-substitution variant of the vendor-compromise spoofing class; (iv) per-vendor selector SUNSET DISCIPLINE — when a vendor relationship terminates, the operator MUST un-publish the vendor's selector TXT record before the vendor's rotation-period maximum elapses, or the historical-vendor's private key remains a latent spoofing-vector even after the business relationship ends; the selectors spoke documents the post-vendor-relationship selector retirement checklist operators run to close the latent-key-compromise attack surface. Read the DKIM-selectors spoke alongside this email-spoofing pillar when the operator-side threat-model includes third-party-ESP-vendor-key- compromise as a credible attack class — the per-vendor selector- publication-isolation discipline the spoke documents is the load- bearing operator-side structural defense that contains a single- vendor compromise's blast radius to only that vendor's signed traffic and prevents cross-vendor compromise propagation through the operator's published DKIM-key portfolio.
• DKIM replay attacks — the byte-for-byte re-sending attack class that valid DKIM signatures cannot block. Includes the 2024 Google/Yahoo bulk-sender-disclosure context.
• DKIM for Google Workspace — the SPOOFING-DEFENSE-VIA-WORKSPACE-PER-DOMAIN-google._domainkey- TXT-PUBLICATION-AS-PER-TENANT-DKIM-SIGNING-IDENTITY-ANCHOR companion to this email-spoofing seven-technique catalogue. Where THIS page documents the canonical seven-mechanism spoofing taxonomy (From: header rewrite, Reply-To injection, IDN homograph, display- name impersonation, lookalike-domain registration, subdomain- takeover, third-party-vendor-key-compromise), the DKIM-for-Google-Workspace spoke is the WORKSPACE-TENANT-SIGNING- IDENTITY-ANCHOR companion documenting the Google-Workspace-tenant- specific DKIM publication topology whose per-tenant identity anchor is the structural prerequisite for the receiver-side DKIM-aligned defense posture this spoofing catalogue's mitigations assume. Google Workspace's DKIM publication model is structurally distinct from most ESP-managed DKIM deployments: the domain-owner generates a 2048-bit key pair via the Workspace Admin Console's Apps > Google Workspace > Gmail > Authenticate email surface, publishes the public key as a TXT record at google._domainkey.<your-workspace-domain> (using the literal selector google by Workspace convention), and toggles the Start authentication button to enable Gmail's outbound DKIM signer for that tenant's mail-streams. This per-tenant signing-identity anchor is the load-bearing prerequisite for FOUR structurally-distinct spoofing-defense outcomes from this catalogue: (i) the third-party- vendor-key-compromise variant (Technique #7 in THIS page) defense relies on per-vendor selector isolation — the Workspace tenant's google selector lives in its OWN namespace separate from any third-party-ESP selector (e.g., SendGrid s1._domainkey, Mailchimp k1._domainkey), so a SendGrid-key compromise does NOT produce messages that pass DKIM verification under the Workspace tenant's google._domainkey public key; the Workspace deployment's per-selector publication isolation bounds the cross-vendor compromise blast radius the dkim_selectors spoke this catalogue cross-references documents; (ii) the lookalike-domain registration variant (Technique #5 in THIS page) defense relies on per-tenant signing-identity anchoring — a lookalike-domain registrant cannot publish a DKIM TXT record at the legitimate Workspace tenant's google._domainkey.<legitimate- domain> location (only the legitimate domain-owner controls that DNS zone), so the lookalike-domain spoofed mail cannot produce a DKIM-Signature that the receiver-side verifier accepts as originating from the legitimate Workspace tenant — identifier-alignment fails at the DKIM d= verdict; the Workspace deployment's per-tenant TXT-record publication is the structural anchor that makes DKIM-aligned defense against the lookalike-domain spoofing class operationally meaningful; (iii) the subdomain-takeover variant (Technique #6 in THIS page) defense relies on parent-domain DNS-zone control — the Workspace tenant's google._domainkey.<domain> publication sits at the apex DNS zone the domain-owner controls; a stale-subdomain dangling CNAME pointing into a third-party provider cannot inject a competing DKIM TXT record under the apex zone's _domainkey namespace; the Workspace deployment's zone-apex publication topology structurally excludes subdomain-takeover-driven DKIM-spoofing variants from the threat model the operator must defend against; (iv) the receiver-side DKIM-Signature replay defense (the DKIM-replay sub-class this catalogue cross-references) partially benefits from Workspace's per-tenant x= signature-expiry deployment discipline — Workspace's Gmail outbound signer adds a default x= tag with a relatively short expiry window that bounds the replay-utility window for any signed-message-instance the attacker captures and re-injects; the Workspace deployment's signer-side x=-tag default is one operator-configurable lever in the multi-layer replay-defense posture (the others being receiver-side replay-detection via DKIM-signature-cache lookups and selector rotation). Read the DKIM-for-Google-Workspace spoke alongside this email-spoofing seven-technique catalogue when the operator-side threat-model includes Workspace-tenant- hosted mail-streams as a spoofing-defense target (the Workspace- admin-console-driven google._domainkey TXT-record publication mechanics the spoke documents are the load-bearing DKIM-signing-identity anchor the receiver-side DKIM-aligned defense posture this catalogue's mitigations assume operationally depends on).
• ARC explained — Authenticated Received Chain (RFC 8617): the forwarding-survival mechanism for SPF and DKIM. ARC preserves authentication results across mailing-list forwarders and corporate-mail gateways.
• Email authentication ecosystem (SPF, DKIM, DMARC, ARC, BIMI) — the cluster-intro pillar tying all four-layer authentication standards together.
• Email security glossary — the threat-and-defense vocabulary glossary defining ~80 terms including spoofing, phishing, BEC, lookalike, IDN homograph, subdomain takeover, and more.
• Email deliverability fundamentals — the cross-cutting business-outcome reference. Spoofing detection at the receiver feeds the deliverability funnel — DMARC-failed mail goes to spam or is rejected.
• DMARC for Microsoft 365 hybrid Exchange — the HYBRID-EXCHANGE-DUAL-SOURCE-MAIL-FLOW-AS-STRUCTURALLY-DISTINCT-SPOOFING-ATTACK-SURFACE companion to this seven-mechanism email-spoofing catalogue. Where THIS page catalogues the SEVEN structurally distinct spoofing mechanisms (header-From-only spoofing, display-name spoofing, lookalike-domain spoofing, IDN-homograph spoofing, subdomain-takeover spoofing, third-party-vendor-key-compromise spoofing, and reply-to spoofing) and the per- mechanism mitigation cookbook each receiver-side DMARC-enforcing posture depends on, the hybrid-Exchange deployment spoke documents the canonical Microsoft enterprise topology where DUAL outbound sources for the SAME header-From organisational domain create a structurally DISTINCT spoofing attack surface beyond the seven mechanisms catalogued here. The hybrid-Exchange spoke documents the SEND-CONNECTOR / DEFAULT-FRONTEND-CONNECTOR DKIM-strip pathology where a legitimate on-prem-Exchange-signed message has its DKIM-Signature header REMOVED at the cloud-side Default-Frontend-Connector relay boundary, leaving the message at the receiver indistinguishable from a forged spoof — a structurally-distinct DEFENSE-WINDOW where the spoofing- MITIGATION posture (publish DMARC at p=reject) cannot deploy until the UNDERLYING dual-signer-strip pathology is resolved. The hybrid-Exchange spoke also documents the ANONYMOUS-SMTP-RELAY- THROUGH-ON-PREM attack-surface where a legacy on-prem internal-server-only relay accepts arbitrary internal senders (printers, line-of-business apps) which an attacker with internal-network access can leverage to send unauthenticated outbound mail bypassing M365 DKIM signing entirely — a topology-specific attacker-bypass vector beyond the seven mechanisms catalogued here. The hybrid- Exchange spoke documents how the topology-specific defense posture must layer the DKIM-aligned alignment mode choice (adkim=s vs adkim=r) on top of an ARC-sealing-the-on-prem-to-cloud-relay (RFC 8617) deployment to cryptographically preserve original-author identity through the hybrid hop, with the four-phase DMARC rollout sequence (p=none → p=quarantine 10% → p=quarantine 100% → p=reject) gated on per-topology dual-source-alignment- pass-rate plateau evidence. Read the hybrid-Exchange spoke alongside this page when designing a spoofing-defense posture for a domain whose outbound mail traverses BOTH on-prem Exchange and Exchange Online — the seven-mechanism spoofing catalogue documented here is the receiver-side defense surface, and the hybrid-Exchange spoke is the canonical operational reference for the sender- side topology-specific configuration steps that must succeed before that defense surface can be deployed.
• DKIM troubleshooting — the SPOOFING-INCIDENT-RESPONSE-PER- MESSAGE-DKIM-VERDICT-SYMPTOM-DRIVEN- FORENSIC-ROOT-CAUSE-ATTRIBUTION- PLAYBOOK companion to this seven- technique spoofing taxonomy. Where THIS page documents the seven canonical spoofing-delivery techniques (display- name spoofing, lookalike-domain registration, header-From-vs-envelope- From disjunction, third-party-vendor compromise, ARC-trust-chain abuse, BEC- pretext-engineering, STARTTLS-strip- and-cleartext-delivery), the DKIM- troubleshooting spoke is the OPERATOR-FACING SYMPTOM-DRIVEN PER- MESSAGE FORENSIC-ATTRIBUTION-PLAYBOOK companion documenting the symptom-to-action diagnostic sequence the SOC analyst runs against the per-message Authentication-Results stamp of the offending spoofing-attack message. Concretely, the spoke documents FOUR spoofing-technique- specific DKIM-verdict-attribution dimensions: (i) lookalike- domain technique dkim=pass with lookalike-domain d=<typosquat-domain> verdict symptom — when the attacker registers a lookalike cousin domain (Punycode-bidi attacks, homoglyph attacks like microsοft.com with Greek omicron) and publishes their own DKIM key under the typosquat domain, the troubleshooting page's identify-which-key-the-signer-used-at- message-sign-time step matches the d=-tag literal against the legitimate publisher's org-domain set and surfaces the Punycode-vs-Unicode glyph divergence as the cryptographically-attestable evidence the SOC analyst forwards to the registrar takedown ticket; (ii) header-From-vs-envelope-From disjunction technique dkim=pass with unaligned d=<attacker-domain> verdict symptom — when the attacker signs the message with their own attacker-controlled domain's DKIM key but rewrites the From: header to a victim-domain identity, the troubleshooting page's compare-the- published-record-bytes step pins the unaligned-d= signing- identity as the discrete-evidence artefact the SOC analyst uses to DISTINGUISH this technique class from the unauthenticated-cleartext-spoofing class (the policy_evaluated.dkim=fail DMARC-non-aligned RUA row is STRUCTURALLY-DIFFERENT from the policy_evaluated.dkim=none unauthenticated-cleartext row); (iii) ARC-trust-chain abuse technique dkim=fail with ARC-Seal cv=pass chain-validation verdict symptom — when the attacker exploits a forwarder's ARC- sealing infrastructure to launder an otherwise-spoofed message through the ARC-trust-chain mechanism, the troubleshooting page's c=relaxed/relaxed vs c=simple/simple canonicalization-pair-inheritance step matches the per-AMS canonicalization- pair byte-shape against the original- signer's emitted byte-shape and surfaces the cryptographically-attestable forwarder-attribution evidence the SOC analyst uses to escalate to the forwarder operator's abuse contact; (iv) third-party-vendor compromise technique dkim=pass with LEGITIMATE vendor d=<vendor-domain> verdict symptom AND ROUTING-anomalous per-day per-hour volume spike — when the attacker has compromised a legitimate third-party-vendor mailbox and emits spoofed mail through the vendor's own DKIM signing infrastructure, the troubleshooting page's identify-which-signer-key-the- per-message-b=-tag-was- generated-against step confirms the message DOES match the vendor's published DKIM key — the NEGATIVE- EVIDENCE (the SOC analyst cannot attribute the message to cryptographic-key-forgery) is itself the discrete evidence the SOC analyst escalates to the third-party-vendor relationship-owner for vendor-side Stage 3 incident-response coordination. Read the DKIM-troubleshooting symptom- driven playbook ALONGSIDE this seven- technique spoofing taxonomy to attribute every per-message DKIM verdict in the SOC's Authentication-Results inventory or per-row RUA aggregate-report XML to the specific spoofing-technique-attack- pattern responsible — the spoke is the operator-facing per-message diagnostic primitive the spoofing-incident- response workflow this technique taxonomy coordinates depends on.
• DMARC policy modes — the PER-SPOOFING-TECHNIQUE-CLASS-AS- DOWNSTREAM-CONSUMER-OF-EVERY-P-EQUAL- POLICY-MODE-ENFORCEMENT-DISPOSITION companion to THIS spoofing-technique taxonomy reference. Where THIS page documents the seven canonical spoofing-technique classes (direct- domain spoof, lookalike-domain, cousin-domain, IDN-homograph, display-name spoof, envelope-MAIL- FROM-only spoof, reply-chain hijack), the DMARC-policy-modes spoke is the publisher-side ENFORCEMENT DISCIPLINE documenting which spoofing-technique classes each p=-tag value structurally defeats vs leaves open at FOUR per-policy-mode-to- spoofing-technique-class dimensions: (i) p=none + all spoofing-technique classes residual — the policy-modes spoke documents how p=none is the rua-stream-only ENFORCEMENT DISPOSITION that surfaces every spoofing-technique-class artefact THIS page documents in the rua- aggregate-XML telemetry but does NOT structurally defeat any of them at receiver-side disposition time — the page is the operator's reminder that p=none publication leaves ALL seven spoofing-technique- classes THIS page catalogues as residual attack vectors; (ii) p=quarantine + direct-domain spoof defeated to spam-folder — the policy- modes spoke documents how p=quarantine defeats the direct-domain spoof technique class (the most common spoofing- technique-class THIS page catalogues) to the spam folder under receiver- side DMARC enforcement but does NOT defeat lookalike-domain / cousin- domain / IDN-homograph classes because those spoof a DIFFERENT Header-From domain altogether; (iii) p=reject + direct-domain spoof defeated to SMTP-bounce — the policy- modes spoke documents how p=reject defeats the direct-domain spoofing-technique- class THIS page documents at SMTP- time bounce — the strongest receiver-side disposition the publisher can publish — but deliberately leaves lookalike-domain, cousin-domain, IDN-homograph, and display-name spoofing-technique- classes as residual attack vectors that DMARC does NOT cover (the publisher must layer BIMI + VMC + recipient-side anti-phishing controls on top); (iv) sp= + subdomain-spoof technique class scope — the policy-modes spoke documents how sp= explicitly publishes the disposition for subdomain-Header-From-spoofing attacks (the technique-class attackers exploit when publisher publishes p=reject at the org-domain but does NOT publish sp=reject at the same domain) — the spoke is the operator's reminder that sp= closes the per- subdomain attack-surface THIS page's subdomain-spoofing-technique- class catalogue documents. Read THIS page when CLASSIFYING the spoofing-technique-class observed in incident-response; read the DMARC-policy-modes spoke when scheduling WHICH receiver-side disposition defeats the spoofing- technique-class observed.
• DMARC reporting pipeline — the PER-SPOOFING-TECHNIQUE-CLASS-AS- DOWNSTREAM-CONSUMER-OF-RUA-AGGREGATE- XML-EVIDENCE-STREAM-FOR-PER-SOURCE-IP- SPOOFING-DETECTION-EVIDENCE companion to THIS spoofing-technique-class taxonomy. Where THIS page documents the seven canonical spoofing-technique classes (direct-domain spoof, lookalike-domain, cousin-domain, IDN-homograph, display-name spoof, envelope-MAIL-FROM-only spoof, reply- chain hijack), the DMARC-reporting- pipeline spoke is the RECEIVER-SIDE TELEMETRY infrastructure documenting how the rua-aggregate-XML stream produced by receivers feeds per- spoofing-technique-class detection evidence at FOUR per-spoofing- technique-class-to-rua-source-IP- attribution dimensions: (i) direct-domain spoofing rua-aggregate-XML per-source-IP detection — the reporting- pipeline spoke documents how the rua-aggregate-XML per-row source_ip + identifiers.header_from + policy_evaluated.disposition cross-product surfaces the unauthorised source IPs that emitted mail with the publisher's exact Header-From domain — the load-bearing detection evidence for the direct-domain spoofing-technique-class THIS page documents; (ii) envelope- MAIL-FROM-only spoofing rua-evidence — the reporting-pipeline spoke documents how the rua-aggregate-XML auth_results.spf.domain vs identifiers.header_from divergence surfaces messages where the envelope-MAIL-FROM is the attacker's domain but the Header-From is the publisher's domain — the envelope-MAIL-FROM-only spoofing- technique-class THIS page documents relies on this rua-row divergence evidence; (iii) shadow-IT sender mistakenly-classified-as- spoofing rua-discovery — the reporting-pipeline spoke documents how the rua-aggregate-XML per-row source-IP discovery surfaces legitimate-but-unauthorised tenants (shadow-IT marketing teams, forgotten ESP integrations, leftover test accounts) that LOOK like spoofing-technique-class attacks but are not — the spoke is the operator's reminder that the spoofing-technique-class taxonomy THIS page documents must be applied AFTER the shadow-IT-discovery workflow the rua-stream produces; (iv) per-receiver spoofing-detection-coverage divergence rua-evidence — the reporting-pipeline spoke documents how rua-aggregate-XML per-receiver coverage varies (Google reports almost all spoofing classes, Microsoft reports partial, Yahoo reports per-Yahoo- tenant subset, smaller receivers do not emit rua at all) — the per-receiver coverage divergence is the structural evidence the spoofing-technique-class attribution THIS page documents must reckon with. Read THIS page when CLASSIFYING the spoofing- technique-class observed in an incident; read the DMARC- reporting-pipeline spoke when ARCHITECTING the rua-stream infrastructure that surfaces the per-source-IP spoofing-detection evidence the per-spoofing- technique-class attribution THIS page documents depends on.
• SPF mechanism comparison: include vs ip4 vs a vs mx — the RFC-7208-§5-PER-MECHANISM- EVALUATION-CATALOGUE-AS-LOAD- BEARING-PER-SOURCE-IP-ANTI- SPOOFING-AUTHORIZATION-PRIMITIVE companion to this email-spoofing threat-classification reference. Where THIS page documents the seven spoofing-technique-class taxonomy (envelope-from spoofing, display-name spoofing, look-alike domain spoofing, exact-domain spoofing, compromised-account sending, cousin-domain spoofing, IDN/Punycode homograph spoofing), the include_vs_ip4_vs_a_vs_mx spoke documents the per-RFC-7208- §5-mechanism-choice catalogue at FOUR per-mechanism-choice-vs- spoofing-technique-class coupling dimensions: (i) per- publisher per-mechanism-correct SPF-record AUTHORING AS LOAD- BEARING per-source-IP envelope- from spoofing DETECTION primitive — every envelope-from spoofing attempt presents a forged envelope-MAIL-FROM whose claimed domain's published SPF-record per- RFC-7208-§5-mechanism evaluation determines per-source-IP authorization-pass-or-fail; the include_vs_ip4_vs_a_vs_mx spoke documents the per-mechanism- choice catalogue whose per- mechanism-correct authoring IS the load-bearing per-publisher per-source-IP envelope-from spoofing detection primitive THIS page documents the receiver-side outcome of; (ii) per- publisher per-mechanism-driven per-source-IP SPF-ALIGNED-PASS EVALUATION AS LOAD-BEARING exact-domain spoofing DETECTION primitive at the per-receiver DMARC-alignment boundary — exact-domain spoofing produces envelope-MAIL-FROM and Header- From-domain identity equivalence with the legitimate publisher's domain; the receiver's DMARC- alignment evaluator depends on the per-publisher per-RFC-7208- §5-mechanism-correct SPF-record producing per-source-IP spf=fail for the attacker-controlled source-IP outside the per- publisher per-mechanism-authorized source-IP set; the include_vs_ ip4_vs_a_vs_mx spoke documents the per-mechanism-choice catalogue whose per-mechanism- correct authoring IS the load- bearing exact-domain spoofing detection primitive at the per- receiver DMARC-alignment boundary THIS page documents; (iii) per-publisher per- mechanism RFC-7208-§4.6.4-TEN- DNS-LOOKUP-CEILING-OVERFLOW AS LOAD-BEARING attack-surface- AMPLIFIER for per-publisher compromised-account-sending and look-alike-domain spoofing techniques — per- publisher per-mechanism-cascade overflow producing spf=permerror verdicts collapses per-source- IP authorization-evaluation at receivers, structurally AMPLIFYING the attack-surface for both compromised-account- sending (where attacker abuses legitimate sender's permerror- collapsed authentication) and look-alike-domain spoofing (where attacker registers a cousin-domain whose SPF-record deliberately exploits the legitimate publisher's permerror state); the include_ vs_ip4_vs_a_vs_mx spoke documents the per-mechanism- cutover remediation disciplines (flattening include: tokens, per-stream envelope-domain isolation) whose preservation IS the load-bearing per- publisher attack-surface- compression discipline against the compromised-account and look-alike-domain spoofing technique classes THIS page documents; (iv) per- publisher deprecated ptr: mechanism RFC-7208-§5.5-DEPRECATION AS LOAD-BEARING per-source-IP anti-spoofing-publication- discipline INVARIANT — RFC 7208 §5.5 explicitly deprecates the ptr: mechanism for SPF evaluation, but per- source-IP PTR-RR / FCrDNS publication remains operationally critical for receiver-side per-source-IP identity-attribution against IP-routing-layer spoofing- technique classes; the include_vs_ip4_vs_a_vs_mx spoke documents the per- mechanism-deprecation invariant whose receiver- side semantic IS the structural complement to the per-source-IP PTR-RR FCrDNS-publication discipline every IP- routing-layer-attributed spoofing-technique-class detection THIS page documents depends on. Read the include_vs_ip4_vs_a_ vs_mx spoke alongside this email-spoofing threat- classification reference whenever the per-publisher operator scopes a per- publisher per-source-IP anti-spoofing-authorization- publication plan — the per- RFC-7208-§5-mechanism- catalogue per-mechanism- correct authoring discipline the spoke documents IS the canonical UPSTREAM per- source-IP anti-spoofing- authorization primitive every spoofing-technique- class taxonomy THIS page documents structurally depends on for per-source- IP-attributed authentication- failure detection.
• Email Header Analyzer — paste a raw email header and the tool surfaces the Authentication-Results verdict, IDN/Punycode form detection, Received: chain anomalies, and Reply-To mismatches automatically.
• Domain Security Checker — verify your own domain's SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, and CAA configuration in one place.
• DNS Record Generator — generate publish-ready SPF, DKIM, DMARC, TLS-RPT, MTA-STS, CAA, and BIMI records for your domain.
• BIMI explained — the AUTHENTICATED-BRAND-LOGO-AS-DIRECT- DOMAIN-SPOOFING-COUNTERMEASURE-VISUAL- SIGNAL companion to this email-spoofing TECHNIQUE-level reference. Where THIS page catalogues the seven canonical spoofing techniques (direct domain, envelope MAIL FROM, display-name, lookalike, IDN homograph, cousin, subdomain takeover) plus their Authentication-Results-header detection signatures, the BIMI-explained spoke documents the receiver-rendered authenticated-brand logo as the front-end recipient-perceivable visual signal that converts each spoofing technique's backend Authentication-Results verdict into a front-end inbox-list visual cue end-users learn to recognise. Concretely, the spoke documents FOUR per-spoofing- technique-visual-countermeasure dimensions: (i) direct-domain spoofing countered by the brand-logo- absence visual cue at the BIMI-aware receiver — when an attacker forges From: brand.com but cannot generate a passing DMARC verdict, the BIMI-supporting mailbox provider suppresses the brand logo on the spoofed message; the spoke documents how the logo-absence on a purported brand message becomes the END-USER- PERCEIVABLE counterpart to the backend dmarc=fail verdict this page's §6 (Authentication-Results detection) catalogues; (ii) lookalike-and-cousin-domain spoofing countered by the brand-logo-absence on the lookalike-domain message — when an attacker registers brand-support.com or secure-brand.com and publishes their own DMARC + DKIM infrastructure (achieving a passing verdict ON THE LOOKALIKE DOMAIN), the BIMI-supporting receiver still suppresses the legitimate brand's logo because the lookalike domain has no default._bimi publication AND no VMC under the genuine brand's trademark; the spoke documents how this differentiates the cousin-domain spoofing technique catalogued in §3.4 of this page from genuine brand mail at the recipient's inbox-list surface; (iii) IDN-homograph spoofing countered by the brand-logo-absence on the Punycode-encoded display-domain message — when an attacker registers xn--brnd-hoa.com (visual brànd.com) and publishes BIMI + DKIM under the Punycode form, the receiver still suppresses the genuine brand's logo because the BIMI publication is anchored to the trademarked organisation identifier in the VMC, not the visual- glyph form; the spoke documents how this IDN-homograph countermeasure complements this page's §3.5 IDN- detection workflow at the recipient- side visual surface; and (iv) envelope-MAIL-FROM-only spoofing countered by the brand-logo presence on ARC-sealed forwarded brand mail — when a legitimate brand message is forwarded through a Trusted-ARC-Sealer intermediary (mailing list, vacation forwarder, security gateway), the envelope MAIL FROM rewrites but the author-domain DKIM signature survives ARC validation; the spoke documents how the BIMI-supporting receiver still renders the brand logo on the forwarded message — DISTINGUISHING the legitimate forwarded brand mail from the envelope- MAIL-FROM-only spoofing technique catalogued in §3.2 of this page where the author-domain DKIM signature is ABSENT. Read the BIMI-explained spoke alongside this email-spoofing TECHNIQUE- level reference when the recipient-side visual-countermeasure surface is the load-bearing detection layer the brand- protection programme must operationalise beyond the backend Authentication- Results header.
• DKIM key rotation — the PER-PUBLISHER-PER-SELECTOR-KEY- ROTATION-OPERATIONAL-DISCIPLINE-AS-LOAD- BEARING-DKIM-SIGNATURE-FRESHNESS-AND- REPLAY-EXPOSURE-WINDOW-BOUND-CONTROL companion to this email-spoofing technique- level reference. Where THIS page documents the email-spoofing technique catalogue (envelope MAIL FROM forgery + From-header display-name impersonation + cousin-domain registration + DKIM-replay-attack reuse of a previously-captured-and-valid DKIM- Signature header against unrelated message bodies + look-alike-typo-squat domains + compromised-account first-party impersonation + Reply-To-header redirection attacks), the DKIM-key-rotation spoke is the per-publisher per-selector operational- discipline reference whose per-rotation cadence + overlap + custody + disposal discipline directly bounds the DKIM-replay- attack technique catalogued on THIS page at four signature-freshness-window-control coupling dimensions: (i) per- publisher per-rotation cadence bounds the per-signature-replay-exposure-window primitive — a captured DKIM- Signature can only be replayed AGAINST a receiver-side public-key-cache-fetch lookup WHILE the per-selector public-key TXT record remains live in DNS; the per- publisher per-rotation cadence THIS DKIM- key-rotation spoke documents (annual / quarterly / per-incident emergency rotation) directly bounds the per- signature replay-exposure-window at the per-rotation retired-selector-deletion cutover — the shorter the per-publisher per-rotation cadence, the tighter the per- signature replay-exposure-window the attacker can exploit; (ii) per- rotation private-key-disposal discipline bounds the private-key-compromise-replay- scope primitive — a compromised per-publisher per-selector private key enables the attacker to FORGE per-message DKIM-Signatures (not just replay captured ones) — the per-publisher per-rotation private-key-disposal-on-retirement discipline THIS DKIM-key-rotation spoke documents (HSM-erasure on retired- selector cutover + per-rotation key- generation-environment-isolation + absolutely no per-rotation private-key backup-to-cold-storage) bounds the private-key-compromise-replay-scope to the active-selector window only; (iii) per-rotation cryptographic-strength-upgrade discipline bounds the per-signature cryptographic-collision-resistance primitive — the per-publisher per-rotation 1024-to-2048-bit RSA upgrade + optional Ed25519 transition discipline THIS DKIM-key-rotation spoke documents directly bounds the per-signature cryptographic-attack-resistance primitive every DKIM-replay-attack signature capture-and-replay technique consumes — the per-publisher per-rotation cryptographic-strength-floor-enforcement primitive prevents the per-publisher per- selector cryptographic-foundation- downgrade pathway every DKIM-replay- attack exploit chain consumes; (iv) per-rotation dual-selector overlap-window discipline bounds the per- rotation cutover-window replay- exploitation primitive — during the per-publisher per-rotation cutover overlap-window, BOTH the OLD and NEW selectors are live in DNS; an attacker with a captured OLD-selector signature can replay it for the duration of the per-rotation overlap-window — the per- publisher per-rotation overlap-window- must-exceed-receiver-side-DNS-cache-TTL- but-not-by-more-than-discipline THIS DKIM-key-rotation spoke documents bounds the per-rotation cutover-window replay- exploitation primitive to the minimum DNS-propagation-window required for zero-downtime cutover. Read the DKIM- key-rotation spoke ALONGSIDE this email- spoofing technique catalogue whenever the per-publisher per-domain DKIM- replay-attack technique surface needs the per-publisher per-selector key- rotation operational-discipline reference whose four discipline dimensions are the load-bearing per-signature-freshness- and-replay-exposure-window-bound-control primitives the DKIM-replay-attack spoofing technique on THIS page structurally consumes.
• DMARC for cPanel / WHM shared-hosting deployments — the per-cPanel-account per-customer- domain DMARC publication workflow at the WHM Email Deliverability auto-generation flow whose per-account p=quarantine / p=reject publication decision is the per-cPanel-account- defender-side enforcement primitive that closes the per-customer-domain spoofing attack class THIS page documents at the receiver-side per-message DMARC-disposition evaluation boundary. cPanel shared-hosting customer-domains are a high-frequency spoofing target precisely because the per-customer-domain DMARC TXT record is often missing or stuck at p=none — read THIS spoofing-techniques reference alongside the cPanel deployment guide so the per-cPanel-account per-customer-domain DMARC-publication discipline accounts for the canonical six spoofing-attack classes this page enumerates (display-name spoofing, lookalike-domain registration, cousin-domain Punycode homograph, envelope-MAIL-FROM disjoint-domain spoofing, DKIM-replay-attack, ARC-seal-absent forwarded-mail injection) at the per- customer-domain DMARC-publication boundary the cPanel deployment guide documents.
• SPF mechanisms explained — the SPF-MECHANISM-AUTHORIZATION-VOCABULARY- AS-CANONICAL-PUBLISHER-SIDE-PRIMITIVE-DEFEATING- SPECIFIC-SPOOFING-ATTACK-CLASS-VARIANTS companion to this email-spoofing threat-class taxonomy. Where THIS page documents the canonical spoofing-attack-class taxonomy (display-name spoofing, From:-header exact-domain spoofing, envelope-MAIL-FROM disjoint-domain spoofing, lookalike / cousin-domain registration, Punycode homograph, DKIM-replay-attack, ARC-seal-absent forwarded-mail injection) at the receiver-side per-message DMARC-disposition evaluation boundary, the SPF-mechanisms spoke is the PUBLISHER-SIDE-AUTHORIZATION-VOCABULARY companion documenting the per-mechanism authorization scope vocabulary the per-publisher per-domain v=spf1 TXT-record uses to defeat the envelope-MAIL-FROM disjoint-domain spoofing attack variant and the source-IP forgery variant the spoofing-techniques taxonomy enumerates. The spoofing-taxonomy-vs- SPF-mechanisms relationship is per-spoof- variant-defeated-by-specific-mechanism-class: the per-publisher per-domain SPF mechanism choice determines which spoofing variant is defensively closed at the first-hop SPF evaluation boundary. Four per-mechanism-vs- spoofing-variant defensive coupling dimensions matter at the per-publisher per-domain SPF- authorization vocabulary boundary: (i) include: cascade mechanism vs envelope-MAIL-FROM ESP-impersonation spoofing — per-publisher include:<esp-pool> authorizes the per-ESP-managed outbound IP- pool to author envelope-MAIL-FROM for the per- publisher per-domain, blocking the envelope- MAIL-FROM spoofing variant where an attacker from a NON-authorized IP-pool would attempt to author envelope-MAIL-FROM under the publisher's domain; (ii) ip4: / ip6: literal CIDR mechanism vs source-IP forgery — per-publisher ip4:<CIDR> / ip6:<CIDR> literal CIDR publication authorizes a specific per-publisher per-domain outbound IP-range, blocking the source-IP forgery variant where an attacker from an out-of-range source-IP would attempt to author envelope-MAIL-FROM under the publisher's domain at the receiver-side SPF evaluator first-hop boundary; (iii) all default-disposition qualifier choice (-all hardfail / ~all softfail / ?all neutral / +all dangerously- permissive) vs spoofing-attempt receiver-side disposition — the per-publisher per-domain -all hardfail discipline produces the receiver-side spf=fail verdict on every spoofing-attempt from an unauthorized source-IP, while +all publication effectively authorizes ALL source-IPs to spoof the per-publisher domain at the SPF-evaluation boundary; (iv) a: / mx: per-publisher-managed RR- target mechanism vs lookalike-domain spoofing — per-publisher a:<hostname> and mx:<hostname> authorizations point to per-publisher-managed infrastructure that lookalike-domain registrations (cousin-domain Punycode homograph attacks the spoofing-techniques taxonomy enumerates) cannot replicate without controlling the per-publisher per-domain authoritative DNS zone, so the per-publisher per-domain SPF mechanism vocabulary serves as a per-publisher per-domain infrastructure- binding primitive distinguishing the per- publisher per-domain authorized senders from cousin-domain attackers. Read THIS page when UNDERSTANDING the canonical spoofing-attack- class taxonomy receivers materialise at the per-message DMARC-disposition evaluation boundary; read the SPF-mechanisms spoke when AUTHORING the per-publisher per-domain SPF authorization-vocabulary publication discipline whose first-hop SPF-evaluation primitive is the load-bearing per-publisher defense against the envelope-MAIL-FROM disjoint-domain spoofing and source-IP forgery variants the spoofing-techniques taxonomy enumerates.
• TLS-RPT explained — the canonical spoofing-attack taxonomy this page enumerates focuses on the envelope-MAIL-FROM disjoint-domain, display-name, lookalike-domain and source-IP-forgery variants the application-layer DMARC composite verdict gates against. TLS-RPT surfaces the parallel transport-layer spoofing variants — TLS-negotiation downgrade attempts, STARTTLS stripping, certificate-mismatch interception — that operate below the DMARC evaluation boundary against the same publisher per-domain mail flow. Together the two observability streams cover both authentication-layer and transport-layer attack-class detection across the per-publisher per-domain mail flow.
• SPF for Microsoft 365 — the per-M365-tenant per-accepted-domain envelope-MAIL-FROM-layer SPF publication- discipline companion to this email- spoofing threat-model reference. Where THIS page documents the per-publisher per-domain email-spoofing attack-class taxonomy (envelope-MAIL-FROM spoofing, RFC 5322 From-header spoofing, display- name spoofing, look-alike-domain spoofing, IDN homograph spoofing, BEC executive-impersonation spoofing), the SPF-for-Microsoft-365 spoke documents the per-M365-tenant per-accepted-domain envelope-MAIL-FROM-layer SPF publication- discipline whose per-tenant per-accepted- domain v=spf1 include:spf.protection.outlook.com -all record IS the load-bearing per-tenant per-accepted-domain envelope-layer anti- spoofing defense primitive enforcing per- message envelope-MAIL-FROM authorization at every per-receiver-side acceptance gate. Four per-M365-tenant per-accepted- domain spoofing-defense coupling dimensions matter at the per-tenant per- accepted-domain composite anti-spoofing defense boundary: (i) per-M365-tenant per- accepted-domain envelope-MAIL-FROM spoofing-defense — the per-tenant per- accepted-domain -all hard-fail SPF qualifier terminates per-tenant per-accepted-domain envelope-MAIL-FROM spoofing attempts at the per-receiver SPF-verification gate, the per-tenant per-accepted-domain SPF publication-discipline THIS email- spoofing reference documents as the canonical envelope-layer anti-spoofing defense; (ii) per-M365-tenant per- accepted-domain DMARC-aligned-pass composite-verdict cascade — the per- tenant per-accepted-domain DMARC composite-verdict pass requires AT LEAST ONE aligned-pass leg (DKIM-aligned-pass OR SPF-aligned-pass) per RFC 7489 §3.1; the per-tenant SPF- aligned-pass leg the SPF-for-Microsoft- 365 spoke documents IS the per-tenant envelope-layer authentication-leg every per-receiver-side per-message DMARC composite-verdict-pass evaluation depends on for the per-tenant per- accepted-domain composite anti-spoofing defense; (iii) per-M365-tenant per- accepted-domain RFC 5322 From-domain organisational-domain alignment evaluation — the per-tenant per-accepted- domain envelope-MAIL-FROM-domain vs RFC 5322 From-domain organisational-domain alignment evaluation per RFC 7489 §3.1.1 relaxed-mode Public-Suffix-List walk IS the per-tenant per-accepted-domain envelope-layer evidence-attribution primitive that surfaces look-alike-domain + IDN-homograph spoofing attempts at the per-tenant alignment-evaluation boundary THIS email-spoofing reference catalogues defense-discipline for; (iv) per-M365- tenant per-accepted-domain composite anti-spoofing defense portfolio — the per- tenant per-accepted-domain composite SPF + DKIM + DMARC + ARC + BIMI publication portfolio IS the per-tenant per-accepted- domain canonical anti-spoofing defense portfolio THIS email-spoofing reference documents threat-model coverage for; the per-tenant per-accepted-domain SPF publication-discipline the SPF-for- Microsoft-365 spoke documents IS the load-bearing per-tenant envelope-layer anti-spoofing-defense-portfolio component every per-tenant per-accepted- domain anti-spoofing defense discipline depends on at the per-tenant per- accepted-domain composite envelope-and- application-layer anti-spoofing-defense- portfolio coordination floor. Read THIS page when AUTHORING the per-publisher per-domain email-spoofing threat-model coverage; read the SPF-for-Microsoft-365 spoke when AUTHORING the per-M365-tenant per-accepted-domain envelope-MAIL-FROM- layer SPF publication that per-tenant per-accepted-domain composite anti- spoofing defense THIS page documents depends on as the per-tenant envelope- layer anti-spoofing-defense primitive.
• DKIM for Microsoft 365
• DMARC troubleshooting
• DKIM best practices
• DMARC for Microsoft 365 — the PER-M365-TENANT-PER-ACCEPTED-DOMAIN-DMARC-COMPOSITE-VERDICT-LAYER-PUBLICATION-DISCIPLINE-AS-LOAD-BEARING-COMPANION-TO-SEVEN-TECHNIQUE-EMAIL-SPOOFING-ATTACK-CATALOGUE companion at four per-M365-tenant per-accepted-domain DMARC-vs-seven-technique-spoofing coupling dimensions: (i) per-M365-tenant per-accepted-domain DMARC p=reject terminal-stage publication-decision per RFC 7489 §6.3 IS the load-bearing per-tenant per-accepted-domain composite-verdict enforcement-floor closing the DIRECT-DOMAIN-SPOOF attack-class (technique 1/7 — RFC 5322 From: forgery) THIS seven-technique catalogue documents at the per-publisher per-domain composite anti-spoofing defense floor; (ii) per-M365-tenant per-accepted-domain DMARC adkim=s + aspf=s strict-alignment-mode publication-decision IS the load-bearing per-tenant per-accepted-domain identifier-alignment-discipline closing the LOOKALIKE-DOMAIN + COUSIN-DOMAIN + IDN-HOMOGRAPH spoof attack-classes (techniques 4 + 5 + 6/7) THIS seven-technique catalogue documents through the per-publisher per-domain strict-alignment-mode publication-discipline; (iii) per-M365-tenant per-accepted-domain DMARC sp=reject subdomain-policy-tag publication-decision per RFC 7489 §6.3 IS the load-bearing per-tenant per-accepted-domain subdomain-policy-discipline closing the SUBDOMAIN-TAKEOVER spoof attack-class (technique 7/7) the seven-technique catalogue THIS page documents at the per-publisher per-subdomain composite anti-spoofing defense floor; (iv) per-M365-tenant per-accepted-domain DMARC RUA aggregate-report per-day per-source-IP per-row attribution-stream IS the load-bearing per-tenant per-accepted-domain detection-evidence stream surfacing per-attacker per-message ENVELOPE-MAIL-FROM-SPOOF + COMPROMISED-ACCOUNT-SPOOF attack-classes (techniques 2 + 3/7) the seven-technique catalogue THIS page documents the per-publisher per-domain forensic-detection workflow of materially depends on for incident-visibility coverage floor preservation.
• Email authentication glossary
• CAA records explained — the PER-PUBLISHER-PER-DOMAIN-CAA-RR-PKI-LAYER-PER-CA-ALLOWLIST-PUBLICATION-DISCIPLINE-AS-LOAD-BEARING-EIGHTH-PROTOCOL-IN-SEVEN-TECHNIQUE-ANTI-SPOOFING-DEFENSE-STACK-CLOSING-PER-ATTACKER-PER-LOOKALIKE-DOMAIN-AND-PER-COUSIN-DOMAIN-PKI-LAYER-CERT-MIS-ISSUANCE-ATTACK-CLASS-SUBSET companion at four per-publisher per-domain CAA-RR-publication-discipline-vs-seven-technique-spoofing-attack-catalogue coupling dimensions: (i) per-publisher per-domain CAA-RR 0 issue "<ca-domain>" property-tag publication-discipline per RFC 8659 §4.2 IS the load-bearing per-publisher per-domain PKI-layer anti-CA-impersonation primitive closing per-attacker per-target-domain rogue-CA cert-issuance attack-class subset of the LOOKALIKE-DOMAIN (technique 4/7) + COUSIN-DOMAIN (technique 5/7) + IDN-HOMOGRAPH (technique 6/7) attack-classes THIS seven-technique catalogue documents — per-attacker per-lookalike/cousin/IDN-homograph-domain infrastructure-provisioning materially depends on per-attacker per-domain HTTPS-enabled credential-harvesting + spear-phishing message-source infrastructure whose per-attacker per-domain TLS-cert acquisition the per-publisher per-domain CAA-RR per-CA-allowlist enforcement at per-CA-issuance time per RFC 8659 §3 BLOCKS; (ii) per-publisher per-domain CAA-RR per-CA-allowlist publication-discipline IS the EIGHTH protocol in the per-publisher per-domain composite anti-spoofing defense-in-depth publication-discipline stack (alongside the SPF + DKIM + DMARC + BIMI + MTA-STS + DANE + TLS-RPT seven-standards application-and-transport-layer defense-stack the seven-technique attack-catalogue THIS page documents the per-publisher per-domain composite anti-spoofing defense-stack-floor coordination of) — closing the per-attacker per-lookalike-domain + per-cousin-domain + per-IDN-homograph PKI-layer cert-mis-issuance attack-class subset that the per-publisher per-domain seven-standards SMTP-layer defense-stack does not structurally address; (iii) per-publisher per-domain CAA-RR 0 iodef "mailto:<security-contact>" property-tag publication-discipline per RFC 8659 §4.4 IS the per-publisher per-domain operator-side per-CA-mis-issuance-incident attribution-mailbox publication primitive structurally parallel to per-publisher per-domain DMARC rua=mailto: aggregate-report-URI + ruf=mailto: forensic-report-URI publication-discipline per RFC 7489 §6.2 the per-publisher per-domain seven-technique attack-catalogue THIS page documents the per-publisher per-domain operator-side forensic-detection workflow of materially consumes for per-attacker per-target-domain per-mis-issuance-event attribution-discipline; (iv) per-publisher per-domain CAA-RR publication-discipline drift (missing CAA-RR at apex / overly-permissive `0 issue ";"` deny-all-but-self mis-publication / missing `iodef` incident-mailbox / CAA-RR DNSSEC-unsigned-zone exposing per-attacker per-zone CAA-RR DNS-cache-poisoning attack-class) directly opens per-publisher per-domain PKI-layer per-attacker per-target-domain rogue-CA cert-issuance attack-window structurally parallel to per-publisher per-domain SPF `+all` permissive-mis-publication + DMARC `p=none` permissive-publication-discipline drift the per-publisher per-domain seven-technique anti-spoofing catalogue THIS page documents the per-publisher per-domain composite anti-spoofing defense-stack-floor coordination of catalogues against — together the per-publisher per-domain seven-technique email-spoofing attack catalogue THIS page documents the per-publisher per-domain composite SMTP-application-and-transport-layer anti-spoofing defense-stack-floor coordination of AND the per-publisher per-domain CAA-RR PKI-layer per-CA-allowlist publication-discipline compose the per-publisher per-domain composite eight-protocol cross-layer authentication-and-PKI publication-discipline-floor coordination boundary.
• MTA-STS for Google Workspace — (i) per-Workspace-tenant per- custom-domain MTA-STS policy file mode: enforce publication- decision per RFC 8461 §3.2 IS the load-bearing per-Workspace-tenant per- custom-domain transport-layer per- receiving-MTA TLS-enforcement primitive closing the per-attacker per-target- Workspace-domain TRANSPORT-LAYER-MITM- DOWNGRADE attack-class subset that the seven-technique application-layer attack catalogue THIS page documents does NOT structurally address — per-attacker per-receiving-MTA STARTTLS-stripping + per-attacker per-receiving-MTA cert- substitution attack-classes are closed at the per-Workspace-tenant per- receiving-MTA enforcement-mode policy- fetch boundary; (ii) per-Workspace- tenant per-custom-domain MTA-STS mx:-pattern publication- discipline (canonical mx: aspmx.l.google.com + Workspace fallback MX hosts alt1.. alt4) is structurally PARALLEL to per-Workspace- tenant per-custom-domain SPF include:_spf.google.com envelope-MAIL-FROM-layer publication- discipline closing the per-attacker per- Workspace-tenant per-receiving-MX-host SUBSTITUTE-RECEIVING-MTA spoof attack- class subset of techniques 4 + 5 + 6/7 (lookalike / cousin / IDN-homograph) at the per-Workspace-tenant MX-publication- cohort boundary; (iii) per-Workspace- tenant per-custom-domain MTA-STS _mta-sts.<workspace-tenant> TXT-RR id=-tag rotation publication-discipline per RFC 8461 §3.1 is the per-Workspace-tenant per-custom-domain receiver-side policy- cache-invalidation primitive structurally parallel to per-Workspace-tenant per- custom-domain DMARC RUA-stream surface feeding per-day per-receiving-MTA TLS-RPT JSON-aggregate-report failure-details attribution the per-publisher per-domain seven- technique catalogue THIS page documents the per-publisher per-domain operator- side forensic-detection workflow of materially consumes for per-attacker per-receiving-MTA transport-layer attribution; and (iv) per-Workspace- tenant per-custom-domain MTA-STS publication-discipline IS the transport- layer (sixth) protocol in the per- publisher per-domain composite anti- spoofing defense-in-depth publication- discipline stack (alongside SPF + DKIM + DMARC + BIMI application-layer + DANE transport-layer + TLS-RPT transport- layer-observability + CAA PKI-layer) closing the per-attacker per-Workspace- tenant per-target-domain per-receiving- MTA-cohort TLS-downgrade + cert- substitution attack-class subset the per-publisher per-domain composite anti- spoofing defense-stack-floor coordination THIS page documents materially depends on for per-Workspace-tenant per-receiving- MTA TLS-enforcement-coverage floor preservation. Read the MTA-STS-for- Workspace spoke alongside this seven- technique spoofing catalogue when AUTHORING per-Workspace-tenant per- custom-domain composite cross-protocol anti-spoofing defense-stack publication- discipline, or when INVESTIGATING per- Workspace-tenant per-receiving-MTA TLS- downgrade-attack incident root-cause traceable to per-Workspace-tenant per- custom-domain MTA-STS publication- discipline drift.
• MX records explained — the inbound-routing companion to this spoofing techniques-and-defenses page. The MX records select the mail exchangers a domain receives mail at, so every inbound spoofing attempt this page catalogues is delivered to the receiver named by the recipient's MX set — and the receiver-side SPF / DKIM / DMARC evaluation that decides whether a forged From: header is quarantined or rejected runs at exactly that MX-selected boundary. A misordered or stale MX-RR set can route inbound mail through an unintended exchanger that does not enforce the domain's authentication policy. Read the MX-records spoke to understand the inbound-routing layer at which the anti-spoofing verdict this page documents is actually applied.
• SPF PermError vs TempError
• DMARC for SaaS & platform senders (per-tenant DKIM, From-domain alignment, and the subdomain strategy a platform uses to reach p=reject) — SaaS platforms are prime impersonation targets: their transactional mail is trusted, high-volume, and easy to mimic, so the direct-domain-spoof and lookalike techniques in this catalogue land hard against them. The SaaS-senders guide is the defensive deployment path — it shows a platform how to lock its sending domain to DMARC enforcement so the spoofing attack-classes here are rejected at the receiver.
• DKIM DNS record syntax — DKIM is one of the three message-authentication legs that close the spoofing techniques this catalogue documents; read the DKIM DNS syntax reference to publish the <selector>._domainkey public-key TXT-RR (v=DKIM1; k=rsa; p=<base64-pubkey>) that lets receivers cryptographically verify a signature and reject forged mail at the message layer.
• 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. Verify your spoofing protection now

The DMARC Analyzer platform automates spoofing detection and prevention across the seven-technique surface area documented on this page. The includes/DnsChecker.php module audits your SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, and CAA records; the includes/DmarcParser.php module ingests DMARC aggregate (RUA) reports and surfaces failing-authentication source IPs so you can identify spoofing attempts against your domain in real time; includes/EmailHeaderParser.php and includes/ForensicReportParser.php handle Authentication-Results parsing and forensic (RUF) report ingestion for incident response.

Audit my domain spoofing protection Inspect a received Authentication-Results header Sign up — Free plan