Why does DKIM authentication sometimes fail with certain ISPs or receivers like Barracuda and Proofpoint?
Updated on 5 Oct 2026: We added message-level troubleshooting steps and clarified signature expiry, DNS key rotation and gateway authentication results.
DKIM authentication can fail at specific receivers like Barracuda and Proofpoint because those receivers often sit as security gateways in front of the final mailbox. They inspect messages and can rewrite URLs, replace attachments, inject disclaimers, re-encode MIME parts, or modify signed headers before passing a changed copy downstream. DKIM signs selected headers and the message body, so a change breaks the signature only when it changes the canonicalized signed data. Passive scanning or adding an unsigned header does not break DKIM by itself.
If Gmail and Yahoo pass DKIM but one gateway fails it repeatedly, check whether the gateway changed signed content after an earlier successful check, its DNS lookup failed, or your signer produced a signature that some receivers cannot process. The evidence needed for each cause is different.
A 95% DKIM pass rate on a large send is not a universal benchmark. It can reflect gateway content changes or intermittent DNS errors, or it can signal a signing defect. Check whether failures cluster by receiver, source, selector, message template, result type, or security gateway.
Common causes of receiver-specific DKIM failures
When DKIM fails at Barracuda, Proofpoint, or another enterprise gateway while passing at consumer mailbox providers, the cause is usually one of these specific issues.
- Body changes: URL rewriting, disclaimer insertion, attachment replacement, tracking changes, or MIME re-encoding changed the body hash.
- Header changes: A gateway modified a header that appears in the DKIM signature's signed header list.
- Transport normalization: An MTA wrapped an overlong line, changed line endings, or converted content transfer encoding after signing.
- Forwarding path: The first hop passed DKIM, then a later hop received a changed copy and reported failure. Forwarding that preserves signed content does not break DKIM by itself; SPF often fails because the connecting IP changes.
- Strict parsing: Your signer produced malformed MIME, headers, or DKIM syntax that lenient receivers accept but stricter MTAs reject.
- DNS inconsistency: A selector, key, CNAME, authoritative DNS, or caching issue caused a missing key, permerror, or temperror at some receivers.
If Barracuda or Proofpoint records DKIM as pass before rewriting, the original signature worked at the gateway edge. If the downstream mailbox reports fail, compare the copies and identify that later verification hop. Check the trusted authentication results before treating the downstream failure as proof of a sender signing problem.
Why Barracuda and Proofpoint report different DKIM results
Barracuda and Proofpoint are often not the final mailbox. They are commonly placed in front of Microsoft 365, Google Workspace, or an on-prem mailbox system. Their job is to evaluate inbound mail before the final mailbox sees it. That means the system doing the first DKIM check is not always the same system writing the DMARC aggregate report you later read.
Barracuda documents sender authentication controls that evaluate SPF, DKIM and DMARC at the gateway. Its Email Security Gateway documentation also warns that wrapping an overlong HTML line can change signed bytes. Proofpoint Essentials documents that URL Defense breaks the original signature when URL rewriting is enabled for DKIM-signed messages. The downstream DKIM result depends on whether signed content changed; local policy and trusted earlier results determine how the receiver handles the message.
A Barracuda Email Gateway Defense sender authentication settings screen.
|
|
|
|---|---|---|
Line wrapping or footer insertion | DKIM fails later | |
URL rewriting when enabled | Body hash fail | |
Mailbox | Second check | Different result |
DNS | Timeout or stale key | Intermittent error |
Common receiver-side reasons DKIM results differ
How DKIM breaks in the mail path
DKIM is sensitive by design. The sender signs a canonicalized version of selected headers and the body. The receiver retrieves the public key from DNS and recomputes the body hash and verifies the signature with that key. If the signed content no longer matches, authentication fails. Relaxed canonicalization tolerates defined whitespace and header formatting changes, but it does not tolerate rewritten URLs, inserted body content, changed MIME encoding, or other meaningful body changes.
DKIM verification at the security gateway and final mailbox after message changes.
Authentication results before and after a gateway changetext
Authentication-Results: gateway.example; dkim=pass header.d=example.com header.s=s1 Authentication-Results: mailbox.example; dkim=fail reason="body hash did not verify" header.d=example.com header.s=s1
The phrase to watch for is body hash. If it did not verify, the canonicalized body does not match bh=. This indicates changed body content or a signing defect; it does not prove that the public key was retrieved or that the cryptographic signature is valid. If the body hash matches but the signature fails, inspect signed headers, the public key, algorithm and b=. RFC 6376 defines these separate verification checks.
Read the exact DKIM result
A non-pass result does not always mean that a gateway changed the message. RFC 8601 defines the Authentication-Results values below. Use the result together with the reason text because receivers do not always describe the same failure identically.
|
|
|
|---|---|---|
fail | Body hash or signature verification failed | Compare raw copies, signed fields and signature expiry |
permerror | Permanent validation problem, such as a missing required header or unusable key | Check selector, TXT record, algorithm, and key |
temperror | Temporary DNS failure or timeout | Check authoritative DNS and retry pattern |
neutral | Signature could not be processed, including syntax problems | Inspect DKIM syntax and the receiver's detailed reason |
none | Message was not DKIM-signed | Confirm the sending stream signs mail |
policy | Signature not acceptable under the receiver's local policy | Review algorithm, key size, and local policy |
Use the receiver's reason text and the affected selector when classifying a result.
For delayed mail, compare the signature's x= expiry with the receiving time and check the t= timestamp for clock errors. Receivers can reject expired signatures or ignore future timestamps. A DKIM public key has no built-in expiry date; an expired signature is different from a removed or revoked DNS key.
Multiple signatures need separate checks
A message can carry more than one DKIM signature, and one can fail while another passes. Match each result to its header.d, header.s, and signature identifier, such as header.b when present, rather than reading the first DKIM result alone. DMARC can pass through DKIM when at least one signature validates and its d= domain meets the visible From domain's DMARC matching rules. Relaxed matching accepts the same Organizational Domain; strict matching requires the exact domain. A domain mismatch affects DMARC without making a valid DKIM signature fail.
How to prove where the failure starts
Start with evidence that separates the original message, the gateway copy, and the final mailbox copy. Save each sample as a raw .eml file when possible. Guessing from a DMARC percentage alone wastes time because the same aggregate failure can come from different mail paths.
- Check DNS: Build the lookup name using the signature's selector and signing domain, for example s1._domainkey.example.com. Follow any CNAME to the TXT key, test multiple resolver paths and confirm that the key matches the signer. A DKIM checker checks the current record; a successful lookup now does not disprove a failure at receipt time.
- Compare raw messages: For the same test send, collect the signed original and gateway or mailbox copies as raw .eml files. Compare MIME encoding, line endings, URLs, footers, attachments and each signed header. Forwarding a sample inline changes it and is unsuitable for byte comparison.
- Trust the right result: Read Authentication-Results only when it was added by a server inside the recipient's trusted boundary. A message can contain forged or stale authentication headers from earlier hops.
- Match every signature: Record each d= domain, s= selector, result, and reason. A failing vendor signature does not cancel a separate signature that passes and meets DMARC's domain matching rules.
- Segment reports: Group DMARC failures by reporting receiver, source IP and DKIM result, using the selector where reported. Use sending logs to map the cluster to a message stream or template. A domain health check helps rule out SPF and DMARC record issues while you inspect DKIM.
- Retest simply: Send a plain-text message with no links, no footer, and one DKIM signature that meets DMARC's domain matching rules. Then add the normal template and gateway transformations back one at a time.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
If the plain-text test passes but the normal template fails, the likely trigger is a body modification, transport normalization, or brittle signature. If both fail only at one gateway, check protocol edge cases: unusual header folding, duplicate headers, malformed MIME boundaries, multiple signatures, selector DNS problems, unsupported algorithms, or a DNS response that fails over one resolver path.
For a broader step-by-step path, the DKIM troubleshooting guide gives a practical checklist for selectors, headers, and message samples.
How to find the messages behind a DMARC failure
DMARC aggregate reports (RUA), defined in RFC 9990, group results by source IP and authentication identifiers. They do not include individual Message-ID values, subjects or message bodies. The reporting organization is not necessarily the recipient domain, and the source IP can be a gateway or forwarder.
Check auth_results/dkim for signature verification results and policy_evaluated/dkim for the DMARC DKIM outcome. A signature can pass verification while failing DMARC domain matching. Selectors and detailed failure reasons are not present in every report.
- Record the reporting period in UTC, source IP, message count, signing domain and available selector for the failure cluster.
- Search sending logs for that interval and signing configuration to identify candidate messages and their Message-ID values. Aggregate counts alone cannot identify an exact message.
- Ask the receiving administrator to correlate those IDs with gateway logs and mailbox message trace, then export raw .eml copies and the authentication results recorded before and after transformation.
- If historical copies are unavailable, run a controlled test through the same route and record its UTC timestamp and Message-ID.
DMARC failure reports (RUF), defined in RFC 9991, provide message-level evidence when a receiver sends them. They are optional and subject to privacy restrictions, so adding ruf= does not guarantee a report or recover old failures.
Gateway changes versus sender mistakes
The fastest way to avoid chasing the wrong fix is to classify the failure. Gateway changes and sender mistakes produce different patterns.
Gateway-driven failure
- Pattern: DKIM passes at direct receivers but fails behind a known security gateway.
- Clue: Raw copies show URL rewriting, a disclaimer, MIME re-encoding, attachment replacement, or a second authentication result.
- Fix: Work with the receiving admin on gateway trust, narrowly scoped rewrite exceptions, ARC handling, or policy overrides.
Sender-driven failure
- Pattern: Failures cluster around one selector, result type, message stream, or template.
- Clue: Different receivers report the same selector, key, syntax, or body-hash issue.
- Fix: Correct signing order, rotate the key safely, use supported cryptography, or fix canonicalization and MIME generation.
A repeated failure at the same MTA is not proof that the MTA is broken. It narrows the investigation to that mail path, including transformations, DNS access and signer interoperability. Reproduce the failure with full raw messages, then inspect whether the gateway changed signed bytes or the sender produced input that only some receivers reject.
ARC (Authenticated Received Chain) carries cryptographically sealed earlier authentication results. It does not repair the original DKIM signature or automatically make DMARC pass. A receiver must verify the chain and trust the sealer before using earlier results for a policy override. Copying an Authentication-Results header without establishing a trusted path is insufficient.
What to fix first
Remove sender-side uncertainty first. Once the sender is clean, any remaining failures are easier to discuss with the receiving domain or their gateway vendor.
- Sign the final message: Apply tracking, disclaimers, MIME encoding and line wrapping before DKIM signing. Keep generated lines within the message-format limit of 998 characters, excluding CRLF, to avoid receiver rewrapping.
- Use current cryptography: Sign with rsa-sha256 and prefer a 2048-bit RSA key. RFC 8301 requires RSA keys of at least 1024 bits and recommends at least 2048 bits. rsa-sha1 is prohibited for signing and verification.
- Use relaxed mode: Use relaxed/relaxed canonicalization unless you have a tested reason for a stricter setting.
- Sign stable headers: Sign From as required and include stable identity and content headers. Add signing after sender-side header changes; do not omit important signed headers just to accommodate a gateway rewrite.
- Avoid partial body signing: Omit the l= body-length tag so appended content cannot sit outside the signed body.
- Keep DNS reliable: Publish one valid TXT key record per selector, verify authoritative nameservers, and keep the old key available until messages signed with it have cleared the mail path. A long key split into quoted strings within one TXT record is valid; multiple separate key records for the same selector are not. Use a new selector for key rotation instead of abruptly replacing the active key.
- Separate streams: Use different selectors for distinct sending streams so failures are easier to isolate.
Illustrative DKIM signature settings, not a publishable recordtext
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1; h=from:to:subject:date:mime-version:content-type; bh=...; b=...
Do not weaken your DMARC policy just because one gateway reports DKIM failures. First confirm whether SPF passes and its authenticated domain meets the visible From domain's matching rules. DMARC passes when at least one authentication path both passes and meets those rules. An SPF pass for an unrelated domain does not rescue DMARC, and one failed DKIM signature does not cancel another qualifying signature that passes.
If your failures mention bh= or show Proofpoint in the path, the body hash failure guide explains what that specific error means and how to prove whether content changed.
Find DKIM failure clusters with Suped
Suped's DMARC reporting product helps find whether DKIM failures cluster by reporting receiver, sending source, IP and result across days of reports. Compare selectors when the receiver includes them, and use sending logs to identify the affected message stream. Raw-message review is still needed to prove which signed bytes changed.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For this issue, Suped's practical workflow is to filter DMARC data for the reporting receiver, compare DKIM results by available selector and source, check whether SPF still meets DMARC's requirements, and investigate alerts for a new failure cluster. Correlate that cluster with sending logs and raw message samples to decide whether to fix the sender or contact the receiving administrator.
Suped's DMARC monitoring workflow groups authentication data and highlights changes that need investigation.
What a 95 percent DKIM pass rate means
A 95% DKIM pass rate deserves investigation, but it does not identify the cause by itself. A B2B list can contain more forwarding paths and secure gateways than a consumer-heavy list, yet a repeatable 5% failure cluster can still expose a sender, DNS, or gateway problem.
There is no universal acceptable DKIM pass rate. Confirm whether the percentage measures signature verification or DKIM's DMARC outcome, which also requires domain matching. Prioritize failures affecting legitimate mail by message count, business impact and persistence, even when the overall pass rate is high.
Use the percentage to spot a change, then investigate its shape. Five percent spread across unrelated forwarding paths calls for different action than five percent on one business-critical stream. If the same receiver family fails every time, escalate with raw messages and timestamps. If the same selector fails across receivers, fix the sender or DNS.
When to contact the receiving administrator
Prove where the first failure appears before changing sender or receiver policy.
Start with selector and DNS validation, compare raw messages, classify the exact DKIM result, check every signature, and retest with a minimal message. If the original message is clean, work with the receiving admin on gateway trust, narrowly scoped rewrite exceptions, ARC handling, or policy treatment. If the sender is inconsistent, fix signing order, canonicalization, cryptography, DNS, or MIME generation before escalating. When escalating, include UTC timestamps, Message-ID values, the affected signing domain and selector, raw message copies and the exact verification reasons.
Frequently asked questions
No. It can mean the gateway changed signed content, a downstream mailbox checked a changed copy, DNS temporarily failed, or your signer has an interoperability issue. Check the exact result and reason before changing DNS.
Yes. If the gateway verifies DKIM first, then rewrites URLs, inserts body content, replaces an attachment, or changes signed headers, a later DKIM check can fail on the modified message.
A fail normally means the body hash or cryptographic signature did not verify. A temperror means verification could not finish because of a temporary problem, usually a DNS timeout or lookup failure.
No. DMARC passes when at least one DKIM signature validates and meets the visible From domain's matching rules, or when SPF passes and its authenticated domain meets those rules. An unrelated signing domain can pass DKIM without satisfying DMARC.
There is no universal acceptable rate. Treat 95% as a reason to segment failures by receiver, selector, result type, source, and message stream. A concentrated failure cluster matters more than the aggregate percentage.
Do not change policy first. Confirm whether another authentication path passes and meets DMARC's domain matching rules, inspect raw messages, and prove whether the failure comes from sender configuration, DNS, or gateway-side modification.
