How to troubleshoot DKIM implementation issues and understand ARC-Seal in email headers?
Published 20 Apr 2025
Updated 19 Oct 2026
14 min read
Summarize with
Updated on 19 Oct 2026: We clarified DKIM error diagnosis, DMARC domain matching, and ARC chain validation.
If a received email has no DKIM-Signature line, the final receiver has no DKIM signature to verify, even if a DKIM DNS record exists. The outbound system usually did not sign that route, although an intermediary can also strip the header. A DNS record only publishes the public key. The outbound mail system still has to sign the message with the matching private key before it leaves.
The d=google.com value that appears under ARC-Seal identifies the claimed ARC sealer as Google. Validate the seal before relying on that identity. ARC helps preserve authentication results across forwarding and relay hops. It does not prove that your domain is signing mail with DKIM, and it does not replace DKIM.
Compare a fresh message before and after the DKIM change using the same sending route. If DKIM-Signature is still absent from the earliest outbound copy, signing is not active for that route. If it appears there but disappears at the receiver, inspect the intermediary that removed it.
What a working DKIM implementation looks like
A working DKIM setup has two separate pieces. First, DNS contains a public key at a selector hostname such as default under _domainkey. Second, the actual mail platform signs outbound messages with a matching private key. Check both because many DKIM failures come from stopping after the DNS step.
DKIM DNS record pattern (truncated, not publishable)dns
default._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." )
That DNS record is necessary, but it is passive. Receivers do not look it up unless the message tells them which selector and signing domain to check. That instruction comes from the DKIM-Signature header added by the outbound mail server.
DKIM header pattern (truncated)text
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=default; h=from:to:subject:date; bh=abc123...; b=def456...;
- Signing domain: For DKIM to satisfy DMARC, the signature must verify and its d= domain must share the organizational domain with the visible From domain under relaxed matching, or match it exactly under strict matching.
- Selector: The s= value tells the receiver which DNS hostname contains the public key.
- Canonicalization: The optional c= value defines how headers and the body are normalized before verification. If it is absent, the default is simple/simple.
- Signed headers: The h= list identifies signed header fields. The From field must be signed, and changes to other listed fields can invalidate verification.
- Body hash: The bh= value contains the hash of the canonicalized body. The receiver compares it with its own calculation, but the signature must also verify. If an optional l= tag is present, only the specified body length is covered.
- Signature: The b= value is the cryptographic signature that receivers verify with the public key in DNS.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
Check DKIM headers before changing DNS
Start with the full source of a received message. In Gmail, open the message menu and select "Show original"; in Outlook, open the message details or internet headers. Save the raw .eml file when investigating body changes, because pasted headers do not contain the message body. DNS shows whether a public key exists. Headers show whether a signature is present.
- Header exists: Look for DKIM-Signature. If it is absent, signing is not active for that path or an intermediary removed the header. Inspect the earliest available outbound copy to distinguish the two cases.
- Domain matches: Check whether d= matches the visible From domain under the domain's DMARC mode.
- Selector resolves: Use s= plus d= to query the exact DKIM TXT or CNAME record.
- Result is clear: Read Authentication-Results added by the final receiver for pass, fail, none, policy, neutral, temperror, or permerror. Check the authserv-id before the first semicolon against the receiver's documented identifier; do not trust an arbitrary upstream result. RFC 8601 defines this trust boundary.
- Route is right: Confirm the message left through the system that owns the DKIM private key.
For a focused DNS check, use Suped's DKIM checker to verify the selector record, then test a live message. Suped's domain health checker checks published authentication records; a DNS check alone cannot establish whether a specific message passes DKIM or DMARC. Read the receiver results for that message.
DKIM checker sample results showing selector, DKIM DNS record, validation checks, parameters, and share link
Suped's product connects this check to ongoing monitoring. It groups reported authentication results by sending source so teams can identify affected senders and investigate their DKIM configuration.
Common DKIM implementation issues
When DKIM is missing after a host says it is configured, treat that as a sending configuration issue first. The public key can be correct and the message can still leave unsigned. That happens with web hosts, CRMs, billing systems, newsletters, help desks, and custom SMTP routes.
|
|
|
|---|---|---|
No DKIM-Signature header | Signing disabled or header removed | Compare the earliest outbound copy with the received message. |
dkim=pass with a different signing domain | Provider-domain signing only | Compare d= with the visible From domain using the applicable DMARC matching mode. |
No key for signature | Missing key or incorrect selector | Query selector._domainkey.signing-domain using the signature's s= and d= values, and follow any CNAME. |
Body hash did not verify | Body changed after signing | Compare footers, MIME encoding, and relay edits against the original raw message. |
Signature did not verify | Key mismatch or signed header changed | Verify the public/private key pair and compare the fields listed in h=. |
dkim=temperror | Temporary verification problem, often DNS | Check authoritative DNS, resolver timeouts, and SERVFAIL responses, then retest. |
dkim=permerror | Verification cannot complete because of an unrecoverable error | Read the detailed reason and repair the signature or key configuration; waiting alone does not fix it. |
Intermittent results | Split routing, key rotation, or cached DNS | Compare sending source and selector; check both authoritative answers and cached answers. |
Signature expired | The optional x= time has passed | Check the signing server clock and delivery delays; send a fresh test message. |
Receiver error wording varies. Use the result and its detailed reason together; RFC 8601 defines the DKIM result codes.
DNS-only setup
- Public key: The TXT record exists, but no sender has been told to use it.
- Headers: The message has no DKIM-Signature line.
- Outcome: Receivers report dkim=none or omit DKIM entirely.
Active signing setup
- Private key: The sending system has the private key and signs outbound mail.
- Headers: The message includes d= and s= values.
- Outcome: Receivers can verify the signature against the DNS key.
Query the exact selector._domainkey.example.com name and confirm that it returns one usable public key. Multiple quoted strings inside one TXT record are concatenated; they are different from separate TXT records at the same selector. DKIM permits folding whitespace in p=, so whitespace alone does not prove corruption. Check for missing key characters, literal quote marks, and an empty p= value, which revokes the key. If the provider uses a CNAME, do not publish a TXT record at the same owner name. During key rotation, keep the old public key available until messages signed with it have cleared normal delivery and retry queues. RFC 6376 defines the key syntax.
Check whether the DNS editor automatically appends your domain, so the hostname is not published as selector._domainkey.example.com.example.com. Query the authoritative nameservers and a recursive resolver to distinguish publication errors from cached answers. Cached records expire according to their TTL; cached missing-record answers also take time to expire. For provider-specific CNAME requirements, use Microsoft's DKIM configuration instructions when the sending platform is Microsoft 365.
For RSA signing, use rsa-sha256 and prefer a 2048-bit key. rsa-sha1 is prohibited, and RSA keys shorter than 1024 bits are invalid under RFC 8301. Add disclaimers and complete MIME encoding before signing. Relaxed canonicalization tolerates specified whitespace changes, but it does not protect arbitrary footer or subject edits.
If the record exists but the message has no signature, work through record exists but no signature as a separate path. If the signature exists but bh= fails, the problem is usually message modification after signing, so use a body-hash workflow for body hash failures.
Why DKIM can pass while DMARC fails
DKIM verification and DMARC domain matching are separate checks. A valid signature can use a provider's domain rather than the visible From domain. DMARC passes when at least one verified DKIM signature meets its domain-matching requirement, or SPF passes with a qualifying MAIL FROM domain. RFC 9989 defines these checks.
Passing authentication with failing DMARCtext
From: sender@example.com Authentication-Results: mx.example.net; dkim=pass header.d=example.org header.s=selector1; spf=pass smtp.mailfrom=bounce.example.org; dmarc=fail header.from=example.com
Here, neither authenticated domain matches example.com, so DMARC fails. Configure custom-domain DKIM signing for the sending service. With adkim=r (the default), mail.example.com and example.com share an organizational domain and meet relaxed matching. With adkim=s, the DKIM d= domain must match the visible From domain exactly.
A message can have multiple DKIM signatures. One verified signature with the required domain match is sufficient for the DKIM path to DMARC, even if another signature fails. Match each result to header.d and header.s. Reply-To and Sender are not the reference identities for DMARC; changing them alone does not repair its domain match.
How to read ARC-Seal without confusing it for DKIM
ARC stands for Authenticated Received Chain and is specified in RFC 8617. It is used when a message passes through an intermediary, such as a forwarder or mailing list, and the final receiver needs context about authentication results seen earlier in the route. ARC-Authentication-Results records the intermediary's checks, and ARC-Message-Signature protects the message at that hop. ARC-Seal protects the chain state.
ARC header pattern (truncated)text
ARC-Seal: i=1; a=rsa-sha256; d=google.com; s=arc-20240605; cv=none; b=abc123... ARC-Message-Signature: i=1; a=rsa-sha256; d=google.com; s=arc-20240605; bh=def456...; b=ghi789... ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.d=example.com; spf=pass smtp.mailfrom=example.com
The important detail is the header name. A verified ARC-Seal with d=google.com identifies Google as the ARC sealer. A verified DKIM-Signature with d=example.com identifies example.com as the DKIM signing domain. The visible header text alone does not verify either signature.
ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results compared with DKIM-Signature
|
|
|
|---|---|---|
d= | Sealer domain | Signer domain |
s= | Sealer key selector | DKIM key selector |
i= | ARC instance | Optional identity |
cv= | Prior chain status | Not used |
ARC fields look similar to DKIM fields, but the header name changes the meaning.
A receiver that trusts an ARC sealer can use a valid chain when forwarding breaks SPF or DKIM later in the path. Cryptographic validation and trust are separate decisions. A passing chain preserves what an intermediary reported, while the final receiver decides whether to trust that sealer and how to handle the message. Ordinary forwarding often breaks SPF because the connecting IP changes; DKIM can survive when the signed content is preserved. ARC can support a local DMARC policy override without repairing a broken DKIM signature or changing the underlying DMARC failure.
How to troubleshoot an ARC chain
One visible ARC-Seal header does not prove that the chain passes. Check complete ARC sets, then distinguish cryptographic validation from the receiver's trust decision. RFC 8617 specifies the validation sequence.
- Check complete sets: Each instance must contain one ARC-Authentication-Results, one ARC-Message-Signature, and one ARC-Seal with the same i= value.
- Check sequence: Instance values must start at i=1 and increase without gaps or duplicate instances. Each instance has three header fields, and the chain cannot exceed 50 sets.
- Read chain status: The first seal must use cv=none. Later seals use cv=pass when the prior chain validated. cv=fail means the prior chain did not validate.
- Verify signatures: Use each ARC-Seal's d= and s= values to locate its public key and validate every seal. Also validate the ARC-Message-Signature with the highest i= value using its own d= and s= values. Earlier message signatures can fail after legitimate intermediary edits without invalidating the chain.
- Read the receiver result: Look for arc=pass, arc=fail, or arc=none in the final receiver's trusted authentication results. An omitted ARC result does not prove that no ARC headers exist. Confirm the receiver's trust policy for the relevant sealing domain.
An arc=pass result does not force inbox delivery. ARC can inform a receiver's DMARC decision, but content filtering and local policy still apply. Do not add a trusted ARC sealer unless it is an intermediary the organization uses and has verified.
A practical header decision path
When only one raw header is available, use this decision path. It keeps ARC, DKIM, SPF, and DMARC separate and avoids chasing the wrong domain value.
DKIM troubleshooting flow for signature presence, selector DNS lookup, and ARC header context
Header evidence levels
Use the strongest evidence available before changing DNS or mail routing.
No DKIM header
Stop
The receiver has no signature to verify. Check whether signing was absent or the header was removed.
Header, no key
Fix DNS
Check the exact selector, CNAME target, and DNS response; distinguish a missing key from a lookup failure.
Header, fail
Trace
Read the reason: key mismatch, signed-content edits, expiry, or an unsupported algorithm.
Header, pass
Continue
Move to DMARC domain matching and reputation checks.
- Collect samples: Send test messages through every real route, including webmail, SMTP, apps, and automation.
- Compare headers: Save one before and one after the change, then compare the authentication headers.
- Check receiver view: Use the final receiver's Authentication-Results rather than assumptions from the sender.
- Map sources: Keep a list of each system sending as the domain and the DKIM selector it uses.
Suped's DMARC monitoring workflow shows which sources pass or fail DKIM and DMARC over time. It adds alerts and remediation steps so teams can verify that a DKIM fix remains effective across every sending route.
What to do when a host says DKIM is done
When a web host or mail provider says DKIM is configured, ask for evidence tied to a real sent message. The right proof is not a screenshot of DNS. The right proof is a received header showing a DKIM signature from your domain and a pass result at a mailbox outside the provider's system.
- Ask plainly: Which outbound server signs the message, and which selector does it use?
- Send externally: Test with two independent external mailbox providers and a mailbox you control, then inspect the full headers.
- Avoid assumptions: Do not treat a visible DKIM TXT record as proof that signing is active.
- Check all routes: Webmail, SMTP clients, website forms, and app mail can use different paths.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For teams with several sending services, Suped's DMARC reporting groups reported authentication results by source so teams can identify affected senders and check results after a fix. Keep message-level header evidence alongside the reports, because aggregate data does not contain the original message body.
Check DNS publication and signing ownership with the host. DKIM records live in DNS, but the private key lives wherever outbound signing runs. If the provider rotates selectors, migrates mailboxes, or changes a CNAME target, old guidance becomes stale quickly. Keep the current selector, provider, signing owner, and last verified date with the domain record. Give support the raw message, selector lookup, and receiver result. If the earliest outbound copy is unsigned, ask the provider to verify signing on that route; if the header disappears later, investigate the relay path.
Views from the trenches
Best practices
Check the actual received headers before changing DNS again or opening a support ticket.
Keep one clean test mailbox outside the sender's platform for authentication checks.
Record each sending source, selector, and signing domain so route issues are visible.
Common pitfalls
Treating a DKIM TXT record as proof of active signing causes long troubleshooting loops.
Reading ARC-Seal d values as DKIM signer domains leads teams to chase the wrong issue.
Testing only one mail route misses unsigned webmail, form mail, or app-generated messages.
Expert tips
Use the final receiver's trusted Authentication-Results to assess message authentication.
Ask the provider which signing system and selector its outbound servers use for this route.
Keep an outbound raw message and a received copy to find where signed content was changed.
Marketer view
Marketer from Email Geeks says the d value under ARC-Seal belongs to the ARC sealer, and large mailbox providers add those seals to preserve authentication context.
2019-03-21 - Email Geeks
Marketer view
Marketer from Email Geeks says a host starting to sign mail should be confirmed by comparing headers before and after the change.
2019-03-22 - Email Geeks
The reliable way to close the issue
Prove DKIM at the message level. Publish the DNS key, enable signing in the outbound system, send through the real route, and inspect the received headers. If DKIM-Signature is missing at the final receiver, inspect the earliest outbound copy. If it is absent there, fix the sender configuration. If it existed earlier and disappeared, inspect the relay path. If the signature exists and fails, move to selector, key, canonicalization, or content-change troubleshooting.
Read ARC-Seal as forwarding and receiver context. A verified d=google.com seal identifies Google as the sealer for that ARC set. It does not establish that your domain's DKIM signature is present or valid.
Frequently asked questions
No. The DNS record publishes the public key. The outbound mail server must still sign each message with the matching private key.
That value names Google as the claimed ARC sealer for that ARC set. Validate the seal before relying on that identity. It is not the DKIM signing domain for your message.
DKIM-Signature contains the signing claim. A trusted Authentication-Results header added by the receiver shows whether it verified successfully. A visible signature alone does not prove verification.
No. ARC preserves earlier authentication results but does not add DKIM signing for your domain. A receiver that trusts a valid ARC chain can use it for a local delivery-policy override while the current DKIM or DMARC check still fails.
It means the sealer could not validate the ARC chain it received. Check the instance sequence, complete ARC sets, public keys, and whether an intermediary modified the message after sealing. It does not by itself mean the message's current DKIM result failed.
Different mail routes use different signing settings. Test webmail, SMTP clients, website forms, and application mail separately.
