Why Your DKIM b= Signature Might Break Email Delivery

You send a carefully crafted email. It passes authentication, looks legitimate, and still lands in spam. Not because of content or sender reputation—but because a single line in your DKIM signature broke under the weight of its own length.

DKIM signatures are meant to verify email authenticity. But if your b= signature exceeds 78 characters per line during transport, it gets silently truncated. No error. No warning. Just failure.

When a transport agent cuts off a DKIM signature mid-line, the receiving server can’t verify it. The message is rejected—or marked as suspicious—often without your team realizing why.

Key takeaways

  • DKIM b= signatures must not exceed 78 characters per line during SMTP transport.
  • Truncation of the b= value breaks DKIM validation even if the signature is syntactically correct.
  • Even valid keys and proper alignment fail if line length limits are violated during transmission.

What Is the 78-Character Line Length Limit in SMTP?

SMTP, as defined in RFC 5321, requires that every line in an email header— including whitespace and line breaks—be no longer than 78 characters. If your DKIM b= signature exceeds this, it must be broken across multiple lines using a soft line break (CRLF followed by a single space). Failing to do so can cause delivery failures or spam filtering, even if the signature is mathematically correct.

Why Line Length Matters in Email Transport

Even if your DKIM signature is valid, a broken line length can be silently rejected by email transport agents. This isn’t about the content being wrong—it’s about the format misaligning with SMTP’s rigid rules. Many mail servers and gateways enforce this limit strictly, and when violated, they may discard the message or flag it as suspect.

Let’s say your DKIM b= value is 150 characters. You can’t just wrap it at any point. The standard way is to add a newline (CRLF) followed by exactly one space—this is called a soft line break. If you use two spaces or no space, or insert a hard break, the agent may treat it as malformed and reject the signature. This causes a failure during verification, even if everything else is correct.

For reference, the original SMTP specification in RFC 5321 explicitly states that all lines, including those in headers, must not exceed 78 characters. This is not a recommendation—it’s a hard requirement. The RFC is the definitive source: https://tools.ietf.org/html/rfc5321. You can find this rule in Section 2.2, under the definition of a "line" in the protocol.

How to Verify Your DKIM Signature Line Lengths

Manually checking every DKIM signature in a bulk email list isn’t practical. But you can spot-check a few using tools that parse raw email headers. If you’re sending via a service like SendGrid, Mailchimp, or AWS SES, you can download message headers and inspect them. The key is looking at the DKIM-Signature header and confirming whether the b= value is properly wrapped.

Even small missteps—like a missing space after a CRLF—are enough to break delivery. It’s not enough to assume your signing library does it right; some libraries have edge cases or legacy behavior that doesn’t strictly follow the standard.

Testing for this issue isn’t just about technical correctness—it’s about inbox placement. If the DKIM signature breaks due to line length, the mail won’t pass validation, and it may land in junk folders—or be outright rejected.

If you’re verifying DKIM signatures at scale, you can check them as part of a full deliverability review. Try MailTester’s inbox placement tool to see how real inboxes react to your messages, including how they handle headers and signatures.

How to Test if Your DKIM b= Signature Is Too Long

You can reliably test whether your DKIM b= signature exceeds the 78-character line length limit by examining the raw header of a delivered email. Look for the DKIM-Signature header and check if the b= value appears as a single, unbroken line longer than 78 characters. If it does, it may be rejected by transport agents that enforce strict line-length rules.

Step-by-Step: How to Verify DKIM b= Line Length

  1. Retrieve a raw email header from a sent message. Send a test email from your domain and collect the full raw header from the delivery record — ideally via an email testing service, inbox monitor, or your mail server’s logging system.
  2. Locate the DKIM-Signature header. In the raw header, find the line starting with DKIM-Signature:. This line contains multiple tag-value pairs, including the b= signature.
  3. Check if the b= value exceeds 78 characters and is not wrapped. The b= value is a cryptographic hash. If it’s longer than 78 characters and appears as one continuous line without soft line breaks (i.e., no CRLF within the value), it violates the transport agent line length rule defined in RFC 2822.
  4. Use a tool that displays raw headers and validates formatting. Services like MailTester’s Inbox Placement Test can help you analyze delivered messages and verify that DKIM signatures are properly formatted — including line wrapping.
  5. If the b= value is too long, reconfigure your signing process. Most DKIM signers allow you to specify line length limits. Ensure your signing library or service wraps long values at or before 78 characters using CRLF, not just spaces, to stay compliant with standards.

Why This Matters for Deliverability

A DKIM signature that’s not properly wrapped causes delivery failures in strict environments. Transport agents like those maintained by ISPs and bulk email providers reject messages with malformed headers — even if the signature is valid otherwise.

The 78-character limit isn't arbitrary. It's rooted in the MIME and SMTP standards that govern how email is transmitted. If your DKIM b= token isn't split correctly, your domain’s sender reputation can be compromised — especially during volume sends or when targeting providers with enforcement policies.

While DKIM verification tools like MailTester’s Email Checker can validate syntax, they won’t catch line length issues unless you inspect the full header. This requires looking at real delivered mail, not just a static test.

Proper DKIM formatting is part of a broader email hygiene practice. Ensuring your signatures are wrapped correctly reduces the risk of rejection, especially when sending at scale.

How MailTester Can Help Verify DKIM Signature Issues

You can test if your DKIM b= signature exceeds the 78-character line length limit by using MailTester’s inbox-placement testing, which sends real emails through actual delivery paths and returns the full raw headers. This lets you inspect the DKIM-Signature header directly and verify whether the b= value is properly wrapped or exceeds the limit—without guessing, simulating, or relying on synthetic data.

Real Delivery, Real Headers

MailTester doesn’t use test mailboxes or mock servers. It sends your email to real inboxes via major providers like Gmail, Outlook, and Yahoo, then captures the exact headers as they were received. This includes the full DKIM-Signature header, where the b= value appears. You’ll see if it exceeds 78 characters or gets broken over multiple lines improperly.

Because the test uses actual delivery agents, the headers reflect real-world behavior—not theoretical limits or lab conditions. If your b= value is too long, you’ll see it in the raw output, and can adjust your signing process accordingly.

Direct Verification Without Guesswork

DKIM signatures must follow RFC 6376, which specifies that header lines must not exceed 78 characters. The b= value is particularly sensitive because it contains the full base64-encoded signature hash, which can grow large with longer keys or more complex headers. Misformatted lines can cause signature verification to fail.

With MailTester, you’re not relying on automated tools that assume or estimate. You’re seeing the actual transport-level header as it was received. This is how deliverability teams at companies with strict compliance standards validate DKIM correctness.

If your signature is misformatted, you can fix the key length, adjust header canonicalization, or simplify the signing process before sending to real users. This prevents rejection by receivers that strictly enforce RFC compliance.

For teams needing to check multiple addresses or domains at scale, MailTester’s inbox-placement tester includes DKIM validation as part of the full delivery report, and you can run this for individual addresses via our email checker or integrate it into your workflow with the real-time verification API.

What Proper DKIM Signature Wrapping Looks Like

You’re testing DKIM signature line length compliance when you check if any line in the DKIM-Signature header exceeds 78 characters without proper wrapping. A valid DKIM signature wraps each parameter value across multiple lines, starting each continuation line with a single space (not a tab or extra whitespace). If the entire header, including spaces and the signature value, goes over 78 characters without wrapping, the signature fails validation. This is enforced by RFC 6376 and commonly checked by mail servers and validation tools like RFC 6376 and MxToolbox.

How to Recognize Correct DKIM Signature Formatting

Let’s look at a properly wrapped DKIM-Signature header. The first line starts with DKIM-Signature:, and each subsequent line begins with exactly one space. This spacing is critical — tabs or multiple spaces break the format.

Example:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail; c=relaxed/relaxed; h=from:subject:to:date; bh=abc123...; b=def456...

The b= value is the longest part and must be wrapped carefully. Any line that exceeds 78 total characters — including the colon, space, and parameter name — is broken into new lines, each starting with a single space. This allows systems to parse the signature correctly, even across long values.

Why Improper Wrapping Breaks DKIM Validation

If your DKIM signing tool or library doesn’t enforce line breaks at or before 78 characters, you risk producing a signature that’s rejected. Even a single line longer than 78 characters (including the initial space) will invalidate the signature. This can happen if the signing process doesn’t respect the line-wrapping rules during header serialization.

Many email validation tools — including MailTester’s real-time email checker — include DKIM validation as part of header-level inspection. They’ll flag signatures that violate 78-character limits or use incorrect spacing, helping you catch issues before they affect deliverability.

What Happens When DKIM b= Is Too Long and Not Wrapped

If your DKIM b= signature exceeds the 78-character line length limit in the MIME transport format and isn’t properly folded across lines, the receiving mail server may reject the message outright or flag it as malformed. Even if accepted, the signature fails DKIM verification, which undermines the message’s authenticity and can damage your sender reputation. Malicious actors sometimes exploit formatting oversights like this, so automated systems often treat such messages as suspicious or low trust.

Why Line Length Matters in DKIM Signatures

DKIM signatures are part of the email’s header and must follow strict MIME formatting rules laid out in RFC 5322. Specifically, email lines must not exceed 78 characters unless properly folded using a soft line break (i.e., a carriage return + line feed). The b= value is a base64-encoded cryptographic hash that can easily exceed this limit, especially with longer signing keys or complex canonicalizations.

When the b= value isn’t wrapped, it breaks the header structure. Most mail servers expect well-formed MIME, and a single malformed line can cause the entire message to be dropped silently or tagged as spam. According to Mail-Tester, improperly formatted headers are among the top reasons for inbox placement failures, even if the content itself is legitimate.

Consequences of Failure: Beyond Bounce Rates

If the signature fails due to length issues, the receiving server will reject the DKIM check, and the email won’t be considered authentic. This doesn’t just mean lower inbox delivery—it also harms your long-term sender reputation. ISPs like Gmail and Outlook track failed DKIM validations, and repeated failures can trigger sender throttling or even domain-level blocks.

Spammers exploit signature format issues to bypass filtering systems, so some automated checks treat long, unbroken b= values as red flags. You aren’t targeting spam, but if your signature format appears suspect, you’re at risk of being treated like one.

Let’s be clear: this isn’t just a technical nitpick—it’s a deliverability issue. The same verification tools you use to clean lists or test inbox placement, like our inbox placement tester, can help catch these issues before they reach production. Use a reliable DKIM generator that respects transport agent limitations and always tests your headers against realistic mail server expectations.

Steps to Fix Malformed DKIM b= Signatures

DKIM signatures with a b= value over 998 characters will break during email transport, causing authentication failures. To fix this, ensure your signing tool splits the signature into multiple lines using soft line breaks (CRLF) before the 998-character limit. Test all signatures in a real inbox environment—no tooling can fully replace actual delivery testing.

Use a compliant DKIM signing tool

  1. Choose a DKIM library that respects line length limits. Tools like OpenDKIM, libsodium, or well-maintained libraries in Python (dnspython), Node.js (node-dkim), or PHP (php-dkim) handle line breaks automatically during signature generation. Avoid custom implementations that concatenate the entire b= value into a single line.
  2. Verify the raw header output. After signing, inspect the DKIM-Signature header. The b= value should be split into multiple lines with a soft line break (CRLF) after every 998 characters. Most MTAs treat a line exceeding this as invalid, even if embedded in a single header field.
  3. Test the signature structure with a real email environment. Even if your tool outputs compliant headers, deliverability depends on how receiving mail servers process them. Use a tool like MailTester's inbox-placement tester to validate how your emails perform in actual inboxes before sending to production lists.

Debug and validate before sending

If you're maintaining a custom signing implementation, you're responsible for enforcing the line limit. The DKIM RFC explicitly defines 998 as the maximum line length for the b= value. Exceeding it breaks authentication and can trigger spam filtering.

Let’s be clear: a malformed signature isn’t just a technical glitch—it’s a delivery killer. Even if the rest of your email stack is solid, one non-compliant DKIM header can sink your message into spam or reject it outright.

Use a real inbox placement tester to catch these issues early. With MailTester’s inbox placement tester, you can send a message to a real-world inbox and see exactly how it lands—whether it hits the inbox, spam, or gets rejected. This step is not optional when sending to large lists.

DKIM Signature Formatting Best Practices

You must wrap long DKIM-Signature headers using a space after a CRLF to avoid transport agent line length limits. Keep the b= value within bounds by using shorter hash algorithms when necessary—though rsa-sha256 remains the default standard. Always validate signatures against RFC 6376, and test with real delivery paths, not just local simulators.

Formatting and Line Length

  • Always wrap DKIM-Signature headers by inserting a CRLF followed by a single space before continuing the value.
  • Never break the header without a leading space after the line break—this violates RFC 6376 and causes validation failures.
  • Use explicit line breaks for readability and compliance. Tools that auto-format signatures should enforce this behavior.

Signature Value Length and Algorithm Selection

  • Limit the length of the b= value by choosing shorter hash algorithms if line length is a concern, though rsa-sha256 is still recommended for security and deliverability.
  • Longer hashes (like sha512) increase the size of the b= component—this can push the signature beyond the 78-character limit in practice, especially with large keys.
  • While rsa-sha256 is the industry standard, using rsa-sha1 or rsa-sha256 with smaller key sizes (e.g., 1024-bit instead of 2048-bit) may reduce signature length if needed.
  • Test signatures using actual email providers’ delivery paths. Simulators rarely replicate real agent behavior, including line length enforcement.
  • Validate compliance with RFC 6376, which defines header structure, encoding, and canonicalization rules.

Use tools that test real-world delivery, such as MailTester’s inbox placement testing, to verify that your DKIM signature survives transport. Even minor formatting issues can cause rejection—especially with strict inbound filters.

"Proper DKIM header formatting isn't about preference—it's about meeting the RFC standard that defines how agents read and validate signed messages."

Why You Shouldn’t Trust Email Verifiers That Don't Test Delivery

Most email verifiers only confirm whether an address exists—no real-world testing involved. That’s not enough. To know if your emails will actually land in inboxes, you need to send a real test message through a real transport path and inspect the raw headers. MailTester does exactly that, sending test emails to check for authentication failures like DKIM b= signature line wrap issues before they damage your sender reputation.

Most Verifiers Don’t Test Actual Delivery

Many tools flag an email as "valid" just because it passes basic syntax and domain checks. But a valid address doesn’t mean your message will be accepted. A domain can accept mail while rejecting messages with malformed authentication, and the only way to find out is to send a real piece of mail. This is where most email verifiers fall short— they don't test delivery.

You can’t trust a list of “valid” emails if your DKIM signature exceeds the 78-character transport agent line length limit. This breaks the signature, causes authentication failures, and can trigger rejections. Even if a verifier says an address is “valid,” it won’t catch a signature wrapping issue unless it sees the full transport path.

MailTester Tests the Full Chain

MailTester sends real test emails from authenticated domains through actual mail transport paths. The tool returns raw headers, including the full DKIM-Signature header, so you can spot problems like improper line wrapping in the b= tag. This is the only way to catch these issues before they hit your sending volume.

For example, if your DKIM signature exceeds the 78-character limit, the signature is rejected by receivers following RFC 2822’s line length rules. This can lead to messages being flagged as misformatted or even blocked entirely. The only way to detect this is by sending a test message and seeing the exact header output—something standard verifiers can’t do.

By sending real test emails and returning full headers, MailTester gives you proof of deliverability, not just a list of “maybe-good” addresses. It’s how you verify that your messages won’t bounce due to technical issues in authentication.

See how it works: test inbox placement and authentication with real-world results. You can also bulk-verify your list and get full header diagnostics for every address.

How to Use MailTester to Catch DKIM Line Length Issues Before Sending

You can test if your DKIM b= signature exceeds the 78-character line limit by sending a test email through MailTester’s inbox-placement tester. After delivery, extract the raw email header and check that the DKIM-Signature header splits long b= values into lines no longer than 78 characters, with proper continuation using a space at the line break. This prevents delivery failures due to transport agent rejection.

Step-by-Step: Verify DKIM Line Length with MailTester

  1. Send a test email using MailTester’s inbox-placement testing feature. This simulates real-world delivery and ensures the full email stack—including headers—is processed as it would be in production. You can test with any email address, including your own or a test mailbox.
  2. Retrieve the raw email header from the test result. MailTester returns the complete header of the delivered message, including all authentication records such as DKIM-Signature, SPF, and DMARC. This gives you full visibility into how your email is parsed by receiving systems.
  3. Inspect the DKIM-Signature header for the b= value. Look for lines that exceed 78 characters. According to RFC 2822, message lines must not exceed 998 characters, but practical transport agents often enforce stricter limits—78 characters is a safe limit for header lines to avoid rejection.
  4. Check for correct line folding. A compliant DKIM signature will wrap the b= value across multiple lines, each starting with a space (a soft line break). If the value appears as a single line longer than 78 characters, it will likely be rejected by systems that strictly enforce line length.

What You’re Looking For: Correct DKIM Header Formatting

The DKIM-Signature header should follow the RFC 8301 (formerly RFC 4871) format. When the b= value is long, it must be split across multiple lines using a space after a CRLF. For example:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector; bh=abc123...; b=xyz789... q=...;

If the b= value appears as a continuous string past line 78, your email will fail during SMTP validation on strict servers. This is especially true in high-volume or transactional email systems where agents like MXToolbox or Spamhaus may reject non-compliant messages.

You can verify your email setup at scale with MailTester’s inbox-placement testing feature. It’s designed to catch technical flaws—like malformed DKIM headers—before they impact sender reputation. Once you identify the issue, adjust your signing process to insert line breaks in the b= value using a space after CRLF when it exceeds 78 characters.

Conclusion: Proactive Verification Prevents Delivery Failures

A single malformed DKIM b= signature can cause rejection by receiving servers, even when DNS records are correct and cryptographic keys are valid.

Line length limits and improper header wrapping are common but often overlooked issues. Testing for them is not optional—it’s essential to maintain deliverability integrity.

Use real-world delivery testing with tools like MailTester to catch problems before they affect sender reputation or inbox placement.

Sources

Keep reading

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

Frequently asked questions

What is the maximum line length for DKIM signatures in SMTP?

SMTP requires all header lines, including those in DKIM-Signature, to be no longer than 78 characters, including the line break.

Does a DKIM signature have to be wrapped if it exceeds 78 characters?

Yes. If a DKIM header line exceeds 78 characters, it must be split into multiple lines using a soft line break (CRLF + space).

Can a DKIM failure be caused by line length?

Yes. If the b= value is not wrapped correctly, the receiving server may reject or fail to verify the signature, even if the key and DNS are valid.

How can I test if my DKIM signature is properly formatted?

Send a test message through a service like MailTester that returns raw headers and check the DKIM-Signature line for line wrapping and length.

Is there a tool that checks line length in DKIM signatures?

Yes — tools that deliver test emails and return raw headers, like MailTester, allow inspection of the DKIM-Signature for line length and wrapping.

Do all email providers enforce the 78-character line limit?

Yes, all standard SMTP providers follow RFC 5321, which enforces the 78-character limit on header lines.

What happens if DKIM b= is too long and not wrapped?

The signature may be truncated, rejected, or marked as invalid, leading to email delivery failure or spam classification.

Can email verifiers detect DKIM line length issues?

Most do not. Only inbox-placement testers like MailTester that send real messages and return raw headers can detect format issues in DKIM signatures.

Is it safe to increase the b= signature length to include more data?

No — the signature’s role is authentication, not data storage. Excessive length compromises delivery and violates SMTP standards.

Why use MailTester over other email verification tools?

MailTester tests actual delivery paths, returns raw headers, and checks DKIM, SPF, and DMARC in real-world conditions — not just syntax.

Do I have to pay to test DKIM signatures with MailTester?

No — you get 100 free verifications to test deliverability, including DKIM issues, with no expiration on purchased credits.

Can poor DKIM formatting affect sender reputation?

Yes — consistent DKIM failures due to malformed signatures can degrade sender reputation and increase the risk of being blocked.