DKIM b= Base64 Padding Error Explained

What causes a DKIM b= signature to fail with a base64 padding error?

You sent a message. The DKIM signature looked right in the headers. But the receiving server rejected it anyway — “invalid base64 padding” — and you’re staring at the error like it’s a puzzle with no solution.

Here’s the reality: DKIM signatures are strict. The b= value must be perfectly encoded in base64, with correct padding. Even one missing = character can break it entirely. This isn’t a lenient validation — it’s a requirement. And getting it wrong means your email fails authentication, no matter how clean the content is.

When the length of the base64-encoded signature isn’t divisible by 4, the padding is missing. That’s what causes the base64 padding error. The server sees a malformed string — not just a mistake, but a violation of the standard.

Key takeaways

DKIM b= signatures must use strict base64 encoding with exact padding using = characters.
Any base64-encoded string length not divisible by 4 results in a padding error and signature rejection.
Even a single missing = character invalidates the signature; no server will accept it as valid.

Why is base64 padding required for DKIM signature values?

Base64 padding with '=' is required because DKIM signatures must be encoded in groups of three bytes, producing four output characters per group. If the final group has fewer than three bytes—common with short or uneven inputs—the decoder cannot parse it without padding. Without '=' signs, the signature appears incomplete, causing validators to reject it, even if the cryptographic content is correct.

How Base64 Groups Bytes and Why Padding Matters

Base64 works by grouping input data into chunks of three bytes, converting each into four printable ASCII characters. When the total length isn’t divisible by three, the last group is incomplete. For example, two bytes become only two output characters—this is where padding comes in. The missing characters are filled with '=' signs to signal the decoder: "this group is not full." Skipping padding breaks the encoding structure.

DKIM validators expect this format exactly. A missing or incorrect padding character means the signature fails to decode, even if the cryptographic key and message match. This results in a validation failure, often logged as a "b= signature error" in bounce reports. It’s not a flaw in your key—it’s a parsing issue caused by improper encoding.

Common Causes and How to Fix Them

When you see a "base64 padding error," it usually means someone or something—like a poorly written signing library—generated the signature without properly handling final byte groups. Email systems, including those used by major providers, follow RFC 4871 and RFC 2045, which strictly define Base64 encoding including padding rules.

Let’s say you’re using a custom script or a lesser-known email library. If it omits padding on purpose (e.g., for brevity), it will fail in production. Always ensure your signing tool respects the standard. Most modern libraries—like those in OpenSSL or Python’s base64 module—handle this automatically.

Want to catch encoding errors before they hit your sending infrastructure? Run your DKIM signature test with a live inbox placement tool. You can simulate how your emails land across providers, including detecting base64 issues early.

Test your email delivery and inbox placement with real-world checks across major providers to catch DKIM, SPF, and header issues before sending at scale.

How do invalid signature lengths trigger base64 padding errors in DKIM?

DKIM signatures must be base64-encoded, and base64 strings require a length divisible by 4. If your signature is 310 characters long (310 mod 4 = 2), it's invalid without proper padding. Missing '=' characters at the end breaks the encoding scheme, causing verification failures even if the content is correct. Tools like MailTester’s email checker can spot these issues early before they trigger delivery problems.

Why base64 requires length divisibility by 4

Base64 encoding works by grouping input bytes into chunks of 3, then representing each chunk with 4 characters. That means every valid base64 string must be a multiple of 4 in length. A 310-character string isn't divisible by 4, so without padding, it’s syntactically incorrect. This isn't a minor glitch—it breaks the decoding process entirely.

Let’s say you have a 310-character signature. Without padding, the decoder expects a 312-character string. The missing two '=' signs mean the final chunk isn’t complete. Even if the content is correct, the system rejects it as malformed. This is why padding isn’t optional—it’s part of the specification.

How signature length errors manifest in practice

When a DKIM signature has the wrong length and missing padding, receiving servers return a syntax error during verification. You won’t see a “bad signature” message—you’ll see “invalid base64” or “invalid length.” These are silent killers of deliverability, especially in regulated industries where every email must be authenticated.

Many senders assume the signature content is the issue. But the real problem is often just a missing padding character. Tools like the MailTester email checker can validate both syntax and structure, catching these encoding flaws before they affect inbox placement.

For a deeper look at how base64 works in email authentication, see RFC 4648, the standard defining base64 encoding. It explicitly states that padding is required when the input length isn’t divisible by 3, which directly affects encoded output length. You can’t skip it and expect compatibility.

Even with correct cryptographic keys, an improperly formatted signature will fail. Always validate the full DKIM structure—including length and padding—before sending. A single missing '=' can mean the difference between delivery and outright rejection.

How to verify if your DKIM signature has correct base64 padding

DKIM signatures must have valid base64 padding — if the length isn’t divisible by 4, the last character must be '='. If it’s not, the signature is malformed and will fail validation. Use actual email content and tools like openssl dgst -sign to check, not just DNS records. The signature in the email header is what matters, not the key in DNS.

Check the signature length and padding

Locate the d= and s= tags in your DKIM header; find the b= value.
Count the characters in the b= value. If it’s not divisible by 4, it’s invalid. Base64 requires padding with '=' to make length divisible by 4.
Confirm that any missing characters are properly padded: one '=' if the length is 1 mod 4, two '=' if it’s 2 mod 4. No padding or wrong padding causes failure.

Validate with real tools — not just DNS

Extract the full DKIM-Signature header from a delivered email (use tools like HTTP header inspection or email debuggers) and copy the b= value.
Use openssl dgst -sign or a DKIM validator to test signature structure. These tools will fail visibly if padding or length is wrong.
Verify the signature against your public key stored in DNS, but only after confirming the encoded signature is structurally sound. A DNS key doesn’t fix a malformed b= value.
Don’t rely on online checkers that only parse DNS. They can’t detect base64 padding errors in the actual email payload.

Let’s be clear: the signature in the email is the only one that counts. DNS records define the key, but not the signature syntax. A valid key with an incorrect padding in the b= value still results in a failed verification. This is a common issue in systems that generate DKIM signatures programmatically, especially with older libraries or misconfigured signing processes.

The 3 steps described in “Check the signature length and padding”, in order.

Base64 encoding requires padding with '=' to ensure data integrity when the length isn’t divisible by 4. This is defined in RFC 4648.

If you're troubleshooting DKIM issues at scale, use a service like MailTester’s email checker to validate delivery-ready emails, including header-level checks like DKIM syntax, before sending. It helps catch issues early, especially in bulk campaigns where one invalid signature can degrade sender reputation.

Common misconfigurations that lead to invalid DKIM b= values

If your DKIM b= signature has a base64 padding error due to invalid length, it’s likely because the signing process omitted padding for short or modified strings, or a manual edit broke the base64 structure. This happens when tools skip padding on short or incomplete outputs, or when you edit the header without re-encoding. Base64 requires full padding (three or four characters for any incomplete block), and some parsers fail if that’s missing. The RFC 4871 specification mandates proper base64 encoding with padding, so invalid length often points to a configuration or automation flaw. Let’s walk through the most common culprits.

Signature generation that skips padding

You’re using a custom signature generator that omits padding for short outputs—this is a frequent mistake when testing or building from scratch.
Some tools or scripts output raw base64 without adding the required = characters, especially when the signature length isn’t a multiple of 4.
Even small changes to the canonicalized body or header can alter the length, but if the generator doesn’t re-encode with proper padding, the signature breaks.

Manual header edits without re-signing

Editing the DKIM header (like h=from:subject) directly in a message and forgetting to re-sign leads to a mismatch between the body and the b= value.
Base64 decoding tools that don’t expect padding will fail if you paste a signature like abcde—this isn’t valid, and you’ll see length errors.
If you modify an email’s content after signing, you must re-sign from scratch. A single change invalidates the original hash and signature.

According to RFC 4871, Section 3.2, any base64-encoded string in a DKIM signature must be properly padded with = if the length isn’t a multiple of 4; this is non-negotiable for validation.

It’s easy to overlook padding when debugging, especially when working with short test signatures. But missing it breaks the entire verification process. Tools that don’t enforce padding during generation or allow raw edits risk producing invalid headers. If you’re validating DKIM records, a single email check can reveal if the signature’s encoding is malformed before sending at scale.

Is there a way to catch DKIM signature errors before sending emails?

You can catch DKIM signature errors early using real-time email verification and inbox placement testing tools. These tools check the full email header structure—including DKIM parameters—before messages are sent, flagging malformed signatures like those with invalid length or incorrect Base64 padding. Testing with actual email clients helps expose issues before they cause bounces or spam classification.

Why testing matters at the header level

Digital signatures like DKIM rely on precise formatting. A single error in Base64 encoding or a signature length mismatch can break authentication, even if the rest of the email is correct. Since many email systems enforce strict parsing, even small flaws can trigger rejection. Tools like MailTester validate the full header during inbox placement tests, simulating how real receivers interpret your message.

For example, the DKIM specification requires that signature values be properly Base64-encoded and that their length matches expected parameters. When a client sees a signature with non-standard padding (e.g., missing trailing '=' signs) or illegal character sequences, it may reject the email outright or mark it as suspicious. These checks aren't usually visible during basic validation—only through full header inspection.

How to test for DKIM issues before sending

Tools that simulate actual recipient systems—like MailTester’s inbox placement testing—analyze the complete message structure, including signing headers, before deployment. By testing with real email client setups (Gmail, Outlook, Apple Mail), you detect structural flaws in time to fix them. This is far more effective than relying on simple syntax checks or post-send analysis.

Using real-time verification APIs (like MailTester’s email verification API) or bulk list tests (e.g., bulk email verification) allows you to flag problematic addresses and headers in advance. These tools don’t just check domain existence—they validate the full delivery path, including alignment and signing integrity.

When you fix DKIM issues early, you reduce bounce rates, improve sender reputation, and increase inbox placement. No amount of content quality will offset a malformed signature—authentication failures are detected before messages reach inboxes.

You don’t need to debug base64 padding errors in your DKIM b= signature manually. MailTester’s inbox-placement tests automatically check every header, including DKIM signature integrity, and flag issues like malformed base64, incorrect padding, or invalid length before your message even leaves your server. This prevents reputation damage and inbox placement drops caused by technical failures that look like spam to receivers.

Real-time DKIM integrity checks during deliverability testing

When you run an inbox-placement test on MailTester, it doesn’t just simulate delivery — it validates how your email is structured end-to-end. That includes parsing the DKIM-Signature header, checking that the b= tag contains properly encoded content, and verifying that base64 padding conforms to the RFC standard. A single missing padding character or an improperly wrapped line can break the signature verification process, leading to hard bounces or rejection.

MailTester’s system catches these subtle problems early. If your DKIM signature has a length that doesn’t match the expected digest length, or if base64 encoding includes invalid characters or wrong padding (like = instead of ==), it will be flagged in the report. This avoids the scenario where your email passes initial validation but fails downstream due to cryptographic inconsistency.

Accuracy and proactive issue detection

Using a model trained on millions of delivery events, MailTester identifies not just outright errors but subtle patterns that correlate with low inbox placement — including malformed DKIM signatures, even when they’re technically valid. This 98.9% accurate verification system helps you fix problems that might otherwise go unnoticed until your volume drops or your domain gets blocked.

For example, a DKIM signature with correct padding but an invalid length (e.g., too short or too long compared to the digest) can still fail verification. MailTester detects this and marks it as risky, helping you catch it before sending to real users. You can test this directly using the inbox placement tester or verify addresses at scale with bulk email verification.

Ultimately, MailTester helps you maintain sender reputation by surfacing technical issues that affect trust — not just deliverability. By ensuring DKIM signatures are correctly formed and validated across real email environments, you reduce the risk of your messages being rejected or marked as suspicious, even if the rest of your email is technically sound.

What happens when a DKIM signature fails due to base64 issues?

If a DKIM signature contains invalid base64 padding—like missing '=' characters or wrong padding length—the receiving server can't decode it properly. This failure often results in the message being rejected outright or marked as spam, even if the sender’s domain is reputable. Since DKIM verification is part of DMARC checks, a malformed signature can break authentication entirely, undermining trust in the entire email flow.

How base64 errors disrupt email authentication

DKIM signatures must be encoded in base64 with correct padding. If the length of the signature is not a multiple of 4, and lacks proper padding, the receiving server rejects it during parsing. This is not a soft failure—it’s a hard rejection at the protocol level. The RFC 6376 specification (the standard for DKIM) requires strict adherence to base64 encoding rules, including the use of padding where needed.

Let’s say your mail server or sending tool generates a DKIM signature with a length of 38 bytes—missing one padding character. The receiving server sees this as invalid and cannot proceed. Even if SPF passes, DMARC validation will fail because DKIM is one of the three required authentication methods. Many receivers, including Gmail and Outlook, treat this as a sign of poor technical hygiene, even if the domain has a good reputation.

Long-term impact on deliverability

Repeated DKIM signature failures—especially due to encoding issues—can hurt sender reputation. Major providers track technical compliance over time. A single malformed signature may be ignored, but consistent problems signal unreliable infrastructure. This raises the risk of being flagged by anti-abuse systems or placed on temporary suspension lists.

Eventually, if your sending domain or IP shows a pattern of authentication failures, it may be blacklisted by services like Spamhaus or MxToolbox. Recovering from such a listing requires correcting the root cause and time, not just a single fix. That’s why validating your DKIM setup during testing is just as important as validating email addresses.

If you're sending bulk mail, use a tool like bulk email verification to test your email infrastructure—including headers, SPF, DKIM, and DMARC—before sending to real users. Catching encoding errors early avoids deliverability issues at scale.

Why SPF, DKIM, and DMARC must work together to ensure deliverability

You can’t rely on any one of SPF, DKIM, or DMARC alone—each has a distinct role in validating your email, and a failure in any one breaks the chain. SPF checks if the sending server is authorized, DKIM ensures the message wasn’t altered in transit, and DMARC enforces what to do when either SPF or DKIM fails. If any piece is missing or broken—even a minor DKIM signature error—reputable inboxes may reject your message outright or mark it as suspicious.

How each layer works—and why they need to align

SPF is like a guest list at a door. It checks whether the IP address sending the email is allowed to send on behalf of your domain. A misconfigured SPF record, or one that’s too long (over 255 characters), can cause a permanent failure and block delivery.

DKIM is your email’s digital fingerprint. It signs the message content using a private key, and recipients verify it with a public key published in DNS. If the signature has a base64 padding error—like missing padding characters when required—or if the signed header length doesn't match the actual data, the signature is considered invalid. Even a single character off breaks verification.

DMARC ties it all together. When both SPF and DKIM pass, DMARC lets recipient servers know what to do with your email. But if DKIM fails and SPF passes, or vice versa, DMARC evaluates the result and can quarantine or reject the email based on your published policy. That’s why having an incorrect DKIM signature—even if SPF is perfect—still harms deliverability.

Let’s say your DKIM signature has a missing padding character in the base64-encoded hash. The recipient’s server tries to decode it, can’t, and logs it as a failure. Even if your SPF is correct and your DMARC policy is set to “none,” this failure can still hurt your sender reputation over time, especially if it’s repeated across multiple messages.

How to prevent a single failure from wrecking your delivery

Use a real email-verification tool like MailTester’s bulk verification to catch invalid or risky addresses before sending. That stops you from sending to domains with broken configurations—like those with misconfigured DKIM or SPF. You can test your own messages with MailTester’s inbox placement test to see how major providers like Gmail and Outlook evaluate your authenticated messages.

For real-time validation, integrate MailTester’s API into your flow to confirm address validity and SMTP-level reachability. It checks for issues like catch-all accounts, role addresses, and disposable domains—common causes of delivery failures.

According to RFC 7208, SPF must be properly published and validated. RFC 6376 defines DKIM’s signature format, including base64 padding rules. Sticking to standards protects your deliverability.

Bottom line: SPFs, DKIMs, and DMARC don’t work in isolation. One gap in the chain—like a misformed DKIM signature—can trigger a full rejection. Regular checks with a tool that tests both syntax and behavior help you stay ahead of delivery issues before they cost you engagement.

How to prevent DKIM issues during list sends and email campaign delivery

DKIM signatures fail when headers or body content don’t meet strict formatting rules—especially if the b= value has incorrect Base64 padding. This usually happens when email infrastructure passes malformed or unverified data, leading to delivery failures or inbox filtering. You fix this by validating your list and sender setup before sending.

Sending clean data starts with list hygiene

Before every campaign, run your entire email list through bulk email verification to catch invalid, role-based, or disposable addresses.
Role addresses like admin@, support@, or info@ often trigger false positives in DKIM validation due to lack of real delivery paths or strict SPF/DKIM alignment.
Use tools that test both syntax and delivery behavior—not just domain presence—to avoid sending to addresses that reject mail after TLS handshake.

Integrate verification into your workflow

Use MailTester’s real-time verification API to validate each email address as it enters your CRM or email platform.
Integrate this API with SendGrid, Mailchimp, or Klaviyo to block invalid addresses before they trigger server-side DKIM checks during send.
The system checks headers, syntax, MX records, and catch-all responses—ensuring only valid, deliverable recipients are included.
Check your sender setup in real time with inbox placement tests to see how your DKIM signature performs across Gmail, Outlook, and other major inboxes.
For full transparency, review the detailed results of each verification—like whether a domain uses role-based mailboxes or greylisting—which can affect header validation.

DNS-based email authentication (SPF, DKIM, DMARC) only works if your mail is sent to valid, active endpoints. If the recipient isn’t real, the signature may appear malformed due to how servers handle unprocessed messages. This is why RFC 6376 (DKIM) includes strict rules around Base64 encoding—the b= value must be cleanly padded and not truncated.

“Even a single invalid address in a large list can trigger a chain reaction of failed DKIM verifications across multiple recipients.”

Preventing this doesn’t require complex code—it just means validating the input data. The most reliable way to do that is using a system designed to test both the address and the domain’s ability to receive mail. MailTester's 98.9% accuracy rate reflects real-world performance across all email types, including tricky catch-all responses and disposable domains.

Fixing DKIM b= signature errors in practice: what to check

DKIM signature validation fails when the b= value doesn’t adhere to base64 encoding rules, especially when padding is missing or incorrect. This often happens due to improper signing logic or misconfigured infrastructure.

Verify selector and domain alignment

Ensure the DKIM selector and domain in your DNS record match the actual sending setup. A mismatch prevents proper verification even if the signature is technically valid.

Check signing process and padding

Base64 encoding requires padding with = characters when the length isn’t a multiple of 4. Signature tools must apply this correctly after signing. Manual or custom implementations often omit this step.

Validate using trusted tools

Use tools like MXToolbox or MailTester to test the full email header and verify the DKIM signature in real-world conditions. These services replicate recipient-side checks and highlight padding or length issues you might miss locally.

Sources

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)
95% of Fortune 500 companies have valid DMARC records and more than 80% have moved to enforcement-level policies, while more than half of DMARC-enabled Inc. 5000 firms still sit at p=none. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)

Keep reading

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

Frequently asked questions

Can a missing '=' in a DKIM signature cause delivery failure?

Yes. A missing padding character in a base64-encoded DKIM signature is a syntax error that causes rejection by receiving mail servers.

What length should a DKIM b= signature be?

The length must be divisible by 4. If not, the signature must end with one or two '=' padding characters.

How can I test my DKIM signature before sending?

Use MailTester’s inbox-placement test or a header analyzer tool to verify DKIM structure, padding, and authenticity.

Does DKIM signing need to follow RFC 6376 exactly?

Yes. DKIM signatures must conform to RFC 6376, including base64 encoding rules and correct header syntax.

Why does my DKIM signature work in test tools but fail in production?

Test tools may ignore minor padding errors. Production servers apply strict RFC 6376 validation, rejecting malformed signatures.

Can a DNS record show a valid DKIM key but still fail in email headers?

Yes. The DNS record contains the public key, but the actual signature in the email must be correctly generated and padded.

How do disposable or role addresses affect DKIM validation?

They don’t affect DKIM validation directly, but sending to invalid or high-risk addresses can harm sender reputation and indirectly reduce deliverability.

Is there a free way to test DKIM signature formatting?

Yes — MailTester offers 100 free verifications to test email headers, including DKIM structure, no credit card required.

What’s the relationship between DKIM and sender reputation?

Repeated DKIM failures signal poor mailing practices, which degrade sender reputation and reduce inbox placement.

How often should I audit DKIM configurations?

At least monthly, especially after server migrations, email platform changes, or updates to signing logic.

Do all email clients and servers validate DKIM uniformly?

Most do, but variations exist. All serious servers enforce RFC 6376, so valid base64 and correct padding are required.

Can email marketing platforms automatically fix DKIM signature padding errors?

No. The platform must ensure its signature generation process includes correct base64 padding. Verification tools like MailTester help detect issues.