Test DKIM B Tag Length

Why DKIM B tag value length matters for email deliverability

You sent an email. It passed SPF. It passed DMARC. But it still didn’t land in the inbox. Why? One invisible culprit: the DKIM B tag value length.

The DKIM B tag holds the cryptographic signature that proves the message hasn’t been altered. If it’s too short, too long, or malformed for the signing algorithm, receivers treat it as invalid — even if the rest of the setup is perfect.

Understanding how to test DKIM B tag value length for correct signature format is essential. It’s not just about the presence of a signature; it’s about whether the signature matches the expected format and length for its algorithm.

Key takeaways

The DKIM B tag must match the expected length for its cryptographic algorithm, such as RSA-SHA256, to be accepted by receivers.
Excessive B tag length can result from malformed or improperly formatted signatures, leading to authentication failures.
Testing DKIM B tag value length is a critical step in diagnosing why authenticated emails are being rejected or flagged as suspicious.

What exactly is the DKIM B tag value and how is it generated?

The DKIM B tag contains a base64-encoded digital signature created by the sending domain’s private key. It's derived from a canonicalized version of the email’s headers and body, hashed using an algorithm like SHA-256. The resulting signature can be unusually long—often 256 to 512 characters or more—especially when using strong RSA keys (2048-bit or larger).

How the signature is formed

When you send an email with DKIM, the server applies a hashing algorithm to the canonicalized content of the message. This generates a fixed-size digest, which is then signed using the domain’s private key. The output of that signing process is the B tag value, which gets base64-encoded for inclusion in the DKIM-Signature header.

It's common to see B tag values over 300 characters when RSA is used with larger key sizes. Larger keys mean stronger security, but also longer signatures—this is normal, not a bug.

Why length matters in practice

Some older systems or poorly configured validators may reject DKIM signatures that exceed a certain length. While RFC 6376 doesn’t set a hard limit, many mail servers expect signatures to remain under 512 bytes—roughly what you get with 2048-bit RSA. Longer values, especially with 4096-bit keys, can cause problems.

Because the B tag is part of the DKIM verification chain, any mismatch in length or format can result in a failed signature check. This impacts inbox placement and sender reputation.

You can validate the correctness of a DKIM signature, including its length and format, during email delivery testing. Tools like MailTester’s inbox placement tester help you confirm that signatures are properly generated and accepted by major providers. It’s a practical way to catch issues before they hit your campaigns.

For deeper inspection, refer to RFC 6376, which defines DKIM, including how signatures are constructed and validated. The standard confirms that base64 encoding is required and that the B tag must match the expected digest based on canonicalization. This ensures alignment across receivers.

What happens if the DKIM B tag value is too long?

If the DKIM B tag value exceeds the standard 255-character limit for DNS TXT records, some receiving servers or DNS parsers may truncate or reject it, breaking the signature validation. This invalidates the DKIM check entirely, causing emails to fail authentication and likely land in spam or be rejected outright—especially common with high-bit-length keys like 4096-bit RSA.

Why TXT record limits matter

DNS constraints aren’t arbitrary—RFC 1035 explicitly caps TXT record strings at 255 characters per segment. When the B tag (which contains the actual digital signature) grows beyond that, the record gets split or cut short. Even if the domain responds, the receiving server may not reconstruct the full signature, leading to a failed DKIM check.

Some providers and mail transfer agents (MTAs) silently enforce this limit, while others log warnings. But regardless of how they handle it, truncated signatures are unusable—meaning even perfectly valid emails get flagged as unauthenticated.

How key length affects signature size

Longer cryptographic keys—like 4096-bit RSA—produce significantly larger signatures. This increases the length of the B tag, making it more likely to exceed DNS limits. For example, a 2048-bit signature is already sizable; doubling the key length nearly doubles the signature payload.

Let’s say you use a 4096-bit key without checking the resulting B length. The signature might be 1,000+ characters long—well beyond the 255-character threshold. If no DNS splitter like RFC 4871 is used to break it into multiple sub-records, the entire DKIM check fails at the receiving end.

Even if your DNS provider allows long records, not all mail servers handle them the same way. Some don’t support or trust multi-part TXT records correctly. That makes strict adherence to DNS limitations not just a technical preference—it’s essential for deliverability.

Proactive checks help prevent this. You can test whether your DKIM B tag would survive DNS transmission—before sending, before deployment. Use tools that check DNS record compatibility, especially if you’re using large key pairs. As part of your pre-send verification workflow, ensure your B tag fits within standard limits.

For teams automating email delivery, embedding DKIM validation into your verification pipeline can prevent issues before they hit the inbox. Whether you're using a real-time API or bulk processing, validate the full DKIM structure—including signature length—before sending.

How to test if your DKIM B tag value length is within acceptable bounds

Use a real-time email deliverability tool to examine signed email headers and extract the full DKIM signature. Isolate the B= value, then verify it doesn’t exceed 255 characters per TXT record segment when split. If it does, split the signature across multiple TXT records using correct d= and p= tags. Validate alignment with tools like MxToolbox or a DKIM validator to ensure your signature remains valid.

Step-by-step verification process

Send a test email with DKIM signing. Use a real email client or SMTP service that signs messages. This ensures you’re testing an actual signed email in production-like conditions.
Inspect the full email headers. Look for the DKIM-Signature header line. It contains multiple tags, including B=, which holds the base64-encoded signature value.
Extract and isolate the B= value. Copy only the portion after B= in the DKIM-Signature line. For example: B=abc123... (excluding the trailing semicolon and other tags).
Check base64 length against 255-character limits. Each TXT record segment in DNS can hold up to 255 characters. If the B= value exceeds this, it must be split across multiple TXT records.
Split the value into 255-character chunks. Use a DNS-aware tool or script to divide the base64 string into segments, each no longer than 255 characters. Each segment becomes a separate TXT record.
Reconstruct the signature with correct tag order. In DNS, multiple TXT records for DKIM must be ordered by their sequence number (e.g., 1, 2, 3...). Use the d= and p= tags to specify the domain and public key, respectively, and ensure the B= parts are correctly referenced in sequence.
Validate with a DNS or DKIM tool. Paste your DKIM record set into a validator like MxToolbox’s DKIM checker or check the alignment using a dedicated tool. This confirms the full signature matches and passes DNS validation.

Why DNS record limits matter

DKIM signatures are typically base64-encoded, and long signatures—especially with complex cryptographic algorithms like RSA-2048 or ECDSA—can exceed the 255-character limit per TXT record. Exceeding this limit breaks DNS resolution, causing DKIM validation to fail, even if the signature is mathematically correct. Per RFC 6376, DNS record splitting is allowed and recommended in such cases.

The 7 steps described in “Step-by-step verification process”, in order.

If you're managing a large email send volume, validating DKIM signature length before sending at scale helps prevent silent delivery failures. Tools like MailTester’s inbox placement tester can help you send and validate such messages in real-time environments, mimicking how recipients see your emails.

For automated checks across multiple addresses, bulk email verification with real-time deliverability testing ensures your outbound emails meet technical standards, including proper DKIM signature formatting.

How MailTester helps verify DKIM B tag length and syntax

MailTester’s inbox-placement testing simulates real email delivery and parses DKIM signatures in real time, catching malformed B tag values, incorrect base64 encoding, and violations of length or syntax rules defined in RFC 6376. It checks that the B tag value aligns with the public key and adheres to expected structure, ensuring your DKIM signature is both valid and properly formatted.

Real-time DKIM signature parsing during delivery simulation

When you run an inbox-placement test on MailTester, the system doesn’t just send email—it analyzes the full header chain, including the DKIM-Signature field, as it would appear in a real inbox. This includes inspecting the B tag, which holds the actual digital signature. The tool validates that the B tag length fits within the expected range for the signing algorithm (e.g., 384 bytes for RSA-SHA256), flags values that are too short or too long, and ensures the signature is correctly base64-encoded and free of padding or syntax issues.

Malformed B tags are a common cause of DKIM failures, even when the domain and selector are correct. MailTester detects these early—before they trigger filtering at receiving servers—so you don’t lose deliverability due to subtle signature errors.

Support with AI-assisted header verification

Let’s say you’re troubleshooting why a DKIM check fails in your email service. MailTester’s in-app AI assistant can help you decode and validate the DKIM headers by comparing them against standards like RFC 6376. You can paste raw headers and let the AI explain whether the B tag value meets length requirements, base64 format, or alignment expectations. It’s like having a deliverability expert reviewing your signature, pointing out where the syntax diverges from the norm.

While RFC 6376 doesn’t mandate a specific length for the B tag—it depends on the key size and hash algorithm—it does enforce that the signature must be consistent with the public key used in DNS. Misaligned signatures, often due to incorrect canonicalization or key mismatch, are flagged too. This level of detail helps teams verify that authentication isn’t just in place, but actually working as intended.

For teams using tools like SendGrid, Mailchimp, or HubSpot, testing DKIM syntax before sending at scale is essential. You can test DKIM signatures using MailTester’s inbox-placement tester, which integrates directly with many email platforms via their APIs or webhooks. If you're building a high-volume send process, you can also use the real-time verification API to validate DKIM format in bulk.

Want to check a single address or test your full mailing list? Explore how MailTester handles DKIM and other deliverability checks through its inbox placement tester or bulk verification tool.

Common DKIM B tag length issues and their causes

DKIM B tag values that exceed 500 characters often fail during DNS lookup, causing signature validation to drop. This usually happens due to oversized keys, improper header canonicalization, or platform limitations in splitting long TXT records. You can avoid delivery issues by ensuring your DKIM signature stays under the 500-character DNS limit, especially when using large key sizes or complex signing tools.

Overly large key sizes exceed DNS limits

Using 4096-bit RSA keys can generate B tag values over 600 characters, exceeding the standard 500-character limit for DNS TXT records.
Smaller keys like 2048-bit RSA typically produce signatures well under 500 characters, making them more compatible with DNS constraints.
Consider switching to 2048-bit keys if you're consistently hitting size limits—this is still considered secure by industry standards, including those outlined in RFC 6376.

Improper canonicalization and tool misconfiguration

DKIM signing tools that fail to canonicalize headers properly can produce longer, inconsistent B tags due to unnecessary whitespace, sorting order, or encoding issues.
Always verify your signing tool applies relaxed or simple header canonicalization—this keeps the output predictable and compact.
Tools that don’t handle trailing newlines or whitespace correctly can inflate B tag length without improving security.
Test raw signatures using a DKIM and SPF inbox placement tester to catch length issues before sending bulk mail.
Some email platforms do not split long DKIM signatures into multiple TXT records, leading to outright rejection during DNS lookup.
Unlike SPF, DKIM does not have built-in support for long record splitting—your DNS provider must allow or handle this via multi-record syntax.
If your signature is longer than 500 characters, split it manually across several TXT records, each under the limit, and verify the final digest matches.

What is the maximum allowable length for a DKIM B tag value?

The DKIM specification does not set a fixed upper limit on the B tag value’s length. However, DNS TXT records are capped at 255 characters per segment. If your DKIM signature exceeds this, you must split it across multiple TXT records using sequential identifiers like "1", "2", etc., ensuring the full signature remains intact when reassembled.

Why TXT record limits matter for DKIM

You might think a longer DKIM signature is better, but DNS doesn’t work that way. Each DNS TXT record segment can hold only up to 255 characters. If your B tag value is longer—common with modern cryptographic algorithms like RSA or ECDSA—it must be split. If you don’t, DNS servers will reject the record, breaking DKIM validation.

How splitting works in practice

Let’s say your B tag value is 510 characters. You’d split it into two TXT records: one labeled with "1" and another with "2", each containing 255 characters (or 254, depending on encoding). The domain’s TXT record now includes both, ordered sequentially. When receiving servers query the DKIM record, they assemble all parts in order and validate the full signature.

While this process is standardized, errors happen—especially when using tools that don’t handle multi-segment TXT records correctly. A missing segment or misordered part breaks the signature, causing delivery failures or spam filtering.

Testing the final DKIM signature before deployment helps catch these issues. Tools like MailTester’s email checker can validate a full DKIM setup during inbox placement testing, showing exactly how your email handles verification in real-world inboxes.

The process is well-documented in RFC 6376, Section 3.4, which defines how signatures and TXT record parsing should behave. It’s not a matter of opinion—it’s how the system was designed to work.

Best practices for managing DKIM B tag length in production systems

Use 2048-bit RSA keys for DKIM signing unless your security policy mandates larger keys. Break long signatures into multiple DNS TXT records if your provider doesn’t handle this automatically. Always validate the full record using a reputable DNS validator to ensure no truncation occurs and all parts are correctly deployed.

Key actions to ensure proper DKIM B tag handling

Use 2048-bit RSA keys unless higher key sizes are required by compliance standards. Larger keys increase signature length, which can exceed DNS TXT record limits.
Verify your email service provider or custom signing tool splits large DKIM B tags across multiple DNS TXT records. Without this, signatures may be truncated and fail validation.
Test every DKIM record with a DNS validator that supports multi-part TXT lookups—tools like MXToolbox or DNSStuff can confirm proper split handling.
Confirm no partial or truncated signatures appear. A truncated B tag results in failed authentication, damaging sender reputation and inbox placement.
Monitor for changes in DNS record size over time. Adding new headers or increasing selector complexity can push signature length beyond safe thresholds.
Use RFC 6376 (the DKIM standard) as a reference for correct signature format and length rules. It defines how B tags must be structured and managed.

Proactive checks and validation

Let’s be clear: a single misformatted or truncated DKIM record can cause all outbound emails from your domain to be rejected. Even if your system passes initial tests, real-world email clients enforce strict validation.

After deploying DKIM, use a dedicated tool to test inbox placement and deliverability across major providers—this gives you real-world insight into whether your signature format is accepted. The inbox tester simulates delivery to Gmail, Yahoo, Outlook, and other major inboxes, including DKIM verification.

Don’t rely on assumptions. Even minor DNS configuration issues can break signing. When in doubt, validate the full TXT record structure using a tool designed for DNS analysis. A single missing or improperly split part can invalidate the entire signature.

Why you can't rely on manual inspection alone to test DKIM B tag length

You can’t trust a quick glance at a DKIM header to catch B tag value issues—encoding mistakes, incorrect canonicalization, or broken line breaks during signing can slip through, even if the length looks right. Many errors won’t trigger a rejection, meaning your message might pass silently with a flawed signature. Only real-time inbox testing that parses headers and simulates actual delivery conditions can confirm whether the B tag is both correctly formatted and accepted by receiving servers.

Manual checks miss subtle, hard-to-spot failures

DKIM’s B tag holds a base64-encoded cryptographic signature that must be perfectly aligned with the header canonicalization and body hashing. A single misaligned line break, a wrong padding character, or a malformed digest can corrupt the signature—yet these issues often don’t show up in a quick visual scan. Even minor deviations can render the signature invalid, and manual inspection simply can’t catch them reliably.

For example, a signature that’s too long or too short may still pass visual inspection if it’s split across lines correctly. But if the line breaks don’t follow canonicalization rules (such as breaking after 76 characters in a strict format), the receiving server may reject the signature or silently ignore it. This is why RFC 6376, the standard governing DKIM, mandates precise formatting rules that manual checks can’t enforce.

Failures are often silent, not immediate

Some mail servers don’t reject messages with malformed DKIM signatures outright—they just ignore them. That means your email might still appear to “deliver,” but without authentication, it’s flagged as suspicious or blocked by spam filters. This silent failure makes it dangerous to rely on human review alone.

Instead, you need test tools that simulate real inbox conditions by receiving and validating the full message chain, including header parsing and cryptographic checks. Only this kind of end-to-end validation tells you whether the DKIM B tag is actually working in practice. For that, you need access to a verified delivery environment that can test real email flows, not just static header inspection.

If you're verifying DKIM signatures at scale, consider using inbox placement testing tools that examine the full header and body during delivery. MailTester’s inbox placement tester enables this by sending real emails to multiple inboxes and confirming deliverability and header integrity—including accurate DKIM signature validation—without needing to set up a full mailing infrastructure.

How to prevent DKIM B tag value length issues before scaling your email

Integrate DKIM verification into your sending pipeline early. Use tools like MailTester’s real-time API to validate DKIM signature formats before messages are sent. Run bulk checks on your email list to catch malformed B tag values that cause authentication failures. Monitor sender reputation and inbox placement over time—subtle shifts may signal DKIM instability before full delivery collapse. This proactive workflow prevents scale-up failures caused by signature length or format errors.

Verify DKIM signatures at scale before sending

Use MailTester’s real-time API to validate DKIM B tag value length and structure during send preparation. This catches format issues before they impact delivery.
Run full list verification with MailTester’s bulk email checker to identify addresses with malformed or missing DKIM signatures. A single bad signature can trigger filtering.
Check B tag values against standards: the value must be a properly encoded base64 string, not truncated or padded incorrectly. Excessive length can violate policy limits—verify alignment with RFC 6376.

Monitor long-term delivery health

Track inbox placement over time using MailTester’s inbox placement tester. A dip in inbox delivery may correlate with DKIM instability, even if bounces remain low.
Monitor sender reputation through consistent testing. Tools like MxToolbox or Spamhaus offer real-time diagnostics for blacklisting or reputation flags that can stem from inconsistent DKIM.
Integrate DKIM validation into your QA process. Let’s treat DKIM as more than a checkbox—it’s a signal of sender trustworthiness. Even minor signature deviations degrade long-term deliverability.

DNS-based authentication is only effective if signatures are correctly formed and consistently validated. The DKIM B tag must represent the full signature hash—trimming or encoding errors break verification. Testing at scale with tools that understand RFC 6376 semantics (like MailTester) is the only reliable way to catch these issues before they scale with your list.

Conclusion: Protect your sender reputation with proper DKIM formatting

The DKIM B tag value must be precisely formatted and within acceptable length limits to ensure authentication succeeds. Even a single incorrect character or an overly long signature can break the chain of trust.

Authentication failures due to malformed DKIM signatures lead to rejected messages, increased bounce rates, and long-term damage to sender reputation. Monitoring these values at scale is essential for consistent inbox placement.

Real-time verification tools like MailTester test DKIM signatures alongside other deliverability factors, allowing you to detect issues before they impact your email program. With 98.9% accuracy, MailTester helps you maintain compliance and avoid delivery failures.

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 is the maximum length of a DKIM B tag value?

The DKIM standard doesn’t enforce a hard limit, but DNS TXT records must be under 255 characters per segment. If the B tag exceeds this, it must be split into multiple records.

Can a long DKIM B tag break email delivery?

Yes. If the B tag is too long and not split correctly, DNS servers may truncate or ignore it, causing DKIM failure and potential reputation damage.

How do I know if my DKIM B tag is too long?

Use a DKIM validator or email deliverability tool that parses real headers. MailTester checks B tag value length, encoding, and alignment.

Do I need to split DKIM B tags across multiple DNS records?

Only if the base64-encoded value exceeds 255 characters in a single TXT record. Splitting is required for longer signatures.

What keys are best for avoiding long DKIM B tags?

Use 2048-bit RSA keys. Larger keys like 4096-bit increase signature length and heighten the risk of DNS truncation.

Can email providers automatically split long DKIM B tags?

No. Most providers expect the sender to manage record splitting or use a service that handles it correctly during signing.

Is a malformed DKIM B tag the same as a failed signature?

Not exactly. A malformed B tag prevents valid authentication. Failed signatures may result from key mismatches, timing issues, or tampering.

Why does my DKIM signature work in testing but not in production?

Production environments may have stricter parsing or DNS handling. Long or poorly split B tags can be truncated in real-world deliveries.

How often should I test DKIM B tag length?

Test after any change to your signing key, domain configuration, or email service integrations. Automate with mailbox testing tools.

Does MailTester check DKIM B tag value length?

Yes. MailTester's inbox-placement testing parses DKIM signatures and verifies B tag length, format, base64 encoding, and alignment.