DKIM b= tag missing despite permitted

Why does MailTester say DKIM is permitted when the b= tag is missing?

You send a test email, check the DKIM result in MailTester, and see “permitted” — but the b= tag isn’t there. Why? It’s not a bug. It’s by design.

DKIM isn’t just about whether a specific message contains a signature. It’s about whether the domain’s configuration allows signed messages to be accepted at all. MailTester checks the DNS record — not the message body — to confirm that the domain is set up to validate DKIM correctly.

Think of it like a security gate. The gate is open (permitted), even if no one has passed through it yet. The absence of the b= tag in one message doesn’t mean the gate is broken. It just means that specific message didn’t carry the tag — not that the policy isn’t valid.

Key takeaways

MailTester evaluates DKIM policy based on DNS records, not the presence of the b= tag in individual messages.
A ‘permitted’ status means receiving servers will accept DKIM-signed mail from the domain, regardless of whether a particular message includes the b= tag.
Missing b= tags in test messages do not indicate an invalid DKIM configuration — they reflect message-level transmission issues, not domain policy.

What does the b= tag in DKIM actually do?

The b= tag in DKIM holds the cryptographic signature of an email’s headers and body, verified by the recipient’s server using your domain’s public key. Without it, DKIM validation fails—even if your DNS records allow signing. It’s the core proof that the message hasn’t been tampered with and genuinely came from your domain.

How the b= tag works in practice

When you send an email, your sending system generates the b= signature using your private key, which is stored in your domain’s DNS records. This signature covers the specific content and headers of the message—any change to the email alters the signature, making it invalid. The receiving server then fetches your public key from DNS, recalculates the expected signature, and compares it to the b= value in the message.

It’s a binary check: if the signatures match, DKIM passes. If they don’t—usually because b= is missing or malformed—the message fails verification. This is why even a small tweak in your email content or MIME structure can break DKIM if not handled properly.

Why a missing b= tag breaks DKIM

If your MailTester DKIM test shows "permitted" but the b= tag is absent, the issue isn’t your DNS. It’s the signing process. The domain may be set up to sign messages, but the sending infrastructure—your email service, mail server, or app—failed to generate the signature at send time.

This often points to misconfigured SMTP clients, incorrect library usage, or third-party email tools not applying DKIM correctly. It’s not a DNS issue. It’s a software or integration flaw.

Check your email provider’s DKIM setup guide—or use MailTester’s inbox placement test to simulate real-world delivery and catch missing b= tags before they hurt deliverability.

For development teams, validating DKIM signatures with tools like RFC 6376 is standard practice. The b= tag is required in all DKIM-signed messages. If it’s not present, the signature is invalid by design.

Let’s be clear: having DNS records that permit signing doesn’t mean emails are signed. The b= tag must be generated during send. If it’s not—whether due to code error, config oversight, or tool misintegration—the signature fails, and your message risks being flagged as spam.

Use MailTester’s real-time verification API to catch such issues early: verify individual addresses or bulk-validate lists for missing or broken DKIM data, especially before sending campaigns.

How does MailTester's DKIM test differ from a real email delivery test?

MailTester’s DKIM test checks your domain’s public DNS record to verify the signing key is published correctly — it does not send an email. This means it can confirm the existence and format of your DKIM record, but not whether the b= tag is actually generated during message transmission. Only a live email delivery test, which includes the full envelope and header injection, can confirm that the b= tag is applied in real time.

What MailTester’s DKIM test actually checks

When you run a DKIM test on MailTester, it performs a passive lookup of your domain’s DNS records. It verifies that a valid DKIM TXT record exists and contains the correct syntax, including the selector and public key. This is an essential first step — without a properly published record, DKIM will fail even if your sending system is correctly configured.

It’s like checking if a lock exists on a door before trying to use it. You can’t test the lock’s function without trying to lock it, and similarly, you can’t test whether DKIM signing is working unless the message is sent through the actual delivery path. MailTester’s DNS-level check gives you peace of mind that the infrastructure is in place, but not that it’s being used.

Why a real delivery test is needed

The b= tag is part of the DKIM-Signature header that gets generated when a message is sent — not at DNS lookup time. This signature is based on the content and envelope info at the moment of sending. Without sending a real email, there's no way to know if this value is being generated correctly.

For example, a mail server might be configured with the right public key in DNS but fail to sign messages due to misconfigured software, incorrect header ordering, or a broken signing pipeline. That’s why tools like MailTester’s inbox-placement test simulate a full sending session, including envelope details, headers, and actual delivery via third-party mail servers — giving you the real-world confirmation that b= tags appear during transit.

For a full picture of your sender health, pairing DNS checks with live testing is ideal. You can verify DKIM setup in minutes using our email checker, then follow up with a delivery simulation using our inbox placement test to see how your message behaves in real inboxes.

As outlined in RFC 6376, DKIM’s effectiveness depends on both proper DNS configuration and correct signature application during transmission — the two are not interchangeable. RFC 6376 makes clear that verification must include both the key and the live signing process to be valid.

What should you check if the DKIM record is present but b= is missing in your emails?

If your DKIM record is published but the b= tag isn’t appearing in delivered messages, your email provider isn’t signing messages with DKIM—despite the DNS record being present. This means the signing process isn’t being triggered in your sending infrastructure. Verify that your ESP or email platform is set to sign outbound emails and that the private key is active and correctly applied. Check delivery logs to confirm whether DKIM was attempted but failed.

Check your email service provider (ESP) or sending platform

Log into your ESP (like SendGrid, Mailchimp, or Amazon SES) and confirm DKIM signing is enabled for your domain.
Some providers, like SendGrid, require a separate DKIM key setup beyond DNS configuration.
Check if your sending domain is correctly assigned to the DKIM key in the platform’s settings.

Review infrastructure and transaction flow

Verify that your SMTP transaction path includes a DKIM signature step. Misconfigurations in relay chains or third-party gateways can strip or skip signing.
Look for logs showing DKIM is attempted but fails—common when the private key doesn’t match the public key in DNS.
Ensure the private key used to generate the b= tag is securely stored and properly integrated into your sending system.

Diagnose common failure points

DKIM signatures are generated by the sending system using a private key and added during the SMTP transaction. If the key is outdated, corrupted, or not loaded, no b= tag appears. The DKIM specification defines that the signature must be included in the message headers under DKIM-Signature:. If it’s absent, the domain’s DKIM policy—no matter how correctly configured—is never enforced.

Use tools like MXToolbox DKIM Checker to test if signatures are being applied at delivery. Compare public key matching with actual message headers.
Check your mail logs for DKIM: none or DKIM: fail indicators during delivery.
If you're using a custom SMTP setup, inspect your email server configuration (e.g., OpenDKIM, Postfix) to ensure signature generation is active and not disabled by filters.

Let’s be clear: a correctly published DKIM record does not mean DKIM is working. You must validate that the signature is actually being applied at send time. A missing b= tag is a red flag for sending setup failure—no matter how clean the DNS looks.

How to confirm your email is actually signing with DKIM before sending

You can verify your email is properly signing with DKIM by sending a test message to a mailbox that shows full headers—like Gmail’s “Show original”—and checking for the DKIM-Signature header. Make sure the b= tag appears, which contains the actual signature. Compare this with your published DNS record to catch mismatches before they cause deliverability issues. Use tools like MailTester’s inbox-placement test to catch problems early.

Step-by-step verification process

Send a test email using your actual sending system—not a third-party tool or mock client. This ensures the signing process reflects real-world conditions.
Open the message in Gmail and select “Show original” to view the full raw message headers. This reveals all authentication headers, including DKIM.
Look for the DKIM-Signature header—it’s typically a long string starting with v=DKIM1;. If it’s missing, your email isn’t signing with DKIM.
Confirm the b= tag is present and properly formatted. The b= tag contains the signed hash. Its absence means the signature was not created or was stripped by a relay.
Compare the b= hash in the header with your published DNS record. Use a DKIM verifier tool (like dmarcian.com’s DKIM checker) to validate the public key alignment.
Check for alignment between the d= tag and your domain. The domain in d= must match the From domain and the selector in the DNS record.
Use MailTester’s inbox-placement test to see how your message fares in real inboxes. The test includes header analysis and shows you if your DKIM setup holds up under real conditions. Test your email in real inboxes before sending to live lists.

Why mismatches matter

Even if your DNS record is correct, the b= tag might be absent due to misconfigured signing keys, email routing via a third-party service, or message tampering during transit. A missing or mismatched b= tag triggers rejection or spam filtering by receivers such as Gmail, Yahoo, and Microsoft. This is not a configuration issue you’ll see in a test tool unless you inspect headers directly.

Industry standards like RFC 6376 define how DKIM signatures must be structured. When b= is missing or malformed, the signature fails validation. The only way to detect it before a campaign fails is by inspecting headers in a real message flow.

Why does a ‘permitted’ DKIM status in MailTester not guarantee successful inbox delivery?

Just because MailTester shows a DKIM status of “permitted” doesn’t mean your email will land in the inbox. That result only confirms the receiving domain allows DKIM signing—nothing more. If the actual email message lacks the required b= tag during delivery, DKIM fails, and your message may be filtered, delayed, or rejected. Authentication checks are just one part of inbox placement. Sender reputation, content quality, engagement signals, and proper alignment across SPF, DKIM, and DMARC all matter.

DKIM “permitted” ≠ DKIM actually applied

MailTester’s DKIM test checks your domain’s DNS records for alignment with the signing domain, and yes—finding a valid DKIM record means the domain permits signing. But that’s not the same as confirming your email server signed the message. No signature in the email header? No b= tag? Then DKIM validation fails, regardless of DNS configuration.

Let’s say you’ve set up DKIM correctly in DNS but forgot to enable signing in your ESP. MailTester sees the record, says “permitted,” and that’s it. But your outgoing email? It lacks the actual cryptographic signature—so it fails at delivery. This means even a clean DNS record won’t prevent delivery issues if the signing step is missing in practice.

Inbox placement depends on more than just a single check

DKIM validation is only one of several checks email providers use. According to industry standards, inbox placement is influenced by multiple factors: sender reputation, authentication alignment (SPF, DKIM, DMARC), email content quality, and recipient engagement patterns like opens and clicks.

Even with all three authentication methods passing, a high volume of spam complaints, a weak sender reputation, or content that triggers spam filters can still result in a message landing in the junk folder. That’s why tools like MailTester are used as a first line of defense—they catch the obvious failures, but they don’t see the full picture of how your domain is perceived in the wild.

You can run a successful DKIM test and still face delivery issues. That’s why it’s critical to use tools like our inbox placement tester to simulate how your email lands across real inboxes, not just DNS records.

What happens when DKIM signature is missing on an email?

If a receiving server enforces DKIM strictly and the email lacks a valid signature, it will likely be rejected outright. Even if the server allows delivery, mailbox providers may flag the message as spam or place it in the junk folder—especially if other signals like SPF, sender reputation, or content quality are weak. Over time, sending large volumes of unsigned emails harms your sender reputation, and repeated failures can lead to domain-level reputation penalties or blacklisting.

How strict is DKIM enforcement in practice?

Most major inbox providers—like Gmail, Outlook, and Yahoo—perform DKIM validation as part of their inbound filtering. While not every bounce is immediate, a missing DKIM signature reduces the trustworthiness of the sender. The absence of the b= tag in a DKIM test result, as seen in some MailTester reports, typically means the signature was not generated at all or was malformed. If DKIM is part of your email infrastructure, this is a technical failure, not a configuration nuance.

As outlined in RFC 6376 (the standard for DKIM), the b= tag is required for a valid digital signature. Without it, the signature is invalid or missing. Receiving systems either reject the message or apply additional scrutiny. According to industry guidelines published by the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), improperly signed or unsigned emails are more likely to be quarantined.

What are the long-term consequences for your domain?

When a domain consistently sends emails without valid DKIM, its reputation suffers. This isn’t just about one bounced message—it’s about cumulative signals. High-volume senders with repeated DKIM failures trigger automated reputation systems used by providers and feedback loops. Once marked negatively, it becomes harder to deliver to inboxes even after fixing the signature.

Let’s say you’ve built a large email list but never validated it. Some addresses may be outdated, role-based, or set to reject signed messages. Others may be set up as catch-alls, which often skip DKIM checks entirely. If your setup lacks verification, you might unknowingly send to hundreds of invalid or insecure receivers—each failure adds to your sender score. A tool like MailTester’s bulk verification checks for these issues before a single email is sent, including DKIM signature presence, catch-all status, and overall deliverability risk.

If your DKIM test shows "permitted but b= tag not present," it’s not a minor glitch—it’s a red flag. The signature failed to generate. You need to check your email service provider’s DKIM setup, ensure your domain is properly configured, and verify your sending domain through tools like MailTester’s inbox placement test to confirm if your messages are now being accepted and seen.

Can a domain be DKIM-permitted but still fail on some receiving servers?

Yes — a domain can pass DKIM validation in DNS but still fail delivery on certain receiving servers, especially when alignment fails or the b= tag is missing or malformed. Even with correct signing, some providers enforce strict policies that reject messages where DKIM doesn’t align with the From domain or where the signature is technically incomplete. This isn’t a flaw in your setup — it’s a reality of inconsistent receiver behavior.

Why DKIM-permitted doesn’t mean universally accepted

DKIM checks against the domain in the DKIM-Signature header, which can differ from the From domain. Many receivers now enforce *alignment*, meaning the signing domain must match the From domain — commonly called SPF/DKIM alignment. If it doesn’t, even a valid signature may be rejected.

Receiving servers also validate the b= tag, which contains the actual digital signature. If the tag is absent, malformed, or uses an unsupported algorithm, delivery can fail — even if the DNS record is correct. This isn’t a rare edge case; it’s a common source of silent bounces.

Testing the real-world delivery path is critical

Just because your DKIM works in a validator doesn’t mean it will pass on Yahoo, Gmail, or Outlook. These services use proprietary filtering systems that may reject messages based on signature structure, alignment, or reputation — even if all technical checks pass.

Using a tool like MailTester’s inbox placement test reveals exactly how your email performs in real inboxes, including how receiving servers interpret your DKIM signature. This goes beyond DNS checks and catches failures before they impact your campaign results.

For developers and senders, testing across multiple receivers is not optional. Real delivery behavior varies, and issues like missing b= tags or weak alignment are often invisible until you test with actual email clients. Bulk verification can identify invalid or poorly signed addresses early, reducing delivery risk.

DNS setup is only part of the picture. The receiving end interprets your signature differently than a test tool. The best defense is testing real deliveries before sending — not just validating syntax.

How to fix a missing b= tag in emails sent through your system

If your MailTester DKIM test shows "permitted" but the b= tag is missing, your email is technically signed but likely not properly authenticated. This can hurt deliverability. Confirm your email service provider has DKIM enabled, the key is correctly published in DNS, and no signing errors occurred in your sending system. You must verify each step in the chain to ensure the signature is fully generated.

Check DKIM configuration at your email service provider

Confirm DKIM is enabled on your ESP (e.g., SendGrid, Mailchimp, Klaviyo). Many providers require manual activation. Disable any auto-detection or fallbacks that may bypass DKIM signing.
Verify the sending domain matches the DKIM selector. The selector in your DNS record (e.g., selector1._domainkey.yourcompany.com) must align with what your ESP uses. A mismatch breaks the signature chain.
Ensure your DKIM public key is correctly published in DNS. Use tools like MXToolbox or RFC 6376 to validate the TXT record. Missing or malformed keys cause authentication failures.

Review logs and headers to detect signing issues

Inspect outbound email headers. Look for Authentication-Results or DKIM-Signature fields. If b= is absent but d= and s= are present, the signing process failed after key lookup.
Check your sending system logs for errors like “DKIM signature generation failed” or “Key not found.” Such logs often reveal misconfigurations or temporary outages in the signing engine.
Re-enable or reconfigure DKIM signing. Some ESPs temporarily disable DKIM during migration or after service degradation. Re-save your DKIM settings to reset the signing pipeline.

If your outbound headers show dkim=pass but no b=, the signature was validated but never created — a sign of a system-level issue. Run a full inbox placement test with MailTester’s inbox placement tool to see whether the email lands in spam folders due to poor authentication.

DKIM isn't optional for trusted senders. A missing b= tag means the signature content isn't signed — not just malformed, but absent.

Keep your DNS records updated and verify them regularly. Even small changes in domain configuration can break signature chains. Use MailTester’s single-email checker to test individual addresses and detect authentication flaws before sending to large lists.

MailTester checks your domain’s DKIM DNS records in real time to confirm they’re correctly set up. If the signature is missing the b= tag—commonly due to incomplete configuration—it flags the mismatch before you send. This catches issues that would otherwise lead to emails being rejected or marked as spam, helping you avoid delivery failures at scale.

How MailTester catches DKIM misconfigurations early

DKIM relies on a signed header and a corresponding DNS record. Without the b= tag in the signature, the receiving server cannot validate the domain's authenticity, and delivery often fails. MailTester runs a full validation, checking both the DNS record and the actual signature in the email header. If the b= tag is absent, it surfaces this as a "DKIM signature incomplete" result.

Let’s say you’re setting up email delivery for a new campaign. You’ve added your DKIM record in DNS, but missed a small detail—maybe a typo, or a missing selector. MailTester’s real-time verification will detect the gap before you send a single message. This is especially valuable when integrating with platforms like SendGrid, Mailchimp, or Klaviyo, where misconfiguration can silently break delivery across thousands of messages.

Building confidence across your send workflows

Running DKIM checks during onboarding, list cleaning, or migration reduces risk. MailTester supports bulk list verification via its email list verification tool, allowing teams to test thousands of addresses at once and isolate those with failed or missing DKIM signatures. This prevents entire campaigns from being flagged or rejected due to outdated or malformed records.

Through its integration with SendGrid, Mailchimp, and others, MailTester can be used as a pre-send validation layer, ensuring every message sent from your verified domain passes both SPF and DKIM checks. This isn’t just about technical correctness—it’s about maintaining sender reputation and inbox placement, which are tied to consistent authentication.

For technical teams, MailTester’s API enables automated checks during onboarding, CRM syncs, or email campaign deployment. This means validation happens at the code level, before any customer-facing message is sent. It’s not a substitute for proper DNS management, but it’s a critical safety net.

DKIM authentication is one piece of a larger deliverability picture. Tools like Spamhaus and RFC 6376 confirm its role in reducing email spoofing and improving trust. But even the best standards fail if the implementation is wrong. That’s where MailTester steps in—offering transparency, clarity, and early warning so your message actually reaches the inbox.

Final takeaway: What ‘permitted’ means and what it doesn’t mean

A 'permitted' DKIM status in MailTester confirms your DNS record is correctly published and recognized by receiving servers. It does not verify that your messages are actually signed during delivery.

DKIM permittance is the first checkpoint in the chain of authentication. It means the domain’s public key is accessible, but it says nothing about whether the b= tag appears in the signed email headers.

What to do next

Verify that every outgoing email includes a valid b= tag in its DKIM signature.
Use MailTester’s inbox-placement test to simulate real delivery conditions and detect missing or malformed signatures.
Don’t rely solely on DNS checks — test actual message flow across real inbox environments.

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

Does a 'permitted' DKIM result mean my emails are signed?

No. MailTester checks your DNS record, not the actual email. A permitted status means signing is allowed, but it doesn't confirm that the b= tag is present in your messages.

Why is the b= tag missing in my emails even though DKIM is enabled?

The signing process may have failed due to misconfiguration in your sending platform, key mismatch, or a system-level issue. Check your outbound email headers and service settings.

Can I send emails with DKIM but without the b= tag?

No. The b= tag is required for the DKIM signature to be valid. Without it, the message fails authentication and may be rejected or marked as spam.

Does MailTester test the actual email content for DKIM?

No. MailTester does not send or receive actual emails. It checks the public DNS record for DKIM configuration, not the presence of the b= tag in a message.

How can I test if my DKIM signature is being applied correctly?

Send a test email, open it in a client that shows headers (like Gmail’s 'Show original'), and look for the DKIM-Signature header with a valid b= tag.

Is a missing b= tag a sign of a security issue?

Not necessarily a security flaw, but it is a configuration failure that reduces trust and increases spam risk. It can also indicate poor system hygiene.

Do all email providers require the b= tag?

Yes — all compliant mail servers require the b= tag to validate DKIM. Its absence results in signature failure, regardless of domain authorization.

Can MailTester detect malformed DKIM signatures?

MailTester does not analyze message content, so it cannot detect malformed b= tags. You must inspect actual email headers to verify signature structure.

Why do some emails show DKIM permitted but fail delivery?

Because a permitted DNS record doesn’t guarantee signing occurs. If the b= tag is missing or invalid, the message fails authentication and is filtered.

Should I rely solely on MailTester’s DKIM test for email delivery?

No. Use MailTester to validate DNS setup and to test sender reputation, but verify real email delivery with inbox-placement tests to confirm b= tag presence and alignment.

How does a missing b= tag affect sender reputation?

Repeated DKIM failures from missing b= tags can signal poor sending practices, potentially leading to reputation damage and higher spam filtering.

What is the difference between a valid DKIM DNS record and a valid DKIM signature?

A valid DNS record means the domain allows signing. A valid signature means the message includes a proper b= tag and passes cryptographic validation.