DMARC Analyzer

TL;DR

• Email authentication is the set of DNS-published, cryptographically- anchored, RFC-defined mechanisms that let a receiving mail server verify a message claiming to be from a given domain was actually authorised to be sent.
• The three core standards: SPF (RFC 7208, IP authorisation), DKIM (RFC 6376, cryptographic signing), and DMARC (RFC 7489, policy + alignment + reporting).
• The four auxiliary standards: BIMI (logo display, draft), MTA-STS (RFC 8461, transport hardening), TLS-RPT (RFC 8460, transport reporting), and CAA (RFC 8659, cert-issuance authorisation).
• ARC (RFC 8617, Authenticated Received Chain) preserves authentication results across forwarding hops where SPF would otherwise break.
• The SPF / DKIM / DMARC trio depends on the distinction between the SMTP envelope MAIL FROM (RFC 5321) and the visible From: header (RFC 5322). SPF evaluates the envelope; DKIM signs the header; DMARC demands at least one aligns with the visible From:.
• The canonical deployment sequence: SPF first, DKIM second, DMARC p=none third (reporting only), report-driven alignment fix-up over 2-6 weeks, DMARC enforcement, then layer MTA-STS / TLS-RPT / BIMI / CAA. Never skip from p=none to p=reject.
• Every standard is a TXT record at a well-known DNS location: SPF at the apex, DKIM at selector._domainkey, DMARC at _dmarc, BIMI at default._bimi, MTA-STS at _mta-sts, TLS-RPT at _smtp._tls, CAA at the apex with a special record type (RR 257).
• DMARC Analyzer ingests DMARC aggregate (RUA) and forensic (RUF) reports via includes/DmarcParser.php and includes/ForensicReportParser.php, renders per-sender / per-IP / per-day authentication breakdowns, and performs live DNS verification for every standard above through includes/DnsChecker.php.

1. What is email authentication?

Email authentication is the set of DNS-published, cryptographically-anchored, RFC-defined mechanisms that let a receiving mail server verify that an inbound message claiming to be from a given domain was actually authorised to be sent from the IP it arrived from, signed by the domain it claims, and aligned with the visible From: header the recipient sees. None of the underlying SMTP protocol mechanics (RFC 5321) authenticate the sender — SMTP was designed in 1982 as a trust- by-default mesh of cooperating mail servers, with no built-in mechanism to verify that a server claiming to deliver bank.example's mail is in fact authorised to do so. Email authentication is the layer that closes that gap decades after the fact.

The seven standards in the ecosystem split cleanly into three core (the authentication trio that every domain publishing mail needs), three auxiliary (transport hardening and consumer-facing brand display), and one intermediate (ARC, the standard that preserves authentication results across forwarding hops):

• SPF (RFC 7208) — IP-level authorisation. Publishes which IPs are allowed to send mail on behalf of a domain.
• DKIM (RFC 6376) — message-level cryptographic signing. Receiver verifies the signature against a published public key.
• DMARC (RFC 7489) — policy + alignment + reporting. Demands that at least one of SPF or DKIM passes AND aligns with the From: header, and tells the receiver what to do when it does not.
• BIMI (draft-brand-indicators-for-message-identification) — consumer-facing brand display. Renders the sender's logo in supporting mail clients once DMARC enforcement is in place.
• MTA-STS (RFC 8461) — transport encryption hardening. Demands receivers use STARTTLS with valid certificate validation when delivering to this domain.
• TLS-RPT (RFC 8460) — transport-layer reporting stream. Receivers send daily reports of every TLS failure they observed.
• CAA (RFC 8659) — certificate-issuance authorisation. Constrains which certificate authorities may issue certificates for the domain.
• ARC (RFC 8617) — Authenticated Received Chain. Preserves the original SPF/DKIM/DMARC result across forwarding hops where SPF would otherwise break (e.g. mailing lists, .forward redirects).

Most operator effort goes into the core three. The auxiliary four are layered defences and visibility streams that pay off once the core three are in enforcement.

2. Why email authentication exists: the threat model

Three categories of attack drive the entire ecosystem:

• Domain spoofing — an attacker sends a message with a forged From: ceo@your-company.example header from arbitrary IP infrastructure they control. Without email authentication, the recipient mailbox displays the spoofed From: name and the message looks indistinguishable from legitimate internal mail. DMARC + SPF + DKIM together close this attack: SPF rejects the attacker's IP, DKIM rejects the missing or invalid signature, DMARC binds those results to the visible From: domain.
• Phishing — a spoofed message tricks the recipient into clicking a link, entering credentials, or downloading malware. Phishing relies on sender impersonation to bypass the recipient's social trust filters. Email authentication does not eliminate phishing (lookalike domains and compromised legitimate accounts remain), but it eliminates the cheapest variant — direct domain impersonation.
• Business Email Compromise (BEC) — the highest-value attack variant, where an attacker impersonates an executive to trick finance staff into wiring funds or releasing data. The FBI IC3 consistently reports BEC as one of the most expensive single attack categories. DMARC at p=reject on every sending domain in an organisation is the primary defence against the direct-spoof variant of BEC.

Two further problem categories drive the auxiliary standards:

• Transport downgrade attacks — a man-in-the-middle strips STARTTLS from the SMTP session, causing the message to deliver over plaintext where the attacker can read or modify content. MTA-STS + TLS-RPT close this: MTA-STS demands the receiver use STARTTLS with valid certificate validation, TLS-RPT delivers daily reports listing every failure.
• Certificate misissuance — a compromised or careless certificate authority issues a TLS certificate for a domain to a party not authorised by the domain owner. The misissued certificate could be used in a transport-layer MITM or a phishing page. CAA constrains which CAs may issue certs for the domain, limiting the blast radius of any single compromised CA.

3. The SMTP envelope plumbing: MAIL FROM vs From: header

The single concept that makes email authentication possible — and the single source of operator confusion — is the distinction between the SMTP envelope MAIL FROM (RFC 5321 Reverse-Path) and the visible From: header (RFC 5322). They live at different layers of the protocol stack and different standards anchor against each.

A typical SMTP conversation:

S: 220 mx.recipient.example ESMTP
C: EHLO mail.sender.example
S: 250 OK
C: MAIL FROM:<bounces@sender.example>     ← envelope sender (RFC 5321)
S: 250 OK
C: RCPT TO:<user@recipient.example>       ← envelope recipient
S: 250 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "CEO" <ceo@your-company.example>  ← visible From: header (RFC 5322)
C: To: user@recipient.example
C: Subject: ...
C: ... message body ...
C: .
S: 250 OK

Note the two distinct sender domains:

• bounces@sender.example is the envelope MAIL FROM. The receiver uses this address for bounce delivery (RFC 5321 §3.7). SPF evaluates this domain — it asks "is the connecting IP authorised by sender.example's SPF record?".
• ceo@your-company.example is the visible From: header. The recipient sees this in their inbox. DMARC alignment evaluates this domain — it asks "does the SPF-passing or DKIM-signing domain match this header?".

Without identifier alignment, an attacker could publish an SPF record at their own attacker.example domain, set MAIL FROM to bounces@attacker.example (SPF passes), and use any From: header they want — including ceo@your-company.example. Alignment is the mechanism that bridges the envelope-vs-header gap: DMARC demands the SPF or DKIM domain match the From: domain (strict or relaxed), eliminating the spoof.

Three further headers matter for authentication debugging:

• Authentication-Results: (RFC 8601) — the receiver's per-message verdict, added on inbound delivery. Lists each check (spf, dkim, dmarc) with pass / fail / none and the domain evaluated. The canonical debugging artefact.
• DKIM-Signature: (RFC 6376) — present on every signed message, carries the signature, selector, signing domain (d=), and signed-header list.
• ARC-*: — three header fields (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) added by a forwarding hop to preserve the original authentication result; see RFC 8617.

4. The seven standards at a glance

The keystone reference for this page. Every standard mapped to its RFC, the layer it operates at, and the DNS anchor where it publishes.

5. How the standards interlock: layered defence-in-depth

The seven standards form a layered model where each layer addresses one specific failure mode and the layers compose to close the full attack surface:

1. SPF closes the arbitrary-IP-spoof: an attacker cannot send from an IP not listed in the sender's SPF record (modulo forwarding edge cases, which is why DKIM exists).
2. DKIM closes the in-transit-tampering and forwarding-survives gaps: the signature binds the message body and signed headers to the domain's public key regardless of which IP delivered the message.
3. DMARC closes the alignment gap: SPF or DKIM passing on a domain the recipient never sees (e.g. envelope MAIL FROM at a SaaS provider's domain) is not enough — DMARC demands the passing identifier aligns with the visible From: header.
4. ARC closes the forwarder-breaks-SPF gap: a mailing list or .forward redirect that modifies headers can preserve the original DMARC verdict for the downstream receiver to honour.
5. MTA-STS closes the transport-downgrade gap: receivers cannot fall back to plaintext SMTP when the policy is in enforce mode.
6. TLS-RPT closes the silent-transport-failure gap: operators learn about TLS failures via daily reports rather than discovering them weeks later when mail is missing.
7. BIMI closes the recipient-cannot-tell-if-authenticated gap (partially): supporting clients display a sender logo that visually confirms the message passed DMARC.
8. CAA closes the CA-misissuance gap: only the named CAs may issue certs for the domain, constraining the blast radius of any single compromised CA.

The model is defence-in-depth: removing any one layer weakens the overall posture, but no single layer is sufficient on its own. SPF without DMARC is bypassable by header spoofing; DMARC without SPF or DKIM has nothing to align; MTA-STS without TLS-RPT silently fails when receivers cannot fetch the policy file. Deploy the full stack.

6. The canonical deployment sequence

Decades of operator experience have converged on a single recommended sequence. Following it eliminates almost every self-inflicted email- outage class:

1. Phase 1 — Publish SPF. Inventory every legitimate sending source (mail server, SaaS provider, marketing platform). Publish a TXT record at the domain apex: v=spf1 include:_spf.google.com -all (example). Use -all (hard fail), not ~all (soft fail) — the soft-fail option exists only for rollout testing. Keep the record under the 10-lookup limit; flatten if needed.
2. Phase 2 — Publish DKIM. Enable signing in every sending platform. Each platform generates a key pair and gives you a public key to publish at <selector>._domainkey.<domain>. Use RSA-2048 minimum (RFC 8301); avoid RSA-1024 which is cryptographically weak. Plan key rotation in advance — most platforms support dual-publication so the new key warms up before the old one is retired.
3. Phase 3 — Publish DMARC at p=none. Add a TXT record at _dmarc.<domain>: v=DMARC1; p=none; rua=mailto:dmarc-reports@<domain>. p=none tells receivers "do not change disposition based on DMARC, but send me daily aggregate reports". This is the zero-risk reporting-only phase.
4. Phase 4 — Alignment fix-up. Read the aggregate reports for 2-6 weeks. Every legitimate sender should appear with SPF or DKIM (preferably both) passing AND aligned with the From: header. Misaligned senders need fixing: SaaS providers typically support either a DKIM delegation (you publish a CNAME at <selector>._domainkey.<domain> pointing at their key) or a custom MAIL FROM domain (so SPF aligns).
5. Phase 5 — Advance to p=quarantine. Once every legitimate sender is aligned, change the DMARC record to p=quarantine. Receivers will deliver DMARC-failing mail to spam. Continue monitoring reports for unexpected failures.
6. Phase 6 — Advance to p=reject. After 1-3 months at p=quarantine without unexpected failures, change to p=reject. DMARC-failing mail is now bounced at the SMTP boundary. Spoofing on this domain is no longer possible against receivers that honour DMARC.
7. Phase 7 — Publish MTA-STS + TLS-RPT. Add the MTA-STS DNS record (v=STSv1; id=...), publish the HTTPS policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt in testing mode, deploy TLS-RPT (v=TLSRPTv1; rua=mailto:...), wait for clean TLS-RPT reports, then advance MTA-STS to enforce mode.
8. Phase 8 — Publish BIMI (optional, brand-protection-conscious senders). Requires DMARC at p=quarantine or p=reject and an SVG Tiny PS logo. Yahoo / Gmail / Apple Mail require a VMC (Verified Mark Certificate) from DigiCert or Entrust.
9. Phase 9 — Publish CAA (security hardening). List the specific CAs authorised to issue certs for the domain (0 issue "letsencrypt.org") plus an iodef contact for misissuance alerts.

Never skip from p=none to p=reject — this is the single most common self-inflicted email-outage cause in DMARC rollouts. The p=quarantine intermediate phase exists specifically to give operators a recoverable middle state where failed mail goes to spam rather than bouncing.

7. Operator decision tree

Where to start, depending on the current state of the domain:

• No SPF, no DKIM, no DMARC → start with the SPF pillar. Get SPF right before adding any other record. SPF alone is sufficient to stop the lowest-effort spoofing class.
• SPF in place, no DKIM → publish DKIM next. See the DKIM pillar. Most sending platforms have one-click DKIM key generation; the only work is publishing the resulting public key in DNS.
• SPF + DKIM in place, no DMARC → publish DMARC at p=none with rua=mailto:.... See the DMARC rollout deep dive. The reports flowing in over the next 2-6 weeks tell you exactly which senders are misaligned.
• DMARC at p=none with reports flowing → use the DMARC aggregate reports deep dive to read the data, then follow the alignment deep dive to fix every misaligned sender. Advance through p=quarantine to p=reject per the rollout spoke.
• DMARC at enforcement (p=quarantine or p=reject) → layer MTA-STS and TLS-RPT for transport hardening, then BIMI for brand display.
• Full stack deployed → layer CAA records to constrain certificate- issuance authorisation. Keep monitoring DMARC aggregate reports indefinitely — new senders are discovered as the organisation grows.

8. Ten best practices

1. Inventory every sender before publishing any record. Marketing platforms, CRM systems, transactional relays, partner integrations, and shadow IT all need to appear in your SPF or DKIM config.
2. Always use SPF -all, not ~all, in production. The soft-fail option exists for testing. Receivers honour -all consistently; ~all is largely ignored.
3. Use RSA-2048 minimum DKIM keys (RFC 8301). RSA-1024 was deprecated in 2018; ed25519 (RFC 8463) is acceptable where the sending platform and receivers both support it.
4. Stage rollouts: SPF first, DKIM second, DMARC third. Never publish DMARC before SPF and DKIM are verified working — DMARC at p=reject on a domain without SPF or DKIM is self-inflicted email suicide.
5. Always start DMARC at p=none — the reporting-only phase. Even if you believe every sender is aligned, the daily reports almost always surface unknown senders the operator did not know existed.
6. Pre-DMARC rollout: audit subdomains. Use sp= and np= (RFC 9091) to control subdomain policy independently. Unused subdomains should publish their own p=reject DMARC record to prevent abuse.
7. Deploy MTA-STS in testing mode first. Wait for clean TLS-RPT reports before advancing to enforce. Enforce-mode MTA-STS with a broken policy file blocks all inbound mail from MTA-STS-aware senders.
8. Pin a stable DKIM selector rotation schedule — at least every 12 months for high-value domains, every 6 months for industries with regulatory pressure. Document the rotation procedure so on-call staff can rotate under pressure.
9. Monitor DMARC aggregate reports indefinitely. The reports are the only visibility you have into who is sending mail claiming your domain. DMARC Analyzer surfaces per-sender trends; alert on new senders appearing.
10. Document the full stack — every TXT record, every selector, every CA on the CAA record. Future on-call staff need to debug under pressure without rediscovering the config from scratch.

9. Ten common mistakes

1. Jumping from p=none to p=reject without the p=quarantine intermediate phase. The single most common self- inflicted email outage. p=quarantine sends failures to spam (recoverable); p=reject bounces them at the SMTP boundary (unrecoverable).
2. Multiple SPF records on the same domain. RFC 7208 §3.2 mandates a single record; multiple records cause a permerror. Merge into one record using include: directives.
3. Exceeding the SPF 10-lookup limit. Every include:, a:, mx:, exists:, redirect= counts as a DNS lookup. Over 10 → SPF permerror. Flatten or remove unused providers.
4. DKIM signing with RSA-1024. Deprecated since RFC 8301 (2018). Modern receivers downgrade the result or refuse to verify entirely.
5. DMARC rua= mailbox on the same domain the DMARC protects, with no cross-domain authorisation. Receivers cannot deliver reports to a mailbox that fails DMARC. Use a different domain or publish a cross-domain authorisation record per RFC 7489 §7.1.
6. SPF +all (allow any IP). This makes the record meaningless and actively harmful — receivers treat the domain as never having published SPF.
7. Publishing BIMI before DMARC is at enforcement. BIMI requires DMARC at p=quarantine or p=reject; supporting clients will not render the logo otherwise. BIMI is the reward for completing the DMARC rollout, not a parallel project.
8. MTA-STS in enforce mode with a wildcard mismatch. The policy file's mx: entries must match the domain's MX records. A renamed MX without an MTA-STS update silently breaks inbound from MTA-STS-aware senders.
9. CAA records without iodef=. The iodef tag tells CAs where to send misissuance reports. Without it, a misissuance event goes undetected until the cert is used.
10. Treating DMARC reports as one-time work. New senders appear constantly (a new SaaS deployment, a new partner integration, a new marketing platform). Indefinite monitoring is the ongoing cost of DMARC enforcement.

10. Troubleshooting

• "My message is being marked as spam despite DMARC pass". DMARC pass does not guarantee inbox delivery — receiver-side reputation systems (Gmail Postmaster, Microsoft SNDS) weigh content signals, sender reputation, recipient engagement, and many other factors. Use Gmail Postmaster Tools and Microsoft SNDS for the full picture.
• "DMARC reports show SPF pass + DKIM pass but DMARC fail". This is an alignment failure. The SPF envelope-domain or the DKIM signing domain does not match the From: header domain. See the alignment deep dive for the SaaS-sender root- cause walkthrough.
• "My SPF record is failing with permerror". Most likely cause: the 10-lookup limit. Run domain security checker or use the SPF pillar's flattening guidance.
• "DKIM signature fails on some receivers". Usually a canonicalization mismatch or a header modification by an intermediate relay. Use email header analyzer to inspect the signature against the actual headers.
• "No DMARC reports arriving". See the aggregate reports deep dive Q5 — most common causes: the rua mailbox itself fails DMARC, the records have not propagated (TTL + 24h), or the mailbox spam filter is flagging them.
• "MTA-STS reports show TLS failures". The TLS-RPT deep dive documents every result-type and the remediation for each.
• "Where do I start debugging?" Three tools complement each other: (1) DMARC reports for production reality, (2) email header analyzer for individual message diagnosis, (3) domain security checker for live DNS validation.

11. Frequently asked questions

What is email authentication?

Email authentication is the set of DNS- published, cryptographically-anchored, RFC-defined mechanisms that let a receiving mail server verify a message claiming to be from a given domain was actually authorised to be sent. The three core standards are SPF (RFC 7208, IP authorisation), DKIM (RFC 6376, cryptographic signing), and DMARC (RFC 7489, policy + alignment + reporting). Auxiliary standards (BIMI, MTA-STS, TLS-RPT, CAA) layer additional defences and reporting streams.

Why do SPF, DKIM, and DMARC all exist if they overlap?

They are complementary, not redundant. SPF authorises specific IPs, DKIM cryptographically signs the message body, and DMARC ties them together by demanding at least one passes AND aligns with the visible From: header — and tells the receiver what to do if not. SPF alone breaks under forwarding; DKIM alone says nothing about envelope IP authorisation; DMARC alone needs SPF and DKIM to evaluate.

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

SPF (RFC 7208) is a TXT record listing which IPs may send for the domain — it evaluates the SMTP envelope MAIL FROM. DKIM (RFC 6376) is a public key plus a DKIM-Signature header — it cryptographically verifies the From: header was not tampered with. DMARC (RFC 7489) is a TXT record at _dmarc publishing a policy and report destinations — it instructs the receiver what to do when SPF and DKIM both fail or fail to align with the visible From:.

In what order should I deploy email authentication?

SPF first, DKIM second, DMARC at p=none third (reporting only), 2-6 weeks of report-driven alignment fix-up, DMARC at p=quarantine, DMARC at p=reject, then layer MTA-STS + TLS-RPT for transport hardening, BIMI for brand display, and CAA for certificate-issuance constraint. Never skip from p=none to p=reject.

What is the difference between the envelope MAIL FROM and the visible From: header?

The envelope MAIL FROM (RFC 5321 Reverse-Path) is exchanged between mail servers during the SMTP session — SPF evaluates this. The visible From: header (RFC 5322) lives inside the message body — the recipient sees it in their client, and DMARC alignment anchors against it. The two domains can legitimately differ (a SaaS sender's MAIL FROM domain vs the customer's From: domain).

Do I need MTA-STS and TLS-RPT if I already have DMARC?

Yes — they solve different problems. DMARC authenticates the sender (stops From: impersonation). MTA-STS and TLS-RPT harden the transport (stop STARTTLS downgrade attacks). A domain at DMARC p=reject without MTA-STS still leaks content over plaintext SMTP when receivers fall back to unencrypted delivery.

What is the role of BIMI in email authentication?

BIMI is the consumer-facing payoff of a successful DMARC deployment. Once DMARC is at enforcement (p=quarantine or p=reject), publishing a BIMI record pointing at an SVG Tiny PS logo causes supporting mailbox providers (Gmail, Yahoo, Apple Mail, Fastmail) to render the logo next to the sender name in the inbox.

How do I know if my email authentication is working?

Four complementary checks: (1) DMARC aggregate reports — daily XML descriptions of every authentication outcome (DMARC Analyzer's includes/DmarcParser.php ingests these), (2) email header analysis — paste raw headers into the header analyzer for per-message diagnosis, (3) live DNS verification — domain security checker validates every record, (4) external reference services (mail-tester.com etc.). Use all four.

12. Related guides

• DMARC explained — the DMARC primer covering the broader DMARC ecosystem, mailing-list / forwarding interactions, and cluster context.
• SPF explained — Sender Policy Framework (RFC 7208). The IP-authorisation layer; the first record every domain should publish.
• SPF mechanisms explained — the canonical mechanism-vocabulary deep dive covering every one of the eight RFC 7208 mechanisms (a, mx, ptr, ip4, ip6, exists, include, all), the four qualifiers (+, -, ~, ?), and the two modifiers (redirect=, exp=) defined in RFC 7208 sections 5 and 6. Per-mechanism Definition / Syntax / Lookup-cost / Use-case / Pitfalls quintuple, the left-to-right first-match-wins evaluation order, a cumulative lookup-cost accounting worksheet, worked deployment examples for the canonical operator profiles, and the seven most common mechanism-level pitfalls. The companion reference operators reach for when they need to decide between include:, ip4:, a, and mx, or when they need to explain why ptr is deprecated, or when they need to know exactly what -all vs ~all vs ?all vs +all means.
• include vs ip4 vs a vs mx — the focused 4-way decision-view companion to the comprehensive mechanism reference above. For operators answering "which mechanism should I use" when authoring or modifying an SPF record: include for managed providers (Microsoft 365, Google Workspace, Mailchimp, SendGrid), ip4 for static IPs you own (zero DNS-lookup cost), a for self-hosted servers identified by an A record, and mx for the historical "outbound also serves as MX" pattern. Side-by-side comparison table (per-mechanism §, lookup cost, auto-tracks provider changes, canonical use case), a five-question decision matrix, three worked deployment examples, and the seven most common mechanism-choice mistakes (mx for cloud mail, hardcoded cloud IPs, stale includes, bare a on a web-server apex, 10-lookup cap overruns, ip4:0.0.0.0/0, missing IPv6).
• SPF qualifiers explained — focused per-qualifier dimensional analysis complementing the mechanism reference above. For operators answering "should I use -all or ~all", "is +all dangerous", or "what does spf=softfail mean": the four RFC 7208 §4.6.2 qualifiers (+ Pass, - Fail, ~ SoftFail, ? Neutral) each with Definition / Syntax / Receiver behaviour / When to use / When NOT to use / Common pitfalls, a side-by-side comparison table, a receiver-side interpretation matrix (Gmail / Microsoft 365 / Yahoo / Apple iCloud), four worked deployment examples (production -all, deployment ~all with DMARC rua, null-sender v=spf1 -all, per-mechanism SoftFail vendor deprecation), and the canonical ~all → -all enforcement-ramp playbook.
• SPF DNS record syntax explained — focused DNS-record-level SYNTAX reference (RFC 7208 §3). Covers the mandatory v=spf1 prefix, the TXT record type (no legacy type 99), the 255-octet character-string limit and multi-string concatenation, whitespace and case-sensitivity rules, the "exactly one SPF record per domain" rule, publication at the apex vs subdomain with no inheritance, wildcards, comments (none), six worked syntactic examples, and the seven most common syntax mistakes. Complements the semantic references above with the DNS-encoding-layer view.
• SPF 10 DNS lookup limit and SPF flattening — focused deep dive on the RFC 7208 section 4.6.4 10-DNS-lookup cap that operators routinely overshoot when they add one more SaaS sender. Covers per-mechanism lookup cost, recursive include resolution, the 2-void-lookup secondary cap, a per-provider cost reference (Workspace, M365, SendGrid, Mailgun, SES, Mailchimp, SparkPost, HubSpot, Klaviyo, Constant Contact), the permerror symptom + DMARC-fail cascade, and the four canonical remediation paths (audit, subdomain delegation, sender consolidation, flattening with a monitored pipeline) with macros as a distant fifth.
• SPF permerror vs temperror — diagnostic deep dive — the focused diagnostic reference for the two SPF error result codes ( RFC 7208 section 2.6.7 permerror, RFC 7208 section 2.6.6 temperror) with receiver-side processing rules in sections 6.7 and 6.8. Documents the seven canonical permerror causes (record-not-found, syntax-error, multiple- records, too-many-lookups, void-lookup-cap, recursive-include, deprecated-mechanism), the three canonical temperror causes (DNS timeout, SERVFAIL, transient resolver failure), how DMARC at RFC 7489 section 5.6.2 interprets each, receiver behavior at the major mailbox providers (Gmail, Microsoft 365, Yahoo, Apple, ProtonMail), the Authentication-Results forensic detection workflow per RFC 8601, the cause-specific resolution playbook for all 10 failure modes, and a per-symptom decision matrix. Where the lookup-limit spoke covers the SPECIFIC permerror cause produced by the 10-lookup cap, this page is the FOCUSED diagnostic operators reach for when debugging a live permerror or temperror incident in production.
• Forwarding issues with SPF — the focused operational deep dive on the #1 reason SPF breaks in production. SPF authenticates the FIRST SMTP hop only ( RFC 7208 section 1.1.3) and every forwarding scenario introduces a SECOND SMTP hop that the original senders SPF record cannot authorise. Documents the four canonical forwarding scenarios (transparent SMTP-level forwarding via .forward / /etc/aliases, user-level forwarding via sieve / Outlook rules / Gmail filter forwarding, mailing list expansion via Mailman 3 / Discourse / Google Groups / Sympa / GitLab, third-party forwarding services including iCloud Mail Drop / Hide My Email / SimpleLogin / DuckDuckGo Email Protection / AnonAddy), the Sender Rewriting Scheme (SRS) forwarder-side fix with the SRS0 and SRS1 address formats and Postfix / Exim / Sendmail / Exchange implementations, the Authenticated Received Chain (ARC, RFC 8617) receiver-side answer with the three ARC headers (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) and the major mailbox provider validator + sealer matrix, the mailing-list mitigations (From-header munging, message wrapping, ARC sealing) and per-list-software configuration (Mailman 3 dmarc_moderation_action, Discourse, Google Groups defaults), the detection workflow in DMARC aggregate (RUA) reports and Authentication-Results headers per RFC 8601, the four canonical operational fixes ranked by deployment scope (SRS, ARC, mailing-list configuration, permissive DMARC policy), a 10-row per-symptom troubleshooting decision matrix, and three composite real-world examples. The operational playbook that complements the permerror / temperror diagnostic spoke.
• Why SPF alone is insufficient — the focused EEAT-authority synthesis answering the canonical operator question "Do I need DMARC if I have SPF?". Enumerates ALL SIX structural limitations of SPF, names exactly which limitations DKIM closes (limitations 2 and 3 via cryptographic body signing) and which only DMARC closes (limitations 1, 4, 5, and 6 via alignment, policy advertisement, and aggregate reporting), and presents the SPF + DKIM + DMARC minimum viable posture as the operational answer. Six-month migration playbook, decision matrix mapping eight organisational profiles, and real-world examples.
• SPF for Microsoft 365 (Exchange Online) — focused operator-implementation walkthrough for SPF on Microsoft 365 / Exchange Online tenants. Documents the canonical M365 SPF record (v=spf1 include:spf.protection.outlook.com -all), the spf.protection.outlook.com include chain (flat ip4/ip6 enumeration, single realised lookup), the third-party- sender SPF addition pattern (Mailchimp, SendGrid, Mailgun, Salesforce, Marketo, Amazon SES, Zendesk, HubSpot), hybrid M365 + on-prem Exchange Server SPF for Centralized Mail Transport and Direct-Delivery topologies, the 10-lookup cap of RFC 7208 section 4.6.4 and three canonical mitigations (flattening, relay consolidation, subdomain partitioning), the <tenant>.onmicrosoft.com SPF gotcha producing the "SPF passes but DMARC fails for my custom domain" symptom, a four-step verification workflow, seven common mistakes, a per- symptom troubleshooting decision matrix, and four real-world examples. Sibling to the DMARC-for-Microsoft-365 deployment guide and the SPF cluster spokes.
• SPF for Google Workspace (Gmail) — focused operator-implementation walkthrough for SPF on Google Workspace / Gmail tenants. Documents the canonical Workspace SPF record (v=spf1 include:_spf.google.com -all), the _spf.google.com nested-include chain (three _netblocks{,2,3}.google.com records consuming 4 lookups out of the box), the third-party-sender SPF addition pattern (Mailchimp, SendGrid, Mailgun, Salesforce, HubSpot, Amazon SES, Marketo, Zendesk), the Google Workspace SMTP relay service (smtp-relay.gmail.com) gotcha and its subdomain-SPF fix, the 10-lookup cap of RFC 7208 section 4.6.4 with three canonical mitigations (sender consolidation, subdomain delegation, SPF flattening), a six-surface verification workflow including Google Postmaster Tools, seven common mistakes, a per-symptom troubleshooting decision matrix, four real-world examples, and the Feb 2024 Google bulk sender requirements context (-all mandate for senders over 5000 messages/day to gmail.com). Sibling to the DMARC-for-Google-Workspace deployment guide and the SPF-for-Microsoft-365 sibling spoke.
• DKIM explained — DomainKeys Identified Mail (RFC 6376). The cryptographic-signing layer that survives forwarding.
• DKIM canonicalization explained — the byte-level deep dive on the RFC 6376 §3.4 canonicalization algorithms. The two header algorithms (simple per §3.4.1, relaxed per §3.4.2) and the two body algorithms (simple per §3.4.3, relaxed per §3.4.4) applied independently produce the four c= tag combinations declared in the DKIM-Signature header. Documents the production-standard c=relaxed/relaxed choice, the optional l= partial-body-length tag and its security trade-off, the seven most common body-hash mismatch causes (forwarder whitespace folding, mailing-list footer injection, content-transform middleware, transfer-encoding changes, MIME re-encoding, trailing CRLF normalisation, Subject-prefix rewriting), the receiver-side forensic detection workflow via the Authentication-Results header (RFC 8601), four worked byte-level examples, and the per-provider canonicalization defaults for Microsoft 365, Google Workspace, Amazon SES, SendGrid, Mailgun, Mailchimp, Postmark, SparkPost, OpenDKIM, Postfix dkim-milter, and Exim DKIM. The canonical reference for debugging DKIM body-hash mismatch incidents.
• DKIM selectors explained — the selector vocabulary deep dive on RFC 6376 §3.1 and §3.6.1. The selector identifier (s= tag in the DKIM-Signature header) and the <selector>._domainkey.<domain> DNS label tree where the public key is published. Documents the every-tag reference for the published selector record (v=DKIM1, k=rsa or k=ed25519, p=, t=, h=, s=, n=), the eight selector-naming patterns operators encounter (numbered-pair, date-based, provider-named, short-letter, opaque, purpose-based, Microsoft-365-hyphenated, hosted-service prefix), the provider selector catalogue for Microsoft 365 (selector1 / selector2 CNAMEs), Google Workspace (google TXT), Amazon SES (three CNAMEs ending in .dkim.amazonses.com), SendGrid (em<n> / s1 / s2 CNAMEs), Mailgun (k1 / mailo TXT), Mailchimp (k1 CNAME), Postmark (date-based TXT), SparkPost (scph<yyyymm> TXT), Klaviyo (klaviyo1 CNAME), HubSpot (hs1- CNAME), and Brevo (mail CNAME), the multi-selector / multi-vendor deployment model, the dual-selector zero-downtime rotation pattern, and the seven most common selector-related failures with symptom / diagnosis / fix for each.
• DKIM key rotation: procedure, cadence, and best practices — operational deep dive on DKIM key rotation defined by RFC 6376 and updated by RFC 8301. Covers the security rationale (cryptographic strength erosion, key compromise, replay attacks), the recommended cadence, the canonical dual-selector zero-downtime procedure every operator should use for routine rotation, the single-selector emergency hot-swap for incident response, per-provider automation for Google Workspace, Microsoft 365, Amazon SES, Mailgun, Postmark, and SendGrid, the 1024-bit deprecation and migration path to 2048-bit RSA or Ed25519 (RFC 8463), and the 255-byte TXT-record pitfall that silently corrupts large public keys at some DNS provider UIs.
• DKIM cryptography basics: RSA / Ed25519 / SHA-256 / canonicalization — the cryptographic-foundation deep dive underneath the DKIM pillar. Covers the canonical mathematical operations DKIM relies on (RSA-2048 / RSA-4096 / Ed25519 signature ceremonies, SHA-256 body-hash computation, base64 encoding boundaries, DNS-record key publication), the simple vs relaxed canonicalization algorithms (RFC 6376 §3.4) and why every modern deployment uses relaxed/relaxed, the l= length-limited body-hash signature variant and its replay-attack risk (links to the replay-attacks spoke), the 1024-bit factoring history that drove the RFC 8301 deprecation, the Ed25519 introduction in RFC 8463 (and why a tiny slice of receivers still ignore it), the DNS-publication byte-counting math (255-byte TXT chunks, the 4096-bit-RSA-needs-quoted- concatenation trap that silently breaks some providers), and the canonical openssl genrsa -out / openssl-pkey -t Ed25519 generation commands. For engineers debugging "DKIM signature wrong" errors and operators deciding RSA vs Ed25519 for new key rollouts.
• DKIM replay attacks: the threat that valid signatures cannot block — security-research deep dive on the attack class where the attacker captures a legitimately-DKIM-signed message and re-sends it byte-for-byte from attacker infrastructure to an arbitrary recipient. The signature stays valid because DKIM signs the message body and headers, not the SMTP envelope or recipient list. Covers the canonical replay-attack pipeline (capture from victim mailbox → re-broadcast via attacker SMTP), the four real-world documented incidents (the 2024 Google/Yahoo bulk-sender-disclosure context, the 2023 ATP-rebroadcast campaign, etc.), the partial defenses (DKIM signing timestamps via t= and expiry via x=, dropping l= length-limited signatures, short-lived DKIM keys, ARC chain validation), and the structural reasons DKIM-replay is fundamentally unsolvable without a new authentication standard that binds the signature to the SMTP envelope. For DKIM operators understanding the threat model and incident responders recognising the canonical replay signature.
• DMARC record tags explained — every tag in the DMARC DNS record (v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri).
• DMARC alignment explained — identifier alignment (RFC 7489 §3.1, §6.6.2): strict vs relaxed, the organizational domain and the Public Suffix List.
• DMARC policy rollout — the operational migration from p=none through p=quarantine to p=reject with a worked Week 0 → Week 26 timeline.
• DMARC deployment checklist (operator quick-reference) — the concise per-phase action list that complements the policy-rollout deep dive: prerequisites (DNS edit access, sender inventory, monitoring mailbox), per-phase action items for discovery / triage / quarantine / enforcement, per-phase exit criteria, a decision matrix for the common scenarios that arise mid-deployment, and an FAQ for the questions operators ask most often during real-world DMARC projects.
• DMARC policy modes: p=none vs p=quarantine vs p=reject — the head-to-head comparative deep dive of the three DMARC policy values defined by RFC 7489 §6.3. Distinct from the rollout journey reference and the deployment checklist: this page covers per-mode semantics (what each mode tells receivers to do), an 11-dimension side-by-side comparison table, receiver behaviour at the major mailbox providers (Gmail, Microsoft 365, Yahoo, Apple iCloud) including the actual SMTP response codes each emits, how the pct= sampling tag interacts with each mode and the planned removal in draft-ietf-dmarc-dmarcbis, how sp= and np= (RFC 9091) subdomain policies interact with the apex p=, a scenario-based decision matrix, and the canonical operator FAQ.
• DMARC aggregate (RUA) reports — the daily XML stream receivers send back; the data behind every rollout decision. Plus the forensic (RUF) sibling.
• DMARC forensic (RUF) reports — the per-message MIME stream (AFRF envelope, RFC 6591) receivers send when a specific message fails DMARC. Covers the fo= tag, the major-receiver coverage reality (Google never, Microsoft no, Yahoo stopped), and the GDPR / CCPA privacy implications.
• BIMI explained — Brand Indicators for Message Identification. The consumer-facing logo-rendering payoff of DMARC enforcement.
• BIMI SVG Tiny PS logo requirements — the byte-by-byte file-format deep-dive spoke off the BIMI pillar covering the BIMI Group SVG Tiny PS profile: four required root attributes (version="1.2", baseProfile="tiny-ps", xmlns, square viewBox), required <title> first child, the categorical forbidden-element list (scripts, animation, hyperlinks, raster embed, foreign objects), the 32KB file-size cap, the solid-background rule for light + dark inbox themes, 7 worked examples, and the BIMI-Group-converter + SVGO + validator toolchain.
• BIMI Verified Mark Certificates (VMC and CMC) — the certificate-acquisition workflow deep-dive spoke off the BIMI pillar covering the Verified Mark Certificate procurement path: VMC vs CMC distinction (registered trademark vs common-law mark), the two authorised CAs (DigiCert and Entrust under the CA/Browser Forum Mark Certificate profile), the six accepted trademark registries (USPTO, EUIPO, UKIPO, JPO, IP Australia, CIPO), the 3-6 week end-to-end acquisition workflow with registry-coordination as the long pole, the RFC 3709 LogotypeExtn SHA-256 SVG-hash binding mechanism, the HTTPS + application/pem-certificate-chain serving rules, the annual renewal calendar, and ten common rejection causes.
• MTA-STS explained — SMTP MTA Strict Transport Security (RFC 8461). The transport-encryption hardening layer.
• MTA-STS vs DANE for SMTP — the side-by-side comparison spoke off the MTA-STS pillar covering RFC 8461 vs RFC 7672: trust-anchor difference (web PKI vs DNSSEC), the canonical DANE-EE TLSA deployment shape, provider support reference (Google, Microsoft 365, Yahoo, ProtonMail, Posteo, Comcast), the RFC 7672 §1.3 coexistence rule, decision matrix for which to deploy first, migration paths between the two.
• MTA-STS policy file syntax — the focused policy-file-level reference for the MTA-STS policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt per RFC 8461 §3.2. Documents the four canonical keys (version: STSv1, mode: enforce|testing|none, mx: with single-label wildcard semantics, max_age: with the one-year hard maximum), the HTTPS-only public-PKI fetch contract, the no-BOM and no-comments rules, the id-token coupling with the _mta-sts DNS record, the canonical testing-mode burn-in workflow, six canonical example policies, and ten common operator mistakes. The syntax-layer half of the MTA-STS reference set; pairs with the protocol pillar.
• MTA-STS for Microsoft 365 (deployment guide) — the first MTA-STS provider-deployment spoke. Operator-implementation walkthrough for Microsoft 365 / Exchange Online tenants: the four-step deployment (publish _mta-sts TXT, stand up external HTTPS hosting at mta-sts.<domain>, serve the policy file at /.well-known/mta-sts.txt, publish TLS-RPT companion record), the <tenant>-com.mail.protection.outlook.com MX enumeration pattern, hybrid Exchange and third-party-gateway shape variants, the testing-mode burn-in workflow with TLS-RPT monitoring, the id-token bump discipline, ten common mistakes, and a per-symptom troubleshooting decision matrix. Notes that M365 has NO Defender portal MTA-STS panel — all configuration is operator-driven at DNS and external HTTPS layers.
• MTA-STS for Google Workspace (deployment guide) — the Workspace counterpart to the M365 MTA-STS deployment spoke above; completes the MTA-STS provider-deployment pair off the MTA-STS pillar. Operator-implementation walkthrough for Google Workspace / Gmail- for-business tenants: the four-step deployment (publish _mta-sts TXT, stand up external HTTPS hosting at mta-sts.<domain>, serve the policy file at /.well-known/mta-sts.txt, publish TLS-RPT companion record), the aspmx.l.google.com plus alt1-4.aspmx.l.google.com five-target MX enumeration pattern (with the simplified smtp.google.com single-target variant for newer tenants), the Workspace-aligned hosting choices (Firebase Hosting, Cloud Run, Cloud Storage + Cloud CDN), the testing-mode burn-in workflow with TLS-RPT monitoring, Gmail's role as an MTA-STS-honoring sender since 2018, the 604800 max_age honoring cap, the id-token bump discipline, ten common mistakes, and a per-symptom troubleshooting decision matrix. Notes that Workspace has NO Admin Console MTA-STS panel — all configuration is operator-driven at DNS and external HTTPS layers.
• DANE for SMTP explained — the DANE-only pillar deep dive covering RFC 7672 + RFC 6698 at full grain: TLSA record format, the Usage / Selector / MatchingType field matrix, the canonical 3 1 1 (DANE-EE / SPKI / SHA-256) deployment shape, end-to-end deployment recipe, two-record overlap rollover, provider support reference, the DNSSEC dependency, and the operator-grade troubleshooting funnel.
• TLS-RPT explained — SMTP TLS Reporting (RFC 8460). The transport-layer reporting stream complementary to DMARC's RUA reports.
• TLS-RPT DNS record syntax — the focused byte-level reference for the _smtp._tls.<domain> TXT record per RFC 8460 §3. Documents the mandatory v=TLSRPTv1 case- sensitive version tag, the mandatory rua= reporting URI list with both mailto: and https: schemes, multi-URI comma-separated destinations, the cross-domain authorisation record at <recipient>._report._smtp._tls.<external> that prevents abuse, the no-subdomain- inheritance rule, the 255-octet character-string limit, and ten canonical operator mistakes. Pairs with the TLS-RPT pillar (which covers the JSON report format and the result-type catalogue).
• Microsoft SNDS and JMRP explained — the Microsoft-consumer-network sender-reputation deep dive: per-IP GREEN / YELLOW / RED filter verdicts, complaint rates, blocked ranges, the Automated Data Access key workflow with its silent 30-day expiry, and the redacted ARF (RFC 5965) complaint format JMRP delivers since June 2026 with Message-ID / custom-X-header attribution. The IP-centric reputation companion to the domain-centric authentication reporting this cluster documents.
• TLS-RPT JSON report format — the focused semantic-layer reference for the on-the-wire report schema per RFC 8460 §4. Field-by-field deep dive of the top-level metadata, the policy object (sts / tlsa / no-policy-found), the summary per-session counts, the failure-details[] array, the 12 canonical result-type values with per-value remediation, the application/tlsrpt+json vs application/tlsrpt+gzip MIME distinction, the mailto: attachment filename convention, the report-id-keyed redelivery and deduplication semantics, five worked example reports, and ten common ingestion-pipeline failure modes. The semantic-layer half of the TLS-RPT reference set; pairs with the record-syntax sibling.
• MX records explained — Mail Exchanger records (RFC 1035 §3.3.9 + RFC 5321 §5.1): the foundational DNS record that defines a domain's inbound mail destinations. The MX layer is what every page in this cluster ultimately addresses: SPF authenticates the connecting IP at the MX target, MTA-STS and DANE secure the TLS connection to the MX target, TLS-RPT reports per-MX-hostname transport failures, the RFC 7505 null-MX convention prevents spoofing from non-mail domains, and the no-CNAME-as-MX-target rule (RFC 2181 §10.3) is a structural constraint affecting every other record. Read once you understand the auth stack and want the addressing-layer reference covering MX priority semantics, the canonical multi-record + priority pattern, MX target IPv4 / IPv6 resolution, TTL recommendations, and the per-provider deployment reference (Google Workspace, Microsoft 365, Amazon SES, Postmark).
• Reverse DNS / PTR records explained — the in-addr.arpa / ip6.arpa reverse- lookup DNS record that maps a sending IP back to a hostname (RFC 1035 §3.5, RFC 8499 §3.1). The fourth-layer identity verification many receivers require before accepting mail: Gmail rejects with 550 5.7.25 when PTR is absent or generic; Microsoft 365 rejects with 550 5.7.1 under analogous conditions. Covers the canonical FCrDNS (Forward-Confirmed reverse DNS) check — PTR must resolve to a hostname whose A/AAAA record resolves back to the same IP — the per-provider PTR coordination paths (AWS reverse-DNS request workflow, Microsoft 365 SmartHost setup, Mailgun / SendGrid / Postmark dedicated-IP ordering), and the deployment patterns for shared-IP vs dedicated-IP senders. Pairs operationally with MX records to provide the bidirectional DNS identity every receiver expects.
• DNS propagation explained — cross-cutting operational reference covering how DNS record changes propagate through the caching hierarchy (authoritative nameserver → recursive resolver → end-user OS resolver → application). Critical for every DMARC / SPF / DKIM / MTA-STS rollout because phase transitions depend on the previously-published record having propagated. Covers TTL semantics (RFC 1035 §3.2.1), negative-caching (RFC 2308), the canonical 24-hour wait-for-propagation guidance, the dual-record overlap pattern for zero-downtime tag changes (set the new record at the new TTL, wait TTL+10 minutes, swap, wait TTL+10 minutes, remove the old), and the per-tool verification commands (dig +trace, kdig, the DNSChecker.org cross-region reachability test). Every Week-boundary phase advance in the policy-rollout journey depends on the previously-published record being propagated; this page is the operational bridge between the deployment-checklist prerequisites and the actual rollout timeline.
• CAA records explained — Certification Authority Authorization (RFC 8659). Constrains which CAs may issue certs for the domain.
• ARC (Authenticated Received Chain) explained — RFC 8617: the standard that preserves the original SPF / DKIM / DMARC verdict across forwarding hops (mailing lists, .forward redirects, security gateways). The three ARC headers, chain validation states, receiver support, the trust model.
• DMARC for Google Workspace — provider-specific deployment guide with Admin Console UI paths, _spf.google.com SPF include, google._domainkey DKIM selector, and the Feb 2024 Google/Yahoo bulk-sender requirements.
• DMARC for Microsoft 365 — provider-specific deployment guide for Exchange Online with the Defender portal UI paths, spf.protection.outlook.com SPF include, the dual-selector CNAME-delegated DKIM model (selector1 / selector2 pointing at <tenant>.onmicrosoft.com), and Defender for Office 365 Trusted ARC Sealers configuration.
• DKIM for Microsoft 365 — the DKIM-only operator reference for Exchange Online tenants. Covers the dual-selector CNAME-delegated architecture (selector1._domainkey and selector2._domainkey delegating to <tenant>.onmicrosoft.com), the three-step deployment workflow, three verification gates, automatic 2048-bit key rotation, the onmicrosoft.com signing-domain gotcha, seven common mistakes, and a per-symptom troubleshooting decision matrix.
• DKIM for Google Workspace — the DKIM-only operator reference for Gmail-for-business tenants. Covers the single-selector TXT-publication model (google._domainkey TXT containing the v=DKIM1; k=rsa; p=<base64> public-key bytes per RFC 6376 §3.6.2), the four-step Admin Console workflow (Generate new record, publish TXT, wait for propagation, click Start authentication), three verification gates, operator-controlled 2048-bit key generation, manual rotation cadence, and the gappssmtp.com signing-identity gotcha (the Workspace counterpart to M365's onmicrosoft.com failure mode). Completes the Workspace trinity alongside the SPF and DMARC Workspace guides; side-by-side comparison with M365's CNAME-delegation dual-selector automatic-rotation model.
• DKIM failures explained (verdict catalogue) — the receiver-side verdict reference for the seven canonical Authentication-Results DKIM verdicts per RFC 6376 §3.9 + RFC 8601 §2.7.1. Covers each verdict (none, neutral, pass, fail, policy, temperror, permerror) with its structural meaning, common causes, operational consequence, and diagnostic next step. Documents the dkim=pass + DMARC fail patterns (the M365 onmicrosoft.com and Workspace gappssmtp.com gotchas), the Authentication-Results anatomy reference (header.d / header.s / header.b / header.i field semantics), the DMARC rua aggregate-report <auth_results><dkim> block format that exposes the seven verdicts to operators, and a per-verdict diagnostic decision matrix.
• DKIM-Signature header explained (byte-by-byte tag anatomy) — the sender-side header reference per RFC 6376 §3.5. Documents every tag (v=, a=, c=, d=, s=, h=, bh=, b=, i=, q=, l=, t=, x=, z=) with format, defaults, validity rules, and failure modes; the two-hash design (bh= body hash + b= signed header set including the DKIM-Signature header itself with b= temporarily emptied); the signed-header set reconstruction algorithm; the l= replay-attack warning (never use); the t=-yes-x=-no timestamp guidance; malformed-header detection patterns. Natural sender-side companion to the receiver-side verdict catalogue.
• DKIM alignment with DMARC (RFC 7489 §3.1.1 deep dive) — the focused DKIM-only deep dive into how the d= tag in the DKIM-Signature header feeds into the DMARC alignment decision per RFC 7489 §3.1.1. DKIM-side complement to help_dmarc_alignment.php's symmetric SPF+DKIM coverage: closes the gap left by the verdict catalogue and the sender-side tag anatomy by documenting the full alignment evaluation algorithm from the DKIM angle. Covers the d=-vs- i= distinction (RFC 7489 §3.1.1 names d= as the alignment identifier); adkim=r (relaxed) vs adkim=s (strict) with the organizational-domain match rule for relaxed and FQDN equality for strict; the PSL organizational-domain extraction algorithm including the .co.uk illustration and the multi-tenant PSL entries (S3 buckets, Workers, herokuapp, gappssmtp); the multiple-signature "any aligns wins" rule per §3.1.1; the Microsoft 365 onmicrosoft.com gotcha in full detail (tenant-default signing vs custom-domain DKIM via the Defender portal CNAME publication); the Workspace gappssmtp.com gotcha (PSL-listed multi-tenant signing domain, custom-domain DKIM via Admin Console TXT publication); the SPF-vs-DKIM asymmetry under forwarding (DKIM survives because d= is inside the signed-header set; SPF breaks because forwarders rewrite the envelope); subdomain semantics edge cases; 10 common alignment mistakes; and a symptom → likely-cause → next-step troubleshooting matrix.
• DKIM troubleshooting (cross-symptom diagnosis guide) — the symptom-driven synthesis page that ties the verdict catalogue (help_dkim_failures_explained.php), the tag anatomy (help_dkim_signatures_explained.php), the alignment deep dive (help_dkim_alignment_with_dmarc.php), and the provider deployment guides into a single actionable decision tree. The operator's first-response reference when a DMARC aggregate report surfaces a dkim= failure: pick the verdict, follow the branch, execute the next step. Covers all eight Authentication-Results dkim= verdicts per RFC 6376 §3.9 and RFC 8601 §2.7.1 with per-branch most-likely-cause + next-step sub-sections, multi-signature scenarios per RFC 7489 §3.1.1 "any aligns wins" rule, provider-specific quick references (M365, Workspace, SaaS senders, transactional ESPs, self-hosted signers), the diagnostic tool surface (Email Header Analyzer, Domain Security Checker, dashboard drill-down), and a compact operator decision matrix.
• DKIM DNS record syntax (RFC 6376 §3.6.2 byte-level reference) — the focused syntactic reference for the DKIM public-key TXT record at <selector>._domainkey.<domain>. Mirrors help_spf_dns_syntax.php for the DKIM half of the DMARC trinity. Covers the FQDN structure, the optional v=DKIM1 version tag, the mandatory p= public-key tag (single continuous base64, no PEM banner), the k= key-type tag (rsa default, ed25519 per RFC 8463), the h= acceptable hash algorithms (sha256 only — rsa-sha1 deprecated by RFC 8301), the t= flags (t=y testing, t=s strict AUID), the s= service-type tag, the deprecated n= and g= tags, the 255-octet character-string chunking rule (RFC 1035 §3.3.14), the empty-p= revocation convention, six canonical examples, and ten canonical operator mistakes.
• DKIM best practices (synthesis operator-discipline reference) — the cluster-closing synthesis page consolidating operator-discipline rules from the 12 sibling DKIM-cluster pages into 15 prescriptive rules: 2048-bit RSA minimum, dual-publish k=ed25519, descriptive dated selectors, annual rotation with dual-selector overlap, c=relaxed/relaxed canonicalization, oversigned From/Subject/Date, empty i= default, NEVER l=, t=y burn-in then REMOVE, single-signature default, Authentication-Results + DMARC aggregate monitoring, multi-string TXT chunking, empty-p= emergency revocation, per-selector change log, and a quarterly cluster audit.
• DMARC for Hybrid Exchange (on-prem + M365) — provider-specific deployment guide for the hybrid topology where outbound mail flows through both Exchange on-premises and Exchange Online. Covers the hybrid topology spectrum (Hybrid Configuration Wizard, Centralized Mail Transport, split-domain coexistence, Edge Transport), the dual-signer DKIM problem (when both sides sign and DMARC alignment becomes non-deterministic), ARC sealing across the on-prem-to-cloud relay via Defender Trusted ARC Sealers (RFC 8617 + Set-ArcConfig), the Default Frontend Connector DKIM-strip pitfall, Send Connector relay loops (NDR 5.4.6), and the migration path from classic hybrid through CMT to fully cloud-routed mail flow.
• Email authentication glossary — canonical definitions reference for every term-of-art the cluster assumes: DMARC tags, DKIM selectors, alignment, organizational domain, PSL, RFC 5321 vs 5322, ARC chain validation, BIMI Mark Type Indicator, MTA-STS policy modes, TLS-RPT result types, and 60+ more — with Schema.org DefinedTermSet JSON-LD for AI-engine deep-linking.
• Email security glossary — the threat / defense vocabulary sibling to the auth glossary. ~80 terms across 9 categories: threat actors, phishing taxonomies (spear phishing, whaling, BEC, smishing, vishing, quishing), look-alike tactics (typosquatting, homograph, cousin domain), OSINT (Shodan, Censys, Certificate Transparency, WHOIS), defense-in-depth (SEG, EDR, zero trust, phishing-resistant MFA, DLP), incident response (NIST SP 800-61), threat modelling (STRIDE, kill chain, MITRE ATT&CK, D3FEND), and security operations (SOC, SIEM, SOAR, XDR, MDR). Paired with the auth glossary as the cluster's reference layer.
• DMARC troubleshooting — the cross-cutting failure-diagnosis reference: 7 canonical DMARC failure patterns each mapped to a root cause and remediation, plus per-pillar root-cause sections covering SPF permerror (10-DNS- lookup limit), DKIM body-hash mismatch, alignment-vs-authentication, DNS record syntax errors, forwarding / mailing-list breakage, and mailbox-provider quirks (Google / Microsoft / Yahoo / ProtonMail).
• DMARC monitoring & reporting analysis — the operational dashboard discipline that follows the policy rollout: 8 core KPIs from RFC 7489 §7.2 aggregate reports, 5 alert thresholds, three-tier review cadence, 5 anomaly detection patterns, the 72-hour post-change observation protocol for regression detection, sender-inventory drift detection, and the 6 canonical aggregate-report-to- operational-action patterns.
• DMARC reporting pipeline (end-to-end RUA + RUF ingestion reference) — the operator-implementation deep dive for the six pipeline stages that turn rua= aggregate and ruf= forensic reports landing in a monitoring mailbox into queryable database records and operational alerts. Ingestion via SMTP / IMAP4rev1 / Microsoft Graph; format detection of XML / gzip / zip / tar.gz via magic bytes; parsing per RFC 7489 Appendix C XML and RFC 6591 AFRF MIME; storage with UNIQUE-constraint deduplication; retention policies driven by GDPR data minimisation and storage cost; analysis and alerting across six alert categories. Anchored directly against the project's reference implementation in includes/DmarcParser.php, includes/ForensicReportParser.php, includes/ImapFetcher.php, and includes/GraphFetcher.php — the pipeline-level companion to the schema-level RUA + RUF deep dives above.
• Multi-Domain DMARC Strategy (portfolio operator reference) — the strategy guide for operators managing DMARC across many domains (acquired companies, marketing subdomains, brand-defensive registrations, parked-but-not-deleted properties). Where the single-domain rollout playbook walks ONE record through ONE rollout, this guide walks the PORTFOLIO: domain inventory from six reconciled sources, the six-category domain taxonomy, the RFC 7489 §3.2 organizational domain rule with Public Suffix List, the sp= subdomain inheritance tag (RFC 7489 §6.3), the np= non-existent subdomain tag (RFC 9091), reporting consolidation under one central rua= pipeline including the _report._dmarc external-domain authorization (RFC 7489 §7.1), the 6-step acquired-company integration playbook with a mandatory 14-30 day visibility window, and the parked-domain hardening pattern (null SPF + p=reject + null MX per RFC 7505) that costs nothing and prevents the most common brand-impersonation attack vector.
• DMARC for cPanel & Shared Hosting — provider-specific deployment guide for the SMB / shared-hosting segment (Bluehost, HostGator, SiteGround, GoDaddy, Namecheap, Hostinger). Covers cPanel's Email Deliverability page, the default._domainkey DKIM selector, provider-specific SPF includes, manual DKIM key rotation, shared-IP reputation, the provider- bounce-domain alignment failure mode, and the end-user-cPanel vs WHM administrator persona split.
• DMARC for Transactional Email (SendGrid, Mailgun, Amazon SES, Postmark, SparkPost, Mailjet, Resend, MailerSend, Brevo) — the first SENDER-TYPE deployment guide, paired with the four mailbox- provider guides. Covers DMARC alignment when a third-party ESP sends transactional mail (password resets, receipts, magic links, 2FA codes) on the operator's behalf: why SPF alignment is unreliable for ESPs, CNAME-delegated custom-domain DKIM as the load-bearing alignment mechanism, per-ESP selector conventions (s1/s2 SendGrid, mailo/mta Mailgun, three-token CNAMEs SES Easy DKIM, scph0316 SparkPost, mailjet, resend, mlsend/mlsend2 MailerSend), Return-Path bounce-domain CNAMEs, dedicated- subdomain segmentation, multi-ESP strategies, dedicated vs shared IP implications, and the Feb 2024 Google / Yahoo bulk-sender requirements anchor.
• DMARC for SaaS Senders (Salesforce Marketing Cloud, HubSpot, Marketo, Mailchimp, ActiveCampaign, Klaviyo, Constant Contact, Brevo, Pardot, Kit) — the second SENDER-TYPE deployment guide, sibling to Transactional Email, covering marketing-automation SaaS platforms. Anchored against the Feb 2024 Gmail / Yahoo bulk-sender requirements: RFC 8058 List-Unsubscribe-Post mandatory, engagement-based reputation thresholds, 30-50 day dedicated-IP-pool warm-up cadence, list hygiene as a DMARC prerequisite, mandatory marketing-subdomain segmentation. Per-platform DKIM selector conventions: SFMC per-Business-Unit, HubSpot hs1/hs2-portal, Marketo + Mailchimp + Constant Contact k1/k2, ActiveCampaign dk, Klaviyo + bounce CNAME, Brevo mail, Pardot per-org-alias, Kit per-account.
• Email deliverability fundamentals (authentication, sender reputation, engagement signals, list hygiene, postmaster tools) — cross-cutting business-outcome deep dive connecting authentication (this cluster's protocol focus) to the broader receiver-side outcome chain that determines whether sent mail reaches the recipient inbox. Documents the four-stage delivery funnel (MX accept, SMTP envelope acceptance, content-classifier placement, recipient action), how each SPF / DKIM / DMARC / ARC / BIMI outcome shifts placement, sender reputation as a weighted composite of IP + domain + tenant + engagement sub-reputations (engagement universally weighted heavily), the recipient engagement-signal feedback loop, list-hygiene discipline (hard-bounce removal, soft-bounce escalation, spam-trap avoidance, double opt-in, address validation at signup), the postmaster- tools observability triad (Google Postmaster Tools at postmaster.google.com, Microsoft SNDS + JMRP, Yahoo Sender Hub at senders.yahooinc.com), the SMTP bounce taxonomy (RFC 3463 enhanced status codes 5.7.1 / 5.7.26 / 5.7.509 / 5.7.605), the per-receiver inbox-vs-spam-vs-Promotions placement model (Gmail tabs, Outlook Focused vs Other, Yahoo Bulk vs Inbox, Apple iCloud), common misconceptions ("good content equals good deliverability" is folk wisdom, "DMARC alone fixes deliverability" is wrong, "switching ESPs fixes deliverability" is mostly wrong), and a 15-item best-practices checklist anchored against the Feb 2024 Gmail / Yahoo bulk-sender requirements. For marketing operations, lifecycle / CRM engineers, deliverability consultants, and DevOps teams operating high-volume sending infrastructure — the audiences that read the email-authentication cluster pillar and ask "but what's the business outcome?".
• Email spoofing explained (7 canonical techniques + SPF/DKIM/DMARC defense + detection) — the foundational TECHNIQUE definition for the entire cluster. Documents what email spoofing actually IS (the protocol-level forgery of one or more sender-identity fields), why email is inherently spoofable (RFC 5321 SMTP from 1982 + RFC 5322 IMF from 2008 were never designed with authentication), the seven canonical spoofing techniques (direct domain From-forgery, envelope MAIL FROM spoofing, display-name spoofing, lookalike-domain registration, IDN homograph via Unicode confusables, cousin-domain registration, subdomain takeover via abandoned DNS), how each of SPF / DKIM / DMARC defends, what DMARC does NOT prevent, the forensic detection workflow via the Authentication-Results header per RFC 8601, real-world examples, and defense-in-depth recommendations. Maps onto MITRE ATT&CK T1566 / T1583.001 / T1036. The entry-point page for operators asking "how do attackers fake the sender of my company email" — the foundational question every page in this cluster exists to answer.
• Phishing protection — the defender playbook against phishing as a campaign — the parent operational reference covering ALL phishing variants. Where email-spoofing documents the protocol-level TECHNIQUE of forging the sender, this page covers the broader CAMPAIGN — the eight-variant phishing taxonomy (mass / spear / whaling / clone / HTTPS / smishing / vishing / quishing), the six-stage phishing kill chain (recon, weaponization, delivery, exploitation, persistence, actions on objective) mapped onto Lockheed Martin CKC, exactly which phishing variant DMARC blocks (ONE — direct domain spoofing) and the seven it does NOT (lookalike domain, display-name, IDN homograph, cousin, compromised account, third-party service, out-of-band), the secure email gateway anti-phishing controls (URL rewriting + sandbox detonation + display-name impersonation rules + lookalike-domain detection + Vendor Email Compromise anomaly detection), phishing-resistant MFA (FIDO2 / WebAuthn / passkeys) with the Adversary-in-the- Middle defense reasoning (origin binding via Relying Party ID defeats Evilginx, Modlishka, Muraena, EvilProxy, Tycoon 2FA), the forensic detection workflow (Authentication-Results per RFC 8601 + URL hover + IDN/Punycode + Reply-To + Received chain + attachment inspection), six real-world phishing examples (Google + Facebook USD 100M BEC, Twitter 2020 vishing, Uber 2022 push-bombing, MGM Resorts 2023 vishing, Snowflake 2024, AitM Microsoft 365 campaigns), the six-layer defense-in-depth stack (email auth / SEG / phishing-resistant MFA / conditional access / EDR / training), and the eight-step phishing IR checklist. Maps onto MITRE ATT&CK T1566 with three sub- techniques (T1566.001 / T1566.002 / T1566.003), T1078 Valid Accounts, T1556.006 MFA Modification, T1539 Steal Web Session Cookie. Cites NIST SP 800-63B AAL3, CISA AA22-279A, FBI IC3, APWG, and Verizon DBIR. The parent operational reference for SOC analysts, security engineers, blue-team operators, IT helpdesks, and CISOs answering "how do we prevent phishing as a class".
• How attackers bypass weak DMARC — security-research-flavoured page documenting 22 concrete attacker techniques against the DMARC ecosystem across 4 classes: §4 direct attacks on the visible From: identity (display-name spoofing, lookalike domains, IDN homographs, brand impersonation), §5 weak-configuration attacks (p=none gap, pct<100 sampling, sp= subdomain free-for- all, missing apex DMARC, SPF +all, subdomain takeover), §6 authentication-mechanism attacks (DKIM 1024-bit factoring, DKIM replay, DKIM l= length-limited body-hash abuse, ARC chain abuse via compromised trusted sealer), §7 infrastructure attacks DMARC cannot stop (BEC compromised accounts, compromised ESP, mail-flow rule abuse, BIMI logo abuse). MITRE ATT&CK T1566 / T1583.001 / T1584 / T1078 / T1114.003 mappings.
• DMARC myths and misconceptions debunked — defender-perspective dual to the attacker- bypass page. The 18 most common DMARC myths debunked one-by-one with RFC 7489 evidence: "p=reject blocks phishing" (no — only direct domain spoofing), "DMARC encrypts email" (no — it authenticates), "I have SPF and DKIM so I do not need DMARC" (the alignment fallacy), "BIMI works at p=none" (no — quarantine or reject required), "subdomains do not inherit policy automatically" (sp= and organizational- domain inheritance), "pct=10 means 10% of attackers blocked" (no — it is a rollout dial), "RUF is the most useful report kind" (no — RUA is the workhorse), and 11 more. Mental- model correction for operators who have read vendor marketing copy.
• Business Email Compromise (BEC) explained — finance- / fraud-team-facing operational deep dive for the FBI Internet Crime Complaint Center (IC3) reports' #1 financial-loss email-crime category (USD 2.9 billion reported U.S. losses in 2023, USD 55 billion cumulative across 2013-2024). Documents the six canonical BEC variants (CEO fraud, invoice fraud / vendor wire redirection, payroll diversion, gift-card scam, M&A fraud, Vendor Email Compromise VEC), the five-stage BEC kill chain, exactly where DMARC defends (direct-domain spoofing at p=reject blocks 1 of 6 variants) vs where DMARC does NOT defend (lookalike domains, display-name spoofing, compromised accounts, VEC, out-of-band channels), the six-layer defense-in-depth control stack, employee red-flag indicators, the FBI Financial Fraud Kill Chain (FFKC) incident-response playbook, and BEC vs ransomware cost-comparison statistics for executive sponsorship. Maps onto MITRE ATT&CK T1566.003 / T1078 / T1534 / T1114.003. Distinct from the attacker-bypass page (which catalogues BEC as one of 22 attacker techniques): this is the standalone playbook for finance, treasury, fraud teams, and CFOs justifying email-authentication investment to the board.
• DMARC for Shared Hosting: Plesk, DirectAdmin, ISPConfig — provider-specific deployment guide for the shared-hosting segment OTHER than cPanel. Covers Plesk (Postfix backend, DKIM at Mail Settings > DKIM spam protection, default selector), DirectAdmin (Exim backend, DKIM at Email Manager > DKIM, single-character x selector), ISPConfig (Postfix + Dovecot), Webmin / Virtualmin, CentOS Web Panel (CWP), AND the generic-no- control-panel population with a SaaS-relay CNAME-delegated DKIM escape hatch.
• DMARC Analyzer Dashboard — ingests aggregate (RUA) and forensic (RUF) reports via includes/DmarcParser.php and includes/ForensicReportParser.php.
• Email Header Analyzer — paste any email's headers and see SPF, DKIM, DMARC results plus the alignment evaluation.
• Domain Security Checker — live DNS lookups for SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT, CAA, and DNSSEC.
• DNS Record Generator — DMARC / SPF / DKIM / TLS-RPT / MTA-STS / CAA / BIMI record wizards.
• RFC 7208 — Sender Policy Framework — SPF specification.
• RFC 6376 — DomainKeys Identified Mail — DKIM specification.
• RFC 7489 — DMARC — DMARC specification.
• RFC 8601 — Authentication-Results header — the per-message verdict header every modern receiver adds on inbound delivery.
• RFC 8617 — Authenticated Received Chain (ARC) — the standard that preserves authentication results across forwarding hops.

13. Get started with email authentication

DMARC Analyzer is the operator console for the full email-authentication stack. The dashboard ingests DMARC aggregate (RUA) and forensic (RUF) reports via includes/DmarcParser.php and includes/ForensicReportParser.php, surfacing per-sender / per-IP / per-day authentication breakdowns; the domain security checker runs live DNS lookups across all seven standards through includes/DnsChecker.php; the email header analyser at header_analyzer.php diagnoses individual message failures; and the DNS record generator at dns_generator.php produces syntactically-correct records for SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT, and CAA.

Sign up — Free plan Check my email-authentication records