Why DKIM b= Tag Shows Garbage Data After Email Authentication

Why does the DKIM b= tag show garbage data after email authentication?

You open an email’s raw headers and see a DKIM b= tag filled with what looks like random characters: q5X7kZ2LdFmPnQw.... You think, “Is this broken? Did my email fail?”

No. That “garbage” is actually a base64-encoded cryptographic signature. It’s not a message, not a bug — it’s the digital fingerprint of your email’s content, signed with your domain’s private key.

Understanding why the b= tag looks unreadable is the first step to diagnosing real authentication issues. If it’s malformed or missing, it’s a misconfiguration, not a protocol flaw.

Key takeaways

• The DKIM b= tag is a base64-encoded signature of the email’s content and headers, not human-readable text.
• Garbage-looking data in b= is normal — it’s cryptographic output, not an error.
• Malformed or missing b= values usually indicate a signing or DNS configuration issue, not a flaw in DKIM itself.

What exactly is the DKIM b= tag, and why does it appear as unreadable text?

The DKIM b= tag contains the cryptographic signature of your email’s headers and body, created using your private key and encoded in base64. This results in a long string of seemingly random characters — like 'xVq3ZaMj8eYkRnX9tH8K7zD12...' — which isn’t garbage. It’s a secure, standardized representation of signed data, designed to be verified by recipient servers using your public key published in DNS. If the math checks out, your email passes authentication.

The b= tag is a cryptographic signature, not content

Let’s be clear: you don’t read the b= tag. You don’t need to. It’s not meant for humans. It’s a digital fingerprint. The signer (your server) computes a hash of the email’s content and signs it with a private key. The resulting signature, encoded in base64, becomes the b= value in the DKIM-Signature header.

Think of it like sealing a letter with a wax stamp. The stamp proves it was sent by you and hasn’t been altered. But the stamp itself isn't the letter — it’s proof it’s unchanged. The b= tag is the same: it proves the email was sent by someone with access to your private key and wasn’t tampered with in transit.

How receivers verify the DKIM b= tag

When an email arrives, the receiver fetches your domain’s public key from DNS. It then re-computes the hash of the incoming email’s headers and body, using the same exact algorithm. It applies your public key to decrypt the b= signature and compares the result to the re-computed hash.

If they match, the email passes DKIM. If not, the email fails. This is how mail receivers determine authenticity. A mismatch — even a single character difference — breaks the signature. This is why any change to the email during transit (e.g., by a relay or filtering tool) typically invalidates DKIM.

For more on how to test your email’s authentication chain — including SPF, DKIM, and DMARC — check out our inbox placement testing tool, which simulates real-world delivery conditions: see how your message lands in real inboxes.

How is the DKIM b= value generated?

The DKIM b= tag contains a base64-encoded, private-key-encrypted hash of your email's canonicalized headers and body. It’s not garbage—it’s a cryptographic signature that proves the message wasn’t altered in transit. The value is generated by hashing selected parts of the email, encrypting that hash with your private key, and encoding the result. This process is standardized in RFC 6376.

The Step-by-Step Signature Process

1. Select headers to sign—Typically from, to, subject, date, and others. The choice affects whether the signature remains valid through forwards or email clients that modify content. Only headers explicitly listed in the DKIM-Signature header are included. You can’t sign every header, as it would break compatibility with some gateways.
2. Canonize the content—Spaces are normalized, line breaks standardized (CRLF to LF), and header fields stripped of excess whitespace. This ensures the same message always produces the same hash, regardless of formatting differences. Canonicalization prevents tampering from invalidating the signature.
3. Apply a hashing algorithm—A SHA-256 (or SHA-1, though deprecated) digest is computed on the canonized data. This creates a fixed-size fingerprint of the original content. If any part changes, the hash changes entirely.
4. Encrypt with your private key—The hash is signed using your domain’s private key. Only the corresponding public key (published in DNS) can verify this signature. This is the part that proves it came from you.
5. Encode in base64—The encrypted hash is converted into a string of readable characters for inclusion in the email’s DKIM-Signature header. This is the b= value you see. Base64 ensures safe transmission through systems that expect ASCII text.

Why You Might See “Garbage” or Inconsistent b= Values

It’s common for b= values to appear random or unreadable—because they are. The base64 output is intentionally opaque. If you see a mismatched or malformed b= tag, it’s likely due to one of three things: a misconfigured signature, a change in content between signing and delivery (e.g., routing through a third-party email service), or a misconfigured DNS public key.

MailTester’s email checker helps validate DKIM alignment and signature integrity by testing how your messages appear to receiving servers. Use it to catch alignment issues before sending to high-value recipients.

The full DKIM specification is available at RFC 6376. For reference, the Spamhaus DKIM guide explains how receivers validate signatures in practice.

What causes the DKIM b= tag to appear invalid or corrupted?

The DKIM b= tag shows garbage data when the signature verification fails due to mismatches in header selection, improper canonicalization, key mismanagement, or DNS configuration errors. These issues corrupt the hash computation, making the signed content appear invalid even if the email is technically sent. Let’s break down each root cause.

Header selection inconsistencies

• Some email systems include or exclude headers inconsistently during signing—like adding X-headers or omitting Received lines—leading to mismatched hashes.
• Let’s say your system signs only specific headers, but the recipient’s server checks a different subset. The resulting alignment failure shows up as corrupted data in the b= tag.
• Always verify the exact header set your signing tool uses; consistency matters. See the DKIM specification’s header canonicalization rules for standards.

Canonicalization errors

• Whitespace, line endings, and folded headers must be normalized before hashing. If you skip this step, the hash will differ between sender and receiver.
• Failing to apply the correct canonicalization (relaxed or simple) is one of the most common causes of b= tag corruption.
• Even a single extra space at the end of a line alters the digest. Use tools like MXToolbox’s DKIM debugger to validate alignment and normalization.

Key and DNS mismanagement

• Using the wrong private key or an expired key during signing means the public key won’t match—the signature fails silently and appears as garbage in the b= field.
• Typo in the DNS selector (e.g., “s=dkim” instead of “s=dmarc”) breaks lookup. Make sure your TXT record uses the exact selector and domain.
• Check your public key record with DKIMValidator to confirm it’s properly published and readable.
• Use MailTester’s email checker to validate the full email delivery path before sending, including DKIM consistency.

How can you verify if a DKIM b= tag is valid without manually decoding it?

You don’t need to decode the DKIM b= tag by hand. Instead, use a real-time verification tool that checks the public key, canonicalization, and signature against your DNS records. This process validates the entire DKIM chain automatically. For the most thorough test, send a real email through a service like MailTester’s inbox-placement tool to see if DKIM, SPF, and DMARC all pass together in a live inbox environment.

Use a real-time DKIM verifier

Manually decoding the b= tag is error-prone and time-consuming. A proper DKIM verifier checks whether the public key in DNS matches the signature, applies the correct canonicalization (relaxed or simple), and confirms the hash integrity. Tools like MailTester’s inbox-placement testing go beyond basic checks by simulating actual email delivery, validating the full stack of email authentication in a real-world context.

Test against known-valid configurations

If you’re unsure whether the b= signature is valid, compare your email headers to a known-good test case. Use a mail debugger like MxToolbox or the SendGrid debugger to analyze headers from a verified email. These tools show what an authentic DKIM signature should look like—including proper base64 encoding, correct hash length, and alignment with the verified public key.

DKIM validation isn’t just about the b= value—it’s about the complete chain: DNS records, header signing, canonicalization rules, and signature digest. Misconfigured or mismatched values will fail even if the b= tag seems plausible. For example, a relaxed header canonicalization must align with how the headers were signed. If they don’t, the signature is invalid even if the key and hash appear correct.

For teams sending at scale, running verification through an API like MailTester’s real-time verification API ensures every email meets authentication standards before it leaves your server. This prevents bounces, improves sender reputation, and keeps you off blocklists. Authentication failures don’t just cause delivery issues—they can silently damage long-term deliverability, especially when the b= tag is incorrectly generated or altered in transit.

Remember, a valid DKIM signature must be verifiable by any receiving server. That means the public key, the signing algorithm, and header order must all be correct. If you’re seeing garbage data in b=, it often means the signature was not validated—or worse, it was tampered with. The only way to be sure is to check the full stack, not just the result.

Why does MailTester help resolve confusion around DKIM b= values?

You see a garbage b= tag in a DKIM signature and wonder if your email is failing auth. The truth is, b= alone tells you nothing—it’s just a base64-encoded digest that looks random if the signature is malformed, expired, or misaligned. MailTester goes beyond parsing that string: it validates the full DKIM signature in real inbox conditions, detects failures at the root—like key misconfiguration or canonicalization errors—and gives you clear, actionable feedback, not just a broken tag.

DKIM b= is just one piece of the puzzle

Many tools only check if the b= tag exists or is syntactically valid. That’s not enough. The real test is whether the receiving server can verify the signature using your public key. If the key is wrong, expired, or the email was altered in transit, the signature fails—and b= will look like garbage because the digest itself is invalid. This is where MailTester differs: it performs a complete, real-world validation of the entire DKIM verification chain.

It checks whether the key is published correctly in DNS, whether the signing domain matches the from address, and whether the header/body canonicalization aligns with the receiving server’s expectations. These are all common causes of "garbage" b= values you see in tools that only parse the signature. Using the DKIM specification, MailTester simulates how actual mail servers behave, catching issues that basic string parsing misses.

Real-world validation, real clarity

MailTester doesn’t stop at the b= tag—it confirms if the signature was generated correctly in the first place. For example, if a sending server uses a key with a 2050 expiration date but the receiving server has a 2025 cutoff (common in some enterprise setups), the signature will fail even with a valid-looking b=. MailTester identifies that as an expiry issue, not a parsing error.

It also detects common problems like improper header or body canonicalization—where spaces or line endings are altered mid-route, breaking the digest. These issues don’t show up in a simple b= inspection but will still cause rejection. With MailTester, you get a detailed breakdown: “DKIM verification failed: body canonicalization mismatch” instead of just “invalid signature.”

If you're testing DKIM signatures before sending, try the real-time email verification API or run bulk checks with the bulk list verification tool. These tools simulate inbox behavior across major providers, giving you a clear picture of what really happens when your email lands in a user’s inbox. The 98.9% accuracy means you get results you can trust—no guesswork, no false positives.

What’s the difference between a DKIM failure and a b= tag showing 'garbage'?

The b= tag showing "garbage" is normal—it's just base64-encoded data. The real test is whether the DKIM signature validates against the public key in DNS. A failure means the signature doesn’t match after decryption and hash comparison, indicating a problem in the signing setup or DNS configuration. If b= is missing, malformed, or the hash doesn’t match, the email is rejected or flagged as unauthenticated by the receiver.

Understanding the b= tag and what “garbage” really means

When you see a b= value like z4kRv5mGjP2QwX8uYkL1nZsOaVbCpDxXeFgHjI, it's not corrupted data. It's simply base64-encoded binary data representing the signed portion of the email. This encoding is standard in DKIM and widely used across email systems. You’ll see similar output in tools like MxToolbox or RFC 6376, which defines the DKIM signature format.

Distinguishing valid signatures from verification failures

Let’s break down what each state means in practice:

Don’t confuse the b= value’s appearance with failure. The real signal is whether the receiving server can verify the signature using the public key published in your domain’s DNS record.

Let’s say you’re using a transactional email service: if your DKIM sign is off, even slightly—like a single header being added after signing—the verification fails, regardless of how “clean” the b= string looks. That’s why proper signing, consistent header inclusion, and valid DNS records are essential.

Before sending, use a tool like MailTester’s email checker to validate your DKIM and overall email setup. It tests the full path—from DNS to delivery—so you can catch issues before they affect your sender reputation.

How to test your DKIM configuration in practice?

You can verify your DKIM setup by sending a test email to a MailTester inbox through your email service, then using the in-app AI assistant to analyze the full headers. It will show if your DKIM signature passes or fails, with specific error details like "signature mismatch" or "selector not found" — confirming whether your domain alignment is correct or needs fix.

1. Send a test email to a MailTester inbox using your email service (SendGrid, Mailchimp, etc.). The MailTester inbox is a real destination that captures full headers and authentication results, mimicking an actual inbox environment. This gives you a live snapshot of how your email is authenticated in transit.
2. Access the full email headers in your MailTester account. Once delivered, open the email and click "View Full Headers" — this exposes the raw authentication data processed by receiving servers. You’ll see the DKIM signature, selector, and alignment results.
3. Use the in-app AI assistant to parse and analyze the headers. It automatically detects the DKIM b= tag and checks its validity against the public DNS record. The assistant surfaces clear verdicts like DKIM: Pass or DKIM: Fail, listing specific issues such as signature mismatch or selector not found — critical for troubleshooting.
4. Check for garbage or invalid data in the b= tag. If you see unexpected or malformed values in the DKIM b= tag, it usually means the signing process is misconfigured. The DKIM signature must be a base64-encoded hash of the signed headers and body. Invalid output typically stems from incorrect signing algorithms, missing or malformed includes, or incorrect selector alignment.
5. Use the bulk verification API to test multiple domains for consistent DKIM alignment. The MailTester API allows you to validate thousands of addresses on a domain, confirming DKIM consistency across large lists. This helps catch misconfigurations that might only show up under volume.

Why the b= tag can appear garbled

The DKIM b= value is derived from a cryptographic hash of the email’s content and headers, signed with your domain’s private key. If the signing software fails — due to encoding errors, mismatched canonicalization, or incorrect key usage — the resulting value becomes meaningless. This isn’t a defect in the receiving server, but a flaw in the sender’s implementation.

According to RFC 6376, the b= tag must be a properly base64-encoded string. Any deviation breaks the signature validation. MailTester’s header analyzer ensures you catch these errors before they trigger deliverability issues.

Why is DKIM critical for deliverability—even when the b= tag looks strange?

DKIM is essential for deliverability because email providers use it to verify that your message hasn’t been tampered with in transit. Even if the b= tag appears garbled or contains unexpected characters, a valid DKIM signature still proves authenticity and boosts inbox placement. Skipping DKIM risks your emails being flagged as spam—or rejected outright, especially from new or unverified domains.

The real job of DKIM: trust, not perfection

Let’s be clear: the b= tag isn’t meant to be readable. It’s a cryptographic hash that verifies the integrity of the email’s body and headers. What matters isn’t the appearance of the tag—it’s whether the signature matches the published public key. Providers like Google, Yahoo, and Microsoft rely on this check to determine whether your domain is trustworthy.

Without a valid DKIM signature, providers assume the message could be forged or altered. This applies even to well-written, permission-based emails from new domains. You might send thousands of messages with perfect content, but missing DKIM means your reputation starts at zero—and your inbox placement rate suffers accordingly.

How DKIM impacts sender reputation and deliverability

A consistent, correctly configured DKIM signature signals that you’re serious about email hygiene. Providers use this as a baseline signal for sender reputation, especially when other data points (like engagement, spam complaints, or sending volume) aren’t yet available.

If a provider detects a message from a domain with DKIM but the signature fails, it’s a red flag. If there’s no DKIM at all, the email often gets filtered into spam or blocked entirely. This is especially true for new senders, where DKIM can be the difference between deliverability and obscurity.

Even if your b= tag looks like random data, that’s normal. As long as the signature is cryptographically valid and matches the DNS record, it’s working as intended. The real issue isn’t the tag’s appearance—it’s whether the verification process completes successfully. You can check this before sending with tools that validate DKIM configurations.

Use MailTester’s inbox placement testing to see how your emails perform across major inboxes, including whether deliverability issues stem from missing or broken authentication like DKIM. For bulk lists, ensure every address has a valid signature using bulk email verification, which checks for authentication alignment and other deliverability risks.

For more context on how email authentication works, refer to the original DKIM standard on IETF’s site.

Can you manually decode a DKIM b= tag to see the actual content?

No, you cannot manually decode a DKIM b= tag to see the original email content. The value is a cryptographic hash of the email’s headers and body, signed with the sender’s private key. Without that key and the exact original message, reverse-engineering the hash is computationally infeasible. Tools claiming to “decode” it are either simulating a result or misrepresenting the process.

Why the b= value is not human-readable

DKIM was designed to verify message integrity, not reveal content. The b= tag is a base64-encoded hash—specifically, the output of a SHA-256 or SHA-1 digest over selected headers and body parts. You can’t reverse this because hashing is a one-way function. Even with the full email, you’d need the sender’s private key to validate the signature, not decode the data.

Let’s say you have an email from [email protected], and its DKIM signature includes b=4QZmXyvW7pLr2KsM5qJnD7iB0RdN3eGhQfRtS8uVv4K=. The only way to confirm this signature is valid is to use the sender’s public key (published in DNS) and recompute the hash using the known header and body. If the result matches the b= value, the message is intact. But you can’t extract the original content from that hash alone.

What happens when tools claim to decode DKIM

Some online tools advertise “DKIM decoder” features. In reality, they don’t reverse the hash. Instead, they simulate a valid signature given the public key and a test message—often using a precomputed example or placeholder data. These tools don’t show the real content; they show an artificial reconstruction. Their output isn’t what the b= tag was generated from—it’s an approximation of a valid signature under specific parameters.

For a true verification of email authenticity, you need access to the sender’s SPF, DKIM, and DMARC records—verified through DNS. Real-time email verification services like MailTester check all three. If an email’s b= value is missing or malformed, it may indicate a delivery issue. Use an email checker to validate addresses and catch authentication errors before sending.

The b= tag exists to protect the integrity of your message—not to be read. Its value is a digital fingerprint, not a message container. RFC 6376, the DKIM standard, confirms that the signature must be validated using cryptographic functions, not reverse interpretation. You’ll find the full specification at RFC 6376.

How does MailTester improve DMARC compliance when DKIM shows issues?

DKIM’s b= tag often displays unreadable or garbled data because it contains a base64-encoded signature. This is normal — the value itself isn't meaningful to humans. The real issue is whether the signature validates against the public key.

MailTester checks DKIM, SPF, and DMARC alignment as a full stack. It doesn’t just report "DKIM failed" — it shows why, whether the key is missing, malformed, or misaligned with the sending domain. When DMARC requires a DKIM pass but the signature fails, messages are rejected. MailTester identifies these gaps before they impact deliverability.

It also simulates real-world inbox behavior, testing how a message lands in major providers’ inboxes. If DKIM is broken, MailTester flags the specific misconfiguration — like an incorrect selector or a mismatched domain — and suggests actionable fixes. This prevents DMARC failures from harming sender reputation.

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)
• After Gmail began requiring authentication for large senders, the number of unauthenticated messages Gmail users received plummeted by 75%. — Google (The Keyword blog) (2023)

Keep reading

• Email authentication: SPF, DKIM, DMARC, BIMI and MTA-STS (complete guide)
• SPF Verification Fails Due to TXT Record Size Too Large for DNS
• Why SPF Fails with Include Directives on Hidden Domains
• SPF include policy fails due to DMARC alignment enforcement
• SPF exp tag URL must use HTTPS to avoid email rejection

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Is the DKIM b= tag supposed to look like random characters?

Yes. The b= tag is a base64-encoded hash of the email content. What appears as 'garbage' is the expected, secure output of the signature algorithm.

Can a DKIM b= tag still be valid if it’s very long or short?

Yes, as long as the signature is properly generated and matches the public key. Length varies based on the hashing algorithm and canonicalization.

Why does my DKIM signature fail even if the b= tag looks correct?

The b= tag may look valid, but a failure occurs if the canonicalization doesn't match, the key is incorrect, or the DNS record is misconfigured.

Can MailTester verify DKIM without sending an actual email?

No. DKIM requires a live email to generate a signature that can be verified. MailTester uses actual test emails to simulate inbox behavior.

Does a valid DKIM b= value mean my email will land in the inbox?

Not necessarily. DKIM is one factor. SPAM scores, sender reputation, and content quality also determine inbox placement.

Why does MailTester offer real-time DKIM verification?

Because automated checks in isolation don't catch misconfigurations. Real-world testing with live send validates the full chain of email authentication.

How often should I test my DKIM setup?

After any change to your email infrastructure—new domain, new email service, or updated DNS records—run a test immediately.

What happens if DKIM fails but SPF passes?

The email is authenticated, but not fully compliant with DMARC if DMARC requires both DKIM and SPF. This may lead to delivery issues.

Can a role email address (e.g. info@) pass DKIM authentication?

Yes. DKIM validates the signature, not the email address type. Role addresses can authenticate successfully if the domain signs properly.

Do disposable email domains ever pass DKIM?

Some do if they sign emails—but they often fail other checks like sender reputation or spam filtering. MailTester flags these during inbox testing.

Is it safe to include DKIM records in public DNS?

Yes. The DKIM public key is designed to be public. The private key must remain secure. Publishing the selector and public key is required.

Can DKIM be forged or broken?

Only if the private key is compromised. Otherwise, DKIM is cryptographically secure. No known practical method exists to forge a signature without the key.