Why Does the DKIM b= Tag Matter for Deliverability?

You send emails with DKIM enabled. Your DNS has the public key. But your messages still get marked as spam or rejected. Why?

Because the b= tag in your DKIM signature is missing, malformed, or not appearing at all in the email header. That tiny piece of data is the core of cryptographic verification. Without it, DKIM fails — no matter what your DNS says.

Think of the DKIM b= tag as the digital fingerprint on a sealed envelope. The envelope (your message) is sent with a key (published in DNS), but if the fingerprint isn’t applied correctly, the recipient can’t verify it was sent by you. Even one error in the signature string breaks trust.

Key takeaways

  • The DKIM b= tag is the cryptographic signature; its absence or corruption causes DKIM failure and harms deliverability.
  • DNS-published DKIM records alone do not guarantee success — the signature must be correctly generated and placed in the email header.
  • Malformed b= tags often result from incorrect header canonicalization, incorrect hashing, or improper key usage during message signing.

What Must Be in Place to Generate a Valid DKIM b= Tag?

You must generate a proper DKIM key pair (RSA 1024 or 2048 bits), place the DKIM-Signature header correctly with all required tags, include the b= tag with a base64-encoded signature of the full header and body, and ensure the d= and s= tags consistently identify the signing domain and selector. If any of these are missing or misconfigured, the b= tag fails validation.

  • Generate a cryptographic key pair using RSA 1024 or 2048 bits — smaller keys are insecure, and larger ones may not be supported by all receivers.
  • Place the DKIM-Signature header in the email’s raw headers, before the body starts; it must appear exactly once and follow the format defined in RFC 6376.
  • Include the b= tag with a base64-encoded digital signature derived from the canonicalized header and body content — any variation in whitespace or order invalidates the signature.
  • Set the d= tag to match the domain you claim to authorize (e.g., example.com); it must be the domain in the email’s From field.
  • Use a consistent s= tag (selector) that matches your DNS TXT record — a mismatch means the receiving server can't retrieve the public key to verify the signature.
  • Ensure the signing process applies canonicalization (relaxed or simple) consistently to both signing and verification sides.

Why Canonicalization & Field Ordering Matter

DKIM relies on predictable input. Even a single extra space, line break, or altered field order alters the hash — and thus the b= value. You can’t just “include” headers; they must be ordered and formatted per the canonicalization rules defined in RFC 6376. Most tools handle this, but custom implementations often fail here.

Testing & Validation

Don’t assume your DKIM signature works just because it’s there. Use tools that check both the full header and body signature. Even if the DNS record is correct, a single encoding error in the b= tag breaks verification. You can test your setup with a real email deliverability tester before sending to production lists.

For teams sending at scale, verifying DKIM structure is just one part of a broader deliverability workflow. Use inbox placement testing to confirm your email reaches inboxes — not just passes technical checks.

How to Verify Your Email Server Is Generating the b= Tag Correctly

Send a test email through your server to a verified inbox or testing tool, then check the raw headers. Look for the DKIM-Signature header containing a non-empty b= tag. Confirm it’s properly base64-encoded and mathematically matches the message body and headers. If the b= value is missing or malformed, your DKIM signing is broken — even if other parts of the signature exist.

Step-by-step verification process

  1. Send a test email from your server to a known address. Use a real, monitored inbox (like a personal Gmail or a mail testing service) to ensure you can access the full message. Avoid disposable or test-only addresses — they won’t reflect real delivery conditions.
  2. Access the raw message headers. In Gmail, click the three-dot menu and select “Show original.” In Outlook or other clients, look for a “View source” or “Show headers” option. Alternatively, use a tool like MxToolbox’s DKIM Validator to analyze the message from a remote server.
  3. Find the DKIM-Signature header. Search for a line that begins with DKIM-Signature:. It should contain at least three essential tags: v=1, a=rsa-sha256, and b=. The b= tag holds the actual cryptographic signature.
  4. Verify the b= value is non-empty and base64-encoded. The value must not be blank. It should consist of valid base64 characters (A–Z, a–z, 0–9, +, /, =). If it starts with b= and is followed by nothing, the signature failed.
  5. Confirm the signature matches the signed content. The b= value must reflect the signed headers and body (as defined in RFC 6376). Any change — even a single space — breaks the signature. Tools like MxToolbox or Ionos’ DKIM checker can validate this automatically.

Common issues and troubleshooting

If the b= tag is missing, your server isn’t signing messages at all. This often happens due to misconfigured DNS records, incorrect key placement, or a broken mail server integration. If b= exists but doesn’t match, the signature was computed incorrectly — usually because of header normalization issues, missing or extra whitespace, or a malformed key.

Always test with a known-good setup. Use a clean, minimal message with one recipient to rule out edge cases. If you’re still stuck, check your server’s signing logs or review the DKIM key’s DNS publication via a tool like MxToolbox’s DKIM checker.

For high-volume senders, automating header checks across sent messages is essential. You can use your existing verification infrastructure to validate deliverability and signing behavior at scale.

Common Causes of Missing or Invalid b= Tags

You might miss the b= tag in your DKIM signature if your email service or MTA isn’t properly configured to sign messages, if the DKIM module is missing or misconfigured, if a third-party delivery service strips or overrides the headers, or if the body is signed incorrectly due to missing or wrong canonicalization settings. These issues prevent receivers from validating your signature, leading to rejected or marked spam emails.

Configuration Issues in Your MTA or Email Service

If you're using Postfix, Sendmail, or Exim, a misconfigured DKIM signing process is one of the most common reasons the b= tag never appears. You might have the module installed but not enabled, or the key isn’t properly referenced in your MTA’s config. Let's be real: even a single typo in the DKIM signing table or missing SignHeaders directive can stop the signature from being generated at all. Always verify your MTA’s logs to confirm signing attempts are occurring. For context, RFC 6376 specifies the required structure of a DKIM signature header — deviating from it breaks validation.

When Services Override or Strip DKIM Headers

If you’re using a third-party service like a transactional email platform or a marketing tool, it may re-sign or strip DKIM headers entirely. Some providers automatically override signatures during delivery to enforce their own reputation, which nullifies your existing b= tag. This happens especially with providers that don’t support DKIM chain transparency. You should check if the service allows you to preserve original headers or offers a way to add your own signature. If not, your DMARC checks might fail, even if your server is technically compliant.

Another subtle but critical issue is body canonicalization. The b= tag value depends on the exact content of the signed body. If the MTA uses "relaxed" body canonicalization when your message uses "simple" rules — or vice versa — the hash will not match. The same goes for whitespace, line endings, or missing newline normalization. You can test this with a tool like DKIM Analyzer, which validates the full signing process. Always ensure your MTA uses consistent canonicalization settings across both header and body signing.

Want to check if a domain’s DKIM setup is working without sending a test email? Use our email checker to verify the full technical state of a recipient’s inbox setup, including DKIM headers and alignment. It’s a quick way to isolate problems before sending.

How MailTester Helps You Confirm DKIM Signatures Are Generated

You can verify that your email server generates valid DKIM signatures with the b= tag by using MailTester’s inbox-placement test. It sends real email through your configured system, then returns a full message header report showing the DKIM signature’s presence, structure, and correctness in real time. This includes checks for missing b= tags, malformed base64 encoding, or signature mismatches that could trigger rejection.

How the test works

  • Send a test email via your server or ESP (like SendGrid, Mailchimp, or Klaviyo) directly through MailTester’s inbox-placement tester to simulate real delivery.
  • MailTester captures the full header and parses the DKIM-Signature header line, validating every component including the b= tag.
  • It checks whether the b= value is present and properly base64-encoded—common issues include truncated or malformed signature values.
  • If the signature’s hash doesn’t match the content being signed, the test flags a mismatch, indicating a misconfiguration in your signing process.
  • It also confirms the selector, domain, and algorithm are correctly applied, based on RFC 6376, the standard for DKIM.

Scale verification across your email infrastructure

  • Integrate MailTester directly with your ESP or marketing platform via native integrations (SendGrid, Mailchimp, Klaviyo, HubSpot) for automated, continuous testing.
  • Run bulk tests on transactional or campaign sends to ensure consistent signing across all outbound mail.
  • Use the real-time verification API for programmatic checks on new domains or updated server configurations before full rollout.
  • Review the results in a structured report that shows exactly which emails passed or failed DKIM, along with specific error codes and remediation paths.

DKIM failures don’t always surface immediately—they can erode sender reputation over time. MailTester surfaces these issues before they cause inbox placement drops or rejection by major providers.

The Role of SPF, DKIM, and DMARC in Email Authentication

You can’t reliably ensure your email server generates DKIM signatures with a b= tag unless you understand how SPF, DKIM, and DMARC work together. SPF validates the sending IP, DKIM cryptographically signs the message to confirm it hasn’t changed and comes from you, and DMARC enforces policies based on SPF and DKIM results. Together, they reduce spoofing risk and signal trust to receiving servers.

How Each Protocol Works in Practice

SPF acts like a whitelist. It lists the IP addresses authorized to send emails on behalf of your domain. If your server’s IP isn’t in the SPF record, the receiving server may reject the message.

DNS-based Authentication, Reporting & Conformance (DMARC) is the enforcement layer. It tells receiving servers what to do if SPF or DKIM fail — such as quarantining or rejecting the message — and provides feedback on authentication results.

DKIM is the technical backbone of message integrity. Each email includes a digital signature (in the form of a b= tag in the DKIM-Signature header) that proves the content hasn’t been altered in transit. This isn’t just a check — it’s a cryptographic seal tied to your domain’s private key.

Real-World Impact on Deliverability

Spam and phishing campaigns rely on broken or missing authentication. According to research from the Internet Systems Consortium, unauthenticated messages are 25 times more likely to be flagged as spam.

When all three protocols are aligned and correctly configured, you improve your sender reputation. Major providers like Gmail, Yahoo, and Outlook use DMARC policies to decide how to handle your messages — especially in high-volume or transactional environments.

Even if your DKIM signature is present, incorrect setup (e.g., incorrect selector, misaligned domain, expired key) can render it ineffective. Tools like MailTester’s email checker can verify whether a signature is properly generated and aligned with the domain.

Protocol What It Confirms How It Works Impact on Deliverability
SPF Sending IP is authorized for the domain Checks the sending server’s IP against a TXT record in DNS Prevents impersonation; blocks unauthorized senders
DNSKEY (DKIM) Message content hasn’t changed and originates from the domain Signs email headers and body using a private key, verified with public key in DNS Proves authenticity; essential for message integrity
DMARC SPF and DKIM align; enforces policies for failures Uses policy records to define actions (none, quarantine, reject) when authentication fails Directs receivers on how to handle unauthenticated mail; enables reporting

Aligning SPF, DKIM, and DMARC isn’t optional. It’s standard practice for anyone sending email at scale. Misconfigurations are a top reason for poor inbox placement. Use tools like Bulk Email Verification to test sender policies across real domains before sending. That’s how you catch misaligned DKIM signatures or missing records before they hurt your reputation.

What to Do When Your DKIM b= Tag Fails Verification

If your DKIM b= tag fails, it means the signature couldn’t be validated against your public key. Start by confirming your DNS TXT record includes the correct selector, domain, and full public key. Check server logs for signing attempts. Use MailTester’s real-time API to test individual emails and capture exact failure details. Ensure every sent message includes a complete DKIM-Signature header with all required fields, especially b= and a=, as missing parts break validation.

Verify Your DNS Configuration

  1. Confirm the TXT record format matches the expected syntax: selector._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...". Use RFC 6376 as the authoritative reference for correct structure.
  2. Double-check the selector — it must match what your mail server uses when generating signatures. A mismatch means the receiving server can’t find the correct public key to validate the signature.
  3. Ensure the public key is complete — it must be in the correct format (Base64-encoded, no line breaks, correctly quoted). Partial or malformed keys cause signature validation to fail.

Test and Diagnose in Real Time

  1. Review your mail server logs for DKIM signing attempts. Look for entries indicating DKIM-Signature generation and any reported errors like "failed to sign" or "key not found."
  2. Use MailTester’s email verification API to send a test message and retrieve the full DKIM-Signature header with real-time feedback on the b= tag. This helps isolate whether the issue is in your server, DNS, or the message structure. Test individual messages with accurate, actionable insights.
  3. Confirm all required header fields are present in the final DKIM-Signature. The a=rsa-sha256 (signing algorithm), d=example.com (domain), and b= (signature) fields are mandatory. Omitting any breaks the validation chain.
Even one missing field in a DKIM-Signature header can cause rejection by receiving servers. Use tools that validate the full structure — not just the key.

Remember: DKIM validation failure isn’t always about keys. Sometimes it’s a missing b= value, incorrect selector, or truncated header. Fixing it requires checking both DNS and message-level headers. Use verified tools and real-world tests to confirm the fix works.

Proper Canonicalization: A Silent DKIM Success Factor

DKIM signatures fail silently if your server's canonicalization doesn’t match the receiving server’s verification process. Even with the correct private key and b= tag, mismatched header or body normalization—due to relaxed vs. simple mode differences—will invalidate the signature. The signing and verifying systems must agree on how whitespace, line breaks, and header order are handled before the b= tag is processed.

How Canonicalization Affects Signature Validation

When you sign an email, the body and headers are normalized using either simple or relaxed canonicalization. Simple mode requires exact formatting: every line break and space must be preserved. Relaxed mode, more common in practice, ignores minor variations—like extra spaces or carriage returns—allowing for legitimate formatting changes during transit.

Receiving servers apply their own canonicalization during verification. If your server used relaxed mode but the verifier expects simple, or vice versa, the normalized content won’t match—resulting in a failed b= tag check. This is not a key issue. It’s a process mismatch, and it’s often invisible unless you examine the full DKIM verification logs.

Why It’s Easy to Miss—and How to Fix It

Even experienced admins overlook canonicalization because the failure mode is subtle. The email might still deliver, but authentication fails. That hurts sender reputation over time, especially with strict filters like Gmail’s and Yahoo’s.

Let’s say your MTA signs with relaxed canonicalization but your DMARC policy expects strict alignment. The receiving server checks the DKIM signature, runs its own relaxed normalization, and finds a mismatch. The message may not be blocked, but it doesn't pass authentication—DMARC fails, and you lose trust.

Best practice: ensure your signing process matches the default behavior of your mail provider and common recipient systems. For most setups, relaxed canonicalization for both headers and body is the safest choice. Check your mail server documentation—for example, RFC 6376 defines the standard behavior for DKIM, including canonicalization options.

If you’re verifying the integrity of your email infrastructure at scale, tools like bulk email verification can help you catch deliverability issues early, including signs of malformed DKIM signatures resulting from misconfigurations like this. Proper canonicalization isn’t glamorous—but it’s essential.

Best Practices for Maintaining Reliable DKIM Signatures

You ensure your email server consistently generates valid DKIM signatures with the b= tag by rotating keys predictably, using documented selectors, validating changes before rollout, and monitoring for abrupt failures. These steps prevent delivery breakdowns and maintain sender reputation over time. Tools like MailTester can verify whether your signature configuration holds up under real-world conditions.

Key Actions to Sustain DKIM Reliability

  • Rotate DKIM keys every 90 to 180 days using a documented schedule. Avoid sudden key changes that break existing signatures; instead, transition by publishing both old and new keys in DNS for a grace period.
  • Adopt consistent selector naming—like mailchimp, sendgrid, or default—and tag them in internal records. This makes troubleshooting easier and ensures alignment across third-party platforms.
  • Test every change in your email stack—DNS updates, server reconfiguration, third-party migration—using a dedicated test environment or a high-volume sample before full deployment.
  • Monitor outbound email delivery logs for drops in DKIM validation rates. A sudden increase in 2.0.0 or 5.7.1 bounces may indicate signature misconfiguration or key expiration.
  • Verify that your b= tag contains a correctly signed, base64-encoded hash. Use open standards like RFC 6376 to validate the structure; tools like RFC 6376 detail the expected syntax.
  • Use real-world inbox placement testing to confirm that signed emails reach inboxes and aren’t blocked by spam filters. DKIM alone isn’t enough—deliverability depends on alignment with SPF and DMARC.

When Problems Arise

Even with solid practices, DKIM can fail due to configuration drift or DNS propagation delays. Catch issues early by setting up alerts for dropped delivery rates or failed validation checks.

For teams running high-volume campaigns, testing sender reputation and signature integrity at scale helps prevent long-term damage. You can validate your entire outbound stack’s health using an inbox placement tester before sending to large lists.

If you're not sure whether your current DKIM signature is being generated correctly, run a real-time test on a single address using our email checker. It will confirm validity, detect catch-all domains, and flag potential delivery issues before you send.

A Final Check: Is Your Email Server Really Generating b= Tags?

You can confirm your email server is generating the b= tag in DKIM signatures by sending a test email through MailTester’s inbox-placement tool and checking the raw headers. If the b= tag is missing, empty, or malformed, your MTA, server configuration, or delivery provider isn’t applying DKIM correctly. The fix starts with DNS, then moves to MTA logs and delivery tool settings.

How to Verify the b= Tag Is Working

  1. Send a test email via MailTester’s inbox-placement tester
    Go to MailTester’s inbox-placement test, send a message to a real recipient, and request the full headers after delivery. This simulates a real send and shows exactly how your server signs the email.
  2. Check the DKIM-Signature header line
    Look for a line starting with Dkim-Signature:. It should include several parameters, and critically, contain a b= parameter followed by a long, base64-encoded string. If the tag is missing or empty, DKIM failed to sign the message.
  3. Verify the b= value is not empty or placeholder
    A b= tag with only q= or == is invalid. Ensure the full signature is present and matches the content of the signed email. The b= tag must be derived from the canonicalized body and include the private key.
  4. Trace the failure: start with DNS records
    If b= is missing, check your DNS for correctly published DKIM records. The DKIM-Signature header includes a q=dns; t=s; tag. Verify your DKIM selector and domain match the record in DNS using tools like MxToolbox or RFC 6376.
  5. Review MTA logs and configuration
    Check your mail transfer agent (MTA) logs for DKIM signing events. Look for errors around key loading, canonicalization, or signature generation. Common issues include incorrect key paths, misconfigured signing policies, or use of an outdated signing algorithm.
  6. Confirm delivery provider settings
    If using a third-party service like SendGrid, Mailchimp, or Amazon SES, ensure DKIM signing is enabled on your account settings. Some providers require manual key generation and DNS verification before signing begins.

What to Do If the b= Tag Is Still Missing

If the b= tag doesn’t appear after checking DNS, MTA logs, and tool settings, the problem likely lies in how your server processes outgoing mail. This often means a misconfigured signing module, an unverified key, or a missing signing policy in your MTA configuration (e.g., Postfix, Exim, or Sendmail).

Conclusion: A Valid b= Tag Is Non-Negotiable for Inbox Delivery

DKIM is a foundational email authentication standard. Without a correctly generated b= tag, receiving servers cannot verify the message's origin, treating it as unverified or potentially malicious.

Even with flawless SPF and DMARC alignment, a DKIM failure will significantly reduce inbox placement. Mail servers prioritize authenticated messages, and a missing or invalid b= tag breaks that chain of trust.

Use MailTester’s real-time verification and inbox-placement tests to catch DKIM issues early. Validate your server’s signature generation before sending to large lists, and ensure your b= tag is present, correct, and cryptographically valid.

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 the b= tag in DKIM mean?

The b= tag contains the base64-encoded digital signature generated from the email’s content and headers using the private key. It’s used by receivers to verify authenticity.

How do I know if my server is signing emails with DKIM?

Check the raw email header for the DKIM-Signature line. Look for the presence of the b= tag and confirm it’s non-empty and properly encoded.

Can I test DKIM without sending real emails?

Yes, MailTester offers inbox-placement tests that simulate real delivery with full header inspection, including DKIM validation.

Why does my DKIM signature fail even with correct DNS records?

Common reasons include incorrect signing of the body or headers, incorrect canonicalization settings, or a misconfigured MTA dropping the signature.

Does DKIM require a specific email provider?

No, any system that supports signing email headers can implement DKIM. However, some providers may handle signing automatically.

How often should I rotate DKIM keys?

Best practice is to rotate keys every 6–12 months. Always update DNS records before expiration to prevent delivery failures.

Can MailTester detect if my DKIM b= tag is malformed?

Yes, MailTester validates the syntax, base64 encoding, and alignment of the b= tag in the header during inbox-placement testing.

What happens if DKIM fails on a message?

Receiving servers may mark the message as spam, reject it outright, or treat it as lower trust, reducing inbox placement and sender reputation.

Is DKIM required for all email sending?

It’s not enforced by law, but major providers like Gmail and Outlook require it for reliable inbox delivery, especially for bulk senders.

Does using a third-party service affect DKIM signing?

Yes — if the service overrides headers, signs differently, or strips DKIM, the original signature is lost or invalidated.

How do I fix a DKIM failure in Mailchimp or SendGrid?

Check the provider’s DKIM setup guide, verify the DNS record and selector, and use MailTester’s inbox test to validate the output.

Can I have multiple DKIM signatures in one email?

Yes, but only if different domains sign different parts. Multiple signatures from the same domain are redundant and uncommon.