Alignment uses the signing domain, not the selector
A DKIM signature includes a signing domain in `d=` and a selector in `s=`. The selector helps the receiver locate the public key in DNS. DMARC alignment compares the `d=` domain of a valid signature with the visible From domain. A selector named `google`, `s1`, or `marketing` says nothing about alignment by itself.
Open the delivered headers and find every DKIM signature. Then read Authentication-Results to see which signatures passed. An ESP admin screen that says DKIM is configured cannot prove that the final message was signed, survived modification, or used the domain you expected.
Relaxed and strict DKIM alignment
Under relaxed alignment, the organizational domain of the valid `d=` value must match the organizational domain of the visible From address. A signature from `mail.example.com` can therefore align with `example.com`. Strict alignment requires the domains to match exactly. DMARC uses relaxed DKIM alignment by default unless `adkim=s` is published.
Relaxed mode works well for most organizations that separate mail streams with subdomains. Strict mode can reduce the accepted identity surface, but it demands a precise inventory. Test every CRM, support desk, billing system, and transactional provider before tightening it.
Multiple signatures and third-party platforms
A message can carry more than one DKIM signature. Your ESP may sign with its own domain while also applying a branded signature. Security gateways and list software may add another. DMARC needs one valid aligned signature; an additional unaligned signature does not cancel the aligned one.
When a third-party platform signs only with its own domain, enable custom DKIM for your domain and publish the selector records it provides. Use a dedicated subdomain if that fits your identity model, but remember the organizational domain relationship. Rotate keys using new selectors rather than replacing a live key without a transition.
Why valid DKIM breaks
DKIM verification can fail when the message changes after signing. Mailing lists, gateways, disclaimers, link rewriting, or broken canonicalization can modify signed headers or body content. DNS mistakes also matter: the selector may be missing, truncated, published under the wrong host, or contain an outdated key.
Compare a direct copy with the problem path. Confirm the selector query, the `d=` domain, the signed-header list, and the body-hash result. If a gateway rewrites mail, decide whether it can preserve the existing signature or add a new aligned signature after modification.
Verify the fix in a delivered message
Publish the provider's DKIM record exactly, enable signing in the sending platform, and send through the production route. The pass condition is a valid signature whose `d=` domain aligns with the visible From address. Keep the header evidence with the placement report so the team can see what changed.
Passing aligned DKIM is necessary identity work, not an inbox guarantee. If placement remains poor, move to audience quality, reputation, sending behavior, and links. The useful outcome is that one major class of failure has been removed from the investigation.
Questions readers ask
Is a DKIM selector the same as the signing domain?
No. The selector identifies a key. The `d=` value identifies the signing domain DMARC evaluates for alignment.
Do all DKIM signatures need to align?
No. DMARC can pass when at least one valid DKIM signature aligns, even if another signature is unaligned.
Why does DKIM pass directly but fail after forwarding?
A forwarding or gateway system may modify signed content. Compare headers and body-hash results on the direct and forwarded copies.