Why does DKIM fail silently despite a valid signature?

You’ve checked the DNS record. The selector matches. The private key is correct. Your DKIM signature validates in the tool. Yet emails still fail. Why?

Because a single missing character — a missing = in the b= field — can break the entire signature, even if everything else appears fine. DKIM validation is strict: it relies on precise base64 encoding, and padding is non-negotiable.

The b= field must contain a properly padded base64 string. A single character off — missing padding, incorrect line breaks, or malformed encoding — triggers rejection, even by receivers with no public logs to explain it. This is why DKIM fails silently: the failure is in the encoding, not the key or DNS.

Key takeaways

  • DKIM signatures require the b= field to be strictly base64-encoded with correct padding using '=' characters.
  • Misencoded or unpadded base64 in the b= field causes silent rejection by strict email receivers, even if the signature appears syntactically valid.
  • Even small syntax errors in the b= value — such as missing padding or line breaks exceeding 76 characters — invalidate the signature and prevent authentication.

What causes the most frequent syntax error in the DKIM b= field?

The most common DKIM b= field syntax error is missing one or more base64 padding '=' characters at the end of the signature. Base64 encoding requires the data length to be a multiple of 4 bytes, so padding is mandatory when it isn't. A 37-character signature needs one '=', 38 needs two, and 39 needs none — get this wrong, and the signature fails verification.

Why base64 padding matters in DKIM

Base64 encodes binary data into ASCII text using a 64-character alphabet. Every 3 bytes of input become 4 characters of output. If the input isn’t a multiple of 3 bytes, padding with '=' ensures the decoder can reconstruct the original data correctly. DKIM signatures are binary blobs signed with an algorithm, then encoded — so the final b= field must be valid base64.

Let’s say your signature is 37 characters long. That’s not a multiple of 4. The decoder expects exactly 36, 40, 44, etc. — so one '=' padding is added to make it 38, which still doesn’t fix it. The correct length for 37 characters is 40 after padding — so you’d need two '=' characters. Missing even one can break the entire signature, leading to a DKIM verification fail.

This error often shows up in raw email headers or DMARC reports, where you see "DKIM verification failed" without much context. The root cause is usually malformed or truncated base64 in the b= field. It's easy to overlook when generating or testing DKIM signatures, especially if you're using a custom script.

Many email providers, including Gmail and Microsoft’s systems, perform strict base64 validation. A single missing pad can result in a failed DKIM check, even if the key and domain are correct. This is why tools that inspect real headers or simulate sending are valuable — they catch these edge cases early.

Understanding this helps when debugging deliverability issues. If you’re seeing DKIM failures in your logs, check the b= value’s length and padding. RFC 4880 (OpenPGP) and RFC 3548 (Base64) cover the encoding rules. A detailed explanation is available at IETF’s base64 specification.

How to validate DKIM signatures correctly

Running your messages through a tool like inbox placement testing helps catch these issues before sending. You can simulate how your email is received and parsed by major providers. If your DKIM is broken, you’ll get a clear signal.

For developers and sysadmins, using a trusted library to generate DKIM signatures — rather than hand-crafting base64 — reduces the risk. Most modern tools handle padding automatically. Still, if you’re manually encoding, remember: always validate the final length with modulus 4, and pad to the nearest multiple of 4.

Even a typo in the signature or a trailing space can break it. The safest approach is to use standardized tools and validate output using known test vectors.

How does base64 encoding work at the byte level in DKIM?

Base64 encoding converts every 3 bytes of binary data into 4 printable characters using a 64-character alphabet. If the input isn't a multiple of 3 bytes, you must add '=' padding to complete the final group. For example, 4 bytes of data produce 6 base64 characters—so the last two slots need padding with '=' to be valid. This is essential in DKIM, where the b= field must be syntactically correct to pass verification.

Breaking down the byte-to-character transformation

Each base64 character represents 6 bits of data. Since 3 bytes equal 24 bits, and 24 ÷ 6 = 4, you get exactly 4 characters per 3 bytes. When the input isn't divisible by 3—like 4 bytes—you end up with leftover bits. Without padding, the decoder can't determine where the data ends. The '=' symbol indicates how many bytes were missing in the final group.

Take a 4-byte input: 1 byte short of a multiple of 3. The decoder expects full groups of 3, so it treats the first 3 bytes as a complete unit (4 chars), and the remaining 1 byte as incomplete. To fix this, two '=' signs are appended, signaling that the data ends and the last group was only 1 byte long—meaning 2 of the 3 expected bytes were missing.

This rule isn't just a suggestion—it's defined in RFC 4648, the standard governing base64 encoding. If the b= field in a DKIM signature lacks proper padding, receiving mail servers reject it, even if the cryptographic content is correct. This is a common cause of DKIM failures.

Why padding fails in DKIM — real-world examples

Let’s say your signing software outputs a base64 string like abcd1234efghijkl for a 4-byte value. It should be abcd1234efghij==. Omitting the two '=' signs means the decoder expects 6 full characters but gets only 4. The result? A parsing error, signature invalid, and a failed DKIM check.

Even tools that claim to "validate DKIM" might miss subtle encoding issues if they don’t test the byte-level structure. This is why some tools show a "pass" while mail servers still reject your messages. The problem isn't the key or the signature—it’s the padding.

Use a robust email verification service to catch malformed DKIM signatures before they hit inbox filters. You can test your sending setup with inbox placement tests that include DKIM parsing checks, ensuring your full email stack is clean and compliant from start to finish.

What happens when the b= field has incorrect or missing padding?

If the DKIM b= field lacks proper base64 padding (the trailing = characters), receiving servers often fail to parse the signature entirely. Even if decoding proceeds, incomplete padding causes hash mismatches during validation—meaning the signature is rejected as invalid, even when the key and selector are correct. This breaks the chain of trust in email authentication.

Why base64 padding matters in DKIM

Digital signatures in DKIM are encoded using base64, which requires padding with = characters to ensure the encoded block size is a multiple of four. Missing or incorrect padding breaks the parsing process. Since DKIM validation relies on successfully decoding the signature to check the hash, any failure here means the message fails authentication.

Let’s say your signing process outputs a b= value like abc123def instead of abc123def=. That’s not a valid base64 string. A receiving server attempting to decode it might silently drop the signature or produce an inconsistent hash. The result? The email appears to lack valid authentication—even if your domain is properly set up.

According to RFC 4648 (the standard for base64 encoding), missing padding leads to undefined behavior. This isn’t a minor issue—it’s a core syntax violation. Receiving systems are designed to reject such payloads outright, and many do so without warning. The failure doesn’t show up as a "spam" rating; it shows as a hard DKIM failure, which can lead to filtering, rejection, or delivery to spam folders.

How to avoid these errors in practice

These mistakes usually come from manual string manipulation or flawed signing libraries. Let’s be honest: it’s easy to mess up padding when you’re building a signature by hand. Even some email tools or libraries skip proper padding, especially if they’re not rigorously tested against real-world receivers.

Using a tool like MailTester’s bulk verification helps catch invalid headers—including improperly formatted DKIM signatures—before they go out to real recipients. While it doesn’t generate or sign emails, it can flag addresses with malformed authentication chains, helping you identify and fix issues in your sending infrastructure before they hurt deliverability.

Valid DKIM requires precision. No matter how strong your encryption key or correct your selector, one misplaced character in the b= field can invalidate the entire signature. That’s why automated validation—especially in bulk—matters. It’s not about chasing perfection. It’s about catching the kind of errors that quietly sabotage your inbox placement. A single missing = doesn’t sound like much. But in DKIM, it’s enough to break everything.

How to verify DKIM b= field syntax using a real tool?

You can verify DKIM b= field syntax errors—especially malformed base64 padding—by testing the full email signature with a tool that checks DNS, cryptographic structure, and encoding. Tools like MailTester analyze the actual DKIM signature, flagging invalid base64 padding, incorrect character sequences, or missing padding in the b= value, which are commonly missed by basic validators.

Step-by-step: How to catch base64 issues in DKIM signatures

  1. Fetch the full raw email from your sending system or a test send. Base64 encoding issues only show when the entire signature is examined, not in isolation.
  2. Upload the raw message to MailTester’s inbox placement tester (test real inbox delivery) or use the API to validate the DKIM signature. The tool parses the b= field and checks for proper base64 encoding as defined in RFC 4648.
  3. Review the DKIM validation result. If the signature is malformed, MailTester returns a clear error like “Invalid base64 padding in b= field” or “Invalid character in b= value.” This helps isolate encoding problems that break cryptographic validation.
  4. Verify the public key is correctly published in DNS. Even with correct base64, a mismatched or missing DKIM DNS record will cause signature verification failure. MailTester checks both the DNS record and its alignment with the message signature.
  5. Fix and retest. Correct the base64 padding (ensure it ends in one or two = signs, depending on byte length) and re-validate. Base64 must be properly aligned—no padding where it's not needed, and full padding where required.

Why base64 padding matters

DKIM signatures use base64 encoding for the b= field. RFC 4648 specifies that base64 strings must end with one or two = padding characters when the length is not divisible by 4. A missing or extra = breaks validation, even if the rest of the signature is correct.

A single missing = in the b= field can cause a DKIM signature to fail, even if all other parts are valid. This is often overlooked in automated checks.

Many basic tools only validate the address or parse the headers, but not the underlying cryptographic structure. MailTester checks the full chain, including the b= field’s syntax, padding, and alignment with the public key.

For developers or senders who automate email verification, using the verification API lets you validate DKIM syntax alongside address validity and inbox placement in one call. This prevents undeliverable messages due to subtle signature flaws.

What’s the difference between valid and invalid base64 in DKIM?

Base64 in the DKIM b= field must use only A–Z, a–z, 0–9, +, /, and = for padding. Extra spaces, line breaks, or incorrect padding (like three = signs for 3-byte data) break the syntax. The RFC 6376 specification defines this precisely—improper encoding triggers signature validation failure. Let’s see how it works in practice.

Valid vs. Invalid Base64: A Reference Table

Example Valid? Why Reference
abc123== Yes Two padding characters correct for three input bytes. Total length must be a multiple of four. RFC 4648, Section 4
abc123=== No Three padding characters imply 6 bytes of data, but only 6 characters before padding exist. Invalid length—requires multiple of 4. RFC 4648, Section 3
abc 123== No Whitespace inside the encoded field breaks the syntax. Base64 must be a single contiguous string. RFC 6376, Section 3.4
abc123= No Only one padding character—insufficient. Must be 0, 1, or 2 = signs, never one in isolation. RFC 4648, Section 4
abc123==\n No Line breaks are not allowed in the b= field. Must be a flat string. RFC 6376, Section 3.4

These rules aren't just technical nitpicking—misencoded b= values cause DKIM failures and can degrade sender reputation. Even a single whitespace character in the signature block triggers rejection by receiving servers that enforce strict syntax. Testing your DKIM output across multiple servers helps catch issues early.

If you're troubleshooting DKIM, use a free email checker to validate individual addresses and check for header-level misconfigurations. For bulk lists, bulk verification can surface encoding anomalies across thousands of messages, especially in automated email campaigns. Accuracy matters—our system validates real-world delivery logic, not just syntax.

Can your email software auto-correct base64 padding issues?

Most email software does not auto-correct base64 padding errors in DKIM signatures. If a b= field is missing padding (like trailing = characters), the signature is rejected immediately—no guesswork, no correction. Strict implementations enforce the full RFC 4880 base64 syntax and fail on any invalid character.

Why auto-correction is rare (and often unsafe)

Base64 padding is not optional—it’s required. Any deviation breaks the signature’s integrity. Because DKIM is designed for cryptographic verifiability, receivers treat malformed input as a failure, not a recoverable error. This isn’t a tolerance issue; it’s a correctness one.

Let’s be clear: no major email server or library attempts to fix missing or incorrect padding. Libraries like OpenDKIM, Python’s email module, and even common mail transport agents (MTAs) will reject a signature with an incomplete or malformed b= field. They don’t rewrite what they find wrong—they simply reject the message.

Only syntax-aware tools catch padding before sending

Only tools that validate the full DKIM syntax—especially the base64 encoding—can catch padding issues before you send. These tools parse the b= field explicitly, checking for valid padding, character set, and line breaks. Without this check, your signature may go undetected until it’s rejected by an inbox provider.

For example, RFC 4880 defines base64 encoding with mandatory padding. The = character is part of the standard—omitting it means the signature is invalid by construction. Real-time validation is the only way to ensure this doesn’t happen.

If your email platform generates DKIM signatures programmatically, verify them on a per-address basis before sending. Use a dedicated email verification service like MailTester's email checker to validate both the address and its cryptographic signatures in bulk. You can catch syntax errors early, before they hurt deliverability.

How to test and prevent DKIM b= field issues before sending?

Run your test emails through a real inbox-placement tool like MailTester’s inbox tester to catch DKIM signature issues—especially base64 padding errors—in a live delivery path. Verify the signed DKIM header using a DNS and header analyzer, and ensure your email library or ESP handles base64 encoding with proper padding (==) at the end. These steps prevent rejection due to malformed signatures.

Check your DKIM signature in a real delivery environment

  • Send a test message to a verified inbox and check the full email headers using MxToolbox or SMTPcheck to inspect the DKIM-Signature field.
  • Look for the b= value in the header. If it ends with a single = or has no padding, it’s invalid—base64 requires padding with == for every incomplete 4-byte group.
  • Use MailTester’s inbox placement tester to see how your message performs in real inboxes, including DKIM validation checks across major providers like Gmail, Outlook, and Yahoo.
  • Confirm that the entire b= value is correctly base64-encoded, including the exact 64-character alphabet and proper padding.

Ensure your tools handle base64 encoding correctly

  • Review your email service provider’s documentation or contact support to confirm that DKIM signing uses standard base64 encoding with == padding. Some libraries strip padding or use non-standard encodings.
  • If you’re using a custom signing library, test it with known-good inputs—like the example from RFC 6376, Section 3.4, which specifies the required padding.
  • Use MailTester’s verification API in your pre-send workflow to validate individual addresses and detect potential delivery risks early.
  • Test bulk lists with bulk verification to catch repeated signature issues across multiple sends before they hit your inbox.
Malformed DKIM signatures due to improper padding lead to rejection even if all other headers are correct. The fix is simple—ensure your signing tool follows base64 standard requirements.

How does MailTester help prevent DKIM b= encoding failures?

You don't have to guess if your DKIM b= field is correctly base64-encoded. MailTester checks the full cryptographic signature during deliverability testing, catching missing padding, invalid characters, or incorrect header inclusion before they break authentication. With 98.9% accuracy, it flags syntax issues in the b= field—like improper padding (e.g., missing '=' signs) or non-base64 chars—so you can fix them early and protect your sender reputation.

How MailTester catches DKIM syntax issues

DKIM signatures rely on strict structure. The b= field must be valid base64, including correct padding with '=' at the end. Even one missing character breaks the signature. MailTester validates the complete signature, not just the address. It detects when padding is incomplete—common when signing tools omit padding during encoding—and spots non-base64 characters silently inserted by flawed scripts.

Base64 encoding uses a specific alphabet (A–Z, a–z, 0–9, +, /) and requires padding with '=' to make lengths multiples of 4. If your signing process drops or adds padding incorrectly, the signature fails validation. This often happens in custom code or with misconfigured email platforms. MailTester verifies that the b= value matches the expected format, flagging these issues as "invalid base64" or "padding error."

Additionally, MailTester checks for correct header inclusion in the signature. The signed headers must match exactly what’s in the message, with no extra spaces or missing fields. If the header list references a field that wasn’t signed—or if a header is included in h= but not in the message—MailTester flags it. This kind of mismatch causes the signature to fail when receivers verify it, even if the b= field looks correct.

Why this matters for sender reputation

DKIM failures don’t always result in immediate bounces, but they degrade sender reputation over time. Receiving servers track authentication consistency, and repeated signature issues signal poor email hygiene. Even a single failed DKIM check can make your messages look suspicious—especially if they come from a domain with weak or inconsistent signing.

MailTester’s inbox placement tests include DKIM validation as part of a full mail stream simulation. You’re not just checking for syntax errors—you’re seeing what happens in real inboxes. If your DKIM fails in MailTester’s tests, it likely fails in Gmail, Outlook, or Yahoo, reducing inbox placement and increasing the risk of being filtered or blocked.

Fixing these issues early helps avoid long-term reputation damage. You can test individual addresses with MailTester’s email checker, validate entire lists via bulk verification, or integrate checks into your workflow using the real-time verification API. All are designed to catch encoding issues before they impact delivery.

What impact do DKIM b= syntax errors have on deliverability?

DKIM b= field syntax errors—especially incorrect base64 padding—break message authentication, leading to failed verification. This reduces sender trust, increases spam likelihood, and can lower inbox placement by up to 20% in strict environments. Even one malformed signature can trigger filtering or reputation penalties over time.

How authentication failures affect sender reputation

When a DKIM signature fails due to improper base64 encoding (like missing or wrong padding), receiving servers flag the message as untrusted. This isn't just a technical hiccup—it signals instability in your sending infrastructure. ISPs and email providers track these failures over time; repeated issues reduce your sender reputation. A single misformatted b= value isn’t catastrophic alone, but consistent errors show up in aggregate scores used by systems like Google’s and Microsoft’s spam filters.

Let’s be clear: even if the rest of your alignment is solid (SPF, DMARC, proper headers), one malformed DKIM signature can be enough to trigger scrutiny. The receiving server may not reject the email outright, but it may apply additional filtering. This reduces the chance it lands in the primary inbox, especially under strict filtering policies like those used by Gmail or Outlook.

Why base64 padding matters in DKIM b= fields

DKIM signatures are encoded in base64, and the encoding must be correct—this includes proper padding with '=' characters to ensure the length is a multiple of four. If the b= field is missing padding or has an incorrect number of padding characters, the decoder cannot reconstruct the signature. The result is a failed validation, even if the cryptographic key or domain is correct.

For example, a signature like abc or abc= is invalid. It must be abc= for 3 characters, or abcd== for 4. Many tools, especially in custom or legacy systems, generate these signatures incorrectly. You can verify this behavior using tools like RFC 6376, which describes DKIM's requirements for signature encoding.

If you’re not regularly checking your outbound messages for DKIM validity, you might be sending messages that appear broken to receivers. Using a tool like the inbox placement tester can catch issues like this before they affect your reputation. For bulk validation, the bulk email verification tool includes DKIM checks as part of its full address assessment. It helps you catch formatting issues across large lists, ensuring only properly signed messages go out.

Fixing the DKIM b= field is not optional — it’s required.

Base64 padding with '=' characters is mandated by RFC 4648. Omitting it or using incorrect padding breaks the encoding standard and causes DKIM verification to fail across major providers.

Even minor deviations—like missing one padding character—can result in authentication failures. Interoperability depends on strict adherence to specifications, not convenience.

Pre-send validation is non-negotiable

  • DKIM signature validation should be included in every email campaign’s pre-send checklist.
  • Use tools that validate the complete DKIM record, including proper base64 encoding of the b= field.
  • Manual checks are error-prone. Automated verification catches flaws before they damage sender reputation.

Sources

Keep reading

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

Frequently asked questions

Why is my DKIM signature failing even though the key matches?

The most common cause is incorrect base64 padding in the b= field. Verify the signature length and ensure it ends with one or two '=' signs as needed.

Can DKIM still pass with a missing padding character?

No. Receiving servers that enforce strict RFC compliance will reject signatures with invalid base64, even if the key is correct.

How do I test if my DKIM b= field has proper padding?

Use a DKIM validator or an email verification tool like MailTester to check the full cryptographic signature and syntax.

What happens if I send emails with malformed DKIM signatures?

Messages may be rejected, marked as spam, or fail sender reputation checks. Some providers block domains with repeated issues.

Do all email providers reject incorrectly padded DKIM signatures?

Most major providers (Google, Microsoft, Apple) enforce strict parsing and reject signatures with malformed base64.

Is base64 padding required for all DKIM signatures?

Yes. RFC 4648 specifies that base64 must use '=' padding when the encoded data length is not a multiple of 4.

Can a mail server accept a DKIM signature with extra padding?

No. Extra padding leads to decoding failure. The b= field must match the exact output of a correct base64 encoder.

How often do DKIM b= field encoding errors occur?

They occur frequently in poorly implemented email systems, especially those using custom signing logic without validation.

Can I fix DKIM b= padding after sending an email?

No. The signature is part of the original message. Fixing it requires re-sending with a correct signature.

How does MailTester help catch DKIM issues?

It validates the full email structure, including DKIM syntax, and reports issues like incorrect base64 padding in the b= field.