What causes a DKIM b= signature Base64 decode error?

You sent a message. The recipient’s server says the DKIM signature is invalid. You check the logs. It fails on b= with a Base64 decode error. Not a typo in the selector. Not a missing key. Just a broken character somewhere in the signature field.

DKIM signs email headers using Base64 encoding to turn binary data into plain-text format. But the b= value must be strictly Base64—no newlines, no spaces, no control characters. Even one invalid character breaks decoding. The signature fails. The email gets rejected.

Key takeaways

  • A single non-Base64 character—like a newline, space, or tab—in the DKIM b= field will prevent successful decoding and cause signature verification to fail.
  • Common sources include misconfigured email servers, poorly written signing tools, or automated systems that modify headers without preserving Base64 integrity.
  • Validation must check both the syntax of the DKIM header and the raw content of the b= value for illegal characters during transmission or relaying.

How to identify a DKIM b= signature error in practice

You can identify a DKIM b= signature error by checking the email’s raw headers for the DKIM-Signature: header, specifically inspecting the value after b=. Look for invalid base64 characters or a “Signature verification failed” message in mail server logs. Tools like MxToolbox or Spamhaus can validate your DKIM record and help diagnose formatting issues in the signature. If the base64 string contains non-alphabet, non-digit, or non-“+”, “/” characters, it’s likely malformed.

Check the raw headers for the DKIM-Signature field

When troubleshooting, start with the email’s raw headers — they’re the most accurate source for diagnosing DKIM failures. Look for the DKIM-Signature: line and examine the value after b=. This value should be a base64-encoded string. If it contains characters outside the allowed set—like spaces, line breaks, or unencoded special symbols—it will fail verification.

Some mail clients or testing tools show a "b= signature base64 decode error" directly in the log. These are clear indicators. If the signature length is off or you see an error like “Invalid base64 characters,” the issue is almost certainly in how the signature was generated or encoded.

Use third-party tools to validate the DKIM record setup

Tools like MxToolbox (https://mxtoolbox.com/) or Spamhaus (https://www.spamhaus.org/) allow you to check your DKIM record configuration in real time. Enter your domain and verify the TXT record contains the correct format: selector._domainkey.yourdomain.com with a value starting with "v=DKIM1;".

These tools can also test if the signature itself is properly signed and base64-encoded. If the verifier reports “Invalid base64” or “Unable to decode,” the fault lies in the signing process—likely due to incorrect encoding, embedded newlines, or non-standard characters in the signature payload.

While MailTester doesn’t directly validate DKIM signatures, you can use our bulk email verification feature to catch invalid or low-quality addresses early. This doesn’t solve DKIM issues directly, but ensures your outbound emails aren’t sent to addresses that may be flagged due to poor sender reputation or formatting mismatches. A clean list reduces the risk of bounces and delivery problems that compound with DKIM failures.

Why invalid characters in DKIM b= break email deliverability

Invalid characters in the DKIM b= signature—like line breaks, non-base64 characters, or improper encoding—cause the receiving server to fail signature validation. Even if SPF and DMARC pass, a broken DKIM means the email’s authenticity can’t be verified, triggering spam filters and reducing inbox placement. You can’t rely on other authentication checks if the DKIM signature is malformed.

How malformed DKIM affects receiving servers

When a receiving server processes your email, it re-calculates the DKIM signature using the public key from your domain’s DNS records. If the b= value contains spaces, line breaks, or characters outside the base64 alphabet, the server fails the decode step and rejects the signature. This leads to immediate rejection or quarantine, especially in systems that enforce strict DKIM policies.

Major providers like Gmail, Microsoft 365, and Yahoo use DKIM validation as a core check. A failed signature doesn’t just mean a soft bounce—it signals potential spoofing or misconfiguration. Even a single instance can trigger rate-limiting or domain-level scrutiny, especially if repeated.

Why reputation and long-term deliverability suffer

If your DKIM signature fails consistently—due to coding errors, incorrect header signing, or bad signing tools—the domain is flagged as unreliable. Receiving providers accumulate these failures over time and lower your sender reputation.

According to the DKIM specification (RFC 6376), the b= value must be a base64-encoded string with no whitespace or line folding. If it’s not, the verification fails by design. This isn’t a quirk—it’s intentional for security. But it means one encoding mistake can tank your delivery even if your domain is otherwise legitimate.

Let’s say you’re using a third-party tool to sign emails. It might be adding a newline or failing to strip trailing spaces. Even small flaws like this become red flags at scale. If hundreds of your emails fail DKIM validation, inbound filters treat your domain as high-risk.

You can test this before sending. Use MailTester’s inbox placement tool to validate how your emails are treated across major providers. It simulates delivery and shows whether DKIM is being accepted—or rejected—by the receiving end. Fixing the b= signature before sending prevents unnecessary bounces and improves long-term sender health.

How to test if your DKIM signature contains invalid characters

You can confirm if your DKIM signature has invalid characters by extracting the full DKIM-Signature: header from a delivered email, pasting it into a Base64 decoder that shows parsing errors, and checking for hidden whitespace, line breaks, or non-Base64 characters. If the decoder fails, the signature is malformed.

Use real-world validation tools to verify integrity

  • Fetch the complete email header from a delivered message—ideally from the recipient's inbox or an email log.
  • Paste the DKIM-Signature: value into a Base64 decoder that highlights parsing errors, such as RFC 6376’s defined structure or a tool like base64decode.org.
  • Look for any signs of malformed data—unexpected characters like tabs, newlines, or spaces within the Base64 string.
  • Run the raw header through a command-line Base64 decoder (e.g. base64 -d on Linux/macOS) or via an API to catch hidden formatting issues that web tools may ignore.
  • Use MailTester’s inbox placement testing to replicate the email in real-world environments and verify signature alignment and header consistency across major providers.

Fix the signature at the source

  • Review your email infrastructure or mail server configuration—common causes include incorrect signing libraries, misconfigured email campaigns, or malformed header generation.
  • Ensure all encoded values in the DKIM-Signature: header are properly padded and use only Base64 characters: A-Z, a-z, 0-9, +, /, and = for padding.
  • Remove any unintended whitespace, especially between the header name and colon, or within the signature value itself.
  • Validate the entire header line using tools like MXToolbox’s DKIM validator to confirm alignment and formatting compliance.
  • After fixing, send a test email and repeat the process—signature integrity should now pass decoding and authentication checks.
Even a single misplaced character or newline can break DKIM validation, leading to authentication failures and delivery issues.

Step-by-step: How to fix DKIM b= signature invalid character errors

You’re seeing a DKIM b= signature base64 decode error due to invalid characters because the signature contains whitespace, line breaks, or control characters—often after signing, when a script or service reformats the output. The fix is to ensure the DKIM signing process produces a single, clean Base64 string with no post-processing interference. Validate with a known-good email and test the decoded output.

Diagnose the root cause

  1. Locate the DKIM signing source. This is usually your email server (e.g., Postfix, Exchange), a cloud email platform (SendGrid, Amazon SES), or a custom sending library. The error originates here, so you must verify where the signature is generated.
  2. Review post-signing processing steps. Any script, filter, or middleware that modifies the email headers after DKIM signing may insert line breaks, extra spaces, or carriage returns. These are not allowed in the b= field and break Base64 decoding. Check for tools that “format” or “pretty-print” headers.
  3. Confirm the signing library outputs clean Base64. Ensure the DKIM library or service emits a single-line, canonical Base64 string with no newlines or padding issues. Some libraries default to line-wrapping at 76 characters, which breaks DKIM validation. Disable any auto-formatting or wrapping.
  4. Test the output in a Base64 decoder. Copy the raw b= value from the email headers and paste it into a standard Base64 decoder. If it fails, the string contains invalid characters. Valid Base64 only includes A-Z, a-z, 0-9, +, /, and = for padding. Any other character means the signature is malformed.
  5. Verify with a test message. Recompile the signing step with the corrected output. Send a test email to a known inbox. Check the raw headers using RFC 6376 as a reference. Confirm the b= field is valid and passes DKIM checks in third-party tools like MXToolbox or MailTester’s inbox placement tester.

Prevent recurrence

Once fixed, document the correct signing logic. If you're using a platform like SendGrid or AWS SES, review their DKIM settings to ensure no post-processing is applied. For custom solutions, enforce strict output formatting in code—never assume libraries preserve Base64 integrity.

DKIM signatures must be syntactically correct per RFC 6376. Any deviation, including improper whitespace, breaks verification.

Use MailTester’s inbox placement tester to validate deliverability and DKIM alignment in real inboxes. This gives you a direct signal of whether the fix resolved the issue. You don’t need to trust the test—it confirms it.

How to prevent DKIM b= signature errors during email transmission

DKIM b= signature errors from invalid characters stem from malformed Base64 encoding, often due to manual changes, poor string handling, or incorrect header construction. To prevent this, never edit DKIM-Signature headers by hand. Use trusted libraries, validate input strictly, and avoid raw string concatenation. This keeps the b= value clean and ensures compliance with RFC 6376.

Don’t roll your own DKIM header edits

  • Never manually edit or reconstruct the DKIM-Signature header, even for debugging — even a single invisible character can break verification.
  • Use well-maintained email libraries like Node.js's mailcomposer or Python's email-validator that handle Base64 encoding correctly by default.
  • These tools enforce standards, including proper padding and character set restrictions, reducing the risk of invalid characters in the b= field.

Validate early, validate often

  • Before sending, scan all header fields—especially the dkim-signature header—for non-[A-Za-z0-9+/] characters. Tools like RFC 6376 specify the allowed character set.
  • Avoid string operations like concatenation or template stitching when building headers; these can introduce spaces, newlines, or control characters invisible to the eye.
  • Use a formal header parser on the final output to confirm the b= value only contains valid Base64 alphabet characters and proper padding.

Even tiny deviations—like a trailing space or an unescaped newline—can trigger a DKIM signature failure. It’s easier to prevent than to diagnose. If you're iterating on email delivery, run a DKIM and header validation test before sending to real inboxes. Catching issues early reduces bounce rates and protects sender reputation.

How MailTester helps catch and fix DKIM signature issues early

You can fix DKIM b= signature base64 decode errors by validating the full syntax of your DKIM signature before sending—MailTester’s real-time API checks the full SMTP and DNS alignment, including proper base64 encoding and header signing, so invalid characters or malformed signatures are flagged before you send. It’s not just about catching a single bad email; it’s about preventing send failures that harm your sender reputation.

Verify DKIM syntax before sending with the real-time API

Let’s say you’re setting up a new campaign and your DKIM signature is failing with a base64 decode error. The root cause might be a malformed b= value, like one containing spaces, missing padding, or invalid characters. MailTester’s real-time verification API doesn’t just check if an address exists—it validates the entire email’s technical stack, including DNS records, SPF alignment, and DKIM signature structure. If the signature isn’t properly base64-encoded, MailTester flags it with a clear error report.

This is where it differs from simple validity checks. Many tools only test if an email address is syntactically correct or exists on a mail server. MailTester goes further: it simulates the full delivery path and checks whether your DKIM signature passes standard validation—something required by industry-level email providers like Gmail and Outlook.

For example, if your signing algorithm or header list has off-by-one issues, the resulting base64 string may decode incorrectly. This can stem from a poorly formatted h= header list, mismatched line endings, or incorrect canonicalization. MailTester checks that all those components align properly against RFC 6376, the standard governing DKIM.

See the bigger picture with bulk and inbox-placement testing

When you run a bulk list verification, MailTester doesn’t just return “valid” or “invalid.” It surfaces patterns—like repeated DKIM failures or inconsistent header signing—across your list. If multiple emails from your domain show failed DKIM validation, it could mean your current signing setup is inconsistent or misconfigured, which damages your sender reputation.

Even more valuable: inbox-placement testing simulates delivery across 14 major email providers, including real-time checks of DKIM signature verification. You’ll see not just whether an email arrives in the inbox, but whether the signature was validated correctly. If it wasn’t, MailTester will show it—even before you send to thousands.

To test your sending setup in full, use the inbox placement tester or integrate the real-time API directly into your send flow. For teams managing high-volume campaigns, this stops problems before they start. And if you’re just getting started, try the email checker to validate single addresses with full technical validation, including DKIM alignment.

Unlike tools that only check syntax or deliverability, MailTester exposes the underlying technical failures—like invalid base64—which cause DKIM verification to fail. That’s what gives you a true signal about your sending health.

Common tooling pitfalls that inject invalid characters into DKIM b=

You’re seeing a DKIM b= signature base64 decode error because tools are altering the raw header text before signing — either by inserting newlines, adding whitespace, or embedding scripts that modify the content during merge. This breaks the precise byte-for-byte matching required by DKIM. The signature must be computed on exactly the same headers that are transmitted, and any change invalidates it. A RFC 6376 specification defines that the b= value must be a valid Base64-encoded string without embedded whitespace or line breaks.

Template engines that inject dynamic content without preserving format

Many email platforms let you use templates with merge tags or macros. If your system evaluates these during rendering and injects JavaScript, HTML, or custom formatting into the header fields (like From:, To:, or Date:), the DKIM signature is computed on a modified version of the original data. The result? Base64 decoding fails because the string now contains invalid characters or embedded newlines. Let’s say your template includes a {{user_id}} field; if it’s replaced with a value that includes spaces or line breaks, and that’s not escaped or normalized, the b= value becomes malformed.

Even well-intentioned debugging can break this. Some developers test templates by previewing them in visual editors that auto-format headers — adding line breaks or extra spaces between header fields. This doesn’t affect the final send if done correctly, but if DKIM is signed before that final cleanup, the signature will never match.

Third-party tools that re-sign or modify headers

Forwarding services and email routing platforms (like shared inboxes, autoresponders, or B2B integrations) often re-sign messages for authentication or tracking. If they don’t preserve the original header layout — especially if they split long header lines or insert new metadata — they alter the signed content. The Base64 string gets corrupted because the signature was computed on one version of the header, but the delivered version differs.

Log parsers and debugging tools also cause this. They often display headers with line breaks for readability — but those breaks are not safe. A tool displaying the DKIM-Signature: header with a forced newline inside the b= field (e.g., splitting long Base64 values) creates invalid input that fails to decode. This isn’t a flaw in DKIM; it’s misuse of the tools meant to inspect it. Always compare signatures using the raw, unformatted output.

If you suspect your DKIM b= value has been corrupted during tooling, run a real-time email verification with MailTester to test how your message is processed end-to-end before sending to a real inbox.

Best practices for maintaining a valid DKIM signature

Always sign your emails with a single, continuous Base64 string—no line breaks, spaces, or indenting. Use a well-tested DKIM library like OpenDKIM, AWS SES, or SendGrid’s built-in signing layer to ensure strict compliance with RFC 6376. Monitor your email logs daily to catch DKIM failures early. Keep your sender reputation healthy by validating that SPF, DKIM, and DMARC all pass in full.

How to avoid DKIM signature base64 decode errors

  • Never insert line breaks or whitespace in the DKIM signature’s b= value. The entire Base64 string must be a single, uninterrupted sequence.
  • Use established libraries like OpenDKIM or AWS SES’s built-in signing to avoid common formatting bugs—these handle encoding and signing correctly by default.
  • Validate your DKIM signature using tools like MXToolbox’s DKIM Record Checker or RFC 6376 to ensure compliance with Base64 encoding rules.
  • Test your signed emails in real inbox environments with inbox placement testing—tools like MailTester’s inbox placement tester show how your messages perform across real mail servers.

Proactive maintenance and sender reputation

  • Review your email logs every day. Even a single DKIM failure can trigger filtering or rejection over time.
  • Ensure SPF, DKIM, and DMARC are all aligned and passing. A single failure in any component can hurt deliverability.
  • Use a bulk email verification tool like MailTester’s email list verifier to remove invalid or non-reachable addresses before sending—this protects your reputation before you even send.
  • If you’re using a custom DKIM implementation, run it through a compliance checker. Many issues stem from incorrect canonicalization or improper header selection.
DKIM is only as strong as its implementation. A single misencoded character breaks the signature—and can be flagged by receivers as suspicious.

Why ignoring DKIM b= errors can harm long-term deliverability

Even a single broken DKIM signature with invalid characters in the b= parameter can signal weak sending hygiene to receiving servers. Over time, repeated failures — even when SPF and DMARC pass — erode sender reputation. Major providers like Gmail and Yahoo actively penalize senders with consistent cryptographic flaws, increasing the odds of inbox placement issues or throttling.

DKIM failures signal poor sending hygiene

Receiving servers don't treat DKIM signature issues lightly. When a b= value contains invalid Base64 characters, it breaks the cryptographic chain. This isn't just a technical hiccup — it suggests the sending infrastructure isn't validated or maintained properly. Even if the message passes SPF and DMARC, a failed DKIM reduces overall trust and increases the likelihood of spam filtering.

Let’s be clear: no major email provider treats DKIM as optional. A broken signature, especially one due to malformed Base64 encoding, is a red flag. According to the DKIM specification (RFC 6376), the b= tag must contain a valid, unpadded Base64-encoded signature. If it doesn’t, the verification fails, and the receiving server may reduce the message’s reputation score.

Impact on reputation and long-term deliverability

Consistent DKIM signature failures don’t disappear. They accumulate in sender reputation systems used by providers like Amazon SES, Microsoft, and Google. A history of cryptographic errors correlates strongly with lower inbox placement, higher spam filtering rates, and even temporary or permanent blocklisting.

Even if your messages still reach the inbox, a weak DKIM signature weakens your credibility. Major providers use this data in machine learning models that assess sender trustworthiness. If your sending pattern includes repeated invalid b= values, you may face throttling — reduced send volume per hour or day — without direct warning.

You can prevent this by validating your DKIM configuration before sending. Use a tool like MailTester's inbox placement tester to check how your messages are received across multiple providers, including their cryptographic validation results. It’s a practical way to catch issues like Base64 decode errors in real-world environments before they damage your sender reputation.

Summary: Fixing DKIM b= signature errors in 5 steps

DKIM signature errors due to invalid Base64 characters are often caused by formatting changes after signing. The root issue is usually a newline, extra whitespace, or non-Base64 character in the b= value.

1. Extract the DKIM-Signature header from a real message

Use a raw email dump (like from an email client or SMTP log) to locate the full DKIM-Signature: header. Ensure the line is complete and unaltered by email clients or parsers.

2. Validate the b= value with a Base64 decoder

Paste the b= value into a strict Base64 decoder. Any character outside the [A-Za-z0-9+/] set (like spaces, line breaks, or = padding errors) will cause decoding failure. Use tools like OpenSSL or online decoders with strict validation.

3. Audit your sending stack for post-signing modifications

Check if your email pipeline applies text formatting, line wrapping, or minification after signing. Some systems insert carriage returns or reformat headers, breaking the signature. This is common in legacy email tools and some content delivery networks.

4. Rebuild the signature with clean, single-line Base64

Resign the email using the exact canonical header structure, with the b= value as a single, continuous line. No spaces, no newlines. Validate that the output contains only Base64 characters and proper padding (=).

5. Verify success with real-world testing

Use MailTester’s real-time API to test a sample email. Confirm the DKIM signature is valid and the message passes inbox placement checks in multiple providers. Monitor logs for any new errors.

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 a DKIM b= signature error mean?

It means the signature's base64-encoded value contains invalid characters, such as newlines, spaces, or control symbols, preventing the receiving server from decoding it properly.

Can a single space in the DKIM b= value cause a failure?

Yes. Even one non-Base64 character, including spaces or line breaks, causes verification to fail because Base64 only accepts alphanumeric characters, '+' and '/' and padding '='.

How do I check if my DKIM signature is properly encoded?

Use a Base64 decoder on the b= value in your DKIM-Signature: header. If it fails, the string contains invalid characters.

Does DKIM fail if the signature has extra padding?

No — Base64 padding with one or two '=' characters is valid. Just ensure the total string contains only valid Base64 characters, no extra whitespace or newlines.

Can email service providers correct DKIM signature issues?

No. Providers do not modify your DKIM signatures. If a signature fails, the issue is on your side — either in the signing process or in post-processing.

How often should I check my DKIM signature integrity?

Check new implementations immediately. For ongoing sends, audit at least once per month to catch tool or configuration drift.

Why does my signature work in test environments but fail in production?

Production systems often apply extra header processing, routing, or logging steps that insert line breaks or whitespace into the b= value, breaking Base64.

Can MailTester detect invalid DKIM signatures?

Yes. MailTester's inbox placement testing and real-time API verify the full email structure, including DKIM signature validity, before sending.

What happens if my DKIM signature is invalid?

The receiving server cannot verify the message’s authenticity. This increases the chance of rejection, spam filtering, or reputation damage.

Is there a free way to test DKIM signature validity?

Yes. Use the free MailTester API to validate email headers and detect invalid DKIM signatures with 98.9% accuracy — 100 free verifications included.