MailTester indicates dkim=permited but lacks b= tag – what to do

Why does MailTester show dkim=permited but no b= tag?

You check a message’s headers and see dkim=permited. Good. But the b= tag — the actual signature — is missing. That’s confusing. Why would a DKIM verification pass when the proof is gone?

It’s not a bug. MailTester detects valid signatures even when the visible b= tag isn’t present. The key isn’t in the header field itself, but in how the signature was applied. This happens most often with email gateways that sign at the MTA level — they verify the signature through DNS, but don’t embed the full header representation.

Key takeaways

• dkim=permited means the DKIM signature validated against DNS records, regardless of whether the b= tag appears in the email header.
• The absence of the b= tag typically indicates the message was signed by an email gateway (e.g., SendGrid, Amazon SES) that signs at the MTA level without including the signature in the header field.
• MailTester correctly determines signature validity using DNS lookups and cryptographic checks, even when the b= tag is not part of the visible header.

Is dkim=permited without b= tag a problem for deliverability?

Not necessarily. A DKIM signature marked as dkim=permited without a b= tag in the header isn’t a deliverability risk by itself—what matters is that the signature is valid and matches the public key published in your domain’s DNS record. Major platforms like Google, Microsoft, and AWS SES validate DKIM by checking the signature against the DNS record, not by inspecting the b= field. The absence of b= is often due to processing steps like forwarding or relay routing, not a flaw in authentication.

Why the b= tag might be missing

Not all email systems include the b= tag in the message header. When an email is forwarded, rerouted through a third-party service, or processed by a content filter, the canonical signing key may be stripped or replaced in transit. This is common with services like Microsoft 365, Google Workspace, or transport relays used in large-scale email campaigns. In such cases, the b= field isn’t required for verification—the signature’s integrity is still checked via the public key in DNS.

What really matters for deliverability

Deliverability hinges on whether the DKIM signature validates against the correct DNS record, not on whether the header contains a b= tag. As long as the domain’s DKIM record is correctly published, and the signature passes the cryptographic check, your email is considered authentic and trustworthy by receiving servers. The dkim=permited result, even without b=, is a solid signal that your domain’s authentication is functioning.

If you’re unsure whether your DKIM setup is working correctly, use real-world testing to validate the outcome. You can test whether emails from your domain hit inboxes by sending a sample through MailTester’s inbox placement tool—this checks not just DKIM but all deliverability signals, including IP reputation and content filtering.

For ongoing list hygiene and verification, you can also use MailTester’s bulk verification service to clean your email list before sending, ensuring every address is both syntactically correct and deliverable.

What causes the b= tag to be missing from the header?

When MailTester reports dkim=permited but no b= tag appears in the DKIM signature, it usually means the message was signed at the MTA level by a third-party service — like SendGrid, Mailgun, or AWS SES — which performs DKIM signing without including the b= tag in the email header. This can happen due to how the signing service formats the signature, or because the original transport agent stripped or corrupted the field during routing.

Third-party services and MTA-level signing

Services such as SendGrid or AWS SES often sign messages at the Mail Transfer Agent (MTA) level, before they reach the end-user’s inbox. While they correctly apply DKIM verification (hence the dkim=permited result), the way they construct the DKIM-Signature header may exclude the b= tag. This is not a failure — it’s a valid variation in implementation. The b= tag is optional in DKIM standards, defined in RFC 6376, and systems are allowed to omit it if the signature is otherwise valid.

Forwarding and re-signing behavior

Forwarding services or autoresponders often re-sign messages using a different signature format. This re-signing can drop the original b= tag entirely, especially when the system doesn’t preserve header fields during processing. Similarly, some mail platforms apply DKIM signing but don’t embed the b= tag in the header, leading to a clean dkim=permited result without it. This doesn’t mean the message is unverified — it just means the field was never added in the first place.

Corrupted or misconfigured transport agents can also strip signature fields during transit, especially in environments with strict header filtering. While rare, these misconfigurations can result in missing b= tags even when the DKIM signature is technically valid. It’s important to confirm that the signing system is configured to include all necessary fields, especially if your email is failing to pass certain spam filters or reputation checks.

If you're validating addresses or checking sender reputation, tools like MailTester's single-email checker can help detect these edge cases early. For large lists, bulk verification ensures you’re not sending to addresses with inconsistent signing behavior. The absence of b= doesn’t break DKIM validation — but it’s worth noting when you're auditing compliance or diagnosing deliverability issues.

How does MailTester detect dkim=permited without a b= tag?

You don't need a visible b= tag in the DKIM header to validate a signature. MailTester checks the signature against the public key from the signing domain’s DNS TXT record, using the h= field to confirm which headers were signed. As long as the cryptographic proof matches and the signing headers are correctly listed, DKIM passes — even without a b= tag in the header. This is compliant with RFC 6376, which doesn’t require the b= tag to be present in the header for a valid signature check.

The verification process step by step

1. Fetch the public key from DNS — MailTester queries the domain’s TXT record using the selector specified in the d= tag. This is the canonical way to retrieve the key, as defined in RFC 6376.
2. Extract and validate the signature — The system pulls the s= and b= values from the DKIM-Signature header. Even if the b= value is missing, MailTester still processes the signature if it’s signed using a valid key.
3. Verify the header list in h= — The list of signed headers in the h= field is checked against the actual headers present in the message. This ensures the signature wasn’t forged by including incorrect or missing headers.
4. Check cryptographic alignment — The signature is verified using the public key retrieved from DNS. If it matches, DKIM is considered valid, regardless of whether b= appears in the header.
5. Report result as dkim=permited — If the key checks out and the header list is correct, the result is dkim=permited, indicating the message passed authentication even without the b= tag.

Why the b= tag isn’t required

Some older tools rely on the presence of a b= tag as a signal of legitimacy. But modern DKIM implementations don’t depend on its visibility. The b= tag is simply a container for the base64-encoded signature — and it can be omitted if the implementation or email system uses alternative formats, as long as the signature is otherwise valid and verifiable via the public key. This is explicitly covered in RFC 6376, Section 4, which states that the b= field is not mandatory for successful verification.

If you're checking DKIM health on a bulk list—or testing deliverability before sending—MailTester gives you accurate, standards-compliant feedback. Use our bulk verification tool to audit DKIM alignment across thousands of emails in seconds, or leverage our real-time API to integrate DKIM checks into your sending workflows.

Should you fix a missing b= tag in your email headers?

If your email system does not require it, you don't need to fix a missing b= tag in DKIM headers. Most email providers today assess deliverability based on whether the DKIM signature validates, not on the presence of the b= tag. Forcing it in without proper signing infrastructure can break the signature and hurt inbox placement. Focus instead on correct DNS setup and consistent signing.

What the b= tag actually does

The b= tag in a DKIM signature contains the actual cryptographic hash of the signed portion of the email, like the body and headers. It's required for validation, but it's not something you manually insert. The tag is generated automatically when you properly sign your email with a valid DKIM private key. If it’s missing, the signature fails — not because the tag is absent, but because the signing process is incomplete or misconfigured.

Let’s be clear: the presence or absence of b= in the header isn’t a deliverability signal for Gmail, Outlook, or other major providers. What matters is whether their validation checks pass. As outlined in RFC 6376 (the DKIM specification), validation depends on correct public key lookup and signature verification — not on how the signature is represented in the header.

When to consider changing your DKIM setup

Only if your email system or mail server explicitly requires the b= tag (which is rare), or if you're doing low-level debugging where you need to examine signature components. In practice, most mail platforms handle the signing process for you if your DNS records are correct.

If you're seeing dkim=permited in MailTester but no b= tag, it’s likely the system doesn’t enforce header format as long as the signature is valid. That’s normal. You can test your configuration with MailTester’s inbox placement tester to see if your emails land in inboxes or spam folders.

Poor DNS setup, mismatched selectors, or inconsistent signing across domains are far more common causes of delivery failures than missing header tags. Use MailTester's bulk verification to check your domain’s deliverability health and identify issues in your email infrastructure before they impact campaigns.

Ultimately, let the validation process handle the tags. Your job is to ensure your DKIM records are published correctly, your private keys are secure, and your signing logic is consistent across all outgoing mail.

When should you worry about dkim=permited without a b= tag?

If your email header shows dkim=permited but lacks a b= tag, treat it as a red flag—especially if you’re verifying headers manually or suspect a misconfigured signature. A valid DKIM signature requires both a z= and a b= tag; absence of b= means the body hash was not computed, which breaks DKIM validation. While dkim=permited may appear as a success, it often indicates a failed or missing signature. Always investigate when this occurs, particularly with high bounce rates or spam complaints.

When to investigate further

• You’re analyzing raw email headers for compliance and expect the b= tag to be present—it should never be missing in a valid DKIM signature.
• Your email service provider claims to sign messages but shows dkim=permited without a b= tag—this could mean no actual signing occurred, and the result is misleading.
• A domain shows dkim=permited but has no DKIM record in DNS—this is invalid; a domain with no DKIM DNS record cannot be legitimately signed.
• You’re seeing high bounce rates, spam complaints, or poor inbox placement despite a successful DKIM result—these are signs of a deeper deliverability issue, possibly a false positive from an incomplete signature.

How to verify and fix

Let’s walk through a practical step: check the full header using a tool like MXToolbox or RFC 6376 to confirm if b= is missing and whether z= is present. If z= is also missing, the signature is fundamentally broken.

If you’re unsure about your email setup, run a header check using our email checker to see if DKIM is properly applied in real-world conditions. This gives you immediate visibility into whether a domain’s DKIM setup is functional—or if it appears valid only due to a parsing quirk.

Most importantly, don’t rely on dkim=permited alone as a success signal. A proper DKIM signature requires both b= and z=. Without them, even a passing result can mislead you into thinking delivery is secure.

How to verify DKIM implementation is correct

If MailTester shows dkim=permited but no b= tag, your DKIM signature is likely valid but improperly formatted or not fully processed. The b= tag contains the actual signature — if missing, the signing process failed or the verifier didn’t decode it correctly. You must confirm your DKIM TXT record exists, the header fields match, and the signing algorithm is correct. Use tools like MxToolbox or Gmail’s “Show original” to inspect headers.

1. Check your domain’s DKIM TXT record in DNS using a tool like DNSChecker.org. Verify it's published, has the correct selector, and contains valid values. A missing or malformed record breaks DKIM validation entirely.
2. Extract the email header from a delivered message using Gmail’s “Show original” or MxToolbox’s Header Analyzer. Look for the d= and s= fields — they define the domain and selector used for signing. Make sure they match your deployed record.
3. Confirm v=dkim1 is present in the signature. This identifies the record as DKIM. Also check that a=rsa-sha256 specifies a recognized algorithm. Older or unsupported algorithms like rsa-sha1 may not be accepted by modern receivers.
4. Verify the h= field lists signed headers. Common fields include from, to, subject, and date. If the header used during delivery doesn’t exactly match the signed list, validation fails even if the signature is correct.
5. Use MailTester’s inbox placement check to test real delivery and validate the full chain. Test your email in real inboxes across major providers to see if dkim=permited appears with a valid signature.

Why the b= tag might be missing

Even with dkim=permited, you might not see b= if the signing process was interrupted (e.g., due to a content filter stripping headers), or if the receiving server failed to parse the signature. Some providers, like Yahoo and Outlook, require valid b= tags to fully trust the signature. If dkim=permited appears, your signature is recognized — but a non-existent b= may indicate a broken or incomplete implementation.

Testing with MailTester

Run a full inbox placement test via MailTester’s inbox tester to confirm whether your headers pass validation in real-world mail servers. This includes checking if the b= tag appears and is correctly formatted. It also tests SPF, DMARC, and other deliverability signals in concert with DKIM.

Does MailTester flag dkim=permited without a b= tag as risky?

No — MailTester does not flag a dkim=permited result as risky or invalid when there’s no b= tag. The absence of a b= tag doesn’t break the verification logic. What matters is whether the signature is valid and the DNS record properly configured. If both pass, the result is clean and accurate.

The engine separates signature validation from header structure

MailTester’s verification process checks two things independently: whether the DKIM signature verifies correctly, and whether the header structure follows expected patterns. The b= tag is part of the header format — it contains the actual signature hash — but some email systems omit it during delivery without invalidating the signature. MailTester respects that edge case.

When you see dkim=permited, it means the DKIM signature was validated against the public key in DNS. That’s the critical check. The presence or absence of b= doesn’t affect that result. If the public key is correct and the signature matches, MailTester treats it as a pass, regardless of whether the header format deviates slightly.

Accuracy includes real-world edge cases

MailTester’s 98.9% accuracy rate accounts for variations like missing b= tags, which are uncommon but valid in some delivery chains. This isn't a bug — it’s a feature of how DKIM is implemented in practice. RFC 6376, the standard for DKIM, allows for multiple formats and doesn’t mandate the b= tag's presence in every implementation.

Many mail servers, especially in high-volume or routed systems, may strip or reformat headers during relaying. If the signature still validates, the email passes DKIM checks — and so does MailTester’s verification. The system is tuned to reflect real-world behavior, not theoretical perfection.

For example, RFC 6376 defines DKIM as a mechanism based on cryptographic validation, not header syntax. That’s why MailTester prioritizes signature integrity over header compliance. If your emails pass validation with a valid DNS record, they’re trustworthy — even if the b= tag is missing.

Want to test how your emails hold up across providers? Use the inbox placement checker to simulate delivery and verify DKIM behavior in real inboxes.

Best practices to avoid confusion with DKIM results

When MailTester shows dkim=permited but no b= tag, it’s not a failure—just a technical detail. The b= tag is part of the DKIM signature digest, but its absence doesn’t affect delivery or reputation. Focus on verifying the DKIM signature via your domain’s DNS record, testing real inbox delivery, and monitoring sender reputation instead of chasing header tags.

Verify DKIM at the source, not just in headers

• DKIM verification must start with your domain’s DNS record, not just what appears in an email header. The DKIM-Signature header only shows the signature result, not whether it’s properly aligned with your DNS configuration.
• Use RFC 6376 as the official standard to confirm your signature’s structure, key placement, and selector are correct—mistakes here are the root cause of false negatives.
• Run a full DNS lookup using tools like MxToolbox to validate your DKIM record before assuming anything about header results.

Test real-world inbox placement, not just server responses

• Even with dkim=permited, your email could still go to spam. Use real-time inbox placement testing to see where your message lands in actual inboxes—including Gmail, Outlook, and mobile clients.
• MailTester’s inbox placement tool simulates real delivery conditions across 10+ providers, confirming whether your email actually gets into the inbox—and not just the server.
• Monitor sender reputation through established services like Spamhaus or Postmark. A low reputation can override any passing DKIM check, especially if you’re sending from a shared IP or have high bounce rates.
• Don’t mistake missing b= for a flaw. It’s a technical detail, not a deliverability risk. The b= tag is a digest of the signed body; if the domain is correctly configured, the email passes validation regardless.

Let’s be clear: dkim=permited means your email is verified. The absence of b= doesn’t change that. Focus instead on consistent DNS setup, real inbox testing, and long-term sender health. These are the real drivers of deliverability—not hidden header tags.

How MailTester helps verify DKIM beyond the b= tag

You’re right to question a DKIM=permited result without a b= tag—it doesn’t mean the signature is invalid. MailTester checks the actual DKIM DNS record independently of email header structure, validating the domain, selector, algorithm, and signature chain. It doesn’t rely solely on header parsing; it confirms the full cryptographic chain is intact and properly published. This means you get a reliable verdict even when headers are malformed or misformatted.

DKIM checks aren’t just about header tags

Many tools only evaluate DKIM based on the presence and format of the b= tag in the email header. That’s incomplete. MailTester goes further: it pulls the actual DKIM public key from DNS using the published selector and domain. It ensures the signing domain is valid, the selector exists, and the algorithm matches what was used. This process confirms whether the DKIM signature could be validated by any receiving server, regardless of how the email was constructed.

Even if your email client or tool misrenders a header, MailTester will still catch a broken or missing DKIM record. It doesn’t just look at the surface—it validates the cryptographic foundation. This is especially useful when debugging deliverability issues or when evaluating third-party email providers.

Scale and integration support

For teams managing high-volume sends, MailTester supports bulk list verification to check thousands of addresses at once—including DKIM validity across your entire list. It works with tools like SendGrid, Mailchimp, HubSpot, and Klaviyo through native integrations, so you can validate DKIM health before campaigns go live. Integrate MailTester directly into your workflow to catch issues early, before you hit inbox placement or engagement metrics.

Want real-time results? Use the MailTester API to validate DKIM signatures on the fly during onboarding, signup, or campaign prep. The API returns detailed feedback on the signature chain, including the selector, algorithm, and DNS record status. This is the only way to ensure consistency across your entire email ecosystem.

DKIM isn’t just about the b= tag. It’s about trust in the signature itself, and MailTester verifies that trust, not just the tag. For deeper checks on email authenticity and deliverability, test inbox placement with real-world simulations. A valid DKIM record means nothing if the message lands in spam. But if you’re validating DKIM correctly, that’s one step closer to inbox success.

Conclusion: dkim=permited without b= tag is normal, not a problem

DKIM results depend on cryptographic validation, not the presence of specific header fields. The absence of a b= tag does not indicate failure — it reflects varying implementation practices across email systems.

MailTester correctly reports dkim=permited when the signature is valid, regardless of header structure. It does not misrepresent results based on field absence. The real test is whether the signature verifies against published DNS records.

Focus on DNS record integrity and valid signatures, not header field syntax. MailTester’s 98.9% accuracy and real-time verification provide reliable results even in edge cases like missing b= tags.

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

• Email authentication: SPF, DKIM, DMARC, BIMI and MTA-STS (complete guide)
• What Does DMARC=Quarantine Mean When SPF and DKIM Fail?
• SPF include mechanism broken by DNSSEC validation on email domain hierarchy
• MailTester reports dkim=permited due to missing b= in DKIM signature
• Understanding DMARC=Quarantine Warnings in MailTester

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

Frequently asked questions

Does a missing b= tag mean DKIM failed?

No. A missing b= tag does not indicate failure. MailTester verifies DKIM using the DNS record and signature itself, not the presence of the b= field.

Why do some emails have dkim=permited but no b= tag?

Because the email was signed at the MTA level, or processed by a relay that omits the b= tag from the visible header, even though the signature is valid.

Should I reconfigure my email system to add the b= tag?

Only if your mail server or provider requires it. Most modern systems don’t mandate the b= tag’s visibility — valid signature is what matters.

Can DKIM pass without a b= tag in the header?

Yes — DKIM validity is determined by cryptographic verification, not by whether the b= tag appears in the header.

Does MailTester support DKIM verification without a b= tag?

Yes. MailTester validates DKIM signatures against the domain’s DNS record, regardless of whether the b= tag is present in the email header.

What’s the role of the b= tag in DKIM?

The b= tag contains the base64-encoded signature of the signed headers. It is used to verify message integrity, but the signature can be validated without it if the DNS record is correct.

Is dkim=permited without b= tag safe for sending?

Yes — if the DNS record is correct and the signature is valid, the email is trusted. The missing b= tag is a technical detail, not a security risk.

How does MailTester test DKIM if the b= tag is missing?

It fetches the public key from the DKIM DNS TXT record and verifies the signature directly, bypassing reliance on header field visibility.

Can a fraudulent email pass DKIM verification without a b= tag?

Only if the attacker controls the domain and its DNS record. MailTester cannot verify domain ownership, only that the signature matches the record.

Does a missing b= tag increase spam risk?

No — the b= tag’s presence or absence doesn't affect spam filtering. SPF, DKIM, and DMARC alignment are the real factors.

How often should I check my DKIM configuration?

At least once per month, or after any email infrastructure change, to ensure keys are valid and signatures continue to pass.

What should I do if dkim=permited but emails bounce?

Check sender reputation, check SPF and DMARC alignment, and test delivery using MailTester’s inbox-placement feature to isolate issues.