Why Does a DKIM b Tag Contain Non-Base64 Characters?

You sent a verified email. The SPF checks out. DKIM signs it. Yet it lands in the spam folder—or worse, vanishes entirely. You check the headers, and the b= tag shows characters like ~, !, or even line breaks. What’s wrong?

Digital signatures in email rely on strict rules. The DKIM b= tag must contain only valid Base64 characters. When it doesn’t, cryptographic validation fails—no matter how clean the rest of the setup looks. This isn’t a rare edge case. It shows up where tools cut corners, testing environments get out of sync, or systems predate modern standards.

Here, you’ll learn exactly why the b= field sometimes contains non-Base64 characters—what misconfigurations, tools, or protocols cause it—and how to spot and fix it before it breaks your sender reputation.

Key takeaways

  • DKIM b= values must use only Base64-encoded characters; any deviation breaks signature validation.
  • Non-Base64 characters in b= commonly originate from testing tools, legacy email gateways, or poorly implemented libraries.
  • Even one invalid character disables cryptographic alignment, triggering DMARC failures and inbox filtering.

How to Spot the DKIM b Tag Issue in Email Headers

You’ll find the DKIM b tag issue by inspecting the raw email headers for the DKIM-Signature: line, then checking the b= parameter. It must contain only valid Base64 characters: A–Z, a–z, 0–9, +, /, and = for padding. Any other character—like a space, hyphen, dot, or control character—breaks the signature and causes rejection by receiving servers.

  1. Access the raw message content from your email client or mail server logs. Most tools like Gmail, Outlook, or MTAs show raw headers when you choose "Show original" or similar.
  2. Locate the DKIM-Signature: header. It appears as a single line, starting with DKIM-Signature: and continuing with multiple parameters such as v=1, a=rsa-sha256, and crucially, b=....
  3. Inspect the b= value. This is the cryptographic signature. It must consist only of Base64 alphabet characters. The full set includes A–Z, a–z, 0–9, +, /, and = for padding. Any deviation invalidates the signature.
  4. Check for invalid characters like spaces, hyphens (-), dots (.), or non-printable ASCII codes. These are commonly introduced by misconfigured signing libraries, manual edits, or broken encoding during transport.
  5. Validate encoding rigorously. Use a Base64 validator or tool like RFC 4871 to confirm the b= value adheres to the standard. Even one errant character breaks authentication.

Why This Matters for Deliverability

DKIM is a core email authentication method. Receiving servers reject messages with invalid signatures—often marking them as spam or dropping them silently. A single non-base64 character in the b= parameter can trigger a hard fail, even if your SPF and DMARC are correct.

Problems like this often appear when automated systems mishandle binary data. For example, some libraries improperly encode binary signature output as quoted-printable or base64 with formatting breaks. Always verify the signing stack’s output is pure, unpadded Base64 before transmission.

Let’s say you're troubleshooting a batch of emails going to major providers like Gmail or Yahoo. Even if your sender reputation is strong, a malformed DKIM b tag can lead to inbox placement failures. Tools that analyze raw headers help you catch this before scaling.

For teams needing to validate large volumes of email addresses or test deliverability early, MailTester can help ensure your sender setup aligns with receiving server expectations.

Test how your emails land in real inboxes.

Common Causes of Invalid Characters in DKIM b Tags

You’re seeing non-Base64 characters in your DKIM b tag because the signature payload wasn’t properly encoded before Base64. This usually happens during signing logic, when debug data leaks in, or when legacy systems misapply escaping. Let’s break down the real culprits so you can fix them.

Signature Generation Issues

  • URLs or strings inside the signature are not properly percent-encoded before hashing — a common mistake in custom signing logic.
  • Some tools accidentally include human-readable headers like Debug: signed by example.com in the signature field, which corrupts the hash.
  • When generating the b tag, a raw binary hash is Base64-encoded without being sanitized — this can introduce control characters or line breaks that break parsing.

Hidden or Legacy System Problems

  • Debug tools, mail servers, or email clients (like older versions of Outlook or Thunderbird) sometimes inject debug comments directly into the header, which get included during signing. These comments appear verbatim in the b tag.
  • Legacy systems that pre-encode parts of the signature (e.g., using URLDecode or URLEncode on portions of the hash) break the canonical signing format.
  • Custom signers that don’t use a standard library may improperly handle binary data, leading to invalid characters like 0x00 or 0x0A in the output.

According to RFC 6376, section 3.4, the b tag must contain only valid Base64 characters: A-Z, a-z, 0-9, +, /, and =. Anything else — including spaces, newlines, or unescaped punctuation — invalidates the signature.

Let’s be clear: even one stray character breaks DKIM. If you’re not using a trusted library (like OpenSSL or DANE tools), your signing logic may be silently misbehaving.

If you're validating your setup, test with a tool that checks the raw header, not just the visible body. Tools like MxToolbox’s DKIM Checker can expose flaws in the raw header that aren’t apparent in email clients.

Before sending, verify your signing process with a real-time API that validates the full email structure, including headers. For example, MailTester’s email verification API checks for valid DKIM signatures as part of deliverability health.

Understanding Base64 in DKIM: The Core Expectation

You must ensure the b= tag in a DKIM signature contains only valid Base64 characters—A–Z, a–z, 0–9, +, /, and = for padding—no spaces, commas, or line breaks. Any deviation, like extra punctuation or whitespace, breaks the format and causes verification failure. The encoded data must represent a correctly canonicalized version of the signed body and headers, as defined in RFC 6376.

The Role of Base64 in DKIM Signatures

DKIM signs parts of an email by converting binary content—like headers and body—into a string of text using Base64 encoding. This allows binary data, which isn’t safe for plain-text transmission, to be passed through email systems unharmed. The b= tag holds the result, which must be a clean, unaltered Base64 string.

Let’s say you’re generating a DKIM signature manually or via code. Every single character matters. If a space sneaks into the encoded string, or a newline appears after a line break, the signature fails validation. The receiving server will reject the email, often marking it as undeliverable or spoofed.

Formatting Rules and Canonicalization

Base64 alone isn’t enough—the content being signed must also be properly canonicalized before encoding. This means removing extra whitespace, normalizing line breaks, and ensuring headers are ordered and formatted exactly as specified in RFC 6376. Even a single mismatch here leads to a mangled signature.

For example, if your sender includes a trailing space in a header like Subject: Test instead of Subject: Test, the canonicalization process will treat this differently than expected. The resulting hash—before Base64 encoding—changes, and so does the final b= value.

Always double-check that your implementation follows the strict format: no embedded newlines, no special characters outside the allowed Base64 set, and complete adherence to the canonicalization algorithm. Tools like RFC 6376 define these rules explicitly.

When debugging, inspect the full DKIM header. Look for any non-Base64 characters, particularly after b=. A missing = padding character, or a + where a / should be, can be the culprit. Use a real-time email checker like MailTester’s email checker to validate the entire header structure before sending.

How MailTester Can Help Debug DKIM b Tag Issues

When your DKIM b tag contains non-Base64 characters, it breaks signature validation and can cause emails to be rejected or marked as spam. MailTester’s real-time verification and inbox-placement testing help you identify and fix these issues by analyzing raw headers, flagging invalid signatures, and confirming whether delivery failures are linked to signature faults.

AI-Powered Header Analysis in Real Time

Let’s say you’re troubleshooting a bounce report and notice DKIM validation failed. You can paste the raw email header into MailTester’s in-app AI assistant, which scans it instantly for non-Base64 content in the b tag. It doesn’t just highlight the error—it points to the exact character causing the failure, such as a newline, unescaped symbol, or encoding misalignment.

This is faster than manual decoding and eliminates guesswork. The tool checks the full header structure against RFC 6376, the industry-standard specification for DKIM, helping you spot issues that slip past basic validators.

Confirm If Signature Errors Impact Inbox Placement

DKIM failures don’t always block delivery, but they can hurt sender reputation and lead to inbox placement drops. Use MailTester’s inbox-placement tester to send test emails from your domain and see whether your signature issues are being flagged by major providers like Gmail or Outlook.

Test results show if your DKIM signature is valid, whether headers are correctly signed, and if the email lands in the inbox or spam folder. If the signature is invalid and the email lands in spam, you’ve found the root cause.

For larger campaigns, run bulk verification using MailTester’s email list verification tool. It scans all addresses for invalid DKIM signatures in their originating mail streams, helping you catch patterns—like a shared SMTP server with misconfigured signing—or domains that consistently fail validation.

When integrated with platforms like SendGrid, HubSpot, or Klaviyo via MailTester’s API integrations, you can catch DKIM signature issues before sending to entire lists. This real-time validation ensures only compliant emails are sent, reducing bounce rates and protecting your sender reputation.

Understanding DKIM is critical—RFC 6376 defines strict formatting rules. A single misencoded character in the b tag can invalidate the entire signature. MailTester doesn’t just flag errors; it helps you understand why they occurred, so you can fix the underlying process.

Verify DKIM Signatures with Real Email Testing

Send a test message from your domain to MailTester’s inbox-placement test service. Check the raw headers for the b= tag in the DKIM-Signature line—invalid characters like spaces or line breaks indicate a non-base64 encoding issue. Validate fixes in a controlled environment before deploying to production.

Reproduce and Validate DKIM Issues with Real-World Testing

  1. Send a test email from your domain to MailTester’s inbox-placement tester. This simulates real sender behavior and captures exact header output as mail servers would see it.
  2. After delivery, open the email in the test results and extract the raw headers. Look for the DKIM-Signature: field and inspect the b= parameter value—this is where base64 encoding must be strict.
  3. Verify that the b= value contains only valid base64 characters: A-Z a-z 0-9 + / =. Any space, newline, or invalid character breaks the signature and triggers rejection by receiving servers.
  4. Reproduce the issue locally using standard tools like RFC 6376, the official DKIM specification, to check if your signing process correctly encodes the hash output. This isolates whether the issue is in the signing library or configuration.
  5. Apply your fix—such as adjusting padding, stripping whitespace, or using a compliant DKIM signer—and rerun the test. Only after consistent successful verification should you deploy to live senders.

Why Real Testing Beats Simulations

Many DKIM issues stem from subtle encoding problems that only surface in real environments. Simulators often ignore line length or whitespace in b=. Real testing exposes these flaws under standards-compliant conditions.

Mail servers reject messages with malformed DKIM signatures—no matter how well-designed the rest of your email stack. A single invalid character in b= invalidates the entire signature, marking your message as untrusted.

According to RFC 6376, the b= tag must contain a base64-encoded string with no delimiters or formatting exceptions.

Testing before production is not optional—it’s essential. Use MailTester’s inbox placement service to catch header flaws early. This is the only way to ensure your DKIM signature is valid in the wild.

Fixing the Root Cause: Base64 Encoding Best Practices

You’re seeing DKIM b tag non-base64 characters because the signature value wasn’t properly encoded or the signing process introduced extra formatting. The fix is simple: canonicalize the message before signing, use trusted libraries like OpenSSL for signature generation, and ensure no extra whitespace or line breaks make it into the final 'b=' value. Always log the unsigned and signed output to confirm correctness before sending.

Canonicalize and Sign Properly

  • Always apply relaxed or simple canonicalization (RFC 6376) to your message headers and body before signing. Skipping this leads to inconsistent signatures across receiving servers.
  • Do not assume the order or spacing of headers is preserved after transit. Normalize all whitespace, collapse multiple spaces, and ensure line endings are LF (not CRLF or mixed).
  • Use established libraries to generate DKIM signatures. OpenSSL, OpenDKIM, and similar tools have been battle-tested for over a decade and avoid common encoding pitfalls you might not anticipate.

Verify Encoding Output

  • Never manually construct the 'b=' value. Let libraries handle Base64 encoding—rolling your own introduces subtle bugs like incorrect padding or stray characters.
  • Check that the raw value after 'b=' contains only valid Base64 characters (A-Z, a-z, 0-9, +, /, and = for padding). Extra spaces, newlines, or comments break the signature.
  • Log both the canonicalized message and the final signed header output. Compare them against known-good samples or use tools like MXToolbox's DKIM validator to confirm structural correctness.
  • Use MailTester’s email checker to validate the final email header structure before sending to real users. It flags malformed DKIM records and helps identify encoding issues early.
“The DKIM signature must match exactly what the receiving server computes. Even one extra space in the 'b=' tag will cause a failure.” — RFC 6376, Section 3.5

DKIM, SPF, and DMARC: The Triad of Email Authentication

You need all three—DKIM, SPF, and DMARC—to ensure your emails are trusted and delivered. DKIM signs the email content cryptographically to prove it hasn’t been altered. SPF checks that the sending IP is authorized by the domain’s published policy. DMARC uses both results to decide whether to deliver, quarantine, or reject the message, and collects reports on failures. Even if SPF passes, a broken DKIM signature can still cause DMARC to fail, blocking delivery.

How Each Protocol Works Together

DKIM protects the content integrity of your email. When you sign a message with DKIM, you add a cryptographic signature to the email headers. Receiving servers validate this by retrieving the public key from your domain’s DNS. If the content has been altered—even slightly—then the signature fails. This protects against tampering in transit.

SPF verifies that the sending IP address is on the approved list published in your domain’s DNS records. It doesn’t check the email body or headers, only the source. If an email comes from an IP not listed in SPF, it’s marked as unauthentic. SPF alone can’t verify the sender’s identity within the email; it only confirms the sending infrastructure.

DMARC ties both DKIM and SPF together. It defines what to do with messages that fail either check—deliver, quarantine, or reject—and sends reports back to you when a failure happens. You can’t rely on one of the three alone. A message passing SPF but failing DKIM will still be rejected under a strict DMARC policy.

When DMARC fails due to a broken DKIM signature, it’s often because of technical errors. For instance, a non-base64 character in the DKIM-Signature header—like a space, invalid symbol, or improperly encoded value—breaks the signature. These small mistakes make the signature invalid and cause receivers to reject the message, even if everything else looks correct.

Understanding how these protocols interact helps you debug issues like non-base64 characters. The key is to validate the entire DKIM header structure. Tools like MailTester’s inbox placement tests let you send real emails to major providers (Gmail, Outlook, etc.) and see whether authentication checks pass before delivery.

For developers, the DKIM standard (RFC 6376) and DMARC specification (RFC 7483) define exact syntax and expectations. Any deviation—like an extra space in a base64 string—triggers rejection. Double-check your signing process, especially around whitespace, character encodings, and header normalization.

Real-World Example: When 'b=' Contains Unexpected Characters

You see a DKIM signature like b=abc123==\nxyz in email headers? The newline and trailing xyz aren’t valid Base64—they signal that a script or tool improperly formatted the signature, likely by splitting output or appending text. Fix it by ensuring the final b= value is a single, compact Base64 string with correct padding and no embedded whitespace or extra characters. This is a common mistake when manually constructing or debugging DKIM signatures.

What the 'b=' Value Should Look Like

Valid DKIM signatures use a single, continuous Base64-encoded string after b=. There should be no line breaks, spaces, or appended text. For example: b=Abc123Def456==. Any deviation—like a newline or extra data—breaks the signature validation process. The DKIM specification (RFC 6376) defines strict formatting rules: only Base64 characters (A–Z, a–z, 0–9, +, /) and padding (=) are allowed.

Why It Happens: Common Causes

It often happens when tools or scripts process the signature but don’t strip newlines or buffer output incorrectly. For instance, a logging utility might dump intermediate output with newlines, or a custom script may use a line-based string builder without proper concatenation. This is especially common when developing or testing DKIM in non-production environments.

Even some older email clients or testing tools might mishandle newlines if they’re not stripped during header parsing. The DKIM RFC explicitly requires the b= value to be a single line without internal breaks.

Let’s say you’re debugging a batch of emails that fail DKIM checks. You inspect the raw headers and find b=abc123==\nxyz. That \n and xyz are red flags. You know you’re not supposed to see that—and you’re right. The digital signature is malformed. This isn’t a server issue. It’s a formatting flaw in the signature generation step.

Use a tool like MailTester’s inbox placement test to verify your DKIM signature in context. It checks not just the signature itself, but how it performs across real inboxes—helping catch these low-level formatting issues before they hit your campaign. Properly formatted DKIM increases inbox placement and avoids rejection from receiving servers.

How to Fix It

Ensure the signing script or library outputs only the raw Base64 string. Avoid splitting output. If you’re using a custom implementation, double-check that you’re not using a function that inserts line breaks or appends logs. Use a single, clean string before applying the b= tag.

For developers: always validate the final b= value against Base64 regex patterns (e.g. ^[A-Za-z0-9+/]*={0,2}$) and ensure no whitespace or newlines are present. Libraries like OpenSSL or well-tested DKIM packages handle this correctly—avoid rolling your own unless necessary.

Preventing Future DKIM Signature Issues

You can catch DKIM signature errors early by validating signatures in your outbound pipeline, testing domains in real inbox environments, auditing header logs, and monitoring DMARC reports. These steps help catch malformed headers—like non-base64 characters—before they affect sender reputation or deliverability.

Automate and validate DKIM signatures in your workflow

  • Integrate DKIM signature validation into your email-sending pipeline before delivery. Tools like the MailTester API can check for syntax errors, including base64 encoding issues, as part of pre-send verification.
  • Use an automated testing layer that validates the full DKIM-Signature header against RFC 6376 requirements, especially the base64 encoding of the signature value. A single non-base64 character can invalidate the signature.
  • Check domain alignment during each send, especially when using third-party services or templates that modify headers. Misaligned or malformed headers often go unnoticed until delivery fails.

Test in real inbox environments and monitor for changes

  • Regularly run inbox-placement tests using tools like MailTester’s inbox tester to see how your emails appear in actual client environments. These tests simulate real-world delivery conditions and flag header anomalies.
  • Review outbound header output during test sends. If you see non-base64 characters in the DKIM-Signature value (e.g., spaces, punctuation, or unencoded bytes), trace the issue to your signing process or template engine.
  • Enable and audit DMARC reports (via dmarc.org or your email provider’s reporting) to detect failed DKIM validations early. These reports highlight domains and senders with signature inconsistencies, often before bounce rates rise.
  • Set up alerts for DMARC reports that flag DKIM failures. Even one repeated failure can signal a configuration issue that impacts deliverability.
DKIM validation failures often stem from encoding errors rather than misconfiguration—base64 must be strictly applied to the signature and no other field.

Let’s be clear: no amount of monitoring works without consistency. The goal isn’t just detection—it’s prevention. Fixing a single malformed header won’t matter if the same flaw repeats. Automate checks, use real-world testing, and monitor logs—not just for bounces, but for subtle header missteps. Your sender reputation depends on it.

The Bottom Line: Keep DKIM Signatures Clean and Valid

A single non-Base64 character in the 'b=' tag of a DKIM signature breaks the signature entirely. Even a space, newline, or incorrect padding invalidates it.

This failure triggers DMARC rejection, harms sender reputation, and reduces inbox placement. No amount of correct SPF or domain configuration can compensate for a malformed DKIM signature.

Always validate DKIM outputs before sending. Use real-world testing with inbox placement tools and verified email verification services. Prevent issues before they impact your deliverability.

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 does 'b=' mean in a DKIM header?

The 'b=' field in a DKIM-Signature header contains the Base64-encoded digital signature of the signed email content.

Can spaces or newlines appear in the DKIM b tag?

No. The 'b=' value must be a single Base64 string with no whitespace, newlines, or extra characters.

Why does my DKIM signature fail DMARC checks?

DMARC fails when DKIM validation fails, often due to incorrect Base64 encoding in the 'b=' field.

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

Use MailTester’s inbox-placement test to send a message and inspect the raw headers for valid Base64 in the 'b=' field.

Can a custom script break DKIM encoding?

Yes. Custom signing logic without proper Base64 output handling can insert invalid characters into the 'b=' field.

Does MailTester check DKIM signatures?

Yes. MailTester validates DKIM signatures during inbox-placement tests and can flag non-Base64 characters in the 'b=' parameter.

How do I know if my email domain is deliverable?

Test with MailTester’s inbox-placement service to check SPF, DKIM, DMARC, and final inbox delivery.

What happens if DKIM is broken?

Emails may be rejected, marked as spam, or silently blocked—especially by providers with strict DMARC policies.

Should I manually test every email header?

No. Use MailTester’s real-time API or inbox tests to automate header analysis and detect issues at scale.

Is Base64 encoding mandatory in DKIM?

Yes. The DKIM standard requires Base64 encoding of the signature; any deviation breaks cryptographic validation.

Can a misconfigured email client cause DKIM errors?

Yes. Client-side tools or debug modes may insert malformed signatures with invalid characters.

Do all email providers check DKIM?

Most major providers (Gmail, Outlook, Yahoo) validate DKIM signatures as part of their spam and authentication checks.