A valid signature can be for the wrong relationship: check which domain signed
A marketing service might send a message showing news@example.com in From while signing with d=mailer.vendor.example. The vendor’s signature can verify correctly. DKIM passes because the public key validates the selected headers and body hash for the signing domain. Yet that domain is unrelated to example.com.
The useful reframe is that DKIM proves a cryptographic association with the signer, not an automatic identity match with the visible author. RFC 6376 says DKIM associates a signing domain with a message and separates the signer from the purported author. RFC 6376 DMARC adds the comparison with the domain in the From field. RFC 9989
Thus dkim=pass and dmarc=fail can both describe the same message accurately. Do not rotate the key or edit DMARC policy until you have written down the signing domain that passed, the visible From domain and the route that created the message.
This is the classic ‘authentication passes but something is still wrong’ puzzle. The signature is genuinely valid: it just proves the supplier’s domain, not yours. Once you see DMARC as an alignment comparison rather than another pass badge, the path forward becomes clear. The alignment guide gives the full version of that comparison.
Capture the receiver’s result and the actual signature
Send a non-sensitive control through the affected application to a mailbox you manage, or open a delivered example from the incident. Obtain the raw original. Find the trusted receiver’s Authentication-Results and copy the DKIM result, header.d signing domain, selector if shown, and DMARC result with header.from.
RFC 8601 defines how authentication results are represented and includes an authentication service identifier that helps locate their administrative boundary. RFC 8601 Do not accept a lower, sender-supplied field as proof. Identify the result added by the receiving system you trust.
Also find the matching DKIM-Signature field and copy its d= and s= tags. A message can carry multiple signatures, so match each result to the correct signer. Record the application feature, UTC time, message ID and recipient service.
Keep the full header private. It may expose addresses, internal routing, provider IDs and tracking information. Share only a stable redacted extract. If no trusted result or provider event is available, stop and ask an authorised mail administrator to collect evidence.
Compare the signing domain and From domain exactly, subdomain by subdomain
Write the visible From domain and every passing DKIM d= domain on separate lines. Preserve subdomains. A dashboard saying ‘DKIM enabled’ often means that some signature is valid; it may not say which domain signed the message.
DMARC DKIM alignment is relaxed by default. Under relaxed alignment, the signing domain and From domain can be different subdomains within the same organisational domain. Under strict alignment, they must match exactly. RFC 9989 defines these relationships and the adkim policy tag. DMARC DKIM alignment
If From is example.com and the passing signer is mail.example.com, relaxed alignment may work while strict alignment does not. If the signer is vendor.example, neither mode connects it to example.com. Use the actual public-suffix boundaries rather than guessing from matching words.
Check whether another signature passes and aligns. DMARC needs at least one passing aligned SPF or DKIM result. An unaligned vendor signature can remain useful for the provider’s accountability even when a separate customer-domain signature supplies DMARC alignment.
The parallel failure is covered in why SPF can pass while DMARC fails, where the authenticated envelope domain may not align with From.
Find the application and account that chose the signer
Trace the message to a specific feature: campaign, invoice, ticket reply, booking reminder, website notification or staff mailbox. Different features in one supplier can use different signing configurations. Record the service owner and the person who controls your DNS.
In the service account, look for custom DKIM, sending-domain authentication or domain verification. Compare the configured domain and selector with the receiver’s evidence. Confirm the setting belongs to the same account, region and From domain. A record copied from another tenant can publish successfully while never matching the private key used by this sender.
Query TXT at selector._domainkey.signing-domain for the observed signature. A key at that name helps explain the pass, but it does not create alignment with another domain. If the service should sign as your domain yet the message still uses its own domain, publication may be incomplete or signing may not have been enabled after verification.
Stop if nobody recognises the sender, the account cannot be matched to the event, or the passing signer belongs to an unknown party. Do not add DNS records for unexplained traffic. Escalate as a possible unauthorised route.
Choose a supported aligned identity
The usual repair is customer-domain DKIM. The provider supplies one or more account-specific selector records for your domain or an aligned subdomain. After DNS is visible, the account owner verifies the domain and enables signing. The next message should carry a signature whose d= value aligns with the visible From domain.
An aligned custom return path can provide DMARC through SPF instead, where the service supports it. This may be a valid alternative, but it does not make the passing vendor DKIM signature aligned. Prefer configuring both supported mechanisms because each has different failure modes.
DKIM can survive ordinary relaying because it is not tied to the final connecting IP, but changes to signed headers or body content can break it. SPF can survive content changes, but forwarding changes the connecting host and can break authorisation. This trade-off is a reason for layered authentication, not a reason to weaken DMARC.
Do not change the visible From address to a provider-owned domain merely to produce a pass unless the address is genuinely controlled and appropriate. Do not set a less protective DMARC policy to hide one sender’s configuration fault.
Most suppliers can sign with your domain or an aligned subdomain once you publish an account-specific selector record. The trick is choosing the mechanism the service actually supports and activating it inside the account, not only publishing DNS. When a signature is failing rather than merely unaligned, the selector troubleshooting guide has the diagnostic stages; for the SPF-side mirror of this problem, see why SPF can pass while DMARC fails.
Publish the key without displacing another sender
Take a DNS snapshot. Compare every requested selector hostname with existing TXT and CNAME records. DKIM selectors allow several senders to coexist, but a single owner name cannot normally hold both an active CNAME and unrelated data. If a selector is occupied, ask the provider for another rather than overwriting it.
Publish the exact account-specific value. Some DNS panels append the domain, so preview the final name. Query the public answer and compare it character for character with the provider’s instruction. Then return to the sending service and complete its verification and activation control.
RFC 6376 describes selectors as a way to support multiple concurrent keys and key replacement. DKIM selectors Keep the selector, account owner, creation date and rotation responsibility in your sender inventory. Do not remove an old selector until evidence shows no active route uses it.
Record the old state, new DNS value, TTL, service activation, approver and rollback condition. A published key with no matching private-key use is harmless to delivery but does not fix the message; a replaced active key can break another route immediately.
Prove alignment on the same message route
Once the service reports the custom domain active and public DNS is correct, send a plain test through the same application feature, account, From domain and recipient provider. Do not test a staff mailbox when the failing route was a finance application.
Open the new original. Confirm the expected DKIM-Signature exists, its d= domain and s= selector match the intended configuration, and the trusted receiver reports dkim=pass for that signer. Then confirm dmarc=pass and preserve the reported From domain.
Exact verification requires all three observations: signature present, expected signer passes, and that signer aligns under the active DMARC mode. A green DNS lookup proves only key availability. A provider badge proves only its internal setup state. A DKIM pass for the old vendor signer does not prove the repair.
Also test reply handling and a pre-existing route that uses another selector. If DMARC still fails, check strict alignment, a different From domain, another account, stale caches and whether an intermediary changed the message.
Verifying on the real message route: the same application, account and From domain: is what proves the repair rather than a green DNS lookup. Reading the receiver’s authentication results in the headers is the reliable way to confirm the signature actually carried the expected domain.
Stop guessing and escalate with the two domains
Send the provider the UTC event time, message ID, application feature, redacted trusted authentication results, visible From domain, passing vendor signer, expected customer signer, selector query and service verification state. Ask why that account did not sign the route with the configured domain. Request confirmation of the selector the platform selected at send time and whether a domain-verification state is scoped to the account, region or message stream. If two signatures were present, label their results independently. This prevents support from replying with evidence for the vendor signature when the unresolved question concerns the absent or failing customer-domain signature.
Stop changes if the requested selector conflicts with an unknown record, DNS ownership is unclear, several critical senders share the domain, or the provider asks for a broad record that does not match its documentation. Stop normal testing if credentials may be compromised or the only available message contains sensitive information that cannot be reproduced safely.
Keep the existing passing vendor signature unless the provider directs otherwise. Multiple signatures can coexist, and removing one is not required for DMARC when another aligned signature passes. The goal is not to make every domain in the header identical; it is to provide at least one trustworthy aligned path without breaking accountability or working mail.
The failure is resolved when the same route carries the intended signature, the receiver validates it and DMARC reports alignment. That evidence is stronger than any account badge.
Sources and further reading
- RFC 6376: DomainKeys Identified Mail
- RFC 9989: Domain-based Message Authentication, Reporting, and Conformance
- RFC 8601: Message Header Field for Indicating Message Authentication Status