DMARC Analyzer

TL;DR

• DKIM alignment is the rule that the d= tag in the DKIM-Signature header must match the visible From: header domain. Defined in RFC 7489 §3.1.1.
• d= drives alignment, not i=. RFC 7489 §3.1.1 names d= as the DKIM-side alignment identifier. The i= AUID tag is ignored for alignment purposes (some receivers use it for non-normative additional checks).
• adkim=r is the default — organizational-domain match per the Public Suffix List. mail.example.com aligns with example.com. adkim=s requires an exact match; same domains do NOT align under strict.
• dkim=pass ≠ DMARC DKIM-aligned. A signature must verify cryptographically AND its d= must align with From:. The onmicrosoft.com and gappssmtp.com gotchas are exactly this distinction: dkim=pass for the tenant default but no alignment for the custom From: domain.
• Multiple signatures, any aligns wins. A message can carry many DKIM-Signature headers; DMARC passes DKIM if AT LEAST ONE valid signature has an aligned d=. Forwarder-added signatures with their own d= are harmless — they cannot help (do not align), and do not hurt (the original aligned signature is still present).
• DKIM survives forwarding when SPF does not. Forwarders rewrite the SMTP envelope and break SPF alignment, but the d= tag is inside the signed-header set and travels with the message. As long as the forwarder does not modify the body or strip the DKIM-Signature header, DKIM alignment survives.
• PSL is authoritative for relaxed. RFC 7489 §3.2 names the Public Suffix List as the source of public suffixes for organizational-domain extraction. For example.co.uk the organizational domain is example.co.uk, not co.uk — the PSL prevents the wrong reduction.
• Fix path for misaligned SaaS senders: enable custom-domain DKIM at the SaaS provider so it signs with d=<your-domain> instead of its own bounce/tenant domain. For M365 that means the Defender portal CNAME publication; for Workspace that means the Admin Console Generate-new- record TXT publication; for SendGrid / Mailgun / Mailchimp / Postmark / etc. the per-provider equivalent.

What this guide covers

The DKIM-side complement to DMARC alignment explained. Where the DMARC alignment page documents alignment from the DMARC-engine angle (covers both SPF and DKIM symmetrically), THIS page is the focused DKIM-only deep dive into how the d= tag in the DKIM-Signature header feeds into the DMARC alignment decision per RFC 7489 §3.1.1.

The page closes the gap left by the verdict catalogue (DKIM failures explained) and the sender-side tag anatomy (DKIM-Signature header explained) — both pages reference DMARC alignment but neither does the full alignment-engine deep dive from the DKIM angle. Together the three pages form a triangle: tags (what the signer emits), verdicts (what the verifier outputs), alignment (how the verdict feeds into DMARC).

Operators arriving here typically have a DMARC failure where DKIM cryptographically passed (dkim=pass) but DMARC failed anyway. The diagnostic is almost always: the d= signing-domain identifier does not align with the From: header domain. The two canonical failure modes — the M365 onmicrosoft.com gotcha and the Workspace gappssmtp.com gotcha — get their own deep-dive sections below.

The d= tag is the alignment anchor

RFC 7489 §3.1.1 specifies that the DMARC DKIM-side alignment identifier is the d= tag of the DKIM-Signature header — NOT the i= AUID tag. The exact wording:

RFC 7489 §3.1.1 (DKIM-authenticated Identifiers):

  In relaxed mode, the Organizational Domains of both the
  [DKIM]-authenticated signing domain (taken from the value
  of the "d=" tag in the signature) and that of the RFC5322.From
  domain must be equal if the identifiers are to be considered
  aligned.

  In strict mode, only an exact match between both of the
  Fully Qualified Domain Names (FQDNs) is considered to produce
  Identifier Alignment.

The d= tag identifies the domain on whose behalf the message was signed. It is the domain whose public-key TXT record under <s>._domainkey.<d> the verifier used to validate the signature.

The i= AUID (Agent or User Identifier) tag, when present, identifies a specific user or sub-agent on whose behalf the message was signed — typically a local-part@d= construction like i=alice@example.com or just @example.com. RFC 7489 §3.1.1 explicitly excludes i= from alignment evaluation: only the d= value participates in the DMARC match. So a signature with d=example.com; i=alice@example.com aligns identically to a signature with d=example.com and no i= at all.

Some receivers (notably some anti-spoof gateways) compare the i= local-part against the From: header local-part for additional verification — but this is a non-normative local policy decision and not part of DMARC. Per the tag anatomy page help_dkim_signatures_explained.php §i= AUID, modern operators typically omit i= entirely because it adds nothing to DMARC and introduces a surface for local-policy surprises.

Why the d= choice is structural, not arbitrary

The DKIM signature itself covers a set of headers selected by the h= tag plus a hash of the message body (bh=). The verifier uses the d= + s= pair to locate the public-key TXT record and verify the b= signature. The d= is therefore the IDENTITY that the signature ATTESTS TO — the signer is making a cryptographic claim "this message is from me, where 'me' is d=<value>". DMARC's job is to confirm that the identity the signer attests to matches the identity the recipient sees in From:. The i= tag, by contrast, is a sub-identifier within d= — it does not change WHO is signing, only WHICH sub-agent of that signer is responsible. For DMARC's "who signed this" question, only d= answers.

Alignment modes: adkim=r vs adkim=s

The DMARC policy record carries the adkim= tag which controls how strictly the receiver compares d= against From:. Two values are defined per RFC 7489 §6.3:

• adkim=r — relaxed, the default. The organizational domains of d= and the From: header must match, determined via the Public Suffix List (next section).
• adkim=s — strict. The d= value must equal the From: header domain byte-for-byte (case-insensitive ASCII).

If the DMARC record omits adkim=, the default per §6.3 is r. Most production DMARC records do not bother setting adkim explicitly and rely on the relaxed default.

Worked alignment examples

Given a From: header of alice@example.com:

d=example.com            adkim=r ALIGNED   adkim=s ALIGNED
d=mail.example.com       adkim=r ALIGNED   adkim=s NOT ALIGNED
d=news.example.com       adkim=r ALIGNED   adkim=s NOT ALIGNED
d=example.co             adkim=r NOT       adkim=s NOT (different org domain)
d=example.org            adkim=r NOT       adkim=s NOT (different TLD)
d=onmicrosoft.com        adkim=r NOT       adkim=s NOT (Microsoft tenant)
d=tenant.gappssmtp.com   adkim=r NOT       adkim=s NOT (Workspace tenant)
d=EXAMPLE.com            adkim=r ALIGNED   adkim=s ALIGNED (case-insensitive)

The interesting cases are the middle two: d=mail.example.com and d=news.example.com align under relaxed because their organizational domain is example.com (the registered name + the public suffix .com), matching the From: organizational domain. Under strict the subdomain mismatch breaks alignment.

When to choose strict

The conventional guidance is:

• Use adkim=r (relaxed) for active sending organizational domains where transactional mail may be signed with subdomain d= values (e.g. d=mail.example.com for transactional, d=news.example.com for marketing).
• Use adkim=s (strict) for non-sending domains where any subdomain-level signature should be treated as suspicious, and for high-value brand domains where the operational discipline of "every legitimate sender signs with d=<exact-domain>" is achievable.

Strict alignment closes the subdomain-spoofing surface — an attacker who compromises a subdomain key cannot sign mail for the organizational domain under strict — at the cost of operational flexibility. The DMARC policy rollout page covers the relaxed-to-strict migration sequence.

PSL organizational-domain matching (relaxed mode)

Relaxed alignment (adkim=r) reduces each domain to its organizational domain before comparing. RFC 7489 §3.2 defines the organizational domain as the registered name plus the public suffix immediately to the right of it. The canonical source of public suffixes is the Public Suffix List (PSL) maintained at publicsuffix.org, originally by Mozilla and now community-maintained.

The reduction algorithm per RFC 7489 §3.2:

1. Find the longest sequence of labels at the end of the FQDN that matches an entry in the PSL. This is the public suffix.
2. Prepend exactly ONE more label — the registered name.
3. The concatenation <registered>.<public-suffix> is the organizational domain.

Worked examples:

FQDN                          Public Suffix    Org Domain
example.com                   com              example.com
mail.example.com              com              example.com
deep.sub.example.com          com              example.com
example.co.uk                 co.uk            example.com (NO - actually example.co.uk)
example.co.uk                 co.uk            example.co.uk
mail.example.co.uk            co.uk            example.co.uk
example.s3.amazonaws.com      s3.amazonaws.com example.s3.amazonaws.com
foo.bar.example.s3.amazonaws  s3.amazonaws.com example.s3.amazonaws.com

The example.co.uk case is the canonical illustration of why the PSL is necessary. Without the PSL, a naive "registered name = last two labels" algorithm would reduce example.co.uk to co.uk — which would then make example.co.uk and other.co.uk "aligned" because they share organizational domain co.uk. Clearly wrong. The PSL encodes that co.uk itself is a public suffix (not a registered name) so the algorithm correctly takes one more label and produces example.co.uk as the organizational domain.

The s3.amazonaws.com case illustrates the OTHER direction: some domains are LISTED in the PSL even though they do not look like traditional public suffixes. AWS adds private subdomains to the PSL so that S3 bucket subdomains do not align with each other. Without that listing, every S3 bucket on the same parent would share amazonaws.com as org domain — privacy-invasive in DMARC aggregate reports. Cloudflare Workers, GitHub Pages, Heroku app domains, and many other multi-tenant platforms have similar PSL entries.

Practical implication for operators

Three operational consequences flow from the PSL design:

• If your domain registers under a country-code TLD with multiple commercial suffixes (.co.uk, .com.au, .co.jp, .com.br), the organizational domain is the full third-level FQDN, not the second-level. DMARC records, policy decisions, and rua reports all operate at that level.
• If your sending infrastructure lives under a PSL-listed multi-tenant platform (e.g., a SaaS-provided subdomain on *.s3.amazonaws.com, *.workers.dev, *.herokuapp.com), each tenant has its own organizational domain and cannot align with any other tenant under relaxed. You CANNOT use these platforms as your DKIM signing domain for mail with a custom From: — you must use custom-domain DKIM with d=<your-registered-domain>.
• The PSL is updated continuously by the community. Receivers MAY cache the PSL but are expected to refresh it regularly; in practice all major mailbox providers update at least weekly. An operator publishing a new DMARC record does not need to do anything special with the PSL — they just need to know that relaxed alignment will Do The Right Thing for normal registered-domain mail flows.

The DKIM alignment evaluation algorithm

The receiver evaluates DKIM alignment as follows per RFC 7489 §3.1.1 + §6.6.2:

1. Extract the RFC5322.From domain from the message — this is the SLD or FQDN in the From: header field that the user-facing client will display.
2. For each DKIM-Signature header in the message, run the DKIM verifier per RFC 6376. Record each signature's result (pass, fail, none, neutral, policy, temperror, permerror) and the d= value.
3. For each signature with a pass result, evaluate the DKIM identifier alignment against the From: domain using the policy mode (adkim=r or adkim=s) from the published DMARC record for the From-domain organizational domain.
4. If ANY pass signature has an aligned d=, DKIM alignment for DMARC = ALIGNED.
5. If no signature passes, or all passing signatures have misaligned d=, DKIM alignment for DMARC = NOT ALIGNED.

The DMARC engine then evaluates the SPF alignment separately (against RFC5321.MailFrom / Return-Path) and the overall DMARC verdict is pass if either DKIM-aligned or SPF-aligned, else fail.

Worked example: aligned + misaligned signatures coexisting

A message from alice@example.com through a SaaS sender and then a mailing list might carry three DKIM-Signature headers:

DKIM-Signature: ... d=example.com         s=mail        ; b=...  (original)
DKIM-Signature: ... d=saas.example         s=k1          ; b=...  (SaaS wrapping)
DKIM-Signature: ... d=list.example.org     s=20240101    ; b=...  (mailing list rewrap)

RFC5322.From:    alice@example.com
DMARC record:    adkim=r (default)

Evaluation per signature:
  d=example.com         -- dkim=pass, org=example.com    -> ALIGNED
  d=saas.example        -- dkim=pass, org=saas.example   -> NOT ALIGNED
  d=list.example.org    -- dkim=pass, org=example.org    -> NOT ALIGNED

DMARC DKIM alignment = ALIGNED (any aligned wins)
DMARC DKIM-aligned signature = d=example.com
DMARC verdict = pass (DKIM-aligned)

The presence of the SaaS and list signatures does not affect the DMARC outcome — they are non-aligning extras. What matters is that AT LEAST ONE dkim=pass signature has an aligned d=. The receiver's Authentication-Results header typically logs the aligned signature explicitly via the policy.policy-from=example.com or dmarc=pass header.from=example.com construction.

Worked example: all signatures misaligned

DKIM-Signature: ... d=onmicrosoft.com ... b=...  (M365 tenant default)
RFC5322.From:    alice@yourcompany.com
DMARC record:    yourcompany.com, adkim=r

Evaluation:
  d=onmicrosoft.com  -- dkim=pass, org=onmicrosoft.com   -> NOT ALIGNED

DMARC DKIM alignment = NOT ALIGNED
SPF alignment        = (separate evaluation)
DMARC verdict        = pass if SPF-aligned, else FAIL

This is the canonical onmicrosoft.com gotcha pattern — dkim=pass verdict but DKIM alignment fails, so the entire DMARC verdict depends on whether SPF aligns. Section 7 below covers the gotcha in full detail.

Multiple DKIM-Signature headers: which one drives alignment

A message MAY carry multiple DKIM-Signature headers — RFC 6376 §3.5 explicitly allows this. Common cases:

• Original sender + SaaS wrapping: the originating application signs with d=<your-domain>, then the SaaS gateway (SendGrid, Mailgun, Postmark) ALSO signs with their own platform domain (d=sendgrid.net, d=mailgun.org) before relay. Both signatures travel together.
• Original sender + mailing list: the original sender signs with d=<your-domain>; the mailing list (Mailman, Discourse, Google Groups) modifies the body (adding a footer, rewriting Subject: with a list-prefix) and adds its own signature with d=<list-domain>. The original signature may break (body modification → bh= mismatch) while the list signature passes — alignment outcome depends on whether either passes AND aligns.
• Per-header rotation / algorithm bridging: a signer emits two signatures simultaneously with different selectors or algorithms — e.g., one with s=20231101 for receivers on the new key and one with s=20230501 for slow DNS-cache receivers during a rotation window.
• ARC sealing: the ARC chain adds ARC-Message-Signature headers, which are NOT DKIM-Signature headers per se but mirror the DKIM signing structure. ARC sealers and DKIM signers can coexist on the same message.

The "any aligns wins" rule in detail

RFC 7489 §3.1.1 (and §6.6.2 for the enforcement step) is unambiguous: any verified DKIM signature whose d= identifier aligns with the From: domain satisfies DKIM alignment for DMARC. The receiver evaluates each signature independently, and the FIRST aligned pass-result determines the DMARC outcome. Other signatures (passing-but-misaligned, failing, or with malformed tags) do not affect the result.

Operational consequence: an operator does NOT need to remove or worry about forwarder-added or SaaS-added DKIM signatures with non-aligned d= values. They are inert from DMARC's perspective. The only thing that matters is whether at least one signature with an aligned d= survives the delivery path intact.

What goes in the rua aggregate report

DMARC aggregate (rua) XML reports per RFC 7489 §7.2 include the per-signature DKIM results in an <auth_results><dkim> block. When multiple signatures are present, the report typically lists each one — operators reading the report should look for the signature with <domain> matching the From: organizational domain. See help_dkim_failures_explained.php §Aggregate reports for the XML format.

The Microsoft 365 onmicrosoft.com gotcha

When you provision a Microsoft 365 tenant, Microsoft assigns it a default routing domain in the form <tenant-name>.onmicrosoft.com — for example, contoso.onmicrosoft.com for the Contoso Corporation tenant. Microsoft auto-provisions DKIM signing for this tenant default with d=<tenant-name>.onmicrosoft.com — the signature is cryptographically valid (dkim=pass at receivers) but it signs as the tenant default, not as your custom domain.

The failure mode follows directly:

From:           alice@contoso.com
DKIM-Signature: ... d=contoso.onmicrosoft.com ... b=...

At the receiver:
  DKIM crypto verification = PASS (Microsoft's key, valid signature)
  DKIM alignment to From   = NOT ALIGNED (d=onmicrosoft.com != From: contoso.com)
  DMARC DKIM alignment     = FAIL
  DMARC verdict            = depends on SPF alignment
                              if SPF-aligned -> DMARC PASS
                              if SPF misaligned -> DMARC FAIL

The gotcha bites in two scenarios:

1. You have not enabled custom- domain DKIM in Defender at all. Microsoft signs all outbound with the tenant default, so every message has the misaligned d=.
2. You enabled custom-domain DKIM but only for the parent domain, not for an alias domain you actually send from. Mail from the alias falls back to the tenant default signature.

The fix

Enable custom-domain DKIM for every sending domain via the Microsoft Defender portal. The procedure is documented in full in help_dkim_for_microsoft_365.php; the high-level steps:

1. Sign in to Microsoft Defender portal at security.microsoft.com.
2. Navigate Policies & rules > Threat policies > DKIM under Rules.
3. Select the custom domain in the table. Microsoft displays the two CNAME values for selector1 and selector2.
4. Publish the two CNAME records at your DNS provider — selector1._domainkey.<your-domain> and selector2._domainkey.<your-domain> pointing at the values Microsoft showed.
5. Return to the Defender DKIM page and toggle Enabled = On. Microsoft begins signing outbound with d=<your-domain> on the next message.

Verifying the fix

Send a test message to a Gmail account (Gmail surfaces full DKIM details in Show Original) and inspect the Authentication-Results header. You should see:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourcompany.com header.s=selector1
            header.b=AbCdEf12;
       spf=pass (google.com: domain of bounces@yourcompany.com designates ...);
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourcompany.com

The critical field is header.i=@yourcompany.com (or equivalently the header.d=yourcompany.com in some receivers' formats). If you still see header.i=@contoso.onmicrosoft.com, DKIM is still signing with the tenant default — re-verify the CNAME publication and Defender toggle.

The Google Workspace gappssmtp.com gotcha

Workspace has its own equivalent of the M365 tenant-default failure mode. When you provision a Workspace tenant and have not yet enabled custom-domain DKIM via the Admin Console, Google signs outbound mail with a default identity using d=<your-domain>.<tenant-id>.gappssmtp.com or a similar Workspace-default form. The signature is cryptographically valid (dkim=pass at the receiver) but the signing domain (<...>.gappssmtp.com) does not align with your From: domain.

From:           alice@contoso.com
DKIM-Signature: ... d=contoso.com.123456abcd.gappssmtp.com ... b=...

At the receiver:
  DKIM crypto verification = PASS (Google's key, valid signature)
  DKIM alignment to From   = NOT ALIGNED (gappssmtp.com != contoso.com)
  DMARC DKIM alignment     = FAIL
  DMARC verdict            = depends on SPF alignment

Unlike M365's <tenant>.onmicrosoft.com pattern, the Workspace default signing domain often INCLUDES your real domain as a label in the FQDN — but a label match is not enough for DMARC alignment. contoso.com.123456abcd.gappssmtp.com has organizational domain gappssmtp.com (per PSL — yes, gappssmtp.com is on the Public Suffix List as a Google-controlled multi- tenant domain), which does not align with contoso.com.

The fix

Enable custom-domain DKIM in the Google Workspace Admin Console for every sending domain. Procedure documented in help_dkim_for_google_workspace.php; the high-level steps:

1. Sign in to the Admin Console at admin.google.com as a super-admin.
2. Navigate Apps > Google Workspace > Gmail > Authenticate email.
3. Select your sending domain. Click Generate new record. Choose 2048-bit key strength (per RFC 8301) and accept the default selector google.
4. Google displays the TXT record value for google._domainkey.<your-domain>. Publish it at your DNS provider. Use 255-byte chunked strings per RFC 1035 §3.3.14 if your DNS provider does not chunk automatically.
5. After publication, return to the Authenticate email page and click Start authentication. Google begins signing outbound with d=<your-domain> s=google on the next message.

Verifying the fix

Send a test message to an account on a different provider (Outlook, FastMail) and inspect the Authentication-Results header:

Authentication-Results: mx-out.outlook.com;
       dkim=pass header.d=yourcompany.com header.s=google
            header.b=PqRsTu12;
       spf=pass smtp.mailfrom=yourcompany.com;
       dmarc=pass action=none header.from=yourcompany.com

The critical field is header.d=yourcompany.com s=google. If you still see header.d=<...>.gappssmtp.com, Google is still signing with the default — re-verify the TXT publication and the Start-authentication toggle.

Why DKIM alignment survives forwarding when SPF does not

SPF and DKIM align on different identifiers, and the consequence is a structural asymmetry under message forwarding:

• SPF aligns the RFC5321.MailFrom (SMTP envelope sender / Return-Path). When a forwarder receives a message and re-injects it, the forwarder REWRITES the envelope to its own bounce address — the original envelope domain is replaced with the forwarder's domain. The SPF check on the forwarded delivery authenticates the forwarder, not the original sender. SPF alignment breaks.
• DKIM aligns the d= tag, which is INSIDE the signed-header set. The DKIM signature covers the headers selected by h= plus a body hash (bh=). As long as the forwarder does not modify the body (which would break bh=) and does not strip the DKIM-Signature header, the original signature travels intact through the forward. The d= value remains whatever the original signer set it to, and DKIM alignment still evaluates against the original signing domain.

What can break DKIM through forwarding

Three things break DKIM signatures during forwarding:

1. Body modification — mailing lists adding a footer ("To unsubscribe..."), security gateways injecting a "[EXTERNAL]" prefix into the body, automated translation services rewriting body text. Any of these changes the body bytes so the receiver computes a different hash than the published bh=. dkim=fail at the receiver. The fix is forwarder-side: use ARC sealing (see help_arc_explained.php) so the receiver can validate the forwarder's attestation that the original signature was valid at ingress.
2. Header modification — security gateways prefixing the Subject: with "[EXTERNAL]" or "[CAUTION]". If Subject: was in the original h= list (which it almost always is for modern signers), the modified header breaks the b= signature check. dkim=fail. Fix: ARC sealing.
3. Re-encoding of the body Content-Transfer-Encoding — relays that convert quoted-printable to base64 or normalize line endings can change body bytes even when the "content" is semantically identical. With c=relaxed/relaxed canonicalization most line-ending normalization is tolerated; with c=simple/simple it breaks. Modern signers use relaxed/relaxed to maximize forward-survivability.

Operational consequence

Because DKIM is the resilient alignment path through real-world mail flow, EVERY sending source should be DKIM-signed with custom-domain DKIM enabled — including every SaaS sender that emits mail with your From: domain (SendGrid, Mailgun, Mailchimp, Postmark, HubSpot, Salesforce, etc.). Each platform has a per-tenant custom-domain DKIM configuration that enables signing with d=<your-domain>. SPF alone is not enough — the moment a message gets forwarded once, SPF stops helping and DKIM is the only alignment path left.

Subdomain semantics under adkim=r and adkim=s

Two edge cases around subdomains deserve their own treatment: signatures from a SUBDOMAIN of From, and signatures from the PARENT of From.

From subdomain of d=

The common case: From is a subdomain, d= is the parent.

From:    alice@mail.example.com
d=       example.com

adkim=r: ALIGNED  (organizational domains both = example.com)
adkim=s: NOT ALIGNED (FQDNs differ)

Why: the From organizational domain (example.com) equals the d= organizational domain (example.com). Under relaxed, that match is sufficient. Under strict, the FQDN comparison fails because mail.example.com ≠ example.com.

d= subdomain of From

The mirror case: From is the parent, d= is a subdomain.

From:    alice@example.com
d=       mail.example.com

adkim=r: ALIGNED  (organizational domains both = example.com)
adkim=s: NOT ALIGNED (FQDNs differ)

Same outcome: relaxed aligns at the org- domain level; strict requires FQDN equality. Both directions of subdomain asymmetry are symmetric under relaxed.

Deep subdomains

From:    alice@example.com
d=       a.b.c.d.example.com

adkim=r: ALIGNED   (organizational domains both = example.com)
adkim=s: NOT ALIGNED

From:    alice@a.b.c.d.example.com
d=       example.com

adkim=r: ALIGNED   (organizational domains both = example.com)
adkim=s: NOT ALIGNED

Depth of subdomain nesting does not affect relaxed alignment — only the organizational-domain match matters.

The DMARC sp= tag interaction

A DMARC record at the organizational domain can specify a different policy for subdomains via the sp= tag. Subdomain alignment evaluation uses the SUBDOMAIN's effective adkim=, not the org-domain's directly. In practice the adkim= tag itself is inherited from the org-domain DMARC record when no subdomain-specific DMARC record exists. The DMARC policy rollout page covers the p=, sp=, np=, pct=, and related-tag interactions.

Different organizational domains

From:    alice@example.com
d=       example.org

adkim=r: NOT ALIGNED (different org domains)
adkim=s: NOT ALIGNED

Trivially never aligned. This is the canonical cross-organizational-domain signature that DMARC is designed to reject.

Common DKIM-alignment mistakes

1. Treating dkim=pass as proof of DMARC pass. The single most common diagnostic confusion. dkim=pass means the signature verified cryptographically. DMARC pass additionally requires the d= to align with From:. Always inspect the aligned-signature column in your rua report, not just the verifier-verdict column.
2. Leaving M365 tenant-default signing on. If Defender DKIM is not enabled for your custom domain, all outbound is signed with d=<tenant>.onmicrosoft.com — a verdict-pass alignment-fail situation. Enable custom-domain DKIM on EVERY tenant domain you send from (see section 7).
3. Leaving Workspace Authenticate-email disabled. The Workspace counterpart of the M365 bug. Until Authenticate email is toggled on per sending domain, Google signs with the gappssmtp.com default (see section 8).
4. Using adkim=s without subdomain-signing discipline. Strict alignment fails any subdomain-vs-parent mismatch. If you publish adkim=s for example.com but a transactional sender signs with d=mail.example.com, DMARC fails. Audit every sending source's actual d= before flipping to strict.
5. Confusing i= with d=. RFC 7489 §3.1.1 specifies alignment against d=, not i=. Some receiver formats display header.i= in Authentication-Results but the domain portion of i= (after the @) is usually equal to d=. Look at the header.d= field directly when available.
6. Not enabling custom-domain DKIM at SaaS senders. Every SaaS sender (SendGrid, Mailgun, Mailchimp, Postmark, HubSpot, Salesforce, Klaviyo, ConvertKit, etc.) has a custom-domain DKIM feature. Without it, the SaaS signs with its own platform domain (d=sendgrid.net, d=mailgun.org, etc.) — which never aligns with your From:.
7. Ignoring the PSL effect on country-code TLDs. For example.co.uk, the organizational domain is example.co.uk, not co.uk. Operators publishing DMARC records at the second-level (co.uk) instead of the third-level (example.co.uk) get no policy enforcement because receivers look for the DMARC record at the organizational-domain level.
8. Assuming forwarder-added signatures help. If a mailing list adds its own DKIM signature with d=<list-domain>, the signature can dkim=pass at receivers — but does not align with your From:. DMARC DKIM alignment for the list-forwarded message succeeds ONLY if the ORIGINAL signature (with d=<your-domain>) also survives. ARC sealing is the protocol-level fix when body modification breaks the original signature.
9. Publishing DMARC at the wrong level for multi-TLD deployments. A company owning example.com and example.co.uk needs SEPARATE DMARC records at each organizational domain — the records do not inherit. Similarly DKIM keys published under example.com do not authenticate example.co.uk mail.
10. Confusing the alignment mode with the policy mode. adkim=s (alignment is strict) and p=reject (policy is reject) are independent knobs. You can have adkim=r; p=reject — a forgiving alignment combined with an aggressive policy. Or adkim=s; p=none — strict alignment but monitor-only policy. The two tags do not constrain each other.

Troubleshooting matrix

Symptom → likely cause → next step:

SYMPTOM                              LIKELY CAUSE              NEXT STEP
====================================== ========================= ==========================
dkim=pass but DMARC fails              d= != From: org domain   Inspect header.d in
                                                                  Authentication-Results.
                                                                  If d=onmicrosoft.com or
                                                                  *.gappssmtp.com, enable
                                                                  custom-domain DKIM.

DMARC aggregate report shows           Some sender signing      Audit every SaaS sender's
mixed pass / fail percentages          with non-aligned d=      DKIM configuration.
for the same domain                                              Look for SaaS-default d=
                                                                  (sendgrid.net, mailgun.org,
                                                                  mandrill.io, etc.).

DMARC fails for mailing-list forwards  Body modification breaks Add ARC sealing OR accept
but passes for direct delivery         original signature       the mailing-list signing
                                                                  d= if it's a trusted list.
                                                                  Cannot align the list's
                                                                  d= with your From:.

DMARC fails for mail FROM your         d= is the parent;        Either: (a) sign with d=
subdomain From: with d= parent         adkim=s is published     equal to From: FQDN, or
                                                                  (b) relax to adkim=r.

dkim=permerror header.d=               Public-key TXT under     Check DNS for the
<your-domain>                          <s>._domainkey.<d>     selector record. Run
                                       missing or malformed     dig +short TXT
                                                                  <s>._domainkey.<d>

dkim=temperror                         Transient DNS lookup     Retry in 5-15 minutes.
                                       failure                  If persistent, check
                                                                  authoritative DNS health.

DMARC report rua shows                 Forwarder rewrote        Add ARC sealing if you
spf=fail dkim=fail for                 envelope AND body        control the forwarder;
forwarded mail                                                   else accept that forward
                                                                  losses are unavoidable
                                                                  without ARC.

DMARC fails for mail signed by         d= label includes        gappssmtp.com is on the
Workspace tenant default               *.gappssmtp.com          PSL. Enable custom-domain
                                                                  DKIM in Admin Console.

All Defender CNAMEs published          Defender DKIM toggle     Toggle Enabled = On at
but messages still d=onmicrosoft        not switched on         security.microsoft.com >
                                                                  DKIM page.

DMARC fails for SaaS-relayed mail      SaaS signing with its    Enable custom-domain DKIM
even though SaaS d= passes             own platform d=          at the SaaS provider
                                                                  control panel.

Frequently asked questions

How does DKIM alignment work in DMARC?

DKIM alignment compares the d= tag in the DKIM-Signature header against the domain in the From: header that the recipient sees. The comparison is per RFC 7489 §3.1.1. Under adkim=r (relaxed, the default), the organizational domains must match — mail.example.com and example.com align. Under adkim=s (strict), the d= value must equal the From: domain exactly. A DKIM signature aligns ONLY when it both verified cryptographically (dkim=pass) AND its d= matches the From: domain under the policy mode. dkim=pass alone is not enough for DMARC — the d= must align.

What is the difference between adkim=r and adkim=s?

adkim=r (relaxed, the default) requires the d= signing domain and the From: header domain to share an organizational domain — that is, they must agree at the registered-name + public- suffix level per the Public Suffix List. mail.example.com and example.com share organizational domain example.com so they align under relaxed. adkim=s (strict) requires d= to equal the From: domain byte-for-byte (case-insensitive ASCII) — mail.example.com and example.com do NOT align under strict. Strict is the more secure choice and is recommended for non-sending and high-value brand domains; relaxed is the practical default for active sending domains with cross-subdomain mail flows.

Why does dkim=pass not always mean DMARC passes?

dkim=pass means the signature verified cryptographically — the body hash matched the bh= tag and the signed-header set signature matched the b= tag. It does NOT mean the d= signing-domain identifier aligns with the From: header. A message can be dkim=pass with d=onmicrosoft.com and From: alice@yourcompany.com — the crypto is valid for the Microsoft tenant default signing identity, but it does not align with the From: header so DMARC fails on alignment. The verdict-vs-alignment distinction is the single most-misdiagnosed DMARC failure mode.

What is the onmicrosoft.com DKIM gotcha?

When you send mail through Microsoft 365 BEFORE enabling custom-domain DKIM via the Defender portal, Microsoft signs outbound mail with a tenant-default DKIM signature using d=<tenant>.onmicrosoft.com. The signature verifies cryptographically (dkim=pass at the receiver) — but d=onmicrosoft.com does NOT align with your From: header domain (yourcompany.com), so DMARC fails on DKIM alignment. The fix is to enable Defender DKIM CNAMEs for your custom domain so Microsoft signs with d=yourcompany.com instead. See help_dkim_for_microsoft_365.php for the full deployment procedure.

What is the gappssmtp.com DKIM gotcha?

When you send mail through Google Workspace BEFORE enabling custom-domain DKIM via the Admin Console, Google signs outbound mail with a default DKIM signature using d=<your-domain>.<tenant-id>.gappssmtp.com or a similar Workspace-default signing identity. The signature verifies (dkim=pass) but d=*.gappssmtp.com does NOT align with your From: header domain, so DMARC fails on DKIM alignment. The fix is to enable custom-domain DKIM in the Workspace Admin Console: Apps > Google Workspace > Gmail > Authenticate email > Generate new record, then publish the TXT and Start authentication. See help_dkim_for_google_workspace.php for the procedure.

Which DKIM signature drives alignment when a message has multiple?

A message can carry multiple DKIM-Signature headers — original sender + forwarder + mailing list each can sign with their own d=. The DMARC engine evaluates each signature independently for crypto-validity AND alignment, and DMARC passes DKIM if AT LEAST ONE valid signature aligns. RFC 7489 §3.1.1 wording: "any" verified signature whose d= aligns satisfies DKIM alignment. So a forwarder adding its own d=forwarder.example signature does not help (does not align), but it also does not hurt — the ORIGINAL sender signature with d=yourcompany.com is still present and still aligns. dkim=fail on a misaligned forwarder signature alongside dkim=pass on an aligned original signature still produces DMARC pass.

Why does DKIM alignment survive forwarding when SPF does not?

SPF authenticates the SMTP envelope MAIL FROM (Return-Path). When a forwarder receives a message and re-sends it, the forwarder rewrites MAIL FROM to its own bounce address — the original envelope domain is gone, so SPF on the forwarded message authenticates the forwarder, not the original sender, and SPF alignment fails. DKIM authenticates the d= tag, which is inside the signed-header set and travels with the message through forwards unmodified. As long as the forwarder does not modify the message body (which would break bh=) or strip the DKIM-Signature header (which would remove the signature entirely), the d= identifier survives forwarding and DKIM alignment still passes. This asymmetry is why every sending source should be DKIM-signed: DKIM is the resilient alignment path through real-world mail flow.

Does DKIM alignment use the i= AUID tag?

No. RFC 7489 §3.1.1 specifies that DMARC DKIM alignment compares the d= tag, NOT the i= AUID tag. The i= tag, when present, identifies a sub-agent or specific user within the signing domain — but DMARC ignores it for alignment purposes. So a signature with d=example.com and i=alice@example.com aligns identically to a signature with d=example.com and no i= tag, and aligns identically to a signature with d=example.com and i=@example.com. Some receivers compare i= against the From: header local-part for additional verification, but this is non-normative and not part of DMARC.

Related guides

• DMARC alignment explained — the symmetric SPF+DKIM alignment reference. THIS page is the DKIM-only deep dive; that page is the engine-wide view.
• SPF mechanisms explained — the SPF-side companion reference informing the SPF-aligned-vs-DKIM-aligned design choice this page documents the DKIM-side of — the SPF-MECHANISM-CROSS-PROTOCOL-COMPANION to this DKIM-alignment-with-DMARC page. DMARC enforcement requires EITHER SPF alignment OR DKIM alignment (RFC 7489 §6.6.2 — the OR-conjunction of the two aligned identifiers) — which means the engineering choice between an SPF-primary or a DKIM-primary alignment posture is informed by the relative operational reliability of the two protocols' alignment mechanisms. Where THIS page is the DKIM-side alignment deep dive (the d=-tag-vs-RFC5322-From-domain match, the relaxed-vs-strict alignment modes, the third-party-sender DKIM re-signing pattern that preserves alignment through SaaS-sender hops), the mechanisms-explained spoke is the SPF-side reference cataloguing the eight SPF mechanisms (RFC 7208 §5 — all, include, a, mx, ip4, ip6, ptr, exists) whose per-mechanism evaluation produces the spf= verdict the DMARC engine consults for SPF alignment. Read the mechanisms spoke alongside this page when designing a DMARC alignment strategy for a domain whose outbound mail traverses multiple forwarders, MLM expanders, or rewriting middleboxes (SPF mechanisms evaluated on the post-rewrite envelope- client-IP frequently break, leaving DKIM alignment as the only viable path to DMARC pass) and you need the SPF-side reference to confirm WHICH mechanism choices in your SPF record would or wouldn't survive the forwarder-hop scenario.
• SPF include: vs ip4: vs a: vs mx: decision tree — the SPF-MECHANISM-CLASS-CHOICE DEEP-DIVE between the four IP-providing mechanisms (include: cascade vs ip4:/ip6: literal CIDR vs a:/mx: host-resolution) that pairs with the mechanisms-explained spoke above. Where the mechanisms-explained spoke catalogues the eight SPF mechanisms generically, THIS decision-tree spoke documents the engineering decision among the four IP-providing mechanisms whose four per-mechanism-vs-DKIM-alignment fallback coordination dimensions determine when the DKIM-alignment leg THIS page documents becomes the SOLE LOAD-BEARING DMARC-pass path: (i) per-mechanism class DNS-query-budget consumption — include: cascades consume 1+N DNS queries per resolved include (multi-level ESP cascades easily consume 5-8 queries) while ip4:/ip6: literals consume 0, and a:/ mx: consume 1 each plus the target's per-A/per-MX expansion — cumulative consumption against the RFC 7208 §4.6.4 10-lookup ceiling determines whether the receiver evaluates the SPF record at all or returns permerror, leaving DKIM-alignment as the sole DMARC-pass path THIS page documents; (ii) per-mechanism class forwarder- survivability — ip4:/ ip6: literals require the sender to enumerate every forwarding-hop egress IP (typically impractical for third-party forwarders the sender doesn't control), include: cascades hosted by ESPs survive forwarder-pool IP churn within the ESP, and a:/ mx: mechanisms re-resolve at evaluation time (survive A-record IP churn but break when the forwarding hop is on a non-listed host) — the mechanism choice directly determines the SPF-alignment failure surface at forwarder hops where DKIM-alignment becomes the SOLE LOAD-BEARING path; (iii) per-mechanism class temperror/permerror risk surface — a:/ mx: resolve through customer DNS at receiver-side evaluation time and can return temperror on transient DNS failure or permerror on NXDOMAIN (RFC 7208 §5.5/§5.6), while ip4:/ip6: literals are deterministic and include: failures cascade as permerror per RFC 7208 §5.2 — the per-mechanism risk surface determines the frequency at which the SPF leg of the RFC 7489 §6.6.2 OR-conjunction produces a non-pass result requiring the DKIM-alignment leg this page documents to rescue the DMARC verdict; and (iv) per-mechanism class operational discipline interacting with DKIM-rotation cadence — the include: cascade's ESP-managed IP-list updates (no operator action required), the ip4: literal's operator-side enumeration discipline at every egress-IP change, the a:/ mx: mechanism's MX-record rotation coordination, and the per-selector DKIM-key-rotation cadence THIS page documents (multi-month CAdES selector rotation, dual-selector zero-downtime pattern) ALL commit to the same publisher DNS zone — the per-mechanism operational discipline coordinates with the DKIM-rotation cadence at the per- publisher per-domain DNS-zone-commit boundary, making the SPF-mechanism choice an upstream determinant of the joint SPF + DKIM operational discipline this page synthesizes.
• SPF qualifiers explained - the PUBLISHER-PUBLISHED-SPF-QUALIFIER- CHOICE-DETERMINES-WHETHER-SPF-LEG-CAN- CONTRIBUTE-AT-ALL-TO-DMARC-ALIGNMENT-OR- WHETHER-DKIM-ALIGNMENT-IS-THE-SOLE-LOAD- BEARING-LEG companion to this DKIM- alignment-with-DMARC operator-reference. Where THIS page documents the DKIM-side identifier-alignment leg of the RFC 7489 §6.6.2 OR-conjunction (the d=-tag-vs-From:- domain strict-vs-relaxed alignment evaluation), the dedicated SPF-qualifiers- explained spoke documents the STRUCTURALLY-LOAD-BEARING publisher-side qualifier-prefix choice at the SPF record's terminating all mechanism (or any other mechanism's qualifier prefix) whose four coordination dimensions determine whether the SPF leg of the same OR-conjunction can EVER contribute a passing leg for traffic outside the SPF-matched mechanism set: (i) publisher publishing -all (HardFail qualifier) commits to a receiver-side spf=fail verdict for any IP not matched by an earlier mechanism - the SPF leg of the OR- conjunction structurally CANNOT contribute a passing leg for unmatched traffic, making DKIM alignment the SOLE LOAD-BEARING DMARC- pass path for any traffic falling outside the SPF record's authorised-sender envelope, and elevating this page's DKIM- alignment computation to mandatory- correctness status; the SPF-qualifiers spoke documents the HardFail-default operator commitment and the per-mail- stream-profile rationale for choosing -all; (ii) publisher publishing ~all (SoftFail qualifier — operator-default during DMARC rollout per RFC 7208 §10.1 guidance) commits to a receiver-side spf=softfail verdict for unmatched IPs - the SPF leg STILL cannot contribute a passing leg, BUT the receiver- side handling differs: spf=softfail is a non-pass verdict at the SPF layer but is treated as ALIGNMENT-NEUTRAL by RFC 7489 §6.6.2 (only spf=pass + aligned counts as the SPF-aligned leg), so the DKIM-alignment leg this page documents remains the SOLE LOAD-BEARING DMARC-pass path for unmatched traffic regardless of the SoftFail-vs-HardFail choice; the SPF-qualifiers spoke documents the SoftFail-vs-HardFail operator-discipline distinction and the per-receiver-implementation handling variation between strict-spf-fail rejecting receivers and softfail-tolerant receivers; (iii) publisher publishing ?all (Neutral qualifier) or +all (Pass qualifier) at the SPF record's terminating mechanism is the AUTHENTICATION-DEFEAT operator-mistake class - ?all produces spf=neutral verdict for unmatched IPs (treated as non-pass at the alignment layer just like SoftFail and HardFail), and +all produces spf=pass for ANY sending IP regardless of authorisation (the maximally-permissive publisher-defeat-of-SPF qualifier choice that authorises the entire IPv4/IPv6 Internet to spoof the publisher's domain) - the DKIM alignment leg this page documents becomes the SOLE OPERATIONAL CONTROL against +all publisher mistakes because the SPF leg has been structurally disarmed; the SPF- qualifiers spoke documents the +all/?all- defeat-operator-mistake-class and the publisher-side audit discipline for catching the operator-mistake before it ships; and (iv) the SPF qualifier prefix attaches to EVERY mechanism in the record (not just the terminating all) - publisher publishing ~include:thirdparty.example.com commits to SoftFail for IPs matched by the third-party include (rather than the default-Pass +include that omitted-qualifier shorthand expands to), which structurally inverts the SPF contribution of every IP authorised via the third-party include from SPF-PASS-CONTRIBUTING to SPF-SOFTFAIL-NON-CONTRIBUTING, making DKIM alignment the LOAD-BEARING DMARC-pass path for every third-party- include-routed traffic stream; the SPF-qualifiers spoke documents the per- mechanism qualifier-prefix discipline and the operator-decision framework for choosing per-mechanism qualifier prefixes that align the publisher's SPF contribution profile with the publisher's DKIM-alignment-load-bearing strategy this page documents.
• SPF 10-DNS-lookup limit (RFC 7208 §4.6.4) — the SPF-LOOKUP-CASCADE-OVERFLOW-AS- DKIM-ALIGNMENT-RESCUE-MECHANISM- MOTIVATOR companion to this DKIM- alignment-with-DMARC page. DMARC enforcement requires EITHER SPF or DKIM alignment (RFC 7489 §6.6.2 OR-conjunction) — and the SPF lookup- cascade overrun is the OPERATIONALLY- MOST-COMMON scenario where the SPF- half of the disjunction breaks at permerror, leaving DKIM alignment as the SOLE remaining viable path to DMARC pass. Where THIS page documents the DKIM-side discipline for the rescue-mechanism scenario (the d=-tag-and-From-header alignment evaluation, the adkim=r / adkim=s alignment mode decision, the operational rules for ensuring a DKIM-aligned signature survives forwarder modifications), the SPF-lookup-limit spoke is the UPSTREAM-FAILURE-MODE-MOTIVATOR companion documenting WHY DKIM- alignment posture must be load- bearing across the customer's mail streams — because as soon as the customer's cumulative include-cascade breaches the 10-DNS-query budget (typical Workspace + Microsoft 365 + SendGrid + Mailchimp stack consumes 9-12 lookups before any additional SaaS-platform integration), the receiver's SPF evaluator emits permerror, the SPF half of the DMARC OR-conjunction collapses, and DKIM alignment becomes the SOLE remaining path to DMARC pass. Required reading for operators running customer-domain SPF records anywhere near the 10-lookup threshold — the spoke's per- platform lookup-cost accounting + budget-overrun-remediation framework determines whether DKIM alignment posture must be LOAD- BEARING (because SPF is one integration away from breaking) or PARTIAL-LOAD-BEARING (because SPF has headroom). The strategic complement to THIS page's DKIM- side discipline — read both together when authoring a DMARC- pass redundancy plan for a multi- platform-sender customer domain.
• SPF forwarding issues (the second-hop break) — the canonical SPF-failure scenario where DKIM alignment becomes the SOLE viable path to DMARC pass — the SPF-FORWARDER-BREAK-MOTIVATING-DKIM-ALIGNMENT companion to this DKIM-alignment-with-DMARC page. DMARC enforcement requires EITHER SPF or DKIM alignment (RFC 7489 §6.6.2 OR-conjunction) — and the forwarder-second-hop SPF break is THE canonical scenario where the SPF-half of the disjunction breaks cryptographically, leaving DKIM alignment as the SOLE remaining viable path to DMARC pass. Where THIS page documents the DKIM-side alignment mechanics (d=-tag-vs-RFC5322-From match, relaxed-vs-strict alignment, third-party-sender DKIM re-signing patterns), the forwarding-issues spoke documents the per-forwarder-class catalogue (corporate mailing list, vacation .forward, MLM expander, alumni-alias service, .edu redirect) of legitimate-forwarder topologies where the connecting client IP at the FINAL receiver is the FORWARDER's IP — not the ORIGINAL sender's IP — so the SPF check fails by construction at the second hop and ONLY the DKIM-aligned half of the DMARC disjunction can produce a pass. Read the forwarding-issues spoke alongside this page when designing a DKIM-alignment-PRIMARY DMARC posture for a domain whose outbound mail traverses any of these legitimate- forwarder topologies, and you need the per-forwarder-class catalogue to confirm WHICH downstream forwarders actually preserve the DKIM signature through their forwarding rewrites (Mailman pre-1980 list-footer injection breaks DKIM body hash; Sieve/.forward typically preserves DKIM; ARC-sealing forwarders explicitly preserve the original DKIM verdict).
• Email deliverability fundamentals — the ALIGNMENT-DRIVEN-DELIVERABILITY-OUTCOME business-outcome consumer of every alignment-pass-rate this page documents — the ALIGNMENT-DRIVEN-DELIVERABILITY-OUTCOME business-outcome companion to this DKIM-alignment-with-DMARC operational deep dive. Where THIS page documents the DKIM-alignment evaluation algorithm at the byte level (the d=-tag-vs-RFC5322-From-domain match, the adkim=r-vs-adkim=s relaxed-vs-strict mode semantics, the Public Suffix List (PSL) organisational-domain boundary lookup, the third-party-sender DKIM re-signing patterns, the onmicrosoft.com / gappssmtp.com / ESP-shared-domain alignment gotchas), the email-deliverability page documents the BUSINESS-OUTCOME consequence of every alignment-pass-rate this page catalogues: how the per-tenant / per-third-party-sender DKIM-alignment pass-rate propagates through the receiver-side accept-vs-reject-vs-spam-folder placement decision and ultimately shifts the sender's inbox-placement rate at every major mailbox provider (Gmail, Microsoft Consumer / M365, Yahoo / AOL, ProtonMail, Apple iCloud Mail). The deliverability page documents the FOUR DELIVERABILITY-OUTCOME REGIMES the per-domain DKIM-alignment-pass-rate decides between (HIGH-ALIGNMENT delivers to PRIMARY-INBOX, MEDIUM-ALIGNMENT delivers to SECONDARY-CATEGORIES like Gmail Promotions / Microsoft Focused-Other, LOW-ALIGNMENT delivers to SPAM-FOLDER, ZERO-ALIGNMENT triggers DMARC-enforced REJECT-AT-MX or DROP), and the Gmail / Yahoo February 2024 bulk-sender deliverability cliff (5,000- msgs/day senders REQUIRED to publish DMARC at p=none-or-higher with one-of-SPF-or-DKIM aligned) DKIM-alignment is the most operationally viable HALF of the OR-conjunction-disjunction to satisfy for forwarder-traversing / list-expander-traversing / rewriting-middlebox-traversing topologies. Read the deliverability page when modeling the BUSINESS-OUTCOME impact of an alignment-mode change documented here (e.g. tightening from adkim=r to adkim=s in a publication where the d=<tenant>.onmicrosoft.com gotcha is unresolved) — the alignment-pass-rate shifts the deliverability funnel modeled in the deliverability page's four-stage receiver-side acceptance → placement → engagement outcomes chain.
• DKIM-Signature header explained — the byte-by-byte tag anatomy. Documents every tag including d= and i= at the syntactic level.
• DKIM failures explained — the receiver-side verdict catalogue. Documents the seven DKIM verdicts (none, neutral, pass, fail, policy, temperror, permerror) and how they feed into the DMARC engine.
• DMARC troubleshooting — the SYMPTOM-DRIVEN-DMARC-FAIL-DIAGNOSTIC- LADDER companion to this DKIM-alignment- with-DMARC reference. Where THIS page documents the per-message DKIM-d=- tag-domain-versus-RFC-5322-From-header- organisational-domain alignment evaluation discipline (the receiver-side comparison that distinguishes dkim=pass from dkim=pass + aligned=true under RFC 7489 §6.6.2, the strict-vs- relaxed alignment-mode-driven adkim= tag-value semantics, the Public-Suffix-List-driven organisational-domain derivation, the canonical DKIM-verifies-but-DMARC-fails defect class), the DMARC-troubleshooting spoke is the STRUCTURAL DOWNSTREAM CONSUMER of every per-message DKIM-alignment evaluation outcome this page documents — the symptom-driven diagnostic ladder operators apply when triaging RUA evidence rows that report dkim=pass + dmarc=fail attributes the root cause to one of four DKIM-alignment diagnostic sub-branches. Four per-DMARC- troubleshooting-DKIM-alignment-diagnostic dimensions: (i) STRICT-VS-RELAXED-ALIGNMENT- MODE-MISCONFIGURATION root-cause attribution (when adkim=s is published but the DKIM signing domain is the organisational-domain rather than the exact 5322.From domain, every signed message produces dkim=pass + aligned=false + dmarc=fail — the spoke's Pattern-3 diagnostic branch walks the operator through the adkim= tag-value vs DKIM- signing-domain audit), (ii) ORGANISATIONAL- DOMAIN-PUBLIC-SUFFIX-LIST-DRIFT root-cause attribution (Public-Suffix-List entries can change as new public-suffix domains are added — a previously-aligned d=esp.example.co.uk + 5322.From=example.co.uk can become misaligned when example.co.uk gets added to the PSL; the spoke's Pattern-3 diagnostic branch catalogues this drift class), (iii) DKIM-D-TAG-VS-5322-FROM-BOUNDARY-TAMPERING root-cause attribution (replay-attack-class message-modification at intermediate hops produces aligned d= but post-tampering 5322.From drift; the spoke's Pattern-3 diagnostic branch cross-references the per-message Authentication-Results-Original chain decode), (iv) THIRD-PARTY-SIGNER-DKIM-PASS- WITHOUT-ALIGNMENT root-cause attribution (the canonical defect class — SaaS senders signing with their own d= producing DKIM-pass but never DKIM-aligned-with-the-publisher's- From-header — the spoke's Pattern-3 diagnostic branch walks the operator through the per-sender DKIM-signing-domain inventory audit). Critical when this DKIM-alignment-with-DMARC page's reader observes per-message dkim=pass + dmarc=fail rows in the aggregate RUA stream — the DMARC-troubleshooting spoke's symptom- driven Pattern-3 alignment-failure diagnostic branch is the canonical next step in the root-cause attribution workflow.
• DKIM troubleshooting — the ALIGNMENT-VS-VERIFICATION-DISTINCTION-TROUBLESHOOTING companion to this DKIM-alignment-with-DMARC page. Where THIS page documents the RFC 7489 §3.1.1 DKIM-alignment rule (a DKIM-authenticated identifier is the signing domain d= compared against the RFC 5322 From: header organisational domain under relaxed mode or against the FQDN under strict mode), the troubleshooting spoke documents the OPERATOR DIAGNOSIS PATH for the SINGLE MOST COMMON OPERATOR CONFUSION in the DKIM/DMARC interaction surface: DKIM verifies BUT DMARC fails. The STRUCTURALLY-DISTINCT failure classes this confusion conflates: (i) DKIM verification fail — the cryptographic check on the DKIM-Signature header (bh= body-hash match + b= signed-header signature check against the public key retrieved at <s>._domainkey.<d>) fails outright (Authentication-Results emits dkim=fail), (ii) DKIM alignment fail — the cryptographic verification PASSES (Authentication-Results emits dkim=pass) but the d= domain on the verified signature is UNRELATED to the From: domain (e.g., d=sendgrid.net while From: is billing@acme.com), producing dmarc=fail with dkim=pass in the Authentication-Results stack. The troubleshooting spoke documents the diagnostic 1-liners that distinguish the two classes: (a) read the Authentication-Results header (if dkim=pass is present AND dmarc=fail is present → alignment fail, not verification fail), (b) compare the DKIM-Signature header d= tag against the From: domain's organisational-domain (PSL lookup), (c) check the aggregate-report auth_results/dkim/domain field against identifiers/header_from. For each diagnosis the troubleshooting spoke documents the remediation: verification fail → fix the underlying key publication, selector rotation, or canonicalization mismatch; alignment fail → coordinate with the third-party sender to either (i) adopt CNAME-delegated DKIM with a customer-domain signing identity, or (ii) sign with an additional operator-controlled DKIM key in parallel to the vendor's default key (dual-signing pattern), or (iii) sacrifice DKIM-aligned-pass in favour of SPF-aligned-pass via custom Return-Path / MAIL FROM domain adoption. The troubleshooting spoke also documents the per-vendor CNAME-delegation pattern (SendGrid em._domainkey.acme.com CNAMEd to em._domainkey.u123.wl.sendgrid.net, Mailgun mta._domainkey.acme.com CNAMEd to mta._domainkey.mg.acme.com, ESP-managed custom-domain DKIM via Marketo / HubSpot / Mailchimp / Klaviyo signing-domain customisation). Read the troubleshooting spoke whenever the RUA stream surfaces a dkim=pass + dmarc=fail row — the spoke is the load-bearing alignment-vs-verification diagnosis reference and the canonical third-party-sender DKIM-alignment remediation catalogue.
• DKIM explained (protocol primer) — the high-level DKIM signing pipeline. Start here if you are new to DKIM.
• Email security glossary — the DKIM-ALIGNMENT-VOCABULARY- RESOLVES-TO-CROSS-CLUSTER-EMAIL-SECURITY- TERMINOLOGY-HUB companion to this DKIM- side alignment procedural deep dive. Where THIS page documents the per-receiver per- message DKIM-side identifier-alignment computation (d=-tag organisational-domain match against RFC 5322 From header organisational-domain, RFC 7489 §3.1.1 relaxed-vs-strict alignment-mode semantics, per-message AUID-vs-d=-tag granularity, per-publisher per-selector signing-domain publication discipline), the email- security-glossary spoke is the cross- cluster TERMINOLOGY-RESOLUTION reference whose per-term canonical definitions establish the shared vocabulary every DKIM-alignment discussion structurally depends on at FOUR per-term vocabulary- resolution dimensions: (i) per- term identifier-alignment-vocabulary canonical-definition reference — the glossary resolves DKIM-alignment- specific terms (identifier alignment, signing-domain, organisational-domain, relaxed-vs-strict mode, AUID, AAR) without per-page re-definition; per- publisher operator audit of per-receiver per-message DMARC-aggregate-report-decode depends on consistent per-term vocabulary-resolution across every sibling DKIM / DMARC / ARC spoke; (ii) per-term cross-cluster cross- protocol vocabulary-coherence invariant — the glossary cross-references DKIM-alignment-vocabulary against parallel SPF-alignment-vocabulary (envelope-MAIL-FROM, return-path domain, SPF-aligned-pass), parallel BIMI- vocabulary (VMC, CMC, BIMI-renderer), parallel ARC-vocabulary (AAR, AMS, AS, cv=-tag) so per-publisher operator cross-protocol reasoning preserves per- term semantics across cluster boundaries; (iii) per-term DMARC-aggregate-report-decode-vocabulary canonical-definition reference — the glossary resolves per-aggregate- report per-row decode-vocabulary (dkim= pass / dkim=fail / dkim=permerror, aligned=true / aligned=false, header- identifier-match) so per-publisher operator per-row evidence-decode preserves per-term DMARC-aggregate-report-grammar semantics; (iv) per-term operator- discipline-vocabulary canonical-definition reference for cross-protocol per-receiver per-day per-publisher KPI-dashboard terminology — the glossary resolves per-receiver per-day per- publisher KPI-vocabulary (DKIM-aligned- pass-rate, per-receiver coverage, baseline-shift, KPI-1 / KPI-2 / KPI-3) so per-publisher operator per-day operational-discipline preserves per-term KPI-dashboard semantics shared across every sibling monitoring / reporting / troubleshooting spoke.
• DKIM best practices — the DKIM-DMARC-ALIGNMENT-PROCEDURE- DEPENDS-ON-DKIM-BEST-PRACTICES companion to this DKIM-side alignment procedural deep dive. Where THIS page documents the DKIM-side identifier alignment computation (d= tag matches RFC 5322 From organisational domain, strict-vs-relaxed alignment modes, third-party-sender DKIM re-signing, the Public Suffix List boundary rules), the DKIM best-practices spoke is the SYNTHESIS LAYER documenting the 15-rule operator- discipline ruleset whose upstream rules determine whether the alignment computation ever PRODUCES a passing verdict on the receiver side. The DKIM-DMARC-ALIGNMENT- PROCEDURE-DEPENDS-ON-DKIM-BEST-PRACTICES cross-reference establishes five specific best-practices-rules-to-alignment dependencies: (i) "sign with d= matching the organisational domain of the From: header" best-practices rule is the UPSTREAM PRECONDITION for the d=-aligns- with-RFC-5322-From alignment computation THIS page documents — if the operator does NOT follow the d= best-practices rule, the alignment computation cannot pass even when DKIM signature itself verifies cryptographically; (ii) "sign all outbound messages, not just a sample" best-practices rule ensures the alignment computation has a DKIM signature to evaluate at all — when only a subset of outbound is signed, the unsigned messages cannot align even if all OTHER best- practices rules are followed; (iii) "use 2048-bit RSA keys at minimum" best-practices rule avoids the Mail.Ru / Yahoo / Google reduced-trust-on- weak-keys penalty that surfaces as dkim=neutral instead of dkim=pass — alignment cannot succeed on a neutral verdict; (iv) "use the relaxed/relaxed canonicalisation default" best-practices rule maximises forward-survivability across MIME-rewrite intermediaries (the SAME rationale the canonicalisation spoke documents) — when operators violate the rule by choosing simple/simple, alignment fails on every mailing-list / forwarder hop the receiver-side DKIM verification encounters; (v) "rotate selectors quarterly with a 30-day publish-overlap window" best- practices rule ensures no message signed with a recently-retired selector loses alignment mid-flight — when the rotation rule is violated and the old selector is removed too soon, in-flight messages signed with the retired selector fail DKIM verification and DROP from alignment-eligible into alignment-failed. Read THIS page when authoring the DMARC alignment procedure; read the DKIM best-practices spoke for the upstream operator-discipline rules whose adherence determines whether the alignment computation can ever produce a passing verdict.
• DKIM for Microsoft 365 — the full deployment procedure for enabling custom-domain DKIM via the Defender portal. The onmicrosoft.com gotcha section above references this page.
• MTA-STS for Microsoft 365 — the M365-TENANT-TRANSPORT-LAYER-INBOUND- AND-OUTBOUND-MX-STARTTLS-ENFORCEMENT-AS- STRUCTURALLY-ORTHOGONAL-COMPLEMENT-TO- APPLICATION-LAYER-DKIM-d-IDENTIFIER- ALIGNMENT companion to this DKIM-alignment- with-DMARC deep dive. Where THIS page documents the per-message DKIM d=<signing-domain> ↔ RFC 5322 From:-header-domain alignment computation (the adkim=r Public Suffix List organisational-domain match vs the adkim=s byte-identical match toggle, the canonical alignment-failure patterns the onmicrosoft.com gotcha and gappssmtp.com gotcha produce, the receiver- side identifier-alignment evaluation algorithm) — i.e. the APPLICATION-LAYER DKIM-IDENTIFIER-AUTHENTICATION-LEG of the M365-tenant mail-authentication stack — the MTA-STS-for-Microsoft-365 spoke is the STRUCTURALLY-ORTHOGONAL TRANSPORT-LAYER- STARTTLS-ENFORCEMENT-LEG companion documenting the M365-tenant-specific transport-security publication topology that operates IN PARALLEL to the application-layer DKIM-alignment surface this page documents. The two spokes together describe the FULL M365-tenant receive-side and send-side authentication posture across FOUR structurally-distinct layering perspectives: (i) DKIM- d= identifier alignment runs at the APPLICATION LAYER on the per-message DKIM-Signature header bytes, INDEPENDENT of which transport-layer STARTTLS posture the receiver-side MX negotiated — an M365-Exchange-Online-outbound message signed with d=<customer-vanity- domain> can pass DKIM-alignment under adkim=s even when the outbound STARTTLS negotiation to the recipient's MX failed with certificate-host-mismatch or starttls-not-supported — the two layers do not gate each other; (ii) MTA-STS mode:enforce STARTTLS-MX-allow-list publication runs at the TRANSPORT LAYER on the inbound MX delivery channel, INDEPENDENT of the receiver-side DKIM-alignment verdict — an M365-tenant publishing https://mta-sts.<customer-domain> /.well-known/mta-sts.txt with mode: enforce + mx: *.mail.protection.outlook.com constrains EXTERNAL senders' transport- layer delivery channel to the Microsoft- managed Exchange Online MX hostnames, regardless of whether those external senders' messages pass or fail DKIM- alignment under THIS page's algorithm at the M365 tenant's recipient mailbox; (iii) the M365 tenant operator must independently maintain BOTH application-layer DKIM-alignment (via the selector1._domainkey + selector2._domainkey CNAME publication this page's onmicrosoft.com gotcha section references) AND transport- layer MTA-STS enforcement (via the _mta-sts.<domain> TXT record + mta-sts.<domain> HTTPS policy-file publication the spoke documents) — both publications are prerequisites for the FULL M365 tenant mail-authentication-and-transport-security posture; one without the other leaves a structurally-exploitable defense gap (DKIM-alignment-only leaves transport downgrade open; MTA-STS-only does not prevent application-layer DKIM-replay or DKIM-misalignment attacks); (iv) the DMARC aggregate-report auth_results/dkim block records per-message DKIM-alignment verdicts while the SMTP TLS-RPT JSON aggregate records per-receiver STARTTLS negotiation outcomes — operationally complementary evidence streams for the same M365 tenant mail-stream; an operator reconciling DKIM-alignment-fail events against TLS-RPT certificate-host-mismatch events for the same recipient domain over the same time window can distinguish between application-layer DKIM- misconfiguration (M365 selector1/selector2 CNAME deletion or Defender-portal toggle OFF) and transport-layer cert-chain misconfiguration (CAA-blocked mta-sts cert renewal at the customer vanity domain). Read the MTA-STS-for-Microsoft-365 spoke alongside this DKIM-alignment deep dive when designing the full M365-tenant inbound and outbound mail-authentication posture — the M365-tenant-specific MTA-STS mode:enforce publication topology the spoke documents is the structurally-orthogonal transport-layer complement to the application-layer DKIM-d=-identifier-alignment computation this page documents.
• TLS-RPT report format (RFC 8460 §4 JSON schema deep dive) — the DKIM-ALIGNMENT-PASS-RATE-AT-AGGREGATE-RUA-PIPELINE-IS-DOWNSTREAM-CONSUMER-OF-PER-RECEIVER-TRANSPORT-LAYER-TLS-RPT-JSON-FAILURE-DETAILS companion documenting the per-field JSON schema ("organization-name" / "date-range" / "policies" with "summary" + "failure-details" sub-records) of the aggregate JSON report receivers serialize per RFC 8460 §4 schema, whose per-failure-record consumption is the load-bearing transport-layer-confound-exclusion analytics the DKIM-alignment operator depends on when interpreting per-RUA-window aligned- pass-rate divergence between MTA-STS-supporting and opportunistic-TLS-receiver populations, across FOUR DKIM-alignment TLS-RPT-JSON-consumer dimensions: (1) Per-RUA-window DKIM-aligned-pass-rate divergence between MTA-STS-supporting (Gmail / Yahoo / Microsoft) and opportunistic-TLS (smaller receivers) populations as transport-confound attribution signal — when the per-RUA-window DKIM-aligned-pass-rate at MTA-STS-supporting receivers diverges materially from the opportunistic-TLS-receiver rate, the JSON TLS-RPT aggregate report's summary.total-failure-session-count at the divergent receiver-class is the load-bearing transport-confound-attribution signal that distinguishes alignment-rate divergence due to publisher misconfiguration (DKIM-side problem) from divergence due to receiver-class transport-layer downgrade (transport-side problem masquerading as DKIM-alignment-rate divergence); (2) Per-RUA-window failure-details[].sending-mta-ip correlation with publisher-side DKIM signer infrastructure for replay-attack discrimination — the JSON per-failure-record sending-mta-ip identifies the SMTP client IP that initiated the downgrade-affected session; correlating this IP against the publisher's known DKIM signer IPs at the same RUA-window distinguishes between legitimate-signer body-harvesting (potential DKIM-replay-attack vector) and downstream-only downgrade not affecting publisher-side aligned-pass-rate; (3) Per-RUA-window failure-details[].result-type byte-token classification at the DKIM-aligned-pass-rate inflection point — when the per-RUA-window aligned-pass-rate crosses below the ramp-exit floor, the co-occurring TLS-RPT result-type classification catalogue (starttls-not-supported, certificate-host-mismatch, sts-policy-fetch-error) at the same RUA-window identifies whether the pass-rate dip is caused by transport-layer receiver-class shifts vs application-layer DKIM publisher-side regression; (4) Cross-protocol RUA-pipeline ingestion-window alignment between DMARC aggregate XML and TLS-RPT aggregate JSON per-publisher-domain — the JSON per-policy date-range Unix-timestamp byte-fields establish the TLS-RPT aggregate window-anchor; aligning this window with the DMARC RUA XML per-receiver window-anchor yields the load-bearing per-window joint-analytics framework where DKIM-aligned-pass-rate divergence at one receiver-class can be triangulated against TLS-RPT transport-failure-rate divergence at the same receiver-class to discriminate transport-layer-confound-exclusion vs DKIM-alignment-side-regression. The JSON-report-consumption across these four dimensions is the load-bearing transport-layer-confound-exclusion analytics every DKIM-alignment operator depends on when distinguishing legitimate publisher-side DKIM-alignment regression from receiver-class-segregated transport-layer downgrade that confounds the aligned-pass-rate accounting documented on THIS page.
• DKIM for Google Workspace — the full deployment procedure for enabling custom-domain DKIM via the Admin Console. The gappssmtp.com gotcha section above references this page.
• DKIM canonicalization — the c= tag deep dive. Relevant because c=relaxed/relaxed maximizes forward-survivability, which keeps DKIM alignment intact through realistic mail paths.
• DKIM cryptography basics (RFC 8301) — the DKIM-CRYPTOGRAPHIC-PRIMITIVE- RFC-8301-RSA-VS-ED25519-AS-ALIGNMENT- VERDICT-CRYPTOGRAPHIC-FOUNDATION companion to this DKIM-alignment-with- DMARC reference. Where THIS page documents the RFC 7489 §3.1.1 relaxed-vs-strict d=-domain- vs-RFC5322.From-domain identifier alignment evaluation (which executes ONLY after a dkim=pass cryptographic verdict has been produced), the DKIM cryptography basics spoke is the RFC 8301 cryptographic- primitive companion whose RSA-with-SHA- 256 / Ed25519-with-SHA-256 keypair generation, public-key publication via the p=<base64-pubkey> tag of the <selector>._domainkey. <d-domain> TXT RR, and receiver-side signature-verification algorithm are the structural cryptographic prerequisites for the DKIM-side identifier-alignment evaluation THIS page documents. The DKIM-CRYPTOGRAPHIC- PRIMITIVE-RFC-8301-RSA-VS-ED25519-AS- ALIGNMENT-VERDICT-CRYPTOGRAPHIC- FOUNDATION cross-reference establishes FOUR structurally-distinct cryptographic- primitive-vs-alignment-evaluation dependency dimensions: (i) cryptographic-verdict-gates-alignment- evaluation dependency — DKIM identifier alignment per RFC 7489 §3.1.1 evaluates ONLY against the d=-domain of a dkim=pass signature; the cryptographic-primitive layer (RFC 8301 RSA-with-SHA-256 or Ed25519-with-SHA- 256) is what produces the dkim=pass verdict; cryptographic-failure (RSA-key-too-short per RFC 8301 §3.1, RSA-with-SHA-1 deprecated per RFC 8301 §3.2, Ed25519- with-SHA-1 nonsensical per RFC 8463 normative semantics) collapses the dkim=pass verdict to dkim=fail and the alignment evaluation NEVER executes; the cryptographic-primitive layer is the structural prerequisite for THIS page's alignment evaluation; (ii) key- rotation-vs-alignment-window dependency — DKIM key rotation per RFC 6376 §3.6.2 (publish new <new-selector>._domainkey. <d-domain> TXT RR with new p=<new-base64-pubkey> BEFORE retiring old selector) maintains continuity of the cryptographic-pass verdict across the rotation window; alignment evaluation MUST see a dkim=pass verdict for EITHER the old selector OR the new selector to keep the alignment-pass contract uninterrupted; if both selectors briefly produce dkim=fail verdicts (because the new key has propagated but the old signer is still using old key against old DNS pubkey that has been removed), the alignment-pass contract collapses across the rotation window; cryptographic- key-rotation discipline is the structural gate for sustained alignment-pass evaluation; (iii) algorithm- agility-vs-alignment-mode-coexistence dependency — RFC 8463 Ed25519 introduction created the algorithm- agility dual-signing pattern (publisher adds an Ed25519 signature alongside the RSA signature using a different selector so that legacy verifiers ignore Ed25519 and modern verifiers prefer Ed25519); the alignment-evaluation layer THIS page documents must handle DUAL signatures (typically same d=-domain, different selectors) and apply alignment evaluation to whichever signature verified cryptographically; the algorithm-agility cryptographic-layer discipline is the structural complement to the alignment-mode coexistence evaluation; (iv) weak-key-vs- replay-attack-vs-alignment-bypass dependency — DKIM replay attacks (RFC 6376 §8.6) exploit cryptographic- signature reuse across attacker- controlled message contexts; if the cryptographic key is too short (RSA-1024 has been compromised in published research; cryptographic-key- strength minimum is RSA-2048 per RFC 8301 §3.1 normative requirement), the attacker can forge a signature that cryptographically verifies AND structurally satisfies alignment for an arbitrary attacker-controlled RFC5322.From domain — collapsing the publisher's INTENDED alignment-and- cryptography contract entirely; the cryptographic-key-strength discipline is the structural foundation that THIS page's alignment evaluation depends on for its security guarantees to hold. Pair this page (the DKIM identifier- alignment evaluation reference) with the DKIM cryptography basics spoke (the RFC 8301 cryptographic-primitive reference) when an operator audits the end-to-end DKIM-side authentication-and- alignment chain and needs to apply the same cryptographic-primitive-vs-alignment- evaluation dependency discipline across BOTH the cryptographic-verification layer and the alignment-evaluation layer the DMARC pass-fail verdict depends on.
• DKIM DNS-TXT-record byte syntax — the DKIM-PUBLIC-KEY-RR-BYTE-LAYOUT-AS- RECEIVER-SIDE-ALIGNMENT-EVALUATION-DNS- LOOKUP-PRECONDITION companion to this DKIM-alignment-with-DMARC reference. Where THIS page documents the receiver-side DKIM d=<signing-domain> vs RFC 5322 From: header organisational-domain alignment computation evaluated AFTER the DKIM signature has cryptographically verified, the DKIM-DNS-syntax spoke is the UPSTREAM BYTE-GRAMMAR PRECONDITION reference documenting the RFC 6376 §3.6.1 per-tag byte-layout that the receiver-side <selector>._domainkey.<signing- domain> TXT-record lookup MUST resolve to a syntactically valid response BEFORE the signature-verification cascade can produce a dkim=pass verdict for the alignment computation to operate on. The DKIM-PUBLIC-KEY-RR-BYTE- LAYOUT-AS-ALIGNMENT-PRECONDITION cross- reference establishes FIVE structurally- distinct DNS-syntax-failure-to-alignment- failure dependencies: (i) missing or malformed p= public-key tag — the receiver-side TXT lookup returns a record but the p= tag is empty (revoked-key sentinel per RFC 6376 §3.6.1) or base64- decoding-malformed, causing the signature- verification cascade to fail with public-key-not-loadable; the alignment computation THIS page documents is SKIPPED at the receiver because there is no DKIM-pass leg to evaluate alignment on; (ii) missing or wrong v= version tag — the TXT record is missing the v=DKIM1 sentinel or carries an unrecognised version value, causing RFC 6376 §3.6.1 compliant verifiers to reject the entire record AS NOT A DKIM KEY RECORD even if all other tags are well-formed; same downstream consequence — alignment is skipped because there is no DKIM-pass leg; (iii) mismatched k= key-type tag vs a= signing-algorithm tag in the DKIM-Signature header — the TXT record carries k=ed25519 but the signature header carries a=rsa-sha256 (or vice-versa), causing the verifier to reject the signature with key-type-mismatch; the alignment computation does not evaluate because the cryptographic verification leg failed BEFORE alignment was reached; (iv) t=y testing-mode flag in the TXT record — RFC 6376 §3.6.1 specifies the t=y flag instructs verifiers to treat the signature as test-mode-only (often producing dkim=neutral rather than dkim=pass in receiver implementations); a neutral verdict is not a pass, so the DMARC evaluation logic THIS page documents records the DKIM leg as not-passed and alignment cannot count toward the DMARC-pass disposition; (v) byte- length overflow at the 512-byte UDP DNS response boundary — large public-key payloads (2048-bit or 4096-bit RSA encoded base64) can push the TXT record's wire-format response past 512 bytes, requiring TCP fallback or EDNS0 UDP-size extension support at the receiver-side resolver; resolvers that do not gracefully fall back return truncated responses, causing the signature-verification to fail with public-key-not-resolvable and again skipping the alignment computation. Pair this page (the DKIM-side receiver-side identifier-alignment evaluation reference) with the DKIM-DNS-syntax spoke (the publisher-side per-tag byte-grammar compliance reference) when diagnosing a sudden RUA-stream collapse to dkim=permerror or dkim=temperror rows that appear orthogonal to any signing-side rotation event — the spoke documents the canonical compliant byte-layout for each tag whose violation produces the receiver-side resolution-or-parse-failure that strips the DKIM-pass leg the alignment computation on this page depends on.
• DKIM selectors explained — the s= tag deep dive. Operator discipline around selector rotation.
• DKIM key rotation — the ROTATION-WINDOW-AS-DKIM-ALIGNMENT- PAUSE-VECTOR companion to this DKIM-alignment- with-DMARC reference. Where THIS page documents the DKIM-side identifier-alignment computation (the DKIM-Signature: d=<signing-domain> tag vs From: header organisational- domain comparison governed by adkim=r relaxed-mode default vs adkim=s strict-mode), the dkim-key-rotation spoke documents the KEY-LIFECYCLE DISCIPLINE whose rotation- window misconfigurations are a leading cause of TRANSIENT DKIM-side alignment failures the publisher observes in the RUA aggregate-report stream as intermittent dkim=fail or dkim=pass aligned=false rows. The two structurally-distinct rotation-window failure modes the spoke catalogues both produce DKIM-side alignment-fail symptoms observable on this page's alignment-evaluation pathway: (i) old-key-published-and-new-key- signed window — the publisher rotates the signing-side from selector_old to selector_new BEFORE publishing the selector_new._ domainkey TXT record (or before the new selector's TXT record propagates through recursive resolvers), causing receiver-side selector_new._domainkey lookups to return NXDOMAIN, the DKIM signature verification to fail with public-key-not-found, and the alignment computation THIS page documents to be SKIPPED at the receiver because there is no DKIM-pass leg to even evaluate alignment on; (ii) new-key- published-and-old-key-signed window — the publisher publishes the new selector TXT record BUT the signing-side has not yet rotated to the new selector, AND the old selector's TXT record has been prematurely deleted, causing selector_old._domainkey lookups to return NXDOMAIN with the same downstream consequence. Both failure-modes produce the same observable symptom on this page's alignment evaluation pathway: aligned-DKIM rate collapses for the rotation-window duration, and the DKIM-alignment-as-DMARC-pass-precondition chain documented on this page fails for that interim period. Pair this page (the DKIM-side identifier-alignment receiver- side evaluation reference) with the dkim-key-rotation spoke (the publisher- side KEY-LIFECYCLE-DISCIPLINE rotation- window operational reference) when diagnosing transient DKIM-alignment-fail bursts in the RUA stream that correlate with a publisher-side selector rotation event — the spoke documents the canonical SAFE-ROTATION procedure (publish-new-key → wait-N-TTL-cycles → sign-with-new-key → wait-M-TTL-cycles → retire-old-key) whose phase-ordering eliminates the rotation-window alignment-pause vector this page's alignment evaluation otherwise observes.
• DKIM replay attacks (RFC 6376 §8.6) — the REPLAY-ATTACK-VS-DKIM-ALIGNMENT companion to this DKIM-alignment-with- DMARC reference. Where THIS page documents the DKIM-side identifier- alignment computation (the DKIM- Signature: d=<signing-domain> tag vs From: header organisational-domain comparison governed by adkim=r relaxed-mode default vs adkim=s strict-mode), the replay-attacks spoke documents the RFC 6376 §8.6 REPLAY-ATTACK structural vector whose captured-and-re-injected signed-message variant exploits the load-bearing property that DKIM- signature-validity is TIME-AND-IP- INDEPENDENT: a captured legitimate DKIM-signed message replayed by an attacker from a different sending IP to a different receiver STILL produces a receiver-side dkim=pass verdict (because the cryptographic signature validates), STILL produces a receiver- side dkim-alignment=pass verdict (because the d= tag is preserved verbatim from the original legitimate sender), and STILL produces a receiver-side DMARC-pass verdict via the DKIM-side alignment leg this page documents — the alignment computation cannot distinguish replay from origin emission. The replay-attacks spoke documents the four structural defenses against this vector at FOUR replay- attack-vs-DKIM-alignment dimensions: (i) narrow signing scope discipline — operators constrain the original signed-message scope (small List-Unsubscribe URIs, signed Content-Type, signed Subject:) so the replayed message diverges from the original in a way that breaks signature validity; (ii) RFC 6376 x= tag short signature lifetime — publishing a signature-expiration timestamp limits the replay-window attackers can exploit; (iii) per-key-lifetime rotation cadence — frequent key rotation (M365 Defender Rotate- DkimSigningConfig per-quarter cadence, Workspace operator-managed manual rotation cadence) shortens the attacker's per-key replay window; (iv) receiver-side replay- detection signals — sophisticated receivers correlate per-Message-ID replay counts and downgrade-or-reject the replayed variants even when the alignment computation evaluates as pass. Pair this DKIM-alignment-with-DMARC reference (the per-message alignment evaluation contract) with the replay- attacks spoke (the time-and-IP- independence vulnerability the alignment evaluation cannot distinguish from origin emission) for the complete picture of when DKIM-pass + DKIM-alignment=pass actually means a legitimate origin- emitted message vs a replayed attacker-injected variant.
• DMARC records explained — the canonical DMARC tag reference. Documents adkim=, aspf=, p=, sp=, np=, and every other DMARC tag.
• DMARC policy rollout — the staged rollout from p=none through p=quarantine to p=reject with the relaxed-to-strict alignment migration.
• DMARC deployment checklist — the GREEN-PATH-DEPLOYMENT-CHECKLIST-PHASE- 1-DKIM-PREREQUISITE-VERIFICATION companion to this DKIM-alignment-with-DMARC reference. Where THIS page documents the per-message DKIM-alignment evaluation discipline (the receiver-side comparison that distinguishes dkim=pass from dkim=pass + aligned=true under RFC 7489 §6.6.2, the strict-vs-relaxed alignment-mode-driven adkim= tag-value semantics, the Public-Suffix-List- driven organisational-domain derivation, the canonical DKIM-verifies-but-DMARC-fails defect class), the DMARC-deployment- checklist is the OPERATOR-FACING WORKFLOW DRIVER whose Phase 1 DKIM-prerequisite- verification step LOAD-BEARINGLY DEPENDS on the per-message DKIM-alignment evaluation outcome this page documents. Four per- deployment-checklist-DKIM-alignment- prerequisite dimensions: (i) PHASE-1-DKIM- SIGNING-DOMAIN-AUDIT (the checklist's Phase 1 DKIM-prerequisite step requires operators to audit every per-sender DKIM- signing-domain against the 5322.From organisational- domain — THIS page documents the exact evaluation rule the audit must apply), (ii) PHASE-1-ADKIM-TAG-VALUE-AUTHORING-DISCIPLINE (the checklist's Phase 1 DMARC-tag-list- authoring sub-step requires operators to choose between adkim=r relaxed and adkim=s strict — THIS page documents the per-mode per-source operational consequence the operator must factor into the choice), (iii) PHASE-2-RUA-INGESTION-DKIM-ALIGNMENT- ROW-AUDIT (the checklist's Phase 2 RUA- publication step produces evidence rows whose per-message DKIM-alignment evaluation outcome the operator audits against THIS page's defect catalogue — every dkim=pass + aligned=false row in the Phase 2 baseline blocks Phase 3 ramp advancement until remediated), (iv) PHASE-3-RAMP-DKIM-ALIGNMENT- BASELINE-VERIFICATION (the checklist's Phase 3 p=none observation window requires a clean DKIM-aligned-pass baseline before advancing to Phase 4 p=quarantine — every third-party-signer DKIM-pass-without- alignment row in the Phase 3 baseline catalogues a Phase 4 ramp-risk operators must remediate via per-sender DKIM- signing-domain coordination before advancement). Critical when operators executing the DMARC-deployment-checklist reach the Phase 1 DKIM-prerequisite- verification step or any subsequent ramp-phase advancement gate that consumes per-message DKIM-alignment evaluation outcomes — THIS page is the canonical per-evaluation reference for the checklist's load-bearing DKIM- alignment prerequisite.
• DMARC multi-domain strategy — the portfolio-level design that applies the DKIM alignment engine documented on THIS page across the organizational-domain umbrella: primary brand domain, subdomains, parked domains, M&A-acquired brands, transactional sender domains, and shared marketing senders. Where THIS page documents the per-message d= ↔ RFC 5322.From alignment mechanic and the adkim=r vs. adkim=s tolerance toggle, the multi-domain strategy page documents how to deploy that engine CONSISTENTLY across N domains — per-domain DKIM-key inventory, the organizational-domain vs. subdomain-domain alignment fanout via Public Suffix List boundaries, the sp= / np= rollup that lets the parent policy govern unsigned subdomain & non-existent subdomain traffic, and the per-domain selector-rotation discipline that prevents one domain's key-roll incident from cascading across the portfolio's DMARC verdicts.
• ARC explained — the Authenticated Received Chain. The protocol-level fix when forwarder body modification breaks the original DKIM signature.
• BIMI SVG Tiny PS logo requirements — the DKIM-ALIGNMENT-PARALLEL- PREREQUISITE-WITH-SVG-BYTE-COMPLIANCE- FOR-BIMI-DISPLAY companion reference. Where THIS page documents the DKIM- side of the DMARC-alignment computation (d=-tag-vs-RFC5322-From match, relaxed-vs-strict alignment, third-party-sender DKIM re-signing patterns) that is the protocol-side prerequisite for any operator wanting to ship BIMI (BIMI display requires the DMARC engine to return a pass verdict, which requires EITHER SPF alignment OR DKIM alignment via the RFC 7489 §6.6.2 OR-conjunction), the BIMI-SVG- requirements spoke documents the STRUCTURALLY-ORTHOGONAL VISUAL-ASSET- BYTE-COMPLIANCE prerequisite that the brand logo SVG must satisfy in parallel: the SVG file served at the BIMI record's l= URL must conform to the SVG Tiny PS profile (a strict subset of SVG 1.1 + SVG 2 forbidding <script>, <foreignObject>, external references, raster image embeds, animation elements, and non-presentation namespaces; requiring a square viewBox, the baseProfile="tiny-ps" root attribute, and a <title> element immediately after the <svg> root) AND must hit a strict 32KB file-size ceiling for Gmail's BIMI rendering path. The implication: the DKIM alignment pass-rate gate this page documents is one of TWO structurally- orthogonal prerequisites BIMI display requires at the receiving MUA (the OTHER being the SVG-byte-compliance gate the requirements spoke documents) — both gates must be satisfied for the brand logo to render at the inbox display surface. An operator who ships a perfect DKIM alignment posture but an SVG that violates the Tiny PS profile invests in the alignment prerequisite this page documents but gets ZERO BIMI display value because the visual-asset-byte-compliance gate the requirements spoke documents is independently unsatisfied. Read the BIMI-SVG-requirements spoke alongside this page when scoping a BIMI-aware DKIM alignment posture — the DKIM alignment work documented on this page only produces a brand-logo render outcome if it is paired with the SVG-byte-compliance work the requirements spoke documents.
• Email authentication pillar — the cluster index page mapping the SPF + DKIM + DMARC + BIMI + MTA-STS + TLS-RPT relationships.
• DNS propagation explained — the DKIM-PUBLIC-KEY-AND-CNAME- DELEGATION-DNS-PROPAGATION-WINDOW-AS-LOAD- BEARING-UPSTREAM-GATE-OF-DKIM-ALIGNED-PASS- VERDICT-EMERGENCE-AT-RECEIVER-AT-FOUR- PROPAGATION-TIMING-COUPLING-DIMENSIONS companion to this DKIM-alignment-with- DMARC reference. Where THIS page documents the DKIM d=-tag header-from- domain alignment evaluation algorithm at receiver-side DMARC evaluation, the DNS- propagation spoke is the canonical propagation-window discipline reference whose per-resolver per-zone-version cache- aging behaviour determines WHEN the per- publisher per-selector DKIM public-key publication becomes globally resolvable at the receiver's recursive-resolver cache tier — at four DKIM-alignment-vs-DNS- propagation timing coupling dimensions: (i) per-publisher per-selector DKIM public-key DNS-publication propagation window gate — the per-publisher per-selector <selector>._domainkey. <d-domain> TXT-RR publishing the RSA-2048 / Ed25519 public-key material the receiver's DKIM-verification algorithm fetches is subject to the recursive-resolver-cache TTL aging behaviour THIS spoke documents; until the per-receiver-cohort recursive-resolver cache has aged the prior-key-version cache-entry and refetched the new key- version from the authoritative server, the per-publisher per-selector key- rotation publication is NOT YET observable at the receiver-side DKIM- verification boundary the DKIM-alignment evaluation depends on; (ii) per- publisher per-selector CNAME-delegation propagation window gate — when the per-publisher per-selector DKIM publication is delegated via CNAME to a third-party ESP-managed <selector>.<d-domain>. <esp-platform>.com authoritative key-publication target, the per-receiver-cohort recursive- resolver cache must propagate BOTH the per-publisher per-selector CNAME-RR AND the per-ESP target TXT-RR before the per-message DKIM-Signature verification can resolve — DOUBLE the per-resolver per-zone cache-aging gate the DKIM- alignment evaluation depends on; (iii) per-publisher per-rotation cutover dual-selector overlap-window vs DNS-propagation window coordination constraint — per-publisher per- rotation dual-selector overlap-window publication discipline (publish the new selector FIRST, wait for receiver-side DNS-propagation completion, THEN rotate the signing-key to the new selector) is gated by the per-resolver per-zone cache-aging propagation-window THIS spoke quantifies — the per-publisher per-rotation cutover-discipline ladder bottoms out on the DNS-propagation- window-discipline reference; (iv) per-publisher per-domain DMARC TXT-RR publication propagation window gate — the per-publisher per- domain _dmarc.<header-from- domain> TXT-RR publishing the DMARC v=DMARC1; p=<policy>; adkim=<mode>; aspf=<mode> ... policy the receiver's DKIM- alignment evaluation consumes is itself subject to the per-resolver per-zone cache-aging propagation window — meaning per-publisher per-domain DMARC-policy rotation (e.g. adkim=r → adkim=s tightening) is not uniformly observable at receivers until the per-receiver- cohort recursive-resolver cache has aged the prior-policy-version cache-entry. Read the DNS-propagation spoke ALONGSIDE this DKIM-alignment-with-DMARC reference whenever a per-publisher per-domain DKIM- alignment evaluation timing question emerges — THIS page gives the DKIM d=-tag alignment evaluation algorithm, the DNS-propagation spoke gives the upstream propagation-window discipline reference the DKIM-alignment evaluation depends on at the per- publisher per-selector DNS-publication boundary.
• DMARC aggregate reports (RFC 7489 §7.2 XML rua) — the PER-MESSAGE-DKIM-ALIGNMENT- EVALUATION-AS-LOAD-BEARING-UPSTREAM- PRODUCER-OF-AGGREGATE-XML-RECORD-LEVEL- DKIM-ALIGNMENT-EVIDENCE-ROW-VOCABULARY companion to this DKIM-alignment-with-DMARC algorithm reference. Where THIS page documents the per-message DKIM-alignment- evaluation algorithm (the RFC 7489 §3.1.1 d=-vs-header-From organisational-domain match algorithm + the strict-vs-relaxed adkim= mode determination + the per-message dkim=pass-AND-aligned=true conjunction producing DKIM-aligned-pass), the DMARC-aggregate-reports spoke is the per-receiver per-source-IP per-day RFC 7489 §7.2 XML aggregate-report record-level DOWNSTREAM CAPTURE whose record-level evidence-row vocabulary is the DIRECT OPERATOR-SIDE OBSERVABILITY SURFACE for per-message DKIM-alignment outcomes at FOUR per-alignment-evaluation-to-aggregate- evidence-coupling dimensions: (i) per-record row/policy_evaluated/dkim=pass attribute as the per-message DKIM-aligned- pass evidence-row producer — the aggregate-reports spoke documents the per-record per-source-IP per-day DKIM- aligned-pass evidence-row aggregation that is the receiver-side per-message DKIM- alignment-pass-rate observability primitive operators consume; (ii) per-record row/policy_evaluated/dkim=fail attribute as the per-message DKIM-aligned- fail evidence-row producer surfacing the misalignment failure modes THIS page documents (d=-tag mismatch with header- From, intermediary body-modification breaking body-hash, missing DKIM signature on legitimate mail) — the aggregate-reports spoke documents the per-record per-source-IP per-day DKIM- aligned-fail evidence-row aggregation operators consume to attribute alignment- failure root causes per-source-IP per-day; (iii) per-record row/auth_results/dkim/result= attribute as the per-message receiver-side dkim= verdict-string evidence-row producer surfacing the dkim=pass-vs-dkim=fail-vs- dkim=temperror-vs-dkim=permerror verification outcome the DKIM-alignment evaluation algorithm consumes as the load-bearing input — the aggregate-reports spoke documents the per-record receiver-side dkim= verdict evidence-row vocabulary operators consume to attribute per-message DKIM-alignment outcomes to upstream DKIM-verification outcomes; (iv) per-record row/auth_results/dkim/domain= attribute as the per-message DKIM-Signature d=-tag-value evidence-row producer surfacing the per-message d=-tag the alignment-evaluation algorithm compares against the header-From organisational domain — the aggregate-reports spoke documents the per-record d=-tag evidence-row vocabulary operators consume to attribute alignment outcomes to specific per-message DKIM- Signature d=-tag values during legitimate- sender third-party-signing-platform onboarding investigations. Read the DMARC- aggregate-reports spoke ALONGSIDE this DKIM-alignment-with-DMARC algorithm reference when investigating per-receiver per-source-IP per-day DKIM-alignment-pass- rate or DKIM-alignment-fail-rate evidence- row patterns — the spoke is the canonical per-receiver per-source-IP per-day RFC 7489 §7.2 XML aggregate-report record-level downstream-capture reference for the per-message DKIM-alignment-evaluation algorithm this page documents.
• DMARC forensic (failure / RUF) reports — the DMARC forensic-reports spoke documents the RFC 6591 ARF + RFC 7489 §7.3 + RFC 8460 per-message failure- envelope grammar that the receiver-side DMARC evaluator emits to the publisher- published ruf= mailbox for per-message DMARC-evaluation-failure evidence. Four DKIM-ALIGNMENT-VERDICT-VS- FORENSIC-REPORT-DIAGNOSTIC-BLOCK coupling axes the forensic-reports spoke documents: (i) per-message DKIM-leg identifier-alignment-fail verdict (the per-message d=-tag vs From:-header organizational- domain mismatch this page documents) STRUCTURALLY POPULATES the per-failure ARF envelope's Authentication-Results: diagnostic-block dkim=fail +policy.d=<mismatched-domain> + header.d=<signed-domain> evidence-row — the per-message DKIM-alignment-fail verdict THIS page's alignment-evaluation algorithm emits is the LOAD-BEARING per-message attribution evidence the forensic-reports spoke catalogues as the canonical downstream-capture format; (ii) per- message DKIM-leg multiple-signature any-aligns-wins rule this page documents STRUCTURALLY DETERMINES the per-failure ARF envelope's per-signature attribution evidence at the per-publisher per-domain per-receiver per-day forensic-evidence-row granularity — per-message multiple-signature deployments (e.g. on-prem-Exchange + transactional-ESP co-signing) populate the per-failure ARF envelope with per-signature dkim=fail / dkim=pass rows whose any- aligns-wins resolution at the per-message DKIM-leg alignment-evaluation algorithm THIS page documents drives the per-failure envelope's emitted-vs-suppressed decision; (iii) per-publisher per-domain adkim=r vs adkim=s strict-vs-relaxed alignment-mode choice STRUCTURALLY DETERMINES the per-failure ARF-envelope-emission rate floor at the per-receiver per-day per-source-IP diagnostic-evidence-row granularity — an operator who flips per-publisher per-domain alignment-mode from adkim=r (relaxed organizational- domain match) to adkim=s (strict exact-match) STRUCTURALLY raises the per-publisher per-domain per-receiver per-day forensic-envelope-emission-rate floor by approximately the subdomain-signing-cohort fraction of the outbound traffic mix, and the forensic- reports spoke documents the resulting per- failure ARF envelope's Authentication-Results: + Original-Mail-From: + Original-Rcpt-To: + redacted-headers diagnostic-block as the canonical per-failure evidence for the alignment-mode-flip operator-decision retroactive readiness audit; (iv) per-message DKIM-leg onmicrosoft.com-gotcha, gappssmtp.com-gotcha, and ESP- CNAME-delegated-default-domain mis-publishing defect-classes this page catalogues STRUCTURALLY POPULATE the per-failure ARF envelope's policy.d= + header.d= diagnostic evidence with cryptographically-legitimate publisher- signed mail mis-attributed to the per-tenant default-domain rather than the publisher organizational domain — the per-failure ARF envelope's dkim=pass-but- dmarc=fail evidence-row emitted under this defect class is the DEFINITIVE diagnostic the operator consumes to attribute the per-publisher per-domain alignment-failure to the tenant-default- domain mis-signing operator-discipline regression rather than to attacker spoofing. Read THIS page when reasoning about the per-message DKIM-leg identifier- alignment-evaluation algorithm; read the forensic-reports spoke when AUDITING the per-message RFC 6591 ARF + RFC 7489 §7.3 per-failure-envelope per-message-diagnostic- block evidence-row stream whose per-failure DKIM-diagnostic block is the canonical downstream-capture format of the per-message DKIM-alignment-evaluation verdict THIS page documents at the receiver-side DMARC-evaluator emit-to-ruf=-mailbox boundary.
• RFC 7489 §3.1.1 — DKIM-authenticated identifiers — the normative source for DKIM alignment.
• RFC 7489 §3.2 — Organizational Domain — the PSL-based organizational-domain extraction rule for relaxed alignment.
• Public Suffix List — the authoritative source for organizational-domain extraction.
• DMARC for SaaS senders — the DKIM-D-DOMAIN-ALIGNMENT-FAILURE- MODE-FOR-SAAS-SHARED-IDENTITY-DEFAULT companion to this DKIM-alignment-with- DMARC operational deep dive. Where THIS page documents the DKIM-alignment evaluation algorithm (the d=-tag-vs-RFC5322-From- domain match per RFC 7489 §3.1.1, the adkim=r-vs-adkim=s relaxed-vs-strict mode semantics, the Public Suffix List (PSL) organisational- domain boundary lookup, the third-party- sender DKIM re-signing patterns that preserve alignment), the SaaS-senders spoke is the SINGLE-MOST-COMMON- ALIGNMENT-FAILURE-CONSUMER companion documenting the CANONICAL failure mode every SaaS-sender deployment encounters at p=quarantine / p=reject enforcement: the SaaS platform signs the outgoing message with the PLATFORM's d= (e.g. d=salesforce.com, d=hubspotemail.net, d=sendgrid.net, d=mailchimpapp.com) by default — producing a cryptographically-valid dkim=pass verdict at the receiver — but the RFC5322 From: header carries the CUSTOMER's domain (e.g. From: hello@example.com), so the alignment check this page documents produces aligned=false even though the signature itself is valid. The SaaS-senders spoke documents the per-platform remediation cookbook: the custom-domain-signing feature each major SaaS platform offers (Salesforce "Email Relay" + "Signed by Domain", HubSpot "Connect a sending domain", SendGrid "Authenticated Domain", Mailchimp "Verified Sending Domain", Marketo "Branded Sending Domain"), the per-platform DKIM-CNAME publication pattern the customer must add to their DNS zone, the per-platform SPF-include token the customer must add alongside, the per-platform Authentication- Results timeline (typically 24-72 hours for the platform to provision the per-tenant signing key after the CNAME resolves), and the RUA- report verification workflow that confirms the dkim=pass + aligned= true transition after the per- tenant signing-key activation. Read the SaaS-senders spoke alongside this page when an operator investigating a dkim=pass + aligned=false RUA-report row identifies the source as a SaaS platform and needs the per-platform custom-domain-signing remediation reference to close the alignment gap.
• DMARC for transactional email — the DKIM-D-DOMAIN-ALIGNMENT-WITH-FROM- HEADER-ORG-DOMAIN-FOR-DELEGATED-ESP-SIGNING- AT-TRANSACTIONAL-SENDER-EGRESS companion to this DKIM-alignment-with-DMARC operational deep dive. Where THIS page documents the DKIM-alignment evaluation algorithm (the d=-tag-vs- RFC5322-From-domain match per RFC 7489 §3.1.1, the adkim=r-vs- adkim=s relaxed-vs-strict mode semantics, the Public Suffix List (PSL) organisational-domain boundary lookup, the third-party-sender DKIM re-signing patterns that preserve alignment), the DMARC-for-transactional- email spoke is the CANONICAL- TRANSACTIONAL-ESP-ALIGNMENT-FAILURE-MODE companion documenting the SINGLE-MOST-COMMON ALIGNMENT-FAILURE-CONSUMER role operators encounter at p=quarantine / p=reject enforcement: the transactional ESP signs the outgoing message with the ESP's d= (e.g. d=sendgrid.net, d=mailgun.org, d=amazonses.com, d=pm-bounces.net for Postmark, d=sparkpostmail.com, d=mandrillapp.com for MailChimp Transactional) by default — producing a cryptographically-valid dkim=pass verdict at the receiver — but the RFC5322 From: header carries the CUSTOMER's domain (e.g. From: receipt@example.com), so the alignment check this page documents produces aligned=false even though the signature itself is valid. The DMARC-for-transactional-email spoke documents the per-ESP custom-domain- signing remediation cookbook: the delegated-DKIM-signing feature each major transactional ESP offers (SendGrid "Sender Authentication" / "Domain Authentication" with the s1._domainkey + s2._domainkey CNAME pair pointing to s1.domainkey.uXXXX.wlYYY.sendgrid.net, Mailgun "Domain verification" with the krs._domainkey + k1._domainkey CNAME pair, Amazon SES "Easy DKIM" with three <selector>._domainkey CNAMEs pointing to <selector>.dkim.amazonses.com, Postmark "DKIM" with two <selector>._domainkey CNAMEs, SparkPost "Sending Domain" with a single scph0816._domainkey CNAME, MailChimp Transactional "Sending Domains" with two CNAMEs), the per-ESP envelope-MAIL-FROM delegated-return-path-domain publication pattern that closes the SPF-aligned-pass side (SendGrid's em.<customer>.com bounce-domain CNAME, Mailgun's mg.<customer>.com subdomain, SES's custom MAIL FROM domain configuration, Postmark's Return-Path domain), and the per-ESP DMARC-aligned-pass verification workflow operators use to confirm the remediation closed the alignment gap. The DMARC-for-transactional-email spoke is structurally distinct from the SaaS-senders spoke immediately above — TRANSACTIONAL ESPs egress per- transaction notifications (password resets, receipts, MFA codes), SaaS SENDERS are multi-tenant platforms sending on customer-domain behalf — but both produce the canonical dkim=pass + aligned=false RUA-row pattern this DKIM-alignment-with- DMARC page surfaces as the central operational consequence of the alignment-vs-verification distinction. Read the DMARC-for-transactional-email spoke alongside this page when an operator investigating a dkim=pass + aligned=false RUA-report row identifies the source as a transactional ESP (per the source_ip attribution to a SendGrid / Mailgun / SES / Postmark / SparkPost / MailChimp Transactional IP cohort) and needs the per-ESP custom-domain- signing remediation reference to close the alignment gap and unlock p=quarantine / p=reject enforcement for the customer's domain.
• DMARC for Microsoft 365 hybrid Exchange — the HYBRID-EXCHANGE-DUAL-SIGNER-PROBLEM-AT-CMT-VS-CLASSIC-HYBRID-VS-SPLIT-DOMAIN-TOPOLOGY-BOUNDARY companion to this DKIM-alignment-with-DMARC page. Where THIS page documents the RFC 7489 §3.1.1 DKIM-alignment evaluation rule at the byte level (the d=-tag-vs-RFC-5322-From-domain match, the adkim=r-vs-adkim=s relaxed-vs-strict mode semantics, the PSL organisational-domain boundary lookup, the onmicrosoft.com / gappssmtp.com / ESP-shared-domain alignment gotchas, and the third-party-sender DKIM re-signing patterns that preserve alignment through SaaS-sender hops), the hybrid-Exchange deployment spoke documents the canonical Microsoft enterprise topology where the SAME DKIM-alignment algorithm produces STRUCTURALLY DIFFERENT results depending on the chosen mail-flow topology — the FIVE outbound paths the page enumerates (Classic Hybrid with on-prem-outbound default, Centralized Mail Transport with cloud-outbound boundary, Split-domain coexistence, Edge Transport server deployments, and Direct Send) each produce a DIFFERENT d=-signing-identity at the final cloud egress, with the FOUR DKIM-signing-pattern decision-tree leaves the hybrid page catalogues (cloud-only signing pattern preferred, on-prem-only signing pattern acceptable, dual-signer signing pattern AVOID, and d=<tenant>.onmicrosoft.com signing pattern AVOID) each corresponding to a DIFFERENT alignment outcome at the receiver. The hybrid-Exchange spoke is the canonical operational reference for the dual-signer-d-tag-disagreement RUA-row pattern (a message signed by BOTH on-prem Exchange's selector AND Exchange Online's selector1.<tenant>._domainkey / selector2.<tenant>._domainkey with two different d= identifiers that may produce DIFFERENT alignment verdicts under adkim=s) that the DKIM-alignment-evaluation algorithm documented here surfaces as the DUAL-SIGNER-PROBLEM the hybrid spoke instructs operators to RESOLVE before DMARC p=reject enforcement, plus the Send-Connector / Default-Frontend- Connector / Anonymous-SMTP-Relay configuration pitfalls that cause the on-prem-Exchange-side DKIM-Signature header to be STRIPPED at the cloud boundary, the ARC-sealing-the-on-prem-to- cloud-relay (RFC 8617) pattern that cryptographically preserves the original DKIM verdict across the hybrid hop, and the four-phase DMARC rollout sequence (p=none → p=quarantine 10% → p=quarantine 100% → p=reject) gated on each phase's per-topology dual-signer-alignment-pass- rate plateau. Read the hybrid-Exchange spoke alongside this page when investigating a dkim=pass + aligned=false RUA-report row whose source_ip attribution maps to a Microsoft Exchange Online IP cohort (40.92.0.0/15, 40.107.0.0/16, 52.100.0.0/14) or to an on-prem Exchange edge-relay deployment, and you need the per-topology hybrid- deployment reference to confirm WHICH of the five mail-flow paths the message traversed and WHICH of the four DKIM- signing patterns the topology's signer configuration corresponds to — the alignment-evaluation algorithm this page documents is the same in both provider-agnostic and hybrid-Exchange contexts, but the d=-signing-identity observable at the cloud egress (the input to the algorithm) is topology-determined in hybrid Exchange and the hybrid spoke is the canonical reference for which signing identity will be present at which boundary.
• Why SPF alone is insufficient — the DKIM-ALIGNMENT-AS-COMPLEMENTARY- DEFENSE-LAYER-COVERING-THE-SEVEN- STRUCTURAL-SPF-PROTOCOL-LIMITATIONS companion to this DKIM-alignment-with- DMARC algorithm deep dive. Where THIS page documents the DKIM-side identifier- alignment computation (RFC 7489 §3.1.1, adkim=r vs adkim=s, the Public Suffix List organizational- domain extraction algorithm, the multiple- signature "any aligns wins" rule, the M365 onmicrosoft.com gotcha, the Workspace gappssmtp.com gotcha, the SPF-vs-DKIM asymmetry under forwarding), the why-SPF-alone-is- insufficient pillar is the BROADER STRUCTURAL ARGUMENT companion documenting the SEVEN structural classes of SPF- protocol limitation that EACH require DKIM-alignment-with-DMARC as the complementary defense layer: (i) forwarding-rewrites-the-envelope- MAIL-FROM at every legitimate forwarder, breaking SPF alignment at the receiving MTA — DKIM-alignment SURVIVES forwarding because the DKIM-Signature header is signed over the message bytes not the envelope, and the forwarded message arrives at the second-hop receiver with the original publisher's DKIM signature INTACT and the original publisher's d= aligned with the original From: header; (ii) shared-hosting-multi-tenant-IP- cohort-as-publisher-identity where SPF authorizes an entire shared-IP cohort that may contain dozens of customer domains, leaving SPF as a poor publisher-distinguisher — DKIM closes this gap because each customer's DKIM private key is per-customer-isolated and the d= tag in the signature identifies the specific customer's organizational domain; (iii) MAIL-FROM-vs-From-header- asymmetry where SPF authenticates only the envelope MAIL FROM and DMARC alignment under SPF requires an aligned envelope MAIL FROM domain — DKIM-alignment authenticates the From: header domain DIRECTLY via the d=-tag-vs-From:-header organizational-domain comparison, closing the cross-header-asymmetry gap; (iv) cloud-provider-IP-rotation where stale SPF authorizations point at IPs now allocated to other customers (including attackers) — DKIM is immune because the IP topology is irrelevant to the cryptographic signature verification; (v) the 10-DNS- lookup-budget cap collapsing entire SPF check to permerror — DKIM-aligned signatures DO NOT consume the SPF DNS- lookup budget because DKIM uses a single per-signature TXT-record lookup at the <selector>._domainkey.<d-domain> DNS name that is independent of the publisher's SPF record; (vi) SPF has NO message-content-integrity guarantee — DKIM's body-hash + header-hash signature is precisely a cryptographic content-integrity proof binding the signed headers and body to the signing private key; (vii) SPF has NO publication-private- key concept — DKIM's RSA / Ed25519 signature requires the signer to hold the publisher-private key, providing a cryptographic-strength publisher-authority proof SPF's IP-cohort-membership check cannot provide. Read the why-SPF-alone- is-insufficient pillar when authoring the operational argument for the DKIM- alignment-with-DMARC deployment urgency — DKIM-alignment is not a "nice-to-have addition" to a working SPF posture, it is the SOLE STRUCTURAL DEFENSE against the seven distinct attack and misconfiguration classes SPF cannot defend against by protocol design.
• Email spoofing taxonomy — the DKIM-ALIGNMENT-AS-PRIMARY-DEFENSE- AGAINST-DIRECT-DOMAIN-SPOOFING-VARIANTS companion to this DKIM-alignment-with- DMARC evaluation-contract reference. Where THIS page documents the per-mode evaluation-contract for DKIM identifier alignment under DMARC (adkim=r relaxed-mode Organizational-Domain match vs adkim=s strict-mode byte- identical match, PSL eTLD+1 algorithm, multiple-signature "any aligns wins" rule, M365 / Workspace gotchas), the email-spoofing spoke documents the SEVEN-TECHNIQUE spoofing taxonomy whose FOUR DIRECT-DOMAIN-SPOOFING VARIANTS the DKIM-identifier-alignment computation THIS page documents is the LOAD-BEARING APPLICATION-LAYER DEFENSE against, across FOUR alignment-as- spoofing-defense dimensions: (i) From: header rewrite spoofing → DKIM-alignment d=-vs-From:-domain comparison structurally rejects — the most basic direct-domain spoofing attempt (attacker forges From: header with no cryptographic signature relationship to the victim's domain) produces dkim=none or dkim=fail AND aligned=false at the receiver, which the DKIM-alignment computation THIS page documents translates into the policy_evaluated.dkim=fail verdict that drives the published p=quarantine / p=reject rejection decision; (ii) display-name + look-alike spoofing → DKIM-alignment d= captures the look-alike's domain, not the impersonated victim's — the look-alike-domain spoofing variant produces DKIM-aligned messages from the LOOK-ALIKE domain (e.g. example-corp.com signed by attacker), which under DKIM- alignment the receiver sees as a DIFFERENT policy_evaluated.header_from domain whose alignment-evaluation is against the attacker's published DMARC posture, leaving the victim's domain DMARC posture untouched — a critical Stage-6 RUA blind-spot that requires operator-side look- alike-detection vigilance beyond DKIM-alignment alone; (iii) compromised-legitimate-sender spoofing → DKIM-alignment d=<victim> passes but the signature is attacker-controlled infrastructure — when an attacker compromises legitimate signing infrastructure that cryptographically aligns under the victim's d= and the receiver's alignment-evaluation passes, the spoofing-taxonomy spoke catalogues this as the dkim=pass + aligned=true + UNFAMILIAR SOURCE_IP RUA-row signature requiring operator-side source_ip-vs-sender- inventory diff analysis; (iv) third-party-vendor-compromise spoofing → per-vendor-selector publication isolation discipline determines blast radius — the third-party-vendor-compromise variant the spoofing taxonomy catalogues at item (vii) of the seven-technique catalogue is structurally LIMITED by the per- vendor-selector publication discipline (each ESP gets its OWN selector under <selector>._domainkey.<d>), which the DKIM-alignment-with-DMARC computation THIS page documents treats as cryptographically isolated per the "any aligns wins" multiple- signature alignment rule — meaning a single compromised vendor's selector does NOT cryptographically invalidate signatures under other selectors. Read the email-spoofing spoke WITH this DKIM-alignment page when triaging a specific spoofing-attempt sample: the seven-technique taxonomy is the canonical reference for UNDERSTANDING WHICH spoofing variant a given RUA-row signature corresponds to, and this DKIM- alignment evaluation-contract is the per-mode by-line reference for understanding WHY the receiver produced the verdict it did.
• Business email compromise (BEC) defence — the DKIM-IDENTIFIER-ALIGNMENT-AS- PRIMARY-CRYPTOGRAPHIC-DEFENCE- AGAINST-BUSINESS-EMAIL-COMPROMISE consumer-of-alignment-pass-posture companion to this DKIM-alignment- with-DMARC page. Where the email- spoofing taxonomy spoke documents the seven structurally-distinct spoofing techniques as a protocol- level catalogue, the BEC spoke is the financial-loss-quantified, human-engineering-amplified, multi-stage-attack-pattern companion documenting the FBI IC3-tracked attack class whose 2024 reported loss was $2.9B globally — and whose canonical stage-1 reconnaissance- plus-impersonation step is exact- domain-spoofing of the target executive's RFC5322 From: header, which the DKIM-d=-↔- From-domain alignment evaluation THIS page documents is the LOAD- BEARING APPLICATION-LAYER DEFENCE against at FOUR BEC-attack-stage alignment-evaluation dimensions: (i) stage-1 exact-domain- spoof of the CEO or CFO From: header → DKIM-aligned signature absence forces DMARC reject under p=reject — the BEC spoke's stage-1 catalogue documents the attacker's characteristic exact-domain impersonation of the victim organisation's senior executive (CEO, CFO, finance lead), which produces a forged RFC5322 From: header whose d= tag the attacker cannot cryptographically sign (no access to the legitimate domain's DKIM private key); receiver evaluates the message under DMARC and finds NO aligned DKIM signature (dkim=none or dkim=fail + aligned=N/A), which means the DMARC OR-conjunction collapses, which means the publisher's p=reject policy directs the receiver to reject — the DKIM-alignment computation THIS page documents is the SINGLE-POINT-OF-FAILURE-PREVENTION cryptographic gate at stage 1 of the attack chain; (ii) stage-2 lookalike-domain BEC variant → DKIM-alignment evaluates against the LOOKALIKE's d= identifier, not the victim's, exposing the BEC-via- cousin-domain attack class to publisher-side RUA visibility via the dmarc_aggregate_reports pipeline — the BEC spoke's stage-2 catalogue documents the lookalike-domain variant where the attacker registers company-llc.com instead of impersonating company.com; in this variant DKIM alignment EVALUATES against the LOOKALIKE's d=company-llc.com identifier, which the attacker CAN cryptographically sign (own private key, own DNS), producing a valid dkim=pass result that ALIGNS with the LOOKALIKE's RFC5322 From: header — meaning the cryptographic alignment-pass posture THIS page documents does NOT prevent the lookalike-domain variant (DMARC is bound to a specific publisher's d=, not to "any plausible domain"), but DOES expose the attack class to publisher-side RUA visibility when the victim's domain is published in company.com's rua= URI — the publisher receives no DMARC row for the cousin- domain (because the cousin is a different publisher), but per-tenant SaaS-platform-level SOC monitoring detects the cousin-registration via upstream lookalike-domain intelligence feeds; (iii) stage-3 reply-chain- hijack BEC variant → DKIM- alignment-aligned-but-content- legitimate-then-thread-pivot attack defeats per-message alignment but is detected by thread-internal-anomaly- analysis — the BEC spoke's stage-3 catalogue documents the most sophisticated variant, where the attacker compromises an in-thread participant's mailbox (typically via separate credential-theft attack), replies legitimately under their own d=- aligned signature for messages 1–N of the conversation, then pivots at message N+1 to a social-engineering payload (wire- transfer redirect, vendor- payment-instructions change); in this variant the DKIM-alignment- evaluation THIS page documents passes correctly at every message (the compromised user IS the legitimate signer), but the thread-pivot is detected by complementary controls (DLP rules, finance-process two-channel verification, EDR alerts on the compromised user's endpoint) — making explicit that DKIM alignment is NECESSARY but NOT SUFFICIENT for full BEC defence, and the stage-3 variant motivates the LAYERED-CONTROLS posture documented in the BEC spoke; (iv) stage-4 post-compromise outbound-spoof from the victim's OWN domain → DKIM-alignment passes for the attacker, motivating per-account anomaly-detection and credential-rotation discipline — the BEC spoke's stage-4 catalogue documents the variant where the attacker has fully compromised a user account at the victim organisation and sends outbound BEC from the victim's OWN infrastructure; in this case the DKIM-alignment evaluation THIS page documents passes CORRECTLY (the attacker is sending from inside the cryptographic perimeter under the publisher's own d= identifier with the publisher's own private key), but the BEC spoke documents the COMPLEMENTARY controls that detect the compromise (impossible-travel sign-in alerts, anomalous- send-volume detection, atypical- recipient-domain analysis, MFA- bypass forensics) — making explicit that DKIM alignment is the OUTBOUND-INTEGRITY gate but not the INBOUND- COMPROMISE detector, and the stage-4 variant motivates the IDENTITY-LAYER plus APPLICATION- LAYER posture documented in the BEC spoke. Read the BEC spoke WITH this DKIM-alignment page when authoring the layered- defence posture for an organisation in the FBI IC3 BEC-target categories (manufacturing, legal, finance, real-estate, construction) — the BEC spoke is the business-outcome threat-modelling reference cataloguing the attack-stage evidence and complementary controls; THIS DKIM-alignment- with-DMARC page is the application-layer cryptographic- gate reference for stage 1 prevention (and stages 2–4 scope-boundary acknowledgement).
• How attackers bypass weak DMARC — the DKIM-IDENTIFIER-ALIGNMENT-AS- PRIMARY-CRYPTOGRAPHIC-DEFENSE-AGAINST- 22-TECHNIQUE-ATTACKER-BYPASS-CATALOGUE- AT-FOUR-DKIM-ALIGNMENT-MODE-CHOICE-VS- ATTACKER-BYPASS-CLASS-DEFENSE-COVERAGE- DIMENSIONS companion to this DKIM- alignment-with-DMARC mechanics reference. Where THIS page documents the RFC 7489 §3.1.1 DKIM-side identifier-alignment algorithm (the adkim=r relaxed-mode organisational-domain-extraction-via- Public-Suffix-List rule, the adkim=s strict-mode FQDN-literal-equality rule, the multiple-signature "any aligns wins" evaluation rule, the M365 tenant.onmicrosoft.com gotcha, the Workspace gappssmtp.com gotcha, the SPF-vs-DKIM asymmetry under forwarding), the attacker-bypass spoke is the OFFENSIVE-PERSPECTIVE 22- TECHNIQUE-CATALOGUE companion documenting the attacker-side bypass techniques the per-publisher per- domain adkim=-tag choice THIS page documents must defeat. Concretely, the spoke documents FOUR DKIM-alignment-mode-choice vs attacker-bypass-class-defense-coverage dimensions: (i) alignment- evasion class — cousin-domain DKIM signing under adkim=r relaxed-mode false-acceptance vulnerability — the attacker-bypass catalogue documents how an attacker can register a cousin domain (homoglyph / Unicode-confusable / Punycode-bidi) and publish their own DKIM key under the cousin domain, then sign a message with d=<cousin-domain> and a forged From:<cousin-domain> header — the per-message DKIM verification produces dkim=pass aligned under adkim=r because the cousin-domain organisational-domain matches itself, illustrating WHY the adkim=s strict-mode cousin-domain-defeat is the structural defense the publisher chooses at per-tag publication time; (ii) authentication-evasion class — third-party-vendor compromise producing LEGITIMATE vendor d=<vendor-domain> signing with attacker-controlled payload — the attacker-bypass catalogue documents how a compromised third-party vendor mailbox (the VEC variant) emits forged-payload mail through the vendor's own DKIM signing infrastructure — the per- message DKIM verification produces dkim=pass against the vendor's published key but the per-row <policy_evaluated><dkim> verdict emits fail because the vendor's d=<vendor-domain> does NOT organisationally align with the protected From:<customer-domain> — the DKIM-alignment leg this page documents is the per-tag-mode defense denying authentication-evasion-class bypass via legitimate-vendor-key misuse; (iii) policy-evasion class — subdomain-spoofing under per-domain adkim=-vs- per-subdomain adkim=-tag- absence drift — the attacker- bypass catalogue documents how an attacker can exploit per-subdomain policy-tag-drift (a parked subdomain with NO DMARC record falling back to the protected org-domain's sp=-tag policy that publishes a weak sp=none even though the parent p=reject) — the per- subdomain DKIM-alignment evaluation the protected org-domain's adkim=-tag publishes applies under organisational-domain inheritance, making the publisher's per-publication adkim=s-vs-adkim=r choice THIS page documents the per- org-domain defense against policy- evasion-class subdomain-traversal bypass; (iv) infrastructure- evasion class — DNS-cache-poisoning / BGP-hijack-against-authoritative-NS producing victim-domain DKIM key substitution — the attacker- bypass catalogue documents how an attacker who can transiently substitute the victim-domain's <selector>._domainkey.<victim-domain> TXT record (DNS-cache-poisoning against the receiver's authoritative resolver, BGP-hijack against the victim's authoritative nameservers) produces a per-message dkim=pass with aligned d=<victim-domain> — illustrating WHY the DKIM-alignment leg THIS page documents is structurally dependent on per-domain DNSSEC publication discipline and per- publisher rapid-rotation cadence as the defense against infrastructure- evasion-class bypass. Read the attacker-bypass spoke ALONGSIDE this DKIM-alignment-with-DMARC mechanics reference to understand which 22- technique attacker-bypass class each adkim=-tag-mode choice the publisher publishes at per-domain publication time structurally defeats vs structurally leaves open as a residual attack vector.
• DMARC policy modes — the DKIM-D-EQUAL-FROM-ALIGNMENT-AS- LOAD-BEARING-INPUT-TO-EVERY-P-EQUAL- POLICY-MODE-EVALUATED-VERDICT companion to THIS DKIM-alignment-with-DMARC pillar. Where THIS page documents the d=-vs-Header-From alignment primitive and the adkim= tag (relaxed vs strict) controlling the organisational-domain-vs-exact-match match-mode, the DMARC-policy-modes spoke is the publisher-side ENFORCEMENT DISCIPLINE documenting how each p=-tag value (p=none, p=quarantine, p=reject) and its sp= subdomain counterpart translate the DKIM-alignment-pass-or-fail verdict THIS page produces into a per-message receiver-side disposition at FOUR per-policy-mode-to-DKIM-alignment- input dimensions: (i) p=none monitor-only mode — the policy- modes spoke documents how p=none is the rua-stream OBSERVABILITY publication discipline that consumes the per-message DKIM- alignment-pass-or-fail verdict THIS page produces WITHOUT applying a per-message disposition; (ii) p=quarantine partial-enforcement mode — the policy-modes spoke documents how p=quarantine instructs per-receiver MTAs to spam-fold a message whose DKIM-alignment-fail-and- SPF-alignment-fail verdict (the disjunction this page documents) materialises at the verifier; (iii) p=reject full- enforcement mode — the policy- modes spoke documents how p=reject instructs per- receiver MTAs to bounce a message whose DKIM-alignment-fail-and-SPF- alignment-fail verdict materialises — the per-message DKIM-alignment-pass outcome THIS page produces is the load-bearing rescue path that prevents legitimate mail from being rejected under p=reject; (iv) sp= subdomain- policy override — the policy- modes spoke documents how sp= publishes a separate enforcement disposition for messages whose Header-From organisational- domain matches a sub-org-domain of the publisher's policy domain, which interacts with the adkim=-tag relaxed-vs- strict match-mode THIS page documents to determine the per-subdomain message-disposition. Read THIS page when understanding HOW the per-message DKIM-alignment verdict is computed; read the DMARC-policy-modes spoke when scheduling WHICH receiver-side disposition the publisher publishes for the per-message DKIM-alignment verdict THIS page computes.
• SPF PermError vs TempError — the PER-PUBLISHER-PER-MESSAGE-SPF- ERROR-CLASS-AS-LOAD-BEARING-UPSTREAM- TRIGGER-FOR-DKIM-ALIGNMENT-RELIANCE companion to this DKIM-alignment-with- DMARC reference. Where THIS page documents the per-publisher per-message DKIM-alignment evaluation discipline (per-publisher per-message DKIM d=-tag publication, per- publisher per-message DKIM-pass verdict production, per-publisher per-message DKIM-identifier-alignment-evaluation adkim=r/adkim=s per-publisher per-domain alignment-mode publication, per-publisher per-message DKIM-aligned-pass verdict production as load-bearing input to per-publisher per-message DMARC-aligned-pass evaluation), the SPF-PermError-vs- TempError spoke documents the per- publisher per-message SPF-error-class publication discipline whose per- message SPF-error-class emergence is the LOAD-BEARING upstream trigger for per-publisher per-message DMARC- evaluation reliance on the per-message DKIM-aligned-pass verdict THIS page documents the per-publisher per- message production discipline of at FOUR per-publisher per-message SPF- error-class-to-DKIM-alignment-reliance coupling dimensions: (i) per- publisher per-message SPF-permerror verdict-class as load-bearing per- message SPF-aligned-pass-path- elimination outcome forcing per- message DMARC-aligned-pass evaluation to rely on per-message DKIM-aligned- pass verdict as load-bearing surviving verdict path — per-publisher per-message SPF-permerror verdict-class emergence per RFC 7208 §4.6.4 (per- publisher per-domain SPF-record- syntax-error publication, per-publisher per-domain 10-DNS-lookup-limit-overflow per RFC 7208 §4.6.4, per-publisher per- domain void-lookup-overflow per RFC 7208 §4.6.4, per-publisher per-domain multi-record-SPF-publication-error) produces per-message spf=permerror verdict-class that defeats per-message SPF-aligned-pass evaluation per RFC 7489 §3.1.1; per-publisher per-message DMARC-aligned-pass evaluation STRUCTURALLY-FORCED to rely on per- message DKIM-aligned-pass verdict the per-publisher per-message DKIM- alignment evaluation discipline THIS page documents the per-publisher production of as the LOAD-BEARING surviving per-message verdict path; per-publisher per-domain SPF-permerror emergence at high per-message rate operationally promotes per-publisher per-message DKIM-aligned-pass discipline from REDUNDANT-ALIGNMENT-PATH to LOAD- BEARING-SINGLE-SURVIVING-ALIGNMENT- PATH; (ii) per-publisher per- message SPF-temperror verdict-class as load-bearing per-receiver per-day per- message-class SPF-aligned-pass-rate volatility-source whose intermittent emergence amplifies per-message DKIM- aligned-pass operational criticality — per-publisher per-message SPF- temperror verdict-class (per-receiver DNS-resolution-timeout, per-receiver intermittent-DNS-failure, per-receiver SPF-record-fetch-network-error per RFC 7208 §4.6.4) produces per-receiver per- day per-message-class SPF-aligned- pass-rate volatility — per-publisher per-message DKIM-aligned-pass discipline the per-publisher per-message DKIM- alignment evaluation discipline THIS page documents the per-publisher production of becomes the LOAD- BEARING per-message-class DMARC- aligned-pass-rate stabilizer absorbing per-receiver per-day per-message-class SPF-temperror-driven SPF-aligned-pass- rate volatility; (iii) per- publisher per-domain SPF-error-class- emergence-rate as load-bearing per- publisher per-domain DKIM-publication- discipline operational-criticality determinant — per-publisher per-domain SPF-permerror emergence- rate captured at per-receiver per-day per-source-IP rua-aggregate-XML row granularity directly drives per- publisher per-domain DKIM-publication- discipline operational-criticality rating — per-publisher per-domain operational team responsible for per- publisher per-domain DKIM-publication discipline the per-publisher per- message DKIM-alignment evaluation discipline THIS page documents the per-publisher production of structurally consumes per-publisher per-domain SPF- permerror-rate as load-bearing per- publisher per-DKIM-signing-infrastructure operational-criticality determinant; (iv) per-publisher per-message SPF-error-class capture at row-level granularity in rua-aggregate-XML + AFRF-forensic-evidence stream as load-bearing per-publisher per-domain SPF-error-class observability surface complementing per-message DKIM- alignment-evaluation observability — per-publisher per-receiver per- source-IP per-day rua-aggregate-XML row capture of per-message spf= permerror / spf=temperror verdict- class at row-level granularity per RFC 7489 §7 + per-publisher per- domain AFRF per-message forensic- evidence capture under per-publisher per-domain fo= failure- options-tag publication discipline operationally composes per-publisher per-domain SPF-error-class observability surface that COMPLEMENTS per-publisher per-message DKIM-alignment-evaluation observability the per-publisher per- message DKIM-alignment evaluation discipline THIS page documents the per- publisher production of operationally captures. Read the SPF-PermError-vs- TempError spoke alongside this DKIM- alignment-with-DMARC reference when planning per-publisher per-domain DKIM- publication-discipline operational- criticality scaling whose per- publisher per-domain SPF-permerror- emergence-rate the per-publisher per- receiver per-source-IP rua-aggregate- XML evidence stream captures, and when investigating per-publisher per- message DMARC-aligned-pass-rate regression whose upstream root-cause is per-publisher per-domain SPF- permerror-class emergence eliminating the per-message SPF-aligned-pass-path the per-message DKIM-aligned-pass- path the per-publisher per-message DKIM-alignment evaluation discipline THIS page documents the per-publisher production of becomes the LOAD-BEARING surviving verdict-path of.
• DMARC for Google Workspace — the WORKSPACE-TENANT-SPECIFIC DKIM-ALIGNMENT-EVALUATION-DEPLOYMENT- WORKFLOW companion to this DKIM- alignment-with-DMARC reference. Where THIS page documents the provider- agnostic per-message DKIM d=-tag vs From:<domain>-header alignment-evaluation algorithm, the Workspace deployment spoke is the WORKSPACE-TENANT-SPECIFIC alignment- evaluation execution guide at FOUR per-Workspace-tenant-to-DKIM-alignment coupling dimensions: (i) per- Workspace-tenant google._domainkey.<domain> CNAME publication discipline that delegates the canonical Workspace DKIM signing-key to Workspace-managed infrastructure while preserving the Workspace-tenant d=<workspace-tenant-domain> attribution required for alignment — the Workspace spoke documents the Workspace-tenant-specific CNAME publication step that PRODUCES the per-message d=<workspace-tenant-domain> tag THIS page's alignment-evaluation algorithm consumes as the load-bearing input; (ii) per-Workspace-tenant Workspace-managed signing-key d=-tag attribution verification — the Workspace-tenant- specific failure mode where Workspace- signed messages carry d=google.com instead of d=<workspace-tenant-domain> when the CNAME publication step is skipped or misconfigured — the Workspace spoke documents the Workspace-tenant-specific DKIM- misalignment failure-mode operators diagnose when DKIM-aligned-pass-rate is anomalously zero on Workspace-emitted messages despite DKIM-pass verdicts; (iii) per-Workspace-tenant third-party-sender d=<sender-domain> drift discipline — the Workspace- tenant-specific failure mode where Salesforce / HubSpot / Mailchimp emit messages with Workspace-tenant From:<workspace-tenant-domain> but the DKIM d=salesforce.com / d=hubspot.com / d=mailchimp.com tag produces alignment=false in every per-message DKIM-alignment-evaluation outcome — the Workspace spoke documents the per-Workspace-tenant third-party-sender alignment-drift diagnostic workflow operators execute to enroll third-party-senders in Workspace-tenant signed-by-domain programs that restore alignment; (iv) per-Workspace-tenant per- receiver per-source-IP per-day DKIM- aligned-pass-rate regression-monitoring via Google Postmaster Tools per- Workspace-tenant authentication- verdict-class telemetry cross-referenced against per-Workspace-tenant rua row/policy_evaluated/dkim= record-level evidence-row aggregation — the Workspace spoke documents the per-Workspace-tenant DKIM-alignment- rate regression-monitoring workflow operators execute to detect Workspace- tenant alignment-pass-rate regression BEFORE it propagates to per-receiver per-source-IP per-day disposition- outcome drift. Read the Workspace deployment spoke ALONGSIDE this DKIM- alignment-with-DMARC reference when executing DKIM-alignment on Workspace tenants — the spoke is the canonical Workspace-tenant-specific alignment- evaluation-deployment reference whose per-Workspace-tenant CNAME-publication + third-party-signed-by-domain + per- Postmaster-Tools regression-monitoring steps are the LOAD-BEARING Workspace- tenant execution discipline every Workspace-tenant DKIM-alignment-driven decision depends on.
• DMARC for Microsoft 365 — the M365-TENANT-SPECIFIC DKIM-ALIGNMENT-EVALUATION-DEPLOYMENT- WORKFLOW companion to this DKIM- alignment-with-DMARC reference. Where THIS page documents the provider- agnostic per-message DKIM d=-tag vs From:<domain>-header alignment-evaluation algorithm, the M365 deployment spoke is the M365-TENANT-SPECIFIC alignment- evaluation execution guide at FOUR per-M365-tenant-to-DKIM-alignment coupling dimensions: (i) per- M365-tenant selector1._domainkey.<domain> + selector2._domainkey.<domain> CNAME-pair publication discipline that delegates the canonical Exchange- Online DKIM signing-key pair to Microsoft-managed selector1-<domain>-com._domainkey.<tenant>.onmicrosoft.com infrastructure while preserving the M365-tenant d=<m365-tenant-domain> attribution required for alignment — the M365 spoke documents the M365- tenant-specific dual-selector CNAME publication step + Microsoft 365 Defender portal DKIM-enablement toggle that PRODUCES the per-message d=<m365-tenant-domain> tag THIS page's alignment-evaluation algorithm consumes as the load- bearing input; (ii) per-M365- tenant default-tenant-domain d=-tag attribution failure-mode — the M365- tenant-specific failure mode where Exchange-Online-signed messages carry d=<tenant>.onmicrosoft.com instead of d=<m365-tenant-domain> when the dual-selector CNAME publication + Defender portal enablement steps are incomplete — the M365 spoke documents the M365-tenant-specific DKIM-misalignment failure-mode operators diagnose when DKIM-aligned-pass-rate is anomalously zero on Exchange-Online- emitted messages despite DKIM-pass verdicts; (iii) per-M365- tenant third-party-sender d=<sender-domain> drift discipline — the M365-tenant- specific failure mode where Salesforce / HubSpot / Mailchimp emit messages with M365-tenant From:<m365-tenant-domain> but the DKIM d=salesforce.com / d=hubspot.com / d=mailchimp.com tag produces alignment=false in every per-message DKIM-alignment-evaluation outcome — the M365 spoke documents the per-M365-tenant third- party-sender alignment-drift diagnostic workflow operators execute to enroll third-party-senders in M365-tenant signed-by-domain programs that restore alignment; (iv) per-M365-tenant per-receiver per-source-IP per-day DKIM-aligned- pass-rate regression-monitoring via Microsoft Defender for Office 365 Threat Explorer per-M365-tenant authentication-verdict-class telemetry cross-referenced against per-M365- tenant rua row/policy_evaluated/dkim= record-level evidence-row aggregation — the M365 spoke documents the per- M365-tenant DKIM-alignment-rate regression-monitoring workflow operators execute to detect M365- tenant alignment-pass-rate regression BEFORE it propagates to per-receiver per-source-IP per-day disposition- outcome drift. Read the M365 deployment spoke ALONGSIDE this DKIM-alignment- with-DMARC reference when executing DKIM-alignment on M365 tenants — the spoke is the canonical M365-tenant- specific alignment-evaluation- deployment reference whose per-M365- tenant dual-selector-CNAME-publication + Defender-portal-DKIM-enablement + third-party-signed-by-domain + Threat-Explorer regression-monitoring steps are the LOAD-BEARING M365- tenant execution discipline every M365-tenant DKIM-alignment-driven decision depends on.
• DMARC reporting pipeline (RUA / RUF ingestion, parsing, delivery) — the canonical downstream-consumer reference documenting how the per- message DKIM d=-tag vs RFC 5322.From-header organisational- domain alignment-evaluation THIS page architectures (the RFC 7489 §3.1.1 DKIM-authenticated-identifier-matches- From: rule + RFC 7489 §3.2 Public-Suffix-List relaxed-mode organisational-domain comparison + adkim=s strict-mode FQDN- equality requirement) directly populates the per-row row/policy_evaluated/dkim= attribute value (pass / fail) of every RFC 7489 §7.2 aggregate-report record the receiver emits per its 24-hour / hourly-rolling-window cadence. The five-stage pipeline that materialises this verdict: (1) per-receiver aggregate-XML generation (Gmail / Microsoft 365 / Yahoo / Mail.ru) where the per-message DKIM-aligned-pass / fail outcome of every signing-identity- vs-From:-organisational-domain comparison becomes one policy_evaluated.dkim=pass or policy_evaluated.dkim=fail attribute value, (2) per-publisher rua= mailbox addressing, (3) IMAP / Microsoft-Graph ingestion at imap_fetch.php / ImapFetcher / GraphFetcher, (4) DmarcParser XML-to-row decomposition minting dmarc_records rows that preserve the per-message DKIM-aligned-pass verdict the alignment-evaluation algorithm THIS page documents produced, and (5) dashboard delivery surfacing the per-source-IP per-disposition evidence operators consume for the DKIM-alignment-rate trend analysis every per-pct=-ramp-advancement decision structurally depends on. Read the reporting-pipeline spoke ALONGSIDE this DKIM-alignment-with-DMARC reference when investigating the dkim=pass-with-aligned=false canonical defect-class (the dominant third-party-ESP DKIM-alignment-loss pattern, where the ESP signs with its own delegated d=-tag organisational domain instead of the publisher's organisational domain) — the alignment-evaluation algorithm THIS page documents is what produces the per-row evidence, the reporting- pipeline spoke documents the end-to-end infrastructure operators consume to detect and triage the defect at scale.
• Phishing protection — the canonical outcomes-layer anti-phishing defense framework reference documenting how the per-message DKIM d=-tag vs RFC 5322.From-header organisational- domain alignment evaluation THIS page architectures (the RFC 7489 §3.1.1 DKIM-authenticated- identifier-matches-From: rule + the adkim=s / adkim=r tag-strictness publication choice) IS the load-bearing primary cryptographic defense against the four canonical phishing-variant catalogue: (i) display-name phishing (attacker-controlled domain in the envelope, forged Friendly-From header) is defeated because the attacker cannot produce a cryptographically-valid DKIM signature whose d=-tag aligns with the impersonated Friendly-From organisational domain without possessing the publisher's private signing key, (ii) lookalike-domain phishing (typo-squatted From-domain) is defeated by the per-publisher per-domain DKIM-aligned-pass enforcement at receiver-side because no attacker-controlled lookalike domain can DKIM-sign as the publisher's organisational domain, (iii) compromised-third- party-ESP phishing is detected as the canonical dkim=pass-with- aligned=false defect-class whose AFRF / aggregate-row signature operators consume as the per-publisher early-warning signal that an included ESP account has been compromised, and (iv) ARC-validated- forwarder-phishing is bounded by the receiver-side adkim=s strict-mode publication choice that rejects ARC-rescued dkim-pass verdicts whose terminal d=-tag does not FQDN-equal the publisher's organisational domain. Read the phishing-protection spoke ALONGSIDE this DKIM-alignment- with-DMARC reference whenever the operator scopes the per-publisher per-domain anti-phishing defense coverage matrix — the DKIM-alignment algorithm THIS page documents IS the primary cryptographic defense layer the phishing-protection outcomes-framework coordinates as the load-bearing per-message authentication primitive every cross- protocol defense layer (DMARC-enforced-From-header authentication + BIMI brand- indicator visual-trust + ARC chain validation + MTA-STS transport-layer-anchored rejection-of-plaintext- downgrade-interception) structurally bottoms out on.
• DMARC for shared hosting — the PER-TENANT-PROVIDER-MANAGED- SHARED-HOSTING-DEPLOYMENT-COMPANION whose four shared-hosting-DKIM- alignment-execution-constraint dimensions determine whether the DKIM-alignment evaluation discipline this page documents can EVER produce an aligned-DKIM verdict for a per-tenant shared-hosting outbound stream: (i) provider-managed default-signer d=-tag pointing to the hosting provider's organisational domain rather than the tenant's RFC 5322 From-domain is the canonical shared-hosting DKIM-alignment-defeat mode — Plesk's auto-configured Postfix outbound signs every tenant's mail with the provider's d=plesk-provider.example selector, producing dkim=pass but NOT aligned (the d=-tag-vs-From:- domain FQDN-equality this page documents as the strict-alignment contract structurally fails for 100% of per-tenant traffic until the operator publishes a per-tenant selector); (ii) per-tenant DKIM authoring affordance variance across the five non-cPanel control panels gates per-tenant signer publication discipline — DirectAdmin exposes a per-domain DKIM toggle, ISPConfig requires Resellers/Email-Domain-level DKIM-Settings drilling, Webmin / Virtualmin requires the DKIM feature flag at the Virtualmin configuration level, CentOS Web Panel requires manual key generation via SSH, and generic no-panel shared hosting requires operator-managed OpenDKIM configuration — each control- panel UI variance bounds the per-tenant DKIM-alignment- compliant signer publication cadence; (iii) tenant- isolation failure where the shared signer's selector serves multiple tenants violates the per-publisher cryptographic identity contract — the DKIM-alignment-with-DMARC contract this page documents assumes a per-publisher per- selector keypair, but provider- managed shared signers in the five-panel topology routinely share one selector across all tenants on a single shared outbound IP, producing cross-tenant DKIM-signature attribution ambiguity that weakens the per-publisher verifiable-attribution guarantee the alignment evaluation depends on; (iv) per- account escalation path to operator-authored per-tenant selectors is the structurally- required remediation — the shared-hosting spoke documents the per-panel operator-discipline required to migrate from provider- managed shared signer to operator-authored per-tenant selector with publisher-side d=-tag FQDN-equal to the tenant's RFC 5322 From-domain, which is the deployment-execution prerequisite for the DKIM- alignment evaluation this page documents to ever produce a passing aligned-DKIM leg for the per-tenant traffic. Read the shared-hosting spoke ALONGSIDE this DKIM-alignment-with-DMARC reference whenever the operator scopes a per-tenant DMARC deployment on Plesk / DirectAdmin / ISPConfig / Webmin-Virtualmin / CWP — the alignment-evaluation algorithm THIS page documents IS the load-bearing per-message DMARC-pass contract whose per- tenant satisfaction the shared- hosting deployment guide encodes the per-provider execution discipline for.
• BIMI explained — the PER-MESSAGE-DKIM-d-TAG-VS-RFC- 5322-FROM-ALIGNMENT-PASS-AS-LOAD- BEARING-PER-PUBLISHER-PER-DOMAIN- BIMI-LOGO-DISPLAY-ELIGIBILITY- PRECONDITION companion documenting the BIMI logo-publication mechanism whose per-publisher per-domain logo-display eligibility at every Gmail / Yahoo / Apple Mail / Fastmail BIMI-consuming receiver is GATED on per-publisher per- domain DMARC enforcement at p=quarantine or p=reject per BIMI draft §5 — which STRUCTURALLY DEPENDS on the per-publisher per-message DKIM- alignment evaluation discipline THIS page documents across four per-DKIM- alignment-verdict-to-per-publisher- per-domain-BIMI-eligibility-coupling dimensions: (i) per-message- DKIM-d-tag-vs-RFC-5322-From-org- domain-alignment-pass-as-per-publisher- per-message-DMARC-aligned-pass- precondition-of-BIMI-logo-display — BIMI logo-display eligibility at the per-publisher per-message evaluation requires per-publisher per- message DMARC-aligned-pass verdict (the EITHER-SPF-aligned-pass-OR-DKIM- aligned-pass DMARC criterion); per- publisher per-message DKIM-d-tag-vs- RFC-5322-From-org-domain-alignment evaluation THIS page documents IS the DKIM-leg-aligned-pass evidence contributing to the per-publisher per- message DMARC-aligned-pass evidence every BIMI-consuming receiver materially consumes; per-publisher per-message DKIM-alignment FAIL evidence on a per-publisher per- message without an accompanying SPF- aligned-pass-leg evidence collapses per-publisher per-message DMARC- aligned-pass verdict, collapsing per- publisher per-message BIMI logo- display at every BIMI-consuming receiver; (ii) per-publisher- per-domain-adkim=s-vs-adkim=r-strict- vs-relaxed-mode-choice-as-load-bearing- per-publisher-per-domain-BIMI- eligibility-strictness-determinant — per-publisher per-domain adkim= alignment-mode choice (adkim=s exact- org-domain match vs adkim=r organizational- domain match) THIS page documents DIRECTLY determines per-publisher per- message DKIM-alignment pass-rate floor; per-publisher per-domain adkim=s strict-mode choice combined with per-publisher per-subdomain (mail.example.com) DKIM-signing-at-the-subdomain pattern collapses per-publisher per-message DKIM-aligned-pass when From: domain is the apex (example.com), collapsing per-publisher per-message DMARC- aligned-pass, collapsing per-publisher per-message BIMI logo-display at every BIMI-consuming receiver; (iii) per-publisher-per-domain- DMARC-enforcement-mode-ramp-discipline- as-load-bearing-per-publisher-per- domain-BIMI-eligibility-prerequisite — BIMI draft §5 EXPLICITLY requires per-publisher per-domain DMARC enforcement at p=quarantine or p=reject WITH pct=100 on the per- publisher per-domain DMARC record; per-publisher per-domain DKIM- alignment-pass-rate floor THIS page documents is the load-bearing per- publisher per-domain DMARC-aligned- pass-rate baseline determinant gating whether the per-publisher per-domain DMARC enforcement ramp can advance from p=none through p=quarantine to p=reject at pct=100 — the BIMI eligibility prerequisite; (iv) per-publisher-per-domain- organizational-domain-vs-tree-walk- DKIM-d-tag-publication-discipline-as- load-bearing-per-publisher-per-domain- BIMI-record-publication-FQDN- precondition — per-publisher per-domain BIMI record publication discipline requires per-publisher per- domain default._bimi.<domain> TXT-RR publication at the per- publisher per-domain authoritative DNS zone boundary AND per-publisher per-domain Tree-Walk-via-PSL organizational-domain inheritance discipline; per-publisher per-domain DKIM-d-tag publication discipline THIS page documents (per-publisher per-selector <selector>._domainkey.<d-tag-domain> TXT-RR publication at the per- publisher per-domain d=-tag-domain) is the STRUCTURALLY-ANALOGOUS per-publisher per-domain authentication-record publication-discipline pattern every per-publisher per-domain BIMI record publication ALSO requires at the per- publisher per-domain default._bimi sub-owner-name boundary. Read THIS page when AUTHORING per-publisher per- message DKIM-d-tag-vs-RFC-5322-From- alignment publication discipline; read the BIMI-explained spoke when SCOPING per-publisher per-domain BIMI logo- publication eligibility as the LOAD- BEARING DOWNSTREAM CONSUMER of the per-publisher per-message DKIM- alignment-pass baseline THIS page documents.
• DMARC myths and misconceptions debunked — the 18-myth operator-mental-model correction catalogue covering the recurring DMARC misconceptions whose canonical refutations the per-protocol- pillar reference pages serve as. The DKIM-alignment myth class this page directly addresses is Myth 4 ("DMARC alignment and DKIM signing are the same") — the per-message DKIM d=-tag-vs-RFC5322- From-domain alignment evaluation THIS page documents is the canonical refutation source for the misconception that ANY dkim=pass verdict is automatically DMARC-aligned. Read THIS DKIM-alignment-with-DMARC pillar alongside the myths catalogue when operators raise the "we signed with the ESP's d= domain but DMARC still failed" rollout-blocker question — the d=-tag-vs-From-domain alignment-evaluation mechanic THIS page documents IS the protocol-layer refutation the myths-catalogue cites at Myth 4's resolution.
• SPF for Microsoft 365 — the PER-PUBLISHER-PER-MICROSOFT- 365-TENANT-SPF-PUBLICATION-DISCIPLINE-AS- LOAD-BEARING-PEER-PROTOCOL-LAYER-PER- OPERATOR-PER-TENANT-DMARC-ALIGNMENT- DETERMINANT companion to this DKIM- alignment-with-DMARC reference. Where THIS page documents the per-publisher per- selector DKIM d=-tag-vs- RFC5322-From-domain alignment-evaluation mechanic at the per-message DMARC alignment-evaluation boundary (relaxed-vs- strict alignment modes via adkim=r/adkim=s, per-selector DKIM d=-tag matching against RFC5322-From-domain, per- third-party-signer-domain alignment-pass evaluation), the SPF-for-Microsoft-365 spoke is the peer per-publisher per- tenant per-Microsoft-365-operator SPF publication discipline whose per-M365- tenant SPF publication discipline (canonical v=spf1 include:spf.protection.outlook.com -all SPF-record template, per-tenant supplemental third-party-ESP include- statement composition, per-tenant cumulative 10-lookup-limit budget arithmetic, per-tenant M365 admin-portal zone-editor commit cadence) is the LOAD- BEARING upstream determinant of the per- message SPF-leg DMARC-aligned-pass evaluation that pairs operationally with the per-publisher per-selector DKIM d=-tag-vs-RFC5322-From-domain alignment evaluation THIS page documents at FOUR per-DMARC-alignment coupling dimensions: (i) peer per-protocol- layer DMARC-alignment-leg parallelism between per-selector DKIM-leg-alignment and per-tenant per-operator-SPF-leg- alignment — the per- publisher per-selector DKIM d=- tag-vs-RFC5322-From-domain alignment evaluation THIS page documents at the per- message DMARC alignment-evaluation boundary pairs operationally with the per-publisher per-tenant per-M365-operator SPF envelope- MAIL-FROM-vs-RFC5322-From-domain alignment evaluation the SPF-for-Microsoft-365 spoke documents the per-tenant per- operator publication-rationale of — both are per-message DMARC-alignment-evaluation legs whose per-message alignment-leg co- composition is the load-bearing per- publisher per-domain DMARC alignment- evaluation rhythm every per-publisher per- domain DMARC-deployment programme requires; (ii) per-publisher per-M365-tenant per-operator SPF-publication-discipline as upstream determinant of per-message SPF- leg DMARC-aligned-pass emission — the per-message DMARC-aligned-pass evaluation THIS page documents at the application-layer DMARC alignment- evaluation boundary operationally depends on the per-publisher per-M365-tenant per- operator SPF publication discipline the SPF-for-Microsoft-365 spoke documents the per-tenant per-operator publication- rationale of — a per-publisher per-M365- tenant SPF-record carrying canonical include:spf.protection.outlook.com -all emits per-message spf=pass for messages originating from M365 outbound MTAs that propagates to per-message policy_evaluated.spf=pass with per-publisher per-domain SPF-leg DMARC-alignment-pass when envelope-MAIL- FROM-domain aligns with RFC5322-From- domain, while per-publisher per-M365-tenant SPF-record syntactic defects cascade per- message spf=permerror/temperror feeding per-message DMARC-alignment-fail emission; (iii) per-publisher per- M365-tenant per-operator cross-protocol- pillar DMARC-alignment-evaluation coordination — the per- publisher per-selector DKIM d=- tag alignment-evaluation THIS page documents at the application-layer alignment-evaluation boundary pairs operationally with the per-publisher per- M365-tenant SPF envelope-MAIL-FROM alignment-evaluation the SPF-for-Microsoft- 365 spoke documents the per-tenant per- operator publication-rationale of — per- publisher per-domain DMARC-aligned-pass evaluation requires per-message DKIM-leg- aligned-pass OR per-message SPF-leg- aligned-pass (per-message either-leg- aligned-pass sufficient for per-message DMARC-aligned-pass), and the per-publisher per-M365-tenant per-operator cross- protocol-pillar alignment-evaluation coordination is the load-bearing per- publisher per-tenant per-operator DMARC- alignment-evaluation rhythm; (iv) per-publisher per-M365-tenant per- operator adkim/aspf strict-vs-relaxed mode choice parallelism — the per-publisher per-domain adkim=r/adkim=s DKIM alignment-mode choice THIS page documents at the per-publisher per-domain DMARC-policy-publication boundary pairs operationally with the per-publisher per- domain aspf=r/aspf=s SPF alignment-mode choice whose per- publisher per-M365-tenant SPF publication discipline the SPF-for-Microsoft-365 spoke documents the per-tenant per-operator publication-rationale of — together the per-publisher per-domain adkim=/aspf= cross-protocol-pillar alignment-mode choice is the load-bearing per-publisher per-domain DMARC alignment-strictness publication rhythm every per-publisher per-domain DMARC-deployment programme coordinates at the per-publisher per- domain cross-protocol-pillar alignment- publication-discipline-composition boundary. Read THIS page when EVALUATING per-publisher per-selector DKIM d=-tag-vs-RFC5322-From-domain alignment; read the SPF-for-Microsoft-365 spoke when PUBLISHING per-publisher per- M365-tenant per-domain SPF infrastructure via the Microsoft 365 admin portal whose per-tenant per-operator SPF publication discipline is the LOAD-BEARING upstream determinant of the per-message SPF-leg DMARC-aligned-pass evaluation pairing operationally with the per-publisher per- selector DKIM-leg DMARC-aligned-pass evaluation THIS page documents at the per- message DMARC alignment-evaluation boundary.
• SPF for Google Workspace (Gmail) — the per-publisher per-Google-Workspace- tenant SPF publication-discipline is the per-deployment-topology Workspace sibling of the per-M365-tenant SPF publication-discipline sibling above, documenting the cross-protocol coordination at four per-Workspace-tenant per- accepted-domain SPF-publication-vs-DKIM- alignment coupling dimensions: (i) per- Workspace-tenant outbound-IP envelope-MAIL- FROM-layer authorisation is published via the SPF record's include:_spf.google.com mechanism-cascade (which itself recursively resolves to _netblocks.google.com + _netblocks2.google.com + _netblocks3.google.com 4-level sub-include cascade publishing Google infrastructure outbound-IP ranges), structurally parallel to the per-Workspace-tenant DKIM google.com-signed dual-selector google._domainkey.<workspace-tenant> TXT-RR CNAME publication producing the per- message DKIM-Signature header verification verdict THIS page documents the alignment discipline of; (ii) the per-Workspace-tenant SPF include:_spf.google.com cascade consumes ~4 DNS lookups against the RFC 7208 §4.6.4 ten-DNS-lookup budget — when cumulative per-tenant include-cascade breaches the 10-budget (typical accelerator: SendGrid +7, Mailgun +5, Amazon SES +3 stacking against Workspace's 4-baseline), the per-receiver per- message spf=permerror verdict eliminates the SPF-leg from DMARC alignment evaluation per RFC 7489 §6.6, forcing the per- publisher per-Workspace-tenant DKIM-aligned- pass leg THIS page documents to bear the SOLE DMARC-aligned-pass-rate-floor load; (iii) per- publisher per-Workspace-tenant SPF qualifier choice (canonical ~all softfail vs strict -all publication- decision) is structurally parallel to per- publisher per-domain DMARC aspf=s strict byte-equality vs aspf=r relaxed organizational-domain match alignment- mode publication-decision per RFC 7489 §3.1.1 — both the per-Workspace-tenant SPF qualifier-publication-discipline and the per- Workspace-tenant DMARC SPF-alignment-mode- publication-discipline jointly determine the per-receiver per-message SPF-leg verdict whose pairing with the DKIM-aligned-pass leg THIS page documents produces the per-message DMARC composite verdict; (iv) per-Workspace- tenant SPF publication-discipline drift (per- tenant zone-editor commit cadence vs per- Workspace per-accepted-domain DNS publication propagation window) is the OPERATIONALLY- MOST-COMMON failure mode whose per-receiver per-day per-source-IP DMARC RUA aggregate attribution row policy_evaluated/spf= permerror emergence forces per- Workspace-tenant per-domain DMARC-aligned- pass-rate-floor preservation onto the per- publisher per-selector DKIM-Signature application-layer authentication-leg- alignment THIS page documents as the LOAD- BEARING surviving verdict path. Read THIS page for the per-message DKIM-Signature d=-tag-vs-From-domain alignment-evaluation algorithm; read the SPF-for-Workspace spoke when PUBLISHING per-publisher per-Workspace- tenant per-accepted-domain SPF infrastructure via the Google Workspace Admin Console whose per-tenant per-operator SPF publication discipline is the LOAD-BEARING upstream determinant of the per-message SPF-leg DMARC-aligned-pass evaluation pairing operationally with the per-publisher per- selector DKIM-leg DMARC-aligned-pass evaluation THIS page documents at the per- message DMARC alignment-evaluation boundary.
• BIMI Verified Mark Certificates — the per-publisher per-domain BIMI VMC as downstream consumer of DKIM-aligned- pass evaluation companion to this per- message DKIM-alignment-with-DMARC reference. Where THIS page documents the per-message per-publisher per-selector DKIM-d=-tag-vs- RFC5322-From-domain alignment evaluation that produces the per-message DKIM-aligned- pass DMARC verdict, the BIMI-VMC spoke documents the downstream consumer of that verdict — the per-message BIMI logo-display gate at Yahoo / Gmail / Apple Mail / Fastmail STRUCTURALLY DEPENDS on the per-publisher per-domain DMARC-aligned-pass enforcement baseline produced by THIS page's per-message DKIM-aligned-pass evaluation as the LOAD- BEARING upstream authentication precondition. Four DKIM-ALIGNMENT-VS-BIMI-VMC-DOWNSTREAM- CONSUMPTION cross-correlation axes the BIMI- VMC spoke documents: (i) the per- message DKIM-aligned-pass evaluation produces the per-message DKIM-leg DMARC- aligned-pass verdict that the BIMI receiver- side logo-display gate consumes — a per- message DKIM-leg DMARC-aligned-pass + p=quarantine- or-stronger enforcement baseline is the LOAD-BEARING upstream condition the BIMI VMC display gate evaluates against per RFC-WIP BIMI draft; (ii) the per-publisher per-domain DKIM-aligned-pass coverage rate THIS page documents STRUCTURALLY DETERMINES the per-publisher per-domain VMC-issuance-readiness — Mark Verifying Authorities require demonstrated per-publisher per-domain DMARC-enforcement with sustained DKIM-aligned-pass coverage BEFORE issuing a Verified Mark Certificate binding the publisher's logo SVG to the per-publisher per-domain identity; (iii) the per-publisher per-domain DKIM-aligned-pass rotation cadence interacts with the per-VMC certificate-renewal cadence — a per-DKIM-selector key-rotation cycle that produces a per-message DKIM-aligned- pass coverage cliff degrades the per- publisher per-domain DMARC-enforcement baseline AND degrades the receiver-side BIMI logo-display rate over the rotation- overlap window; (iv) the per-publisher per-domain DKIM-alignment- relaxed-vs-strict adkim mode-choice THIS page documents interacts with the per- publisher per-domain VMC-vs-CMC certificate- class choice — strict-alignment subdomains require per-subdomain DKIM-selector publication discipline AND per-subdomain VMC-or-CMC issuance discipline to display logos at receiver-side BIMI-aware mailbox providers. Read THIS page when DESIGNING per-publisher per-domain DKIM- alignment-with-DMARC discipline; read the BIMI-VMC spoke when SHIPPING the per- publisher per-domain logo-display rollout whose receiver-side display gate consumes the per-message DKIM-aligned-pass evaluation THIS page documents.
• Email Header Analyzer — paste any Authentication-Results and DKIM-Signature header to see the alignment evaluation broken down per signature.
• Domain Security Checker — validates your DMARC record (including the adkim= mode) and confirms DKIM selectors resolve.
• DMARC monitoring — the per-publisher per-domain DMARC- monitoring KPI dashboard as downstream consumer of per-message DKIM-aligned- pass evaluation companion to this DKIM- alignment-with-DMARC operator-reference. Where THIS page documents the per-message DKIM-side identifier-alignment leg of the RFC 7489 §6.6.2 OR-conjunction (the d=-tag-vs-From:- domain strict-vs-relaxed alignment evaluation), the DMARC-monitoring spoke is the OPERATOR-CONSOLE REFERENCE documenting the per-publisher per-domain KPI dashboard whose per-day per-receiver per-source-IP DMARC-disposition pass- rate / DKIM-aligned-pass coverage-rate / alignment-strictness-mode-axis pass-rate- cliff alarm telemetry the per-publisher per-domain operator MUST track to detect per-message DKIM-alignment-discipline regression BEFORE it propagates into per- receiver inbox-placement degradation. Four DKIM-ALIGNMENT-AS-MONITORING-KPI- UPSTREAM-INPUT cross-correlation axes the monitoring spoke documents: (i) per-publisher per-domain DKIM-aligned-pass coverage-rate as upstream determinant of monitoring-KPI sustained pass-rate baseline — the per-publisher per-domain DKIM- aligned-pass coverage-rate (the share of per-day outbound messages whose d= tag matches the RFC5322 From-domain under the published adkim= strict-or-relaxed mode) is the LOAD-BEARING upstream determinant of the monitoring-KPI sustained DMARC-pass-rate baseline; the DMARC-monitoring spoke documents the per-day per-receiver per-source-IP DKIM-aligned-pass-rate KPI panel whose baseline-vs-current pass-rate divergence is the load-bearing per-publisher per- domain DKIM-alignment-discipline regression-detection primitive; (ii) per-publisher per-domain adkim= mode-choice publication-discipline-correctness as upstream cause of monitoring-KPI pass- rate-cliff alarm — a per- publisher per-domain adkim=s-to-adkim=r downgrade (or vice versa) publication- discipline regression emits per-day per- receiver per-source-IP DMARC-pass-rate cliffs the monitoring-KPI dashboard surfaces as the operator-side discipline- regression alarm; the DMARC-monitoring spoke documents the adkim=- mode-change-vs-pass-rate-cliff attribution rule the per-publisher per- domain operator applies to distinguish publication-discipline regression from per-day per-receiver per-source-IP legitimate-traffic-pattern shift; (iii) per-message DKIM-leg DMARC- aligned-pass cross-protocol-pillar co- ingestion as complete authentication- monitoring posture — the per- publisher per-domain operator-side complete authentication-monitoring posture requires per-day per-receiver per-source-IP DKIM-aligned-pass + SPF- aligned-pass + DMARC-disposition co- ingestion at the monitoring-KPI dashboard; the DMARC-monitoring spoke documents the per-message DKIM-leg DMARC-aligned-pass cross-protocol-pillar co-ingestion discipline that lets the per-publisher per-domain operator distinguish per-message DKIM-aligned- pass coverage-rate degradation from per-message SPF-aligned-pass coverage- rate degradation as the structural root cause of per-day per-receiver per- source-IP DMARC-pass-rate decline; (iv) per-publisher per-domain p=reject deployment- readiness as function of per-message DKIM-aligned-pass coverage-rate baseline stability — the per- publisher per-domain ramp-advancement from p=quarantine to p=reject structurally depends on per-day per-receiver per- source-IP DKIM-aligned-pass coverage- rate baseline stability; the DMARC- monitoring spoke documents the coverage-rate-baseline-vs-ramp- advancement readiness gate the per- publisher per-domain operator applies BEFORE advancing the per-domain DMARC policy-mode against the per-message DKIM-alignment-discipline regression budget. Pair this page (the DKIM-side identifier-alignment evaluation reference) with the DMARC-monitoring spoke (the operator-side per-publisher per-domain KPI dashboard reference) when designing the per-publisher per- domain DMARC-alignment-evaluation-to- monitoring-KPI feedback loop — the spoke documents the per-day per- receiver per-source-IP DKIM-aligned- pass-rate KPI panel whose telemetry is the operationally-grounded discipline- regression-detection stream every per- publisher per-domain DKIM-alignment evaluation discipline STRUCTURALLY FEEDS as the upstream per-message per- signature alignment-leg verdict.
• Email authentication glossary — the cluster-wide canonical entity-first DefinedTermSet vocabulary reference whose per-term DefinedTerm JSON-LD entries (DKIM d=-tag, DKIM AUID, DKIM i=-tag, identifier alignment, strict-vs-relaxed alignment-mode, adkim=s vs adkim=r, organizational domain, Public Suffix List, RFC 5322 From: identifier, RFC 6376 §3.5 DKIM-Signature header byte-grammar) are the per-protocol-concept vocabulary substrate the per-message DKIM-aligned- pass evaluation algorithm THIS page documents structurally consumes at the per-receiver alignment-evaluation boundary. Where THIS page documents the RFC 7489 §3.1.1 + §6.6.2 DKIM-side identifier- alignment evaluation algorithm (the per- message DKIM d=-tag-vs- From-domain match-rule, the adkim=s strict-FQDN evaluation vs adkim=r relaxed-via-PSL-orgdomain evaluation, the per-message policy_evaluated.dkim verdict the alignment-pass / alignment-fail decision yields), the email-authentication-glossary spoke is the DEFINED-TERM-DEFINITION reference documenting the canonical entity-first definition-lede vocabulary substrate every per-message DKIM-alignment decision structurally consumes. Four DKIM-ALIGNMENT-EVALUATION-TO- GLOSSARY-DEFINED-TERM coupling dimensions the glossary spoke documents: (i) DKIM d=-tag / AUID DefinedTerm vocabulary as per-message instantiation of the DKIM-signer-identity substrate — the DKIM d=-tag (signing-domain identifier) and AUID (Agent or User Identifier, derived from i=-tag-or-default) DefinedTerm vocabulary the glossary catalogues is the per-message signer-identity vocabulary substrate the per-message DKIM-aligned- pass evaluation algorithm THIS page documents structurally consumes at the per-message identifier-alignment decision boundary; (ii) identifier-alignment DefinedTerm vocabulary as per-message instantiation of the From-domain-vs- signing-domain match-rule substrate — the identifier-alignment DefinedTerm the glossary catalogues (the RFC 7489 §3.1 formal definition: the RFC 5322 From- domain MUST match the DKIM signing-domain either by strict-FQDN equality or by relaxed-via-PSL-orgdomain equality) is the per-message match-rule substrate the per-message DKIM-aligned-pass evaluation algorithm THIS page documents structurally instantiates at every per-message alignment decision; (iii) strict-vs-relaxed- alignment-mode DefinedTerm vocabulary as per-publisher per-domain tag-strictness publication-discipline substrate — the strict-vs-relaxed alignment-mode DefinedTerm vocabulary the glossary catalogues (the adkim=s FQDN-equality-required vs adkim=r PSL-orgdomain- equality-accepted distinction) is the per-publisher per-domain tag-strictness publication-discipline vocabulary substrate the DKIM-alignment evaluation algorithm THIS page documents structurally consumes from the per-publisher per- domain v=DMARC1; adkim=... publication; (iv) organizational-domain + Public-Suffix-List DefinedTerm vocabulary as per-FROM-domain orgdomain- resolution substrate the relaxed-mode evaluation depends on — the organizational-domain + Public-Suffix- List DefinedTerm vocabulary the glossary catalogues (the RFC 7489 §3.2 PSL-based orgdomain-resolution algorithm: walk the From-domain labels right-to-left, consult the PSL public-suffix table to find the longest registrable-prefix + public-suffix, the resulting registrable-domain is the orgdomain) is the per-From-domain orgdomain-resolution substrate the per-message adkim=r relaxed-alignment evaluation algorithm THIS page documents structurally consumes at every relaxed- mode alignment decision. Read THIS page when AUTHORING the per-publisher per- domain DKIM-aligned-pass evaluation discipline; read the email- authentication-glossary spoke when CO-AUTHORING the per-publisher per- domain canonical DefinedTermSet vocabulary substrate every per-message DKIM-alignment decision the algorithm THIS page documents structurally consumes.
• SPF DNS record syntax — the PEER-AUTHENTICATION-RECORD-CLASS PER-PUBLISHER-PER-DOMAIN SPF-RECORD-BYTE- GRAMMAR-AS-LOAD-BEARING-PRECONDITION-FOR- PER-MESSAGE-SPF-ALIGNED-PASS-CASCADE-INTO- DMARC-VERDICT companion to THIS page's per- message DKIM-alignment evaluation algorithm. Where THIS page documents the per-message DKIM-alignment evaluation algorithm (the per-publisher per-domain adkim=s strict-alignment vs adkim=r relaxed-alignment evaluation, the per-receiver-side per- message d=-tag-vs-From-header- Organizational-Domain matching, and the RFC 7489 §3.1.1 alignment-verdict cascade into the per-message DMARC verdict), the SPF-DNS-syntax spoke is the PEER- AUTHENTICATION-RECORD-CLASS byte-grammar reference documenting the per-publisher per-domain SPF-record TXT-RR syntactic publication discipline whose byte-level compliance is the load-bearing PRECONDITION for the per-message spf=pass- AND-aligned cascade into the DMARC verdict THIS page's DKIM-alignment evaluation participates in. The two spokes together form the PER-AUTHENTICATION-RECORD-CLASS publication-discipline catalogue: a per- publisher per-domain DMARC-aligned-pass verdict requires AT LEAST ONE of SPF- aligned-pass OR DKIM-aligned-pass at the per-receiver per-message alignment evaluation boundary (RFC 7489 §4); a per- publisher per-domain syntactically- malformed SPF record breaks the SPF-side aligned-pass cascade by producing a receiver-side spf=permerror verdict, leaving the per-publisher per- domain DKIM-aligned-pass path THIS page documents as the SOLE per-message DMARC- aligned-pass cascade. Read THIS page when AUTHORING the per-publisher per-domain DKIM-alignment evaluation discipline; read the SPF-DNS-syntax spoke when AUTHORING the per-publisher per-domain peer- authentication-record-class SPF-record byte-grammar publication discipline whose syntactic-correctness floor sustains the SPF-side aligned-pass cascade as the independent per-message DMARC-aligned- pass path complementing THIS page's DKIM- side cascade.
• DMARC for cPanel-hosted domains
• MTA-STS for Google Workspace
• SPF (Sender Policy Framework) primer
• DANE for SMTP (RFC 7672) explained — the PER-PUBLISHER-PER-DOMAIN-DKIM- APPLICATION-LAYER-AUTHENTICATION-LEG- ALIGNMENT-AS-STRUCTURALLY-PARALLEL- APPLICATION-LAYER-AUTHENTICATION-LEG- COMPANION-TO-DANE-TRANSPORT-LAYER-TLS- CERTIFICATE-AUTHORIZATION-LEG companion to this DKIM-alignment-with-DMARC reference. Where THIS page documents the per-publisher per-domain DKIM-Signature d=-tag vs RFC 5322 From-header organisational- domain alignment evaluation per RFC 7489 §3.1.1 (relaxed = organisational-domain match per Public-Suffix-List walk; strict = exact-domain match) at the per-publisher per-domain application-layer authentication- leg-alignment publication-discipline level, the DANE-explained spoke is the STRUCTURALLY-PARALLEL transport-layer-TLS- certificate-authorization-leg companion whose per-publisher per-MX-host TLSA-RR publication-discipline is the transport- layer cryptographic-authorization-leg running orthogonally to the per-publisher per-domain DKIM-Signature application- layer cryptographic-authentication-leg- alignment at FOUR per-publisher per-domain DKIM-alignment-vs-DANE-transport-layer coupling dimensions: (i) per- publisher per-domain DKIM application-layer authentication-leg-alignment vs per- publisher per-MX-host DANE transport-layer TLSA-RR-based TLS-cert-authorization-leg protocol-layer parallel — per-publisher per-domain DKIM-Signature d=-tag alignment per RFC 7489 §3.1.1 IS the application-layer authentication-leg evaluating per-message cryptographic-signing-domain alignment with the visible RFC 5322 From-header; per-publisher per-MX-host DANE TLSA-RR publication per RFC 7672 §3 IS the transport-layer authorization-leg evaluating per-MTA-connection TLS- certificate authorization at the receiver- side STARTTLS-cert-validation execution boundary — both per-publisher per- domain cryptographic-authorization-leg primitives publish independently and cascade jointly into per-publisher per- domain composite anti-spoofing-and-anti- downgrade defense-portfolio coordination; (ii) per-publisher per-domain DKIM-alignment-mode adkim=r/s publication-decision vs per-publisher per-MX-host DANE certificate-usage (DANE-EE=3, DANE-TA=2, PKIX-EE=1, PKIX-TA=0) publication-decision — both are per-publisher per-domain operator-side cryptographic-strictness publication- decisions at the per-publisher per-domain composite application-layer-and-transport- layer authentication-discipline coordination boundary; per-publisher per-domain DKIM adkim=s strict byte-equality publication-decision IS structurally parallel to per-publisher per-MX-host DANE DANE-EE=3 end-entity-pin publication-decision — both close per-attacker per-target-domain CA-mis- issuance-or-substitution attack-window at the per-publisher per-domain composite cryptographic-strictness publication- discipline coordination boundary; (iii) per-publisher per-domain DKIM- Signature DNS-TXT-RR publication at <selector>._domainkey.<d> vs per-publisher per-MX-host DANE TLSA-RR publication at _25._tcp.<mx-host> publication-discipline parallel — both are per-publisher per-domain DNSSEC-validatable RR publication-discipline primitives whose joint per-publisher per- domain publication-portfolio coordination underpins the per-publisher per-domain composite cryptographic-authentication-and- authorization publication-discipline floor; (iv) per-publisher per-domain DKIM-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 converge in 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 DKIM-alignment-with-DMARC 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 DKIM- application-layer-alignment-and-DANE- transport-layer-authorization coordination boundary.
• MTA-STS vs DANE for SMTP — DKIM alignment proves the message identity at the application layer; MTA-STS and DANE are the two competing transport-layer disciplines that protect the SMTP hop carrying that signed message from STARTTLS-stripping and MX-substitution downgrade. This head-to-head reference walks the HTTPS-PKI-anchored (MTA-STS) versus DNSSEC-anchored (DANE) decision so you can pick the transport-security leg that complements the DKIM-aligned authentication this page documents.
• CAA records explained — DKIM alignment is published in your DNS zone; so is the CAA record that constrains which certificate authority may issue the TLS certificate the MTA-STS or DANE transport leg relies on. Read the CAA primer to see how this same-zone issuance-authorization control complements the message-layer DKIM alignment this page documents.
• Microsoft SNDS + JMRP monitoring — a valid DKIM signature does not outrank a bad IP reputation at Outlook.com: SNDS shows how Microsoft's consumer network actually graded each sending IP (GREEN/YELLOW/RED) and JMRP surfaces the Junk clicks behind a degraded verdict.

Check DKIM alignment in your reports

DMARC Analyzer parses every <auth_results><dkim> block in every uploaded aggregate report and surfaces the per-signature d= versus From: alignment in the dashboard. The Email Header Analyzer at header_analyzer.php accepts raw message headers and produces a parsed view of every DKIM-Signature instance including the alignment decision against the From: header. The Domain Security Checker validates your DMARC record's adkim= mode and confirms your DKIM selectors resolve to valid public-key TXT records.

Sign up — Free plan Inspect DKIM alignment