DMARC Analyzer

TL;DR

• DMARC alignment is the rule that the SPF- or DKIM-authenticated domain MUST match the From: header domain the user sees. Defined in RFC 7489 §3.1. Without alignment, SPF and DKIM authenticate SOME domain — but not necessarily the one shown to the recipient.
• DMARC passes when at least one of SPF-aligned OR DKIM-aligned passes. Both failing produces a DMARC fail regardless of the underlying SPF and DKIM results.
• Relaxed alignment (r, the default) requires the organizational domain to match — mail.example.com aligns with example.com. Strict alignment (s) requires an EXACT domain match — mail.example.com does NOT align with example.com under strict.
• The adkim tag controls DKIM alignment; aspf controls SPF alignment. Both accept r or s and default to r.
• SPF aligns the envelope sender (MAIL FROM); DKIM aligns the d= tag in the DKIM-Signature header. Both compare against the visible From: header domain.
• The organizational domain is derived using the Public Suffix List (RFC 7489 §3.2). For example.co.uk the organizational domain is example.co.uk, NOT co.uk — the PSL prevents the latter wrong match.
• SPF alignment breaks during forwarding (envelope rewrite); DKIM usually survives. That asymmetry is why every sending source should be DKIM-signed with custom-domain DKIM enabled.

1. What is DMARC identifier alignment?

DMARC identifier alignment is the rule that the authenticated domain identifier from SPF or DKIM MUST match the domain in the From: header that the recipient actually sees. The concept is defined in RFC 7489 §3.1, and the per-protocol alignment rules in §3.1.1 (DKIM) and §3.1.2 (SPF).

Before DMARC, SPF and DKIM each produced an authenticated result against their own identifier. SPF authenticates the SMTP envelope sender (MAIL FROM / bounce address); DKIM authenticates the signing domain (d= tag in the DKIM-Signature header). Neither of those identifiers is the same as the From: header that mail clients display to the user.

An attacker could pass SPF for bounce.attacker.example while displaying billing@yourbank.com in From:. Both authentication checks "passed" — but the recipient sees a forged sender. DMARC alignment closes that gap by requiring that the domain SPF or DKIM authenticated matches the From: header domain.

A DMARC evaluation produces a single pass or fail decision: pass if at least one of SPF-aligned or DKIM-aligned passes; fail if both fail. The underlying SPF and DKIM results matter, but only after alignment is applied. A message with spf=pass for a misaligned envelope domain and no DKIM signature produces a DMARC fail.

2. How a receiver evaluates alignment

1. The receiver runs SPF on the MAIL FROM envelope sender and records the result (pass, fail, neutral, etc.) plus the SPF-authenticated domain (the d-domain).
2. The receiver verifies every DKIM signature in the message and records each signature's d= tag plus its pass/fail result. Multiple signatures are common; any one signature that passes is sufficient for DKIM-aligned.
3. The receiver extracts the From: header domain — the domain to the right of the @ in the displayed From: address. RFC 7489 §6.6.1 requires exactly ONE From: header; multiple From: headers cause DMARC to fail without further evaluation.
4. The receiver computes the organizational domain for the From: header by walking the domain against the Public Suffix List per RFC 7489 §3.2 — for news.example.co.uk the organizational domain is example.co.uk.
5. For each SPF / DKIM result, the receiver applies the alignment rule from the published DMARC record: under r (relaxed) the organizational domain of the authenticated identifier MUST match the organizational domain of the From: header; under s (strict) the FQDN of the authenticated identifier MUST exactly match the FQDN of the From: header.
6. If at least one of SPF-aligned or DKIM-aligned passes, the message passes DMARC. If both fail, the message fails DMARC and the policy (p, sp, or np) is applied per RFC 7489 §6.6.

3. Where do SPF and DKIM identifiers come from?

Alignment compares an authenticated identifier against the From: header. Each protocol contributes a distinct identifier:

SPF — the d-domain (envelope sender)

SPF authenticates the SMTP envelope sender, also called the MAIL FROM address or the Return-Path. RFC 7489 §3.1.2 names the domain portion of that address the "SPF d-domain". For envelope bounce@mail.example.com the d-domain is mail.example.com. SPF alignment compares this against the From: header.

DKIM — the d= tag

Every DKIM signature includes a d= tag in its DKIM-Signature header declaring the signing domain. A signature with d=example.com attests that the holder of the selector._domainkey.example.com private key signed the message. DKIM alignment compares this d= value against the From: header. Per RFC 7489 §3.1.1, the i= tag (if present) is NOT used for alignment — only d=.

The From: header

The HTTP-style From: header in the message body — the address mail clients display to the user. RFC 5322 §3.6.2 defines the field; RFC 7489 §6.6.1 requires exactly ONE From: per message. DMARC alignment uses the domain portion of the From: address as the comparison target for both SPF and DKIM.

Crucially, SPF and DKIM produce independent identifiers. A typical SaaS deployment has SPF passing for bounce.sendgrid.net (the SaaS bounce domain) while DKIM passes for example.com (custom-domain DKIM enabled at the SaaS). The SaaS envelope misaligns with From: but the DKIM signature aligns, so DMARC passes via DKIM-aligned.

4. Strict vs relaxed alignment

Both adkim (DKIM alignment mode) and aspf (SPF alignment mode) accept two values: r (relaxed) and s (strict). Both default to r.

Relaxed is the operationally safe default because most production mail flows DKIM-sign and SPF-authorise at a subdomain (mail.example.com, news.example.com) while the From: header carries the bare organizational domain. Relaxed alignment makes those flows align without per-subdomain configuration.

Strict is the high-security choice for non-sending domains and high-value brand domains. With adkim=s; aspf=s, only mail DKIM-signed AND SPF-authorised at exactly the organizational domain passes — closing the subdomain-spoofing surface where an attacker who controls one subdomain could otherwise produce relaxed-aligned mail for the parent.

The two alignment modes are evaluated independently. A record with adkim=s; aspf=r requires strict DKIM alignment but accepts relaxed SPF — useful when DKIM is signed by tightly-controlled infrastructure but SPF includes a third-party sender at a sibling subdomain. See the DMARC records deep dive §5 for the tag interactions.

5. The organizational domain & Public Suffix List

Relaxed alignment compares organizational domains, not full domain names. RFC 7489 §3.2 defines the organizational domain as the registered name plus its public suffix, where the public suffix is the longest entry from the Public Suffix List (PSL) that the domain ends with.

The PSL is essential for safe relaxed alignment. Without it, a naive "strip the leftmost label" rule would consider example.co.uk and other.co.uk aligned (they share co.uk) — clearly wrong because co.uk is a public registry, not a private organization. The PSL's co.uk entry tells the receiver "this is a public suffix; do not strip past it".

Subdomains hosted on shared platforms — example.github.io, example.netlify.app, example.vercel.app — are listed as public suffixes themselves, so each example.-prefixed name is its OWN organizational domain. This is exactly the correct behaviour: GitHub-Pages users should not be considered the same organization as each other for DMARC alignment.

The PSL is maintained at publicsuffix.org by Mozilla and the wider community. Receiver software refreshes its local copy periodically; expect daily-cadence updates on major mail providers.

6. Alignment worked examples

6.1 Relaxed alignment, both pass (typical SaaS)

From:        billing@example.com
MAIL FROM:   bounce@mail.example.com
DKIM d=:     mail.example.com
SPF result:  pass (for mail.example.com)
DKIM result: pass (for mail.example.com)
DMARC:       v=DMARC1; p=reject; adkim=r; aspf=r

SPF aligned?  mail.example.com ↔ example.com (relaxed) ⇒ ALIGNED
DKIM aligned? mail.example.com ↔ example.com (relaxed) ⇒ ALIGNED
DMARC result: PASS

6.2 Strict alignment, DKIM fails alignment

From:        billing@example.com
DKIM d=:     mail.example.com
DKIM result: pass (for mail.example.com)
DMARC:       v=DMARC1; p=reject; adkim=s

DKIM aligned? mail.example.com ≠ example.com (strict) ⇒ MISALIGNED
SPF aligned?  (similar evaluation)
DMARC result: depends on SPF alignment alone

6.3 SPF fails alignment via forwarding

From:        billing@example.com (original sender)
MAIL FROM:   user@forwarder.example  (rewritten by forwarder)
DKIM d=:     example.com
SPF result:  pass (for forwarder.example — the rewritten domain)
DKIM result: pass (for example.com — body unmodified)
DMARC:       v=DMARC1; p=reject; adkim=r; aspf=r

SPF aligned?  forwarder.example ≠ example.com ⇒ MISALIGNED
DKIM aligned? example.com ↔ example.com ⇒ ALIGNED
DMARC result: PASS (via DKIM-aligned)

This is why DKIM signing matters: DKIM survives forwarding when SPF cannot. A message signed only by SPF fails DMARC the moment it is forwarded.

6.4 SaaS sender with custom-domain DKIM

From:        hello@example.com
MAIL FROM:   bounces+abc123@bounce.sendgrid.net
DKIM d=:     example.com (custom-domain DKIM enabled at SendGrid)
SPF result:  pass (for bounce.sendgrid.net)
DKIM result: pass (for example.com)
DMARC:       v=DMARC1; p=reject; adkim=r; aspf=r

SPF aligned?  bounce.sendgrid.net ≠ example.com ⇒ MISALIGNED
DKIM aligned? example.com ↔ example.com ⇒ ALIGNED
DMARC result: PASS (via DKIM-aligned)

The standard pattern for SaaS mail. SPF for your custom From: domain is almost never enabled by SaaS providers (their bounces go to THEIR domain); custom-domain DKIM is the universal escape hatch and must be enabled at every SaaS sender.

6.5 Mailing-list breaks DKIM body signature

From:        member@example.com
MAIL FROM:   list-bounces@list.example.org
DKIM d=:     example.com (original signature)
SPF result:  pass (for list.example.org)
DKIM result: fail (list re-wrote Subject and appended footer — body hash mismatch)
DMARC:       v=DMARC1; p=reject; adkim=r; aspf=r

SPF aligned?  list.example.org ≠ example.com ⇒ MISALIGNED
DKIM aligned? signature failed verification ⇒ N/A
DMARC result: FAIL

Mailing lists routinely rewrite Subject lines and append footers, invalidating the original DKIM body signature. The remediation patterns are RFC 8617 ARC (Authenticated Received Chain) where the list re-signs with its own ARC headers, or From: rewriting where the list changes From: to its own domain so DMARC does not trigger on the original domain.

6.6 Public-Suffix-List edge case — Github Pages

From:        notifications@example.github.io
DKIM d=:     example.github.io
DKIM result: pass
DMARC:       v=DMARC1; p=reject; adkim=r

DKIM aligned? example.github.io ↔ example.github.io
              (organizational domain = example.github.io because
              github.io is on the PSL) ⇒ ALIGNED
DMARC result: PASS

With github.io on the PSL, example.github.io is its own organizational domain. The naive "strip leftmost" rule would have considered it aligned with other.github.io — incorrectly granting alignment across unrelated GitHub Pages users.

6.7 Internal subdomain attack blocked by strict alignment

Scenario: attacker compromised mail.example.com infrastructure.
          They can sign mail with d=mail.example.com.

From:        billing@example.com
DKIM d=:     mail.example.com
DKIM result: pass (genuine signature from compromised host)
DMARC:       v=DMARC1; p=reject; adkim=s

DKIM aligned? mail.example.com ≠ example.com (strict) ⇒ MISALIGNED
DMARC result: FAIL — attack blocked

Under adkim=r (relaxed) the attacker's compromised mail.example.com host could sign mail for the parent example.com; under adkim=s (strict) the same mail fails DMARC. Strict alignment is therefore the canonical defense against subdomain-takeover spoofing — at the cost of legitimate subdomain-signed mail also failing (which is why strict is reserved for non-sending domains and brand-protection domains).

6.8 Multiple DKIM signatures — any aligned signature wins

From:        billing@example.com

DKIM signature 1:  d=mail.example.com  pass
DKIM signature 2:  d=example.com       pass
DKIM signature 3:  d=relay.example.net pass

DMARC:       v=DMARC1; p=reject; adkim=s

Signature 1 aligned? mail.example.com ≠ example.com (strict) ⇒ no
Signature 2 aligned? example.com ↔ example.com (strict) ⇒ YES
Signature 3 aligned? example.net ≠ example.com ⇒ no

DKIM-aligned overall: YES (any one passing signature is sufficient)
DMARC result: PASS

A message can carry multiple DKIM signatures. DMARC's DKIM-aligned check requires that at least ONE signature both passed AND aligned with From: — not all of them. Major SaaS senders often produce two signatures (one for their bounce domain, one for the custom domain) to maximise the chance of alignment.

7. Alignment best practices

• Enable custom-domain DKIM at every sending platform. Marketing tools, transactional providers, helpdesks, CI/CD pipelines — every source that sends mail with your From: domain MUST sign with a d= that aligns with your From:. SPF alignment will routinely break (forwarding, SaaS bounce domains); DKIM alignment is the durable channel.
• Default to adkim=r; aspf=r for active sending domains. Relaxed alignment makes the common cross-subdomain mail flows work without per-subdomain configuration. Move to strict only after a stable enforcement baseline is established.
• Use adkim=s; aspf=s on non-sending domains and brand-protection portfolio domains. Strict alignment closes the subdomain-spoofing surface; non-sending domains have no operational cost from strict.
• Audit your DKIM d= values regularly. SaaS providers sometimes change their default signing domain or revoke custom-domain DKIM during plan changes. A surprise mid-flight switch from d=example.com to d=mailing.sendgrid.net misaligns every subsequent message, whether adkim is relaxed or strict.
• Watch organizational-domain edge cases. Domains under shared public suffixes (github.io, herokuapp.com, netlify.app, vercel.app, s3.amazonaws.com) are individual organizational domains; you cannot rely on relaxed alignment to make sibling subdomains align.
• Read your aggregate reports for alignment-specific failures. The policy_evaluated block in every report's <record> shows dkim and spf pass/fail INCLUDING alignment — a "pass" there means authentication AND alignment both succeeded. The <auth_results> block shows authentication only. A consistent gap between the two columns flags an alignment problem, not an authentication problem.
• Avoid mixing adkim=s with shared SaaS DKIM. If SendGrid signs with d=u123.example.com (their per-customer custom signature pattern) but you have adkim=s published, every SendGrid message fails alignment. Either use SendGrid's true-custom-domain DKIM (d=example.com) or relax adkim.
• Test alignment via mail-tester.com or DMARC Analyzer's Email Header Analyzer before relying on production reports. The header analyzer decodes SPF and DKIM headers AND computes the alignment result against the From: domain for any message you paste.

8. Common alignment mistakes

• Assuming "SPF passed" means DMARC will pass. SPF passes for the envelope domain — which is rarely your From: domain when a SaaS or forwarder is involved. Without alignment, SPF passing is operationally useless to DMARC.
• Forgetting to enable custom-domain DKIM at SaaS senders. Default SaaS DKIM signs with the SaaS provider's domain (d=u123.smtp.example-saas.com), which never aligns. Every SaaS provider has a custom-domain DKIM setup procedure — run it for every sender.
• Setting aspf=s while relying on SaaS senders. Strict SPF alignment requires the envelope domain to exactly match the From: domain — almost never the case with SaaS. Strict SPF is viable only for fully-controlled infrastructure.
• Using i= in DKIM thinking it controls alignment. The DKIM i= tag identifies the "agent or user on whose behalf the message is signed" — RFC 6376 §3.5. RFC 7489 §3.1.1 explicitly says alignment uses d= only; i= is ignored.
• Adding extra DKIM signatures to "fix" alignment without verifying the existing signature. A failing original signature plus a passing aligned signature still passes DMARC — but the underlying problem (the original signature failing) often points at a body-modification upstream that will cause other problems.
• Relying on relaxed alignment across the Public Suffix List. example.github.io and other.github.io are SEPARATE organizational domains because github.io is on the PSL. Relaxed alignment does NOT merge them.
• Confusing the SPF authenticated domain with the HELO/EHLO value. SPF can be evaluated against either MAIL FROM or the HELO identity. DMARC alignment uses the MAIL FROM result specifically (RFC 7489 §3.1.2). A HELO-only SPF pass does not contribute to DMARC alignment.
• Two From: headers in the message body. RFC 5322 forbids multiple From: headers, but some bug-classes (mail merge tools, broken relays) produce them. RFC 7489 §6.6.1 says receivers MUST fail DMARC for messages with multiple From: headers — alignment is not even evaluated.

9. Alignment troubleshooting

Aggregate report shows spf=pass in <auth_results> but spf=fail in <policy_evaluated>

SPF authenticated successfully but the authenticated domain misaligns with the From: header. The <auth_results> block shows authentication only; <policy_evaluated> shows the alignment-applied result. The fix: either change the envelope sender to align with From:, or rely on DKIM alignment as the primary channel.

DKIM verifies but DMARC fails

The DKIM signature passed verification but its d= tag misaligns with the From: header. Common causes: a SaaS provider signing with their domain instead of yours (enable custom-domain DKIM); a wildcard subdomain signing with the subdomain instead of the apex (consider adding an apex signature too); strict adkim=s rejecting a subdomain-signed message that would have aligned under relaxed.

Mail from one specific subdomain fails DMARC under adkim=s

Expected behaviour. Strict alignment requires the DKIM d= to match the From: FQDN exactly. Either move that sender to DKIM-sign at the From: FQDN (typically the organizational apex), or relax adkim to r.

Mailing-list mail fails DMARC

The list rewrote the Subject or appended a footer, invalidating the original DKIM signature; SPF also misaligns because the list's envelope is its own bounce domain. Two fixes: (a) the list adopts ARC re-signing per RFC 8617; (b) the list rewrites From: to its own domain so DMARC is evaluated against the list, not the original sender.

The header analyzer says SPF aligned but my aggregate report shows otherwise

Receivers sometimes compute alignment against the Return-Path (final post-routing) rather than the original MAIL FROM. Forwarding can change this. Check the report timestamp range and look at the actual Received headers to determine the post-routing envelope.

Strict alignment broke my legitimate mail after a DNS change

Revert adkim or aspf to r immediately to restore delivery; the likely root cause is a sender signing or sending from a subdomain that no longer matches the From: FQDN. Investigate via the next aggregate-report cycle, then re-enable strict once the sender is fixed.

I see spf=none and dkim=none in <policy_evaluated>

Means neither SPF nor DKIM was attempted (or both produced inconclusive results), so alignment was not evaluated either. The message has effectively no authentication — usually because SPF was not published for the envelope domain AND no DKIM signatures were attached. Publish SPF and enable DKIM at the sending source.

10. Frequently Asked Questions

What is DMARC alignment?

DMARC alignment is the requirement that the authenticated domain identifier from SPF or DKIM matches the domain in the From: header that the recipient actually sees. Defined in RFC 7489 §3.1, alignment is what closes the gap between "SPF/DKIM passed for SOME domain" and "the message is genuinely from the From: domain". A message passes DMARC when at least one of SPF-aligned or DKIM-aligned passes; both failing produces a DMARC fail regardless of the underlying SPF and DKIM results.

What is the difference between strict and relaxed alignment?

Relaxed alignment (r, the default) requires the authenticated domain to match the From: header at the organizational-domain level — mail.example.com and example.com are aligned. Strict alignment (s) requires an exact domain match — mail.example.com and example.com are NOT aligned under strict. Strict alignment is the more secure choice; relaxed is more forgiving of cross-subdomain mail flows. The adkim tag controls DKIM alignment mode and aspf controls SPF alignment mode; both default to r.

What is the organizational domain?

The organizational domain is the registered name plus the public suffix immediately to the right of it — for example.co.uk the organizational domain is example.co.uk, NOT co.uk and NOT news.example.co.uk. RFC 7489 §3.2 defines this concept and references the Public Suffix List (PSL, maintained at publicsuffix.org) as the canonical source of public suffixes. Without the PSL, relaxed alignment would consider example.co.uk and other.co.uk "aligned" because they share the co.uk suffix — clearly wrong. The PSL prevents that.

How does SPF alignment work?

SPF alignment compares the SPF-authenticated envelope domain (the MAIL FROM / Return-Path domain, also called the SPF "d-domain") against the From: header domain. Under relaxed (aspf=r, default), the organizational domains must match. Under strict (aspf=s), an exact match is required. SPF alignment routinely breaks during forwarding because forwarders rewrite the envelope sender to their own domain — which is why DKIM alignment matters: it survives forwarding when SPF does not.

How does DKIM alignment work?

DKIM alignment compares the DKIM signing domain — the d= tag in the DKIM-Signature header — against the From: header domain. Under relaxed (adkim=r, default), the organizational domains must match. Under strict (adkim=s), an exact match is required. DKIM signatures typically survive forwarding because they cover the message body and selected headers; if the message body is not modified in transit, the signature remains valid and the d= identifier remains aligned regardless of envelope changes.

Why does my SPF pass but DMARC fail?

The most common cause is misaligned SPF: SPF authorised the IP, but the authorised envelope domain is not the From: header domain. Examples: (1) a SaaS sender (SendGrid, Mailgun) puts their own bounce domain in MAIL FROM, so SPF passes for the SaaS domain but does NOT align with your From:; (2) forwarding rewrites the envelope to the forwarder. The fix is to enable custom-domain DKIM at the SaaS sender — DKIM aligns regardless of envelope, so a successful DKIM signature in the From: domain saves the DMARC result.

Should I use strict or relaxed alignment?

Default to relaxed (r) for active sending domains because cross-subdomain mail flows (transactional mail signed by mail.example.com, marketing mail signed by news.example.com) all align with a From: of example.com. Use strict (s) for non-sending domains and high-value brand domains where any subdomain-level mismatch should fail DMARC. Strict alignment closes the subdomain-spoofing surface (an attacker who compromises mail.example.com cannot sign mail for example.com under strict), at the cost of operational flexibility.

11. Related guides

• DMARC record tags explained — every tag in the DMARC DNS record with syntax, defaults, and interaction rules. This page documents adkim and aspf in their broader tag context.
• DMARC reporting pipeline — RUA / RUF ingestion, parsing, and delivery (the ALIGNMENT-PRODUCES-PIPELINE-RECORDS companion to this alignment-mechanics reference) — the ALIGNMENT-PRODUCES-PIPELINE-RECORDS companion documenting the INFRASTRUCTURE PATH that turns the per-message alignment computation THIS page documents into the aggregate-report row stream operators consume for monitoring and rollout advancement gates. Where THIS page documents the alignment COMPUTATION itself in protocol-precise terms (RFC 7489 §3.1 + §6.6.2 SPF-or-DKIM- authenticated-identifier-matches-From: rule, relaxed-via-PSL-orgdomain vs strict- via-FQDN evaluation, the adkim=s/aspf=s tag-strictness selection, the policy_evaluated.dkim and policy_evaluated.spf verdict each message yields), the reporting- pipeline spoke documents the END-TO-END FIVE-STAGE INFRASTRUCTURE PATH that SERIALISES the alignment-evaluation verdicts into the aggregate-report XML stream: (1) receiver-side report generation cadence (Gmail 24-hour UTC- aligned batch, Microsoft 365 hourly rolling window, Yahoo / Mail.ru 24-hour UTC-aligned batch — each emitting one record block per source_ip × From:-domain × alignment-outcome combination, where the policy_evaluated.dkim/spf fields ARE the per-row materialisation of the alignment computation this page documents), (2) publisher-side rua= addressing (the mailbox list whose external-domain entries require a _report._dmarc.example.com delegation per RFC 7489 §7.1), (3) mailbox-side IMAP / Microsoft Graph ingestion (imap_fetch.php / ImapFetcher / GraphFetcher polling + attachment unwrap), (4) parser-side XML-to-row decomposition (DmarcParser walking the RFC 7489 §7.2.1 XSD-validated record blocks and minting dmarc_records rows with the per-message policy_evaluated.dkim/spf verdict the alignment computation produced), (5) dashboard delivery (the empirical evidence the operator consumes for the Phase-2 advancement gate that requires ~99% legitimate-mail policy_evaluated=pass — the criterion the canonical DMARC-rollout ramp uses to advance from p=none → p=quarantine → p=reject). Read THIS alignment-mechanics page WITH the reporting-pipeline reference when an operator asks "where do the policy_evaluated verdicts come from": the answer is TWO-LAYERED — THIS page documents the per-message computation, the reporting- pipeline spoke documents the infrastructure path that serialises those computations into the daily XML stream the operator actually sees. Where THIS page documents the COMPUTATION-LAYER alignment-evaluation algorithm, the reporting-pipeline spoke documents the INFRASTRUCTURE-LAYER delivery path that empirically EXPOSES every alignment verdict on every message.
• Phishing protection — the ALIGNMENT-DENIES-DIRECT-DOMAIN-SPOOFING companion documenting the BROADER PHISHING- DEFENSE-IN-DEPTH STACK whose CORE PROTOCOL- LAYER MECHANISM is the identifier-alignment computation THIS page documents. Where THIS page documents alignment MECHANICS in protocol- precise terms (RFC 7489 §3.1 + §6.6.2 SPF-or-DKIM-authenticated-identifier-matches- From: rule, relaxed-via-PSL-orgdomain vs strict-via-FQDN evaluation, the adkim=s/aspf=s tag-strictness selection), the phishing- protection umbrella documents WHY the alignment computation matters operationally: alignment IS the protocol-layer mechanism that denies the single highest-volume phishing attack class — DIRECT-DOMAIN SPOOFING where an attacker forges the visible From: header to billing@yourbank.example and sends from attacker-controlled infrastructure. The phishing-protection spoke documents the FULL DEFENSE-IN-DEPTH STACK that surrounds alignment — DMARC at p=reject (alignment's policy- layer enforcement contract), SPF and DKIM (the alignment computation's two protocol- layer inputs), BIMI (the post-DMARC visual-indicator trust signal that ENCOURAGES legitimate-sender alignment adoption), MTA-STS + DANE (the transport- layer integrity controls that prevent downgrade-attack interception), secure-email-gateway anti-impersonation rules (the application-layer defenses against display-name spoofing, lookalike- domain abuse, and Reply-To injection that alignment CANNOT see), and user-awareness training (the last-mile defense for the residual surface no protocol-layer control can close). Read THIS page WITH the phishing-protection umbrella when an operator asks "why is alignment so important if we already train users to spot phishing": the answer is TWO- LAYERED — alignment closes the highest- volume DIRECT-DOMAIN attack class STRUCTURALLY (no user training required), and the residual surface (display-name, lookalike, Reply-To) requires the complementary defense layers the phishing- protection umbrella enumerates. Where THIS page documents the COMPUTATION, the phishing-protection spoke documents the COMPUTATION's ROLE in the broader defense stack.
• Email spoofing — the attack that identifier-alignment denies — the threat-model companion to this alignment-mechanics page. Where this page documents how identifier alignment is evaluated (the RFC 7489 §3.1 / §6.6.2 comparison of the SPF-authenticated envelope domain or DKIM-signed d= domain against the RFC 5322 From: domain under relaxed-via-PSL-orgdomain or strict-via-FQDN modes), the spoofing page documents what attacker techniques the alignment check structurally denies: an attacker forging the visible From: header to billing@yourbank.example while sending from an attacker-controlled domain whose SPF passes and DKIM signature verifies — the message passes SPF and DKIM evaluation in isolation but FAILS DMARC because neither authenticated identifier aligns with the visible From: domain. Alignment IS the anti-spoofing mechanism; this page documents how it works, the spoofing page documents which spoofing techniques it closes (exact-domain From-header forge, envelope-MAIL-FROM- vs-From split, subdomain abuse on unprotected children) and which it does not close (Display-Name spoofing, Punycode/IDN homograph, Reply-To substitution — all of which require complementary defenses BIMI / homograph normalisation / header-validation engines).
• How attackers bypass DMARC — the ALIGNMENT-ATTACKER-RESIDUAL companion to this alignment-mechanics reference. Where THIS page documents IDENTIFIER ALIGNMENT MECHANICS in protocol-precise terms (RFC 7489 §3.1 + §6.6.2 SPF-or-DKIM-authenticated- identifier-matches-From: rule, relaxed-via-PSL-orgdomain vs strict-via- FQDN evaluation, the adkim=s/aspf=s tag-strictness selection), the attacker-bypass spoke documents the STRICT-ALIGNMENT RESIDUAL ATTACK SURFACE that remains AFTER the operator publishes the most aggressive adkim=s; aspf=s combination. The strict-alignment residual is STRUCTURALLY-DIFFERENT from the relaxed-alignment residual because the attack vectors strict-alignment closes are PRECISELY THE SUBDOMAIN-MISMATCH AND ORGANIZATIONAL-DOMAIN-RELAXATION classes — every OTHER attack vector remains structurally invisible to alignment regardless of strictness: (i) display- name spoofing — alignment is evaluated against the From: address domain, not the From: display-name phrase, so an attacker sending from billing@unrelated-domain.example with display-name "Acme Bank Billing" passes alignment trivially (the display- name is not protocol-protected), (ii) lookalike-domain registration where the attacker authors valid DKIM / SPF / DMARC for acme‐bank.com (Unicode hyphen) or acmebank.co (TLD swap) and passes the LOOKALIKE'S alignment (alignment has no concept of "string similarity to a target brand"), (iii) Punycode / IDN homograph — IDN-encoded From-headers with homoglyph characters (Cyrillic 'а' for Latin 'a') pass alignment because the IDN-encoded ASCII representation (xn--cme-zfa.com) is what DMARC evaluates against the d= or MAIL-FROM identifier, (iv) Reply-To substitution + conversation-hijacking — alignment evaluates the message's identity-bearing headers at receipt, not the post-receipt reply-routing surface the attacker manipulates via Reply-To, (v) DKIM-replay attacks — when the attacker rebroadcasts a legitimately-DKIM-signed message to a victim distribution list, the signature still verifies and DKIM-alignment still passes (the canonicalised hash matches the d=-signed payload regardless of replay-route), (vi) DKIM-key compromise via short-key / expired-key / leaked-key — when the attacker has the private key, alignment passes by construction, (vii) ARC trust- chain abuse — when a forwarder injects ARC-Authentication-Results that the operator's receiving MTA accepts as an alignment-fail-to-pass override, (viii) third-party-vendor compromise where the attacker takes over a legitimately- aligned ESP-tenant and inherits the ESP's d= alignment authority. The attacker-bypass spoke is the load-bearing residual-attack-surface reference for any operator publishing adkim=s; aspf=s on the strength of THIS page's strict-alignment recommendation — strict alignment closes ONE PARTITION of the attack surface (subdomain-mismatch + organisational- domain-relaxation) and the attacker-bypass spoke catalogues every OTHER partition the operator's complementary-defence stack must address (BIMI for display-name trust anchoring, header-validation engines for Reply-To and From-header structural anomalies, anti-homograph normalisation in receiver pipelines, DKIM-key rotation discipline, ARC-Authentication-Results skeptical-evaluation policy).
• DMARC policy modes — p=none vs p=quarantine vs p=reject — the head-to-head COMPARISON of the three DMARC enforcement values. Read this once alignment is understood: a message that fails BOTH SPF and DKIM alignment is subjected to the published p= disposition (no-op at p=none, spam folder at p=quarantine, bounced 550 at p=reject) — the downstream consequence of every alignment failure documented on this page.
• DMARC explained — the central DMARC primer covering rollout strategy, aggregate-report XML schema, and mailing-list / forwarding interactions.
• SPF explained — Sender Policy Framework (RFC 7208). Companion standard whose envelope-domain result feeds DMARC's SPF-alignment evaluation.
• Why SPF alone is insufficient — the alignment-as-mandatory-second-layer companion to this DMARC-alignment-mechanics reference — the WHY-SPF-ALONE-CANNOT-PROTECT-A-DOMAIN companion documenting the four structural failure modes (forwarding-strip, mailing-list-rewrite, envelope-vs-header- domain decoupling, p=none operator inaction) that motivate the identifier-alignment evaluation THIS page documents. Where THIS page documents alignment MECHANICS in protocol-precise terms (the aspf=r-vs-aspf=s relaxed-vs-strict mode semantics, the envelope-MAIL-FROM-domain-vs-RFC5322-From- domain match per RFC 7489 §3.1.2, the organisational-domain inheritance per RFC 7489 §3.2), the why-SPF-alone spoke documents the OPERATIONAL MOTIVATION for layering DKIM alignment over SPF alignment in the first place: SPF alone fails on forwarding (envelope rewrite breaks the ip4 / include match), fails on mailing- list redistribution (List-Server-Manager- Forge envelope rewrites preserve the original From: but break SPF), fails on envelope-vs-header-domain decoupling (where envelope MAIL FROM points at a different organisational domain than the From: header — the legitimate ESP-tenant pattern), and fails operationally when the published policy is p=none (the receiver-side enforcement contract is no-op so SPF-fail messages still reach inboxes). Read the why-SPF-alone spoke WITH this alignment-mechanics page when an operator asks why DMARC alignment requires TWO authentication inputs (SPF and DKIM) rather than a single one — the answer is the four-failure-mode catalogue the why-SPF-alone spoke documents, all of which the DKIM-alignment branch of the alignment computation this page documents compensates for.
• SPF for Google Workspace — the DMARC-SPF-ALIGNMENT-EVALUATION- MECHANICS-FOR-WORKSPACE-TENANT-OUTBOUND- MAIL-WITH-_SPF.GOOGLE.COM-INCLUDE-BASELINE- AS-ENVELOPE-MAIL-FROM-DOMAIN-AUTHORISER companion to this DMARC-alignment operational deep dive. Where THIS page documents the DMARC-alignment evaluation algorithm (the aspf=r-vs-aspf=s relaxed-vs-strict mode semantics, the envelope-MAIL-FROM-domain-vs-RFC5322- From-domain match per RFC 7489 §3.1.2, the organisational-domain inheritance per RFC 7489 §3.2, the SPF-aligned-pass evaluation produced by either an organisational-domain match (relaxed aspf) or an exact-domain match (strict aspf)), the SPF-for-Workspace spoke is the WORKSPACE-TENANT-SPF-AUTHORING- CONSUMER-OF-DMARC-ALIGNMENT companion documenting the SPF-record authoring discipline that determines whether Workspace-tenant outbound mail produces the SPF-aligned-pass verdict the DMARC alignment evaluation on THIS page consumes. The four-axis DMARC-ALIGNMENT- VS-WORKSPACE-SPF comparison exposes the structurally-distinct WORKSPACE-ENVELOPE- MAIL-FROM-AUTHORISATION roles: (i) Workspace-tenant outbound mail uses the Workspace organisation-domain as the default envelope-MAIL-FROM domain — the envelope-MAIL-FROM (Return-Path) for Workspace-tenant outbound is by default <sender-localpart>@<tenant-domain>, producing an exact-domain match against the From-header organisation domain that achieves SPF-aligned-pass under either aspf=r or aspf=s alignment mode this page documents; (ii) Workspace SMTP-relay-from-outside-Workspace introduces a divergent envelope-MAIL- FROM domain that requires alignment- mode coordination — Workspace tenants using SMTP-relay for outbound from on-prem / partner / vendor infrastructure that uses a different envelope-MAIL-FROM domain (e.g. bounces.<tenant>.com bounce subdomain) require the SPF-for- Workspace spoke's envelope-MAIL-FROM coordination discipline to ensure the relaxed-aspf alignment mode this page documents produces aligned-pass; (iii) Workspace mailing-list and Google Groups integration produces an envelope-MAIL-FROM rewriting pattern that breaks both SPF-aligned-pass and DKIM-aligned-pass — the SPF-for-Workspace spoke documents the canonical Google Groups intermediary envelope-rewriting pattern that the DMARC alignment evaluation on THIS page surfaces as a SPF-aligned-fail row population; (iv) Workspace- tenant ~all-vs--all qualifier choice determines whether unauthorised-IP outbound from the Workspace tenant's organisation domain produces SPF-softfail (treated as alignment-fail under DMARC's binary aligned-pass/aligned- fail evaluation) or SPF-hardfail (same DMARC consequence but with firmer envelope-MAIL-FROM authorisation signal) — the SPF-for-Workspace spoke documents the qualifier-selection decision tree the DMARC alignment evaluation on THIS page consumes. Read the SPF-for-Workspace spoke alongside this DMARC alignment reference when the operator is on Google Workspace — the spoke is the AUTHORITATIVE Workspace-tenant SPF-authoring prerequisite that determines whether the SPF-side identifier-alignment decision THIS page documents can even reach aligned-pass for a Workspace-tenant outbound envelope.
• SPF mechanisms explained (per-directive reference) — the per-mechanism deep dive on the SPF directives whose evaluation produces the auth_results/spf verdict THIS page feeds into the SPF-side identifier- alignment decision. Where the SPF-explained pillar above introduces the protocol at a conceptual level and THIS page documents how the SPF-authenticated MAIL FROM domain is compared against the From:- header domain for the DMARC SPF-alignment decision (governed by the aspf=r relaxed-mode default vs aspf=s strict-mode), the SPF- mechanisms-explained spoke documents the per-directive grammar that determines WHICH sending IPs pass MAIL FROM authentication in the first place: include:<domain> (delegated evaluation of another domain's SPF tree), ip4: / ip6: (literal CIDR ranges), a / a:<domain> / mx / mx:<domain> (DNS-resolved address sets), ptr (deprecated reverse-DNS lookup), exists:<domain> (macro-driven existence check), all (fall-through default), and the redirect=<domain> modifier. Read this when an aggregate-report row shows auth_results/spf/result=pass but spf/domain differs from the From:-header organisational domain — knowing WHICH mechanism produced the SPF pass clarifies whether the sender is a delegated SaaS sender (typical include: on a vendor-published SPF macro) or a directly-controlled IP range (ip4:) and informs the alignment-failure remediation path.
• include: vs ip4:/ip6: vs a: vs mx: SPF mechanism choice — the DMARC-aspf-ALIGNMENT-EVALUATION- CONSUMER-OF-PER-MECHANISM-CHOICE companion to this DMARC-alignment-mechanics reference. Where THIS page documents the receiver-side aspf=r relaxed- mode and aspf=s strict-mode evaluation rules comparing the SPF- authenticated envelope MAIL FROM domain against the From:-header organizational domain, the include-vs-ip4-vs-a-vs-mx spoke is the PER-MECHANISM-CHOICE- DECISION-MATRIX companion documenting WHICH mechanism the publisher SHOULD author for each per-sender-population and HOW that choice propagates through the receiver-side alignment evaluation THIS page documents. The PER-MECHANISM- CHOICE-VS-ASPF-ALIGNMENT-CONSUMER cross- reference establishes FOUR structurally- distinct dimensions where the spoke's per-mechanism reference is the load- bearing decision input for the alignment verdict THIS page documents: (i) include: cascade producing SPF pass via delegated evaluation — alignment computed against envelope MAIL FROM not include-publisher domain — the spoke documents the include-cascade semantics where the receiver resolves the include:<vendor-domain> token's recursive SPF tree to authorize the sending IP; THIS page documents that the resulting SPF pass produces spf.domain = envelope MAIL FROM domain (NOT the vendor's include- publisher domain) for the alignment evaluator — for SaaS-sender deployments the receiver computes aspf-alignment against the publisher's envelope MAIL FROM, which is the publisher's organizationally-controlled MAIL FROM (custom Return-Path subdomain delegation) regardless of which vendor's include- cascade authorized the sending IP — the spoke's per-include-platform reference clarifies when the publisher needs custom Return-Path delegation to make aspf-alignment pass for include- authorized senders; (ii) ip4: + ip6: literal CIDR producing SPF pass via direct IP match — alignment computed against the envelope MAIL FROM domain, decoupled from receiver-side mechanism inspection — the spoke documents the ip4:/ip6: literal CIDR semantics where the receiver matches the message's envelope-source IP against the published CIDR list and emits spf=pass; for the alignment evaluator the resulting spf.domain is the envelope MAIL FROM domain regardless of how the SPF pass was produced — for the publisher's authoring workflow this means ip4:/ip6: literal choice EQUIVALENTLY produces aspf- aligned messages to include: cascade choice when the envelope MAIL FROM domain is the protected domain — the spoke's per-mechanism reference clarifies when ip4:/ip6: literal is the budget-efficient choice that produces the SAME alignment outcome as include: cascade for publisher- owned infrastructure; (iii) a: mechanism producing SPF pass via A- record-resolved IP match — A-record- host is NOT the alignment input, envelope MAIL FROM is — the spoke documents the a: mechanism semantics where the receiver resolves a:<mail-host> to an IP and matches against the envelope- source IP; for the alignment evaluator the resulting spf.domain is STILL the envelope MAIL FROM domain (NOT the a: target hostname) — the publisher's choice of a: vs ip4: literal does NOT affect aspf-alignment outcome; the spoke's per-mechanism reference clarifies the a: mechanism is a SHORTHAND-CONVENIENCE that lets the publisher avoid hardcoding the IP when the mail-host's A record IS the egress IP, without changing the alignment computation THIS page documents; (iv) mx: mechanism producing SPF pass via MX- record-resolved host-list IP match — MX hostname is NOT the alignment input, envelope MAIL FROM is — the spoke documents the mx: mechanism semantics where the receiver resolves mx:<domain> to the MX-record-host-list and matches each MX host's resolved IP against the envelope-source IP; for the alignment evaluator the resulting spf.domain is STILL the envelope MAIL FROM domain (NOT any MX host's domain) — the publisher's choice of mx: mechanism for self-receive-and-send domain topologies is an authorization- delegation convenience that does NOT change the alignment computation, but the spoke documents the per-receiver MX-rotation-cache-staleness false- fail edge cases where mx: produces spf=temperror or spf=permerror that STRUCTURALLY DEFEATS the alignment evaluation THIS page documents (per the spf_permerror_vs_temperror cross-reference). Read the include- vs-ip4-vs-a-vs-mx spoke alongside this DMARC-alignment-mechanics reference when authoring the publisher's SPF record to coordinate the per-mechanism choice with the alignment-pass outcome the receiver computes — the spoke is the canonical per-mechanism-choice decision-matrix reference whose four mechanism-type dimensions each propagate structurally-distinctly through the aspf alignment evaluation THIS page is the receiver-side reference for.
• SPF qualifiers explained — the per-character prefix grammar driving the SPF-result verdict THIS page consumes — the per-qualifier deep dive on the single-character prefix grammar (+ Pass / - Fail / ~ SoftFail / ? Neutral) that determines WHICH SPF result a receiver returns when an SPF mechanism matches, and therefore whether SPF feeds an auth_results/spf/result=pass verdict into THIS page's DMARC SPF-alignment decision in the first place. Where the SPF- mechanisms-explained spoke above documents the per-directive grammar deciding WHICH IPs match, the qualifiers spoke documents the per-prefix grammar deciding WHAT VERDICT the match produces. The DMARC SPF-alignment check only evaluates when the SPF result is Pass — a SoftFail (~ match), Neutral (? match), or Fail (- match) all short-circuit the alignment check because there is no SPF-pass identifier to align in the first place. Read the qualifiers spoke when an aggregate-report row shows auth_results/spf/result=softfail or =neutral and the operator cannot understand why DMARC marks the message policy_evaluated/spf=fail despite the SPF record syntactically including the sending IP — the tail-qualifier ~all / ?all / -all choice and any per-mechanism prefix-qualifier choice (?include: / ~include: for low-trust partner trees) directly determines the SPF-pass-or-not verdict feeding the SPF-alignment evaluation.
• SPF DNS record syntax (byte-level TXT-record reference) — the SPF-TXT-RECORD-BYTE-LEVEL- PUBLICATION-PREREQUISITE companion to this DMARC alignment reference. Where THIS page documents the SPF-AUTHENTICATED-MAIL-FROM-DOMAIN-VS- FROM-HEADER-ORGANISATIONAL-DOMAIN alignment evaluation governed by the aspf=r relaxed-mode default vs aspf=s strict-mode tag, the SPF-dns-syntax spoke is the BYTE-LEVEL-TXT-RECORD-PUBLICATION upstream prerequisite documenting the canonical v=spf1 … TXT-record byte layout the receiver retrieves and parses BEFORE any identifier-alignment evaluation can even reach the SPF-pass-or-not verdict this page feeds into the DMARC SPF- alignment decision: (i) the RFC 7208 §3 single-record-per-domain constraint (only ONE v=spf1 TXT record may be published at any given domain label — duplicate v=spf1 records produce spf=permerror at every receiver, killing the SPF-alignment check before it begins), (ii) the multi-string concatenation form ("v=spf1 " "include:…") for records exceeding the 255-byte single-string TXT limit (the RFC 1035 / RFC 7208 byte-string concatenation contract that some registrar UIs implement incorrectly, producing a record-publication artifact where the recipient sees a literal "v=spf1 " "include:…" with embedded quote characters instead of the concatenated record body — breaks SPF parsing entirely, drops the SPF result to permerror, and prevents the SPF-alignment evaluation), (iii) the 512-byte UDP-DNS-response soft limit and the 4096-byte EDNS0-DNS- response upper bound that constrain practical SPF-record total byte budget, (iv) the v=spf1 mechanisms… qualifier-all ordering grammar (the first-match-wins evaluator semantics means the operator must place explicit- pass mechanisms BEFORE the fallthrough all mechanism — incorrect ordering can produce a Pass verdict for a sending IP that should have failed, feeding a misleading SPF-aligned-pass into DMARC), (v) the redirect= modifier vs include: mechanism distinction (redirect REPLACES the current record's evaluation entirely; include EVALUATES the target subtree then returns to continue this record — a structural distinction that determines WHICH domain's SPF-published envelope-MAIL-FROM authorisation produces the SPF-pass-domain feeding this page's identifier-alignment evaluation). Read the SPF-dns-syntax spoke when the operator is debugging SPF-alignment failures that resolve to SPF-RECORD-PUBLICATION-LEVEL faults (duplicate-record permerror, multi- string concatenation breakage, record- ordering precedence errors, redirect-vs-include semantic confusion) — the spoke is the byte-level TXT-record-publication reference upstream of every SPF- alignment evaluation THIS page documents.
• MX records explained — the ORGANISATIONAL-DOMAIN-MX-RR-AS- RELAXED-MODE-IDENTIFIER-COTENANT- RESOLUTION-INPUT companion to this DMARC identifier-alignment reference, and the DNS-RR-LAYER substrate for the organisational-domain identifier-equivalence computation THIS page documents the receiver-side alignment-evaluation consumer-side of. Where THIS page documents the RFC 7489 §3.1 / §6.6.2 identifier- alignment evaluation — the per-message decision computed at every receiver-side DMARC verifier deriving "is the SPF- authenticated MAIL FROM domain in the same organisational-domain family as the From:-header organisational domain (with aspf=r relaxed-mode default) or byte-identical to it (with aspf=s strict-mode)" plus the structurally-parallel "is the DKIM- signature d= domain in the same organisational-domain family (with adkim=r) or byte-identical (with adkim=s)" — the mx-records spoke documents the RFC 1035 §3.3.9 MX resource-record syntax governing how the operator's MX-RR publication topology REVEALS the cotenant / consolidation / segregation TOPOLOGY of the organisational-domain identifier-space THIS page presupposes during alignment evaluation. Concretely: (i) when example.com publishes MX RRs for mail.example.com and mail2.example.com on the organisational domain, those MX-RR targets identify the cotenant mail servers operating WITHIN the organisational-domain identifier family whose envelope-MAIL-FROM and DKIM- signing-domain values can take ANY name under the organisational-domain umbrella AND still align under relaxed mode (aspf=r / adkim=r); (ii) when a subdomain marketing.example.com publishes its OWN MX RRs pointing to a DIFFERENT mail-server cluster, the MX-RR topology REVEALS the subdomain operates an INDEPENDENT mail-egress identity that still relaxed-aligns to the organisational domain UNLESS the publisher uses sp= subdomain-specific policy with aspf=s / adkim=s; (iii) the "null MX" pattern (example.com IN MX 0 . per RFC 7505) declaring the domain accepts no mail establishes that any envelope-MAIL-FROM with that domain is necessarily fraudulent — relevant to alignment evaluation because an organisa- tional domain with null MX should not be sending mail and any apparent SPF-pass for that domain warrants forensic investigation. Pair this page (the DMARC identifier-alignment receiver-side evaluation reference) with the mx-records spoke (the DNS-RR-LAYER substrate for the organisational-domain identifier- topology revelation) when auditing the publisher-side MX-RR publication discipline whose topology determines the alignment- evaluation surface THIS page documents.
• Reverse DNS (PTR) and FCrDNS explained — the PER-SOURCE-IP-RDNS-AND-FCrDNS- AS-PER-IP-IDENTITY-DIMENSION-COMPLEMENTING- PER-MESSAGE-DMARC-IDENTIFIER-ALIGNMENT- EVALUATION companion to this DMARC identifier- alignment mechanics reference. Where THIS page documents the RFC 7489 §3.1 / §6.6.2 per-message identifier-alignment evaluation — the per-DOMAIN identifier match between the SPF-authenticated envelope-MAIL-FROM domain AND the From:-header organisational domain (gated by aspf=r / aspf=s) plus the structurally- parallel per-DOMAIN identifier match between the DKIM-signature d= domain AND the From:-header organisational domain (gated by adkim=r / adkim=s) — the reverse-DNS / PTR / FCrDNS spoke documents the per-source-IP rDNS publication discipline whose forward-confirmed PTR-then-A-lookup round-trip is the receiver-side per-IP- IDENTITY attribution dimension that operates at the PER-CONNECTION layer ORTHOGONAL TO the per-message per-domain identifier- alignment evaluation THIS page documents at FOUR per-DMARC-alignment-vs-per-IP-rDNS- attribution coupling dimensions: (i) SPF-aligned-pass at the per-domain layer vs FCrDNS-pass at the per-IP layer as TWO INDEPENDENT receiver-side gates — the SPF-aligned-pass outcome THIS page evaluates depends on the envelope-MAIL-FROM domain authorising the per-source-IP via published SPF mechanisms (and the SPF-domain sharing an organisational suffix with the From:-header domain under aspf=r); the per-source-IP FCrDNS-pass outcome is a SEPARATE per-IP identity-attribution gate the receiver runs whose PTR resolves to a hostname whose forward A-lookup returns the same IP — a per-source-IP SPF-aligned-pass with FCrDNS-fail still leaves the receiver-side per-connection legitimacy-evaluation flagged regardless of the per-message DMARC verdict; (ii) per-source-IP rDNS hostname as receiver-side per-IP cohort-attribution input feeding per-message dispositioning — when the per-source-IP PTR resolves to a known forwarder / ESP / mailing-list hostname, the receiver-side per-message disposition decision (alongside the p=-tag the DMARC publisher specifies for non-aligned messages) is informed by the per-IP cohort the rDNS hostname attests to — the per-message DMARC=fail row from a known-forwarder PTR is operationally distinct from the same DMARC=fail row from an attacker-PTR-NXDOMAIN IP; (iii) shared-IP-pool per-tenant rDNS attribution under DMARC=fail spike triage — when a multi-tenant publisher (cPanel-shared-hosting, marketing- ESP, transactional-ESP) sees a DMARC=fail rate spike attributed to the shared-IP-pool egress, the per-source-IP PTR resolving to a hosting-vendor-canonical hostname identifies the SHARED pool — the per-tenant attribution boundary then depends on cross-referencing the per-message envelope-MAIL-FROM and DKIM- d= values against the per-tenant publisher identity the DMARC verdict alignment- evaluated; (iv) per-IP rDNS-publication discipline as publisher-side per-egress-IP legitimacy-signal authoring prerequisite for DMARC enforcement — operators committing to DMARC p=quarantine or p=reject enforcement use the rDNS spoke's per-IP PTR + FCrDNS publication checklist to ensure every publisher-controlled egress IP carries forward-confirmable rDNS, removing the FCrDNS-fail false-positive class from receiver-side per-connection legitimacy evaluation that would otherwise compound with DMARC verdict-evaluation under enforcement policy modes. Read the reverse-DNS / PTR / FCrDNS spoke when designing the per-egress-IP rDNS publication discipline whose forward-confirmed PTR-then-A round-trip is the per-IP-identity surface the receiver-side per-connection legitimacy-attribution gates on ALONGSIDE the per-message per-domain identifier-alignment evaluation THIS page documents.
• DKIM explained — DomainKeys Identified Mail (RFC 6376). Companion standard whose d= signing-domain feeds DMARC's DKIM-alignment evaluation.
• DKIM-Signature header anatomy (byte-level field reference) — the byte-level reference for the DKIM-Signature: header THIS page extracts the d= tag from when evaluating DKIM-side alignment. Where the DKIM-explained pillar above introduces the protocol at a conceptual level and THIS page documents how the d= tag is compared against the From:-header domain for the DMARC DKIM-alignment decision, the DKIM-signatures-explained spoke documents the FULL field grammar of the DKIM-Signature header byte by byte: the v=1 version tag floor (case sensitive), a=rsa-sha256 / a=ed25519-sha256 algorithm selection, the c=relaxed/relaxed vs c=simple/simple canonicalisation modes (different whitespace-collapsing rules between header-canonicalisation and body-canonicalisation produce different signature inputs — the most-confused source of DKIM-pass-fail variance under forwarding), the s= selector that names the <selector>._domainkey.<d-tag> DNS TXT record holding the public key, the bh= body hash and b= signature value, and the h= signed-headers list that enumerates which headers the signature covers (RFC 6376 §3.5 recommends From: To: Subject: Date: Message-ID: at minimum; omission of From: from h= is signed-DKIM-with-no- From-protection — a defect mode an operator only catches by reading the signature byte by byte). Read this when the DMARC aggregate report's <auth_results><dkim> section reports a domain that is unexpected (the verbatim d= tag value from the message's DKIM-Signature header) and you need to map that back to which signing key on the sending infrastructure produced the signature — the DKIM-signatures spoke documents the structural mapping from header byte-pattern back to signing key.
• DKIM alignment with DMARC (the DKIM-specific deep dive) — the DKIM-focused companion to this SPF-and-DKIM-together alignment page. Where THIS page documents the identifier-alignment evaluation for the FULL DMARC pipeline (both SPF envelope- domain alignment AND DKIM d=-tag alignment running in parallel, with the DMARC pass-if-either rule per RFC 7489 §6.6.2), the dedicated DKIM-alignment-with-DMARC page focuses narrowly on the DKIM half: the DKIM-Signature d= tag extraction, the From:-header domain extraction, the adkim=r (relaxed: organisational-domain match via PSL) vs adkim=s (strict: FQDN-equality) policy knob and the receiver-side decision tree, the canonical DKIM-pass-but-DMARC-fail provenance patterns each mode produces (M365 d=<tenant>.onmicrosoft.com gotcha, Workspace d=<domain>.gappssmtp.com gotcha, ESP shared-domain signing patterns at SendGrid / Mailchimp / Postmark / Mandrill / SES that ship DKIM signed with the ESP's domain unless authenticated-domain DKIM is CNAME-delegated), and the mitigation sequence for each pattern. Read this page once you understand the joint SPF + DKIM alignment rules on the current page and need a DKIM-only-focused diagnosis path for an aggregate-report payload that shows dkim=pass + dmarc=fail on rows from a known authenticated sender.
• DMARC for transactional email — the TRANSACTIONAL-ESP-AS-ALIGNMENT- EVALUATION-EDGE-CASE-FACTORY companion to THIS DMARC alignment-mechanics reference. Where THIS page documents the alignment computation per RFC 7489 §3.1 + §6.6.2 (SPF-or-DKIM-authenticated-identifier- matches-From: rule, relaxed-via-PSL-orgdomain vs strict-via-FQDN evaluation, the adkim=s / aspf=s tag-strictness selection, the policy_evaluated.dkim / policy_evaluated.spf per-message verdict), the dmarc_for_transactional_email spoke is the PER-TRANSACTIONAL-ESP ALIGNMENT-EDGE-CASE COMPANION documenting how each transactional ESP (SendGrid / Mailgun / Amazon SES / Postmark / Mailjet / SparkPost / Resend / Loops) physically SHAPES the alignment-evaluation inputs at the publisher-side signing point: (i) ESP-default d= service- domain anti-pattern — the canonical DKIM- aligned-pass-but-DMARC-unaligned failure-class amplifier — SendGrid's d=sendgrid.net, Mailgun's d=mailgun.org, Amazon SES's d=amazonses.com, Postmark's d=pm-mta.com all produce dkim=pass verdicts with the WRONG d= for DMARC alignment against the customer's From: organisational domain; (ii) tenant- managed DKIM CNAME-delegation as the canonical alignment-remediation path — every major transactional ESP offers a per-tenant CNAME-delegated DKIM mode that republishes the signing-side d= to the tenant's organisational domain; the CNAME-chase-and-TXT-fetch infrastructure is the operational mechanism by which a transactional ESP's alignment-remediation path crosses from "service-domain d=" to "tenant-domain d="; (iii) per-stream sub-domain segmentation as alignment-PSL- boundary discipline — transactional senders typically isolate transactional traffic under txn.example.com / notifications.example.com / mail.example.com sub-domains whose Public Suffix List organisational- domain extraction lands at example.com under adkim=r relaxed mode; (iv) SPF-side relay-IP authorisation gotcha at shared-IP-pool ESPs — shared-IP-pool ESPs require customer SPF records to include: the ESP's helper-record, and the SPF-side alignment path consumes the customer's envelope MAIL FROM domain (not the ESP's amazonses.com Return-Path) — a frequent operator misconfiguration on Amazon SES "easy DKIM" deployments that defaults to a service-managed Return-Path domain. Read the transactional-email spoke when an operator on a transactional ESP reports unexplained dkim=pass+DMARC-unaligned or spf=pass+DMARC-unaligned verdicts that THIS page's protocol-level alignment-mechanics reference catalogues as a failure-class but does NOT attribute to the operationally-distinct ESP-side configuration mechanisms.
• DKIM key rotation — the DKIM-D-DOMAIN-IDENTIFIER-ALIGNMENT- MUST-BE-MAINTAINED-ACROSS-PUBLISHER-SIDE- ROTATION-CUTOVER-WINDOW companion to this DMARC alignment-mechanics reference. Where THIS page documents the DKIM-side identifier-alignment evaluation (the DKIM-Signature d= tag must match the From: header author-domain per RFC 7489 §3.1.1 strict or §3.1.2 relaxed alignment), the key-rotation spoke documents FOUR rotation-vs- alignment-preservation dimensions: (i) selector-only rotation preserves d= identity — the canonical publisher-controlled rotation pattern rotates the s= selector token (s1 → s2) while leaving the d= domain token unchanged, so DKIM-side identifier alignment evaluation continues to pass across the rotation cutover window — the rotation spoke documents the canonical operator discipline that protects DKIM-side identifier alignment across rotation events by NEVER changing the d= domain token in the rotation procedure; (ii) multi- stream publisher rotation coordination — when separate streams (corporate + transactional + marketing) have DIFFERENT d= domain defaults (apex-domain vs subdomain-per- stream), per-stream rotation coordination preserves per-stream alignment independently — the rotation spoke documents the per-stream rotation-coordination discipline operators with heterogeneous per-stream d=-domain assignment must execute to preserve per-stream identifier-alignment evaluation across the cluster-wide rotation event; (iii) publisher-initiated d=- domain CHANGE event (rare, but operationally-distinct from selector rotation) BREAKS identifier alignment unless the From: header author-domain is changed in lockstep — the rotation spoke documents the operationally-distinct edge case where the publisher chooses to migrate from d=oldbrand.com to d=newbrand.com (post- rebrand, post-acquisition, post- subdomain-flattening event) and the identifier-alignment evaluation requires BOTH the From: header author-domain AND the DKIM-Signature d= tag to be updated in lockstep, with the per-publisher migration-coordination across DNS publish + signer-config update + From-header authoring pipelines; (iv) alignment-strict (s) vs alignment-relaxed (r) mode interaction with rotation — strict-mode publishers cannot tolerate ANY d=-vs- From-header subdomain divergence, while relaxed-mode publishers can tolerate organizational-domain-matching subdomain divergence per RFC 7489 §3.1.2 — the rotation spoke documents the per-publisher rotation-vs-alignment- mode coordination where strict-mode publishers must execute rotation events with FINER per-stream d=- domain precision than relaxed-mode publishers (strict-mode forbids the relaxed-mode shortcut of consolidating per-stream rotation into a single organizational-domain-level d=- token). Read the rotation spoke when planning a DKIM-key-rotation event on a domain whose DMARC enforcement depends on DKIM-side identifier- alignment (which is most published DMARC deployments, since DKIM alignment is the more-robust half of the DMARC pass-if-either rule) — the spoke is the authoritative per-rotation operational reference for the DKIM- rotation-meets-DMARC-identifier- alignment cross-cluster boundary.
• DMARC for SaaS senders — the MULTI-TENANT-ESP-AS-ALIGNMENT- EVALUATION-CROSS-TENANT-COORDINATION- FACTORY companion to THIS DMARC alignment-mechanics reference. Where THIS page documents the protocol-level alignment computation per RFC 7489 §3.1 + §6.6.2 and the transactional-ESP spoke immediately above documents the per- transactional-ESP alignment-edge-case catalogue, the saas-senders spoke is the MULTI-TENANT-PLATFORM SIBLING documenting the OPERATIONAL-COORDINATION engineering whereby SaaS / marketing-automation / CRM / membership / e-commerce / customer- engagement platforms (Mailchimp, Marketo, HubSpot, Pardot, Klaviyo, Constant Contact, Salesforce Marketing Cloud, Shopify, BigCommerce) physically shape the alignment-evaluation inputs at the customer-domain-authority-boundary coordination surface — distinct from the transactional-ESP-deep-dive above by operational class (transactional ESPs SHIP message-throughput infrastructure; SaaS multi-tenant platforms ship customer-engagement-workflow infrastructure that EMITS mail as a side-effect of platform actions). Four operationally- distinct multi-tenant-platform alignment- coordination axes the spoke documents that THIS page's alignment-mechanics reference individually consumes but never collectively attributes to the multi- tenant-platform-specific authority-boundary configuration: (i) per-customer sub-tenant CNAME-delegated DKIM signing- zone discipline — the operational engineering whereby the platform publishes per-customer signing-key zones (k1._domainkey.customer.com → k1.customer-zone.platform.example) and the customer publishes CNAME records in their own apex zone delegating the signing-key lookup; the alignment computation THIS page documents consequently SEES a d=customer.com signing-domain that aligns with the From:-domain even though the platform operationally holds the private-key material; (ii) customer-domain SPF-include token coordination — the operational engineering whereby the customer adds the platform's published include token (include:_spf.mailchimp.com, include:spf.marketo.com, include:_spf.klaviyo.com, etc.) at their own apex SPF record's head; the alignment computation THIS page documents consequently SEES an spf=pass on the platform's shared-tenant pool IP because the customer's authority-boundary SPF record authorises the platform-operator IP-pool token expansion, even though the platform operator (NOT the customer) physically operates the egress IPs; (iii) cross-tenant pool-IP attribution challenge in RUA aggregate-report rows — the operational engineering gap whereby the platform's shared-tenant pool IP shows up in the customer's RUA aggregate report's source_ip column with no sub-tenant differentiation, making per-customer deliverability- problem attribution structurally impossible without platform-side per-tenant sender-zone separation — the alignment-evaluation outputs THIS page documents do NOT carry sub-tenant identity at the aggregate-report row level; and (iv) third-party- sender abuse via shared-tenant pool compromise — the residual- attack-surface engineering whereby an attacker signs up for the platform as a legitimate sub-tenant and weaponises the platform's customer-domain SPF authorisation + shared-tenant pool IP to send DMARC-aligned mail from the customer's domain perspective (bypass class (vii) of the attacker-bypass spoke); the alignment computation THIS page documents consequently PASSES at the customer-domain protocol layer because the platform-operator infrastructure has authoritatively- signed the attacker's mail under the platform's master-tenant identity. Read the saas-senders spoke when an operator on a SaaS / marketing-automation / CRM platform reports unexplained alignment- edge cases or cross-tenant attribution gaps that THIS page's protocol-level alignment-mechanics reference catalogues as a failure-class or attribution-class but does NOT attribute to the operationally-distinct multi-tenant- platform authority-boundary coordination engineering.
• DKIM for Google Workspace — the WORKSPACE-TENANT-DKIM-AS-ALIGNMENT- INPUT companion documenting the canonical case where the DKIM half of the DMARC identifier-alignment evaluation documented on THIS page receives its per-message d=-tag value directly from the Workspace tenant's google-selector signing infrastructure. Documents FOUR Workspace-parallel alignment-input dimensions (Workspace's per-author-domain DKIM signature produces d=<author-domain> s=google which the receiver-side DMARC evaluator extracts as the candidate-aligned d=-tag value AGAINST the Header-From: domain — the Workspace tenant is the SOURCE-OF-TRUTH for the per-message DKIM d=-tag value the alignment evaluator consumes; Workspace's tenant- managed signing publishes d=<customer-domain> rather than d=workspace.google.com — meaning the Workspace tenant's signature is INTRINSICALLY aligned with the customer's author-domain under BOTH adkim=r relaxed AND adkim=s strict alignment modes (because the d=<customer-domain> value EXACTLY matches the Header-From: domain at the organizational AND strict-equality level); Workspace tenants whose author-domain ALSO routes mail through third-party SaaS senders (Mailchimp, SendGrid, Marketo, HubSpot) experience per-message DKIM alignment outcomes that DIVERGE per-path — Workspace- signed messages produce d=<author-domain> s=google intrinsically aligned, while SaaS- signed messages either produce d=<saas-platform>.com s=esp requiring per-customer- CNAME-delegation to achieve alignment, OR produce d=<author-domain> s=esp via per-customer CNAME delegation already aligned; the Workspace tenant's Admin-Console- managed DKIM-key-rotation directly affects per-message DKIM-pass-rate which IS the DKIM-half of the per- message DMARC pass-or-fail verdict — a Workspace operator who rotates the google-selector public key without proper overlap window observes a per-message DKIM-fail spike that contributes to per-message DMARC-fail verdicts which the publisher's RUA aggregate reports surface). Read the Workspace spoke alongside this alignment reference when authoring Workspace-tenant DMARC deployments — the spoke documents the per-tenant Admin Console DKIM-key-generation workflow, the google-selector TXT- record publication procedure, and the per-tenant key-rotation discipline that together produce the per-message d=-tag value the alignment evaluator consumes as the DKIM half of the alignment evaluation THIS page documents.
• DKIM for Microsoft 365 — the M365-TENANT-DKIM-AT-selector1-AND- selector2-DOMAINKEY-PUBLICATION-PRODUCES- DKIM-EQUALS-AUTHOR-DOMAIN-D-EQUALS-TAG- VALUE-AS-THE-DKIM-HALF-OF-THE-IDENTIFIER- ALIGNMENT-EVALUATION companion reference. Where THIS page documents the DMARC identifier-alignment evaluation mechanics (the adkim=r organisational- domain match vs adkim=s FQDN match between the DKIM-Signature d=-tag and the RFC 5322 From: author-domain; the disjunction with SPF-alignment to produce the DMARC alignment-pass verdict), the dkim_for_microsoft_365 spoke is the M365-TENANT-DKIM-PUBLICATION canonical reference documenting the FOUR M365-tenant- specific DKIM-publication-vs-alignment- input coupling dimensions every M365- tenant DMARC deployment depends on: (i) selector1._domainkey.< d> + selector2._domainkey. <d> dual-selector M365 CNAME-pointer publication discipline — M365 publishes DKIM keys via per-tenant CNAMEs pointing at the Microsoft-managed selector1-<tenant>._domainkey.<tenant>. onmicrosoft.com / selector2-<tenant>. _domainkey.<tenant>.onmicrosoft.com host- names, and the per-message DKIM-Signature d=-tag value materialises as the M365-tenant primary domain at the EOP outbound DKIM-signer at signing time — without the per-tenant selector1/selector2 CNAME publication this spoke documents, EOP emits messages WITHOUT a DKIM-Signature header (the dkim=none Authentication- Results verdict that defeats the DKIM- alignment-pass evaluation THIS page documents); (ii) M365 default d=<tenant>.onmicrosoft.com emission vs operator-side protected-domain DKIM-enablement discipline — M365's default out-of-box DKIM-Signature emission uses the <tenant>.onmicrosoft.com domain as the d=- tag value (NOT the protected vanity domain), which DEFEATS the adkim=r relaxed-mode alignment evaluation THIS page documents because the per-message <tenant>.onmicrosoft.com d=-tag never matches the protected vanity From-domain at the organisational-domain boundary; the operator MUST enable DKIM-signing for the protected vanity domain via the Microsoft 365 Defender portal > Email & collaboration > Policies & rules > Threat policies > DKIM management panel; (iii) M365 2048-bit key-strength upgrade-from-default- 1024-bit operator-side discipline — M365's legacy default DKIM key-strength is 1024-bit RSA (deprecated per RFC 8301 §3); the operator MUST execute the PowerShell Rotate-DkimSigningConfig -KeySize 2048 sequence to upgrade each per-tenant signing configuration to 2048-bit RSA before the modern receiver- side DKIM-verifier-and-DMARC-aligner produces meaningful per-message DKIM-aligned-pass verdicts; (iv) M365 dual-selector rotation Rotate-DkimSigningConfig orchestration vs per-tenant DKIM-alignment-preservation discipline — M365's Rotate-DkimSigningConfig PowerShell cmdlet orchestrates the selector1-to-selector2 cutover with Microsoft-managed key generation, but the per-tenant operator MUST verify the d=-tag VALUE remains the protected vanity domain across the rotation cutover (the rotation moves per-selector keys, not per-tenant d=-tag identity) so the DKIM-half of identifier-alignment THIS page documents continues to evaluate against the SAME author-domain From: header across the rotation. Read the dkim_for_microsoft_365 spoke as the M365- tenant-specific DKIM-publication-vs- alignment-input reference whenever the protected domain is hosted on the M365 cloud tenant and the alignment-evaluation algorithm THIS page documents needs an M365-tenant DKIM-publication baseline.
• DKIM selectors explained (s= and d= tags) — the tag-by-tag deep dive on the d= signing-domain tag that this alignment guide depends on as DMARC's DKIM-alignment input. Where this alignment page documents how the d= value is compared against the RFC 5322 From: domain under adkim=r relaxed (organizational domain equality via the Public Suffix List) and adkim=s strict (FQDN equality) modes, the selectors page documents how operators choose, publish, and rotate the d= value itself — the DNS TXT-record syntax (selector._domainkey.example.com), the s= selector-name conventions (eight canonical naming patterns: date / sequence / hash / purpose / tenant / environment / version / opaque), the per-provider selector catalogue (Google Workspace / Microsoft 365 / Mailchimp / SendGrid / Mailgun / Postmark / SES), and the dual-selector zero- downtime rotation procedure that maintains alignment continuity across key-rotation events. The selectors page also covers the critical SaaS-multi-tenant pattern where per-tenant selectors share a single d= root — important when an ESP signs on behalf of a customer domain and the customer publishes the per-tenant selector under their own DNS zone to achieve DKIM alignment with their RFC 5322 From: domain. Pair this alignment page (the evaluation rules) with the selectors page (the publication mechanics) when diagnosing why a DKIM-signed message passes signature verification but fails DMARC alignment.
• DKIM best practices — the DMARC-ALIGNMENT-EVALUATION- CONSUMER-OF-DKIM-KEY-CRYPTOGRAPHY-AND- SIGNING-HYGIENE-OPERATOR-REFERENCE companion reference. Where THIS page documents the DMARC identifier-alignment evaluation mechanics (the adkim=r organisational-domain match vs adkim=s FQDN match; the DKIM d=-tag-against-From:- header-organisational-domain comparison; the disjunction with SPF-alignment to produce the DMARC alignment-pass verdict), the dkim_best_practices spoke is the OPERATOR-HYGIENE PREREQUISITE canonical reference defining the signer-side key-cryptography + signing-hygiene invariants without which DKIM-alignment- pass cannot mechanically OCCUR at the receiver-side evaluation boundary (regardless of adkim=-tag choice or d=-tag identity — if the DKIM signature itself fails verification, the alignment-evaluation step is unreached). FOUR structurally- distinct DMARC-ALIGNMENT-DKIM-HYGIENE- PREREQUISITE dimensions the operator- hygiene spoke defines that this DMARC- alignment-evaluation page structurally consumes: (i) RFC 8301 2048-bit RSA key-size discipline AS THE ALIGNMENT-EVALUATION-PREREQUISITE that DKIM signature verification SUCCEEDS at the receiver before alignment evaluation applies — the dkim_best_practices spoke documents the cross-receiver weak-key-deprecation invariant; an adkim=r- configured DMARC record with a perfect d=<domain>-vs-From:- organisational-domain match cannot produce a DKIM-alignment-pass verdict if the DKIM signature itself fails verification at the receiver (Gmail's October-2024 1024-bit-RSA rejection); the DMARC-alignment evaluation rules THIS page documents PRESUPPOSE the signer-side has cleared the operator- hygiene spoke's key-size floor; (ii) RFC 6376 §3.6.1 k=rsa + h=sha256 signing- algorithm discipline AS THE ALIGNMENT-EVALUATION-PREREQUISITE that the receiver verifier accepts the algorithm-tag combination before alignment evaluation applies — the dkim_best_practices spoke documents the RSA-SHA-256 receiver-canonical baseline; receivers verifying DKIM signatures with deprecated hash algorithms (SHA-1 per RFC 8301) produce DKIM-fail BEFORE the alignment-evaluation rules THIS page documents are applied; the operator- hygiene spoke's algorithm-tag discipline is the prerequisite for the alignment evaluation pathway to execute at the receiver; (iii) per-selector custody-isolation discipline AS THE ALIGNMENT- EVALUATION-PREREQUISITE that the receiver resolves the d=<domain>-tag-to- public-key lookup successfully before alignment evaluation applies — the dkim_best_practices spoke documents the cross-signer custody-isolation invariant (one selector per signer- infrastructure instance; no selector- reuse across operator-distinct signers); when an operator violates this invariant (e.g. an old retired ESP's selector continues to be referenced by stale signed messages while the ESP has removed its TXT publication on the operator's d=<domain>), the receiver's <selector>._domainkey.<d-domain> TXT lookup returns NXDOMAIN AND DKIM-fail-temperror or DKIM-fail- permerror occurs at signature verification — alignment evaluation IS UNREACHED for those messages (the operator's per-selector custody-isolation discipline is prerequisite to alignment-pathway execution); (iv) RFC 6376 §3.6.1 overlap-window rotation discipline AS THE ALIGNMENT- EVALUATION-PREREQUISITE that the receiver resolves BOTH the old AND new selector successfully during per-rotation cutover windows so DMARC-alignment-pass continuity is preserved across the cutover — the dkim_best_practices spoke documents the per-rotation overlap- window discipline (publish new selector ≥7 days before retiring the old; per-rotation per-receiver DKIM-pass-rate monitoring); for DMARC alignment evaluation, an operator who skips the overlap- window discipline produces per-day DMARC-alignment-pass-rate regressions during the cutover window (messages signed with the new selector at the signer side before the new selector's TXT publication propagates fail DKIM-fail-NXDOMAIN at receivers; messages signed with the old selector after the old selector's TXT publication is retired fail similarly); the rotation-overlap discipline the operator-hygiene spoke documents is the load-bearing prerequisite for alignment-pass continuity the DMARC monitoring operator depends on. Read the dkim_best_practices spoke alongside this DMARC-alignment page when authoring a DMARC-enforcement program — the alignment-evaluation rules THIS page documents PRESUPPOSE the signer-side has cleared all four operator-hygiene invariants the dkim_best_practices spoke catalogues at the cross-provider operator- reference level; an alignment- evaluation diagnostic that finds DKIM-fail-before-alignment-pathway- execution should pivot to the operator-hygiene spoke's per- invariant audit pattern.
• DKIM cryptography basics — the DMARC-ALIGNMENT-EVALUATION- CONSUMER-OF-DKIM-RSA-VS-ED25519-KEYPAIR- AND-SHA-256-HASH-AND-CANONICALIZATION- CRYPTOGRAPHIC-FOUNDATION companion reference. Where THIS page documents the receiver-side identifier-alignment evaluation rules (adkim=r organisational-domain match vs adkim=s FQDN match between the DKIM-Signature d= tag and the RFC 5322 From: author-domain) that runs ONLY AFTER a DKIM-pass verdict has surfaced, the cryptography-basics spoke is the CRYPTOGRAPHIC-FOUNDATION canonical prerequisite documenting the RSA-2048 (or Ed25519 per RFC 8463) keypair-generation algorithm whose per-message DKIM-Signature b=-tag RSA-PKCS#1-v1_5 (or Ed25519) signature math is the load-bearing cryptographic primitive that produces the dkim=pass verdict THIS page's alignment- evaluation algorithm depends on as its upstream message-layer-authentication input. Pair THIS alignment page (the receiver-side evaluation algorithm) with the cryptography- basics spoke (the signer-side key-and- signature foundation) when an aggregate- report row shows dkim=permerror / dkim=fail on rows from a sender that publishes a nominally-valid d= tag — the crypto-basics spoke catalogues every signer-side cryptographic-foundation error class (RSA-1024-publication-deprecated-by-RFC-8301 / SHA-1-hash-algorithm-deprecated / public- key-byte-corruption-at-TXT-record-chunking- boundary / private-key-custody-loss-forcing- unsigned-egress / canonicalization-choice- mismatch-with-forwarder-modification- pattern) that collapses the DKIM-pass verdict before the alignment-evaluation algorithm THIS page documents can ever execute.
• DKIM DNS record syntax (RFC 6376 §3.6.2 byte-level TXT-record encoding rules) — the DNS-RECORD-PUBLICATION-PREREQUISITE spoke this alignment page implicitly depends on. Where this page documents the DKIM-alignment evaluation rules (adkim=r organisational-domain match vs adkim=s FQDN match) the receiver applies AFTER the DKIM signature has verified, the DKIM-DNS-syntax spoke documents the byte-level rules of the published KEY RECORD whose presence and integrity are PREREQUISITE to the DKIM-pass that drives DMARC alignment in the first place. The page covers two knobs that interact directly with the adkim= tag on the DMARC record: (i) the DKIM key-record t=s flag (RFC 6376 §3.6.1) which enforces STRICT i-domain-vs-d-domain identity at the DKIM-Signature header layer — when published, the i= identity in the signature must exactly equal or be a subdomain of the d= value, which propagates a stricter alignment surface into the DKIM-pass that DMARC then sees (the t=s flag is sometimes confused with adkim=s but operates at a DIFFERENT layer — t=s is the SIGNER's own internal identity-discipline knob, adkim=s is the DMARC RECEIVER's identifier-alignment knob; they pair well but are not equivalent), (ii) the s=email service-type constraint (RFC 6376 §3.6.1) which filters which messages the key is authorised to sign — a botched s=newsletter publication produces DKIM-no-signature verdict for every regular message, which collapses DKIM-alignment to no-result for those rows in the aggregate report regardless of adkim=r or adkim=s. The spoke also documents the empty-p= key- revocation convention (which silently drops alignment to no-pass for every row on the affected selector until the record is removed) and the 255-octet character-string chunking rule (an improperly chunked 2048-bit RSA public key produces an unparseable DKIM record, which receivers report as dkim= permerror — an alignment-impossible failure mode distinct from any adkim= tag value). Pair this alignment page (the evaluation algorithm) with the DKIM-DNS-syntax page (the publication mechanics) when an aggregate report shows dkim=permerror on rows from a sender that publishes a nominally-valid record — the byte-syntax spoke catalogues every operator-error class that produces permerror at the receiver before DMARC alignment even runs.
• DKIM troubleshooting (symptom-driven debugging) — the DMARC-ALIGNMENT-EVALUATION- CONSUMER-OF-DKIM-VERIFICATION-VERDICT companion documenting the symptom-driven debugging playbook for the DKIM-pass-or- fail verdict THIS page's alignment- evaluation algorithm consumes as INPUT. Where THIS page documents the receiver- side alignment evaluation (relaxed adkim=r organisational- domain match vs strict adkim=s FQDN match between the DKIM-Signature d= tag and the RFC 5322 From: domain) that runs AFTER a DKIM-pass verdict surfaces, the DKIM-troubleshooting spoke documents the FOUR canonical DKIM-fail-class diagnostics operators run WHEN the aggregate-report RUA row shows dkim=fail (body-hash mismatch from forwarder-inserted signature region modification, signature- tag invalidity from a corrupted b= base64 payload, public- key DNS resolution failure when the <selector>._domainkey.<d=domain> TXT lookup returns NXDOMAIN or the decoded p= public key fails crypto-verification, RSA-key-too-small when the published key is below the RFC 8301 1024-bit minimum). The four-axis ALIGNMENT-MECHANICS-VS-DKIM-TROUBLESHOOTING- COMPARISON exposes the operationally- distinct diagnostic ladders: (i) DKIM-fail at the cryptographic-verification layer means alignment evaluation has NOTHING TO EVALUATE — the alignment algorithm THIS page documents requires an authoritative pass verdict as input, so DKIM-fail bypasses alignment entirely and the operator must diagnose the verification failure first via the DKIM-troubleshooting spoke before the alignment-mechanics on THIS page become relevant; (ii) DKIM-pass- but-not-aligned — when DKIM verification succeeds but the d= signing-domain does NOT align with the header-From organisational domain under the active adkim= mode, the alignment-mechanics on THIS page produce dkim=pass + aligned=false in the RUA record; the DKIM-troubleshooting spoke's per-selector / per-signing-infrastructure diagnostic playbook is the operational path to identify WHICH sending-infra emitted the non-aligning d=; (iii) DKIM-fail at the canonicalization-boundary layer — when forwarder-inserted body-modification breaks the body-hash, the DKIM-troubleshooting spoke documents the relaxed-vs-simple canonicalization choice + the l= body-length-limit configuration that determine whether DKIM-pass survives the forwarder-hop modification boundary — a fail-mode that the alignment-mechanics on THIS page observe but do not diagnose; (iv) DKIM-fail at the key-rotation window — when the active selector signs with one key but the published key is mid-rotation, the DKIM-troubleshooting spoke documents the publish-new → wait-TTL → sign-new → wait-TTL → retire-old safe-rotation procedure whose mid-rotation window produces transient dkim=fail verdicts ALIGNMENT cannot rescue. Read the DKIM-troubleshooting spoke ALONGSIDE this alignment page when the RUA stream shows a sustained dkim=fail or dkim=pass + aligned=false pattern on a protected domain — the DKIM-troubleshooting spoke is the symptom-driven diagnostic entry point that ROUTES to the right per-cause remediation BEFORE the alignment-mechanics on THIS page can affect the per-message DMARC outcome.
• BIMI explained — Brand Indicators for Message Identification. Requires DMARC at p=quarantine or p=reject — and aligned mail.
• BIMI Verified Mark Certificates (VMC and CMC) — the ALIGNMENT-MECHANICS-CONSUMER-FOR-VMC- INVESTMENT-READINESS companion reference. Where THIS page documents the alignment COMPUTATION in protocol-precise terms (RFC 7489 §3.1 SPF-or-DKIM-authenticated- identifier-matches-From: rule, relaxed-via-PSL-orgdomain vs strict-via-FQDN evaluation, the adkim=s / aspf=s tag-strictness selection), the BIMI-VMC-certificates spoke documents the OPERATIONAL-INVESTMENT-GATE that converts that alignment-computation into a brand-display outcome: VMC issuance from DigiCert or Entrust REQUIRES the operator's DMARC record at p=quarantine pct=100 or p=reject (the CMC second-class cert relaxes the trademark-evidence requirement but NOT the DMARC-enforcement prerequisite), AND requires that the alignment computation this page documents is producing a steady-state pass-rate on every legitimate mail-stream — because the moment an operator flips from p=none to p=quarantine pct=100 (the BIMI-display threshold), every alignment- failure-mode this page documents (DKIM-only pass on a Return-Path differing from From:, SPF-only pass with a DKIM=fail because an ESP rewrites headers post-signing, the relaxed-orgdomain vs strict-FQDN evaluation producing different pass/fail outcomes for the same subdomain mail-stream) translates directly into mail-stream-suppression-or- bounce on the legitimate mail flow that the operator was about to invest $1,500-$3,000 per year of VMC certificate spend on. Read the BIMI-VMC-certificates spoke alongside this page when scoping a BIMI rollout — the certificate procurement workflow is downstream of the alignment-pass-rate verify gate this page documents, and every dollar of VMC investment is wasted if the alignment computation isn't reliably passing on the mail-stream the brand logo is supposed to display alongside.
• DMARC for Hybrid Exchange (on-prem + M365) — the ALIGNMENT-MECHANICS-CONSUMER-IN- HYBRID-DUAL-EGRESS-EXCHANGE-COEXISTENCE- TOPOLOGY companion reference. Where THIS page documents the alignment COMPUTATION in protocol-precise terms (RFC 7489 §3.1 SPF-or-DKIM-authenticated-identifier- matches-From: rule, relaxed-via-PSL- orgdomain vs strict-via-FQDN evaluation, the adkim=s/aspf=s tag-strictness selection), the DMARC-for-Hybrid-Exchange spoke documents the canonical OPERATIONAL-FAILURE-MODE topology where the alignment-computation this page documents produces dkim=fail and spf=fail in production for legitimate mail FROM the protected domain because the hybrid sender topology produces dual-egress paths with non- aligned default identifiers: (i) mail egressing via Exchange Online's outbound path is DKIM-signed with the M365 tenant-managed selector1/selector2 CNAME infrastructure (d= = the M365-tenant protected domain — aligns when set up correctly), while (ii) mail egressing via the on-prem Edge Transport role is EITHER unsigned (a common misconfiguration) OR signed with a legacy on-prem DKIM key under a different d= domain than the protected From:-domain, AND (iii) the SPF include:spf.protection.outlook.com covers ONLY the EOP-outbound IP range — the on-prem Edge IP must be added as a SECOND ip4:<on-prem-edge-IP> mechanism (or the second IP fails SPF=pass), and (iv) inbound mail forwarded between the hybrid topology's TWO mailbox locations (on-prem-routed inbound forwarded to a cloud mailbox vs cloud-routed inbound forwarded to an on-prem mailbox) can BREAK the alignment computation by rewriting the envelope-MAIL-FROM at the transport-rule boundary. Read the DMARC-for-Hybrid-Exchange spoke alongside this page when investigating policy_evaluated.dkim=fail or policy_evaluated.spf=fail rows from an M365 organisation — hybrid-Exchange topology is the SINGLE most common root cause of legitimate-mail alignment-failure-mode incidents because the dual-egress paths produce structural identifier-misalignment scenarios that the alignment computation on this page correctly flags as fail.
• DMARC for cPanel & Shared Hosting — the ALIGNMENT-MECHANICS-CONSUMER-AT- CPANEL-EXIM-MAIL-FROM-REWRITING-AND- EXIM_DKIM-DEFAULT-SELECTOR-SIGNING- INFRASTRUCTURE companion reference. Where THIS page documents the alignment COMPUTATION in protocol-precise terms (RFC 7489 §3.1 + §6.6.2 SPF-or-DKIM- authenticated-identifier-matches-From: rule, relaxed-via-PSL-orgdomain vs strict- via-FQDN evaluation, the adkim=s/aspf=s tag-strictness selection), the DMARC-for-cPanel deployment spoke documents the SHARED-HOSTING OPERATIONAL TOPOLOGY where the alignment computation must reconcile FOUR cPanel-default behaviours that structurally affect identifier alignment: (i) cPanel's WHM-managed Exim outbound MTA, when configured with the "Sender Verification" feature OR with per-tenant bounce-address rewriting, can rewrite the envelope- MAIL-FROM to bounces+<tenant-id>@<cpanel-server-hostname> at relay-handoff — which BREAKS SPF alignment with the protected From:-domain (the SPF check evaluates against the rewritten envelope domain, not the original) unless DKIM-aligned-pass carries the message; (ii) cPanel's EXIM_DKIM default-signing toggle (WHM → Exim Configuration Manager → ACL Options → "Enable DKIM Signing") signs every outbound message with selector default._domainkey under d=<tenant-domain> — which IS aligned with the From:-domain UNLESS the operator has overridden the d= via Exim's dkim_domain macro, in which case the alignment-evaluation outcome shifts; (iii) cPanel's "Email Deliverability" UI (cPanel UI → Email Deliverability) auto-generates the default._domainkey DKIM TXT and the v=spf1 +a +mx include:websitewelcome.com ~all SPF default — both records' alignment with the protected From:-domain depends on the cPanel server's websitewelcome.com-cohabitant IP reputation co-tenancy, which the alignment computation does NOT structurally see; (iv) cPanel's WHM-level "Reseller Account" boundary introduces a SECOND tier of envelope- rewriting under the reseller's bounces+<reseller-id> identifier whose alignment-mode evaluation feeds the receiver-side policy_evaluated.spf verdict the alignment computation produces. Read the DMARC-for-cPanel spoke alongside this page when investigating policy_evaluated.spf=fail rows from a cPanel-hosted domain whose DKIM-aligned-pass is the only surviving leg — cPanel-default Exim envelope- rewriting is the canonical first-suspect root cause and the alignment-evaluation algorithm THIS page documents is the per-message contract the cPanel deployment guide must satisfy at every Phase-1-to-Phase-4 rollout milestone.
• DMARC for shared hosting — the ALIGNMENT-MECHANICS-CONSUMER-AT- MULTI-TENANT-SHARED-IP-POOL-EGRESS-AND- CO-TENANT-PUBLISHER-INDISTINGUISHABILITY companion to this alignment-mechanics reference. Where THIS page documents the alignment COMPUTATION in protocol-precise terms (RFC 7489 §3.1 + §6.6.2 SPF-or-DKIM- authenticated-identifier-matches-From: rule, relaxed-via-PSL-orgdomain vs strict- via-FQDN evaluation, the adkim=s/aspf=s tag-strictness selection), the shared- hosting deployment spoke documents the STRUCTURALLY-DISTINCT non-cPanel shared- hosting tenancy topology (Plesk / DirectAdmin / ISPConfig / Webmin / Virtualmin / CWP — the five canonical non-cPanel control panels) where the alignment computation must reconcile FOUR shared-hosting-tenant-specific alignment- evaluation dimensions distinct from the cPanel deployment guide's cPanel-Exim envelope-rewriting + EXIM_DKIM default- selector signing materialisations: (i) shared-outbound-relay envelope- MAIL-FROM rewriting as per-tenant SPF- alignment-evaluation gate — the per-tenant control-panel's outbound relay rewrites the envelope MAIL-FROM to bounces+<tenant-id>@<shared- relay-hostname> at relay-handoff, which structurally fails the aspf=r organisational-domain- match AND the aspf=s exact- FQDN-match against the tenant's protected From:-domain — alignment-pass survives ONLY via the DKIM-aligned-pass leg of the SPF-OR-DKIM disjunction, making per-tenant DKIM publication-and-signing-key isolation the LOAD-BEARING precondition for any per-tenant p=quarantine / p=reject posture surviving the shared-relay envelope-rewriting; (ii) per-tenant DKIM-d=- tag-as-publisher-distinguisher under shared-IP-pool egress — the shared-hosting topology renders SPF STRUCTURALLY UNABLE to distinguish the per-tenant publisher (the shared-IP-pool authorises ANY co-tenant's outbound mail for ANY tenant's From:-domain that include:s the shared-relay pool); only the per-tenant-isolated DKIM private-key with the per-tenant d=<tenant-domain> tag produces the per-publisher-distinguisher the alignment evaluation requires for per-tenant attribution — the alignment computation THIS page documents thus operates ASYMMETRICALLY on shared-hosting tenant mail: SPF-alignment-pass is operationally CHEAP-AND-AMBIGUOUS, DKIM- alignment-pass is operationally LOAD- BEARING-AND-DISAMBIGUATING; (iii) per-tenant subdomain alignment- mode coordination at the sp=-tag layer for shared- hosting subdomain rotation — the shared-hosting application stack frequently publishes per-application subdomains (blog.<tenant>, shop.<tenant>, support.<tenant>) on the SAME shared-IP-pool — the sp=-tag (subdomain policy) coordination the shared-hosting deployment spoke documents IS the per-tenant alignment-mode override the alignment- evaluation algorithm THIS page documents consumes when the per-message header_from is a tenant subdomain rather than the apex; without the sp=-tag the per-subdomain alignment evaluation defaults to the organisational-domain p= tag which the shared-hosting tenant must explicitly override to enforce per- subdomain alignment-mode discipline; and (iv) multi-tenant include:<hosting-vendor-pool> cascade-vs-per-tenant-supplemental- ip4: SPF-side alignment-input authoring — the shared-hosting tenant inherits a vendor-managed include:<hosting-vendor-pool> sub-record cascade (Plesk's include:_spf.plesk.com, DirectAdmin's per-virtual-host +a mechanism, ISPConfig's +mx +a default) that cooperatively-extends the per-tenant SPF record with co-tenant-authorised egress IPs; the per-tenant authorisation of the shared-IP-pool is structurally the SAME as every co-tenant's authorisation, which is precisely the alignment- evaluation input asymmetry the aspf=r / aspf=s evaluation must resolve when the receiver cannot distinguish co-tenants by SPF evaluation alone. Read the shared-hosting deployment spoke alongside this page when investigating per-tenant policy_evaluated.dkim/spf verdicts on a non-cPanel shared-hosting domain whose per-tenant alignment-mode posture must reconcile the shared-IP-pool co-tenant-publisher-indistinguishability constraint — the alignment-evaluation algorithm THIS page documents is the per- message contract the shared-hosting deployment guide's Phase-1-to-Phase-4 per-tenant rollout sequence must satisfy for every per-tenant _dmarc.<tenant> publication at the per-control-panel zone-editor publication boundary.
• MTA-STS explained — SMTP MTA Strict Transport Security (RFC 8461). Companion transport-security standard.
• TLS-RPT explained — SMTP TLS Reporting (RFC 8460).
• TLS-RPT record syntax (RFC 8460 §3) — the DMARC-ALIGNMENT-RFC5322-FROM- IDENTIFIER-DOMAIN-ATTRIBUTION-PARALLEL- WITH-TLS-RPT-POLICY-DOMAIN-DISCOVERY-NAME companion to this DMARC alignment reference. Where THIS page documents the RFC 7489 §3.1 relaxed-vs-strict identifier-alignment evaluation at the application layer (the RFC5322.From header-address-domain MUST match the SPF return-path domain or the DKIM d= signing-identifier domain for the corresponding leg to pass DMARC), the TLS-RPT record-syntax spoke is the RFC 8460 §3 TLS-RPT TXT-RR publication-discovery companion whose _smtp._tls.<policy- domain> per-policy-domain discovery-name discipline mirrors the per-RFC5322.From-domain identifier- alignment attribution THIS page documents. The DMARC-ALIGNMENT-RFC5322- FROM-IDENTIFIER-DOMAIN-ATTRIBUTION- PARALLEL-WITH-TLS-RPT-POLICY-DOMAIN- DISCOVERY-NAME cross-reference establishes FOUR structurally-distinct per-domain authentication-outcome attribution dimensions: (i) per-domain discovery-name attribution parallel — DMARC alignment per RFC 7489 §6.6.3 attributes every receiver-side DMARC-evaluation outcome to the RFC5322.From header-address- domain (the "Org Domain" derivation per §3.2 collapses From=foo.bar.example.com to example.com for policy-record lookup); TLS-RPT per RFC 8460 §3 attributes every receiver-side TLS- delivery-failure outcome to the policy-domain that publishes the _smtp._tls.<policy- domain> discovery name (which the receiver derives from the delivery-recipient's domain for report-target lookup); both protocols share the publisher-side-publishes- per-domain-policy / receiver-side- derives-policy-from-message-domain attribution discipline; (ii) per-domain DNS-RR publication location parallel — DMARC publishes the policy record at _dmarc.<policy-domain> (per RFC 7489 §6.1); TLS-RPT publishes the policy record at _smtp._tls.<policy- domain> (per RFC 8460 §3.1); both protocols use the underscore- prefixed sub-label naming convention to distinguish protocol-specific TXT RRs from generic-purpose TXT RRs at the same apex; both protocols' receiver- side discovery follows the same publisher-side-publishes-at- underscore-prefixed-sub-label-then- receiver-side-queries-that-exact-name pattern; (iii) per-domain publisher-side intent vs receiver-side observation separation parallel — DMARC alignment evaluation produces the per-RFC5322.From-domain pass/fail verdict the receiver REPORTS back to the publisher via the rua=-tag-listed aggregate- report mailbox (closing the per-domain observation feedback loop); TLS-RPT receiver-side TLS-delivery-failure observation produces the per-policy- domain success/failure verdict the receiver REPORTS back to the publisher via the rua=-tag-listed TLS-RPT report-target URI (closing the per-domain transport-failure feedback loop); both protocols' per-domain publisher-side intent vs receiver-side observation separation is the same publisher-side-publishes-intent / receiver-side-observes-outcome / receiver-side-reports-back-via- per-domain-tag-list pattern; (iv) per-domain publisher-side publication topology parallel for multi-domain enterprise deployments — DMARC alignment for a multi-domain enterprise requires each sender-domain to publish its own _dmarc.<sender-domain> policy record (with subdomain-policy inheritance via the sp= tag per RFC 7489 §6.3); TLS-RPT for a multi-domain enterprise requires each recipient-domain to publish its own _smtp._tls.<recipient- domain> policy record (with no subdomain-policy inheritance — each recipient subdomain requires its own explicit TLS-RPT publication per RFC 8460 §3.1 normative semantics); both protocols' per-domain publication topology shares the per-leaf-domain- publisher-side-responsibility discipline, with TLS-RPT's stricter no-inheritance contract producing a per-subdomain publication-coverage audit obligation the DMARC subdomain-policy inheritance does not require. Pair this page (the DMARC RFC5322.From identifier-alignment evaluation reference) with the TLS-RPT record-syntax spoke (the RFC 8460 §3 TLS-RPT TXT-RR publication-discovery reference) when an operator authors the per-domain DNS-RR publication topology for the enterprise's authentication-and- transport-reporting deployment and needs to apply the same per-RFC5322.From- domain / per-policy-domain attribution discipline across both the application- layer DMARC alignment evaluation and the transport-layer TLS-RPT report publication.
• TLS-RPT JSON report format (RFC 8460 §4) — the DMARC-ALIGNMENT-VS-TRANSPORT-LAYER- COMPLEMENT companion to this DMARC identifier-alignment reference. Where THIS page documents alignment EVALUATION at the application layer (RFC 7489 §3.1 relaxed-vs-strict identifier-alignment computation, the organizational-domain-derivation algorithm against the Public Suffix List, the SPF-side aspf= and DKIM-side adkim= tag semantics, the per-message application-layer pass/fail verdict that feeds the DMARC-policy decision), the TLS-RPT report-format spoke documents the RFC 8460 §4 JSON report-payload byte-schema that captures the TRANSPORT-LAYER cleartext-vs-encryption observation receivers emit when their inbound STARTTLS connection to the publisher's sending MTA fails — an observability dimension structurally ORTHOGONAL to the application-layer alignment computation but operationally COMPLEMENTARY because (i) alignment-pass with transport-layer downgrade delivers an aligned-but-cleartext message that passes DMARC at the receiver but leaked the entire message body, headers and attachments to any on-path observer along the publisher-to-receiver path, (ii) alignment-fail with transport-layer encryption keeps the message body confidential against on-path observers but still arrives at the receiver flagged as DMARC-fail and quarantined or rejected per the publisher's p= policy, (iii) the complete end-to-end mail-authentication confidence picture for any production domain requires BOTH the application-layer alignment-pass-rate metric documented by THIS page (read from the publisher's DMARC aggregate reports) and the transport-layer STARTTLS-success-rate metric documented by the TLS-RPT JSON report-format spoke (read from the publisher's TLS-RPT reports). Read the TLS-RPT report-format spoke once the DMARC alignment-pass-rate on this page is steady at the operationally-acceptable ceiling and the operator needs the orthogonal transport-layer evidence stream to confirm the BIMI-eligibility / payment- gateway-compliance / EU-Privacy-Notice / SAML-IdP-transport-confidentiality post-deployment baseline.
• CAA records explained — Certification Authority Authorization (RFC 8659).
• DMARC myths and misconceptions — the DMARC-ALIGNMENT-MODE-SEMANTICS-AS- CANONICAL-REFUTATION-OF-SPF-OR-DKIM-ALONE- IS-ENOUGH-MYTH companion to this DMARC- alignment-evaluation reference. Where THIS page documents the per-message identifier-alignment computation (RFC 7489 §3.1 / §6.6.2: the SPF-or-DKIM-authenticated-identifier- matches-From:-header-domain rule, the aspf=r/aspf=s SPF-mode strictness knob, the adkim=r/adkim=s DKIM-mode strictness knob, the relaxed-via-PSL-organisational-domain- match vs strict-via-FQDN-equality decision logic, the policy_evaluated.dkim / policy_evaluated.spf verdict each message yields), the DMARC-myths-and-misconceptions spoke is the OPERATOR-MENTAL-MODEL-CORRECTION catalogue cataloguing the 18 distinct misconceptions about DMARC that recur in operator rollout-blocker decision-making, FOUR of which directly engage with the alignment-mode-semantic mechanics THIS page documents and which this alignment pillar is the canonical refutation-source for: (i) Myth 3 ("I have SPF and DKIM so I do not need DMARC") — the canonical "raw SPF+DKIM is sufficient" myth, refuted at the protocol-semantic level by THIS page's identifier-alignment computation: bare SPF and bare DKIM both authenticate identifiers (envelope-MAIL-FROM and DKIM-d=-signing-domain respectively) that are STRUCTURALLY ORTHOGONAL to the visible From:-header domain attackers control — so SPF-pass and DKIM-pass can BOTH succeed for an attacker's own domain while the visible From-header impersonates the victim, and only DMARC's alignment evaluation (this page's subject) CLOSES that gap by requiring the authenticated-identifier to MATCH the visible From:-header domain; (ii) Myth 17 ("DMARC blocks attackers spoofing my employees' Gmail addresses") — the consumer-mailbox spoofing myth, refuted at the alignment-semantic level by DMARC's From:-header-DOMAIN-scope: DMARC evaluates alignment for the From: header's DOMAIN portion (e.g. gmail.com), NOT the local- part (e.g. employee-name); Gmail publishes p=reject for the gmail.com domain so attackers cannot spoof From: anything@gmail.com, but DMARC has NO mechanism to police which gmail.com mailboxes belong to which corporate employees — that's outside the protocol's design scope; (iii) the implicit "relaxed mode is insecure" objection — refuted by THIS page's relaxed-via-PSL-organisational-domain match section: relaxed mode is the RFC 7489 §3.2 DEFAULT and the operationally-correct choice for any organisation that signs mail at a subdomain (mail.example.com) but publishes the DMARC record at the organisational apex (example.com); strict mode would break this entirely-routine deployment topology, making relaxed the SECURITY-CORRECT default not a weakened compromise; (iv) the "strict mode is always more correct than relaxed" false dichotomy — refuted by THIS page's adkim=s/aspf=s strictness-tradeoff section: strict mode disables ALL subdomain-to- organisational-domain matching, so mail.example.com-signed DKIM no longer aligns with the example.com apex DMARC record — strict mode is correct ONLY when the operator publishes a DMARC record at EVERY signing subdomain AND has audited that NO downstream forwarder rewrites the From-header to a sibling subdomain (an audit floor most operators cannot pass). Read the myths catalogue alongside this alignment-evaluation reference when designing operator-facing rollout documentation that must overcome the "we already do SPF and DKIM" objection and the "strict mode is more secure" oversimplification operators raise when blocking DMARC movement from p=none to p=quarantine to p=reject — the myths catalogue is the canonical misconception-correction substrate; this alignment-evaluation reference is the canonical protocol-semantic refutation source.
• Business Email Compromise (BEC) — the ALIGNMENT-MECHANICS-AS-PRIMARY-BEC-DEFENSE-FORENSIC-PATH companion to this alignment-mechanics reference — the ALIGNMENT-MECHANICS-AS-PRIMARY-BEC- DEFENSE-FORENSIC-PATH companion documenting how the per-message identifier-alignment computation THIS page documents is the SINGLE most operationally-load-bearing protocol-layer defense against the BEC threat class. Where THIS page documents alignment EVALUATION in protocol-precise terms (RFC 7489 §3.1 SPF-or-DKIM-authenticated-identifier-matches- From:-domain rule, relaxed-via-PSL-orgdomain vs strict-via-FQDN modes, the adkim=s/aspf=s tag- strictness selection, the policy_evaluated.dkim/spf verdict each message yields), the BEC spoke documents how attackers structurally probe each alignment failure mode — exact-domain spoofing (closed by p=reject with policy_evaluated alignment-fail rejecting at receive), lookalike-domain spoofing (registered Punycode confusables that ALIGN on their own attacker-controlled domain and thus pass DMARC, requiring out-of-band controls), display-name spoofing (the From:-header friendly-name presents a victim brand while envelope-MAIL-FROM and d=signing-domain align on attacker's own domain — alignment passes, deception succeeds), and forwarded-mail / mailing-list modification (where ARC chain verification decides whether the upstream alignment verdict propagates through the forwarder). Read THIS alignment-mechanics page WITH the BEC reference when a financial-fraud incident review asks "which alignment failure modes did the attacker exploit": the answer maps to the four BEC sub-techniques the spoke catalogues. Where THIS page documents the DEFENSE COMPUTATION, the BEC spoke documents the ATTACK SURFACE that defense covers and the four sub-techniques attackers structurally deploy against each alignment failure mode.
• DMARC deployment checklist — the ALIGNMENT-LITMUS-TEST-GATING-PHASE-ADVANCEMENT-ON-CHECKLIST companion to this alignment-mechanics reference — the ALIGNMENT-LITMUS-TEST-GATING-PHASE- ADVANCEMENT-ON-CHECKLIST companion documenting how the per-message alignment computation THIS page documents is the EMPIRICAL GATING TEST that drives every phase advancement on the linear deployment checklist. Where THIS page documents alignment EVALUATION in protocol-precise terms (RFC 7489 §3.1 SPF-or-DKIM-authenticated-identifier-matches- From: rule, relaxed-via-PSL-orgdomain vs strict-via-FQDN modes, the adkim=s/aspf=s tag- strictness selection, the policy_evaluated.dkim/spf verdict each message yields), the deployment- checklist spoke documents the ORDERED SEQUENCE of steps and the alignment-pass-rate gate at each phase advancement: (Phase 1) publish p=none, accumulate two weeks of RUA observation, identify every legitimate sender path; (Phase 2) advance to p=quarantine pct=10 only when alignment-pass-rate ≥99% on legitimate mail for two consecutive observation windows; (Phase 3) advance to p=quarantine pct=100 and then p=reject on the same alignment-pass-rate gate; (Phase 4) publish sp=reject for the organizational domain on the same gate applied to subdomain traffic. Read THIS alignment-mechanics page WITH the deployment- checklist reference when an operator asks "when can I move from p=none to p=quarantine": the answer is DETERMINISTIC — the alignment-pass-rate computation THIS page documents is the empirical input to the phase-advancement decision the checklist spoke catalogues. Where THIS page documents the COMPUTATION-LAYER alignment-evaluation algorithm, the deployment-checklist spoke documents the OPERATIONAL-LAYER phase-advancement playbook gated on that computation's production-mail aggregate-statistics.
• DMARC monitoring — the ALIGNMENT-PASS-RATE-AS-PRIMARY-MONITORED-KPI-AND-DRIFT-DETECTION-SIGNAL companion to this DMARC-alignment RFC 7489 §3.1.1 evaluation-algorithm reference. Where THIS page documents the COMPUTATION-LAYER alignment-evaluation algorithm at the byte level (the SPF-aligned condition where the envelope-MAIL-FROM domain matches the RFC 5322 From: organisational domain under aspf=r / aspf=s, the DKIM-aligned condition where the DKIM-Signature d= identifier matches the RFC 5322 From: organisational domain under adkim=r / adkim=s, the OR-conjunction-disjunction semantics where EITHER SPF-aligned OR DKIM-aligned produces DMARC-pass, and the Public- Suffix-List organisational-domain boundary lookup the relaxed-mode evaluation consults), the DMARC-monitoring deployment spoke documents the OPERATIONAL CONSUMER of the per-message alignment-evaluation verdict THIS page documents — the time-windowed alignment-pass-rate aggregation surface a continuous- monitoring posture computes from the RUA aggregate-report stream and exposes as the PRIMARY MONITORED KPI gating the four- phase DMARC rollout sequence (p=none → p=quarantine 10% → p=quarantine 100% → p=reject) on alignment-pass-rate plateau evidence. The monitoring spoke documents the per-cohort alignment-pass-rate-drift-detection signals an operator alerts on (a new-third-party-ESP-onboarding-without- DKIM-aligned-publication drop, a DKIM-selector-rotation-misconfiguration regression where the new selector fails the alignment check this page documents, an envelope-MAIL-FROM-rewriter-breaking- SPF-alignment regression at an intermediate-forwarder boundary), plus the per-cohort ALIGNMENT-FAILURE-BUT-AUTHENTICATION-PASS RUA-row pattern this page surfaces as the canonical operational consequence of the alignment-vs-authentication distinction. The monitoring spoke is the canonical operational reference for the per-phase alignment-pass-rate THRESHOLDS an operator gates rollout-phase-advancement on (e.g. DKIM-aligned-pass-rate ≥ 98% sustained over 7 days as the typical Phase-3 → 4 threshold), the per-cohort attribution-and-remediation playbook for closing per-third-party-sender alignment gaps surfaced by the alignment- algorithm this page documents, and the per-source_ip-anomaly-detection windowing discipline distinguishing legitimate-third-party-sender alignment-drift from external-attacker-bypass-attempt alignment-failure spikes. Read the monitoring spoke alongside this page when designing the observability infrastructure for a domain's DMARC posture — the alignment-evaluation algorithm described here is the per-message COMPUTATION the monitoring spoke aggregates over a time-windowed rolling sample, and the monitoring spoke is the canonical reference for WHICH alignment-derived KPIs feed which operational decisions (rollout-phase-advancement, regression alerting, third-party-sender remediation escalation).
• SPF PermError vs TempError diagnostic deep dive — the SPF-AUTH-RESULT- DEFEATS-ALIGNMENT-CHECK companion reference. Where THIS page documents the DMARC identifier-alignment evaluation (RFC 7489 §3.1) — the receiver- side rule that BOTH the SPF- validating MAIL FROM RFC5321 envelope-domain AND the DKIM- validating signing-domain d= tag must be compared to the header.From RFC5322 author domain under the publisher's aspf= / adkim= alignment- mode (relaxed organisational- domain or strict full-FQDN), and the alignment-passing-disjunction rule (SPF-aligned-pass OR DKIM- aligned-pass produces an overall DMARC-pass) — the SPF-PermError- vs-TempError spoke is the authoritative reference for the UPSTREAM PRECONDITION the SPF- side of the alignment evaluation depends on: an AUTHORITATIVE SPF auth-result enum from the set none, neutral, pass, fail, softfail, temperror, permerror (per RFC 7208 §2.6). BOTH TempError AND PermError STRUCTURALLY DEFEAT the SPF-side of DMARC alignment by construction — alignment requires the SPF outcome to be an authoritative pass for the envelope-domain to be considered SPF-aligned-pass with the header.From author-domain, and neither error mode produces an authoritative pass. The operational consequence: a publisher running an include:-heavy SPF chain (M365 + SendGrid + Mailgun + Marketo + Salesforce, often ~9 of the 10-DNS-lookup-budget consumed) that tips over the 10-lookup cap per RFC 7208 §4.6.4 sees the SPF side of the alignment evaluation PERMANENTLY-DEFEATED across the entire sender population — DMARC-pass then DEPENDS ENTIRELY on the DKIM-aligned-pass disjunct, and publishers without consistent DKIM-signing across all sender vendors see broad DMARC-fail bursts in the aggregate-report feed despite having no apparent deliverability-cliff-trigger publisher-side change. Similarly, an upstream DNS-resolver outage producing sustained spf=temperror bursts (per RFC 7208 §5 retry-with-backoff) defeats SPF- alignment for the duration of the outage; the canonical operator response is rate-against-baseline investigation (≤1% temperror rate normal; ≥10% sustained warrants DNS-operations escalation). The SPF-PermError-vs-TempError spoke catalogues the seven canonical PermError causes (record-not- found, syntax-error, multiple- records, too-many-lookups, void- lookup-cap, recursive-include, deprecated-mechanism) and the three canonical TempError causes (DNS resolver timeout, SERVFAIL upstream, transient network unreachable), with per-symptom Authentication- Results-header forensic-detection workflows (RFC 8601) and cause-specific resolution playbooks. Read the spoke alongside this alignment page when diagnosing unexplained DMARC-alignment-fail bursts in the aggregate-report feed — the SPF auth-result-column of the affected dmarc_records rows is the FIRST DIAGNOSTIC SIGNAL distinguishing a publisher- side SPF-record-syntax fault (PermError, fix-immediately) from a publisher-side intermittent- DNS-outage (TempError, investigate- rate-against-baseline) from a genuine alignment-mode-mismatch (relaxed-vs-strict aspf publisher-misconfiguration this alignment page documents).
• Email deliverability — the ALIGNMENT-AS-DELIVERABILITY- PRECONDITION-AT-RECEIVER-SIDE companion reference. Where THIS page documents the DMARC identifier- alignment evaluation (RFC 7489 §3.1 organisational-domain alignment under aspf=r / adkim=r vs full-FQDN alignment under aspf=s / adkim=s, the alignment-passing-disjunction rule where SPF-aligned-pass OR DKIM-aligned- pass produces overall DMARC-pass), the deliverability spoke documents the UMBRELLA RECEIVER-SIDE INBOX-PLACEMENT OUTCOME the alignment-decision ultimately determines. The misaligned-auth-pass class this alignment page documents (SPF-pass on an envelope-MAIL-FROM domain that does not share organisational-domain with the From: header; DKIM-pass on a d= domain that does not share organisational-domain with the From: header) STRUCTURALLY DEFEATS the deliverability outcome at receivers even when the publisher's SPF and DKIM records are individually well-formed: the receiver-side DMARC evaluation records the message as DMARC-fail (because neither auth-result is aligned), the per-domain reputation score the deliverability spoke documents accumulates the DMARC-fail events as negative reputation signal, and the receiver-side per-message disposition shifts toward spam-folder placement or outright reject regardless of the underlying SPF/DKIM-pass results. The deliverability spoke is therefore the canonical reference for the RECEIVER-SIDE- REPUTATION-SCORE-INPUT layer that the alignment-decision feeds into; THIS page's relaxed-vs-strict alignment- mode tuning is the publisher-side knob whose RIGHT-SETTING is necessary for the deliverability spoke's umbrella outcome to be defensible. Read THIS alignment page WITH the deliverability spoke when diagnosing a publisher whose individual SPF / DKIM evaluations pass at receiver-side but whose inbox-placement-outcome deteriorates — alignment-mode misconfiguration is the canonical first-suspect.
• ARC explained (RFC 8617 Authenticated Received Chain) — the FORWARDER-INDUCED-SPF-AND-DKIM- BREAK-SURVIVAL-VIA-PER-HOP-AMS-PRESERVATION- OF-PRIOR-HOP-AUTHENTICATION-RESULTS-FOR- DOWNSTREAM-DMARC-ALIGNMENT-EVALUATION-CHAIN- VALIDATION companion to this DMARC identifier-alignment-evaluation reference. Where THIS page documents the alignment COMPUTATION in protocol-precise terms (RFC 7489 §3.1 + §6.6.2 SPF-or-DKIM- authenticated-identifier-matches-From: rule, relaxed-via-PSL-orgdomain vs strict- via-FQDN evaluation, the adkim=s/aspf=s tag-strictness selection), the ARC- explained spoke documents the STRUCTURALLY-COMPLEMENTARY per-hop forwarder-relay authentication-results- preservation mechanism (RFC 8617 ARC- Message-Signature + ARC-Authentication- Results + ARC-Seal header chain) whose per-hop publication discipline supplies the receiver-side DMARC-alignment evaluator with PRESERVED PRIOR-HOP VERDICTS across FOUR ARC-chain-vs-DMARC-alignment- evaluation dimensions: (i) per- hop ARC-Authentication-Results header preserves the prior-hop SPF + DKIM verdict the canonical alignment evaluator THIS page documents would consume at the prior-hop receiver-side evaluation boundary — when Gmail forwards a message that originally spf=pass smtp.mailfrom=<esp> + dkim=pass d=<publisher-domain>, Gmail's ARC sealer captures those exact verdicts in its per-hop ARC-Authentication-Results header AND signs the prior-hop verdict-set with its ARC-Message-Signature — the final-hop receiver consulting the ARC chain in instance-order (i=1 → i=2 → i=n) recovers the original publisher-side alignment-evaluable verdict-set even when the receiver's own SPF re-evaluation against the forwarder's IP produces spf=fail; (ii) per- hop ARC-Seal chain-validation cv=pass verdict as gate for receiver-side override of the canonical alignment computation — when the final-hop receiver's ARC chain-validator traverses every per-hop ARC-AMS + ARC-AS signature in instance-order and produces a cv=pass chain-validation verdict, the receiver MAY override the canonical RFC 7489 §3.1 alignment computation THIS page documents (specifically: bypass the aspf=s / aspf=r strict-vs-relaxed gate that the forwarder-induced envelope-rewrite produces) and consume the prior-hop publisher-domain-aligned DKIM verdict the ARC chain preserved as the alignment-pass evidence; (iii) per-hop ARC sealer-domain as alignment-trust-delegation boundary distinct from the publisher-domain alignment THIS page documents — the ARC chain introduces a per-hop sealer-domain identifier (the d=<sealer-domain> in each AMS / AS header) that the receiver-side ARC chain validator treats as a per-hop trust-anchor; the receiver's local-policy applies a per- sealer-domain trust-list to the chain- validation outcome (only chain-validations whose every per-hop sealer-domain is on the receiver's trust-list contribute alignment-pass evidence — a Gmail- forwarded message's chain typically passes; a chain through an unknown intermediate gateway may not), an evaluation step structurally orthogonal to the canonical alignment-evaluator THIS page documents at the per-message publisher-domain layer; and (iv) per-hop ARC chain provides forwarder-attribution evidence for per-symptom alignment-failure debugging the troubleshooting spoke catalogues — the per-hop ARC-Authentication-Results header explicitly identifies WHICH forwarder-relay (arc-authres.< sealer-domain>) made WHICH per-hop authentication-verdict claim, enabling the receiver-side debugging operator to attribute a policy_evaluated.spf=fail row in the RUA stream to a specific forwarder-induced second-hop break rather than to the publisher's primary- egress SPF configuration — the per-hop ARC chain IS the canonical attribution- evidence stream that closes the forwarder-induced-alignment-failure symptom-debugging gap THIS page's canonical alignment-evaluation algorithm would otherwise have to attribute ambiguously. Pair THIS DMARC identifier-alignment reference with the ARC-explained spoke when investigating per-message policy_evaluated.spf=fail or policy_evaluated.dkim=fail rows on messages whose Authentication-Results header contains an ARC chain — the canonical alignment- evaluation algorithm THIS page documents consumes the ARC chain's preserved prior-hop verdicts AND the chain-validation cv= verdict as inputs the receiver-side local-policy MAY apply to override the canonical alignment-fail outcome in favour of the prior-hop publisher-domain- aligned verdict the ARC chain captures.
• DMARC aggregate (RUA) reports — the ALIGNMENT-EVALUATION-OUTCOME-AS- PER-ROW-POLICY-EVALUATED-XML-EVIDENCE- STREAM-AT-FOUR-ALIGNMENT-VERDICT- EMISSION-DIMENSIONS companion to this DMARC identifier-alignment-mechanics reference. Where THIS page documents the canonical RFC 7489 §3.1.1 identifier-alignment algorithm (the adkim=r/adkim=s DKIM-side alignment-mode evaluation, the aspf=r/aspf=s SPF-side alignment-mode evaluation, the Public Suffix List organisational- domain extraction, the multiple- signature "any aligns wins" rule, the From: header extraction rules per RFC 7489 §6.6.1), the aggregate-reports spoke is the EVIDENCE-PRESERVATION-XML- SCHEMA-EMISSION companion documenting the per-row XML byte-shape every receiver serialises the alignment- evaluation outcome into for per-source- IP per-day publisher analysis. Concretely, the spoke documents FOUR alignment-verdict-emission dimensions: (i) per-row <policy_evaluated><dkim> + <policy_evaluated><spf> evaluated-after-alignment per-leg verdicts — the receiver-emitted per-row XML records the alignment- evaluation OUTCOME (not the raw DKIM / SPF verification result) — when the message produces dkim=pass at the raw verification layer but the d= signing-domain does NOT organisationally align with the From: header per the adkim= tag mode THIS page documents, the per-row XML emits <policy_evaluated><dkim>fail</dkim> — the STRUCTURAL DISTINCTION between the raw-verification-result emitted in <auth_results> and the post-alignment-evaluation result emitted in <policy_evaluated> is the load-bearing evidence the publisher reads to attribute alignment- failure root causes per-source-IP per- day; (ii) per-row <auth_results><dkim> ><domain> + <auth_results><spf> ><domain> per-leg identifier-domain attribution — the receiver-emitted per-row XML records the actual d= signing-domain and envelope-MAIL-FROM domain evaluated against the From: header organisational domain — the publisher reads these per-leg identifier-domain literals to pin the WHICH-SIGNING-DOMAIN-WAS-USED diagnostic evidence when the per-row <policy_evaluated> verdict surfaces alignment-fail (the canonical M365 tenant.onmicrosoft.com / Workspace gappssmtp.com unaligned-d= attribution diagnostic THIS page documents as the most-common alignment-failure root cause); (iii) per-row <identifiers><header_from> From-header organisational-domain attribution — the receiver- emitted per-row XML records the RFC 5322 From: header organisational- domain as the alignment-reference- anchor against which the d= signing-domain and envelope-MAIL-FROM domain were aligned — providing per- subdomain <header_from> attribution to the publisher's sp=-tag subdomain-policy coordination evidence stream THIS page documents as the subdomain-vs-org- domain alignment-mode coordination primitive; (iv) multiple- <auth_results><dkim> entries per-row reflecting the any-aligns-wins evaluation rule — the receiver-emitted per-row XML records EACH DKIM signature evaluated against the message (publisher's own signature + downstream-relay-resigner signature + ARC-signer signature), each in its own <auth_results><dkim> block — the per-row XML preserves the any-aligns-wins evaluation evidence THIS page documents as the load-bearing DKIM-side-alignment-pass-via-multiple- signatures-disjunction primitive for diagnosing transactional-ESP / mailing-list / forwarder-induced alignment-evaluation outcomes. Read the aggregate-reports spoke ALONGSIDE this alignment-mechanics reference to close the feedback loop between the per- message alignment-evaluation algorithm and the per-receiver per-day per-row XML evidence stream the algorithm produces at every receiver.
• DMARC forensic / failure reports — the per-message alignment-fail- triggered AFRF forensic-evidence-capture pipeline companion to this DMARC alignment-mechanics reference. Where THIS page documents the RFC 7489 §3.1 identifier-alignment contract (the per-message DKIM-aligned-pass / SPF-aligned-pass disjunction at the per-receiver evaluation boundary, the per-publisher adkim=r|s + aspf=r|s relaxed/strict alignment-mode publication commitments, the per-receiver per- message alignment-evaluation algorithm producing per-row <auth_results> aggregate-XML evidence), the forensic- reports spoke documents the structurally-distinct PER-MESSAGE AFRF (Abuse Feedback Report Format, RFC 6591) forensic-evidence-capture publication-discipline DOWNSTREAM CONSUMER of the per-message alignment- fail evaluation this alignment- mechanics reference's per-message algorithm produces. Four PER-MESSAGE- ALIGNMENT-FAIL-TO-AFRF-CAPTURE coupling dimensions the forensic- reports spoke documents that THIS page's per-message alignment- evaluation algorithm is the upstream receiver-side trigger for: (i) per-publisher fo=0 failure-option as complete-alignment-fail AFRF trigger — the per-publisher fo=0 publication choice produces AFRF forensic-evidence ONLY when BOTH per-message DKIM-aligned- pass AND per-message SPF-aligned-pass evaluate to fail, the canonical alignment-disjunction-zero outcome this alignment-mechanics page's algorithm produces; (ii) per-publisher fo=1 failure-option as underlying-mechanism-fail AFRF trigger — the per-publisher fo=1 publication choice produces AFRF on ANY per-message underlying-mechanism fail (even when the per-message alignment-disjunction evaluates to pass), giving the per- publisher visibility into per-message SPF-pass-but-misaligned and DKIM- pass-but-misaligned per-message outcomes this alignment-mechanics page's algorithm distinguishes; (iii) per-publisher fo=d failure-option as DKIM-fail-only AFRF trigger — the per-publisher fo=d publication choice produces AFRF on per-message DKIM-fail (whether aligned or not), giving the per- publisher per-message visibility into the per-publisher per-selector DKIM- signing failures this alignment- mechanics page's per-message DKIM- aligned-pass evaluation depends on; (iv) per-publisher fo=s failure-option as SPF-fail-only AFRF trigger — the per-publisher fo=s publication choice produces AFRF on per-message SPF-fail (whether aligned or not), giving the per-publisher per-message visibility into the per- publisher per-source-IP authorisation failures this alignment-mechanics page's per-message SPF-aligned-pass evaluation depends on. Read the forensic-reports spoke alongside this alignment-mechanics reference whenever per-publisher per-message alignment- evaluation outcomes need per-message diagnostic detail beyond the per-row aggregate-XML evidence — the per- publisher per-message alignment-fail algorithm THIS page documents is the upstream receiver-side trigger criterion the forensic-reports spoke's per-message AFRF-evidence- capture pipeline downstream-consumes for every per-receiver per-message AFRF emission that materialises into the per-publisher ruf-mailbox.
• Email Header Analyzer — paste any email's headers and see SPF, DKIM, DMARC results PLUS the alignment evaluation against the From: domain.
• Domain Security Checker — live DNS lookups for DMARC, SPF, DKIM, and the full DNS-security stack against any domain.
• DMARC troubleshooting — the SYMPTOM-DRIVEN ALIGNMENT-FAILURE- DIAGNOSIS companion to THIS identifier- alignment-contract reference. Where THIS page documents the RFC 7489 §3.1 identifier- alignment contract (the RFC5322.From domain MUST align with EITHER the SPF-authenticated RFC5321.MailFrom domain UNDER the strict/relaxed mode the aspf= tag selects, OR the DKIM-signing d= tag domain UNDER the strict/relaxed mode the adkim= tag selects) as the PROTOCOL-FOUNDATION-LAYER rule, the troubleshooting spoke documents the SYMPTOM-DRIVEN debugging playbook for the #1 receiver-side dmarc=fail root-cause family this page's alignment contract is the protocol foundation for. Four ALIGNMENT-CONTRACT-VS-TROUBLESHOOTING- PLAYBOOK axes the troubleshooting spoke documents that THIS page is the protocol foundation for: (1) SPF-aligned-but- not-DMARC-aligned root cause — the troubleshooting spoke's "DMARC = fail despite SPF = pass" symptom-catalogue traces the per-message Authentication-Results spf=pass smtp.mailfrom=<esp.com> with header.From=<tenant.com> to the SPF-RFC5321.MailFrom-vs-RFC5322.From divergence root cause this page's identifier- alignment contract defines as a structural consequence; (2) DKIM-signed-but-not- DMARC-aligned root cause — the troubleshooting spoke's "DMARC = fail despite DKIM = pass" symptom-catalogue traces the per-message Authentication-Results dkim=pass d=<esp-signing-domain.com> with header.From=<tenant.com> to the DKIM-d-tag-vs-RFC5322.From divergence root cause this page's adkim=r-vs-adkim=s contract resolves; (3) forwarder- induced alignment cascade — the troubleshooting spoke's "DMARC = fail on Gmail-forwarded message" symptom-catalogue traces the forwarder-induced SPF-failure + DKIM-body-hash-rewrite cascade through this page's identifier-alignment contract to the forwarder-MUST-emit-ARC-signature remediation (RFC 8617); (4) relaxed-vs-strict alignment-mode diagnostic — the troubleshooting spoke's "DMARC = fail on subdomain" symptom-catalogue traces the per-message header.From=<sub.tenant.com> AGAINST the aspf=s-vs-aspf=r + adkim=s-vs-adkim=r published-tag-state through this page's organisational-domain-vs-exact-match alignment-mode contract. Read THIS page to UNDERSTAND the alignment contract; read the troubleshooting spoke when DIAGNOSING the per-symptom alignment-failure-root-cause- attribution the contract makes possible.
• DMARC multi-domain strategy — the PER-ORG-DOMAIN-AND-PER- SUBDOMAIN-COORDINATION companion to this alignment-mechanics reference. Where THIS page documents the SINGLE- message identifier-alignment algorithm (the adkim=r/adkim=s DKIM-side organisational-domain-vs- FQDN-literal-equality contract, the aspf=r/aspf=s SPF-side mirror contract, the any- aligns-wins DKIM multi-signature evaluation rule, the M365 tenant.onmicrosoft.com gotcha, the Workspace gappssmtp.com gotcha), the multi-domain-strategy spoke is the PER-ORG-DOMAIN AND PER-SUBDOMAIN COORDINATION REFERENCE documenting how the same identifier-alignment contract multiplies across every distinct Friendly-From-header organisational domain a multi-brand publisher emits under PLUS every sibling subdomain under each operator- published org-domain. Concretely the spoke documents FOUR per-org-domain- publication-discipline-vs-alignment- contract dimensions: (i) per- org-domain apex _dmarc.<org-domain> TXT-RR adkim= / aspf= tag-byte publication runs INDEPENDENTLY per Friendly-From- header organisational domain — every distinct brand / business- unit / acquired-company org-domain the multi-brand publisher emits under requires its OWN per-org-domain adkim= / aspf= tag-byte publication-discipline commitment, and per-org-domain adkim=s-strict-mode vs adkim=r-relaxed-mode choice runs INDEPENDENTLY per-org- domain because each per-org-domain legitimate-sender population has per-org-domain organisational-domain- extraction characteristics; (ii) adkim=s-strict- mode publication discipline is the per-org-domain structural defense against the cousin-domain DKIM signing attacker-bypass class every multi-brand publisher must apply across every operator- published org-domain — the multi-domain-strategy spoke documents the per-org-domain adkim=s-strict-mode publication-discipline coordination the multi-brand publisher must apply to defeat the cousin-domain-DKIM- signing-with-attacker-controlled- key bypass technique that adkim=r-relaxed-mode organisational-domain-extraction false-accepts under Public-Suffix- List rules; (iii) per- subdomain sp=-tag inheritance vs override coordination across every sibling subdomain under every operator-published org-domain is the PER-SUBDOMAIN ALIGNMENT- CONTRACT EXTENSION — the per-org-domain apex _dmarc TXT-RR sp=-tag publication governs the per-subdomain inheritance contract receivers apply when evaluating mail emitted from <sub>.<org-domain> subdomains, and the per-subdomain alignment evaluation runs the SAME identifier-alignment algorithm this page documents but against the per- subdomain published policy via sp=-tag inheritance — the multi-domain-strategy spoke documents the per-subdomain publication-discipline gap-closure coordination every multi-brand publisher must apply to defeat the parked-subdomain-traversal attacker-bypass class under sp=none default inheritance; and (iv) per- org-domain rua=-tag aggregate-report stream surfaces per-org-domain identifier-alignment gap evidence per-source-IP per-day the multi-brand publisher consults per-org-domain INDEPENDENTLY — per-org-domain RUA evidence keyed by per-row <header_from> attribution surfaces per-org-domain identifier-alignment failures the per-org-domain adkim=/aspf= tag-byte publication must close, and the multi-domain-strategy spoke documents the per-org-domain evidence-consultation contract every multi-brand publisher must apply when coordinating cross-org-domain alignment posture. Read the multi- domain-strategy spoke ALONGSIDE this alignment-mechanics reference when authoring the multi-brand publisher's per-org-domain coordination playbook — the spoke documents how the per-message identifier-alignment contract THIS page establishes multiplies across every Friendly- From-header org-domain plus every sibling subdomain the multi-brand publisher emits under.
• SPF forwarding issues — the PER-FORWARDER-ENVELOPE-REWRITE-AS- SPF-ALIGNMENT-LOSS-ROOT-CAUSE-CLASS companion to this DMARC-alignment reference. Where THIS page documents the RFC 7489 §3.1 SPF-alignment and DKIM- alignment identifier-matching contract (relaxed-mode organisational-domain match vs strict-mode exact-FQDN match, aspf= and adkim= per-tag publication discipline), the SPF-forwarding-issues spoke is the CANONICAL-SPF-ALIGNMENT-LOSS-ROOT-CAUSE catalogue documenting how the per- forwarder envelope-MAIL-FROM rewrite breaks the SPF-alignment match THIS page defines at FOUR per-forwarding-hop envelope-rewrite-to-SPF-alignment-loss coupling dimensions: (i) per- mailing-list-expander envelope-MAIL-FROM rewrite to the list's bounce-handler domain breaks the SPF-MAIL-FROM-vs- Header-From relaxed-alignment match unconditionally — even when the publisher's SPF record passes for the list's bounce-handler IP topology, the rewritten envelope MAIL-FROM no longer shares an organisational domain with the original Header-From; the SPF-forwarding- issues spoke catalogues this canonical mailing-list-induced SPF-alignment failure root-cause class that the alignment contract THIS page defines is the receiver- side evaluation gate for; (ii) per- account-forwarding (Gmail, .forward, Outlook rules) envelope-MAIL-FROM rewrite produces SPF-pass-but-misaligned outcomes the receiver-side aspf=relaxed mode cannot rescue — the forwarding-account's envelope-MAIL-FROM domain is structurally orthogonal to the original Header-From's organisational domain, so even SPF-pass at the forwarder's own IP topology cannot satisfy the relaxed-alignment match THIS page documents; the SPF-forwarding-issues spoke catalogues the per-account-forwarding envelope- rewrite signature whose receiver-side SPF- alignment-loss is the root-cause class the alignment evaluator on THIS page rejects; (iii) per-SRS-rewriter Sender Rewriting Scheme deployment as the canonical per-forwarder envelope-MAIL-FROM rescue primitive that explicitly orphans the downstream SPF-alignment-with-Header-From signal — SRS rescues envelope- layer SPF at the forwarder's own IP topology BUT the rewritten SRS-encoded envelope-MAIL-FROM cannot organisationally- match the original Header-From, leaving DKIM-alignment as the only DMARC-alignment path the receiver-side evaluator on THIS page can satisfy; the SPF-forwarding-issues spoke catalogues SRS as the per-forwarder operational primitive whose SPF-alignment orphaning is structurally inherent; (iv) per-forwarder ARC-chain sealing as the receiver-side cross-hop authentication- results-evidence preservation primitive that propagates the ORIGINATING-hop SPF- alignment verdict through subsequent forwarding hops — the SPF- forwarding-issues spoke catalogues ARC- sealing as the receiver-side cross-hop evidence-preservation primitive whose per-hop SPF-alignment-verdict propagation is the canonical receiver-side forwarded- message rescue path the alignment evaluator on THIS page can consume in place of the (broken) direct envelope- MAIL-FROM-vs-Header-From alignment match. Read the SPF-forwarding-issues spoke alongside this DMARC-alignment reference when scoping the per-forwarded-message SPF-alignment-loss root-cause classes every receiver-side DMARC evaluator encounters at scale.
• SPF for Microsoft 365 — the PER-M365-TENANT-SPF-PUBLICATION-AS- SPF-ALIGNMENT-VERDICT-INPUT companion to this DMARC-alignment reference. Where THIS page documents the RFC 7489 §3.1 SPF- alignment and DKIM-alignment identifier- matching contract (relaxed-mode organisational-domain match vs strict-mode exact-FQDN match), the SPF-for-Microsoft- 365 spoke is the PER-TENANT PUBLICATION DISCIPLINE catalogue documenting how the per-M365-tenant SPF publication topology determines the receiver-side SPF-alignment verdict at FOUR per-M365-tenant-publication- discipline-to-SPF-alignment-verdict coupling dimensions: (i) per-M365-tenant include:spf.protection.outlook.com cascade publication as message-layer SPF input to aspf= alignment match-mode — every M365 tenant whose SPF record includes the spf.protection.outlook.com macro inherits the cascade's per-tenant outbound IP-pool topology, which the receiver-side SPF- alignment evaluator on THIS page consumes as the load-bearing SPF-pass precondition before relaxed-or-strict alignment match- mode runs; (ii) per-M365-tenant SPF-coverage completeness as load-bearing precondition for safe per-tenant p=quarantine or p=reject rollout — the per-tenant Exchange Online inbound and outbound smarthost / mail-flow-connector IP topology must be exhaustively published in the per-tenant SPF record for the DMARC-alignment evaluator on THIS page to produce stable SPF-alignment-pass verdicts; gaps in the per-tenant SPF publication produce intermittent SPF-alignment-fail verdicts that destabilise downstream DMARC policy enforcement; (iii) per-M365- tenant per-subdomain SPF publication as per-subdomain SPF-alignment input to sp= subdomain-policy coordination — every per-tenant subdomain whose marketing-mail, ticketing, or transactional-mail flow emits from a distinct M365 sub-tenant requires per- subdomain SPF publication for the SPF- alignment evaluator on THIS page to produce per-subdomain SPF-alignment-pass; the per- tenant per-subdomain SPF publication discipline the SPF-for-M365 spoke catalogues is the per-subdomain SPF- alignment input every sp= subdomain-policy publisher this page documents depends on; (iv) per- M365-tenant -all qualifier publication as per-tenant SPF-fail commitment to receiver-side DMARC- alignment-fail enforcement — the per-tenant SPF record's tail-mechanism qualifier (-all hard-fail vs ~all soft-fail vs ?all neutral) is the per- tenant publication commitment that directly determines whether the receiver- side SPF-alignment-fail verdict on THIS page produces a DMARC-aligned fail result or a softer policy result; the per-tenant qualifier discipline the SPF-for-M365 spoke catalogues is the per-tenant publication commitment every receiver-side DMARC-alignment evaluator on THIS page consumes. Read the SPF-for-Microsoft-365 spoke alongside this DMARC-alignment reference when scoping the per-M365-tenant SPF publication discipline the receiver- side SPF-alignment verdict on THIS page structurally depends on.
• DKIM replay attacks — the DKIM-REPLAY-ATTACK-AS-CANONICAL- EXPLOITATION-OF-VALID-DKIM-ALIGNED-PASS- VERDICT-AGAINST-THE-IDENTIFIER-ALIGNMENT- CONTRACT-THIS-PAGE-DOCUMENTS companion documenting how the DKIM-replay attack- class catalogued in RFC 6376 §8.6 (an attacker captures a legitimately-signed DKIM message and re-injects identical body+signature bytes into the SMTP stream addressed to a new recipient cohort) STRUCTURALLY EXPLOITS the per-message DKIM-aligned-pass verdict contract THIS identifier-alignment reference documents the load-bearing evaluation algorithm of. Where THIS page documents the per-message RFC 7489 §3.1 identifier-alignment evaluation (per-row SPF-aligned-pass via envelope- MAIL-FROM organisational-domain matching Friendly-From-header org-domain + per- row DKIM-aligned-pass via signing- domain d= tag organisational-domain matching Friendly- From-header org-domain + per-row adkim= / aspf= strict-vs-relaxed-alignment mode), the DKIM-replay-attacks spoke is the per- message-replay-attack-class reference whose threat-model exploits the cryptographic-validity-preservation property of DKIM signatures across replay-hop boundaries at four DKIM- replay-attack-vs-DMARC-identifier- alignment-contract coupling dimensions: (i) DKIM-aligned-pass verdict survives the replay-hop boundary cryptographically intact → replay- injected message produces dkim=aligned-pass verdict even though the attacker is not the legitimate publisher — the per-message DKIM signature this page's alignment evaluation consumes is cryptographically VALID across the replay boundary because the original publisher's per-selector private-key signed the body+headers, and the replay attacker does NOT need to re-sign the message (just re-emit the bytes); the per-receiver per- message DKIM verification produces dkim=aligned-pass verdict for the replay-injected message at the receiver, satisfying the identifier-alignment-disjunction this page documents as the per-message DMARC-pass condition; (ii) per- message identifier-alignment-pass at the replayed publisher's per-domain org-domain → receiver-side per- message DMARC-pass verdict permits the replayed message past p=reject enforcement — once the replay- injected message produces dkim=aligned-pass per the evaluation algorithm THIS page documents, the per-message DMARC verdict is dmarc=pass at the replayed publisher's per-domain organisational-domain regardless of the publisher's per-domain p=reject / p=quarantine / p=none policy — the publisher's per-domain enforcement policy this page's alignment-evaluation feeds into does NOT prevent the replay-injected message from being delivered, even though the publisher never authorised the replay-hop's per- connecting-IP source; (iii) per- publisher rate-limit-tag (t= signature-tag timestamp or x= signature-tag expiration) as load- bearing per-publisher per-message replay-mitigation primitive at the DKIM-signature-publication layer — the per-publisher per-message DKIM signature this page's alignment evaluation consumes optionally carries the RFC 6376 §3.5 t=<timestamp> + x=<expiration> signature tags whose per-receiver validation enforces per-message- signature-time-bounded validity; per- publisher per-domain DKIM-signing infrastructure that publishes x=-bounded signatures constrains the replay-attack-window this DKIM-replay-attacks spoke documents the threat-model of — making the per-publisher per-message t=/x=-tag publication discipline the load-bearing per-message per-receiver replay- mitigation primitive the DMARC identifier-alignment-pass verdict this page documents structurally depends on for replay-attack-resistant per-message DMARC-pass attribution; (iv) per- receiver per-publisher per-source-IP aggregate-XML row distribution as load- bearing replay-attack-detection signal the per-publisher per-domain DMARC monitoring KPI dashboard consumes — when a per-publisher per-domain DKIM-aligned-pass verdict surfaces in the per-receiver per-source-IP aggregate-XML stream from a per-source- IP NOT in the publisher's per-domain authorised infrastructure (canonical replay-attack signature in the aggregate-XML cohort), the per- publisher per-domain monitoring KPI dashboard surfaces the per-source-IP replay-cohort as a per-receiver per- publisher per-source-IP DKIM-aligned- pass-rate distribution anomaly the per-publisher operator must investigate as a potential DKIM-replay-attack cohort; the per-publisher per-domain identifier-alignment-evaluation this page documents is the upstream verdict- producer that surfaces the per-source-IP replay-cohort signal in the per- publisher per-domain aggregate-XML downstream consumer KPI cohort. Read the DKIM-replay-attacks spoke alongside this identifier-alignment reference when scoping per-publisher per-message per-receiver replay-mitigation discipline, per-publisher t=/x=-tag DKIM-signature-publication choice, per- publisher per-source-IP replay-cohort detection in the aggregate-XML observability stream, and per-publisher per-domain replay-attack-resistance evaluation across the per-domain DKIM- signing-infrastructure posture this page's alignment-evaluation structurally depends on.
• DKIM canonicalization — the PER-PUBLISHER-PER-MESSAGE- CANONICALIZATION-ALGORITHM-CHOICE- AS-LOAD-BEARING-DETERMINANT-OF- DKIM-SIGNATURE-SURVIVAL-ACROSS-PER- FORWARDER-HOP-MODIFICATIONS companion to this DMARC alignment evaluation reference. Where THIS page documents the receiver-side DMARC-alignment evaluation algorithm consuming the per-message spf= and dkim= verdicts + the per-message d= signing-domain + the per-message Header-From domain to produce the per-message DMARC- aligned-pass / DMARC-aligned-fail verdict, the DKIM-canonicalization spoke is the STRUCTURALLY-UPSTREAM per-publisher per-message canonicalization-algorithm-choice- publication-discipline reference whose RFC 6376 §3.4 simple-vs- relaxed canonicalization-algorithm- pair primitive published in the per- message DKIM-Signature header's c=-tag (header-canon / body-canon pair) directly determines whether the per-message DKIM signature survives per-forwarder-hop header-and-body modifications to produce the dkim=pass verdict THIS page's alignment-evaluation consumes as its load-bearing message-layer- authentication-input. The DKIM- canonicalization-vs-DMARC-alignment cross-layer coupling establishes four specific per-publisher canonicalization- choice-to-alignment-evaluation dimensions: (i) per-publisher c=simple/simple canonicalization choice as load- bearing precondition for per-message dkim=fail verdict on per-forwarder- hop header-rewrite OR body-whitespace- normalization — simple canonicalization treats any header or body modification as signature- breaking; per-forwarder-class mailing-list-footer-injection / Subject-prefix-rewrite (e.g., [list-name] / Re: ) / Content-Type- boundary-normalization produces dkim=fail at the receiver, which removes the per-publisher signature from the DMARC alignment-candidate set even when the per-publisher d=/ Header-From identifier-alignment would otherwise pass; (ii) per-publisher c=relaxed/relaxed canonicalization choice as load- bearing precondition for per-message dkim=pass verdict survival across per-forwarder-hop whitespace-folding + header-case-normalization — relaxed canonicalization folds repeated whitespace + normalizes header-field-name case + strips trailing CRLF + trailing-empty-line body normalization; per-forwarder- class header-line-rewrap / body- whitespace-pretty-print survives dkim verification to produce dkim=pass, which DOES enter the DMARC alignment-candidate set THIS page's algorithm evaluates; (iii) per-publisher canonicalization-choice-driven per-receiver per-forwarder-class dkim-pass-rate distribution as load-bearing per-source-IP observability signal feeding DMARC- alignment-rate KPI — per- publisher c= choice published in every per-message DKIM-Signature header drives per-receiver per- forwarder-IP dkim-pass-rate distribution visible in per- receiver rua aggregate-XML rows; per-publisher canonicalization- choice change (simple → relaxed as part of mailing-list-survival discipline) directly lifts per- publisher per-forwarder-class DMARC-aligned-pass-rate the alignment-evaluation algorithm THIS page documents observes; (iv) per-publisher canonicalization-choice as load- bearing per-publisher cross- receiver alignment-evaluation deterministic-input constraint — per-publisher c= publication discipline (canonicalization choice consistent across all per-publisher d= signing-domain selectors) ensures per-publisher per-message DKIM-verification is deterministically evaluated by per-receiver alignment- evaluation algorithm; per-publisher canonicalization-drift (different c= choice across per-publisher selectors / per-tenant DKIM-signing infrastructure) introduces per- publisher per-receiver dkim-pass- rate variance that degrades the per-publisher cross-receiver DMARC- aligned-pass-rate KPI THIS page's alignment-evaluation algorithm consumes. Read the DKIM- canonicalization spoke alongside this DMARC alignment reference when investigating per-publisher per-forwarder-class dkim=fail cohorts whose root-cause is per- publisher canonicalization-choice mismatch with per-forwarder-hop header-and-body modification discipline, and when planning per- publisher per-DKIM-signing- infrastructure canonicalization- algorithm migration (typically simple → relaxed for per-publisher mailing-list-survival posture) whose impact on per-publisher DMARC-aligned-pass-rate is observable in per-receiver rua aggregate-XML per-source-IP per- forwarder-class distribution THIS page's alignment-evaluation algorithm structurally produces.
• BIMI SVG Tiny PS requirements — the PER-PUBLISHER-PER-DOMAIN-DISPLAY- LAYER-LOGO-PUBLICATION-PRIMITIVE-DOWNSTREAM- OF-DMARC-ALIGNED-PASS-VERDICT companion to this DMARC alignment reference. Where THIS page documents the per-message DMARC- identifier-alignment-evaluation algorithm (the strict-vs-relaxed alignment-mode choice, the SPF-aligned-vs-DKIM-aligned verdict composition, the Public-Suffix-List relaxed-alignment-mode evaluation, the per-publisher per-domain DMARC-aligned-pass verdict production), the BIMI-SVG-Tiny-PS- requirements spoke documents the per- publisher per-domain display-layer consumer of every per-message DMARC- aligned-pass verdict at FOUR per-message DMARC-alignment-to-BIMI-display-eligibility coupling dimensions: (i) per- message DMARC-aligned-pass verdict as load-bearing precondition for per-message BIMI SVG-Tiny-PS render at per-receiver inbox display-layer — per RFC 9077 §3, BIMI display-eligibility requires that the per-message DMARC verdict be pass with per-publisher per- domain p=quarantine or p=reject enforcement posture; the per-publisher per-domain BIMI SVG Tiny PS file published at the per-domain l=<svg-url> location the per-domain BIMI DNS record references is NEVER fetched / rendered by Gmail / Apple Mail / Yahoo / Fastmail unless the per-message DMARC-alignment-evaluation algorithm THIS page documents produces pass on that specific per-message envelope at receiver-side evaluation time — per-publisher per- domain SVG Tiny PS profile publication discipline is operationally moot at the per-message render boundary if the per- message DMARC-alignment-evaluation produces fail; (ii) per-publisher per-domain relaxed-vs-strict alignment- mode (aspf=r / aspf=s and adkim=r / adkim=s) choice as load-bearing per-publisher per-domain BIMI-display-scope determinant across subdomain-mail-stream cohorts — per-publisher aspf=r relaxed-mode publication widens the per- publisher per-domain DMARC-aligned-pass scope to per-subdomain mail (per-receiver evaluating marketing.brand.com sender against organisational-domain brand.com per-publisher BIMI record) while aspf=s strict- mode constrains BIMI display-eligibility to exact-FQDN-match per-message envelopes only; per-publisher per-domain alignment- mode choice the alignment-evaluation algorithm THIS page documents directly determines per-publisher per-subdomain BIMI-display-coverage KPI for marketing / transactional / notification mail-streams the per-publisher per-domain SVG Tiny PS profile the BIMI-SVG-requirements spoke documents publishes; (iii) per- publisher per-forwarder-class ARC- validated DMARC-alignment-pass- preservation as load-bearing upstream condition for per-mailing-list-recipient BIMI display on per-publisher per-domain forwarded mail — per-publisher per-message BIMI display at per-mailing- list-recipient inbox requires the per- forwarder-hop ARC-chain to preserve the per-publisher per-domain DMARC-aligned- pass verdict the alignment-evaluation algorithm THIS page documents originally produced; per-publisher per-forwarder- class ARC-validate failure at per-hop boundary collapses per-publisher per- message BIMI-display-eligibility for every downstream per-mailing-list- recipient envelope — the per-publisher per-domain SVG Tiny PS profile the BIMI- SVG-requirements spoke documents the publisher invested in operationalising is per-mailing-list-forwarder display- scope-collapsed without per-publisher ARC-chain discipline at every per- forwarder hop boundary; (iv) per- publisher per-receiver per-source-IP DMARC-aligned-pass-rate distribution as load-bearing determinant of per-publisher per-domain cross-receiver BIMI-display- coverage KPI — per-publisher per-domain BIMI-display-coverage KPI across the Gmail + Apple Mail + Yahoo + Fastmail receiver-set is the cross- receiver aggregate of per-message DMARC- aligned-pass verdicts THIS page's evaluation algorithm produces; per- publisher per-receiver per-source-IP aligned-pass-rate variance the alignment- evaluation algorithm THIS page documents produces directly drives per-publisher per-receiver BIMI-display-coverage KPI drift the per-publisher per-domain SVG Tiny PS profile publication the BIMI- SVG-requirements spoke documents the publisher operationalised — per- publisher operations team responsible for the per-publisher per-domain BIMI SVG Tiny PS publication discipline must sustain per-message DMARC-alignment-pass discipline the alignment-evaluation algorithm THIS page documents enforces at per-receiver per-source-IP per- forwarder-class granularity as the load-bearing upstream of the per- publisher BIMI-display-coverage KPI the per-publisher SVG Tiny PS publication operationalises. Read the BIMI-SVG- requirements spoke alongside this DMARC alignment reference when planning per- publisher per-domain BIMI deployment whose per-message display-eligibility is directly gated by the per-message DMARC- alignment-evaluation outcome the alignment-evaluation algorithm THIS page documents produces, and when investigating per-publisher per-receiver BIMI-display-coverage variance whose upstream root-cause is per-publisher per- receiver per-source-IP DMARC-aligned- pass-rate variance the alignment- evaluation algorithm THIS page documents structurally produces.
• MTA-STS for Microsoft 365 — the M365-TENANT-MESSAGE-LAYER-DMARC- ALIGNMENT-EVALUATION-AS-LOAD-BEARING- MESSAGE-LAYER-COMPLEMENT-TO-PER-M365-TENANT- TRANSPORT-LAYER-MTA-STS-POLICY-PUBLICATION companion to this DMARC identifier-alignment reference. Where THIS page documents the per-publisher per-message DMARC identifier- alignment evaluation algorithm (the adkim=r/s organizational- domain match vs FQDN match between the DKIM-Signature d=-tag and the RFC 5322 From: author-domain + the aspf=r/s match between the SMTP envelope MAIL FROM domain and the From: author-domain + the disjunction to produce the per-message DMARC-aligned- pass verdict), the mta-sts-for-microsoft- 365 spoke is the STRUCTURALLY-PARALLEL transport-layer publication-discipline reference whose per-M365-tenant per-domain MTA-STS-policy-file publication at mta-sts.<d> HTTPS well-known-path + _mta-sts.<d> TXT-RR publication discipline is the load- bearing transport-layer publication- discipline complementary to the message- layer DMARC-alignment-evaluation publication THIS page documents at four cross-layer M365-tenant publication-discipline coupling dimensions: (i) Per-M365-tenant per-message message-layer DMARC-aligned- pass verdict vs per-M365-tenant per-MX- host transport-layer MTA-STS-policy-driven- TLS-handshake-success-rate cross-layer composition — the per-message DMARC-alignment-evaluation verdict THIS page documents (the message-layer per-publisher per-domain author-domain- attribution evidence the receiver-side DMARC-evaluator consumes) composes with the per-MX-host MTA-STS-policy-driven STARTTLS-handshake-success-rate evidence the mta-sts-for-microsoft-365 spoke documents (the transport-layer per- publisher per-domain per-MX-host confidentiality-and-cert-trust-attestation evidence) into the per-M365-tenant per- domain complete-cross-layer-publication- coverage the Gmail+Yahoo Bulk Sender Requirements 2024 compliance-gate evaluates at the per-publisher per- receiver per-message gate-boundary; (ii) Per-M365-tenant message-layer adkim-and-aspf-tag publication + per-M365- tenant transport-layer MTA-STS-policy- mode-and-max_age publication parallel — the per-publisher per-domain message- layer adkim=r/s + aspf=r/s tag publication discipline THIS page documents (the operator-side per-publisher relaxed-vs- strict alignment-mode choice) is STRUCTURALLY PARALLEL to the per-M365- tenant per-domain transport-layer mode: testing/enforce + max_age: tag publication discipline the mta-sts-for-microsoft-365 spoke documents (the operator-side per- tenant transport-layer testing-to-enforce mode-progression discipline); both publication-disciplines are per-publisher per-domain operator-controlled stage-gate publications at the per-tenant per-domain DNS-zone-management surface; (iii) Per-M365-tenant message-layer- DMARC-aligned-pass-rate per-receiver per- source-IP rua-row distribution + per-M365- tenant transport-layer-TLS-RPT-JSON per-receiver per-MX-host per-failure- class evidence-row distribution cross- layer observability composition — the per-message DMARC-aligned-pass-rate observability surface THIS page documents (rua aggregate-XML per-receiver per- source-IP per-day per-disposition row distribution) composes with the per-MX- host TLS-handshake-success-rate observability surface (TLS-RPT-JSON per- receiver per-MX-host per-failure-class per-day row-emission discipline per RFC 8460 §3.1) the mta-sts-for-microsoft-365 spoke's transport-layer publication- discipline produces; both per-tenant per- domain observability surfaces are operator- consumed for per-M365-tenant per-domain cross-layer publication-discipline-stack health-monitoring; (iv) Per-M365- tenant per-domain cross-layer publication- discipline-stack composition as load- bearing M365-tenant complete-publication- coverage — the per-M365-tenant per-domain complete cross-layer publication- discipline-stack composes message-layer (DMARC-alignment-evaluation THIS page documents + per-tenant DKIM + per-tenant SPF + DMARC-disjunction publication) with transport-layer (MTA-STS-policy-file at mta-sts.<d> HTTPS well-known-path the mta-sts-for-microsoft- 365 spoke documents + TLS-RPT-publication- with-rua-mailbox-evidence-collection- stream) into the per-M365-tenant per- domain complete-cross-layer publication- coverage at the per-publisher per-message- survival-across-forwarder-and-transport- class-and-receiver-class boundaries every per-publisher per-receiver per-message Bulk Sender Requirements 2024 compliance- gate evaluation consumes. Read the mta- sts-for-microsoft-365 spoke ALONGSIDE this DMARC-alignment-evaluation reference whenever the protected domain is hosted on the M365 Exchange Online cloud tenant and the per-message message-layer DMARC- alignment-evaluation algorithm THIS page documents needs an M365-tenant-specific cross-layer publication-discipline-stack composition baseline for end-to-end authentication-and-confidentiality survival across the per-publisher per- message per-receiver per-MX-host boundary.
• MTA-STS for Google Workspace — the WORKSPACE-TENANT-MESSAGE-LAYER-DMARC- ALIGNMENT-EVALUATION-AS-LOAD-BEARING-MESSAGE- LAYER-COMPLEMENT-TO-PER-WORKSPACE-TENANT- TRANSPORT-LAYER-MTA-STS-POLICY-PUBLICATION companion to this DMARC identifier-alignment reference. Where THIS page documents the per-publisher per-message DMARC identifier- alignment evaluation algorithm (the adkim=r/s organizational- domain match vs FQDN match between the DKIM-Signature d=-tag and the RFC 5322 From: author-domain + the aspf=r/s match between the SMTP envelope MAIL FROM domain and the From: author-domain + the disjunction to produce the per-message DMARC-aligned- pass verdict), the mta-sts-for-google- workspace spoke is the STRUCTURALLY-PARALLEL transport-layer publication-discipline reference whose per-Workspace-tenant per-domain MTA-STS-policy-file publication at mta-sts.<d> HTTPS well-known-path + _mta-sts.<d> TXT-RR publication discipline (per Workspace's Admin Console + DNS-zone- management surface, with Workspace MX targets aspmx.l.google.com + the four altN.aspmx.l.google.com hosts as the per-MX-host transport-layer STARTTLS-cert-trust evaluation boundary) is the load-bearing transport-layer publication- discipline complementary to the message- layer DMARC-alignment-evaluation publication THIS page documents at four cross-layer Workspace-tenant publication-discipline coupling dimensions: (i) Per- Workspace-tenant per-message message-layer DMARC-aligned-pass verdict vs per-Workspace- tenant per-MX-host transport-layer MTA-STS- policy-driven-TLS-handshake-success-rate cross-layer composition — the per- message DMARC-alignment-evaluation verdict THIS page documents (the message-layer per- publisher per-domain author-domain- attribution evidence the receiver-side DMARC-evaluator consumes) composes with the per-MX-host MTA-STS-policy-driven STARTTLS- handshake-success-rate evidence the mta-sts- for-google-workspace spoke documents (the transport-layer per-publisher per-domain per-MX-host confidentiality-and-cert-trust- attestation evidence at the five-host Workspace MX tier) into the per-Workspace- tenant per-domain complete-cross-layer- publication-coverage the Gmail+Yahoo Bulk Sender Requirements 2024 compliance-gate evaluates at the per-publisher per-receiver per-message gate-boundary; (ii) Per- Workspace-tenant message-layer adkim-and- aspf-tag publication + per-Workspace-tenant transport-layer MTA-STS-policy-mode-and- max_age publication parallel — the per-publisher per-domain message-layer adkim=r/s + aspf=r/s tag publication discipline THIS page documents (the operator-side per-publisher relaxed-vs-strict alignment-mode choice) is STRUCTURALLY PARALLEL to the per-Workspace- tenant per-domain transport-layer mode: testing/enforce + max_age: tag publication discipline the mta-sts-for-google-workspace spoke documents (the operator-side per- tenant transport-layer testing-to-enforce mode-progression discipline at the Workspace Admin Console boundary); both publication- disciplines are per-publisher per-domain operator-controlled stage-gate publications at the per-tenant per-domain DNS-zone- management surface; (iii) Per- Workspace-tenant message-layer-DMARC-aligned- pass-rate per-receiver per-source-IP rua- row distribution + per-Workspace-tenant transport-layer-TLS-RPT-JSON per-receiver per-MX-host per-failure-class evidence-row distribution cross-layer observability composition — the per-message DMARC- aligned-pass-rate observability surface THIS page documents (rua aggregate-XML per- receiver per-source-IP per-day per- disposition row distribution) composes with the per-MX-host TLS-handshake-success-rate observability surface (TLS-RPT-JSON per- receiver per-MX-host per-failure-class per- day row-emission discipline per RFC 8460 §3.1) the mta-sts-for-google-workspace spoke's transport-layer publication- discipline produces; both per-tenant per- domain observability surfaces are operator- consumed for per-Workspace-tenant per- domain cross-layer publication-discipline- stack health-monitoring; (iv) Per- Workspace-tenant per-domain cross-layer publication-discipline-stack composition as load-bearing Workspace-tenant complete- publication-coverage — the per- Workspace-tenant per-domain complete cross- layer publication-discipline-stack composes message-layer (DMARC-alignment-evaluation THIS page documents + per-tenant DKIM at google._domainkey.<d> + per-tenant SPF at include:_spf.google.com + DMARC-disjunction publication) with transport-layer (MTA-STS-policy-file at mta-sts.<d> HTTPS well-known-path the mta-sts-for-google- workspace spoke documents + TLS-RPT- publication-with-rua-mailbox-evidence- collection-stream) into the per-Workspace- tenant per-domain complete-cross-layer publication-coverage at the per-publisher per-message-survival-across-forwarder-and- transport-class-and-receiver-class boundaries every per-publisher per-receiver per-message Bulk Sender Requirements 2024 compliance- gate evaluation consumes. Read the mta-sts- for-google-workspace spoke ALONGSIDE this DMARC-alignment-evaluation reference whenever the protected domain is hosted on the Google Workspace cloud tenant and the per- message message-layer DMARC-alignment- evaluation algorithm THIS page documents needs a Workspace-tenant-specific cross- layer publication-discipline-stack composition baseline for end-to-end authentication-and-confidentiality survival across the per-publisher per-message per- receiver per-MX-host boundary.
• DKIM failures explained — the DKIM-VERDICT-CLASS-TAXONOMY-AS-LOAD- BEARING-UPSTREAM-INPUT-TO-DMARC-ALIGNMENT- EVALUATION-ALGORITHM companion to this DMARC-alignment-evaluation reference. Where THIS page documents the DMARC-alignment- evaluation algorithm (per-message adkim=r/s relaxed-vs-strict DKIM-d-domain-vs-From- organisational-domain match + per-message aspf=r/s relaxed-vs-strict SPF-MAIL-FROM- domain-vs-From-organisational-domain match), the DKIM-failures-explained spoke is the UPSTREAM RFC 6376 §3.9 receiver-side DKIM verdict-class taxonomy whose four verdict keywords (bodyhash-mismatch / signature-mismatch / permerror / temperror) are the load-bearing gating input every DKIM-side-of-the- disjunction alignment-evaluation pass-or-fail decision THIS page documents structurally consumes at four DKIM-failure-class-to- alignment-evaluation coupling dimensions: (i) per-message bodyhash-mismatch verdict eliminates the DKIM-aligned-pass evaluation path entirely — when the receiver-recomputed body-hash does not match the signature bh= value, the per-message DKIM verdict is fail and the DMARC-alignment-evaluation algorithm THIS page documents never reaches the adkim=r/s d-domain-vs-From-domain match decision on the DKIM side of the DMARC-disjunction — the DMARC-aligned-pass outcome then depends entirely on the SPF-aligned-pass path (per-message MAIL-FROM domain alignment), producing the per-publisher per-message cascade pattern where forwarder-induced body-modification (mailing-list footer injection / link-tracking URL substitution / character-set renormalization) eliminates the DKIM-aligned-pass path and concurrently breaks the SPF-aligned-pass path at the per-forwarder-hop envelope-MAIL-FROM rewrite boundary, yielding per-message DMARC=fail; (ii) per-message signature-mismatch verdict similarly eliminates the DKIM-aligned-pass evaluation path — when the per-message b=-tag RSA-PKCS#1-v1_5 (or Ed25519) signature fails verification against the per-selector public-key TXT record at <selector>._domainkey.<d>, the per-message DKIM verdict is fail and the DMARC-alignment-evaluation algorithm again never reaches the adkim=r/s d-domain- vs-From-domain match decision on the DKIM side — the canonical operational driver is stale-public-key-cache-during-key-rotation- cutover when the publisher rotates the private key but the receiver retains the old public-key TXT record beyond TTL; (iii) per-message permerror verdict as DKIM-aligned-pass path permanent elimination class — permerror is the RFC-7489-§4.6.2-canonical publisher-fault permanent DKIM-evaluation failure-class (DKIM-Signature header syntactically invalid + public-key TXT record cannot be retrieved + DKIM-Signature v=-tag missing-or-unsupported + multi- signature precedence ambiguity) that eliminates DKIM-aligned-pass path evaluation entirely until the publisher corrects the per-publisher per-selector publication-discipline failure — the per-publisher per-domain DKIM-permerror- rate is then a load-bearing observability surface every per-publisher per-message DMARC-aligned-pass-rate KPI tracks; (iv) per-message temperror verdict as per-receiver-fault transient DKIM-aligned-pass-rate volatility-source amplifying SPF-aligned-pass-path operational-criticality — temperror is the RFC-7489-§4.6.3-canonical per-receiver-fault transient DKIM- evaluation failure-class (per-receiver DNS-resolver TXT-record retrieval timeout + intermittent DNS-failure during public- key fetch) producing per-publisher per- domain per-day per-message DKIM-aligned- pass-rate volatility that amplifies the per-publisher operational-criticality of the SPF-aligned-pass path THIS page documents as the parallel alignment evaluation branch — the per-receiver-cohort DKIM-temperror-rate is then a load-bearing receiver-side observability surface every per-publisher per-domain per-receiver- cohort coverage-quality KPI gates on. Read the DKIM-failures-explained spoke ALONGSIDE this DMARC-alignment-evaluation reference whenever an operator triaging a per-publisher per-message DMARC-aligned- pass-rate regression needs the per-message DKIM verdict-class taxonomy whose four failure-class verdicts are the load-bearing UPSTREAM gating input the alignment- evaluation algorithm THIS page documents consumes at the per-message DKIM-side-of- the-disjunction pass-or-fail decision boundary.
• Email authentication glossary — the DMARC-IDENTIFIER-ALIGNMENT- EVALUATION-AS-LOAD-BEARING-CONSUMER- AND-PRODUCER-OF-CANONICAL-DEFINED- TERM-DEFINITIONS companion to this DMARC alignment-evaluation reference. Where THIS page documents the RFC 7489 §3.1 per-message identifier- alignment evaluation algorithm (the DKIM-side-of-the-disjunction evaluation of DKIM-Signature d=-tag vs From-header organisational-domain alignment under the adkim=s strict or adkim=r relaxed alignment-mode, the SPF-side-of-the- disjunction evaluation of envelope- MAIL-FROM-domain vs From-header organisational-domain alignment under the aspf=s strict or aspf=r relaxed alignment-mode, the per-publisher PSL-derived organisational-domain computation per RFC 7489 §3.2), the email-authentication-glossary spoke documents the canonical DefinedTerm JSON-LD reference whose per-term entity-first definition-lede is the upstream-vocabulary substrate every identifier-alignment-evaluation slot this page documents consumes at FOUR per-DMARC-alignment-to-glossary- defined-term coupling dimensions: (i) per-identifier-vocabulary- as-load-bearing-consumer-of-canonical- defined-term-definition — every per-identifier slot THIS page documents (the From-header RFC 5322 identifier, the envelope-MAIL-FROM RFC 5321 identifier, the DKIM- Signature d=-tag signing-domain identifier, the DKIM- Signature i=-tag AUID, the HELO identity) CONSUMES the canonical glossary-spoke DefinedTerm definition for the underlying identifier-concept the slot enumerates — operator-side identifier-alignment-evaluation decision-tree traversal requires prior canonical-definition fluency in the five-identifier vocabulary the glossary spoke documents; (ii) per-alignment-mode-vocabulary- as-load-bearing-consumer-of-canonical- defined-term-definition — the per-tag adkim=s / adkim=r / aspf=s / aspf=r strict-vs-relaxed alignment-mode grammar THIS page documents CONSUMES the canonical glossary-spoke DefinedTerm definition for the strict-vs-relaxed alignment-mode semantics — operator-side per- publisher per-tag alignment-mode selection requires prior canonical- definition fluency in the four-mode alignment-mode vocabulary the glossary spoke documents; (iii) per-organisational-domain- PSL-vocabulary-as-load-bearing- consumer-of-canonical-defined-term- definition — the per- publisher PSL-derived organisational- domain computation per RFC 7489 §3.2 and the per-publisher eTLD+1 derivation discipline THIS page documents CONSUME the canonical glossary-spoke DefinedTerm definitions of organisational domain, Public Suffix List, eTLD+1, and per-PSL-revision-cadence derivation discipline — operator- side organisational-domain-derivation discipline requires prior canonical- definition fluency in the four-term PSL-vocabulary the glossary spoke documents; (iv) per-DMARC- alignment-AI-retrieval-engine- citation-vocabulary-as-load-bearing- producer-of-canonical-defined-term- definition — every DMARC- alignment-evaluation slot THIS page documents PRODUCES the per-term entity-first definition the glossary-spoke DefinedTermSet JSON- LD root cites as the canonical reference for AI-retrieval-engine citation (Perplexity / ChatGPT / Claude / Gemini / Google AI Overviews / Bing Copilot) — the bi-directional citation loop between THIS DMARC-alignment- evaluation reference and the glossary-spoke DefinedTerm JSON-LD entries is the AI-retrieval-engine canonical-reference foundation the cluster relies on for per-term deep-link citability of every DMARC-identifier-alignment-concept. Read the email-authentication- glossary spoke alongside THIS page when the operator asks "what is the canonical definition of the DMARC- alignment-concept this evaluation algorithm enumerates" — the answer is FOUR-LAYERED: THIS page documents the DMARC-identifier-alignment- evaluation algorithm, the email- authentication-glossary spoke documents the canonical DefinedTerm definition for every identifier- alignment-concept the algorithm enumerates.
• SPF 10-DNS-lookup limit — the canonical UPSTREAM failure-mode reference documenting how the RFC 7208 §4.6.4 ten-DNS-lookup ceiling (counted across include:, a, mx, ptr, exists:, and redirect= mechanisms during recursive SPF evaluation) produces an spf=permerror verdict that makes SPF-side identifier-alignment evaluation STRUCTURALLY IMPOSSIBLE — the SPF-alignment-evaluation algorithm THIS page documents requires an spf=pass verdict to evaluate the envelope MAIL FROM RFC 5321.MailFrom identifier vs the header From: RFC 5322.From identifier match, and a permerror verdict produces NO spf=pass to align against, collapsing the per-message SPF-alignment outcome to a non-aligned state regardless of aspf=s or aspf=r tag-strictness publication choice. Read the SPF-lookup-limit spoke alongside THIS alignment-mechanics page when the operator's aggregate-report policy_evaluated.spf field shows persistent fail across every source_ip × From:-domain × evaluation-outcome row despite a published v=spf1 record — the canonical first hypothesis is ten-lookup-ceiling exceedance during recursive SPF evaluation at the receiver, and the SPF-lookup-limit spoke documents the four per-publisher remediation strategies (envelope domain split, third-party-include flattening via static IP/CIDR publication, SPF-record macro consolidation, and the redirect=-as-single- lookup-replacement pattern) that restore the spf=pass verdict the SPF-side alignment-evaluation algorithm structurally requires.
• MTA-STS policy-file syntax — the PER-PUBLISHER-PER-DOMAIN- RFC-8461-MTA-STS-POLICY-FILE-BYTE-GRAMMAR- PUBLICATION-DISCIPLINE-AS-LOAD-BEARING- PEER-TRANSPORT-LAYER-POLICY-ENFORCEMENT- DISCIPLINE companion to this DMARC identifier-alignment evaluation algorithm reference. Where THIS page documents the RFC 7489 §3.1 application- layer DMARC identifier-alignment evaluation algorithm (strict-vs-relaxed alignment-mode adkim / aspf tag semantics, header-From-domain vs DKIM d=-tag vs SPF MAIL-FROM-domain matching, Public-Suffix-List-based organizational- domain derivation, per-message alignment- verdict emission), the MTA-STS-policy- syntax spoke is the peer per-publisher per-domain RFC 8461 transport-layer policy-file publication discipline whose per-policy-file mode: enforce commit gates per-receiver per-session per-MX hop message-acceptance at FOUR per-protocol- layer policy-enforcement coupling dimensions: (i) per-message application-layer authentication-and- alignment evaluation vs per-session transport-layer encryption-and-policy- enforcement parallelism — the per-publisher per-domain DMARC application-layer alignment evaluation THIS page documents gates per- message acceptance at the per-message application-layer authentication-and- alignment evaluation boundary, the per- publisher per-domain MTA-STS transport- layer policy-file mode: enforce commit the MTA-STS-policy-syntax spoke documents gates per-session message-acceptance at the per-receiver per-session per-MX hop transport-layer encryption-and-policy enforcement boundary, and the per- publisher per-domain operator-side complete cross-layer policy-enforcement posture requires BOTH layers' policy- publication discipline to compose at per-message-and-per-session message- acceptance time; (ii) per- publisher per-domain three-mode policy- progression parallelism — the per-publisher per-domain DMARC three-mode application-layer policy progression (p=none → p=quarantine → p=reject) THIS page documents the alignment-evaluation- upstream of pairs operationally with the per-publisher per-domain MTA-STS three- mode transport-layer policy progression (mode: none → mode: testing → mode: enforce) the MTA-STS- policy-syntax spoke documents the byte- grammar of, and the per-publisher per- domain operator-side per-layer per-mode- progression-commit cross-layer coordination discipline is the load- bearing per-mode parallel rhythm BOTH protocols share at the per-publication- step boundary; (iii) per- publisher per-domain alignment-strictness- mode-axis-vs-policy-mode-axis policy- publication-discipline parallelism — the per-publisher per-domain DMARC adkim / aspf strict-vs-relaxed alignment-strictness- mode axis THIS page documents at the application layer pairs operationally with the per-publisher per-domain MTA- STS mx: per-MX matching- pattern strict-vs-wildcard mode axis the MTA-STS-policy-syntax spoke documents at the transport layer, and the per- publisher per-domain operator-side per- layer per-strictness-mode publication- discipline cross-layer coordination is the load-bearing per-strictness-mode parallel rhythm BOTH protocols share at per-policy-publication boundary; (iv) per-publisher per-domain Bulk- Sender-Requirements-2024 cross-layer policy-enforcement-floor composition coverage — the per- publisher per-domain Feb-2024 Gmail/ Yahoo Bulk Sender Requirements deliverability-floor composition explicitly requires the per-publisher per-domain DMARC p=reject application-layer terminal-enforcement state THIS page documents the alignment- evaluation-upstream of AND per-publisher per-domain MTA-STS-policy-file-and-TLS- RPT transport-layer publication discipline the MTA-STS-policy-syntax spoke documents as paired cross-layer publication components of the per- publisher per-domain complete cross- layer authentication-and-encryption deliverability posture. Read THIS page when AUTHORING per-publisher per-domain DMARC application-layer identifier- alignment evaluation discipline; read the MTA-STS-policy-syntax spoke when CO- AUTHORING the per-publisher per-domain peer transport-layer policy-file publication discipline whose per-policy- file mode: enforce commit composes operationally with the DMARC alignment-evaluation discipline THIS page documents at the application layer.
• Email security glossary — the cluster-wide threat-and-defense vocabulary reference whose ~80 per-term entity-first DefinedTerm definitions name the threat classes the per-message DMARC identifier-alignment evaluation algorithm THIS page documents structurally denies at the application-layer authentication boundary. Where THIS page documents alignment MECHANICS in protocol-precise terms (RFC 7489 §3.1 + §6.6.2 SPF-or-DKIM- authenticated-identifier-matches-From: rule, relaxed-via-PSL-orgdomain vs strict-via-FQDN evaluation, the adkim=s / aspf=s tag-strictness selection, the policy_evaluated.dkim / policy_evaluated.spf per-message verdict), the email-security-glossary spoke is the THREAT-AND-DEFENSE-VOCABULARY reference documenting the canonical attack- class taxonomy the alignment algorithm structurally counters and the canonical defense-stack taxonomy the alignment algorithm structurally participates in. Four ALIGNMENT-EVALUATION-TO-THREAT- TAXONOMY coupling dimensions the security- glossary spoke documents: (i) direct-domain spoofing as primary attack class the alignment algorithm denies — the per-message alignment-pass verdict THIS page documents is the protocol-layer countermeasure to the direct-domain From-header-spoofing attack class the security glossary catalogues under the email-borne-attacks vocabulary (exact-match From-domain forgery, From-header injection, MAIL-FROM-vs-From identifier mismatch); (ii) look-alike and cousin-domain attack residual the alignment algorithm cannot reach — the look-alike tactics the security glossary catalogues (typosquatting, homograph / IDN-homoglyph, cousin domain, combosquatting) are the per-attacker per-domain attack residual that ESCAPES the per-publisher per-domain alignment evaluation THIS page documents (the attacker registers a DIFFERENT domain and aligns ON THAT domain) — the complementary defense the security glossary documents (secure-email-gateway anti-impersonation, brand-monitoring, registrar-side defensive registrations) is the per-portfolio defense-in-depth layer the alignment algorithm structurally depends on; (iii) BEC and conversation- hijacking attack variants the alignment algorithm partially mitigates — the BEC variants the security glossary catalogues (CEO fraud, invoice fraud, vendor email compromise, account takeover, conversation hijacking) interact with the alignment algorithm in nuanced ways (account-takeover BEC PASSES alignment because it originates from the legitimate publisher's authenticated infrastructure; look-alike BEC FAILS alignment on the spoofed domain but the receiver-side display-name heuristic is the residual gap) — the operator-side BEC-runbook vocabulary the security glossary documents (NIST SP 800-61 IR lifecycle, IoCs, dwell time, MTTD / MTTR) is the load-bearing operations-layer complement to the per-message alignment-pass / alignment-fail verdict stream this page documents; (iv) MITRE ATT&CK Initial- Access / Phishing technique vocabulary the alignment algorithm participates in — the MITRE ATT&CK technique-vocabulary the security glossary catalogues (T1566 Phishing, T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1566.003 Spearphishing via Service) is the canonical threat-modelling-framework vocabulary the per-message alignment- fail verdict THIS page documents feeds into at the per-receiver SOC / SIEM triage boundary. Read THIS page when AUTHORING the per-publisher per-domain DMARC identifier-alignment evaluation discipline; read the email-security- glossary spoke when AUDITING the per-publisher per-portfolio threat- taxonomy vocabulary whose per-attack- class defender-side mitigation discipline the per-message alignment- evaluation algorithm THIS page documents structurally participates in.
• DMARC policy rollout — the PER-PUBLISHER-PER-DOMAIN-DMARC-RAMP- AS-LOAD-BEARING-DOWNSTREAM-CONSUMER-OF-PER- MESSAGE-IDENTIFIER-ALIGNMENT-VERDICT-CONTINUITY companion to this per-message identifier- alignment evaluation reference. Where THIS page documents the per-message SPF-aligned- pass / DKIM-aligned-pass evaluation algorithm (RFC 7489 §3.1, adkim=r/s, aspf=r/s, the Public Suffix List organizational-domain extraction, the "any-aligns-wins" multi-DKIM-signature rule, the onmicrosoft.com / gappssmtp.com third-party-relay gotchas) as the LOAD-BEARING per-message application-layer verdict the receiver-DMARC- engine emits per-row in the policy_evaluated aggregate-report block, the policy-rollout spoke documents the FOUR PER-DMARC-RAMP-PHASE-AS-PER-MESSAGE- ALIGNMENT-VERDICT-CONSUMER DIMENSIONS the per-publisher per-domain operator MUST master to advance through the canonical p=none → p=quarantine → p=reject ramp without per-phase rollback: (i) per-phase ADVANCEMENT GATE driven by per-receiver per- day aligned-pass-rate floor — the per-publisher per-domain operator MUST observe a per-receiver per-day aligned-pass- rate ≥ 95 % across the trailing 14-day per-receiver-aggregate-report window BEFORE advancing from p=none to p=quarantine, and that floor is structurally gated on the per-message identifier- alignment evaluation evidence THIS page's algorithm produces row-by-row in the policy_evaluated aggregate-report block; (ii) per-phase ALIGNMENT-MODE- CHOICE coordination (adkim=r/s + aspf=r/s) — the per- publisher per-domain operator MUST lock the per-domain adkim + aspf alignment-mode-choice BEFORE entering the p=quarantine phase, because per-phase advancement under an unstable alignment-mode-choice causes per- receiver per-day aligned-pass-rate deviation attributable to the per-message alignment- mode-flip rather than the per-publisher per- sender-source authentication discipline; (iii) per-phase onmicrosoft.com / gappssmtp.com third-party-relay alignment-gotcha PRE-REMEDIATION — the per-publisher per-domain operator MUST remediate the M365 third-party onmicrosoft.com DKIM-d-tag misalignment gotcha + the Workspace third- party gappssmtp.com DKIM-d-tag misalignment gotcha BEFORE entering p=quarantine, because the per- message alignment-fail blast radius from an unremediated third-party-relay alignment gotcha causes per-receiver per-day per-domain legitimate-mail-bounce at quarantine-and- reject phases that would otherwise have been invisible under p=none; (iv) per-phase per-receiver per-day rua= aggregate-report policy_evaluated row-by-row observability primitive — the per- publisher per-domain operator reads the per- day per-receiver rua= aggregate report <policy_evaluated><dkim> and <policy_evaluated><spf> verdict-per-row block as the SINGLE observability surface that surfaces BOTH per- message identifier-alignment evidence AND per-policy-ramp-phase enforcement-verdict- distribution evidence, letting the operator attribute a per-receiver per-day per-phase enforcement-distribution deviation to the SPECIFIC per-source-IP per-message alignment- fail root cause. Read the policy-rollout spoke ALONGSIDE this identifier-alignment evaluation reference whenever the per- publisher per-domain operator COORDINATES the per-message identifier-alignment evaluation discipline with the per-DMARC-ramp-phase advancement cadence — the per-policy-ramp- phase-as-per-message-alignment-verdict- consumer coordination catalogue is the canonical operator-facing companion every per-publisher per-domain identifier-alignment operator MUST master to advance through the canonical p=none → p=quarantine → p=reject ramp without per-phase rollback.
• DMARC for Google Workspace — the GOOGLE-WORKSPACE-TENANT-PER-CUSTOM- DOMAIN-DKIM-AND-SPF-ALIGNED-PASS-RATE- FLOOR-AS-CANONICAL-PER-TENANT-DMARC- ALIGNMENT-CONSUMER companion to this DMARC identifier-alignment reference. Where THIS page documents the per-receiver per- message DMARC identifier-alignment evaluation algorithm (the RFC 5322 From: header organisational-domain extraction, the per-message DKIM d=-tag-vs-From: domain comparison per RFC 7489 §3.1.1, the per- message SPF MAIL-FROM-domain-vs-From: domain comparison per RFC 7489 §3.1.2, the strict-vs-relaxed alignment-mode selection per the adkim= / aspf= DMARC record tags, and the per-message DMARC composite-pass algorithm requiring at-least-one DKIM-or- SPF aligned-pass), the Workspace-tenant spoke documents the per-Workspace-tenant per-custom-domain DKIM CNAME-delegated google._domainkey selector topology + SPF include:_spf.google.com cascade publication discipline that produces the per-Workspace-tenant per- custom-domain DKIM-aligned-pass + SPF- aligned-pass evidence the DMARC alignment algorithm THIS page documents evaluates at the per-receiver per-message DMARC composite-pass boundary. The per- Workspace-tenant per-custom-domain DMARC alignment evaluation IS the per-Workspace- tenant per-custom-domain canonical consumer of the DMARC identifier-alignment algorithm THIS page architectures at four Workspace- tenant-DMARC-deployment-vs-DMARC-identifier- alignment coupling dimensions: (i) per- Workspace-tenant DKIM d=<tenant-domain> tag- emission as canonical per-tenant per- custom-domain DKIM-aligned-pass evidence — the per-Workspace-tenant per-custom-domain Google-egress DKIM signer emits per- message DKIM-Signature headers with d=<tenant-domain> + s=google, producing the per- message DKIM-aligned-pass evidence the DMARC alignment algorithm THIS page documents evaluates against the RFC 5322 From: domain at the receiver-side DMARC composite-pass boundary; (ii) per- Workspace-tenant SPF include:_spf.google.com cascade as per-tenant SPF-aligned-pass- rate source — the per-Workspace-tenant per-custom-domain SPF record's transitive cascade through Google's per-tenant per- source-IP authorisation sub-cascades produces the per-message SPF-aligned-pass evidence the DMARC alignment algorithm evaluates against the per-message MAIL- FROM-domain-vs-From: domain alignment check; (iii) per-Workspace-tenant adkim= / aspf= alignment-mode selection as Workspace- tenant DMARC-ramp-cadence-aligned discipline — the per-Workspace-tenant per- custom-domain DMARC record's adkim=r (relaxed) default vs adkim=s (strict) selection coordinates with the per-Workspace-tenant sub-domain emission pattern the DMARC alignment algorithm THIS page documents evaluates; and (iv) per-Workspace-tenant DMARC-ramp cadence as per-tenant per- custom-domain DMARC-aligned-pass-rate- floor-preservation discipline — the per- Workspace-tenant per-custom-domain p=none → p=quarantine pct=N → p=reject ramp cadence depends on the per-Workspace-tenant per-custom-domain DMARC-aligned-pass-rate floor the DMARC identifier-alignment algorithm THIS page documents structurally produces. Read THIS page when AUTHORING the per-publisher per- domain DMARC identifier-alignment evaluation discipline at the canonical receiver-side alignment-algorithm reference layer; read the Workspace-tenant DMARC deployment spoke when AUDITING the per- Workspace-tenant per-custom-domain DMARC- aligned-pass-rate floor against the DMARC identifier-alignment algorithm THIS page documents at the per-Workspace-tenant per- custom-domain managed-egress DMARC- composite-pass evaluation boundary.
• DMARC for Microsoft 365 — the parallel enterprise-mailbox-provider sibling to the Google Workspace spoke above. Where the Workspace reference documents the per-Workspace-tenant per-custom-domain DKIM CNAME-delegated google._domainkey selector topology + SPF include:_spf.google.com cascade publication discipline, the Microsoft 365 spoke documents the per-M365-tenant per- custom-domain DKIM CNAME-delegated selector1._domainkey / selector2._domainkey dual-selector topology + SPF include:spf.protection.outlook.com publication discipline. Both produce per- tenant per-custom-domain DKIM-aligned-pass + SPF-aligned-pass evidence the DMARC alignment algorithm THIS page documents evaluates at the per-receiver per-message DMARC composite-pass boundary.
• MTA-STS vs DANE for SMTP — the structurally parallel transport-layer publication-discipline companion to this DMARC identifier-alignment application-layer composite-verdict reference. Where THIS page documents the per-publisher per-domain RFC 7489 §3.1 identifier-alignment evaluation algorithm (DKIM-d-domain-vs-RFC5322-From-domain strict-or- relaxed alignment + SPF-MAIL-FROM-domain-vs- RFC5322-From-domain strict-or-relaxed alignment + composite-verdict OR-leg cascade) at the per- receiver-side per-message DMARC-aligned-pass evaluation boundary, the MTA-STS-vs-DANE spoke documents the structurally parallel per- publisher per-domain transport-layer publication- discipline decision-matrix whose per-publisher per-domain selection drives the per-receiving- MTA per-MX-host STARTTLS enforcement pathway — the transport-layer authentication-and- encryption envelope that wraps the per-message DMARC-aligned-pass evaluation discipline. Four per-protocol-layer publication-discipline coupling dimensions matter: (i) per-publisher per-domain DUAL publication primitive — per- publisher DMARC publication via per-domain _dmarc.<domain> TXT-RR application-layer publication, per-publisher MTA-STS via per-domain HTTPS Well-Known-URI transport-layer publication; (ii) per-publisher per-domain DUAL verification-pipeline integration — per-receiver per-message DMARC composite- verdict evaluation is independent-of yet complementary-with per-receiving-MTA STARTTLS enforcement; (iii) per-publisher per-domain DUAL trust-anchor model — per-publisher DMARC trust-anchored to per-domain zone-file commit, per-publisher MTA-STS to HTTPS Web-PKI X.509, per-publisher DANE to per-zone DNSSEC signing- chain; (iv) per-publisher per-domain DUAL composite application-and-transport-layer publication-discipline portfolio — per-publisher DMARC application-layer composite-verdict publication + per-publisher MTA-STS-or-DANE transport-layer publication form the composite per-publisher per-domain composite-publication- discipline portfolio every per-publisher per- domain deployment THIS page documents materially coordinates publication discipline against.
• DNS propagation timelines
• DANE for SMTP (RFC 7672) explained — the PER-PUBLISHER-PER-DOMAIN-DMARC- COMPOSITE-VERDICT-ALIGNMENT-EVALUATION-AS- APPLICATION-LAYER-AUTHENTICATION-DISCIPLINE- COMPANION-TO-DANE-TRANSPORT-LAYER-TLS- CERTIFICATE-AUTHORIZATION companion to this DMARC-alignment reference. Where THIS page documents the per-publisher per-domain DMARC alignment-mode publication-discipline (adkim=r/s + aspf=r/s tag publication per RFC 7489 §3.1, RFC 7489 §3.1.1 DKIM organisational-domain-walk via Public Suffix List, RFC 7489 §3.1.2 SPF organisational-domain-walk), the DANE- explained spoke is the STRUCTURALLY- ORTHOGONAL transport-layer cryptographic- authorization-leg companion whose per-MX- host TLSA-RR publication-discipline is the transport-layer cryptographic-authorization- leg running ALONGSIDE the per-publisher per-domain DMARC application-layer alignment-evaluation at FOUR per-publisher per-domain DMARC-alignment-vs-DANE- transport-layer coupling dimensions: (i) per-publisher per-domain DMARC application-layer composite-verdict alignment-evaluation vs per-publisher per- MX-host DANE transport-layer TLSA-RR-based TLS-cert-authorization-evaluation protocol- layer orthogonality — per- publisher per-domain DMARC composite- verdict per RFC 7489 §6.6 is evaluated at the receiver-side application-layer post- STARTTLS authentication-leg-alignment boundary; per-publisher per-MX-host DANE cert-authorization per RFC 7672 §3 is evaluated at the receiver-side transport- layer STARTTLS-cert-validation boundary BEFORE the application-layer DMARC composite-verdict evaluation begins — per-publisher per-domain DANE- verifier-side TLS-handshake-failed per-MTA-connection bounce blocks the per- publisher per-MX-host receive-pipeline before per-publisher per-domain DMARC composite-verdict alignment-evaluation can attribute per-message authentication- leg-aligned-pass evidence at the per- receiver per-day per-source-IP per-row DMARC RUA aggregate-XML evidence-stream boundary; (ii) per-publisher per- domain DMARC alignment-mode publication- decision vs per-publisher per-MX-host DANE certificate-usage publication- decision — per-publisher per-domain DMARC adkim=s / aspf=s strict alignment-mode publication-decision IS structurally parallel to per-publisher per-MX-host DANE certificate-usage=3 (DANE-EE end-entity-pin) publication- decision — both per-publisher per- domain operator-side cryptographic- strictness publication-decisions close per-attacker per-target-domain mis- attribution-or-cert-mis-issuance attack- window at the per-publisher per-domain composite cryptographic-strictness publication-discipline coordination boundary; (iii) per-publisher per-domain composite SPF + DKIM + DMARC TXT-RR publication-portfolio at <domain> + <selector>._domainkey.<domain> + _dmarc.<domain> vs per-publisher per-MX-host DANE TLSA-RR publication at _25._tcp.<mx-host> publication-discipline parallel — all four per-publisher per-domain DNSSEC-validatable RR publication- discipline primitives jointly underpin the per-publisher per-domain composite application-layer-authentication-AND- transport-layer-authorization publication- discipline floor whose joint per-publisher per-domain publication-portfolio coordination IS the load-bearing per- publisher per-domain anti-spoofing-and- anti-downgrade defense-stack baseline; (iv) per-publisher per-domain DMARC-aligned-pass evidence stream feeding DMARC RUA aggregate-XML report attribution vs per-publisher per-MX-host DANE- verifier-side per-MTA-connection evidence stream feeding TLS-RPT JSON aggregate report attribution per RFC 8460 — both per-publisher per-domain per-receiver-emitted aggregate-evidence streams jointly populate the per-publisher per-domain composite anti-spoofing-and- anti-downgrade defense-portfolio operational-observability floor at the per-publisher per-domain composite DMARC- aggregate-and-TLS-RPT-aggregate-evidence coordination boundary. Read the DANE- explained spoke WITH this DMARC alignment- evaluation reference when AUTHORING per- publisher per-domain composite application- layer-and-transport-layer cryptographic- authorization publication-discipline portfolio at the per-publisher per-domain composite DMARC-application-layer- alignment-and-DANE-transport-layer- authorization coordination boundary.
• Email authentication explained — the umbrella primer for the SPF + DKIM + DMARC stack this alignment page sits at the heart of. Alignment is the rule that turns a raw SPF or DKIM pass into a DMARC pass by requiring the authenticated identifier to match the RFC 5322 From domain; the email-authentication overview frames why that binding step is what makes the three mechanisms a coherent anti-spoofing system rather than three isolated checks. Read it for the context this alignment deep-dive assumes.
• RFC 7489 §3.1 — Identifier Alignment — the foundational alignment specification.
• Public Suffix List — the canonical registry of public suffixes used by relaxed alignment (RFC 7489 §3.2).
• RFC 8617 — ARC (Authenticated Received Chain) — the standard for preserving authentication results across forwarding / mailing-list hops that break SPF and often DKIM.
• Microsoft SNDS + JMRP monitoring — DMARC reporting shows who fails authentication; Microsoft SNDS + JMRP shows how Outlook.com's filter and its users judge the mail that passes — the per-IP reputation signal aggregate reports cannot see.

12. Audit your DMARC alignment now

DMARC Analyzer's Email Header Analyzer (header_analyzer.php) parses any email's raw headers, runs SPF / DKIM / Authentication-Results decoding via includes/EmailHeaderParser.php, and reports the alignment outcome against the From: header. The Domain Security Checker (domain_checker.php) performs live DNS lookups and surfaces published adkim / aspf values alongside the SPF, DKIM, and DMARC records.

Analyze a real message Sign up — Free plan