Why the B= tag format matters in email verification

You send a batch of emails, only to find half are bouncing. Not because the addresses are wrong—but because the DKIM signature failed. And one tiny detail in the signature, the B= tag, might be the root of it.

The B= tag is the core of a DKIM signature. It carries the actual digital signature, and if it’s malformed—missing padding, wrong character encoding, or invalid base64—receiving servers reject the email. An email verification platform that detects incorrect B= tag format catches this before you send.

Fixing technical flaws like these isn’t just about syntax. It’s about inbox placement. A single malformed tag can harm sender reputation, trigger spam filters, and break deliverability for every message.

Key takeaways

  • The B= tag is the primary component of a DKIM signature and must follow strict formatting rules to be valid.
  • Malformed or incorrectly encoded B= tags cause DKIM validation failures, leading to inbox rejection even if the email address is technically correct.
  • Using an email verification platform that analyzes DKIM structure—including the B= tag—helps identify technical flaws before they hurt deliverability.

What is the B= tag in DKIM, and why does its format matter?

The B= tag in DKIM contains the cryptographic signature that verifies an email’s authenticity and integrity. If the signature is malformed—using invalid characters, improper base64 encoding, or incorrect line breaks—receiving servers reject the email, even if the content is legitimate. This is why strict formatting is mandatory: a single misplaced character breaks the signature chain.

How the B= tag works in practice

In DKIM, the B= tag holds the result of signing the email’s headers and body using a private key tied to your domain. The receiving server uses your public key (published in DNS) to validate this signature. If the B= value isn't correctly base64-encoded, or if it contains spaces, line breaks in the middle of the signature, or uppercase letters where lowercase is expected, validation fails.

DKIM is case-sensitive. A signature with the wrong combination of uppercase and lowercase letters won’t match the expected output. Similarly, inserting line breaks where they’re not tolerated (e.g., splitting the base64 string every 76 characters incorrectly) will corrupt it. RFC 6376, the standard governing DKIM, specifies that the B= value must be a single, continuous base64 string—no padding issues, no whitespace, no delimiters.

Why format errors matter for deliverability

Even if your email content is clean and your SPF/DKIM records are set up properly, a malformed B= tag can trigger immediate rejection. Major providers like Gmail, Microsoft, and Yahoo validate signatures rigorously—any deviation results in a hard bounce or spam filtering. According to the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), invalid or malformed DKIM signatures are among the top technical reasons for delivery failures in enterprise email systems.

Incorrect B= format often happens during email generation or API integration when libraries mishandle the signature output. For example, some SMTP clients or email builders don’t escape newlines or encode output correctly before placing it in the B= field. These errors are invisible during preview but fatal at delivery.

You don’t need to parse DKIM signatures manually. An email verification platform like MailTester’s bulk verification tool can catch these structural flaws before you send. It checks not just if an address exists, but whether the domain’s DKIM configuration—including signature formatting—is valid. This helps you spot domains with broken signing before they start damaging your sender reputation.

How does an email verification platform detect incorrect B= tag format?

A truly accurate email verification platform detects incorrect B= tag format by simulating real SMTP transmission and parsing DKIM headers at the protocol level. It validates that the B= field contains a properly base64-encoded string of the correct length and adheres to the expected character set—failing fast on malformed, improperly padded, or non-base64 content before any message is sent.

Testing DKIM metadata under real-world conditions

DKIM signatures are not just checks—they’re cryptographic validations built into the email’s header. To spot a malformed B= tag, a platform must examine the header during a live-style SMTP session. Without this, you’re only guessing. MailTester runs synthetic sends that mirror actual delivery, checking each DKIM field in real time.

Specifically, it verifies that the B= field:

  • Contains only valid base64 characters (A–Z, a–z, 0–9, +, /, =).
  • Is correctly padded with = signs to ensure byte alignment (e.g., "abcd==" vs. "abcd")
  • Matches the expected digest length for the signing algorithm (like SHA-256)

Why simulation matters more than static parsing

Some tools scan headers after the fact, but that’s too late. If the B= tag is malformed, the message will likely fail validation at the receiving server—even if the email address itself is real. You won’t know until you send. MailTester detects these issues proactively, during its simulation phase, by emulating how actual mail servers process DKIM.

For example, if a sender uses an improperly formatted signature—say, a missing = or a non-base64 character—the platform flags it as invalid. This prevents sending messages that would otherwise be rejected or marked as spam.

When you send through MailTester’s API or bulk verification tool, it doesn’t just check syntax—it validates the full digital integrity of the DKIM signature. This means you catch format issues that static tools miss. For technical teams integrating with SendGrid, Mailchimp, or Klaviyo, this is critical: a single malformed B= tag can break deliverability.

For deeper technical validation, see the official DKIM specification in RFC 6376. Standards like this define how B= fields should be structured, and real verification tools must follow them rigorously.

Use MailTester’s bulk verification to check thousands of addresses at once, including DKIM metadata integrity, before sending. Or try the API checker to verify individual addresses in real time with accuracy that includes signature validation.

Common B= tag format errors caught by MailTester

You’ll catch formatting issues in DKIM's B= tag — like invalid base64 characters, missing padding, line breaks, or case sensitivity errors — that break signature validation. These flaws, even if small, cause emails to fail authentication. For example, a single space or incorrect capitalization can mean a message is rejected, even if the domain and key are correct. RFC 6376 specifies strict formatting rules, and MailTester enforces them during real-time verification.

Base64 format and structure issues

  • Whitespace or punctuation (e.g. commas, spaces, hyphens) inside the B= value — these are not valid base64 characters and will break DKIM validation.
  • Missing or incorrect padding (e.g. missing '=' characters) in base64 strings — this breaks decoding and may result in a failed DKIM signature.
  • Improper line folding within the B= content — DKIM requires the signature value to be a single line; any line breaks or wrapping violate RFC 6376.
  • Case sensitivity errors — DKIM is strict about case. A mismatch in uppercase/lowercase letters in the B= value or other parts of the header results in signature failure.

Why these matter in practice

Even small errors here can cause emails to be marked as spam or rejected outright. According to RFC 6376, the base64-encoded signature must be exact — no room for typos or formatting tweaks. Tools that skip this check may send emails that pass initial validation but fail during gateway review.

MailTester catches these issues before they cost you deliverability. You’re not just checking if an email exists — you’re validating that the authentication setup is technically correct. This prevents bounces, improves sender reputation, and helps you stay off blocklists.

Use the real-time verification API to test DKIM B= tags at scale, or run bulk checks with the bulk verification tool. Both integrate with your existing workflows and flag technical errors like malformed signatures before they go live.

Why traditional email verifiers miss B= tag format issues

Most email validation services only check if an address has an @ symbol and a valid domain — they don’t look at DKIM’s cryptographic headers, which means they miss malformed B= tags entirely. These tools focus on deliverability risks like catch-all accounts or disposable domains, not on whether your email signature is technically correct or if the DKIM signature was generated properly. Without simulating an actual SMTP transaction, they can’t verify if the B= tag in the DKIM signature matches what the receiving server expects. This leaves a critical gap: even if an address is "valid," your email may fail authentication and be marked as spam.

What’s missing in basic validation

Traditional email verifiers treat syntax (like presence of @) and basic domain health as enough. They don’t analyze DKIM signatures because doing so requires deeper access to the email’s cryptographic layer and simulating how real mail servers process messages. You might think a list with 98% "valid" addresses is safe — but if those addresses have malformed DKIM signatures, your messages will be rejected or flagged by Gmail, Outlook, or Yahoo. This isn’t just theoretical: RFC 6376, the standard for DKIM, defines precise rules for how the B= tag must be structured, particularly in line folding and encoding, and even small deviations break validation.

Why SMTP-level checks matter

DKIM signature validation starts with the receiving server parsing the B= tag and verifying it against the public key. If the tag is malformed — for example, if line breaks are incorrect, or base64 encoding is off — the signature fails, and the entire message becomes suspicious. Without testing the full delivery pipeline, including the cryptographic handshake, you’re flying blind. That’s why platforms like MailTester’s bulk verification go further: they simulate real SMTP transactions and inspect how each DKIM signature is rendered in practice. This isn’t about guessing — it’s about verifying whether your email headers match what mail servers actually accept.

DKIM is not optional for high-volume senders. It’s a core part of authentication, and a single malformed B= tag can disrupt deliverability. You can’t rely on simple syntax checks or catch-all detection to ensure your messages pass the full chain of security validation. For deeper insight, consult the DKIM specification (RFC 6376) — it spells out the exact structure of the B= tag, including how it must be folded and encoded across multiple lines. Even a missing newline in a signature can invalidate the signature in a real-world mail server environment.

How MailTester catches B= tag issues with real-time verification

You don't just check the syntax of a B= tag—you test it in a live SMTP session. MailTester verifies real email delivery by simulating actual server connections, parsing DKIM headers during the handshake, and flagging B= values that fail base64 decoding or violate standard formatting. This real-world validation catches issues other tools miss.

Why the B= Tag Matters in DKIM

The B= tag contains the digital signature in a DKIM-signed email. If it’s malformed, the signature fails verification, and ISPs may reject the message. This isn’t just about format—it’s about whether the email actually reaches the inbox. Poorly formed B= values often result in bounce rate spikes or inbox filtering.

  1. Initiate a live SMTP session with the destination mail server using real-time API calls. Unlike passive checks, this builds an actual connection to test delivery conditions as they occur in production.
  2. Fetch and parse the DKIM header during the handshake. MailTester examines the full DKIM-Signature header, including the B= tag, as it would appear in a live email transmission.
  3. Validate B= tag format against RFC 6376. The system checks for correct base64 encoding, line breaks, and character sets. Any deviation triggers a risk flag, even if the tag appears syntactically correct at first glance.
  4. Confirm integrity by testing the full signing chain. A valid B= value must align with the public key and selector in DNS. MailTester cross-references this to ensure the signature is mathematically and structurally sound.
  5. Flag delivery risks and return detailed diagnostics. If the B= value fails decoding or violates standards, the result is labeled as “risky” or “invalid” in the verification report—with context on the exact issue.

DKIM is an industry-standard email authentication method. Misconfigurations here can harm sender reputation and trigger spam filters. According to RFC 6376, the B= value must follow strict encoding rules. Our verification process enforces these rules in practice, not just theory.

How This Works in Practice

Let’s say you’re sending marketing emails and notice high bounce rates. Running those addresses through MailTester’s real-time verification reveals that several have B= tags with invalid base64 padding or illegal characters. These fail DKIM checks even if the email address itself is valid. Fixing the signing mechanism prevents future bounces.

Use our real-time verification API to catch these issues at scale, or run a single address check before adding it to a campaign. For bulk lists, go to our list verification tool to scrub your data automatically. Each test includes full DKIM analysis—no assumptions, just real server feedback.

What happens when B= tag format errors are ignored?

If your DKIM signature contains a malformed B= tag, major email providers like Gmail, Outlook, and Yahoo will reject the message—even if the recipient’s address is valid. Authentication fails, delivery is blocked or marked as spam, and your sender reputation suffers over time due to consistent signature failures. Fixing these issues before sending is not optional; it’s foundational.

Why malformed B= tags cause delivery failure

The B= tag in a DKIM signature holds the actual cryptographic hash of your message’s content. If it's formatted incorrectly—due to encoding errors, missing padding, or invalid characters—the entire signature is considered invalid. Providers like Google and Microsoft scan incoming messages against DKIM standards, and any deviation triggers rejection.

Even when the email address is correct and the message content is legitimate, a single malformed B= tag breaks authentication. The result? Delivery fails silently, or the message lands in spam folders without notification. This is especially damaging for transactional or time-sensitive emails, where delayed delivery is just as bad as failure.

Major senders use strict validation. According to RFC 6376 (the standard governing DKIM), the B= field must be properly base64-encoded and correctly padded. An error here breaks alignment with industry norms, which are enforced rigorously by inbox providers.

Reputation damage accumulates silently

Each time a message with a malformed DKIM signature is sent, it adds to a record of technical failure. ISPs and email platforms track sender behavior over time. Repeated authentication drops—even if your list is clean—signal a lack of technical diligence to algorithms that assess sender trust.

You might still see a "delivered" status, but that often refers only to the SMTP handshake, not inbox placement. If the DKIM check fails, the message may be blocked during post-delivery filtering, often without a bounce. This leads to ghost bounces—where no feedback is returned, but delivery never succeeds.

Over time, a pattern of failed DKIM checks reduces your sender reputation. Even if you fix the issue later, reputation recovery takes time. It’s far easier to prevent failures by validating your DKIM configuration before sending.

Use MailTester’s email checker to verify individual addresses and inspect their DKIM signatures early. For bulk sends, run your list through bulk verification to catch structural issues like malformed signatures at scale. The platform doesn’t just check validity—it tests deliverability across real inbox environments.

How MailTester improves accuracy with a 98.9% verification rate

MailTester achieves 98.9% accuracy not just by checking if an email exists, but by detecting subtle technical flaws like incorrect b= tag format in DKIM signatures—issues that can silently undermine deliverability. This level of detail separates it from basic validators that only check syntax or basic reachability.

Technical depth behind the accuracy

Many platforms stop at “valid” or “invalid.” MailTester goes further by simulating real-world email delivery conditions. It checks not only if an address is routable, but also whether the underlying email infrastructure—like DNS records, SPF, DKIM, and header formatting—is correctly configured.

For instance, a misconfigured b= tag in a DKIM signature might pass basic syntax checks but still cause email rejection by receiving servers. MailTester identifies these anomalies during header analysis, giving you a clearer picture of whether an email can actually reach the inbox or will be flagged as suspicious.

Real-time validation, layered checks

Our process combines three layers: real-time API calls, full SMTP simulation, and deep inspection of email headers. While some tools only test whether an address responds to a connection attempt, MailTester validates the full envelope, including authentication chains.

This layered approach is uncommon. Most email verification platforms focus on list hygiene—removing invalid or disposable addresses—but miss infrastructure-level risks. These hidden flaws may not cause immediate bounces, but they erode sender reputation over time, increasing the risk of inbox placement issues.

For example, DKIM RFC 6376 specifies the exact format for the b= tag. Deviations, even minor ones like missing padding, can lead to authentication failure. MailTester checks for these in real-time.

If you're sending at scale, catching these errors before deployment is critical. Use our bulk verification to scan entire lists, or our real-time API to verify individual addresses as you collect them. The result is a deliverability-ready list with fewer failures and higher engagement. Not just a cleaner list—better performance.

MailTester’s integration with email platforms prevents B= tag issues

When you integrate MailTester with SendGrid, Mailchimp, HubSpot, or Klaviyo, it checks every email address before it’s sent—catching invalid formats, including malformed DKIM signatures like incorrect B= tags. This stops delivery failures and protects your sender reputation before they start.

How MailTester catches B= tag problems during delivery prep

  • You send a list through Mailchimp, HubSpot, or Klaviyo—MailTester runs instant checks in the background.
  • If a DKIM signature includes a B= tag with an invalid format (like missing padding or unsupported characters), MailTester flags it as a failed verification.
  • Bad DKIM signatures often result from misconfigured email providers or incorrect key formatting—MailTester detects these issues before your message hits the wire.
  • Instead of sending a message that fails DMARC checks, MailTester returns clear feedback: “DKIM signature validation failed: malformed B= tag.”
  • This prevents hard bounces, inbox placement drops, and damage to sender reputation that comes from inconsistent or invalid cryptographic signatures.

Real-time feedback helps you fix issues fast

Let’s say a contact used a role email like [email protected], but the DKIM key setup was wrong. The B= tag might appear invalid due to improper encoding—MailTester’s detection logic identifies that and marks it as “risky” or “invalid.”

When you use the inbox placement test, you’ll see not just delivery results, but exactly why messages failed—like “DKIM verification failed: B= tag not properly base64-encoded.”

DKIM is a requirement in modern email delivery; RFC 6376 specifies the syntax for B= tags. Errors here break authentication, which major providers like Gmail and Outlook detect and penalize. MailTester’s engine checks that standard, so you stay compliant.

You’re not just verifying addresses—you’re validating the full cryptographic path. That means fewer bounces, stronger reputation, and higher inbox placement.

Want to check your list before sending? Run it through our bulk verification tool to catch errors before they impact deliverability.

Best practices to ensure B= tag format is correct

You can prevent DKIM signature failures caused by an incorrect B= tag format by using certified libraries, avoiding manual changes to signatures, testing with trusted tools, and validating alignment regularly. The B= value must be a properly base64-encoded, non-truncated, and correctly formatted digest of the signed content — any deviation breaks verification. Let's walk through the essentials.

Use only RFC-compliant DKIM signing libraries

  • Choose DKIM signing libraries that implement RFC 6376 exactly, especially around header canonicalization and base64 encoding of the B= value.
  • Libraries like OpenDKIM, libsodium, and verified implementations in Python (e.g., dnspython with proper validation) are proven to follow the standard.
  • Custom or DIY signing logic introduces hidden errors — even a single extra space or missing newline can corrupt the digest.

Never edit or truncate the B= value after signing

  • The B= value is a cryptographic digest — editing it breaks DKIM verification.
  • Do not trim whitespace, alter line breaks, or modify the value during email processing, forwarding, or rewriting.
  • If you're using an email service or middleware, verify no automatic processing introduces changes to raw headers or body content.
  • Use our real-time email checker to test individual addresses and detect if a signature was altered in transit.

Test DKIM signatures before sending

  • Use tools like MxToolbox’s DKIM Validator to inspect real-world emails and confirm B= format compliance.
  • Run checks before sending to production lists — catch misforms early.
  • For deeper validation, use RFC-compliant debuggers to parse header and body canonicalization step-by-step.

Validate alignment and format across all sending domains

  • Check that every domain used to send emails has a valid DKIM record and that the B= value aligns with the d= and s= values.
  • Perform regular audits — even trusted domains can break if records are misconfigured or updated.
  • Use our bulk verification tool to pre-screen your mailing list and flag domains with weak or misaligned signatures.

Final takeaway: verification isn’t just about address existence—test the full email stack

Even a perfectly formatted email address can fail to deliver if the DKIM signature is malformed. The B= tag format is a critical part of that signature, and errors here can trigger rejection by receiving servers—even if the address itself is valid.

Many email verification tools stop at syntax checks or MX record validation. They miss deep technical flaws like incorrect B= tag formatting, which can derail deliverability in production. True verification must inspect the full email stack.

MailTester goes beyond basic checks

Our platform validates not just the address, but the complete technical chain: DNS records, DKIM configuration, catch-all detection, and server behavior. This full-stack assessment catches failures before they hit the inbox.

Deliverability isn’t just about sending to valid addresses—it’s about sending to addresses that can receive your message. MailTester ensures your emails pass every gate, from DNS to authentication.

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 B= tag in email verification?

The B= tag in DKIM contains the cryptographic signature of an email. Its format must be strictly base64-encoded, properly padded, and correctly structured to pass validation.

Can an email address be valid but still fail DKIM due to B= tag issues?

Yes. Even if the address is real and deliverable, a malformed B= tag in DKIM will cause authentication failure and may result in rejection by recipient servers.

Why don’t most email verifiers detect B= tag format errors?

Most platforms only check email syntax and common delivery risks. They don’t simulate SMTP or validate cryptographic headers like DKIM.

How does MailTester detect B= tag issues?

MailTester performs a full SMTP-level verification, parses DKIM headers, and checks the B= field for correct base64 encoding, length, padding, and formatting.

What happens if the B= tag is not properly formatted?

The email fails DKIM authentication. Major providers like Gmail and Outlook treat this as a red flag, often marking the message as spam or blocking it entirely.

Do I need to fix B= tags after sending?

No. The only effective approach is to detect errors before sending. Once sent, a malformed signature cannot be corrected in transit.

Can a catch-all address pass DKIM if the B= tag is malformed?

Yes. Catch-all addresses may deliver, but DKIM failure still risks reputational harm and eventual blocklists, even if the email reaches the inbox.

How often should I audit my DKIM signatures?

At least weekly for active senders. Any change in signing infrastructure, domain, or email template can introduce format errors in the B= tag.

Which email platforms integrate with MailTester to catch B= issues?

MailTester integrates with SendGrid, Mailchimp, HubSpot, and Klaviyo. These integrations allow pre-send verification of DKIM signatures during campaign deployment.

Does MailTester check all parts of DKIM, not just the B= tag?

Yes. It validates the full DKIM signature, including the selector, signing domain, alignment, and header canonicalization, ensuring the entire flow is technically sound.

What percentage of bounces are caused by DKIM issues like malformed B= tags?

While exact figures vary, DKIM failures account for a meaningful share of hard bounces when senders are not validating signatures correctly.

Can disposable email domains pass B= tag validation?

Yes. Disposable domains may have valid signatures. The issue is not with the domain type but with the B= tag format—if it's malformed, it fails regardless of domain type.