What causes the DKIM b= signature invalid length error in SMTP?

You sent a perfectly valid email with a correct DKIM signature—yet it failed. The receiving server says the signature is invalid. The error points to the b= tag in your DKIM header. What went wrong?

It’s not a bug in your DKIM implementation. It’s how SMTP handles long header lines. When the transport agent cuts off a DKIM signature mid-stream, the hash breaks. Even one missing character invalidates the entire signature.

The issue isn’t in DKIM—it’s in how older and some misconfigured SMTP transport agents limit header line length to 78 characters. A long DKIM signature exceeds that. When it gets truncated, the receiving server recalculates the hash. The result doesn’t match. The email is rejected.

Key takeaways

  • SMTP transport agents like Microsoft Exchange, Sendmail, and Postfix cap header line length at 78 characters by default.
  • DKIM b= signatures can exceed 78 characters, especially with larger key sizes or complex headers.
  • Truncation breaks the cryptographic hash, causing signature mismatch and delivery failure—even if the signature is otherwise correct.

Why does the SMTP transport agent truncate DKIM b= signatures?

SMTP transport agents truncate DKIM b= signatures because they enforce RFC 5322’s 78-character limit on header lines, a legacy rule designed for human-readable email text. DKIM signatures, especially with RSA-SHA256, often exceed 300 characters, forcing splits or truncation when they cross the 78-character boundary. Since transport agents don’t recognize cryptographic content as special, they apply the same line-length rules to all headers, causing validation failures. No updated standard has relaxed this limit for crypto fields.

RFC 5322’s Line Length Limit Still Applies

Even though modern emails carry large payloads and cryptographic data, the core transport layer still follows RFC 5322’s line-length restriction. This rule originated in an era when systems processed small, text-only messages. Today, transport agents — including those in Microsoft Exchange, Google Cloud, and AWS SES — enforce it without exception, treating all headers uniformly regardless of content type.

Why DKIM b= Values Are Vulnerable

The DKIM b= tag contains a base64-encoded hash of the message body and headers. With algorithms like RSA-SHA256, this value can easily surpass 300 characters. When a header line exceeds 78 characters, SMTP systems either break it into multiple lines (using soft line breaks) or discard the rest. The latter results in truncated signature data, which fails verification when the recipient’s server reassembles and recalculates the hash.

There’s no current standard that redefines the 78-character limit for cryptographic headers. While some modern systems support longer lines via folded headers, the behavior remains inconsistent across mail servers. This inconsistency means a message can pass validation on one server but fail on another, based solely on how a transport agent handles line breaks.

Let’s be clear: this issue isn’t about misconfiguration or broken code. It’s a fundamental design mismatch between old standards and current cryptographic needs. The problem persists because updates to SMTP’s foundational specs are slow, and vendors often prioritize backward compatibility over fixing edge cases in legacy formatting.

If you're dealing with DKIM failures and seeing unexpected invalid length errors, check your header line length during DKIM signing. Tools like our email checker can help verify whether a target address is technically reachable and whether your sending infrastructure is consistent with modern delivery requirements — though they won’t directly fix header formatting, they will highlight potential issues early in your workflow.

For deeper insights into mail delivery logic, refer to the original RFC 5322 and the DKIM specification (RFC 6376). The gap between them remains a silent cause of delivery problems.

How do truncated DKIM signatures affect email deliverability?

If your DKIM b= signature is truncated, email recipients may reject or quarantine your messages due to authentication failure—even if SPF and DMARC pass. This breaks trust in your domain’s identity, leading to poor inbox placement, misclassified bounces, and damage to sender reputation over time. Check your DKIM configuration and signing process to prevent this.

Authentication failure leads to rejection and quarantine

Most modern email receivers validate DKIM signatures as part of their spam and fraud defenses. A truncated b= value—common when the signature exceeds 256 characters or is improperly encoded—means the signature fails verification. This results in outright rejection or placement in quarantine, even if other checks like SPF pass.

Receivers like Gmail, Microsoft 365, and Yahoo rely heavily on DKIM to confirm message integrity. When verification fails, they treat the message as untrusted, regardless of content or reputation. This often happens silently, leaving you unaware until delivery drops.

Sender reputation and inbox placement suffer

Even if a message is delivered, recipients that perform strict authentication checks may still mark it as suspicious. This reduces inbox placement rates, especially in competitive verticals like finance or e-commerce, where high deliverability signals are expected.

Repeated DKIM failures—especially across multiple domains—significantly damage sender reputation. The reputation engine sees consistent authentication errors as a red flag, lowering trust scores over time. According to RFC 6376 (which defines DKIM), a malformed or truncated signature invalidates the entire authentication chain.

Many bouncers misclassify DKIM-related failures as "temporary" (like transient network issues) or "permanent" (like invalid addresses). But those are misdiagnoses. The real issue is the signature's length or encoding, not the email's validity. You’ll see these mislabeled bounces as "hard" when they’re not, leading to poor list hygiene.

Spam filters increasingly flag repeated DKIM verification failures as high-risk behavior. This can trigger automatic filtering or delay, especially if multiple messages from a domain fail validation in a short time. A single misconfigured transport agent can trigger this at scale.

Use our email checker to validate single addresses before sending, or integrate with our real-time verification API to catch such issues in your send stream. Prevent errors at source—don’t wait for bounces to find out your DKIM is broken.

What are the two primary causes of this DKIM truncation issue?

DKIM b= signatures get truncated during SMTP transport when mail servers enforce strict 78-character line limits and fail to apply proper line folding, or when large signatures from modern algorithms (like SHA256 with 2048-bit keys) exceed those limits by design. This breaks the DKIM verification process and leads to invalid length errors, even if the signature itself is correct.

Strict 78-character limits without line folding

Many legacy or misconfigured mail transfer agents (MTAs) still enforce an old 78-character limit on header lines without allowing line folding. The DKIM specification (RFC 6376) allows for line folding via whitespace at the end of a line, but some MTAs treat this as invalid or simply truncate. When this happens, the b= signature gets cut off mid-value—often leaving it incomplete and causing verification failure.

Even if the MTA doesn’t break the line, if the sender’s DKIM generator doesn’t fold long lines correctly, the message is still at risk. The issue isn’t always the receiver’s fault—bad sender-side implementation can cause the same problem.

Large signatures from modern cryptographic standards

Modern DKIM implementations using SHA256 and 2048-bit RSA keys produce significantly longer digest values than older methods. A SHA256 hash alone is 64 characters in base64, and when combined with a long key signature, the total b= value can easily exceed 78 characters per line. If the line isn’t folded properly, it triggers the error—regardless of correctness.

This isn’t a flaw in the design; it’s a consequence of stronger cryptography. As more organizations adopt modern standards, this issue is increasingly common in real-world email flows. According to the IETF’s SMTP guidelines (RFC 5321 section 4.5.3), all content in email headers must be properly formatted, including line folding for long fields.

If you're seeing this error in your email delivery pipeline, it’s worth checking both your MTA configuration and how your signing tool generates headers. You can also test actual delivery behavior with real inbox placement tools before sending. Test your message delivery to see how it lands across real inboxes, and verify your sender reputation with a full bulk verification run to catch invalid or problematic addresses early.

How to prevent DKIM b= signature truncation during SMTP relay?

SMTP transport agents truncate DKIM b= signatures when line length exceeds 998 characters, triggering invalid length errors. To fix it, enable MIME line folding in your outbound mail server, use DKIM formats that support CRLF continuation, ensure your MTA properly handles header continuation, avoid unnecessarily long keys, and test signatures in real-world conditions instead of relying on theory alone.

Configure your mail server for proper line folding

  • Enable MIME line folding in your outbound mail server (e.g., Postfix, Exim, or cloud MTA) to break long lines at 998 characters using CRLF followed by whitespace.
  • Ensure your MTA or email service provider applies correct line continuation rules for header fields like DKIM-Signature, especially within the b= value.
  • Check configuration files for settings like smtpd_mime_header_len or equivalent—this limit must accommodate the full DKIM signature with folding.

Optimize DKIM signature generation and testing

  • Use SHA256 with 1024-bit keys—this key length is sufficient for most use cases and reduces signature size without sacrificing security.
  • Choose DKIM signing methods that support base64 folding via CRLF and whitespace on continuation lines; this is mandated by RFC 6376 for header field length compliance.
  • Test DKIM signatures in real-time using tools that simulate actual delivery pipelines—static checks won’t catch relay-level truncation.
  • Verify your domain’s DKIM alignment and signature validity under real conditions with inbox placement testing or real-time address verification.

Even minor misconfigurations in line folding can break DKIM, leading to failed authentication and rejected emails. This isn't just theoretical—many large-scale email platforms experience this due to strict SMTP envelope validation.

How to test if your DKIM signature is getting truncated?

You can diagnose DKIM signature truncation by testing a sent email and examining the raw SMTP session logs or header output. Look for incomplete DKIM-Signature headers that cut off mid-phrase or lack proper CRLF continuation. Compare the final b= value against the expected signature length. Tools like MxToolbox or MailTester’s inbox placement test can confirm integrity after relay, and you’ll often notice the b= value is shorter than it should be—especially if you’re hitting a 4,000-character limit in the header.

Step-by-step verification process

  1. Send a test email using a real-time verification API such as MailTester’s API or a similar service. This creates a controlled, traceable outbound message where you can capture raw headers immediately after sending.
  2. Inspect the outgoing SMTP session logs using tools like Wireshark, a mail server debug log, or a transactional email service that exposes raw sessions. Look for the DKIM-Signature: header. If it appears broken—ending mid-phrase, missing newlines, or cutting off after a line longer than 78 characters—this suggests truncation occurred during transport.
  3. Compare the transmitted b= value with the original signature. The b= portion must match the cryptographic hash output from your signing software. If the final value is shorter than expected (e.g., 400 characters instead of 500+), it likely got truncated before transmission.
  4. Use header analyzers like MxToolbox or MailTester’s inbox placement test to decode and validate the signature across multiple receiving servers. These tools show how the email was received and whether the DKIM-Signature header was preserved intact. MxToolbox’s DKIM Analyzer can confirm if the signature passes validation, helping isolate where it failed.
  5. Check for CRLF continuation issues in the header. DKIM headers can span multiple lines using \r\n continuation. If your mail server or relay drops line breaks or enforces hard limits (e.g., 4,000-byte header lines), the signature may get silently cut. RFC 4871 mandates proper line continuation, and violations break validation.

Why this matters

If your DKIM b= value is truncated—even by a few characters—the signature fails validation. Receiving servers reject such messages, harming deliverability. This often happens with poorly configured relays, third-party email gateways, or transport agents that impose line-length restrictions without accounting for headers like DKIM. Using MailTester’s inbox placement tester lets you simulate real-world delivery and catch these issues before sending to your full list.

What happens when the DKIM b= value is truncated in transit?

When the DKIM b= signature is truncated during SMTP transport—typically due to line length limits or misconfigured MTAs—the receiving server computes a hash that doesn’t match the shortened value in the header. Even if the original signature was mathematically valid, the mismatch causes DKIM validation to fail. The message is then rejected, flagged as spam, or quarantined, undermining trust in SPF, DMARC, and sender reputation—regardless of their alignment.

The hash mismatch: why the signature fails

DKIM relies on a cryptographic hash of the message body and headers. The b= value is the encoded result of this hash, signed with the sender’s private key. If the signature gets truncated—say, during a line break in an older SMTP relay—the receiver’s hash calculation will differ because it’s based on the full, unaltered content. This mismatch breaks validation, even though no message content was changed maliciously.

The issue often arises when the SMTP transport agent enforces strict line length limits (like 78 or 998 characters), and the long signature line is incorrectly split or cut short. While modern systems handle long lines correctly, legacy or misconfigured MTAs still cause this. You might not notice it unless you inspect raw headers with tools like MxToolbox or check email logs from major providers.

Consequences: silent failures and trust erosion

Unlike a clear bounce or delivery failure, truncated DKIM signatures often result in silent rejection. The server doesn’t send an error back to the sender—your email just vanishes into a spam filter or quarantine. This is a major red flag for deliverability: even if SPF and DMARC pass, DKIM failure is treated as a signal of poor sender hygiene.

Because DKIM serves as the cryptographic backbone for authenticating email, a consistent failure—even from legitimate sources—can lower sender reputation over time. Email providers track these validation patterns, and repeated DKIM mismatches are correlated with spammy behavior. This isn’t about just one message; it’s about systemic trust degradation.

Let’s be clear: the email wasn’t forged. But if the signature is cut off, the system assumes tampering. That’s why proactive verification is essential. Use MailTester’s email checker to validate individual addresses before sending, or bulk verification to clean up mailing lists at scale—catching issues like malformed DKIM signatures before they impact deliverability.

For deeper insight into email transport issues, see RFC 6376, which defines DKIM and specifies formatting limits for signature lines.

Why is MailTester effective at catching DKIM signature corruption?

MailTester catches DKIM signature corruption by sending test emails through real SMTP relays, mirroring actual delivery. It captures raw headers at every stage, including outbound SMTP, and checks whether the DKIM 'b=' value remains intact. If it’s truncated—causing an 'invalid length' error—it flags it immediately. With 98.9% accuracy, only 1.1% of real issues go undetected, making it reliable for spotting corruption before it reaches inboxes.

Testing what actually happens on the wire

Many tools check syntax or verify address format, but only MailTester simulates real delivery. It doesn’t just validate the address—it sends the email through actual SMTP sessions to real mail servers. This means you’re not testing a model or a guess. You’re seeing what happens when your message hits the wire, including how the DKIM signature is processed through each hop.

During this process, MailTester captures the full header set, including the raw DKIM-Signature line, before and after it leaves your server. This lets it compare the original 'b=' value with what arrives at the receiver’s end. If any part of the signature is altered, truncated, or corrupted during transport—common when an SMTP Transport Agent improperly sanitizes or mangles headers—it triggers an explicit "invalid length" error in the response.

Real-world validation, not just theory

DKIM signature truncation often happens due to aggressive filtering rules in SMTP transport agents, especially in corporate environments or third-party email gateways. These systems may strip long header values without warning. MailTester’s approach identifies these real-world failures by replicating them in the test environment.

Unlike passive validation tools that check only the address or domain, MailTester checks the full end-to-end delivery chain. It’s not a guess. It’s observing actual header behavior through genuine SMTP conversations. This is why it can catch issues that no syntax checker or domain lookup will find—like a signature being cut mid-stream due to agent misconfiguration.

For teams using tools like SendGrid, Mailchimp, or HubSpot, this means you can test not just the address, but how it behaves under real delivery conditions. With integrations already in place, you can run automated inbox placement tests before large send campaigns (learn more: test inbox delivery). The result? Fewer bounces, fewer reputation hits, and stronger deliverability.

For deeper validation, the real-time verification API lets you integrate this same detection logic into your workflows, catching DKIM corruption before your campaigns go live.

SMTP standards define header length limits (see RFC 5322), but some agents still break them. MailTester doesn’t assume everything follows the rules—it tests whether it actually does.

How does MailTester help fix SMTP transport agent issues?

MailTester catches DKIM signature truncation early by validating email addresses at scale with real-time authentication checks. You can test thousands of addresses with DKIM verification enabled, simulate outbound sends via inbox placement tests, and use the in-app AI to decode raw headers and pinpoint where truncation occurs—before it disrupts your deliverability.

Bulk DKIM and SMTP health checks

  • Run a bulk email list verification with DKIM validation enabled by default, catching invalid or truncated signatures before you send.
  • Use inbox placement tests to check if your messages fail delivery due to DKIM length errors during real-world delivery attempts.
  • Check if SMTP transport agents like Microsoft’s are cutting signatures by testing how your domain’s DKIM tokens behave under actual delivery conditions—including common truncation thresholds.

Integrate, diagnose, and clean at scale

  • Connect MailTester directly to SendGrid, Mailchimp, Klaviyo, or HubSpot to validate outbound messages before sending—catching truncation issues during the draft phase.
  • Use the in-app AI assistant to parse raw email headers and identify which transport agent or relay is likely truncating the b= signature, based on known behavior and length thresholds (e.g., 768-character limits in some agents).
  • Filter and clean invalid or risky addresses—especially those with malformed or overlong DKIM records—before they hit your sender reputation or trigger blacklisting.
  • Refer to RFC 6376 for official DKIM signature structure, where b= is defined as a base64-encoded hash value that must not exceed implementation-specific limits in transit.
Truncated DKIM signatures often appear as “invalid length” errors in logs—especially when signatures exceed 768 bytes. The root cause is typically an overzealous transport agent stripping content that doesn’t fit a hard-coded limit.

What’s the best way to ensure DKIM signatures survive SMTP transport?

Use DKIM tools that follow RFC 5322 line folding rules when signing messages. Validate every email through a real-time service like MailTester before sending. Check header integrity in production automatically. Keep signatures simple unless compliance demands complexity. Update your MTA and signing software regularly—some now allow longer lines to prevent truncation. These steps prevent DKIM b= values from being cut mid-signature, which causes invalid length errors.

Keep DKIM signatures intact with proper line folding

  • Ensure your DKIM signing tool breaks long header lines at 78 characters, as required by RFC 5322, not 76 or 77.
  • Never manually break lines or rely on text editors that don’t respect folding rules—this breaks the signature.
  • Test your signing pipeline using real email headers from live traffic, not just mocks.

Verify before you send, and monitor in production

  • Before sending, check every address with a real-time verification tool—use MailTester’s email checker to confirm validity and signature integrity.
  • Run automated checks on a sample of sent emails using a service like inbox placement testing to catch signature corruption early.
  • Implement header validation in your delivery pipeline—validate that all headers, especially DKIM-Signature, are complete and correctly folded.
  • Keep your DKIM keys and domain policies updated. Some modern MTAs now support longer header lines, but older systems still follow strict 78-character limits.
  • Avoid overly complex signatures unless required by policy—larger signatures increase the chance of truncation during relay.
Even if the DKIM signature is mathematically correct, a broken line fold invalidates it at the receiving end.

Truncation during SMTP transport often stems not from failure to sign, but from misconfigured line folding. If your tool doesn’t follow RFC 5322 exactly, any MTA with strict line-length enforcement—such as older versions of Exim or Postfix—will mangle the signature.

Regularly audit your outbound email flow. Use MailTester’s verification API to integrate validation directly into your sending workflow. This catches problems before they hit the inbox.

Remember: a DKIM signature is only as strong as its least-protected component. The moment you send a malformed signature, you invite rejection—even if the content is valid.

Can DKIM signature truncation be fixed after the fact?

No — once a DKIM b= value is truncated in transit, the signature is irrecoverably broken. The integrity of the cryptographic hash depends on the full length of the signature field. Any truncation invalidates the verification process at the receiving end.

Re-sending the message without correcting the underlying configuration will produce the same failure. The recipient’s server cannot reconstruct the original hash from a partial value, regardless of how many times the message is resent.

The only effective solution is prevention. Ensuring correct line folding and proper MIME encoding during the SMTP transport phase — before the message leaves the sending server — is the only way to preserve DKIM signature validity.

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Does DKIM truncation break all incoming messages?

It breaks messages where the receiving server enforces DKIM validation. Messages may still pass if the recipient skips DKIM checks, but delivery reliability drops significantly.

Can I fix DKIM truncation using DNS settings?

No—DNS only stores public keys and policy records. Truncation happens at SMTP relay level, not during DNS lookup.

Is DKIM line folding supported worldwide?

Most modern MTAs support line folding, but some legacy systems still enforce hard 78-character limits without folding.

What is the maximum length of a DKIM b= value?

It depends on the key size and hashing algorithm. A typical SHA256 signature with a 1024-bit key can be 250–350 characters long.

Why does MailTester claim 98.9% accuracy?

This reflects the percentage of email address validations that correctly identify issues like DKIM failure, catch-all addresses, or role accounts based on real SMTP interactions.

Do all email services apply header line limits?

Yes—most SMTP servers apply RFC 5322 limits. However, some modern platforms implement line folding for long headers, reducing truncation risk.

Can I detect DKIM truncation without sending an email?

Not reliably. Static validation tools may flag overly long signatures, but only live SMTP testing confirms if the signature survives transmission.

What’s the difference between a DKIM failure and a bounce?

Bounces are delivery errors; DKIM failures are validation errors. A message can deliver but still fail DKIM checks, leading to spam filtering.

How does MailTester integrate with SendGrid?

It validates email addresses before sending through SendGrid and tests DKIM integrity in real delivery conditions using the same infrastructure.

Are disposable email addresses more prone to DKIM truncation?

No—truncation affects all messages using long DKIM signatures regardless of the sender or recipient domain.

Can I test DKIM signatures for bulk emails?

Yes—MailTester's bulk verification service checks all addresses in a list and flags DKIM-related delivery risks for each.

Does MailTester check SPF and DMARC too?

Yes—MailTester’s verification process checks SPF, DKIM, and DMARC alignment as part of its 98.9% accurate validation engine.