Why does DKIM signature validation fail when the b= tag lacks base64 padding?

You’re troubleshooting an email that’s being rejected, and the logs show a DKIM signature validation failure. The error points to the b= tag—specifically, missing padding. You double-check the code, and everything seems correct. But the signature still fails. Why?

DKIM signatures are strict. They rely on precise formatting—every character matters. If the b= tag in the DKIM-Signature header isn’t properly base64-encoded with trailing == padding, the verifier treats it as malformed. Even one missing character breaks the math.

This isn’t a rare edge case. It happens when custom tools or scripts generate signatures without validating the output against the standard. A missing == at the end of a base64-encoded string—common in poorly tested code—will cause validation to fail, even if the rest of the signature is correct.

Key takeaways

  • DKIM signature validation requires base64-encoded b= tags to end with standard == padding
  • Missing padding causes verifiers to reject the signature as malformed, regardless of cryptographic correctness
  • Custom email signing tools often fail to enforce proper base64 formatting, leading to silent delivery failures

What does the b= tag in a DKIM signature actually contain?

The b= tag in a DKIM signature contains the base64-encoded cryptographic signature generated by applying the sender’s private key to the canonicalized headers and body of the email. This value must be properly padded with == when the length of the base64 string isn’t divisible by 4; missing padding breaks the decoding process, leading to a DKIM validation failure even if the signature is otherwise correct.

How the b= value is created

When an email is signed, the sender’s mail server computes a hash of the standardized (canonicalized) headers and body using a cryptographic algorithm—typically SHA-256. The resulting hash is then encrypted using the private key from the DKIM selector record. The output of this operation is a large number that must be encoded in base64 for inclusion in the email header.

Base64 encoding requires the input string length to be a multiple of 4. If it isn’t, one or two = padding characters are added to the end. For example, a 24-character base64 string is valid, but a 25-character string is not unless it ends in ==. Without this padding, most decoders will reject the value outright.

Why missing padding causes failure

Even minor errors in the b= value—like an incomplete or improperly padded base64 string—trigger a DKIM failure. Recipient servers perform strict validation, and a malformed signature is treated as invalid. This doesn’t mean the email is spam, but it does mean the sender’s domain can’t prove it sent the message. Many mail servers—including Gmail, Outlook, and others—reject messages with invalid DKIM signatures, often marking them as untrusted or sending them to junk folders.

According to RFC 4871, the standard for DKIM, the signature value in the b= tag must be base64-encoded and correctly padded. It’s a non-negotiable part of the spec.

Let’s say you're debugging a delivery issue and see a “DKIM signature validation fails” error. You may assume it’s a misconfigured key or header issue—but the root cause could be as simple as a missing == at the end of the signature. The fix isn’t in adjusting your SPF or DMARC settings. It’s ensuring that your email signing process produces properly padded base64 output.

For teams managing large email sends, verifying that DKIM signatures are correctly generated can prevent a significant portion of technical bounces. You can proactively test your email deliverability and check for such header-level issues using inbox placement testing tools. You can also verify your DNS records and signature syntax using a tool like MailTester’s inbox placement tester to simulate real-world delivery conditions across major providers.

How can missing base64 padding in b= tags break email deliverability?

DKIM signature validation fails when the base64-encoded b= tag lacks padding—specifically, when the encoded string doesn't end with one or two = characters. Receiving servers enforce strict RFC-compliant parsing. A missing = breaks the base64 format, causing the signature check to fail, even if SPF and DMARC pass. This alone can trigger spam filters or outright rejection, especially when repeated across messages.

The technical chain of trust

DKIM signs the message body and selected headers using a cryptographic key. The resulting signature is encoded in base64 and placed in the b= tag. The format is strict: every base64 string must be padded to a multiple of four characters. If it isn’t, the recipient’s server cannot decode it, and validation fails immediately. This isn't a soft warning—it’s a hard rejection at the protocol level.

Even if your SPF and DMARC records are correctly configured, a single DKIM failure can override them. Mail receivers treat DKIM as a core trust signal. A failed signature signals instability or misconfiguration, which harms your domain reputation over time. As a result, repeated failures—especially in bulk sends—can trigger automatic filtering, low inbox placement, or even blocklisting.

Some providers silently drop messages with malformed signatures. Others reject them with a 5xx error code. Either way, you get no delivery confirmation, no bounce, just silent failure. This makes DKIM issues especially hard to detect without active verification.

How to catch and fix it

Let’s say your email system generates DKIM signatures. If you're using a custom script or third-party tool, double-check the base64 encoder. It must ensure padding is added after encoding. Many libraries do this automatically, but mistakes happen—especially when handling binary data or custom signing processes.

You can test for this problem by fetching the raw message headers and inspecting the DKIM-Signature line. Tools like MXToolbox’s DKIM validator or RFC 6376 define the exact format. Even minor deviations—like an off-by-one padding error—break the standard.

Prevention starts with verification. Before sending, validate your messages using a tool that checks DKIM signature integrity. MailTester’s inbox placement testing simulates real-world delivery paths and flags technical issues like malformed DKIM. If you’re verifying a list before sending, run a bulk check with MailTester’s email list verify to catch domain-level problems early.

How to debug a DKIM validation fail caused by missing padding?

You can fix a DKIM signature validation fail due to missing padding by checking the raw email’s DKIM-Signature header, verifying that the b= value has proper Base64 padding (ending with =), and using tools like MxToolbox or MailTester’s inbox placement test to validate the full signature structure during real-world delivery.

Step-by-step: Find and fix missing padding in b=

  1. Fetch the raw email source—open the email in your client, view source, and locate the full DKIM-Signature header. This is where the b= value lives, and it’s the most likely place for encoding issues to appear.
  2. Check the b= value for padding—Base64 strings must be a multiple of 4 characters long. If the b= value ends in ... without one or two = signs, it’s missing padding. For example, abc or abcd are valid, but abcde is not. Use a standard Base64 decoder to confirm. The RFC 4648 specifies this requirement explicitly.
  3. Recreate the signature with correct padding—if you’re generating the signature, ensure your encoding library appends = to make the length divisible by 4. Most modern libraries do this automatically, but some manual implementations don’t. Test with a known-good string to verify.
  4. Validate the full DKIM structure—don’t rely on the b= value alone. Use a tool like MxToolbox’s DKIM Checker or MailTester’s inbox placement testing to simulate real delivery and validate everything from DNS records to signature hashing.

Why this matters in practice

DKIM validation fails silently if the signature doesn’t decode. Even a single missing = breaks the entire validation process. Most email receivers reject the message outright, leading to delivery failures or spam placement.

Even if your DNS records are correct and the key is published, a malformed b= value—especially one missing padding—will cause the signature to be rejected. This is a common issue when manually constructing headers or using legacy software that doesn’t adhere to RFC 4648.

Automated testing is critical. Tools like MailTester’s API or inbox placement tester can catch this before you send to thousands. They test real-world behavior, including how receivers process padding and hashing.

Don't assume your DKIM is valid just because it looks right in a debug log. A single missing padding character can break trust at scale.

Real-world example: A missing == in the b= tag caused delivery to fail

You sent transactional emails to Gmail, passed SPF and DMARC, yet 15% were rejected. The fix? A missing == at the end of the DKIM b= value in the signature. The raw header showed b=...r8Qx instead of b=...r8Qx==. Adding the two padding characters restored valid DKIM signature validation and fixed inbox placement. This isn't a parser quirk — it’s a mandatory part of Base64 encoding, defined in RFC 4648.

Why Base64 padding matters in DKIM

Digital signatures in DKIM use Base64 encoding to represent binary data. The standard requires padding with = characters to ensure the length is a multiple of four. Without it, the signature is technically malformed. Even modern systems like Gmail’s DMARC validation engine will reject a signature if the b= value isn’t properly padded — no matter how correct the signing key or DNS record might be.

Let’s walk through what happened. The enterprise’s email server generated the DKIM signature using a library that omitted padding during output. The signature looked valid to a casual glance: alphanumeric characters, no obvious errors. But when Gmail parsed the b= field, it failed to decode it. The resulting validation failure didn’t appear in the header log with a clear "invalid Base64" message — it just showed as a "DKIM signature validation failed" bounce. This made root cause analysis difficult unless you studied the raw message.

How to catch this before it breaks delivery

Even if your email stack passes SPF and DMARC, a flawed DKIM signature can break inbox delivery. You won’t see it in a basic syntax check, but you will see it in real-time delivery reports — or worse, in a sudden spike in bounces from Gmail, Microsoft, or Apple.

Check your outgoing emails using a tool that parses raw headers and validates DKIM mechanics. Tools like MailTester’s inbox placement tester simulate delivery across Gmail, Outlook, and Apple Mail while reporting granular validation feedback. It doesn’t just confirm "pass/fail" — it shows exactly where the signature chain broke.

For bulk senders, validating DKIM in real-time before sending is critical. Use an email verification API like MailTester’s real-time verification API to ensure every address you send to is not just active but also receiving from a technically sound source. The system checks for common misconfigurations like missing DKIM padding, invalid DNS records, or invalid sender IPs — all things that can silently degrade deliverability.

What are the correct character requirements for the b= tag in DKIM?

The b= tag in DKIM must contain a base64-encoded signature using only A-Z, a-z, 0-9, +, and /, with padding consisting of one or two = characters added only at the end. If the length isn't a multiple of 4, the absence or incorrect placement of padding causes validation to fail. You must ensure the encoding follows RFC 4871 and RFC 4648 precisely. Tools like MailTester’s email checker can help you test and debug these signatures before sending.

Character and formatting rules for the b= tag

  • The b= value must use the standard base64 alphabet: A-Z, a-z, 0-9, +, and / — no other characters are allowed.
  • The encoded string length must be a multiple of 4. If not, you must append one or two = padding characters at the very end.
  • Padding must never appear in the middle or be missing entirely. Interleaved or absent padding invalidates the signature during validation.
  • Do not encode the signature using base64url (which replaces + with -, / with _, and omits padding) — that’s a different format and will fail DKIM checks.
  • Always verify the output matches the specification in RFC 4871, the foundational document for DKIM signing.

Why missing or misplaced padding breaks DKIM

DKIM validation is strict about formatting. A single missing = at the end, or a = inserted mid-string, results in a malformed base64 string. Most validators reject this immediately, treating it as an invalid signature. This is commonly seen in systems that use nonstandard or custom base64 encoders.

Let’s say your signature is 59 bytes long after encoding. 59 is not divisible by 4. You need one = to pad to 60. Add it only at the end—no exceptions. RFC 4871 and the base64 standard both define this behavior precisely.

If you're troubleshooting a DKIM failure, inspect the raw header value. Misencoded b= tags are a frequent cause. Use tools that validate the full DKIM structure. MailTester’s inbox placement test includes DKIM signature validation as part of its diagnostic report.

How do email verification tools like MailTester help catch this issue?

MailTester catches DKIM signature validation failures caused by missing base64 padding in the b= tag during inbox-placement tests. It checks the full structure and encoding of DKIM signatures, including proper base64 padding, and flags malformed signatures before you send at scale—so you avoid bouncebacks and delivery issues due to technical errors in your email authentication.

What MailTester checks in DKIM signatures

When you run an inbox-placement test with MailTester, it doesn't just verify the email address—it inspects the full delivery chain. That includes validating the DKIM signature structure, which starts with the DKIM-Signature: header. The b= tag contains the actual signature in base64 format, and it must conform to strict encoding rules.

One common failure is missing padding—base64 strings must end in one or two = characters to be valid. A signature like abc123 instead of abc123= or abc123== fails validation. MailTester detects this by parsing the syntax and verifying padding against RFC 4648, which defines base64 encoding standards.

This means even if your domain passes SPF and DMARC checks, a malformed b= tag will still break DKIM verification—leading to rejected messages or poor reputation. MailTester surfaces these failures explicitly during inbox-placement tests, so you can fix them before they impact your send rate.

Fix it before you send

Many senders don’t realize their DKIM signatures can fail for such subtle reasons. Let’s be honest: it’s easy to overlook base64 padding when manually crafting or validating a signature. Tools like MailTester act as safety nets. You can test individual addresses with the email checker, verify entire lists with bulk verification, or use the inbox placement tool to see how your email behaves in real Gmail, Hotmail, and other inboxes.

These tools don’t just say "valid" or "invalid"—they tell you why. If a DKIM validation fails due to missing padding, the report shows the exact header and line that broke. That precision helps you debug issues in your email system, whether you’re using a marketing platform, custom SMTP, or a legacy email service.

And since DKIM is a core part of sender reputation, fixing these issues early stops delivery problems before they start. You’re not just verifying addresses—you’re verifying your authentication stack. For more details on how MailTester’s real-time API integrates with your workflow, see the verification API documentation, where you can automate validation across your entire delivery pipeline.

Can automated tools generate DKIM signatures with missing padding?

Yes — many automated tools, especially those using untested or non-standard signing libraries, can generate DKIM signatures with missing Base64 padding in the b= tag. This happens when the encoder omits the required padding characters (=) at the end of the Base64 string, leading to validation failures even if the cryptographic signature is otherwise correct. RFC 4648 explicitly defines Base64 encoding with padding, so tools that skip it violate a core standard.

Why padding is often omitted in practice

Let’s be honest: automated systems don’t always follow the RFC exactly. Some signing libraries use simplified or legacy Base64 encoders that assume the input is already padded or skip it entirely for performance. Others may not validate output format at all, trusting that the end result will be accepted by mail servers. This works until it doesn’t — especially in large-scale or transactional email setups where even minor deviations cause rejection.

The b= tag in a DKIM signature must be a valid Base64-encoded string, including trailing padding when necessary. Omitting it, even if only in one out of a hundred thousand messages, can trigger a validation failure. The receiving server doesn’t guess — it rejects. This is why you’ll see failed DKIM checks in tools like MxToolbox or the DMARC analyzer at https://dmarcian.com/ — not because the key is wrong, but because the signature is malformed.

Verifying your signing process

Even a single improperly signed message can impact your overall sender reputation. If you're sending transactional or bulk email, you must verify that your DKIM signing process outputs fully compliant signatures. This includes proper padding, correct header canonicalization, and a consistent hash across all included tags.

While DKIM signature validation is technically complex, you can test individual signatures or whole lists for compliance. Tools like MailTester’s email checker can help flag suspicious domains or suspicious signing patterns during list hygiene checks.

When you're building or maintaining an email system, always assume the worst: that every part of the signature can be broken by a small coding mistake. Let’s make sure your signing library uses a well-known, RFC 4648-compliant Base64 encoder — not a custom one with untested behavior. If you're unsure, test with real email providers, not just mock validators. The difference between delivery and rejection can be a single equal sign.

How to ensure consistent DKIM signature formatting across your email system?

Use established email libraries like DKIMCore or OpenDKIM instead of custom code. Validate every signature with an independent tool before sending, and integrate real-time verification—like MailTester’s API—into your workflow to catch formatting errors, including missing padding in the base64-encoded b= tag, before they hit production.

Start with proven libraries, not custom implementations

  • Never write your own DKIM signer. Even minor deviations—like incorrect base64 padding in the b= tag—break validation. Libraries like OpenDKIM or DKIMCore handle padding, signing order, and header normalization consistently.
  • Custom code often assumes it's handling the full algorithm, but missing small details like trailing padding equals a failed signature. This is common in poorly documented implementations or hastily built systems.
  • Adopting a well-documented, community-tested library reduces the risk of protocol-level errors. RFC 6376 (the DKIM standard) specifies strict formatting rules; tools built with this in mind follow them reliably.

Validate signatures before sending

  • Don’t rely solely on your own system to validate its output. Use independent tools like DKIM Analyzer or MxToolbox’s DKIM tool to verify signed messages externally.
  • These tools parse the DKIM-Signature header, decode the b= value, and check for correct base64 padding and length. They’ll flag missing padding—e.g., if the string ends in ... instead of == or =—which breaks verification.
  • Running these checks as part of a pre-send validation step catches format issues before they affect deliverability, especially in bulk or automated campaigns.
  • Integrate MailTester’s real-time verification API into your sending workflow. It checks not just deliverability but also DKIM signature format, flagging missing padding and other structural flaws.
  • Use the email checker for individual addresses in development or debugging mode to test specific cases.
  • For bulk sends, validate your list with bulk email verification to catch patterns of malformed signatures across your domain.
Even one malformed DKIM signature in a high-volume email can trigger reputational flags. Consistent formatting is not optional—it’s part of the signature’s integrity.

How does MailTester’s verification process detect base64 padding errors?

MailTester checks DKIM signatures by parsing the full DKIM-Signature header and enforcing strict base64 decoding rules on the b= value. It verifies that the string length is divisible by 4 and that any required padding (the = character) is present and correctly placed—catching even a single missing or misplaced = that would break validation.

Strict Base64 Decoding Detects Hidden Errors

Base64 encoding requires output lengths to be multiples of four. When the b= value doesn’t meet this, decoding fails. MailTester doesn’t skip ahead—it checks the length first, then validates padding. A single missing = at the end of a short signature breaks the sequence, and MailTester flags it immediately.

Unlike some tools that assume or tolerate malformed input, MailTester treats RFC 4871’s rules literally. For example, a signature like b=abc instead of b=abc= fails to parse, and MailTester reports this exact failure. You can test this behavior directly in our email checker, which processes DKIM in real time.

Why This Matters for Deliverability

DKIM validation fails if the signature is malformed, even if the key itself is correct. A missing = breaks the cryptographic chain, causing receivers to reject the email—even if otherwise legitimate. This isn’t just a parsing issue; it’s a signal of flawed infrastructure, often indicating poor DKIM implementation.

MailTester catches these issues early. Whether you’re sending from a custom system, a third-party service, or an in-house email platform, validating the b= field’s encoding prevents deliverability drops. If you’re unsure whether your sender implementation is padding correctly, inbox placement testing can show how your messages behave in real mailboxes.

The full DKIM-Signature header must be parsed as intended. For details on how DKIM works at the protocol level, see RFC 4871, which defines the standard behavior of the b= tag.

Prevent DKIM signature issues before they affect your sender reputation

Incorrect DKIM signature formatting—like missing base64 padding in the b= tag—can trigger validation failures, leading to rejected emails and damaged sender reputation.

MailTester’s bulk verification and inbox-placement testing catch these flaws before you send to large lists, ensuring your messages meet technical standards.

The tool explicitly flags signature validation issues, including base64 padding errors, giving you clear, actionable insights. With 98.9% accuracy and credits that never expire, MailTester supports consistent deliverability across campaigns.

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 happens if the b= tag in DKIM has no padding?

The signature is considered malformed during validation. Receiving servers will reject the DKIM check, leading to delivery issues or spam filtering.

Is missing base64 padding a common DKIM error?

Yes, it’s frequently seen in custom or poorly tested signing implementations, especially when non-compliant libraries are used.

Why does base64 require padding characters?

Base64 encodes data in chunks of 6 bits, and the output length must be a multiple of 4. Padding ensures correct decoding.

Can a single missing = character break DKIM?

Yes. Even one missing = at the end of the b= tag is enough to cause validation failure due to improper encoding.

How can I test if my DKIM signature is properly padded?

Use a Base64 decoder to check the length of the b= value. If not divisible by 4, add the required = characters.

Does MailTester detect this type of DKIM syntax error?

Yes. MailTester’s inbox placement tests validate the full structure of DKIM signatures, including base64 padding.

What’s the best way to fix a DKIM signature with missing padding?

Review your signing logic, ensure it follows RFC 4648, and apply standard Base64 encoding with correct padding.

Can tools like MxToolbox detect missing DKIM padding?

Yes, MxToolbox performs DKIM validation and can flag malformed b= values, though it doesn’t provide granular feedback on padding.

Is this issue limited to certain email providers?

No. All major providers (Gmail, Yahoo, Outlook) enforce strict DKIM validation, including proper Base64 formatting.

Why should I care about base64 padding if SPF and DMARC are OK?

DKIM failure alone can trigger spam filters or rejection, even if SPF and DMARC pass. It impacts inbox placement and sender reputation.

How does MailTester’s AI assistant help with DKIM issues?

It interprets verification results, identifies common errors like missing padding, and offers actionable corrections during testing.

Can I test my DKIM setup without sending live emails?

Yes. MailTester’s inbox-placement tests simulate delivery using real provider environments without sending to real users.