DKIM Failure Due to Trailing Whitespace

Why Does a Single Space After the DKIM b= Tag Break Authentication?

You sent an email, everything looked correct, yet it ended up in spam or got rejected. No bounce message—just silence. You checked your DNS, your SPF, your DKIM selector. You even ran it through a verifier. The signature passes. But the receiving server still fails validation.

Here’s the silent killer: one trailing space after the base64-encoded value in the DKIM b= tag. A single character. But because DKIM signatures are strictly base64-encoded and validated, that space breaks the hash. The receiving server sees a mismatch. Authentication fails. You’re not sending malformed email—your tools just missed this edge case.

DNS and SPF are the guardrails. DKIM is the signature—signed with strict rules. According to RFC 6376, section 3.4, the b= tag value must be a valid base64-encoded string with no extraneous whitespace. A single space at the end, even in a test environment, breaks the signature hash.

Key takeaways

A single trailing space in the DKIM b= tag value causes a signature hash mismatch and authentication failure.
DKIM signatures are base64-encoded and validated strictly—whitespace outside the encoding is not permitted.
RFC 6376, section 3.4 explicitly prohibits whitespace in the b= tag value; this is a well-documented edge case in email authentication.

How Common Is This Issue in Production Email Systems?

This issue is rare in well-maintained production systems but shows up consistently during DKIM audits, especially in custom-built or automated email tools. It's typically the result of untrimmed whitespace in the b= tag during signature generation, often from scripts that concatenate strings without normalizing whitespace. Many senders only discover it after a major provider flags the message as "DKIM verification failed" in a bounce.

Why It Appears (and Why It's Hard to Catch)

Let’s be honest: this isn’t a flaw in the DKIM standard itself. It’s a subtle implementation error. The problem arises when a signing script builds the canonicalized header and body text using string concatenation—especially in languages like PHP, Python, or JavaScript—where trailing spaces in a raw string get carried forward. The RFC 6376 specification doesn’t tolerate additional whitespace in the b= tag, but human error or lazy string handling does.

It’s not widespread across enterprise systems because mature email platforms usually test their output against known validators. But it frequently surfaces in smaller senders, marketing tool integrations, or self-hosted systems that skip formal testing. The issue often slips through because DKIM checks are not always part of routine email validation, especially in older or poorly documented pipelines.

When It Surfaces in Practice

Most senders only learn about it the hard way—after a batch of emails bounces with a DKIM failure message, or when their domain starts showing up in deliverability alerts. Major providers like Gmail, Yahoo, and Microsoft do not give detailed reason codes in bounces, so the root cause can be misdiagnosed as a broken DNS record or misconfigured signature.

According to the IETF RFC 6376, the b= value must be exactly as computed, with no leading or trailing whitespace. A single space outside that value breaks the signature verification, even if everything else is correct. This makes it a critical validation point during email sender audits.

Tools like MailTester’s email checker can surface this issue early, even before sending, by validating the full signature structure during a real-time verification test. If you’re building or maintaining an email system, it’s worth testing your DKIM output against known validators—especially when integrating third-party tools or rolling your own signing logic.

What Does a DKIM Signature Look Like in Real Mail Headers?

DKIM signatures appear in email headers as a series of key-value pairs starting with DKIM-Signature:. A valid one includes fields like v=1, a=rsa-sha256, d=example.com, and a b= value containing the actual cryptographic signature. Even a single invisible trailing space after the final character in the b= field breaks the signature validation, making the email appear forged—even if the rest is correct.

Real-World Examples of Valid and Failing DKIM Signatures

Let’s look at a fully valid DKIM-Signature field from a real message:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=brisbane; bh=QwRdFtGvYh3uLmKqXpZjHlI9sTf2PqZ7RbXcYdE5N8o=; b=Ko5tQ9Y2X8WZ7NkFpQsA3LwVbD1UqXwE6mV7Y3HxTgRyDcF7MkLhWpXZrQ9nSbKmGvPnHqT4P8uIwHtZcR1sEhJqWvN0kA==

This is compliant with RFC 6376 and will pass validation if the public key is correctly retrieved and the signature matches the computed hash.

Now, the same signature—but with one extra space at the end of the b= value:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=brisbane; bh=QwRdFtGvYh3uLmKqXpZjHlI9sTf2PqZ7RbXcYdE5N8o=; b=Ko5tQ9Y2X8WZ7NkFpQsA3LwVbD1UqXwE6mV7Y3HxTgRyDcF7MkLhWpXZrQ9nSbKmGvPnHqT4P8uIwHtZcR1sEhJqWvN0kA==

That space is invisible to the human eye. But it alters the signature’s byte stream. DKIM verifiers compute the expected signature hash based on the full header content—every character matters. The mismatch causes validation to fail, marking the email as potentially forged. This is the exact reason a DKIM signature validation failure due to trailing whitespace in b= tag occurs.

How to Prevent This in Practice

Trailing spaces in headers often come from misconfigured email software, copy-paste errors, or buggy SMTP libraries. Some tools don’t normalize whitespace before signing. The fix isn’t to ignore it—it’s to catch it early. You can verify the full header structure, including DKIM fields, using inbox placement testing to simulate real-world delivery environments.

For developers and senders, validating DKIM signatures manually or via automated tools before sending is essential. Tools like MailTester’s real-time email checker can assess syntax correctness, including DKIM-related anomalies, before you send. It won’t just flag invalid addresses—it helps catch hidden issues like malformed headers that silently break authentication.

How to Validate DKIM Signatures in Real-Time to Catch This Issue

You can catch DKIM signature validation failures due to trailing whitespace in the b= tag by parsing raw email headers accurately, validating the full base64 signature string without trimming, and ensuring no post-processing alters whitespace during signing. Real-time systems must treat the DKIM-Signature header as a literal string—any normalization or trimming breaks validation, even with a correct cryptographic hash.

Key Steps to Catch Trailing Whitespace Errors

Use a tool that parses raw email headers without auto-stripping or canonicalizing whitespace, especially in the b= tag value. Even a single trailing space can invalidate the signature.
Extract the entire Dkim-Signature: field as-is—do not parse fields individually unless you preserve the raw string exactly as received.
Verify the full base64-encoded signature length and content before any hash computation. A mismatch here means validation will fail, even if the signing key is correct.
Validate that the signing process doesn’t sanitize or normalize whitespace. Some libraries or frameworks automatically trim headers—disable this behavior or handle raw strings manually.
Test with real-world headers from your mail server logs using a tool that mimics how receiving servers process DKIM, including strict RFC 6376 compliance.

Why This Matters

DKIM signature failures often go unnoticed until emails are rejected or marked as spam. According to RFC 6376, the signature must be verified exactly as transmitted—no modifications allowed. Even a single trailing space in the b= tag is a valid reason for rejection.

Tools like MailTester’s email checker process raw headers and validate DKIM signatures in real time, catching these subtle issues before messages are sent. You can integrate the real-time verification API into your outbound workflow to catch signature issues across large lists.

Let’s be clear: this isn’t about missing a field or wrong key—it’s about the exact string matching. If your system trims whitespace, you’re breaking DKIM.

DKIM validation fails if the canonicalized input doesn’t match the one used in signing. A single character error breaks the chain.

Automated testing with real-time tools reduces the chance of delivery failure due to parsing or canonicalization errors. You don’t want to spend time debugging why a valid key isn’t working—because the signature string was altered.

Step-by-Step: How to Check for Trailing Whitespace in a DKIM b= Tag

You can diagnose a DKIM signature validation failure caused by trailing whitespace in the b= tag by first extracting the raw DKIM-Signature header from a delivered email, then carefully inspecting the value assigned to the b= tag. If it ends with a space, line break, or tab, that invisible character can break verification. Use a hex viewer to confirm; re-sign the message after trimming the extra space, and retest.

Extract and Isolate the DKIM b= Tag

Fetch the raw email header from your mail server logs or an email client with a "show original" or "view source" option.
Locate the DKIM-Signature header. It typically starts with v=1; and contains fields like a=rsa-sha256, d=example.com, and b=...;.
Copy the entire b= value exactly as it appears, including spaces, line breaks, and any other characters at the end.

Inspect for Invisible Characters

Examine the final character of the b= value. A trailing space, newline, or tab may be invisible but will prevent DKIM verification.
Use a hex or ASCII viewer — tools like RFC 6376 explains that DKIM signature values must be strictly formatted, and even minor deviations break validation.
If the last character is non-printable, remove it. Re-sign the message using your email system’s DKIM module, ensuring no extra whitespace is appended.
Send a test message and validate the new signature using a tool that checks headers in real time, such as MailTester’s inbox placement tester.

Trailing whitespace is a common but easy fix. Since DKIM validation is strict, even one extra space at the end of the b= field will result in failure. This is especially important if your mail server or third-party service auto-generates signatures — some systems, like older versions of SendGrid or custom SMTP setups, don’t normalize newlines in base64 output. Double-checking the signature in hex form prevents hours of confusion when bounces start appearing.

The 3 steps described in “Extract and Isolate the DKIM b= Tag”, in order.

Even a single trailing whitespace in the b= tag can cause DKIM validation to fail, as per the formal specification in RFC 6376.

Use a consistent process: extract, copy, validate, fix. Once confirmed, you can integrate the fix into your email workflow. For teams sending at scale, use MailTester’s email verification API to catch invalid or misconfigured addresses before send, and to test delivery reliability across inboxes.

Why Some Email Verification Tools Miss This Issue

Many email verification tools only check basic syntax—like whether an address looks like an email—without validating the cryptographic integrity of DKIM signatures. A signature with trailing whitespace in the b= tag may pass as "valid" even if it fails to verify during actual delivery. Only full end-to-end email delivery testing can expose these hidden flaws.

Most Tools Stop at Syntax

Too many services treat email validation as a check for format correctness: does it have an @, a domain, etc.? They don’t simulate real delivery, so they miss issues that only show up during SMTP handshake and cryptographic validation. A DKIM signature with a single trailing space isn’t technically invalid by syntax rules, but it breaks verification in practice.

Let’s say a tool says the signature is “valid”—it might have parsed the b= tag just fine. But if that tag ends with a space or newline, the cryptographic hash won’t match. That’s a silent failure, and it can lead to emails being rejected by receiving servers even if the address exists and is otherwise legitimate.

Only Real Delivery Testing Finds It

SMTP-level checks with live servers are the only way to catch this kind of defect. Tools that use only DNS, domain reputation, or pattern matching can’t simulate the actual signature verification process. This is why even high-accuracy providers miss it—because they don’t reach the layer where DKIM is actually validated.

For example, the DKIM specification (RFC 6376) requires strict parsing of the b= tag. Whitespace at the end of the base64-encoded signature is not allowed and will cause validation to fail. But many tools assume “it parses” means “it’s usable,” which is incorrect.

This is where full inbox placement testing—like the kind offered by MailTester's inbox tester—provides real value. It doesn’t just scan a list or check syntax. It sends a real email and verifies whether the entire chain—from DNS records to cryptographic signature—passes in the wild.

Can You Test DKIM Signatures in a Test Environment Before Sending?

You can test DKIM signatures in a real-world simulation before sending by using tools that validate all authentication headers—including base64-encoded bodies—during delivery. Syntax-only checkers miss hidden errors like trailing whitespace in the b= tag, which breaks validation even if the rest of the signature appears correct. Only testing with a live email delivery simulator catches these issues.

Simulate Real-World Server Behavior

DKIM is designed to validate in production environments, where mail servers enforce strict header parsing rules. Tools that simulate actual recipient servers—like MailTester’s inbox placement test—parse and verify the full header, including the b= value, as it would be processed in the wild. This includes detecting subtle formatting mistakes such as extra spaces after the final character in the signature.

For example, a DKIM signature with trailing whitespace like b=abc123... def456 (with a space before the closing bracket) will fail verification on most mail servers, even though it might pass a basic syntax checker. The same applies to line breaks in base64 data that aren't properly encoded. These are not syntax errors per se, but encoding violations that affect validation.

Why Syntax-Only Validators Fall Short

Many online DKIM checkers only validate the format of the header—checking that the DKIM-Signature: field contains the right tags and structure. They won’t decode the base64 content or validate whether the signature aligns with the actual email body and headers, which is how DKIM actually works.

According to RFC 6376, the b= tag must contain a properly padded base64-encoded hash. Any deviation—such as improper line wrapping, extra whitespace, or incorrect padding—renders the signature invalid. This is why you need a tool that performs full header and body validation during delivery simulation.

Let's be clear: the only way to truly test DKIM is to send a message in an environment that mimics real recipient processing. That’s why MailTester’s inbox placement test lets you send a real test email to an isolated receiving server where all authentication mechanisms—including DKIM—are evaluated exactly as they would be in production.

Test DKIM and other email authentication headers in a controlled environment before sending to real users. You’ll see exactly how recipient servers interpret your message, including any signature validation failures caused by whitespace or encoding issues.

How MailTester Helps Detect This Issue in Bulk Deliverability Tests

MailTester’s inbox placement tests analyze full email headers, decoding DKIM signatures to catch subtle validation failures like trailing whitespace in the b= tag. This ensures your messages pass technical checks before hitting inboxes, preventing silent drops due to parsing errors. You can run bulk tests across dozens of domains to spot systemic issues early.

Real-time DKIM header analysis

MailTester parses every incoming email header in real time during inbox placement tests, including full DKIM signature decoding.
It validates the b= tag content exactly as receivers do, flagging any non-compliant formatting—like trailing whitespace after the signature.
Unlike basic list cleaners, MailTester doesn’t just check syntax; it simulates the actual receiving server’s validation logic.

Bulk detection of systemic issues

Use MailTester’s inbox placement tests to run hundreds of tests across different domains or campaigns in one batch.
If multiple emails fail DKIM validation due to identical whitespace issues, MailTester surfaces this pattern—helping you identify a flawed mailer or automation process.
Such failures are common in systems that generate signatures programmatically without trimming output—MailTester detects them before they trigger sender reputation penalties.
According to RFC 6376 (the standard for DKIM), the b= tag must not contain leading or trailing whitespace, and servers enforce this strictly [RFC 6376, Section 4.2].
Fixing these issues during testing avoids delivery failures, improves inbox placement rates, and preserves sender reputation.

Whitespace in DKIM signatures might seem minor—but even a single space after the b= tag can cause a validation failure. MailTester catches it before your email gets rejected.

Best Practices to Avoid This Issue in Future DKIM Signatures

Always trim input strings before base64 encoding in your DKIM signing process, use a vetted library instead of handrolling signatures, and validate outputs with tools like OpenSSL before sending. This prevents silent failures like trailing whitespace in the b= tag — a common cause of DKIM validation errors that can break email deliverability without warning.

The Root Cause: Whitespace in b= Tags

DKIM signatures are base64-encoded. Even a single trailing space in the value being encoded can corrupt the signature. When the receiving server decodes a b= value with extra whitespace, the resulting hash no longer matches the original, and DKIM fails. This isn’t a misconfiguration — it’s a flaw in payload construction.

RFC 6376 (the DKIM specification) mandates strict formatting. Any deviation, even non-visible characters, can invalidate the signature [RFC 6376, Section 3.5]. This is why input sanitization is not optional — it's required.

Trim all input strings before base64 encoding — ensure no whitespace, newlines, or invalid characters exist in the header field values or signature components during construction.
Use a dedicated DKIM signing library — libraries like node-dkim, dkim-signer, or Python’s dkimpy handle encoding and formatting correctly. Avoid rolling your own string manipulation.
Validate signatures before sending — use OpenSSL’s openssl dgst or a tool like MXToolbox DKIM Validator to test raw signatures against known headers.
Test in a staging environment — always send test messages with generated DKIM headers to a private inbox or sandbox tool like MailTester’s Inbox Placement Test to catch validation mismatches early.
Log and audit generated signatures — store a copy of every DKIM signature in your logs for later debugging — including the exact input and encoded value.

Common Pitfalls to Avoid

Many developers assume they’re encoding correctly if the b= value looks right in a raw email. But base64 encoding is sensitive. A single space at the end of a value becomes a different byte sequence.

Even if your code works today, changes to libraries, frameworks, or email service providers may expose formatting flaws. Automated validation is the only way to catch this before production sends fail.

Let’s be clear: this isn’t about being “careful.” It’s about building systems that self-validate. Tools like MailTester’s email checker can help catch syntax issues early by validating individual addresses and their associated domains — a layer that complements but doesn’t replace proper DKIM construction.

What to Do When This Error Occurs in a High-Volume Send

If your high-volume email campaign is failing DKIM signature validation due to trailing whitespace in the b= tag, stop sending immediately. Even one malformed signature can trigger filtering at major providers. Review all templates with autodrafted signatures, inspect your DKIM generator’s output, and verify real-time email integrity using a trusted tool like MailTester’s API before resuming.

Immediate Actions to Prevent Further Damage

Pause the current campaign. Don’t risk sending more emails with invalid DKIM signatures. Every message that fails DKIM checks can degrade your sender reputation, especially at providers like Gmail and Outlook that prioritize authentication.
Review all recent templates using autodrafted signatures. These often include dynamic content that can accidentally append whitespace—particularly in signature blocks. Look for spaces after closing tags, newlines, or hidden characters in templates.
Audit your DKIM signature generator. Many tools generate the b= tag value by concatenating parts from the signed email. Ensure it doesn’t preserve trailing spaces, line breaks, or formatting artifacts. This is a known issue in poorly implemented DKIM generators RFC 6376 outlines the exact syntax for the b= value, including the need to preserve canonicalized content.

Verify Signature Integrity in Real Time

Use MailTester’s API to test sample sent messages. You can send a few recent emails from your campaign to the API and check if the DKIM signature passes validation. This catches issues like trailing whitespace before they reach inboxes or trigger blocklists.
Validate the output before deploying fixes. Patch your template or DKIM setup, then re-test with the API. This ensures the root cause—whitespace in the b= tag—is resolved before sending to full lists.
Re-enable sends only after full verification. Don’t rely on post-send reports. Use real-time testing to confirm integrity. Tools like MailTester offer direct checks of email headers and signatures, ensuring your outbound messages meet standards Spamhaus warns that authentication failures are among the top reasons for email rejection.

Let’s be clear: a single whitespace character in a DKIM signature breaks the verification chain. It’s easy to miss in code but visible in raw headers. If you're managing bulk sends, don’t wait for bounces. Use MailTester’s real-time verification API to test your email outputs before they leave your server—before they damage your reputation.

Final Reminder: A Single Space Breaks Crypto, Even If You Don’t See It

DKIM signature validation is exact. Even a single trailing space in the b= tag alters the cryptographic hash, causing verification to fail. Invisible characters are not tolerated, regardless of how they appear in your email client.

This error is simple to fix once identified, but nearly impossible to spot with casual inspection. It requires testing under actual delivery conditions, including parsing full email headers and validating the raw signature.

Don’t rely on basic syntax checks. Use tools that validate the full email envelope and headers, simulating real-world recipient behavior. Real deliverability depends on real integrity, not assumptions.

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 exactly causes a DKIM validation failure due to trailing whitespace?

A single space after the final character in the b= tag results in a base64-encoded signature that doesn't match the expected hash, causing validation to fail even if other aspects are correct.

Can trailing whitespace in the b= tag be detected by email clients?

No — email clients only display the message. The failure only appears in mailbox server logs or bounce messages from receivers like Gmail or Outlook.

Is this issue only found in custom email-sending scripts?

Yes — it typically emerges from manual or scripted DKIM signature generation, not from email platforms like SendGrid or Mailchimp that handle signing internally.

Does MailTester detect DKIM issues like trailing whitespace?

Yes — MailTester’s inbox placement tests include full header parsing and DKIM signature validation, flagging malformed b= tags.

How can I verify if my DKIM signature is valid before sending?

Use a tool like MailTester’s real-time API or inbox placement test to simulate delivery and validate all email authentication fields, including exact signature content.

Does every DKIM failure point to whitespace in the b= tag?

No — reasons include mismatched private keys, expired timestamps, or broken domain alignment. The b= tag issue is specific and common, but not the only cause.

Is there an RFC that covers this whitespace limitation?

Yes — RFC 6376, section 3.4, specifies that base64 values in DKIM signatures must not contain extraneous whitespace.

Why do automated tools miss this problem?

Many only validate DNS records or syntax. They don’t decode the full signature or check for invisible characters in the base64 string.

Can this issue affect sender reputation?

Yes — repeated DKIM failures can trigger spam filters, leading to lower inbox placement and potential sender reputation damage.

Should I remove the b= tag entirely to fix failures?

No — that breaks DKIM entirely. Instead, ensure the value is base64-encoded and trimmed of any trailing whitespace.

How often should I test my DKIM signatures?

Test every time you update your sending infrastructure or modify your email templates, especially when using automated signing.

Are there free tools to test DKIM signatures?

Yes — tools like MxToolbox and Google’s Email Security Test can verify DKIM records, but they don’t test the full delivery behavior. For real-world validation, use MailTester.