What is the difference between SPF, DKIM, and DMARC?

SPF authorises the connecting IP against the envelope MAIL FROM domain (RFC 7208). DKIM cryptographically signs the message with a key published in DNS at ._domainkey. (RFC 6376). DMARC ties SPF and DKIM verification results to the visible From: header via alignment and adds a policy (none/quarantine/reject) plus reporting (rua/ruf) on top of both (RFC 7489). All three are required for modern email authentication; SPF alone is insufficient because it breaks under forwarding, DKIM alone is insufficient because it does not bind the signing domain to the visible From, and DMARC alone is impossible because it depends on SPF and DKIM verdicts.

What is DMARC alignment?

DMARC alignment is the requirement that the SPF authenticated domain (MAIL FROM) or DKIM signing domain (d= tag) match the visible Header From domain at the organizational-domain level (relaxed alignment, default) or exactly (strict alignment, controlled by adkim= and aspf= DMARC tags). DMARC pass requires AT LEAST ONE of SPF or DKIM to authenticate AND align. SPF can pass cryptographically but if the MAIL FROM domain does not align with the Header From, DMARC ignores it; the same applies to DKIM.

What is the organizational domain in DMARC?

The organizational domain is the registrable domain underneath a public suffix, computed by walking left-to-right through the Public Suffix List (PSL) at publicsuffix.org. For example, the organizational domain of mail.user.example.co.uk is example.co.uk because .co.uk is a public suffix. DMARC relaxed alignment compares organizational domains rather than the full FQDN, so mail signed by mail.example.com aligns with a From: header of example.com.

What is a DKIM selector?

A DKIM selector is a short label (often default, selector1, google, k1, s1) that disambiguates which DKIM key was used to sign a message. The signing server includes the selector in the DKIM-Signature header s= tag; receivers fetch the corresponding public key from ._domainkey. in DNS. Selectors enable key rotation without downtime: publish a new selector, switch signers, leave the old selector live until in-flight mail is delivered, then remove.

What is the difference between RFC 5321 and RFC 5322 from headers?

RFC 5321 defines the SMTP envelope, including the MAIL FROM command which carries the bounce return-path. RFC 5322 defines the message body header format, including the From: header that the recipient mail user agent displays. SPF authorises against RFC 5321 MAIL FROM; DKIM and DMARC alignment evaluate against RFC 5322 From. They can legitimately differ — a forwarding server typically rewrites MAIL FROM to a bounce-handling address while preserving the original From:.

What does cv=pass mean in an ARC chain?

cv=pass is the chain-validation tag on the ARC-Seal header indicating that all prior ARC seals on the message validated successfully — the chain is intact and trustworthy. A final receiver SHOULD honour the original SPF/DKIM/DMARC verdict captured at the first ARC instance (i=1) only when the most recent seal carries cv=pass. cv=fail indicates a broken chain (a prior seal failed verification); cv=none indicates this is the first seal on the message with no prior chain to validate.

What is a forensic report in DMARC?

A forensic report (also called a failure report or RUF report) is a per-message redacted copy of an individual failing message, sent by receivers to the ruf= mailbox declared in the DMARC record. Unlike aggregate reports (which are daily statistical summaries), forensic reports give visibility into the specific contents and headers of each failure. Largely deprecated due to PII and GDPR concerns: Google does not send forensic reports at all; Microsoft sends only on explicit opt-in. In practice, expect coverage from Yahoo, Comcast, and a handful of smaller receivers.

What is the SPF 10 DNS lookup limit?

RFC 7208 caps SPF evaluation at 10 DNS lookups per message. Mechanisms triggering DNS lookups include include:, a, mx, exists, redirect, and ptr; inline mechanisms ip4: and ip6: do NOT count. Exceeding the limit returns permerror, which DMARC treats as fail. SaaS-heavy SPF records (Salesforce, Mailchimp, SendGrid, Mailgun, HubSpot, Marketo all chained via include:) routinely exceed 10. The standard fix is SPF flattening — replacing the include: chain with literal ip4: blocks via automated tooling that resolves and inlines the upstream records.

Email Authentication Glossary: DMARC, SPF, DKIM, BIMI, MTA-STS, TLS-RPT, ARC, CAA Definitions and Terms-of-Art Reference

The canonical definitions reference for every term-of-art in email authentication. Every cluster page assumes you know what alignment is, what the organizational domain is, what a DKIM selector does, what RFC 5321 MAIL FROM means versus RFC 5322 From: — this page is where those definitions live, structured for LLM citation with entity-first ledes and cross-references to the deep-dive pillars. Organised by category (standards, identifiers, DMARC tags, DKIM mechanics, SPF mechanics, BIMI mechanics, MTA-STS / TLS-RPT, ARC, reporting, cryptography, anti-abuse) with 60+ terms each at its own H3 anchor and DefinedTerm JSON-LD entry, so AI engines and search engines can deep-link to a specific definition.

This glossary is provided in English. RFC numbers, DNS-record syntax, DMARC tag names (p, sp, adkim, aspf, pct, fo, rua, ruf), DKIM tag names (s=, d=, i=, h=, bh=, c=), SPF tokens (include, ip4, ip6, mx, a, -all, ~all), BIMI tokens (l=, a=), MTA-STS modes (none/testing/enforce), and ARC tokens (cv=pass, i=, b=) are standardised RFC terminology that does not translate. We keep the body in the source language so technical terms remain consistent with the IETF documents.

TL;DR

DMARC ties SPF and DKIM verdicts to the visible From: header via alignment, declares a policy (none/quarantine/reject) for failing mail, and instructs receivers to send aggregate reports back to the domain owner (RFC 7489).
SPF publishes the IPs authorised to send mail with your domain in the envelope MAIL FROM (RFC 7208). Capped at 10 DNS lookups per evaluation.
DKIM attaches a cryptographic signature to outbound mail, with the public key in DNS at <selector>._domainkey.<domain> (RFC 6376).
Alignment requires the SPF MAIL FROM domain or DKIM d= domain to match the visible From: header domain at the organizational-domain level (relaxed) or exactly (strict).
Organizational domain is the registrable domain under a public suffix (example.co.uk under .co.uk), computed via the Public Suffix List at publicsuffix.org.
RFC 5321 MAIL FROM (envelope) is what SPF authorises; RFC 5322 From: (header) is what users see and what DMARC alignment evaluates. They can legitimately differ.
ARC (RFC 8617) preserves the original SPF/DKIM/DMARC verdict across forwarding hops via three per-message headers (ARC-Seal, ARC-Authentication-Results, ARC-Message-Signature) plus chain validation (cv=pass).
Aggregate report (RUA) is the daily XML feedback loop from receivers to the domain owner — the only practical way to inventory who is sending mail purporting to be from your domain.

1. Email authentication standards

DMARC: Domain-based Message Authentication, Reporting, and Conformance (RFC 7489) is the email-authentication policy and reporting protocol that ties SPF and DKIM verification results to the visible From: header domain via alignment, declares a domain-owner policy (none/quarantine/reject) for unauthenticated mail, and instructs receivers to send aggregate and forensic reports back to the domain owner.
SPF: Sender Policy Framework (RFC 7208) is an email-authentication standard that lets a domain owner publish a DNS TXT record listing the IP addresses, hostnames, and other identifiers authorised to send mail with the domain in the envelope MAIL FROM. Receivers reject or mark mail that arrives from non-authorised sources.
DKIM: DomainKeys Identified Mail (RFC 6376) is an email-authentication standard that lets a sender attach a cryptographic signature to outbound messages, with the corresponding public key published in DNS at <selector>._domainkey.<domain>. Receivers verify the signature to prove the message originated at the signing domain and was not modified in transit.
BIMI: Brand Indicators for Message Identification is the standard that lets a domain publish a logo (as an SVG Tiny Portable/Secure image) in DNS, which compliant receivers (Apple Mail, Gmail, Yahoo Mail) display next to authenticated messages from the domain. BIMI requires DMARC enforcement (p=quarantine or p=reject) as a precondition.
MTA-STS: SMTP MTA Strict Transport Security (RFC 8461) is the transport-security standard that lets a domain require inbound mail to arrive over STARTTLS-encrypted SMTP connections with valid PKI certificates. Policies are published via a DNS TXT record at _mta-sts.<domain> pointing at an HTTPS policy file under /.well-known/mta-sts.txt.
TLS-RPT: SMTP TLS Reporting (RFC 8460) is the companion reporting standard to MTA-STS that lets a domain owner receive daily JSON reports from sending receivers about TLS-handshake successes and failures. The DNS record at _smtp._tls.<domain> publishes the rua= reporting destination.
ARC: Authenticated Received Chain (RFC 8617) is an email-authentication standard that lets intermediate servers (mailing lists, .forward redirects, security gateways) cryptographically attest the original SPF/DKIM/DMARC verdict so the final receiver can honour a sender domain DMARC policy even after legitimate forwarding has invalidated SPF and DKIM.
CAA: Certification Authority Authorization (RFC 8659) is the DNS record type that lets a domain owner declare which Certificate Authorities are authorised to issue TLS certificates for the domain. Although not strictly an email-authentication record, CAA is a hidden prerequisite for MTA-STS (requires a valid PKI cert on mta-sts.<domain>) and BIMI (requires a VMC issued by an authorised CA).

2. Identifiers and headers

Header From (RFC 5322 From): The From: header that the mail user agent displays to the recipient. Sometimes called "RFC 5322 From" or "5322.From". DMARC alignment evaluates the organizational domain of this field against the SPF/DKIM domain. Distinct from MAIL FROM (RFC 5321), which carries the envelope return-path and can differ from the visible From:.
MAIL FROM (RFC 5321 envelope From): The SMTP-envelope sender address used during the MAIL FROM command of the SMTP transaction. Sometimes called "RFC 5321 From", "5321.From", or "Return-Path". SPF authorises the connecting IP against this domain. Distinct from the Header From (RFC 5322), which is what users see in the From: header; they can legitimately differ (a server forwarding mail typically rewrites MAIL FROM but preserves the Header From).
Alignment: The DMARC concept that ties an authenticated identifier (SPF MAIL FROM domain or DKIM signing domain) to the visible Header From domain. DMARC pass requires that AT LEAST ONE of SPF or DKIM authenticated AND the corresponding domain aligned with the Header From at the organizational-domain level (relaxed) or exactly (strict, controlled by adkim/aspf).
Organizational domain: The registrable domain underneath a public suffix, computed by walking left-to-right through the Public Suffix List (PSL). For example, the organizational domain of "mail.user.example.co.uk" is "example.co.uk" because ".co.uk" is a public suffix. DMARC relaxed alignment compares organizational domains rather than the full FQDN.
Public Suffix List (PSL): The community-maintained list at publicsuffix.org of DNS suffixes under which Internet users can directly register domains. DMARC uses the PSL to compute the organizational domain for alignment evaluation. Operators publishing DMARC on a subdomain must ensure the parent domain has a published DMARC record (or rely on the sp= tag), because receivers walk up to the organizational domain when the FQDN lacks a DMARC record.
Identifier alignment: The DMARC term for matching the SPF or DKIM authenticated domain against the Header From domain. Relaxed alignment compares organizational domains (mail.example.com aligns with example.com). Strict alignment requires exact match. Controlled by adkim= and aspf= DMARC tags (default relaxed).
Envelope vs Header: The SMTP transaction carries two From identifiers: the envelope (MAIL FROM, RFC 5321) used for bounce routing and SPF, and the header (From:, RFC 5322) shown to the user and used by DKIM and DMARC. Mail forwarders routinely rewrite the envelope while preserving the header, which is precisely why SPF alone is insufficient and ARC exists to preserve the original verdict across hops.

3. DMARC tags and mechanics

p= (DMARC policy): The DMARC policy tag that declares the domain owner intent for unauthenticated mail at the organizational domain. Values: none (monitor only, no action), quarantine (move to spam), reject (block at SMTP). Required for any DMARC record. Operators ALWAYS start at p=none, ingest reports for 2-6 weeks, advance to p=quarantine, then p=reject — never skip directly to p=reject.
sp= (DMARC subdomain policy): The DMARC tag declaring a separate policy for subdomains that lack their own DMARC record. If omitted, sp= inherits from p=. Setting sp=reject while keeping p=none lets an operator block subdomain spoofing while still monitoring the organizational domain. Critical for organizations with many subdomains that may receive spoof attempts independently of the main domain.
np= (DMARC non-existent subdomain policy): A DMARC tag introduced by RFC 9091 (2021) declaring a policy for non-existent subdomains. Receivers apply np= to mail purportedly from a subdomain that has no MX, A, or AAAA records. Used to block spoof attempts targeting subdomains that were never created. Not yet universally supported but increasingly honoured by major receivers.
adkim= (DKIM alignment mode): The DMARC tag controlling DKIM-to-Header-From alignment strictness. Values: r (relaxed, default — organizational-domain comparison) or s (strict — exact FQDN comparison). Relaxed allows DKIM signing under a subdomain to align with a parent-domain Header From; strict forbids that flexibility.
aspf= (SPF alignment mode): The DMARC tag controlling SPF-MAIL-FROM-to-Header-From alignment strictness. Values: r (relaxed, default — organizational-domain comparison) or s (strict — exact FQDN comparison). Relaxed is recommended for nearly every deployment because envelope-MAIL-FROM rewriting on outbound relays is common practice.
pct= (DMARC percent ramp): The DMARC tag declaring what percentage of failing messages the receiver should apply the policy to (0-100, default 100). Used during gradual rollout: setting pct=10 with p=quarantine quarantines only 10 percent of failing mail, surfacing alignment failures via aggregate reports without breaking high-volume traffic. Increment toward 100 as confidence grows.
fo= (DMARC forensic options): The DMARC tag declaring under which conditions the domain owner wants forensic (RUF) reports. Values: 0 (default, only on dual SPF+DKIM failure), 1 (any auth or alignment failure), d (DKIM-signature failure even if alignment passed), s (SPF-evaluation failure even if alignment passed). Set fo=1 during initial rollout to maximize visibility into failure modes.
rua= (DMARC aggregate report destination): The DMARC tag declaring where receivers should send daily aggregate (RUA) reports. A comma-separated list of mailto:URIs. Required for any actionable DMARC deployment because aggregate reports are the only feedback loop into who is sending mail purporting to be from your domain. Cross-domain destinations require a published reverse-authorisation record at <sender-domain>._report._dmarc.<recipient-domain>.
ruf= (DMARC forensic report destination): The DMARC tag declaring where receivers should send per-message forensic (failure) reports — redacted bounce-style copies of each individual failing message. Largely deprecated due to PII / GDPR concerns; Google does not send RUF, Microsoft sends only on explicit opt-in. Operators relying on forensic reports should expect coverage from Yahoo, Comcast, and a handful of other receivers only.
ri= (DMARC reporting interval): The DMARC tag declaring the desired reporting interval in seconds for aggregate reports. Default 86400 (24 hours). Receivers honour this as a minimum interval; most receivers send daily regardless. Rarely changed in practice.
rf= (DMARC reporting format): The DMARC tag declaring the desired forensic-report format. Default afrf (Authentication Failure Reporting Format, RFC 6591). Reserved for future expansion; never changed in current deployments.

4. DKIM mechanics

DKIM selector: A short label (often "default", "selector1", "google", "k1", "s1") that disambiguates which DKIM key was used to sign a message. The signing server includes the selector in the DKIM-Signature header (s= tag); receivers fetch the public key from <selector>._domainkey.<signing-domain>. Selectors enable key rotation without downtime — publish a new selector, switch signers, leave the old selector live until in-flight mail is delivered, then remove.
AUID (Agent or User Identifier): The DKIM i= tag declaring the identity of the user or agent on whose behalf the message was signed. Defaults to @<signing-domain> if omitted. Receivers use AUID for additional verification context but DMARC alignment evaluates only the d= tag (signing domain), not i=.
DKIM body hash (bh=): The base64-encoded SHA-256 (or SHA-1) hash of the message body, computed after canonicalization, embedded in the DKIM-Signature header. The receiver recomputes the body hash and compares; if the body was modified in transit, body-hash verification fails before any signature math runs.
DKIM canonicalization: The DKIM step that normalises header whitespace + folding (simple vs relaxed) and body whitespace + trailing CRLFs (simple vs relaxed) before hashing, so trivial transformations during transit do not invalidate the signature. The c= tag declares the chosen pair (e.g. "relaxed/relaxed"). Recommended: relaxed/relaxed because any mail through a relay-style intermediate will likely add or strip a trailing CRLF.
header.d (DKIM signing domain): The DKIM d= tag declaring which domain owns the signing key. This is the domain DMARC alignment compares against the Header From. A SaaS provider signing on behalf of customer-domain.com publishes d=customer-domain.com (via CNAME-delegated key) so DKIM aligns; if they sign d=saas-provider.com, DKIM does NOT align and DMARC fails unless SPF aligns.
header.i (DKIM AUID): See AUID. The DKIM i= tag is informational for DMARC purposes; alignment uses header.d not header.i.
DKIM key rotation: The periodic process of generating a new DKIM keypair, publishing the new public key at a new selector, switching the signing server to the new selector, waiting for in-flight mail to drain, then removing the old selector. Recommended cadence: every 6-12 months. Modern providers (Microsoft 365, Google Workspace) automate this; cPanel / Exim / self-hosted setups require manual rotation.

5. SPF mechanics

SPF qualifier: The single character prefix on an SPF mechanism declaring the action when the mechanism matches. + (Pass, default), - (Fail), ~ (SoftFail), ? (Neutral). The overall record terminator (e.g. -all or ~all) declares the qualifier for mail that does not match any explicit mechanism. -all is the only correct terminator for any operator who wants real protection; ~all is a stop-gap during rollout only.
SPF mechanism: A directive in the SPF record that matches against the sending IP, hostname, or SPF policy at another domain. Common mechanisms: ip4:, ip6:, a, mx, include:, exists:, ptr (deprecated). Each mechanism is paired with a qualifier (default +) and evaluated left-to-right until a match.
SPF modifier: An SPF directive that affects evaluation but does not match against the sending IP. The two standard modifiers: redirect= (transfers evaluation to another domain SPF record, rarely-used) and exp= (declares a domain whose TXT record holds an explanation string shown on -all rejection).
SPF 10 DNS lookup limit: RFC 7208 caps SPF evaluation at 10 DNS lookups (DNS lookups triggered by include:, a, mx, exists, redirect, ptr — but not ip4: or ip6: which are inline). Exceeding 10 returns permerror. Common SaaS-heavy SPF records exceed the limit; the fix is SPF flattening (replacing include: chains with literal ip4: blocks via automated tooling).
SPF void lookup: A DNS lookup during SPF evaluation that returns no answer (NXDOMAIN or empty). RFC 7208 caps void lookups at 2; exceeding returns permerror. Catches typos in include: hostnames that otherwise silently degrade SPF coverage.
SPF permerror: A permanent SPF evaluation failure (typically syntax error, lookup-limit exceeded, or void-lookup-limit exceeded). DMARC treats permerror as a fail — operators must monitor aggregate reports for SPF permerror rates and remediate quickly because permerror means SPF stops protecting the domain.
SPF temperror: A transient SPF evaluation failure (DNS timeout, SERVFAIL). DMARC typically retries; consistent temperror rates indicate DNS-infrastructure problems on the sender side.

6. BIMI mechanics

Mark Type Indicator: The BIMI a= tag declaring the type of certificate authority that issued the Verified Mark Certificate (VMC). Currently the only supported value points at a DigiCert or Entrust-issued VMC. Some receivers (Apple) accept a BIMI record without a VMC (a "self-asserted" record), but Gmail and Yahoo require a VMC.
VMC (Verified Mark Certificate): A PKI certificate issued by an approved Certificate Authority (currently DigiCert or Entrust) that cryptographically binds a registered trademark logo to a domain. Required by Gmail and Yahoo for BIMI display. Costs USD 1500-2000 per year; the trademark must be registered with an approved IP office before the CA will issue a VMC.
SVG Tiny PS: The "SVG Tiny Portable/Secure" SVG profile required by BIMI for the logo file. A subset of SVG that excludes scripts, animations, and external references for security. The file must be no larger than 32 KB, must have square aspect ratio, must declare baseProfile="tiny-ps", and must encode the logo on a transparent background.
l= (BIMI logo location): The BIMI l= tag declaring the HTTPS URL of the SVG Tiny PS logo file. Must be served over HTTPS with a valid certificate. The file is fetched by the receiver at message-display time (with caching).
a= (BIMI authority evidence): The BIMI a= tag declaring the HTTPS URL of the Verified Mark Certificate (.pem file). Required by Gmail and Yahoo. Apple Mail honours a BIMI record without a VMC for some senders, but the universal pattern is to publish both l= and a=.

7. MTA-STS and TLS-RPT mechanics

MTA-STS policy file: The text file served at https://mta-sts.<domain>/.well-known/mta-sts.txt declaring the MTA-STS policy: version (STSv1), mode (none/testing/enforce), mx (allowed MX hostname patterns), max_age (cache lifetime). The DNS record at _mta-sts.<domain> publishes a TXT v=STSv1; id=<unique-id> that pins the current policy version.
MTA-STS mode (enforce/testing/none): The mode line in the MTA-STS policy file declaring receiver enforcement behaviour. testing: sender SHOULD NOT block on policy violations but SHOULD report via TLS-RPT. enforce: sender SHOULD block on policy violations. none: legacy / withdrawal mode. Always deploy at mode: testing first, monitor TLS-RPT reports for a week or two, then advance to mode: enforce.
/.well-known/ URI: RFC 5785 establishes the /.well-known/ URI prefix for serving machine-readable resources at known paths. MTA-STS uses /.well-known/mta-sts.txt; ACME (Let's Encrypt) uses /.well-known/acme-challenge/. The well-known prefix isolates protocol-defined paths from operator-controlled content.
STARTTLS: The SMTP command (RFC 3207) that upgrades a plaintext SMTP connection to TLS-encrypted in-band. MTA-STS makes STARTTLS effectively mandatory at the sender side; without MTA-STS, downgrade attacks (active interception removing the STARTTLS advertisement) can force plaintext delivery.
TLS-RPT result type: One of 12 standard failure-type strings in a TLS-RPT JSON report describing why a TLS handshake failed: starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, validation-failure, tlsa-invalid, dnssec-invalid, dane-required, sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, certificate-error. Each maps to a specific remediation action on the receiver MTA side.

8. ARC mechanics

ARC-Seal: One of three per-message ARC headers (RFC 8617). The ARC-Seal cryptographically signs the prior ARC-Authentication-Results and ARC-Message-Signature headers, sealing the chain so a downstream intermediate cannot retroactively rewrite an earlier verdict. The seal carries i= (instance number) and cv= (chain validation state).
ARC-Authentication-Results: One of three per-message ARC headers (RFC 8617). Records the authentication verdict (SPF/DKIM/DMARC pass/fail) at the moment of insertion, preserving the original verdict across forwarding hops. Future receivers consult the chain to honour the original sender DMARC policy even when local SPF/DKIM fail due to legitimate forwarding.
ARC-Message-Signature: One of three per-message ARC headers (RFC 8617). A DKIM-like cryptographic signature over the message at the moment of insertion, proving the intermediate received the message with that body and those headers. Distinct from the original DKIM signature, which the intermediate may also relay separately.
cv=pass / cv=fail / cv=none: The chain-validation tag on the ARC-Seal indicating the verdict of validating all prior ARC seals. cv=pass: chain is intact and trustworthy. cv=fail: chain is broken (a prior seal failed verification). cv=none: this is the first ARC seal on the message (no prior chain to validate). Final receivers SHOULD honour the original DMARC verdict only when cv=pass.
ARC chain: The ordered sequence of ARC-Seal / ARC-Authentication-Results / ARC-Message-Signature header triples on a forwarded message, each tagged with a successive instance number (i=1, i=2, i=3). A receiver validates the chain by verifying each seal in order; chain validation passing means every hop was a trustworthy participant, and the original verdict (from i=1) can be honoured.

9. Reporting (aggregate and forensic)

Aggregate report (RUA): Daily XML reports sent by receivers to the rua= mailbox declared in the domain DMARC record. Each report aggregates per-source-IP, per-disposition counts of messages received purporting to come from the domain over the reporting period. The primary feedback loop for DMARC rollout. Schema defined by RFC 7489 Appendix C.
Forensic report (RUF): Per-message redacted bounce-style reports sent by receivers to the ruf= mailbox on individual message failures. Largely deprecated due to PII / GDPR exposure; Google does not send RUF; Microsoft sends only on explicit opt-in. Format: AFRF (Authentication Failure Reporting Format, RFC 6591).
Report sampling: Some receivers (notably Google) sample aggregate reports rather than recording every single message — a one-percent sample at high volume is statistically representative but means the count totals in the report are scaled estimates not exact. The DMARC tooling that ingests reports must NOT assume per-message-level accuracy.
Report deduplication: Receivers may send the same aggregate report multiple times (retries, redelivery). The report-id field in the XML metadata is the canonical deduplication key; ingestion tools (including DMARC Analyzer includes/DmarcParser.php) MUST deduplicate on report-id to avoid double-counting.

10. Cryptography

RSA: The asymmetric cryptography algorithm originally used for DKIM signing. Public-key sizes: 1024-bit (legacy, increasingly rejected), 2048-bit (current recommendation), 4096-bit (overkill — does not fit in standard DNS TXT record without splitting). DKIM signers should use RSA-SHA256 at 2048-bit; 1024-bit keys are routinely cracked offline.
Ed25519: A modern elliptic-curve signing algorithm supported by DKIM (RFC 8463) as an alternative to RSA. Keys are short enough to fit comfortably in a single DNS TXT record (43 base64 characters). Verifier support is increasing but not yet universal; recommended deployment publishes BOTH RSA-2048 and Ed25519 at different selectors so receivers pick the strongest they support.
Signature verification: The receiver-side process of fetching the public key (DKIM, BIMI VMC, MTA-STS HTTPS cert, ARC seal) from the declared location, computing the expected hash over the relevant content (DKIM canonicalized headers + body hash; BIMI logo file; etc.), and confirming the published signature matches. A pass means the content originated at the declared identity and was not modified.

11. Anti-abuse vocabulary

Spoofing: The forgery of the From: header to make a message appear to come from a domain the attacker does not control. SPF + DKIM + DMARC at enforcement (p=quarantine or p=reject) is the email-industry standard defense. DMARC at p=none does NOT prevent spoofing — only monitors it.
Look-alike domain: A domain registered to closely resemble a legitimate domain (e.g. paypa1.com for paypal.com, micros0ft.com for microsoft.com) used in phishing campaigns. DMARC does NOT block look-alikes because the look-alike has its own DNS and can publish its own SPF/DKIM/DMARC. Defenses: trademark enforcement, look-alike domain registration ("defensive registration"), and content-filtering at the receiver.
Homograph attack: A look-alike domain attack using Unicode characters that visually resemble ASCII (e.g. Cyrillic "а" U+0430 vs Latin "a" U+0061). Modern browsers and mail clients render the Punycode form for non-mixed-script domains, but mixed-script attacks (a single non-ASCII character in an otherwise ASCII string) sometimes display the Unicode form. Defense: same as look-alike — monitor for new registrations targeting your trademarks.
BEC (Business Email Compromise): A targeted phishing attack where the attacker impersonates a senior executive or trusted business partner to manipulate the recipient into an action (wire transfer, credential reset, gift-card purchase). BEC frequently uses look-alike domains rather than direct spoofing (because direct spoofing is now usually blocked by DMARC at enforcement). FBI IC3 ranked BEC as the highest-loss email crime category in recent reports.
Display-name attack: An attack that sets the From: header to "Executive Name <attacker@gmail.com>" — the display name is the spoofed brand but the actual address is attacker-controlled. DMARC does NOT block this because DMARC evaluates the address-portion organizational domain (gmail.com here, which has its own SPF/DKIM/DMARC). Defense: receiver-side display-name pattern matching against known-executive lists.

FAQ

What is the difference between SPF, DKIM, and DMARC?: SPF authorises the connecting IP against the envelope MAIL FROM domain (RFC 7208). DKIM cryptographically signs the message with a key published in DNS at <selector>._domainkey.<signing-domain> (RFC 6376). DMARC ties SPF and DKIM verification results to the visible From: header via alignment and adds a policy (none/quarantine/reject) plus reporting (rua/ruf) on top of both (RFC 7489). All three are required for modern email authentication; SPF alone is insufficient because it breaks under forwarding, DKIM alone is insufficient because it does not bind the signing domain to the visible From, and DMARC alone is impossible because it depends on SPF and DKIM verdicts.
What is DMARC alignment?: DMARC alignment is the requirement that the SPF authenticated domain (MAIL FROM) or DKIM signing domain (d= tag) match the visible Header From domain at the organizational-domain level (relaxed alignment, default) or exactly (strict alignment, controlled by adkim= and aspf= DMARC tags). DMARC pass requires AT LEAST ONE of SPF or DKIM to authenticate AND align. SPF can pass cryptographically but if the MAIL FROM domain does not align with the Header From, DMARC ignores it; the same applies to DKIM. See DMARC alignment explained for the deep dive.
What is the organizational domain in DMARC?: The organizational domain is the registrable domain underneath a public suffix, computed by walking left-to-right through the Public Suffix List (PSL) at publicsuffix.org. For example, the organizational domain of mail.user.example.co.uk is example.co.uk because .co.uk is a public suffix. DMARC relaxed alignment compares organizational domains rather than the full FQDN, so mail signed by mail.example.com aligns with a From: header of example.com.
What is a DKIM selector?: A DKIM selector is a short label (often default, selector1, google, k1, s1) that disambiguates which DKIM key was used to sign a message. The signing server includes the selector in the DKIM-Signature header s= tag; receivers fetch the corresponding public key from <selector>._domainkey.<signing-domain> in DNS. Selectors enable key rotation without downtime: publish a new selector, switch signers, leave the old selector live until in-flight mail is delivered, then remove. See DKIM explained for the full mechanism.
What is the difference between RFC 5321 and RFC 5322 from headers?: RFC 5321 defines the SMTP envelope, including the MAIL FROM command which carries the bounce return-path. RFC 5322 defines the message body header format, including the From: header that the recipient mail user agent displays. SPF authorises against RFC 5321 MAIL FROM; DKIM and DMARC alignment evaluate against RFC 5322 From. They can legitimately differ — a forwarding server typically rewrites MAIL FROM to a bounce-handling address while preserving the original From:.
What does cv=pass mean in an ARC chain?: cv=pass is the chain-validation tag on the ARC-Seal header indicating that all prior ARC seals on the message validated successfully — the chain is intact and trustworthy. A final receiver SHOULD honour the original SPF/DKIM/DMARC verdict captured at the first ARC instance (i=1) only when the most recent seal carries cv=pass. cv=fail indicates a broken chain (a prior seal failed verification); cv=none indicates this is the first seal on the message with no prior chain to validate. See ARC explained for the full mechanism.
What is a forensic report in DMARC?: A forensic report (also called a failure report or RUF report) is a per-message redacted copy of an individual failing message, sent by receivers to the ruf= mailbox declared in the DMARC record. Unlike aggregate reports (which are daily statistical summaries), forensic reports give visibility into the specific contents and headers of each failure. Largely deprecated due to PII and GDPR concerns: Google does not send forensic reports at all; Microsoft sends only on explicit opt-in. In practice, expect coverage from Yahoo, Comcast, and a handful of smaller receivers.
What is the SPF 10 DNS lookup limit?: RFC 7208 caps SPF evaluation at 10 DNS lookups per message. Mechanisms triggering DNS lookups include include:, a, mx, exists, redirect, and ptr; inline mechanisms ip4: and ip6: do NOT count. Exceeding the limit returns permerror, which DMARC treats as fail. SaaS-heavy SPF records (Salesforce, Mailchimp, SendGrid, Mailgun, HubSpot, Marketo all chained via include:) routinely exceed 10. The standard fix is SPF flattening — replacing the include chain with literal ip4: blocks via automated tooling that resolves and inlines the upstream records.

Email authentication explained — the cluster-intro pillar covering the ecosystem at standards-overview level.
Email security glossary — the peer / sibling glossary for this page; where this glossary defines the protocol vocabulary (DMARC tags, DKIM selectors, SPF qualifiers, MTA-STS modes, ARC chain validation, alignment, organizational domain, PSL, envelope MAIL FROM, AUID, canonicalization), the security glossary defines the complementary threat-and-defense vocabulary (APT, BEC, CEO fraud, spear phishing, whaling, smishing, vishing, quishing, clone phishing, pharming, look-alike domains, homograph attacks, typosquatting, OSINT reconnaissance, the cyber kill chain, MITRE ATT&CK, STRIDE threat modelling, the diamond model, NIST IR lifecycle, indicators of compromise, dwell time, SOC / SIEM / SOAR / EDR / XDR / MDR operations vocabulary). Read the two glossaries side-by-side: the protocol glossary tells you what the standard does; the security glossary tells you what the adversary does and how defenders respond. Pair with the DMARC attacker bypass catalogue and DMARC myths and misconceptions for the full threat-model deep dive.
Business Email Compromise (BEC) explained — the standalone operational deep dive on the financial-fraud attack family the sibling security glossary catalogues. Where the protocol glossary on this page defines the underlying mechanisms BEC abuses (RFC 5322 From header, RFC 5321 envelope MAIL FROM, identifier alignment, the organizational domain), the BEC page documents how attackers compose these protocol primitives into financial-fraud campaigns: six canonical variants (CEO fraud, vendor / supplier-invoice fraud, payroll-redirect, attorney impersonation, data / W-2 theft, account-compromise BEC), the five-stage BEC kill chain, the precise DMARC gap (p=reject closes one variant only), and the full defense-in-depth control stack including wire-transfer out-of-band verification, payroll-change verification, and the finance / treasury team incident-response playbook. Read the BEC page after this glossary to see the protocol vocabulary in adversary action on the highest-loss email crime category (FBI IC3: USD 2.9B reported loss 2023, USD 55B+ cumulative since 2013).
DMARC overview — the DMARC primer with a deployment checklist and operator workflow.
SPF explained — pillar page covering SPF mechanisms, qualifiers, the 10-DNS-lookup limit, and flattening strategies.
Why SPF alone is insufficient — the structural-limitation reference — the focused operational deep dive on the six structural limitations of an SPF-only posture that this glossary catalogues in single-sentence form across multiple vocabulary entries ("SPF forwarder break", "SPF lookup limit", "SPF permerror", "SPF temperror", "header-From spoofing", "DMARC alignment requirement", "policy contract", "aggregate feedback loop", "SPF qualifier ?all / ~all / -all tail"). Where this glossary defines each limitation as a single-sentence vocabulary entry, the SPF-insufficiency spoke unfolds each limitation into a full operational deep dive: the forwarder-break limitation (RFC 7208 §11.4) with the canonical mailing-list / distribution-list / SaaS-relay topology examples; the header-From-vs-MAIL-FROM gap with the RFC 5321-vs-RFC 5322 distinction on which receivers actually display to end users; the no-integrity gap with the body-modification-undetected pattern; the no-policy gap with the "~all-doesn't-block-anything" operational consequence; the no-feedback gap with the "operators publish SPF and never see what receivers do with the result" gap; and the 10-lookup-cap gap with the SPF-overrun attack pattern. The spoke also walks the DMARC-binding remedy section-by-section, showing exactly which glossary-entry limitation each DMARC tag closes (adkim= / aspf= / p= / sp= / np= / rua=). Especially valuable as a glossary cross-link because SPF-insufficiency is the rare topic where the single-sentence glossary definition leaves the operator's actual question ("why doesn't SPF alone protect my domain") fundamentally unanswered — the spoke is the canonical operational answer that an SPF-pillar reference cannot embed because the answer transcends the SPF protocol into the DMARC enforcement layer.
SPF mechanisms explained (per-directive reference) — the canonical per-mechanism deep dive on every SPF directive this glossary catalogues in single-sentence form. Where this glossary defines "SPF mechanism" as a single sentence ("the directive types include: / a / mx / ip4: / ip6: / ptr / exists: that populate the authorised-sender set"), the mechanisms-explained spoke documents the FULL per-directive grammar of each token: include:<domain> (delegated SPF-tree evaluation — 1 lookup plus the recursive cost of the included tree, the dominant contributor to the 10-lookup limit governed by the help_spf_lookup_limit.php sibling glossary defines), ip4:<CIDR> / ip6:<CIDR> (literal ranges, 0 lookups), a / a:<domain> (1 lookup plus A/AAAA RRset returned), mx / mx:<domain> (1 lookup for MX plus 1 A/AAAA per MX target — second most common overrun source), ptr / ptr:<domain> (N lookups per resolved PTR, deprecated by RFC 7208 §5.5 for performance), exists:<domain> (1 lookup macro-driven existence check), all (tail fall-through token bound to the qualifier glossary entry), and the redirect=<domain> modifier. Read the mechanisms spoke when a glossary definition leaves a per-directive grammar question unanswered — the spoke is the authoritative reference for everything beyond the single-sentence definition.
include vs ip4 vs a vs mx — the four-mechanism decision view — the focused decision-aid spoke on the four IP-providing SPF mechanisms operators actually pick between when authoring or modifying a typical SPF record. Where this glossary defines each individual mechanism token in single-sentence form (include: / ip4: / a / mx), and where the mechanisms-explained spoke documents the COMPLETE 8-mechanism vocabulary including the non-IP-providing tokens (all, exists:) and the deprecated ptr per RFC 7208 §5.5, THIS spoke is the focused 4-way comparative DECISION VIEW answering the operator's operational question "which of the four common mechanisms should I use" when building or restructuring an SPF record. Each subsection presents the same five- part decision frame (Definition / Syntax / Lookup cost / When to use / When NOT to use / Common pitfalls) so the four can be directly compared row-by-row. Read this decision-view spoke when the glossary's single-sentence definition leaves a comparative-choice question unanswered ("should I use include: or ip4: for my AWS SES ranges", "is mx safe for a domain whose MX list might grow", "when does a become a permerror risk") — the spoke is the authoritative comparative reference for the four-way mechanism-selection decision.
SPF for Google Workspace — the CANONICAL-PROVIDER-DEPLOYMENT-RECORD companion to the SPF-deployment vocabulary this glossary catalogues. Where this glossary defines the SPF deployment-and- operational vocabulary in single-sentence form (SPF record, SPF mechanism, include directive, SPF lookup limit (RFC 7208 §4.6.4 10-DNS-lookup ceiling), SPF flattening, SPF permerror, third-party sender, nested include expansion, cloud mailbox provider, SPF qualifier, policy delegation), the SPF-for- Google-Workspace spoke documents the WORKSPACE-PROVIDER-DEPLOYMENT-MATERIALIZATION of those vocabulary terms in concrete form: (i) the canonical apex SPF record every Workspace tenant publishes — v=spf1 include:_spf.google.com ~all — concretely materialising the SPF record + include directive + qualifier tail vocabulary in the single most common form operators encounter in the wild; (ii) the recursive include expansion the receiver-side SPF evaluator unfolds at evaluation time (_spf.google.com → _netblocks.google.com + _netblocks2.google.com + _netblocks3.google.com) — concretely materialising the nested include expansion + SPF lookup limit vocabulary as the ~6–8 DNS lookups the single-line Workspace record actually consumes once the receiver-side resolver expands it; (iii) the operator-side third-party sender coordination pattern — Workspace's ~6–8 lookups leaves so little headroom that adding ANY third-party sender (SendGrid / Mailchimp / HubSpot / Constant Contact / Marketo) commonly pushes the record into permerror territory — concretely materialising the SPF flattening + third-party sender + SPF permerror vocabulary as the recurring real-world operator decision every Workspace operator faces when adding their second or third sender, and (iv) the Workspace SMTP-Relay service coordination surface — the operator-side decision when to use the SMTP-Relay add-on (an Exchange-OAuth- protected SMTP egress for non-Workspace applications relayed through Google's infrastructure) vs publishing a separate sender-domain SPF — concretely materialising the policy authority delegation vocabulary as the operator-side authority boundary decision the Workspace tenancy forces. Pair this glossary (the single- sentence vocabulary entries) with the SPF- for-Google-Workspace spoke (the canonical provider-deployment record + the recursive chain expansion + the third-party-sender coordination decision) for the vocabulary- to-deployment-reality translation operators need when adopting Workspace or auditing an existing Workspace tenant's SPF posture.
SPF qualifiers explained — the per-character prefix grammar (RFC 7208 §4.6.1) — the focused per-qualifier deep dive on the single-character prefix grammar this glossary catalogues in single-sentence form across two vocabulary entries. Where THIS glossary defines the SPF qualifier entry in a single sentence (the four prefix characters + Pass / - Fail / ~ SoftFail / ? Neutral, the omitted-default rule that bare mechanisms carry an implicit +, and the tail -all / ~all / ?all grammar that declares the catch-all qualifier), and where the SPF result entry separately defines the FIVE check-result names a receiver returns after evaluating the record (Pass / Fail / SoftFail / Neutral / TempError / PermError / None — RFC 7208 §2.6), the qualifiers-explained spoke documents the FULL RFC 7208 §4.6.1 byte-level evaluation rule per qualifier: the Pass verdict the receiver returns when a +-prefixed mechanism matches and the operational consequence (DMARC sees SPF-pass, the IP-to-domain authorisation contract is satisfied); the Fail verdict on a --prefixed mechanism match and the historical bounce-at-MAIL-FROM stance receivers like Gmail no longer execute; the SoftFail verdict on ~-prefixed match and the ambiguous receiver-tag-only treatment that leaves the spoof unblocked; the Neutral verdict on ?-prefixed match and the identical-to-None operator-disabled effect; the rare per-mechanism qualifier choices operators use when authoring partial-trust records (?include: / ~include: for low-confidence partner SPF trees); the rolling-deployment-pattern ~all → -all transition every operator must complete before SPF starts enforcing. Read the qualifiers spoke when a glossary definition leaves a per-qualifier semantic question unanswered — the spoke is the authoritative reference for the four-character prefix grammar and the four-result tail-qualifier semantics every receiver implements per RFC 7208 §4.6.1 and §4.7.
SPF DNS record syntax explained — the RFC 7208 §3 byte-level publication rules — the focused GLOSSARY-TERM-RESOLUTION companion documenting the RFC 7208 section 3 byte-level DNS-record reference governing how the SPF policy is encoded as a TXT record at the publishing domain. Where THIS glossary catalogues SPF-related vocabulary (the SPF entry, the SPF record entry, the TXT record entry, the v=spf1 version tag entry, the SPF qualifier entry, the SPF result entry, the SPF mechanism entry, the SPF PermError entry) each in single-sentence form, the syntax spoke documents the FULL byte-level RFC 7208 §3 publication grammar: the mandatory v=spf1 version tag and the case-sensitivity rule, the TXT record type (with the November 2014 deprecation of legacy DNS RR type 99 — receivers ignore SPF type 99 publication entirely), the 255-octet DNS character-string limit and the multi-string concatenation rule (when an SPF record approaches 255 octets it must be split into multiple quoted strings within the SAME TXT RDATA, NOT into multiple TXT records), the "exactly one SPF record per domain" rule (publishing two v=spf1 records on the same name triggers PermError per §4.5 and loses ALL SPF authentication), the whitespace and case-sensitivity rules, the apex vs subdomain publication semantics (wildcard TXT records do NOT cover the apex), and the comment-syntax rule (there are no comments in SPF). Read the syntax spoke when a glossary entry leaves a per-byte-level encoding question unanswered — the spoke is the authoritative reference for the byte-level TXT-record publication grammar every operator must obey to avoid receiver-side PermError even when every semantic mechanism is correctly chosen.
DNS propagation — the GLOSSARY-VOCABULARY-RESOLVES-TO- TTL-BOUNDED-AUTHORITATIVE-RESOLVER- CACHE-INVALIDATION companion to this email authentication glossary. The DNS propagation spoke is the publisher-side publish-and-verify- cycle reference that mediates every DNS-published-record vocabulary term THIS glossary catalogues at the on-the-wire authoritative-resolver layer at FOUR DNS-propagation- lifecycle dimensions: (i) SPF record publication → receiver-side authoritative TXT lookup at envelope-sender domain → TTL-bounded receiver-resolver cache invalidates only on TTL expiry — the DNS propagation spoke documents how SPF vocabulary terms (SPF record, SPF mechanism, include directive, all qualifier) THIS glossary catalogues at the semantic-protocol layer materialise at the publisher-side publish-cycle as TTL-bounded TXT record publications — the receiver's resolver-cache invalidation discipline is governed by the publisher-emitted TTL value (typical 300-3600 seconds for SPF), making the lower-TTL choice a publisher-controllable knob over the publish-to-receiver-visibility latency for any SPF record change (mechanism add / include flush / qualifier flip from ~all to -all); (ii) DKIM selector publication → receiver-side authoritative TXT lookup at selector._domainkey.<d> → key-rotation window is governed by the TWO-keys-published operator-discipline pattern THIS glossary catalogues — the DNS propagation spoke documents how DKIM vocabulary terms (DKIM selector, DKIM public-key TXT record, key rotation, two-keys-published discipline) THIS glossary catalogues materialise at the publisher-side as TTL-bounded selector-subdomain TXT publications — the rotation- window operator-discipline (publish new selector, wait-out-cache-TTL, switch signer, wait-out-cache-TTL, retire old selector) is upstream-governed by the DNS propagation cycle the spoke documents; (iii) DMARC record publication → receiver-side authoritative TXT lookup at _dmarc.<d> → policy-tag transition (p=none → p=quarantine → p=reject) is bounded by the TTL-and-pct=-ramp coordination THIS glossary catalogues — the DNS propagation spoke documents how DMARC vocabulary terms (DMARC record, policy tag, organizational domain, relaxed alignment) THIS glossary catalogues materialise at the publisher-side as TTL- bounded TXT publications whose policy-tag transition is bounded by the publish-cycle and is the operationally-most-critical DNS-propagation coordination event at the publisher's enforcement- ramp lifecycle; (iv) BIMI / MTA-STS / TLS-RPT record publication → receiver-side authoritative TXT lookup and HTTPS policy-fetch at _bimi.<d> / _mta-sts.<d> / _smtp._tls.<d> → multi-record publish-coordination cycles every modern email- authentication vocabulary term THIS glossary catalogues depends on at the operator-discipline layer — the DNS propagation spoke documents how the modern email-authentication record taxonomy (BIMI VMC / l= URL, MTA-STS policy ID / HTTPS-fetched policy body, TLS-RPT rua= URI / failure- report channel) THIS glossary catalogues materialises at the publisher-side as coordinated multi- record publications (BIMI requires both DNS TXT and VMC HTTPS certificate; MTA-STS requires both DNS TXT id= and HTTPS policy body; TLS-RPT requires both DNS TXT and rua= mailbox MX availability) whose coordinated propagation the spoke is the operator-discipline reference for. Read the DNS propagation spoke WITH this glossary when scheduling any DNS record change affecting an email- authentication vocabulary term THIS glossary catalogues — the glossary defines WHAT the record is; the propagation spoke defines HOW LONG until the change takes effect at the receiver and HOW TO COORDINATE multi- record changes safely.
SPF PermError vs TempError — the two SPF-failure result codes (RFC 7208 §2.6.7-§2.6.8) — the focused per-error-code deep dive on the two SPF-failure result codes this glossary catalogues each in single-sentence form. Where THIS glossary defines SPF permerror ("permanent failure — the SPF record is invalid or evaluation hit the 10-DNS-lookup limit; no amount of retrying will resolve it") and SPF temperror ("transient failure — DNS resolution timed out or returned SERVFAIL; retry may succeed") each in single-sentence form, the permerror-vs-temperror spoke documents the FULL RFC 7208 §2.6.7-§2.6.8 byte-level rules distinguishing the two verdicts: PermError triggers on record-grammar violations (invalid mechanism tokens, malformed CIDR, missing v=spf1 version prefix, multiple SPF records at apex per RFC 7208 §3.2), on the 10-DNS-lookup limit per §4.6.4, and on macro-expansion failures per §7; TempError triggers on DNS resolver timeouts, SERVFAIL responses, and transient name-resolution failures during evaluation. The spoke also documents the operator-side diagnostic workflow: how to identify the canonical causes of each verdict from aggregate-report rows (PermError rows = audit record-grammar and lookup-count first; TempError rows = check DNS resolver health and recent record propagation events), the receiver-side treatment difference (Gmail and Microsoft both fail-open on TempError to avoid delivery loss during transient DNS outages, but treat PermError as a hard SPF-fail), and the canonical operator mistakes that cause each (PermError: copy-paste a partner SPF snippet that hits the 10-lookup limit when combined with the existing record; TempError: deploy an SPF record edit during peak DNS-cache TTL expiry causing transient SERVFAIL at downstream resolvers). Read the permerror-vs-temperror spoke when a glossary definition leaves an operator's diagnostic question unanswered — the spoke is the authoritative reference for distinguishing the two SPF-failure verdicts every receiver implements per RFC 7208 §2.6.7-§2.6.8.
SPF forwarding issues — the GLOSSARY-VOCABULARY-RESOLVES- TO-SPF-FORWARDING-BREAK-CATALOGUE companion reference. Where THIS glossary catalogues the email- authentication vocabulary at the SPF forwarding-failure boundary (envelope- MAIL-FROM, return-path, SRS / Sender Rewriting Scheme, second-hop break, forwarder, mailing-list intermediary, auto-forwarder, vacation forwarder, recipient mailbox rule), the spf_forwarding_issues spoke is the SPF-FORWARDING-BREAK CATALOGUE canonical reference every glossary vocabulary term on THIS page's SPF-forwarding section structurally resolves to. FOUR structurally- distinct GLOSSARY-VOCABULARY-TO- SPF-FORWARDING-BREAK resolution dimensions: (i) glossary terms envelope-MAIL-FROM / return- path / SRS resolve to RFC 7208 §10.4 forwarding-break mechanism — the spf_forwarding_issues spoke documents §10.4's articulation of why SPF breaks at the second-hop boundary (the envelope-MAIL-FROM domain at the original sender does NOT change unless the forwarder rewrites the envelope per Sender Rewriting Scheme; receivers verify SPF against the envelope-MAIL-FROM domain, NOT against the forwarder's IP); the four glossary terms on THIS page resolve to the §10.4 mechanism's load-bearing vocabulary; (ii) glossary terms mailing-list- intermediary / Mailman / Sympa / Discourse resolve to per-forwarder per-recipient SPF-fail-rate distribution — the spf_forwarding_issues spoke documents the per-mailing-list-platform per- recipient SPF-fail-rate baseline (the canonical SPF-fail behaviour of every major mailing-list intermediary catalogued on THIS glossary); the operator structurally consumes this per-platform baseline for DMARC-ramp- readiness / monitoring-baseline decisions; (iii) glossary terms auto-forwarder / vacation- forwarder / recipient-mailbox-rule- forwarder resolve to per-receiver per-forwarder SPF-fail-rate distribution at major mailbox- provider populations — the spf_forwarding_issues spoke documents the per-receiver per-forwarder SPF- fail-rate at Gmail vacation-auto- forwarders / Outlook mailbox-rule forwarders / Apple iCloud forwarders / Yahoo auto-forward rules; the receiver-population vocabulary on THIS glossary resolves to the per- receiver per-forwarder baseline the forwarding-issues spoke quantifies; (iv) glossary terms DKIM- aligned-pass-on-forwarded-path / DMARC disjunction / forwarder-DKIM- preservation resolve to the per- forwarder DKIM-survival distribution that defines the DMARC-ramp-readiness floor — the spf_forwarding_issues spoke documents the per-forwarder DKIM-aligned-pass survival distribution (which forwarders body-modify the message and break the DKIM body-hash; which forwarders preserve the original- signer's DKIM signature unchanged); the DMARC disjunction (SPF-aligned- pass OR DKIM-aligned-pass) requires DKIM survival on the forwarded path for DMARC-ramp readiness — the glossary's DKIM-DMARC disjunction vocabulary on THIS page resolves to the per-forwarder DKIM-survival baseline the spf_forwarding_issues spoke documents at the operator- side ramp-readiness assessment boundary. Read the spf_forwarding_issues spoke alongside this glossary when the SPF-forwarding vocabulary terms on THIS page need to resolve to their canonical RFC 7208 §10.4 forwarding- break catalogue and the per- forwarder per-receiver SPF-fail-rate baseline reference — the forwarding-issues spoke is the operator-side decision-input reference every email-authentication vocabulary term in THIS glossary's SPF-forwarding section structurally resolves to.
DKIM explained — pillar page covering DKIM selectors, canonicalization, key rotation, and AUID.
DKIM best practices (operator-facing key-cryptography & signing-hygiene reference) — the operator-facing best-practices reference for the DKIM-cryptography choices this glossary catalogues each in SINGLE-SENTENCE form. Where THIS glossary defines RSA-2048, ED25519, selector rotation, dual-signing, body-hash ceiling (l= tag risk), canonicalization mode, key inventory, signing-domain alignment, and the RSA-1024 deprecation timeline each in a SINGLE sentence, the best-practices spoke documents the FULL operator-facing deployment-and-maintenance discipline: the canonical 2048-bit RSA minimum (after the 2024 Gmail / Yahoo deprecation of RSA-1024), the ED25519 / RSA dual-algorithm publication strategy that gives verifiers a choice while protecting against the future-day RSA breakage, the 6-month selector-rotation cadence with overlap-window dual-signing (publish new selector + start signing with new key BEFORE retiring the old selector — never DELETE before retiring), the explicit avoidance of the l= body-length tag (body-hash-ceiling attacks let attackers append unsigned content below the ceiling — recommended: omit l= entirely so the entire body is covered), the relaxed/relaxed canonicalization choice for forwarder-survivability (relaxed body canonicalization permits whitespace normalisation without breaking the body-hash), the per-provider key-inventory discipline (every SaaS sender + ESP + MTA + relay needs its own documented DKIM keypair under the operator's d=<org-domain> umbrella OR a sub-domain delegation), the d=<rfc5322.from-domain> alignment discipline that ensures DKIM-pass also satisfies DMARC alignment, and the post-quarantine breach-response key-revocation protocol when an attacker compromises a DKIM private key.
DKIM selectors explained (s= and d= tags) — the tag-by-tag deep dive on the DKIM s= selector and d= signing-domain pair this glossary catalogues. Where this glossary defines "DKIM selector" in a single sentence, the selectors page documents the full DNS- record syntax (v=DKIM1; k=rsa; p=… public-key blob plus optional g= granularity, h= hash-algorithm, s= service- type, t= flags, n= notes per RFC 6376 §3.6.1), the eight canonical naming patterns operators choose between, the per-provider selector catalogue (Google Workspace google / selector1.google; Microsoft 365 selector1 / selector2; Mailchimp k1 / k2; SendGrid s1 / s2; Mailgun k1; Postmark 20150623; Amazon SES the amazonses per-domain selector), the multi-selector / multi-key deployment patterns for ESP migrations and per-stream signing isolation, and the dual-selector zero-downtime rotation procedure. Pair this glossary (the term definitions) with the selectors page (the tag-by-tag operator reference) to translate "selector" from a vocabulary entry into an actual DNS deployment.
DKIM DNS record syntax (RFC 6376 §3.6.2 byte-level TXT-record encoding rules) — the FULL byte-level DNS-record syntactic reference for the DKIM key TXT record this glossary catalogues in single-sentence vocabulary entries. Where this glossary defines "DKIM key TXT record", "v=DKIM1", "k=rsa", "k=ed25519", "p= public key", "h=sha256", "t=y testing flag", "t=s strict i-domain flag", "s=email service type", "n= notes", "g= granularity", "empty p= key revocation" each in a single-sentence vocabulary definition, the DNS-record-syntax spoke documents the complete RFC 6376 §3.6.2 byte-level TXT-record encoding rules operators apply when actually publishing a DKIM key: the tag-value-list grammar separated by semicolons, the mandatory-vs-optional tag taxonomy (p= mandatory, all other tags optional with documented defaults), the case-sensitivity rules (v=DKIM1 must be uppercase DKIM1, tag names are case-sensitive lowercase, base64 padding within p= is case-sensitive), the 255-octet character-string chunking rule (RFC 1035 §3.3.14 — a 2048-bit RSA public key exceeds 255 characters and MUST be split into multiple quoted strings in the zone file, concatenated by the resolver at lookup time), the empty-p= revocation convention (publishing v=DKIM1; p= with no key material signals "this selector is revoked"), the deprecated-tag handling (g= granularity removed from RFC 4871 by RFC 6376 but still recognised for legacy interop; n= notes retained as operator-readable text), the canonical operator-mistake catalogue (TXT- record-vs-CNAME publication confusion, missing v=DKIM1 when publishing alongside other TXT records, unquoted public-key strings, base64 whitespace mangling, character-string boundary mid-base64-padding, multiple v=DKIM1 TXT records at the same selector producing non-deterministic verifier behaviour), the RFC 8463 ed25519 publication shape (k=ed25519 with the 32-byte raw Ed25519 public key base64-encoded as p= per RFC 8410 SubjectPublicKeyInfo), and the RFC 8301 RSA-2048 floor enforcement (no sub-1024-bit RSA keys, rsa-sha1 deprecated). Pair this glossary (the term definitions for each tag and each operational concept) with the DNS-record-syntax page (the normative byte-level publication reference) when translating a glossary entry into the actual zone-file string an operator pastes into Cloudflare / Route 53 / cPanel WHM / Microsoft 365 Admin Center / Google Admin Console.
DKIM canonicalization explained (simple vs relaxed) — the byte-level header-and-body normalisation algorithm pair this glossary defines as the c= tag value in the DKIM-Signature header. Where this glossary catalogues "canonicalization" as a single vocabulary term, the canonicalization page documents the four possible c= values (simple/simple, simple/relaxed, relaxed/simple, relaxed/relaxed) with the full RFC 6376 §3.4.1–§3.4.4 algorithm definitions: simple header canonicalization (verbatim bytes, fragile against any whitespace mangling), relaxed header canonicalization (collapses internal whitespace, strips trailing whitespace, lowercases field names per §3.4.2), simple body canonicalization (hashes verbatim, rejects ANY trailing-byte modification), relaxed body canonicalization (collapses internal whitespace, strips trailing whitespace, ignores trailing empty lines per §3.4.4). The page also documents the operationally-critical l= partial-body-length tag (§3.5) — the most replay-dangerous canonicalization-adjacent knob in the spec, lets attackers APPEND content after the signed prefix and the signature still verifies; the canonical recommendation is avoid l= in production regardless of canonicalization choice. Pair this glossary (the term definitions) with the canonicalization page (the byte-exact algorithm reference) when diagnosing body-hash mismatches at forwarders, mailing-list footer-injection breakage, or whitespace-mangling MTA traversal.
DKIM signatures explained — the byte-layout deep dive on the DKIM-Signature: header structure — the byte-level reference for the DKIM-Signature: header structure itself that this glossary defines as the single-sentence protocol-vocabulary anchor. Where this glossary defines DKIM-Signature header, h= signed-headers list, b= signature data, bh= body hash, a= signing algorithm, c= canonicalization pair, d= signing domain, s= selector, t= timestamp, x= expiration, l= body length, i= AUID, q= query method, and v= version each in single- sentence form, the signatures-explained spoke documents the full per-tag deep dive on the DKIM-Signature header: the canonical tag-grammar (per RFC 6376 §3.5: tag-name = ALPHA *(ALPHA / DIGIT), tag-value = 0*DKIM-quoted-printable), the byte-order rules (no required tag order on the wire but operators publish in a conventional v=1; a=...; c=...; d=...; s=...; h=...; bh=...; b=... order for readability), the per-tag length considerations (the b= tag's base64-encoded signature data is the longest field — typically 300-400 bytes for RSA-2048 — and operators must allow header-folding per RFC 5322 §2.2.3 across the long-line wrap), the signer-vs-verifier asymmetric view (the signer assembles the DKIM-Signature header with b= empty, canonicalizes the headers in h= + the DKIM-Signature itself with b= empty + the body per c=, computes the signature over the assembled canonicalized bytes, and prepends the now-populated DKIM-Signature header to the message; the verifier extracts the DKIM-Signature header, empties the b= value in its copy of the header for canonicalization purposes, then canonicalizes per c= and verifies b= against the assembled byte stream), and the operationally-load-bearing tag interactions (h= determines WHICH headers the signature commits to — operators must include From: to make the signature meaningful for DMARC alignment, and the h=...:From:... string is checked verbatim by every verifier; l= body-length scoping allows footer-injection survival but enables length-extension attacks operators should typically avoid). The signatures-explained spoke is especially valuable as a single navigation target for the glossary because the DKIM-Signature header is the OPERATOR-VISIBLE wire-format DKIM produces and that every diagnostic tool emits — every glossary entry that names a DKIM- Signature tag (h=, b=, bh=, a=, c=, d=, s=, t=, x=, l=, i=, q=, v=) SHOULD route operators to the signatures-explained spoke for the full byte-grammar reference. Distinct from the DKIM-explained pillar above (which is the PROTOCOL-WALKTHROUGH primer covering the verification pipeline end-to-end) and the DKIM-DNS-syntax spoke above (the DNS TXT-record reference for the public-key publication side — the v=DKIM1; k=rsa; p=... record at <selector>._domainkey.<domain>) — this is the DKIM-SIGNATURE-HEADER byte-grammar reference that the protocol presupposes but does not itself document at the per-tag operational-detail level.
DKIM failures explained (the verification-failure taxonomy) — the operational deep dive on the per-failure-class diagnostic taxonomy for every DKIM verification-failure result code this glossary catalogues in single-sentence form. Where this glossary defines "DKIM fail", "body hash mismatch", "DKIM permerror", and "DKIM temperror" each in a single vocabulary entry, the failures- explained spoke documents the FULL per- class diagnostic decision tree: the four canonical failure result codes (bodyhash mismatch — forwarder-induced or canonicalization- mismatch; signature mismatch — selector-key-rotation race or wrong public key fetched; permerror — selector NXDOMAIN, malformed DKIM- Signature header, or oversized signature rejected; temperror — DNS SERVFAIL on selector lookup or transient verifier-side resource exhaustion) with the specific auth_results/dkim/comment substring patterns each receiver reports in the aggregate-report row. Read the failures-explained spoke when the glossary's single-sentence definition leaves a diagnostic-decision question unanswered ("which of the four classes does THIS RUA-row dkim=fail fall into", "is the recurring failure on my Reply-To-rewriting forwarder a bodyhash mismatch or a signature mismatch", "does a selector NXDOMAIN produce permerror or temperror") — the spoke is the authoritative diagnostic-decision reference for converting a DKIM-fail signal in the RUA stream into a specific root-cause remediation.
DKIM troubleshooting — the symptom-driven debugging reference — the operational red-path companion to every DKIM vocabulary entry this glossary catalogues. Where this glossary defines "DKIM selector", "DKIM signature", "DKIM body hash", "DKIM canonicalization", "DKIM key rotation", "DKIM temperror / permerror", and "l= tag" each in a single-sentence vocabulary entry, the troubleshooting spoke is the SYMPTOM-DRIVEN diagnostic ladder operators actually walk when a production DKIM deployment misbehaves. Distinct from the DKIM-failures-explained taxonomy reference (sibling above): failures_explained organises by FAILURE-CLASS (bodyhash / signature / permerror / temperror) for RUA-row-to-class classification; troubleshooting organises by SYMPTOM (selector NXDOMAIN at fresh deploy, selector-name mismatch across multiple signing infrastructures, public-key truncation past the 255-byte character-string boundary, TXT-vs-CNAME selector record-type mismatch, DNS propagation-window mismatch between signer and verifier, forwarder-injected footer or whitespace-rewriting list server breaking body-hash, MIME re-encoding breaking relaxed/relaxed body canonicalization, signature algorithm rejection — RSA-1024 rejected at modern Microsoft / Google receivers, ED25519-key rejection at legacy verifiers, key-rotation overlap-window misconfiguration, BIMI display loss after DKIM regression). Read the troubleshooting spoke when an operator arrives with a SYMPTOM (rather than a failure-class classification) and needs the symptom→diagnosis→fix walkthrough that the glossary's single-sentence definitions cannot embed.
DKIM replay attacks — the GLOSSARY-VOCABULARY-RESOLVES-TO- POST-VERIFICATION-RESIDUAL-ATTACK-SURFACE companion to this email-authentication glossary's DKIM and signature-mechanics vocabulary entries. Where this glossary defines "DKIM signature", "body hash", "l= tag", "signing timestamp t=", "signature expiration x=", "signed-header set", "selector", and "signing algorithm" each in single-sentence vocabulary form, the replay-attacks spoke is the ATTACK-MECHANICS catalogue documenting the operational pattern whereby an attacker captures a single legitimately DKIM-signed message and re-injects the EXACT SAME signed bytes at scale across thousands of receivers — every per- message verification emits dkim=pass (the signature cryptographically verifies against the captured signed-header set + body-hash), DMARC alignment passes (the d= domain still matches the From: header), and yet the receiving infrastructure has been weaponised to deliver attacker-chosen recipient lists at the legitimate sender's reputation. TWENTY-EIGHTH glossary-as-universal-source use per memory feedback_glossary_as_universal_source: the email-authentication glossary's DKIM-signing / body-hash / signature-validity-window / post-verification-defence vocabulary entries naturally resolve to the replay-attacks spoke as the POST-VERIFICATION-RESIDUAL-ATTACK-SURFACE catalogue every DKIM-related vocabulary term this glossary defines ultimately defends against (or, in the case of the l= tag, ENABLES if misconfigured). Four operationally- distinct attack-class axes the spoke documents that this glossary's vocabulary entries individually catalogue but never collectively interconnect: (i) baseline signature-reuse replay — capture-and-replay of the verbatim DKIM-signed message across attacker-chosen recipient channels with no payload modification (the single-message replay-amplification attack class); (ii) l= body- length-limit trailing-content injection replay — exploitation of the l= tag's signed-prefix-only coverage to append attacker-chosen UNSIGNED trailing content (new recipient list, new phishing payload, new attachment) AFTER the l=-bounded signed prefix while still earning a dkim=pass verdict (the operational reason DKIM best practices forbid l= in production signing); (iii) signature-validity-window hardening via x=/t= — the documented mitigation contract whereby signers narrow the x=−t= validity window from the de-facto unbounded- emission default to a deliberately-narrow (≤7 days) operational window, strictly bounding the post-capture replay-attempt window and shifting attacker economics toward faster-but-narrower-yield campaigns; and (iv) receiver- side per-selector recipient-velocity baseline detection — the residual-attack-surface DETECTION signal that no per-message DKIM verification can independently surface, increasingly published as a deliverability-tier gate by Gmail / Yahoo / Microsoft / Apple mailbox-provider reputation systems. Read the replay-attacks spoke when this glossary's signature-and- replay vocabulary needs to resolve to the residual-attack-surface engineering model an anti-impersonation defender actually deploys against a successfully- signed but maliciously-replayed message stream — the spoke is the canonical attack-mechanics reference downstream of every signature-reuse / signature- validity-window / per-message-velocity- baseline vocabulary term this glossary catalogues at the email-authentication- terminology layer.
Reverse DNS / PTR records for mail servers — the operator deep dive on the SMTP-connection-layer reverse-DNS vocabulary this glossary catalogues (PTR record, in-addr.arpa, ip6.arpa, FCrDNS / Forward-Confirmed reverse DNS, HELO/EHLO host, generic provider PTR, delegated reverse zone, nibble-reversed IPv6 encoding). Where this glossary defines each term in a single sentence, the reverse-DNS page documents the full byte-level DNS-record syntax (the in-addr.arpa octet-reversal convention, the ip6.arpa nibble-reversal convention, the canonical PTR record format per RFC 1035 section 3.3.12 and the terminology formalised in RFC 8499), the FCrDNS check sequence performed by every modern SMTP receiver per RFC 1912 section 2.1 reinforced by RFC 5321 BEFORE any SPF / DKIM / DMARC evaluation runs, the operationally-significant difference between forward-zone delegation (registrar to domain owner) and reverse-zone delegation (RIR to IP-block holder to ISP / cloud provider), the deprecation of the SPF ptr mechanism per RFC 7208 section 5.5 ("SHOULD NOT BE PUBLISHED"), and the canonical reverse-DNS mistakes (missing PTR, generic provider PTR like cust-203-0-113-1.isp.example, PTR-and-HELO mismatch, missing IPv6 PTR after dual-stack rollout, multiple PTRs on one IP, PTR pointing at non-resolving forward hostname, PTR change request submitted to wrong registrar). Pair this glossary with the reverse-DNS page to translate "FCrDNS" from a vocabulary entry into the actual SMTP-connection reputation check that runs BENEATH the protocol layer this glossary otherwise documents.
MX records explained — the dedicated DNS-record deep dive on the MX resource record class this glossary catalogues alongside other DNS-published email-authentication records. Where this glossary defines "MX record", "preference value", "implicit MX-from-A fallback", and "MX-target host" each in a single sentence, the MX records page documents the full RFC 1035 section 3.3.9 wire format (16-bit preference + RDATA target name), the canonical multi-MX failover pattern with preference values (10 primary / 20 secondary / 30 tertiary), the implicit-MX-from-A fallback rule when no MX is published per RFC 5321 section 5.1 (the receiver falls back to A/AAAA of the domain itself), the cloud-mail "MX points at provider" pattern (Google Workspace aspmx.l.google.com + 4 backup MXs, Microsoft 365 example-com.mail.protection.outlook.com), and the operationally-significant distinction between INBOUND MX targets (used by receivers for SMTP delivery) and OUTBOUND mail sources (which never appear in MX records and require independent SPF/DKIM/DMARC authentication). Pair this glossary with the MX records page to translate "MX record" from a vocabulary entry into the actual DNS-record class that gates every inbound SMTP delivery to your domain and that the SPF mx mechanism reads at authentication time.
Email spoofing — the threat-class catalogue — the technique-catalogue companion to the protocol vocabulary on this page. Where this glossary defines individual vocabulary terms (RFC 5322 From: header, RFC 5321 envelope MAIL FROM, AUID, Display-Name, Reply-To, Punycode / A-label IDN encoding, identifier alignment, organizational domain) each in a single sentence, the spoofing page documents the seven canonical attacker techniques that abuse each protocol surface this glossary catalogues: (1) exact-domain From-header forge against an unpublished DMARC record, (2) Punycode / IDN homograph From-domain substitution (аpple.com with Cyrillic "а" U+0430 instead of Latin "a" U+0061 renders identically in most fonts), (3) Display-Name-only spoofing where the address-spec From: actually points at the attacker but Display-Name reads as the victim brand, (4) Reply-To substitution where SPF/DKIM/DMARC all align on the attacker's domain but the Reply-To: routes the reply to attacker-controlled infrastructure, (5) envelope-MAIL-FROM-vs-From split exploiting relaxed alignment, (6) subdomain abuse on never-defended child labels, (7) lookalike-TLD attacks (example.co vs example.com, example.com.cm typo-domain registration). Pair this glossary with the spoofing page to translate "From header" from a vocabulary entry into the actual attacker abuse surface area each tag-value DMARC standard structurally denies.
Phishing protection — the operator-facing defense-in-depth playbook — the OPERATIONAL DEFENSE-IN-DEPTH PLAYBOOK companion to the threat-class catalogue sibling spoke above (email-spoofing) and to this protocol-vocabulary glossary. Where this glossary defines individual protocol terms (DMARC p= policy, DKIM d= tag, SPF qualifiers, identifier alignment, organizational domain, ARC chain validation) each in a single sentence, and where the email-spoofing spoke catalogues the seven attacker techniques that abuse each protocol surface, the phishing-protection spoke documents the OPERATOR-SIDE LAYERED CONTROL STACK that the glossary vocabulary composes into a working defense: (i) authentication-protocol layer (the SPF + DKIM + DMARC + BIMI + MTA-STS + DANE + ARC controls this glossary catalogues in vocabulary form, deployed in production- ready configuration), (ii) gateway-control layer (Secure Email Gateway + sandbox URL analysis + attachment detonation + AI-based content classification), (iii) endpoint layer (EDR + browser isolation + phishing-resistant WebAuthn / FIDO2 MFA), (iv) identity layer (Conditional-Access + impossible-travel detection + token-binding + session-risk scoring), (v) user-behaviour layer (continuous phishing simulation + reporter- button workflow + JIT just-in-time training), (vi) response layer (SOC + SIEM correlation + SOAR playbook automation + tabletop-exercise cadence). Read this spoke after the vocabulary on this glossary when an operator asks "what does the full anti-phishing control stack look like" — the glossary tells you WHAT each protocol primitive is in single- sentence form, the phishing-protection spoke tells you HOW those primitives compose into a layered defense alongside the non-protocol controls (EDR / SEG / MFA / SIEM / IR) that sit ABOVE and BELOW the email-authentication layer in the defense-in-depth stack.
DMARC records tag-by-tag — deep dive on every DMARC tag: p, sp, np, adkim, aspf, pct, fo, rua, ruf, ri, rf.
DMARC alignment explained — deep dive on identifier alignment, relaxed vs strict, the organizational domain, and the Public Suffix List.
DKIM alignment with DMARC (the adkim= half of identifier alignment) — the FOCUSED DKIM-SIDE-ONLY deep dive on the identifier-alignment vocabulary this glossary catalogues in single-sentence form. Where THIS glossary defines adkim, strict alignment, relaxed alignment, organizational domain, Public Suffix List, FQDN equality, signing domain, and DKIM d= tag each in a single-sentence vocabulary entry, AND the DMARC-alignment-explained spoke above catalogues the JOINT SPF+DKIM alignment evaluation algorithm (the pass-if-either OR rule across the two underlying authentication mechanisms), the DKIM-alignment-with-DMARC spoke is the DKIM-HALF-ONLY focused reference: the DKIM-Signature d=-tag extraction from the verified signature, the From: header organizational-domain extraction, the adkim=r (relaxed: organizational-domain match via the Public Suffix List boundary) vs adkim=s (strict: FQDN equality) policy knob and the receiver- side decision tree, and the canonical DKIM-pass-but-DMARC-fail provenance patterns each mode produces. Glossary readers landing on this entry to understand adkim get the single-sentence definition above; the DKIM-alignment spoke is the authoritative operator reference for the three CANONICAL DKIM-alignment-failure provenance patterns that drive every observed DKIM-pass-but-DMARC-fail aggregate-report row: (i) the M365 onmicrosoft.com gotcha (Microsoft 365 default signing uses d=<tenant>.onmicrosoft.com when the From: domain is the customer's vanity domain — fixed by enabling customer-domain DKIM in Defender's DKIM blade), (ii) the Google Workspace gappssmtp.com gotcha (Workspace default signing uses d=<domain>.gappssmtp.com for non-Workspace-DKIM-enabled customers — fixed by enabling customer-domain DKIM in the Workspace Admin Console), (iii) the ESP shared-domain signing pattern at SendGrid / Mailchimp / Postmark / Mandrill / Amazon SES (the ESP signs with d=<esp-domain> unless CNAME-delegated authenticated- domain DKIM is provisioned). Pair this glossary (the term definitions for adkim, relaxed, strict, organizational domain, PSL) with the DKIM-alignment-with-DMARC spoke (the authoritative operator reference for what produces a dkim=pass + dmarc=fail row in the aggregate-report stream) when an operator asks "I see DKIM passing but DMARC failing — which of the three canonical gotchas is biting me".
DMARC policy rollout — operator playbook for the p=none → p=quarantine → p=reject migration cadence with pct ramping.
DMARC policy modes — p=none vs p=quarantine vs p=reject (the GLOSSARY-TERM-RESOLUTION head-to-head comparison reference) — the focused GLOSSARY-TERM-RESOLUTION companion documenting the head-to-head comparison of the three DMARC enforcement values p=none / p=quarantine / p=reject whose single-sentence definitions this glossary catalogues. Where THIS glossary defines the DMARC policy entry, the p tag entry, the sp tag entry, the np tag entry, the monitor mode entry, the quarantine entry, the reject entry, and the policy_evaluated entry each in single-sentence form, the policy-modes spoke documents the FULL head-to-head receiver- enforcement contract each value implies: the p=none verdict (receivers IGNORE the DMARC verdict and deliver-to-inbox even on policy_evaluated=fail rows — pure monitoring mode, suitable for the initial 2-4 week observation window when DMARC is first deployed), the p=quarantine verdict (receivers DELIVER-TO-JUNK on fail rows — partial enforcement, suitable for the intermediate stabilisation phase when most but not all legitimate senders have been identified), the p=reject verdict (receivers SMTP-REJECT-AT-RCPT or DROP on fail rows — full enforcement, the operator's target end-state). Critical vocabulary cross- reference when a glossary definition leaves a per-policy-mode behaviour question unanswered — the spoke is the authoritative reference for the three-value VALUE-CHOICE decision every operator must make as their DMARC deployment matures, the pct= percent-rollout knob that gradually shifts enforcement from the prior mode to the current mode, the fo= forensic-feedback options gated by the policy-mode choice, and the operator-observable receiver-side enforcement signals (aggregate-report policy_evaluated/disposition field mirroring the active mode). Seventeenth glossary-as-universal-source application per the cluster's universal- source pattern.
DMARC multi-domain strategy (portfolio-level design) — the portfolio-design reference that the glossary's vocabulary entries organizational domain, subdomain, parked domain, sp tag, np tag, Public Suffix List, and shared sender domain are each defined for in single-sentence form. Where THIS glossary entry-by-entry catalogues the vocabulary AT THE TERM LEVEL, the multi-domain-strategy spoke documents the OPERATIONAL DESIGN at the portfolio level: how the organizational-domain umbrella governs subdomain DMARC inheritance via the PSL boundary, the parent sp= tag's rollup over unsigned subdomains, the np= tag's rollup over non-existent subdomains preventing attacker-fabricated subdomain spoofing, the per-domain key & selector inventory across the portfolio, parked-domain p=reject with explicit SPF v=spf1 -all / DKIM-zero-selector publication, the M&A integration cadence consolidating an acquired brand's DMARC posture, and the shared marketing-sender alignment fanout. Distinct from the policy-rollout spoke above (which is the SINGLE-DOMAIN time-axis migration from p=none to p=reject) — this is the MULTI-DOMAIN portfolio-axis view.
DMARC deployment checklist (step-by-step procedural reference) — the operational deep dive on the first-time DMARC deployment procedure this glossary catalogues as a single vocabulary entry. Where this glossary defines "DMARC deployment" / "DMARC rollout" / "sender inventory" each in a single single-sentence definition, the deployment-checklist spoke documents the FULL procedural sequence: the pre-flight sender inventory enumerating every SaaS, MTA, and ESP that sends from @your-domain, the SPF + DKIM prerequisite verification across all sources, the baseline RUA-stream instrumentation BEFORE the policy publishes, the initial syntactically-complete p=none record construction with the receiver-side propagation verification at multiple resolvers, and the 30-60-day post-publication monitoring cadence with weekly RUA review and ramp-decision gates. Where the policy-rollout sibling above is the CADENCE companion (Week 0 through Week 26 timeline for advancing through the three p= values), the deployment-checklist spoke is the PROCEDURE companion (the step-by-step actions taken at each gate). Read the deployment-checklist spoke when the glossary's single-sentence definition leaves a procedural question unanswered ("what is the actual sequence of steps for a first-time DMARC deployment", "what should I inventory BEFORE publishing the record", "how do I verify the published record reaches receivers correctly before advancing to p=quarantine") — the spoke is the authoritative procedural reference for first-time DMARC publication.
DMARC aggregate reports (RUA) — deep dive on the XML schema, sampling, deduplication, and operator interpretation.
DMARC forensic reports (RUF / AFRF) — the per-message failure-report companion to RUA aggregate reports — the focused per-message-failure deep dive on the RUF (failure-report) channel this glossary catalogues alongside RUA aggregate reports in single-sentence form. Where THIS glossary defines RUF (per-message redacted bounce-style reports sent to the ruf= mailbox on individual message failures), forensic report, AFRF (Authentication Failure Reporting Format, RFC 6591), fo= tag (failure options — 0=both auth fail / 1=either fail / d=DKIM fail / s=SPF fail), rf= tag (reporting format default afrf), and the ruf-forensic-report entry's deployment-state observations ("largely deprecated due to PII / GDPR exposure; Google does not send RUF; Microsoft sends only on explicit opt-in") each in single-sentence form, the forensic-reports spoke documents the FULL operator-side reference for the RUF channel: the RFC 6591 AFRF message-format byte-grammar (multipart/report MIME envelope with the machine-readable message/feedback-report body-part listing the failed auth_results and the redacted message/rfc822-headers body-part carrying the original failed message's headers); the PII / GDPR exposure that drove the modern receiver-side deprecation (RUF reports historically included full message bodies, exposing user PII to the publishing domain via the ruf= URI); the receiver-side policy matrix today (Gmail = does not send RUF at all per Google's 2024 DMARC announcement; Microsoft = sends only on explicit opt-in via the M365 tenant portal; some smaller receivers still send by default); the fo= tag-grammar deep dive distinguishing the four common operator-published values; and the canonical operator workflow for RUF consumption — when forensic reports are worth ingesting at all, the legal-review prerequisite for PII / GDPR compliance, and the per-receiver opt-in / opt-out matrix. Read the forensic-reports spoke when the glossary's RUF / forensic-report / AFRF / fo= / rf= single-sentence entries leave a per-channel operator-side question unanswered — the spoke is the authoritative reference for the full RUF channel from RFC 6591 byte-grammar through GDPR-deprecation context to the modern receiver-side policy matrix every operator must understand before publishing a ruf= tag on a domain.
DMARC reporting pipeline (end-to-end RUA / RUF ingestion architecture) — the END-TO-END OPERATIONAL ARCHITECTURE for the daily aggregate-and-forensic-report stream this glossary catalogues as SINGLE-SENTENCE VOCABULARY ENTRIES. Where THIS glossary defines aggregate report, RUA, RUF, forensic report, failure report, rua= tag, ruf= tag, ri= tag (reporting interval), rf= tag (failure-report format), fo= tag (failure-options), auth_results, policy_evaluated, and policy_published each in a SINGLE-SENTENCE vocabulary entry, the reporting-pipeline spoke documents the 15-section end-to-end operator architecture: Stage 1 ingestion (the IMAP + Microsoft Graph mailbox transport layer the report stream arrives over), Stage 2 format detection and extraction (the RUA XML / ZIP / GZ / TAR.GZ multi-format envelope the receiver-side report-generator emits), Stage 3 parsing (the RUA XML schema traversal that extracts every <record> / <auth_results> / <policy_evaluated> / <policy_published> element the glossary catalogues as vocabulary entries), Stage 4 storage and deduplication (the dmarc_reports / dmarc_records persistence layer with per-XML-report-ID idempotency guard), Stage 5 retention policies (the per-tenant rolling-window archival discipline that defines how long each report persists before age-off), and Stage 6 analysis and alerting (the per-source-IP / per-reporter / per-record drill-down views the dashboard surfaces to operators). Plus the dedicated IMAP- and Graph-setup sections that document the inbound-mailbox transport-layer configuration (OAuth credentials, IMAP folder selection, attachment extraction) every operator MUST configure before any RUA stream materialises in the dashboard. Read the reporting-pipeline spoke when the glossary's single-sentence vocabulary entry leaves an operational question unanswered ("how does my aggregate report actually reach the operator dashboard from the receiver-side report-generator", "what is the end-to-end transport-and-parse pipeline for the daily RUA stream", "which per-stage failure mode produces zero aggregate-report rows in the operator dashboard despite a valid published rua= tag") — the spoke is the authoritative end-to-end operator reference for the report-stream observability infrastructure the glossary's vocabulary entries name each piece of in isolation.
DMARC monitoring discipline — the GLOSSARY-VOCABULARY-RESOLVES- FORWARD-TO-OPERATIONAL-MONITORING- DISCIPLINE companion documenting the daily-weekly-quarterly observability cadence the glossary's monitoring- vocabulary entries operationally instantiate. Where THIS glossary defines aggregate report, RUA, policy_evaluated, policy_published, source_ip, header_from, disposition, dkim_aligned, spf_aligned, ri= tag (reporting interval), pct= tag (rollout percentage), and fo= tag (failure-options) each in a SINGLE- SENTENCE vocabulary entry, the DMARC- monitoring spoke documents the FOUR canonical operational monitoring observation classes the vocabulary entries above are the BUILDING BLOCKS of: (i) daily-failure-row-count delta monitoring — the policy_evaluated.dkim=fail / policy_evaluated.spf=fail row-count delta between consecutive UTC- day RUA batches is the canonical signal the operator watches for sudden alignment breakage; (ii) per-source_ip failure-attribution monitoring — grouping failures by source_ip + header_from is the canonical attribution discipline the operator uses to localise WHICH sender's infrastructure produces the alignment failure; (iii) RUA- arrival-cadence anomaly monitoring — measuring time-between-arriving- aggregate-reports against the published ri= tag's expected delivery rhythm is the canonical signal that the publisher-side rua= tag addressing or the receiver-side mailbox ingestion has broken; (iv) policy- distribution ramp monitoring — comparing the published p= value in policy_published against the disposition column in each row of policy_evaluated is the canonical signal that receiver-side adoption of the published policy lags the publisher-side ramp, often gated by the pct= tag's gradual roll- out percentage. Read the DMARC-monitoring spoke WHEN looking up any of the monitoring-vocabulary entries above and wondering "how do I operationally use this in my daily monitoring cadence" — the spoke documents the per-vocabulary- entry operational discipline the glossary entry itself catalogues as a single- sentence vocabulary atom. Where THIS glossary is the LOOKUP TABLE the operator consults to decode a term, the monitoring spoke is the OPERATIONAL CADENCE REFERENCE the operator consults to embed the term's referent into their daily observability discipline.
Email deliverability — the cluster-spanning operational reference — the operational deep dive on the business-outcome layer this glossary catalogues as individual single-sentence vocabulary entries. Where this glossary defines "inbox placement" / "sender reputation" / "engagement signals" / "complaint rate" / "encryption rate" / "bounce code" each in a single single- sentence definition, the deliverability spoke is the cluster-spanning operational reference that documents the FULL 14-section deliverability framework (delivery funnel, authentication layer, sender reputation across IP / domain / tenant / engagement axes, list hygiene, postmaster tools across Google / Microsoft / Yahoo, SMTP bounce taxonomy, inbox vs spam vs Promotions placement models, common misconceptions, and the best-practices checklist). Where the single-sentence definitions in this glossary collapse each concept to its minimum-viable vocabulary entry, the deliverability spoke is the cluster-spanning operational reference that wires every term back into the cause-and-effect chain receivers use to score every inbound message. The deliverability spoke is especially valuable as a single navigation target for the cluster-spanning glossary because it is the rare help-cluster page that touches all eight protocol layers (SPF / DKIM / DMARC / ARC / BIMI / MTA-STS / TLS-RPT / CAA) in a single unified business-outcome frame — operators who arrive at this glossary from any cluster pillar will find the deliverability spoke as the natural cross-cluster bridge that explains why each protocol matters operationally. Read the deliverability spoke when the glossary's single-sentence definition leaves a business-outcome question unanswered ("how does sender reputation actually move", "what is the cause-and- effect chain between SPF/DKIM/DMARC and Gmail's spam-folder placement model", "which Gmail / Yahoo Bulk Sender Requirements are deliverability prerequisites and which are deliverability accelerants") — the spoke is the authoritative cluster-spanning operational reference for the deliverability business outcome.
BIMI explained — pillar page covering Mark Type Indicator, VMC, SVG Tiny PS, and the l= / a= tags.
BIMI Verified Mark Certificates (VMC and CMC) — the trademark-attestation deep dive sibling of the BIMI-explained pillar above — the operational deep dive on the Verified-Mark-Certificate (VMC) and Common-Mark-Certificate (CMC) issuance, validation, and renewal procedure this glossary catalogues as individual single-sentence vocabulary entries. Where this glossary defines VMC, CMC, Mark Type Indicator (MTI), DigiCert / Entrust BIMI CA, trademark evidence pack, PEM-bundle, SVG Tiny PS, BIMI logo a= tag, and BIMI record l= tag each in single-sentence form, the BIMI-certificates spoke documents the full commercial-acquisition procedure operators follow once their DMARC policy ramp reaches p=quarantine or p=reject: which of the two issuing CAs (DigiCert vs Entrust) accepts which trademark evidence pack (registered trademark for VMC vs unregistered mark for CMC — and the asymmetry that only Gmail currently honours CMC while VMC is the broader standard supported by Gmail + Apple Mail + Yahoo + Fastmail + Outlook), the byte-level PEM-bundle file format the BIMI record's a= URL must serve (the SVG-Tiny-PS-embedded-in-X.509 format and the certificate-chain ordering), the 12-month VMC renewal cadence and what triggers an early reissuance (trademark registration change, logo file modification, registrant ownership change), the operational interplay between the VMC's certificate-chain validation and the BIMI record's l= logo-URL plus a= certificate-URL pairing, and the canonical deployment-failure-pattern taxonomy (logo-not-rendering even with valid VMC, mailbox-provider-specific quirks where Outlook honours VMC but Apple Mail rejects, the rendering-suppression cases triggered by DMARC enforcement gaps). The BIMI-certificates spoke is especially valuable as a single navigation target for the glossary because the Verified-Mark- Certificate commercial-acquisition surface is the rare BIMI-cluster page that translates the BIMI protocol's trademark-attestation primitive into the concrete operator-side procurement workflow — operators who arrive at this glossary looking up VMC / CMC / DigiCert / Entrust / trademark-evidence-pack / PEM- bundle vocabulary will find the BIMI-certificates spoke as the authoritative deeper procedural reference. Distinct from the BIMI-explained pillar above (which is the BIMI-PROTOCOL- WALKTHROUGH primer covering the DNS record format and the rendering-pipeline at the mailbox-provider level) — this is the BIMI-CERTIFICATE-ACQUISITION-AND-RENEWAL PROCEDURE that the protocol presupposes but does not itself document.
BIMI SVG Tiny PS file-format requirements — the operational deep dive on the SVG-Tiny-PS-1.2-profile authoring, validation, and serving procedure this glossary catalogues as individual single-sentence vocabulary entries. Where this glossary defines SVG Tiny PS, baseProfile="tiny-ps", viewBox, square aspect ratio, application/svg+xml MIME type, BIMI logo a= tag, and BIMI record l= tag each in single-sentence form, the BIMI-SVG-requirements spoke documents the full file-format authoring procedure operators follow when producing the SVG that the BIMI record's l= URL serves (and that the VMC PEM bundle's a= URL embeds): the SVG Tiny PS 1.2 profile constraints (which SVG features are allowed — basic shapes, paths, gradients, transforms — and which are forbidden — scripts, animations, external resources, metadata, titles, embedded fonts), the square-aspect-ratio requirement and the viewBox="0 0 SIZE SIZE" attribute that enforces it, the baseProfile="tiny-ps" document-element attribute that signals Tiny PS profile compliance to validators, the maximum file-size constraints (~32 KB unminified, ~8 KB minified is the operational target), the background-color requirements that ensure the logo renders distinctly against both light and dark inbox themes, the MIME-type-serving requirements (application/svg+xml or image/svg+xml via the Content-Type response header from the URL the BIMI record's l= tag points to), and the canonical validation tools (BIMI Group's SVG validator, Cloudflare's BIMI inspector, Mailhardener's BIMI lookup tool). The BIMI-SVG-requirements spoke is especially valuable as a single navigation target for the glossary because the SVG Tiny PS profile is the rare BIMI-cluster page that translates the BIMI protocol's logo-display primitive into the concrete file-format authoring procedure operators execute when producing the actual SVG asset — operators who arrive at this glossary looking up SVG-Tiny-PS / baseProfile / viewBox / square-aspect-ratio / application/svg+xml vocabulary will find the BIMI-SVG-requirements spoke as the authoritative deeper procedural reference. Distinct from the BIMI-explained pillar above (the BIMI-PROTOCOL-WALKTHROUGH primer covering the DNS record format and rendering pipeline) and the BIMI-certificates entry immediately above (the BIMI-CERTIFICATE-ACQUISITION-AND- RENEWAL trademark-attestation procedure) — this is the BIMI-SVG-FILE-FORMAT-AUTHORING PROCEDURE that the protocol presupposes but does not itself document at the format-grammar level. Pairs side-by-side with the BIMI-certificates entry for the complete-BIMI-cluster coverage: the certificates spoke covers the COMMERCIAL- TRADEMARK-ATTESTATION surface, this spoke covers the TECHNICAL-FILE-FORMAT surface, and together with the BIMI-explained pillar above they form the three-spoke cluster operators must complete for a production BIMI deployment.
MTA-STS explained — pillar page covering the policy file, modes (none/testing/enforce), and STARTTLS enforcement.
MTA-STS for Google Workspace — the per-provider MTA-STS deep dive — the operational deep dive on the Google-Workspace MTA-STS deployment procedure this glossary catalogues as individual single-sentence vocabulary entries. Where this glossary defines MTA-STS, STARTTLS, STARTTLS stripping, opportunistic TLS, policy file, testing mode vs enforce mode, and TLS-RPT each in single-sentence form, the MTA-STS-for-Workspace spoke documents the full Workspace-side deployment procedure: where exactly to publish the _mta-sts.<domain> TXT record at the registrar (with the v=STSv1; id=<policy-version> format and the version-bump rotation protocol), how to stand up HTTPS hosting for the mta-sts.<domain> web origin (the four common hosting patterns — GCS bucket + Cloud CDN, Cloud Run + Cloud Load Balancing, Firebase Hosting, third-party static-site host — and the certificate-renewal requirements), how to author the /.well-known/mta-sts.txt policy file (the version: STSv1 / mode: testing|enforce|none / mx: *.<provider>.gmail.com / max_age: <seconds> fields and their byte-exact grammar), how to enumerate the four canonical Workspace MX hosts (aspmx.l.google.com + alt1.aspmx.l.google.com + alt2.aspmx.l.google.com + alt3.aspmx.l.google.com + alt4.aspmx.l.google.com) in the policy file's mx: directives, how to wire up TLS-RPT (the _smtp._tls.<domain> TXT record with v=TLSRPTv1; rua= pointing to a JSON-failure-report- ingestion endpoint), and the testing-mode burn-in workflow that protects production mail during the deployment window (publish testing-mode policy → monitor TLS-RPT for failures over 4 weeks → switch to enforce mode only when zero unexplained delivery failures observed). The MTA-STS-for-Workspace spoke is especially valuable as a single navigation target for the glossary because Google Workspace is one of the two operator-personas (with Microsoft 365) that the glossary's transport-security vocabulary catalogues but cannot expand to a full procedural reference within a single-sentence vocabulary entry — operators who arrive at this glossary looking up Workspace-specific MTA-STS vocabulary (the four aspmx.l.google.com MX hostnames, the mta-sts.<domain> hosting requirement, the version-bump DNS-TXT rotation protocol) will find the MTA-STS-for-Workspace spoke as the authoritative deeper procedural reference. Distinct from the MTA-STS-explained pillar above (which is the PROTOCOL-WALKTHROUGH primer) — this is the WORKSPACE-DEPLOYMENT PROCEDURE.
MTA-STS for Microsoft 365 — the per-provider MTA-STS deep dive (Exchange Online sibling of the Workspace entry above) — the operational deep dive on the Microsoft-365 MTA-STS deployment procedure this glossary catalogues as individual single-sentence vocabulary entries. Where this glossary defines MTA-STS, STARTTLS, STARTTLS stripping, opportunistic TLS, policy file, testing mode vs enforce mode, and TLS-RPT each in single-sentence form, the MTA-STS-for-Microsoft-365 spoke documents the full Exchange-Online-side deployment procedure: where exactly to publish the _mta-sts.<domain> TXT record at the registrar (with the same v=STSv1; id=<policy-version> format and version-bump rotation protocol as the Workspace entry above — the policy file itself is the only mailbox-provider- specific surface), how to stand up HTTPS hosting for the mta-sts.<domain> web origin on Azure (the four common Microsoft-native hosting patterns — Azure Blob Storage + Azure CDN, Azure Static Web Apps, Azure App Service, Azure Front Door — and the auto-renewing managed certificate options each provides), how to author the /.well-known/mta-sts.txt policy file with the Exchange-Online-specific mx: directive (mx: <tenant>-com.mail.protection.outlook.com — Exchange Online's tenant-scoped MX hostname differs structurally from the Workspace four-host aspmx.l.google.com / alt1.aspmx.l.google.com / alt2.aspmx.l.google.com / alt3.aspmx.l.google.com / alt4.aspmx.l.google.com set catalogued in the entry above), how to wire up TLS-RPT (the _smtp._tls.<domain> TXT record with v=TLSRPTv1; rua= pointing to a JSON-failure-report-ingestion endpoint), and the testing-mode burn-in workflow that protects production mail during the deployment window (publish testing-mode policy → monitor TLS-RPT for failures over 4 weeks → switch to enforce mode only when zero unexplained delivery failures observed). The MTA-STS-for-Microsoft-365 spoke is especially valuable as a single navigation target for the glossary because Exchange Online is one of the two operator-personas (with Google Workspace, catalogued in the sibling entry above) that the glossary's transport-security vocabulary catalogues but cannot expand to a full procedural reference within a single-sentence vocabulary entry — operators who arrive at this glossary looking up M365-specific MTA-STS vocabulary (the tenant-scoped <tenant>-com.mail.protection.outlook.com MX hostname, the Azure hosting choices for mta-sts.<domain>, the version-bump DNS-TXT rotation protocol) will find the MTA-STS-for-Microsoft-365 spoke as the authoritative deeper procedural reference. Distinct from the MTA-STS-explained pillar above (which is the PROTOCOL-WALKTHROUGH primer) and from the MTA-STS-for-Workspace sibling immediately above (which is the WORKSPACE-DEPLOYMENT procedure) — this is the EXCHANGE-ONLINE-DEPLOYMENT PROCEDURE.
MTA-STS policy file syntax — the byte-exact grammar reference for the /.well-known/mta-sts.txt policy file (version / mode / mx / max_age fields) — the SYNTAX-REFERENCE companion to the MTA-STS pillar + the two MTA-STS deployment guides immediately above. Where the pillar documents the MTA-STS PROTOCOL walkthrough and the deployment guides document the per-provider PROCEDURE, the syntax-reference spoke documents the byte-exact grammar of the /.well-known/mta-sts.txt policy file: the four canonical directives (version: STSv1, mode: testing|enforce|none, mx: <host-pattern>, max_age: <seconds>), the per-directive value rules (the version must be the literal STSv1; the mode is one of three enumerated literals; the mx directive accepts one host per line and supports the leading-*. wildcard for the first label only; the max_age is an integer seconds value bounded by RFC 8461 at 86400 minimum and 31557600 maximum), the repeat-directive semantics (only the mx: directive is repeatable; a repeated mode: or version: is a fatal parse error), the LF / CRLF line-ending rules (the policy file must use UTF-8 encoding with either LF or CRLF line endings — but not mixed within a single file), the comment syntax (the policy file has no comment syntax — any line that is not a recognised directive is a parse error), and the version-bump DNS-TXT rotation protocol (the v=STSv1; id=<policy-version> TXT record at _mta-sts.<domain> is the rotation pin; bumping the id= value forces receivers to re-fetch the policy file before the previously cached max_age: window has elapsed). Read the syntax reference when authoring or reviewing a policy file — the spoke is the authoritative per-directive grammar reference for the four canonical fields that the pillar introduces in PROTOCOL form and the deployment guides apply in PROCEDURE form.
DANE explained — DNS-based Authentication of Named Entities for SMTP (RFC 7672 TLSA-record-via-DNSSEC chain) — the protocol pillar for the TRANSPORT-SECURITY-VIA-DNSSEC primitive that this glossary catalogues in single-sentence vocabulary entries. Where this glossary defines DANE, TLSA record, DNSSEC chain-of-trust, STARTTLS, port 25 / MTA-to-MTA encryption, opportunistic TLS, STARTTLS stripping, and the four TLSA usage / selector / matching-type slots (DANE-EE / DANE-TA / PKIX-EE / PKIX-TA usage × SPKI / FullCert selector × SHA-256 / SHA-512 / FullData matching) each in single-sentence form, the DANE-pillar spoke documents the full RFC 7672 protocol at the operator level: how a publishing domain authors the _25._tcp.mx.example.com IN TLSA record for each MX hostname, why DNSSEC is structurally REQUIRED (without DNSSEC the TLSA record itself is forgeable and DANE collapses to no-defense), how a receiver-side MTA validates the TLSA fingerprint against the certificate presented in the STARTTLS handshake, the operational difference between DANE-EE (pin the leaf certificate hash, certificate rotation requires TLSA-record update) and DANE-TA (pin the issuing CA, certificate rotation requires only same-CA reissue), and the canonical DANE-vs-MTA-STS comparison (DANE = cryptographic trust anchor via DNSSEC ↔ MTA-STS = certificate validation via PKIX with no separate trust anchor). Read this spoke when the glossary's single-sentence DANE / TLSA / DNSSEC entries surface in an operator context (TLS-RPT failure-type tlsa-invalid / dnssec-invalid / dane-required) and you need the full byte-level protocol reference, not just the vocabulary lookup.
MTA-STS vs DANE — the GLOSSARY-VOCABULARY-RESOLVES-TO- TRANSPORT-LAYER-PROTOCOL-CHOICE-DECISION companion reference. Where this glossary defines the transport-security vocabulary in single-sentence entries (MTA-STS, DANE, TLSA record, DNSSEC chain-of-trust, STARTTLS, STARTTLS stripping, opportunistic TLS, certificate validation via PKIX, policy file at /.well-known/mta-sts.txt, policy-id TXT record at _mta-sts.<domain>, TLSA usage / selector / matching-type slot triple, DANE-EE leaf-cert pin, DANE-TA CA-cert pin, policy mode enforce / testing / none, max_age TTL budget, TLS-RPT failure-type tlsa-invalid / sts-policy-fetch-error / certificate-host-mismatch), the MTA-STS-vs-DANE spoke documents the OPERATOR-FACING PROTOCOL-CHOICE DECISION between the TWO transport-security protocols this glossary vocabulary catalogues at the across-protocol comparison-axis level: DNSSEC requirement (DANE STRUCTURALLY requires a DNSSEC- signed parent zone — without DNSSEC the TLSA record is forgeable and DANE collapses to no-defense; MTA-STS is DNS-based but uses certificate-validation via PKIX, working WITHOUT DNSSEC), trust anchor (DANE = cryptographic trust anchor via DNSSEC chain ↔ MTA-STS = certificate validation via PKIX with no separate trust anchor), publication surface (DANE publishes ONE _25._tcp.mx.<domain> IN TLSA record per MX hostname, MTA-STS publishes a TXT record at _mta-sts.<domain> plus a policy file at /.well-known/mta-sts.txt on the publishing domain's HTTPS endpoint), certificate rotation operational cost (DANE-EE pins the leaf certificate hash and EVERY rotation requires a TLSA-record update synchronised with the new certificate's deployment window; DANE-TA pins the issuing CA and rotations within the same CA require NO TLSA-record update; MTA-STS has NO certificate-pin constraint and rotations are operationally free at the protocol level), receiver- side ecosystem coverage (Gmail and Microsoft 365 enforce MTA-STS at receiver-side; major German and Dutch receivers including Deutsche Telekom / T-Online / GMX / Web.de / XS4ALL enforce DANE; many large receivers including Yahoo, Apple iCloud, Comcast, and Orange enforce BOTH at the operator's publication choice). Read the MTA-STS-vs-DANE spoke when the glossary's single-sentence transport- security vocabulary surfaces in an operator's choose-between-protocols decision context (greenfield deployment choice, post-incident remediation, or receiver-population-coverage-driven dual-deployment scoping) and you need the FULL operator-facing decision-tree between the two transport-security protocols, not just per-protocol vocabulary lookups.
TLS-RPT explained — pillar page covering the JSON report format, result types, and the 12 standard failure-type strings.
TLS-RPT record syntax (RFC 8460 §3 byte-level _smtp._tls TXT-record grammar) — the byte-by-byte DNS-record syntax reference for the TLS-RPT PUBLISHER-SIDE record that this glossary catalogues as single-sentence vocabulary entries. Where THIS glossary defines TLS-RPT, _smtp._tls. owner-name prefix, v=TLSRPTv1 version tag, rua= report-aggregation URI tag, mailto: URI scheme, https: URI scheme each in single-sentence form, the record-syntax spoke documents the full RFC 8460 §3 grammar at the byte level: the _smtp._tls.<domain>. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com" canonical record shape, the v=TLSRPTv1 version-tag first-position requirement (RFC 8460 §3.2 — receivers MUST ignore records without this tag in the first position), the rua= URI-list comma-separated syntax (multi- URI failover), the mailto: vs https: URI scheme trade- off (mailto = receiver POSTs reports to an SMTP mailbox you operate; https = receiver POSTs reports to a web endpoint you operate), the external-domain authorisation requirement (mailto: domain ≠ owner domain MUST publish reciprocal v=TLSRPTv1; rua=... delegation per RFC 8460 §3.4), and the canonical 12 publishing-mistakes the syntax page catalogues (missing v= tag, wrong owner-name prefix, unescaped semicolons in URI parameters, missing trailing dot, DNS-record-length 255-octet chunking). Read this spoke once the glossary's single-sentence TLS-RPT / rua= / v=TLSRPTv1 entries surface in an operator-authoring context (publishing the receiver-side TLS-RPT record for a domain) and you need the byte-level record-authoring reference. Pairs with the TLS-RPT report-format sibling below (publisher-side record syntax + receiver-side report format = the full TLS-RPT DEPLOYMENT-AND-CONSUMPTION reference the glossary catalogues in vocabulary form).
TLS-RPT report format (RFC 8460 §4 JSON schema deep dive) — the byte-by-byte JSON schema reference for the TLS-RPT report format that this glossary catalogues as a single vocabulary entry. Where THIS glossary defines TLS-RPT, policy-type, policy-string, failure-details, result-type, and the 12 standard starttls-not-supported / certificate-host-mismatch / certificate-expired / certificate-not-trusted / validation-failure / tlsa-invalid / dnssec-invalid / dane-required / sts-policy-fetch-error / sts-policy-invalid / sts-webpki-invalid failure-type strings each in a SINGLE-SENTENCE definition, the report-format spoke documents the FULL JSON-schema field-by-field anatomy: the report-envelope fields (organization-name, date-range, contact-info, report-id) that identify the receiving MTA + the reporting window, the policies[] array that names each operator-published transport policy (tlsa for DANE / TLSA and sts for MTA-STS) the receiver attempted to enforce, the summary per-policy success-and-failure counters that feed the operator's STARTTLS deployment baseline, the failure-details[] array's per-incident sending-mta-ip + receiving-mx-hostname + failed-session-count + result-type tuples that decompose each failure batch into actionable AiTM-or-misconfiguration diagnosis, and the additional-information URI extension point for reporter-side forensic artifacts (PCAPs, certificate chains, server logs). Distinct from the explained pillar above (which is the PROTOCOL-WALKTHROUGH primer) — this is the BYTE-LEVEL JSON-SCHEMA-FIELD-CATALOGUE.
CAA records explained — pillar page covering issue / issuewild / iodef tags and the CA identifier registry.
ARC explained — pillar page covering the three per-message ARC headers, chain validation, and the trust model for forwarded mail.
DMARC for Google Workspace — deployment guide for Workspace tenants.
DKIM for Google Workspace — the per-provider DKIM-side deep dive — the operational deep dive on the Google-Workspace DKIM signing-setup procedure this glossary catalogues as individual single-sentence vocabulary entries. Where this glossary defines dkim-selector / dkim-header-d / dkim-key-rotation / dkim-canonicalization / dkim-body-hash / gappssmtp each in a single single-sentence definition, the DKIM-for-Google-Workspace spoke is the authoritative per-provider procedural reference covering the FULL Workspace DKIM deployment procedure: where exactly in the Admin console (Apps → Google Workspace → Gmail → Authenticate email) to generate the 2048-bit DKIM keypair, the exact google._domainkey.<domain> TXT-record host + value to publish at the registrar, the Activate button workflow (24-72 hour TXT-propagation gate before Workspace will let an admin click Activate), the verify-with-mail-tester workflow, the half-yearly key-rotation procedure (generate at new selector, wait for propagation, switch signers, drain in-flight mail, remove old selector), and the gappssmtp.com signing-identity gotcha (Workspace's default signing identity is <domain>.gappssmtp.com before custom DKIM is activated — which passes DKIM verification but does NOT align with the From-header organisation domain and therefore fails DMARC alignment). The DKIM-for-Google-Workspace spoke is especially valuable as a single navigation target for the glossary because Google Workspace is one of the two operator-personas (with Microsoft 365) that the glossary's DKIM vocabulary catalogues but cannot expand to a full procedural reference within a single-sentence vocabulary entry — operators who arrive at this glossary looking up Workspace-specific DKIM vocabulary (the google selector, the google._domainkey host name, the gappssmtp.com default signing identity, the Workspace 24-72 hour propagation gate) will find the DKIM-for-Google-Workspace spoke as the authoritative deeper procedural reference. Where this glossary's single-sentence entry for the google selector collapses the concept to a one-sentence definition, the DKIM-for-Google-Workspace spoke documents the full 14-section procedural framework (TL;DR, overview, architecture, prerequisites, Step 1 generate, Step 2 publish, Step 3 activate, verify, rotation, the gappssmtp.com gotcha, seven common mistakes, troubleshooting decision matrix, FAQ, related guides). Distinct from the DKIM-explained pillar above (which is the PROTOCOL-WALKTHROUGH primer) — this is the WORKSPACE-DEPLOYMENT PROCEDURE.
DMARC for Microsoft 365 — deployment guide for Exchange Online tenants.
DMARC for Office 365 hybrid (Exchange on-prem + Exchange Online coexistence) — the per-deployment hybrid-topology deep dive — the operational deep dive on the Exchange-hybrid-coexistence DMARC deployment procedure this glossary catalogues as individual single-sentence vocabulary entries. Where this glossary defines hybrid Exchange, Exchange on-prem, Hybrid Configuration Wizard (HCW), centralized mail transport (CMT), Exchange Online Protection (EOP), connector, send connector vs receive connector, coexistence period, and mailbox migration batch each in single-sentence form, the hybrid-deployment spoke documents the full hybrid-topology procedure operators with concurrent Exchange-on-prem + Exchange-Online mailbox populations follow when configuring DMARC: the dual-transport- path SPF authorisation (the on-prem Exchange edge MTA's outbound IPs PLUS the EOP outbound IPs — both must appear in the SPF record because mail can leave through either path during coexistence), the dual-DKIM-signing- domain coordination (on-prem mail typically signs with the operator's public domain via an Exchange Edge Transport rule, while EOP signs with the CNAME-delegated Microsoft-managed key — both must pass DKIM-verification AND both must align with the From: header per RFC 7489 §3.1.1 for DMARC to pass on either path), the centralized-mail-transport vs non-centralized-mail-transport topologies (CMT routes ALL outbound through on-prem first then EOP, which changes the SPF authorisation chain because mail leaves from the on-prem edge MTA's IPs even for cloud-mailbox senders; non-CMT lets each mailbox use its native transport, which makes SPF authorisation cleaner but loses the data-loss-prevention centralization many enterprises require), the Hybrid-Configuration-Wizard-generated connector pair (the inbound connector from EOP to on-prem and the outbound connector from on-prem to EOP both carry hybrid-coexistence headers that EOP uses for trust decisions — but these headers do NOT establish DMARC alignment by themselves), and the DMARC-aggregate-report attribution across two transport paths (a single receiver-emitted RUA report will contain row groups for both the on-prem edge IP block AND the EOP IP block for the same sending domain; the operator must read both transport-path's row-groups to confirm the rollout is healthy on BOTH paths). The hybrid-deployment spoke is especially valuable as a single navigation target for the glossary because the Exchange-hybrid operator persona is the operator role that the glossary catalogues but cannot expand to a full procedural reference within a single-sentence vocabulary entry — operators who arrive at this glossary looking up Exchange-hybrid vocabulary (hybrid Exchange / HCW / centralized mail transport / EOP / connector / coexistence period) will find the hybrid-deployment spoke as the authoritative deeper procedural reference. Distinct from the per-mailbox-provider DMARC-for-Microsoft-365 spoke immediately above (which documents the SINGLE-PATH cloud-only Exchange Online deployment procedure) — this is the DUAL-PATH hybrid-coexistence deployment procedure that the cloud-only guide presupposes the operator has already migrated past, but does not itself document at the hybrid-topology level. Pairs side-by-side with the DMARC-for-Microsoft-365 entry immediately above for the complete-M365-cluster coverage: the cloud-only spoke covers the single-transport-path EXCHANGE-ONLINE- TENANT deployment, this spoke covers the dual-transport-path EXCHANGE- ON-PREM-PLUS-EXCHANGE-ONLINE hybrid coexistence, and together they form the two-spoke cluster covering both M365 mailbox-population topologies operators encounter.
DKIM for Microsoft 365 — the per-provider DKIM-side deep dive — the operational deep dive on the Microsoft-365 DKIM signing-setup procedure this glossary catalogues as individual single-sentence vocabulary entries. Where this glossary defines dkim-selector / dkim-header-d / dkim-key-rotation / dkim-canonicalization / dkim-body-hash / onmicrosoft each in a single single-sentence definition, the DKIM-for-Microsoft-365 spoke is the authoritative per-provider procedural reference covering the FULL Exchange Online DKIM deployment procedure: where exactly in the Microsoft 365 Defender portal (security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM) to enable signing for the custom domain, the exact two selector1._domainkey.<domain> and selector2._domainkey.<domain> CNAME records (NOT TXT) pointing to selector1-<domain-dash-form>._domainkey.<tenant>.onmicrosoft.com and selector2-<domain-dash-form>._domainkey.<tenant>.onmicrosoft.com respectively (the dash-form is the custom domain with dots replaced by dashes — e.g. example.com → example-com), the enable workflow (Microsoft validates the CNAMEs exist before letting an admin click Enable), the verify-via-Authentication- Results workflow, the dual-selector zero-downtime rotation procedure Microsoft performs automatically every ~6 months by alternating between selector1 and selector2, and the onmicrosoft.com signing-domain gotcha (Exchange Online's default DKIM signing identity before custom-DKIM activation is <tenant>.onmicrosoft.com — which PASSES DKIM verification but does NOT align with the From-header organisation domain and therefore FAILS DMARC alignment despite the green DKIM verdict). The DKIM-for-Microsoft-365 spoke is especially valuable as a single navigation target for the glossary because Microsoft 365 is one of the two operator-personas (with Google Workspace) that the glossary's DKIM vocabulary catalogues but cannot expand to a full procedural reference within a single-sentence vocabulary entry — operators who arrive at this glossary looking up Exchange-specific DKIM vocabulary (the selector1 / selector2 alternating selector pair, the _domainkey.<tenant>.onmicrosoft.com CNAME-target template, the onmicrosoft.com default signing identity, the ~6-month Microsoft-driven rotation cadence) will find the DKIM-for-Microsoft-365 spoke as the authoritative deeper procedural reference. Where this glossary's single-sentence entry for the selector1 / selector2 Exchange Online selector pair collapses the concept to a one-sentence definition, the DKIM-for-Microsoft-365 spoke documents the full 14-section procedural framework (TL;DR, overview, architecture, prerequisites, Step 1 publish CNAMEs, Step 2 enable, Step 3 verify, rotation, the onmicrosoft.com gotcha, seven common mistakes, troubleshooting decision matrix, FAQ, related guides). Distinct from the DKIM-explained pillar above (which is the PROTOCOL-WALKTHROUGH primer) — this is the EXCHANGE-ONLINE-DEPLOYMENT PROCEDURE. Pairs with the DKIM-for-Google-Workspace spoke immediately above for the two-major- mailbox-provider DKIM deployment coverage; the CNAME-vs-TXT record-type distinction between Exchange Online (CNAME-delegated to Microsoft-managed key) and Google Workspace (TXT-published from Workspace-managed key) is the most common operator confusion when switching between platforms.
SPF for Microsoft 365 — the operational deep dive on the Microsoft-365 SPF authoring procedure this glossary catalogues as individual single-sentence vocabulary entries. Where this glossary defines spf-include / spf-mechanism-include / spf-lookup-limit / spf-permerror / spf-aligned-pass / spf-mailfrom-domain / spf-soft-fail / spf-hardfail / spf-all-mechanism each in a single single-sentence definition, the SPF-for-Microsoft-365 spoke is the authoritative per-provider procedural reference covering the FULL Microsoft 365 SPF authoring procedure: the canonical v=spf1 include:spf.protection.outlook.com -all baseline record shape for an M365-tenant custom domain whose outbound mail flows exclusively through Exchange Online, the spf.protection.outlook.com sub-include cascade (the top-level include expands to spf-a.outlook.com / spf-b.outlook.com / spfd.protection.outlook.com sub-tokens, each consuming a lookup slot of the 10-DNS-lookup budget imposed by RFC 7208 §4.6.4), the ~all-vs--all qualifier-selection decision tree (Microsoft's published guidance ships both depending on Exchange-hybrid topology presence and rollout phase), the on-prem-Exchange hybrid coexistence pattern (on-prem outbound hostnames must be added as explicit ip4: or a:mail.<org>.<tld> tokens because they are NOT covered by the Microsoft-managed spf.protection.outlook.com include), the secondary-SaaS-sender layering pattern (SendGrid / Mailgun / Amazon SES / Mailchimp / HubSpot / Marketo senders need their own include tokens added alongside the M365 baseline — and the cascade-overflow class is the dominant failure mode this layering produces, surfacing as spf=permerror in Authentication-Results), the M365 Direct-Send / SMTP-AUTH-relay-from-outside-M365 coverage gap (Direct-Send / SMTP-relay originating from outside the M365-tenant outbound IP envelope is NOT covered by spf.protection.outlook.com and requires explicit ip4: tokenisation), and the verify-via-Authentication-Results workflow (M365 outbound is verified via the spf=pass (sender IP is …) Authentication-Results line at a recipient mailbox provider). The SPF-for-Microsoft-365 spoke is especially valuable as a single navigation target for the glossary because Microsoft 365 is one of the two operator-personas (with Google Workspace) that the glossary's SPF vocabulary catalogues but cannot expand to a full procedural reference within a single-sentence vocabulary entry — operators who arrive at this glossary looking up M365-specific SPF vocabulary (the spf.protection.outlook.com baseline token, the cascade-overflow permerror cause, the Direct-Send coverage gap, the hybrid-Exchange on-prem-IP4-supplementation pattern, the secondary-ESP-include-layering cohabitation pattern) will find the SPF-for-Microsoft-365 spoke as the authoritative deeper procedural reference. Where this glossary's single-sentence entry for spf-include collapses the concept to a one-sentence definition, the SPF-for-Microsoft-365 spoke documents the full M365-tenant SPF-authoring framework (TL;DR, overview, architecture, prerequisites, baseline record, hybrid-Exchange coexistence, secondary-ESP layering, lookup-cost management, qualifier selection, Direct-Send gap, verify- via-Authentication-Results, common mistakes, troubleshooting decision matrix, FAQ, related guides). Distinct from the SPF-explained pillar near the top of this Related Guides section (which is the PROTOCOL- WALKTHROUGH primer) — this is the EXCHANGE-ONLINE-DEPLOYMENT PROCEDURE. Pairs with the SPF-for-Google-Workspace entry (the Workspace-tenant SPF sibling) for the two-major- mailbox-provider SPF deployment coverage; the spf.protection.outlook.com- vs-_spf.google.com baseline-token distinction between Exchange Online (Microsoft-managed sub-include cascade) and Google Workspace (Google-managed flatter include) is the most common operator confusion when authoring SPF for a domain that flows mail through both platforms.
DMARC for cPanel & Shared Hosting — deployment guide for SMB / shared-hosting operators.
DMARC for SaaS senders — the per-deployment deep dive for multi-tenant platforms sending mail on behalf of customer domains — the operational deep dive on the SaaS-multi-tenant DMARC deployment procedure this glossary catalogues as individual single-sentence vocabulary entries. Where this glossary defines SaaS sender, multi-tenant platform, per-tenant DKIM, CNAME-delegated DMARC record, per-tenant subdomain, virtual MTA pool, shared sending IP, tenant brand- impersonation isolation, and heterogeneous policy-mode distribution each in single-sentence form, the SaaS-senders spoke documents the full multi-tenant deployment procedure operators on both sides of the SaaS boundary follow when the SaaS platform sends mail on behalf of customer domains: the per-tenant authentication-plane that isolates each customer's DKIM-key + DMARC-policy + SPF envelope-sender from every other tenant's, the CNAME-delegation pattern the customer publishes (_dmarc.<tenant>.<customer>.com CNAME _dmarc.<tenant-id>.<saas>.com) so the SaaS provider owns the runtime DMARC record at the operational layer while the customer retains DNS-publishing control, the per-tenant DKIM-key rotation cadence the SaaS platform coordinates across its tenant fleet, the virtual-MTA-pool-per-tenant pattern that isolates outbound-IP reputation between tenants, the heterogeneous- policy-mode-distribution the SaaS platform sees across its fleet (some tenants at p=none, some at p=quarantine, some at p=reject simultaneously), the per-tenant aggregate-report attribution the SaaS provider parses from the receiver-emitted RUA stream, the brand-tenant asset-upload pipeline (logo, BIMI SVG, VMC bundle) the SaaS platform must implement per-tenant for BIMI rendering, and the cross-tenant phishing-defense pattern that isolates customer A's brand from being spoofed through customer B's compromised tenant context. The SaaS-senders spoke is especially valuable as a single navigation target for the glossary because the SaaS-multi-tenant operator persona is the operator role that the glossary catalogues but cannot expand to a full procedural reference within a single-sentence vocabulary entry — operators who arrive at this glossary looking up SaaS-multi-tenant vocabulary (SaaS sender / multi-tenant platform / per-tenant DKIM / CNAME-delegated DMARC / virtual MTA pool / heterogeneous policy-mode distribution) will find the SaaS-senders spoke as the authoritative deeper procedural reference. Distinct from the per-mailbox-provider DMARC deployment spokes above (DMARC for Google Workspace, DMARC for Microsoft 365, DMARC for cPanel / shared hosting) which document the SINGLE-TENANT OPERATOR-AT-A-MAILBOX-PROVIDER deployment procedure — this is the MULTI-TENANT-SAAS-PLATFORM-ON-BEHALF-OF- CUSTOMER-DOMAINS deployment procedure that the per-provider mailbox guides presuppose the SaaS layer has already completed, but do not themselves document at the multi-tenant authentication-plane level. Pairs side-by-side with the shared-hosting spoke immediately below: the shared-hosting spoke covers the OPERATOR-EMPOWERMENT-CEILING that constrains tenants on shared infrastructure they do not control, while the SaaS-senders spoke covers the inverted view — the SaaS-PLATFORM- OPERATOR-EMPOWERMENT-FLOOR that the SaaS provider must implement to enable per-tenant DMARC sovereignty for customers on the platform's shared infrastructure.
DMARC for shared hosting (cPanel / Plesk / DirectAdmin) — the per-provider deep dive — the operational deep dive on the shared-hosting deployment procedure this glossary catalogues as individual single-sentence vocabulary entries. Where this glossary defines "shared hosting" / "operator empowerment ceiling" / "shared IP reputation" / "tenant-level DKIM" / "shared MTA" each in a single single-sentence definition, the shared-hosting spoke is the authoritative per-provider procedural reference covering the FULL deployment procedure across the three major shared-hosting platforms (cPanel / Plesk / DirectAdmin): where exactly in the control-panel UI to publish the _dmarc.<domain> TXT record, how to inventory legitimate senders when the shared-hosting MTA's d= domain belongs to the provider not to the tenant, the operator-empowerment ceiling that constrains custom-domain DKIM, the shared-IP-block reputation observability gap, and the ?all qualifier degradation many shared-hosting platforms force on operators. The shared-hosting spoke is especially valuable as a single navigation target for the glossary because shared-hosting is the operator-persona that the glossary catalogues but cannot expand to a full procedural reference within a single-sentence vocabulary entry — operators who arrive at this glossary looking up shared-hosting vocabulary (cPanel / Plesk / DirectAdmin / shared IP / shared MTA / operator-empowerment ceiling) will find the shared-hosting spoke as the authoritative deeper procedural reference. Where this glossary's single-sentence entry for "shared hosting" collapses the concept to a one-sentence definition, the shared-hosting spoke documents the full 13-section procedural framework (Feb 2024 requirements + operator- empowerment ceiling, prerequisites, Step 1 SPF, Step 2 DKIM, Step 3 DMARC p=none, Step 4 sender inventory + alignment fixes, Step 5 advance to p=quarantine then p=reject, shared-hosting gotchas, common mistakes, troubleshooting, FAQ). Read the shared-hosting spoke when the glossary's single-sentence definition leaves a procedural question unanswered ("what is the actual deployment sequence on cPanel", "what is the operator-empowerment ceiling and how do I work around it", "how do I inventory legitimate senders when the MTA's d= domain is the provider's" ) — the spoke is the authoritative per-provider procedural reference for the shared-hosting operator persona.
DMARC for transactional email — the GLOSSARY-VOCABULARY-RESOLVES-TO-PER- MESSAGE-TYPE-DEPLOYMENT-PATTERN companion to this email-authentication glossary's transactional sender, SaaS- relay envelope, DKIM d= delegation, Return-Path, SPF include: third-party-sender, identifier alignment, and per-stream authentication discipline vocabulary entries. Where this glossary defines each transactional-email-relevant term in single-sentence form, the transactional-email spoke is the authoritative per-message-type deployment reference covering FOUR transactional- email-authentication-provenance dimensions: (i) per-ESP DKIM-signing posture for outbound transactional streams → SendGrid / Mailgun / Postmark / Amazon SES / Stripe-platform / Twilio-SendGrid / Customer.io selector-publication patterns → publisher CNAME-delegation discipline — the transactional-email spoke documents WHICH selector subdomain each canonical transactional ESP requires the publisher to delegate via CNAME, the canonical s1._domainkey.<domain> / s2._domainkey.<domain> SendGrid pattern, the per-tenant <tenant>._domainkey.<domain> Postmark pattern, the AWS SES domain- identity / easy-DKIM CNAME-trio pattern, and the operationally-distinct SHARED-INFRASTRUCTURE-VS-DEDICATED-IP per-tenant DKIM-key sovereignty differences across these platforms; (ii) per- ESP SPF include: cascade and the 10-DNS- lookup limit — multi-ESP SPF flattening coordination → envelope-MAIL-FROM-vs-From alignment-relaxation strategy — the transactional spoke documents the canonical operator failure pattern (publish SPF with SendGrid + Mailgun + Amazon SES + Postmark + Salesforce + HubSpot include: tokens then hit PermError at the 10-lookup ceiling), the flattening-vs-include trade-off (flatten for fixed-IP ESPs, retain include for ESPs with rotating IP fleets), and the per-ESP envelope-Return-Path patterns (bounces.<tenant>.sendgrid.net, email.<tenant>.mailgun.org, per-domain Return-Path on Amazon SES); (iii) per-message-type DMARC enforcement ramp — transactional-only sub-domains vs apex-mixed deployment — the transactional spoke documents the operationally-significant per-stream subdomain pattern (publish marketing / transactional / corporate streams on DEDICATED subdomains so each stream's DMARC enforcement ramp can advance INDEPENDENTLY of the others), the per- stream RUA-row attribution discipline operators use to identify which stream is misaligned before advancing p=none → p=quarantine → p=reject, and the canonical anti-pattern (mixing all transactional ESPs + corporate Microsoft 365 + marketing automation on the BARE apex domain forces every stream onto the slowest stream's enforcement ramp); (iv) transactional-message inbox- placement sensitivity — the receiver-side reputation consequence of any transactional-stream misalignment — the transactional spoke documents WHY transactional streams are the highest- sensitivity surface for the receiver-side reputation feedback loop (recipients actively EXPECT order confirmations, receipts, and password-reset codes within seconds-to-minutes of triggering; spam- folder routing of these messages produces the highest user-reported-as-junk complaint-rate baseline of any operationally-distinct stream type; spam-folder password-reset codes are the canonical support-ticket escalation trigger), the canonical operator-side SLA-vs-deliverability framework coordination point between operations engineering, customer support, and product teams, and the operationally- significant BIMI-eligibility prerequisite (per-message-type 99% DMARC pass-rate floor over a rolling 90-day window) that the transactional stream is the easiest- to-achieve baseline for. Read the transactional-email spoke when an operator arrives with a PER-MESSAGE-TYPE deployment question that the glossary's single-sentence definitions cannot embed: the spoke is the authoritative per-ESP- and-per-stream operational reference for the transactional-email-authentication- provenance domain.
DKIM cryptography basics (RSA / Ed25519 / 2048-bit / public-key signing) — the per-concept cryptographic-foundations deep dive — the authoritative per-concept cryptographic-foundations reference underpinning the DKIM-related single- sentence vocabulary entries in this glossary. Where this glossary catalogues "RSA" / "Ed25519" / "key size" / "public-key cryptography" / "private key" / "hash algorithm" / "canonicalization" / "DKIM-Signature" / "selector" / "v=DKIM1" / "p= public key tag" each as an individual single- sentence vocabulary entry, the DKIM- cryptography-basics spoke is the authoritative per-concept procedural reference for the FULL cryptographic foundations underpinning DKIM signing and verification: WHY RSA-2048 is the defensible-floor key size (RSA-1024 is factorable within commercial-cloud- compute budget; RSA-2048 NIST SP 800-57 Part 1 Rev 5 §5.6.2 transition-to-2030 defensible-floor; RSA-3072 NIST 2031- 2050 transition-target; RSA-4096 defense-in-depth ceiling), WHY Ed25519 is the emerging-alternative algorithm (RFC 8032 EdDSA / RFC 8463 DKIM- Ed25519-SHA256 algorithm tag / deterministic-signature property / constant-time-implementation property / smaller-key-and-signature-size property / receiver-compatibility-floor caveat), HOW the DKIM-Signature header b= base64- encoded RSA / Ed25519 signature blob encodes the verifier's cryptographic proof of publisher identity (publisher publishes p= public-key as a TXT record at <selector>._domainkey.<domain> / receiver retrieves p= public-key via DNS at verification time / receiver computes signature over canonicalized headers + body / receiver compares computed signature against b= signature blob / verification result emitted as Authentication-Results header), HOW the bh= body-hash tag binds the message body to the signature (receiver computes SHA-256 over canonicalized body / receiver compares computed body-hash against bh= body-hash / body-hash mismatch indicates body modification between publisher and receiver), HOW the h= header-list tag binds the signed headers to the signature (publisher specifies which headers are included in the signature input / omitted headers are unsigned and can be modified without invalidating the signature / RFC 6376 REQUIRES From: / SHOULD include Subject / Date / To / Message-ID / common-list: From / Subject / Date / To / Cc / Message-ID / MIME-Version / Content-Type / Content-Transfer-Encoding), HOW the a= algorithm tag binds the signature algorithm to the signature (rsa-sha256 as RFC 8301 mandatory floor / rsa-sha1 deprecated by RFC 8301 / ed25519-sha256 as RFC 8463 emerging-alternative / receivers SHOULD reject rsa-sha1 / per- receiver-vendor variance in rsa-sha1 rejection posture), HOW selector rotation (RFC 6376 §6.1 selector recommendation / quarterly rotation cadence / publisher publishes new selector TXT record before transitioning signing infrastructure / publisher retains old selector for validation-window grace period / publisher deletes old selector after validation-window expires) bounds the compromised-key attack window, and HOW publisher-private-key storage discipline (HSM-backed signing infrastructure / per-customer key isolation in SaaS- platform multi-tenancy / no-export attribute on cloud-KMS-backed signing keys / no-checkout-to-developer-laptop discipline / no-shared-key-across-tenant posture in shared-hosting platforms) provides the publisher-distinguisher property that SPF cannot provide. The DKIM-cryptography-basics spoke is especially valuable as a navigation target for glossary readers because the glossary's single-sentence entries for "RSA" / "Ed25519" / "public key" / "private key" / "hash algorithm" / "canonicalization" / "DKIM-Signature" collapse the concepts to one-sentence definitions that leave the procedural questions ("WHY RSA-2048 not RSA-1024 or RSA-4096?" / "WHEN should I migrate to Ed25519?" / "WHAT is the relationship between bh= and the b= signature blob?" / "WHICH headers should I sign in the h= list?" / "HOW often should I rotate selectors?" / "WHERE should I store the private key?") unanswered — the spoke documents the full per-concept cryptographic-foundations framework with cryptographic-primitive-by-primitive defensible postures, receiver-vendor- compatibility floors, and operator- empowerment ceilings.
SPF 10-DNS-lookup limit and SPF flattening — the GLOSSARY-VOCABULARY-RESOLVES-TO- SPF-10-DNS-LOOKUP-BUDGET-AND-PERMERROR- AND-FLATTENING-OPERATIONAL-DISCIPLINE companion to this email-authentication glossary. Where THIS glossary catalogues the canonical vocabulary used across the SPF / DKIM / DMARC / ARC / BIMI / MTA-STS / TLS-RPT ecosystem in term-by-term dictionary form, the SPF-lookup-limit spoke is the per-publisher-RFC-7208-§4.6.4- ten-DNS-query-budget operational reference whose four GLOSSARY-VOCABULARY-RESOLUTION dimensions map every lookup-budget-related term on THIS glossary down to the executable SPF-evaluation algorithm and the four-class remediation catalogue every publisher operating an include:-heavy SPF record eventually consumes: (i) per-term "permerror" / "void lookup" / "lookup budget" vocabulary resolution — the glossary entries for SPF result codes, the RFC 7208 §4.6.4 ten-lookup cap, and the §4.6.4 void-lookup secondary cap (two void DNS queries hard-fail the SPF evaluation regardless of cap headroom) all resolve to the SPF-lookup-limit spoke's per-publisher per-record budget accounting and the canonical spf=permerror symptom cascade into dmarc=fail at every DMARC-honouring receiver; (ii) per-term "include cascade" / "recursive resolution" / "redirect= " vocabulary resolution — the glossary entries for the per-mechanism DNS-query cost (include / a / mx / ptr / exists / redirect= each consume 1 lookup; ip4 / ip6 / all cost zero) and the recursive include-expansion algorithm (a top-level include: whose body contains nested include: chains accumulates lookups multiplicatively) all resolve to the SPF-lookup-limit spoke's per-include- per-ESP lookup-cost reference table (Google Workspace / Microsoft 365 / SendGrid / Mailgun / Amazon SES / Salesforce / Mailchimp / Postmark / Klaviyo / HubSpot / Constant Contact) every publisher consults before stacking a fourth or fifth ESP onto the per-domain SPF record; (iii) per-term "flattening" / "subdomain delegation" / "sender consolidation" vocabulary resolution — the glossary entries for the four canonical remediation paths (flattening: a recurring cron job that resolves every include / a / mx down to ip4 / ip6 and republishes the flattened record; subdomain delegation: hosting one ESP on a per-subdomain SPF record to split the budget; sender consolidation: retiring redundant ESPs to a single relay; macro tricks: using exists: with per-source-IP macro substitution to cost zero additional lookups) all resolve to the SPF-lookup-limit spoke's per-remediation operational-trade-off catalogue documenting which class to deploy at which scale-of-organisation; and (iv) per-term "DNS amplification" / "DoS-mitigation rationale" / "per-receiver-NDR variation" vocabulary resolution — the glossary entries for the historical DoS-amplification rationale that produced the §4.6.4 cap (SPF evaluation with arbitrarily-deep include chains could be weaponised into a DNS-amplification DoS vector against arbitrary third-party DNS servers) and the per-receiver NDR diagnostic variation (Google: "550 5.7.26 ... too many DNS lookups"; Microsoft: "550 5.7.1 ... SPF permerror"; Amazon SES: "550 ... SPF result is none/permerror") all resolve to the SPF-lookup-limit spoke's per-publisher per-record publication-discipline catalogue that prevents the SPF-publication topology from triggering the §4.6.4 hard cap in production. Read the SPF-lookup- limit spoke alongside this glossary whenever an operator searches for "SPF too many DNS lookups", "SPF permerror", "SPF 10 lookup limit", "SPF flatten", or "SPF lookup limit fix" — the glossary anchors the terminology and the lookup-limit spoke is the executable operational reference every publisher consults to diagnose, remediate, and audit the per-domain SPF-publication budget the canonical vocabulary describes.
DMARC troubleshooting — the GLOSSARY-VOCABULARY-RESOLVES-TO- OPERATOR-FACING-DIAGNOSTIC-LADDER companion to this email-authentication protocol- vocabulary glossary. Where THIS page defines every per-protocol vocabulary term in single-sentence form (RFC 7489 DMARC tags, RFC 6376 DKIM canonicalization / selectors / signed-header-list, RFC 7208 SPF mechanisms / qualifiers / 10-lookup limit, RFC 8617 ARC chain validation / AS / AMS / AAR, RFC 8461 MTA-STS modes, RFC 8460 TLS-RPT JSON schema, identifier alignment, organizational domain, PSL, envelope MAIL FROM, AUID), the dmarc- troubleshooting spoke is the OPERATOR-FACING DIAGNOSTIC LADDER reference whose Pattern-1- through-Pattern-4 root-cause investigation ladders bottom out on the protocol-vocabulary entries THIS glossary catalogues. Pattern 1 (SPF-aligned-pass-regression) bottoms out on the SPF-record-publication-discipline failure- class vocabulary entries (SPF permerror, SPF temperror, SPF 10-lookup overflow, SPF forwarder break, envelope MAIL FROM rewrite), Pattern 2 (forwarder-hop-alignment-loss) bottoms out on the envelope-MAIL-FROM-rewrite + SRS + ARC vocabulary entries (RFC 5321 envelope, ARC chain validation, AS / AMS / AAR header preservation), Pattern 3 (DKIM- alignment-pass-failure) bottoms out on the DKIM canonicalization + selector + signed- header-list + body-hash vocabulary entries (RFC 6376 §3.4 canonicalization, RFC 6376 §3.5 b= / bh= / h= / d= / s= tag-anatomy), and Pattern 4 (per-source-IP-cohort-attribution) bottoms out on the source-IP + DNS-PTR + organizational-domain vocabulary entries (RFC 5321 connecting IP, reverse-DNS PTR lookup, PSL-based organizational-domain computation). Read the troubleshooting spoke AFTER this glossary when a per-operator per-domain DMARC-aligned-pass-rate regression emerges in the per-receiver per-source-IP rua aggregate-XML stream — THIS glossary gives the vocabulary, the troubleshooting spoke gives the four ordered diagnostic ladders that walk the operator from the observed regression to the protocol-vocabulary root cause in this glossary. The glossary + troubleshooting pair is the canonical vocabulary-to-diagnostic-ladder coupling every per-publisher per-domain DMARC operator consults when the rua aggregate-XML stream surfaces an unexpected disposition shift.
DKIM key rotation — the GLOSSARY-VOCABULARY-RESOLVES-TO-PER- PUBLISHER-PER-SELECTOR-KEY-ROTATION- OPERATIONAL-DISCIPLINE-CANONICAL-REFERENCE companion to this email-authentication glossary (29th glossary-as-universal-source use). Where THIS glossary defines the per- publisher per-domain DKIM selector + d=-tag + p=-tag + s=-tag + t=-tag + x=-tag + k=-tag per-message DKIM-Signature header vocabulary primitive, the DKIM-key-rotation spoke is the OPERATIONAL DISCIPLINE that consumes that vocabulary as the per-publisher per- selector key-rotation cadence + overlap- window + cryptographic-strength-upgrade publication-discipline-vocabulary every per-publisher per-message DKIM-pass verdict- rate stability KPI gates on at four DKIM-key-rotation-vocabulary coupling dimensions: (i) per-publisher per- selector namespace lifecycle vocabulary primitive — the per-selector namespace (selector1 → selector2 → selector3 per the M365 pattern; google → google2 → google3 per the Workspace pattern; arbitrary per- publisher per-rotation epoch labels per the cPanel/Exim pattern) the per-publisher per- rotation cutover discipline publishes per- rotation is the load-bearing per-publisher per-receiver-DNS-cache-TTL-bounded zero- downtime overlap vocabulary primitive every per-publisher per-rotation operations team consumes; (ii) per-publisher per- selector private-key custody-discipline vocabulary primitive — the per- publisher per-selector private-key custody + per-rotation key-generation-environment- hygiene + per-rotation private-key-disposal discipline vocabulary every per-publisher per-rotation operations team consumes; (iii) per-publisher per-rotation cryptographic-strength-upgrade discipline vocabulary primitive — the per- publisher per-rotation 1024-bit-to-2048- bit RSA upgrade per RFC 8301 + optional Ed25519 per RFC 8463 discipline vocabulary every per-publisher per-rotation cryptographic-foundation upgrade operations team consumes; (iv) per- publisher per-rotation TTL-bounded overlap- window publication-discipline vocabulary primitive — the per-publisher per- selector overlap-window-duration-must- exceed-receiver-side-DNS-cache-TTL discipline vocabulary every per-publisher per-rotation operations team consumes at the per-rotation cutover-boundary to prevent stale-public-key-cache-during- rotation-cutover dkim=fail / dkim=permerror verdict regression. Read the DKIM-key-rotation spoke ALONGSIDE this email-authentication glossary whenever a per-publisher per- domain DKIM-pass verdict-rate regression post-key-rotation emerges in the per- receiver per-source-IP rua aggregate-XML stream — THIS glossary gives the per- publisher per-selector vocabulary, the DKIM-key-rotation spoke gives the operational-discipline reference the per- publisher per-rotation cutover ladder bottoms out on at the per-publisher per- selector key-rotation publication- discipline boundary.
Email Header Analyzer — paste any email's headers and see SPF, DKIM, DMARC, and ARC results applied to a real message.
Domain Security Checker — live DNS lookups for every email-authentication record on a domain.
DNS Record Generator — SPF / DKIM / DMARC / TLS-RPT / MTA-STS / CAA / BIMI record wizards.
DMARC Analyzer Dashboard — ingests aggregate (RUA) and forensic (RUF) reports via includes/DmarcParser.php and includes/ForensicReportParser.php, evaluates DNS records via includes/DnsChecker.php, and parses raw email headers via includes/EmailHeaderParser.php.
RFC 7489 — DMARC
RFC 7208 — SPF
RFC 6376 — DKIM
RFC 8617 — ARC
RFC 5321 — SMTP (envelope)
RFC 5322 — Internet Message Format (headers)
Public Suffix List — the canonical PSL referenced by DMARC for organizational-domain computation.
Microsoft SNDS + JMRP monitoring — the operational guide behind the SNDS, JMRP, ARF, and complaint-rate entries: what Microsoft's consumer network exposes per sending IP and how to monitor it via the Automated Data Access key with its silent 30-day expiry.

Apply the glossary to your domain

Every term in this glossary maps to a concrete artifact in DMARC Analyzer. Use the dashboard to ingest your aggregate reports, the Email Header Analyzer to walk through SPF + DKIM + DMARC + ARC results on a real message, and the Domain Security Checker to verify your DNS records.