DKIM b= Tag Issues | MailTester

Why is your DKIM b= tag getting cut off or corrupted?

You sent an email that passed SPF and DMARC—but Gmail marked it as unverified. The DKIM signature failed. Not because the key was wrong, but because the b= tag, which holds your email’s digital fingerprint, got chopped off mid-transmission.

It’s not a flaw in your setup. It’s a silent disruption in how emails move through the network—like a signature torn from a letter before it reaches the recipient. And when that happens, even a legitimate message gets blocked, especially by strict recipients like Gmail and Yahoo.

The b= tag is the cryptographic proof your email hasn’t been tampered with. If it’s truncated or corrupted, even slightly, the entire signature fails. This can happen during relay, due to incorrect encoding, or because a mail server enforces a hard size limit that cuts off long headers.

Key takeaways

The DKIM b= tag contains the cryptographic signature that verifies email authenticity; any truncation causes validation failure.
Corruption often occurs during message relay due to encoding mismatches (e.g., improper base64 or line folding) or strict size limits enforced by mail servers.
ISPs like Gmail and Yahoo enforce strict DKIM validation—any disruption in the b= tag leads to delivery rejection, even with valid SPF and DMARC.

How DKIM Works at the Protocol Level

DKIM signs emails using a private key on the sending server, creating a digital signature stored in the email header as a b= tag. This signature must stay unchanged through every step of delivery—any alteration during transit causes verification to fail. Receiving servers check that b= value against the sender’s public key, published in DNS, to confirm the message hasn’t been tampered with.

Signing the Message

When you send an email, your server uses a private key specific to your domain to sign the message’s content and certain headers. This signature is then added to the email header as the b= tag. The b= value is a long cryptographic string—often 200–500 characters—that acts like a fingerprint of the signed data.

Let’s say you send a newsletter from [email protected]. DKIM ensures the receiving server can verify it was actually sent by your domain and wasn’t re-sent or modified in transit. The signature includes only specific parts of the message—defined by the signing selector—and not the entire body or all headers, so the process remains efficient.

Validation and Integrity

When the recipient’s mail server receives the email, it looks up your domain’s public key via DNS. It then recalculates what the b= value should be based on the current message content and checks it against the signature you sent. If they don’t match, the email fails DKIM verification—and may be marked as spam or rejected.

This process is standardized in RFC 6376, the official specification for DKIM. It’s designed so that any change to the email—inserting a link, adding a tracking pixel, or even changing line breaks—invalidates the signature. That’s why the b= tag must remain intact during transit.

Common causes of b= corruption include mail transfer agents (MTAs) that modify headers for routing, message size limits on transit nodes, or poorly configured email hygiene software that strips or rewrites header fields. Even some email clients reformat content in ways that break the signature integrity.

Common Causes of DKIM b= Tag Truncation or Corruption

You’re likely seeing a corrupted or cut-off DKIM b= tag when your emails fail validation because the signature line was broken during transit due to length limits, improper header formatting, or flawed processing by email gateways. This often happens when the DKIM signature exceeds header line limits, gets mishandled by poorly written tools, or suffers from encoding errors. The fix starts with understanding how and where the line gets damaged.

Header Size and Line Length Limits

Many mail servers enforce strict header line length limits—typically 76 characters—breaking long lines without proper folding.
DKIM signatures, especially with long cryptographic keys, easily exceed this, leading to truncation if not folded correctly with CRLF and soft line breaks.
Messages over 10MB may be rejected outright by some inbound servers, indirectly affecting signature integrity.
Check your email client’s or service’s outbound handling: even small, innocent tools can strip or truncate long headers.

Processing Errors in Email Gateways and Clients

Third-party relays and filtering tools sometimes rewrite or simplify headers without preserving DKIM’s exact structure.
Gateways that don’t validate or maintain header integrity can cut off the final b= value mid-line.
Some older or poorly implemented email clients may misrender long header fields, especially when parsing or logging.
Use a tool like MailTester’s email checker to test how your outbound messages are rendered in real inbox conditions.

Encoding and Line Folding Issues

Improper handling of CRLF (Carriage Return Line Feed) sequences during transmission can break the DKIM signature line.
Incorrect line folding—where you wrap long headers but lose the space after the break—renders the b= value invalid.
Using non-RFC-compliant encoding (like plain ASCII where MIME requires quoted-printable) can corrupt the signature payload.
Always follow RFC 2822 specifications for header formatting, especially when using automated tools to generate messages.

Even a single missing character in a DKIM signature can invalidate the entire authentication result—your email might look fine to users, but servers like Gmail or Yahoo will silently reject it.

Let’s say you’re sending a bulk campaign from a third-party platform. If the DKIM signature gets truncated, your sender reputation takes a hit. Use MailTester’s bulk verification to spot check your list for addresses with known delivery issues or misconfigured domains. You can also run deliverability tests with our inbox placement tool to measure how often your emails pass DKIM checks in real inboxes.

Why Line Length Matters in DKIM Headers

DKIM signatures can be long—sometimes exceeding 1000 characters—especially when multiple domains are signed or complex policies apply. If the b= tag isn’t broken into lines under 78 characters using soft line breaks, receiving servers may misinterpret or truncate it, leading to signature verification failures. This happens because RFC 5322 mandates that headers must not exceed 78 characters per line, and long values like DKIM signatures must be folded properly.

The RFC 5322 Line Length Limit

According to RFC 5322, no line in an email header should be longer than 78 characters. This isn’t a suggestion—it’s a strict technical requirement. When DKIM signatures exceed that limit, they must be split across multiple lines using soft line breaks (a CRLF followed by a space or tab). Without proper folding, the receiving server might see the signature as malformed or cut off.

How Misfolded Headers Cause Problems

Let’s say a DKIM b= tag runs 1,200 characters. If it’s not folded, the email might get truncated during transport. The receiving server sees it as incomplete, rejects it, or flags the email as suspicious. Even slight misalignment—like using a hard break or no space after a line break—can cause the signature to be dropped entirely.

It’s not just about length; it’s about correct formatting. Some email systems or libraries automatically handle line folding, while others don’t. If your email service provider or mailer doesn’t apply proper folding, you risk deliverability loss—even if your DKIM key and domain are valid.

One way to catch these issues early is to inspect raw email headers after sending. Tools like MxToolbox or RFC 5322 provide clarity on how headers should be structured. The goal isn’t to avoid long signatures—it’s to ensure they’re correctly formatted so no server misreads them.

If you're sending bulk emails and want to avoid signature failures, validate your list and test your sender setup beforehand. You can use MailTester’s inbox placement test to check how your email is received across real inboxes, including whether DKIM validation passes during delivery. This helps isolate issues like misfolded headers before they impact your sender reputation.

How to Test and Verify DKIM Signature Integrity

DKIM b= tags get corrupted or cut off when headers are improperly line-folded, truncated during transport, or altered by intermediaries like webmail filters or poorly configured email relays. The most common cause is violating RFC 2822’s line-length rule: long DKIM headers must be folded with a space or tab after each newline. You can catch this by testing real email delivery and inspecting raw headers in a tool designed for inbox placement validation.

Step-by-Step: Check and Confirm DKIM Header Health

Send test emails via real deliverability tools — Use a service like MailTester’s inbox placement tester to send emails through real ISP environments (Gmail, Outlook, Yahoo, etc.). Unlike local SMTP testing, this shows how headers appear after real-world processing and filtering.
Extract and review raw headers — After sending, retrieve the full message source. Look for the DKIM-Signature header. It should follow standard formatting: each line after the first must begin with a single space or tab after a newline, not the start of a new line.
Check for broken folding or missing characters — Search for signs of corruption: a truncated b= value (e.g., b=abc instead of b=abc123def), missing closing brackets in the header value, or missing whitespace after line breaks. Even one missing space can trigger failure.
Validate signature using DKIM record lookup — Use a public tool like dmarc.org’s DKIM lookup or MxToolbox to check if the selector and public key in your DNS match the signature’s s= and k= fields. A mismatch often indicates a malformed or altered signature.
Monitor for header truncation in transit — Some email gateways or antivirus software cut headers exceeding 1000 characters. Use a tool that shows how the header appears at the recipient’s end, not just at your sending end.

Use Real ISPs to Validate Signature Integrity

Even if your email passes internal checks, it may still fail in production if DKIM is malformed. ISPs like Gmail and Outlook perform strict header validation. MailTester’s inbox placement testing sends messages through actual ISP servers and returns the raw received headers. This lets you see precisely how DKIM appears — and whether it was altered or truncated — at the destination. It’s the only reliable way to confirm that your DKIM b= tag isn’t being cut off mid-signature due to folding or transport issues.

The 5 steps described in “Step-by-Step: Check and Confirm DKIM Header Health”, in order.

For teams sending bulk email, combining header inspection with tools like the inbox placement tester gives you full visibility into how your DKIM-signed messages are rendered in real inboxes.

How MailTester Helps Detect DKIM Signature Issues

DKIM b= tags get corrupted or cut off due to header folding errors, overly long signatures, or flawed email clients stripping malformed content. MailTester’s real-time API and bulk verification tool check for these exact issues by validating DKIM header structure, catching folding mistakes, and simulating inbox delivery to expose truncation before your emails reach recipients. That’s how you prevent silent delivery failures.

Structural Integrity Checks in Real Time

When you send an email, the DKIM signature must remain intact from sender to inbox. A single line break in a misfolded header can truncate the b= tag, rendering the signature invalid. MailTester’s verification system checks for this by parsing DKIM headers exactly as receiving servers do—no guesswork.

Using the real-time verification API or bulk processing via bulk verification, you can catch folding errors (like breaking lines between "b=" and the signature value) long before they cause bounces or inbox filtering.

Inbox Placement Testing Exposes Failures You Can’t See

Even if a DKIM signature passes structural checks, issues like signature length exceeding 2048 characters or improper base64 encoding can still cause failures during actual delivery. MailTester’s inbox placement tests replicate real-world conditions by sending test emails to Gmail, Yahoo, and Outlook. These systems validate DKIM signatures on the fly—and if the b= tag is corrupted, it fails silently.

By simulating these deliveries, MailTester identifies signature truncation and other structural flaws that third-party tools may miss. This gives you a clear signal: “Don’t send yet—your DKIM is broken.”

Our accuracy—98.9%—is based on validating over 5 billion real-world email addresses across live domains and configurations. Unlike tools that rely solely on heuristics or outdated blocklists, MailTester checks what actually happens in production.

Learn more about how inbox placement testing works and see how your emails behave in real inboxes, so you never send a corrupted signature again.

Best Practices to Prevent DKIM b= Tag Corruption

DKIM b= tags get corrupted when long header lines aren’t folded correctly, causing the signature to break. This often happens when MTAs or sending platforms insert line breaks mid-value, usually after a non-space character. The fix is simple: always fold headers after a space using a soft line break (CRLF + space), as defined in RFC 2822. Use tools to verify signatures before sending to catch issues early.

Header Folding and Line Length

Ensure your sending platform or MTA performs proper header folding: break long lines only after a space, not in the middle of a token.
Use soft line breaks (CRLF + space) instead of hard breaks (CRLF alone) to keep DKIM signatures intact.
Never split a DKIM b= value across lines without proper folding—this breaks the signature digest.
Follow the standards in RFC 2822 Section 2.1.1 for correct line folding in email headers.

Testing and Prevention

Test your DKIM signatures before sending to production lists using tools like MxToolbox or MailTester’s inbox placement tester to validate signature integrity.
Avoid third-party email services that rewrite or strip headers without preserving DKIM signature integrity—this is a common source of corruption.
Monitor bounce reports and authentication failures; unexpected failures on valid domains often signal DKIM truncation.
Verify your signature value length: a long b= value may be cut if headers aren’t folded correctly, even if the domain is properly configured.
Use the MailTester email checker to test individual addresses and verify that your outbound delivery path hasn't altered the signature.

DKIM vs SPF vs DMARC: Roles in Email Authentication

You can think of SPF, DKIM, and DMARC as a chain of authentication checks. SPF confirms the sending server’s IP is authorized. DKIM verifies the email content hasn’t been altered in transit. DMARC sets the rules—what to do if either SPF or DKIM fails—and provides reporting to track issues. When DKIM fails, it often triggers a DMARC failure, which can block delivery. Together, they’re required for strong deliverability. Use tools like our email checker to validate addresses before sending.

SPF: The IP Checkpoint

SPF (Sender Policy Framework) checks whether the IP address sending the email is listed as authorized in the domain’s DNS records. It’s like a guest list for your domain’s mail server. If the sending IP isn’t on that list, the email fails SPF. But SPF doesn't cover forwarded messages or mailbox-level delivery, so it’s only part of the puzzle.

DKIM: The Content Integrity Seal

DKIM (DomainKeys Identified Mail) uses cryptographic signatures to verify that an email’s content hasn’t been tampered with since it left the sender’s server. Each email is signed with a private key, and the receiving server checks it using a public key published in DNS. A corrupted or cut-off d= tag in the DKIM signature—often due to encoding errors, line length issues, or poorly formatted headers—can cause verification to fail. The RFC 6376 specification details the correct header format and signing methodology.

DMARC: The Policy Enforcer

DMARC (Domain-based Message Authentication, Reporting & Conformance) tells receiving servers what to do when SPF or DKIM validation fails. It can instruct them to quarantine or reject the message, and it enables feedback loops via aggregate and forensic reports. DMARC policies rely on both SPF and DKIM: if either fails, DMARC can drop the email into the spam folder or block it entirely.

When DKIM fails due to a corrupted or cut-off signature, even a single missing character in the digital signature or an improperly wrapped line can break the validation. This often leads to DMARC failure. Common causes include header field folding issues, incorrect base64 encoding, or misconfigured email templates that strip or alter headers. To catch these before sending, validate your email setup with our inbox placement tests or use our bulk verification to clean your lists and reduce delivery risks.

Together, SPF, DKIM, and DMARC form the cornerstone of email authentication. They work best when all three are implemented correctly. For more on what’s actually valid in a recipient’s inbox (and what isn’t), consult the IETF RFC 6376 on DKIM and RFC 7483 on DMARC—both foundational standards for modern email security.

When DKIM Signing Is Bypassed or Ineffective

DKIM signatures can be corrupted or cut off when the final sending layer fails to apply them, or when intermediate systems like legacy gateways, content filters, or poorly configured platforms strip or rewrite headers before signing. If a message is re-sent through a filter that modifies content, the original DKIM signature no longer validates unless the signature is regenerated at the new sending point. This breaks authenticity checks and increases the risk of your email being flagged as spoofed or spam.

Limited or Failed Signing at the Sending Layer

Some older email gateways—especially those handling high-volume outbound traffic—may disable DKIM signing entirely due to configuration gaps or processing limitations. If your email is routed through such a system, no valid DKIM signature is added, and the message fails authentication at the recipient’s end. This is especially common in systems designed for internal routing or bulk transactional use, where security checks are overlooked for speed.

Even when DKIM is enabled, multiple signatures applied without proper preservation can lead to collisions. If a platform signs a message that’s already been signed, and doesn’t preserve the original, the original signature becomes invalid or truncated. This is a frequent issue when third-party services like ESPs or marketing automation tools stack signatures without coordination—especially if you’re using a tool like Mailchimp or SendGrid with custom routing rules. The resulting d= or b= tags may appear cut off or malformed in headers.

Content Filters and Header Rewriting Break DKIM

Content filters—used for anti-malware, anti-spam, or compliance purposes—often rewrite message headers or body content automatically. These modifications invalidate the original DKIM signature, even if it was correct to start with. For example, a filter might normalize whitespace, replace URLs, or add disclaimer text, all of which alter the canonical payload and break the cryptographic hash.

Unless the filter is configured to re-sign the message using DKIM, any such change invalidates the auth check. This is why some enterprise-level email protection systems require a re-signing layer or “DKIM proxy” to maintain continuity. Without it, even legitimate messages may be rejected outright, especially with strict policies enforced by large providers like Gmail, Outlook, or Yahoo.

It’s not just filters that break DKIM—some webmail gateways or forwarders also strip or alter headers without re-signing, especially when routing messages through non-standard transport paths. According to RFC 6376, the DKIM specification itself assumes that signed content remains unaltered through delivery, which is only true if signing happens at the final sending layer and is preserved through all intermediary steps.

If you're unsure whether your sender infrastructure preserves DKIM signatures through all transit points, testing with real inbox placement tools gives you insight. MailTester’s inbox tester lets you send to known inboxes and inspect full headers to confirm if the signature appears intact or was removed during transit.

Use MailTester to Validate DKIM Integrity Before Scaling Campaigns

DKIM b= tag corruption often stems from incorrect header formatting, overly long signatures, or flawed signing configurations during bulk email processing. You can catch these issues early by testing email headers in real inboxes before sending at scale. Use MailTester’s inbox placement tests to validate DKIM integrity, delivery success, and overall email health across major ISPs.

Validate DKIM Headers Before You Scale

Run inbox placement tests using MailTester’s inbox tester to see how your emails appear in Gmail, Outlook, Apple Mail, and other major inboxes — including if the DKIM b= tag is truncated or malformed.
Integrate MailTester with platforms like SendGrid, Mailchimp, or Klaviyo via the available integrations to verify that outbound emails meet ISP standards before they leave your system.
Test your DKIM signature length and formatting using MailTester’s real-time verification tool — some mail servers reject emails with DKIM signatures longer than 2048 characters, a common cause of b= tag truncation.
Use the in-app AI assistant to analyze anomalies in email headers, including malformed DKIM records, incorrect alignment, or missing tags, which can cause delivery failures even if the core content is valid.
Check your SPF, DKIM, and DMARC alignment in one test to confirm that all three authentication layers are properly configured, as misalignment can trigger b= tag issues or outright rejection.

Start With Confidence, No Upfront Cost

Begin with 100 free verifications — no credit card required — to test DKIM integrity across your email list without risk.
Run tests on both individual addresses and full campaigns using the bulk verification tool to catch systemic signature issues before they impact sender reputation.
Use the real-time API to validate DKIM headers during automation workflows, ensuring every outbound email passes integrity checks before transmission.
Purchased credits never expire, so you can test frequently and build confidence in your mail flow over time.
Refer to the DKIM specification (RFC 6376) for how signatures are constructed and verified — a key reference for diagnosing structural issues in b= tags.

Final Thoughts: Protect Your Sender Reputation with Proper DKIM

A corrupted or truncated DKIM b= tag can trigger rejection or filtering, even if your email list is clean and your content is legitimate.

Deliverability failures often stem from low-level issues like malformed headers or signature truncation. Verifying authenticity alone isn’t enough—signature integrity must be tested at the header level during every deployment.

Use tools like MailTester to detect and resolve header-level issues before they impact your sender reputation. Real-time inbox testing and bulk verification help catch problems invisible to standard validation.

Sources

DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

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

Frequently asked questions

What does a corrupted DKIM b= tag look like?

It appears as a truncated or malformed string in the DKIM-Signature header — for example, showing incomplete characters, missing closing brackets, or a value that doesn’t match the expected signature length.

Can DKIM fail due to line wrapping?

Yes. If the DKIM b= tag is not properly folded using soft line breaks after 78 characters, it can be truncated or misinterpreted by receiving servers.

Do email filters break DKIM signatures?

Yes. Some mail filters or content rewrite services modify headers in ways that invalidate DKIM, especially if they don’t re-sign the message.

How do I test if my DKIM signature is intact?

Check the raw email header for the DKIM-Signature line and verify proper line folding. Use tools like MailTester to simulate inbox delivery and detect signature failures.

Why does my DKIM signature fail in Gmail but not elsewhere?

Gmail enforces strict DKIM validation. Corrupted or improperly folded signatures may pass on less strict servers but fail in Gmail’s system.

Can a single character error corrupt a DKIM signature?

Yes. DKIM signatures are cryptographic. Even a single incorrect character, such as from truncation or wrong encoding, causes the signature to fail.

Is DKIM signing required for all bulk emails?

Yes. Most major ISPs require DKIM for bulk mail. Without a valid signature, messages are likely to be rejected or marked as spam.

What happens if DKIM b= tag is cut during transport?

The receiving server cannot verify the message's authenticity. This often results in rejection, marking as spam, or DMARC failure due to authentication loss.

Can a misconfigured MTA cause DKIM corruption?

Yes. If the MTA doesn’t preserve headers or applies incorrect encoding during delivery, it can break the DKIM b= value or truncate long lines.

How often should I audit DKIM integrity?

Before every major campaign release, and periodically if using third-party sending platforms. Use MailTester’s deliverability tests to audit headers and signature validity.

Does MailTester test DKIM b= tags during inbox placement?

Yes. MailTester’s inbox placement tests include header-level validation, checking for properly formed DKIM signatures and correct line folding in the b= tag.

Can I fix DKIM issues with tools like MailTester?

MailTester doesn't fix issues directly but identifies them via real-time testing and delivery simulation, enabling you to troubleshoot and correct the source configuration.