Validate DKIM Base64 Format

Why DKIM base64 encoding matters for inbox delivery

You send an email that passes SPF and DMARC—so why is it landing in spam?

One overlooked detail can be the culprit: DKIM signature encoding. Even a single missing padding character in the base64 string can break the entire authentication chain.

DKIM requires signatures to be properly encoded in base64, as defined by RFC 6376. Any deviation—wrong line breaks, invalid characters, or missing padding—results in a validation failure. Receiving servers don't tolerate errors. The outcome? Your message gets rejected, flagged as spam, or ignored entirely.

Validating DKIM with correct base64 encoding format in email header isn’t a minor detail. It’s a foundational requirement for inbox placement.

Key takeaways

DKIM signatures must follow RFC 6376 exact specifications, including correct base64 encoding with proper padding.
Even one incorrect character or missing '=' padding in the base64 string can cause the signature to fail validation.
Improper encoding bypasses authentication, increasing the risk of emails being rejected or marked as spam.

What does a valid DKIM signature header look like?

A valid DKIM-Signature header contains a properly base64-encoded value for the b tag, typically following the format: Dkim-Signature: v=1; a=rsa-sha256; d=example.com; s=brisbane; bh=abc123...; b=def456.... The b= value must be a clean base64 string with no line breaks, padding errors, or extra whitespace. Even a single invalid character can break the signature and trigger rejection.

Understanding the b tag

Let’s break down the b tag in that header. It contains the digital signature, which is an encryption result of the signed email content. This value must be encoded using standard base64—no padding quirks, no newlines, no spaces. If your email server or library adds line breaks (e.g., wrapping at 76 characters), the signature fails, even if the underlying data is correct.

For example, a valid b value might look like b=JrLX3vFw3qT2Y7nKx9tP2h6Z3vN2kDyJvE9mL2pGfBzQcRkYwTqZxN2wV1fPdE7sFm9kX4rRmTgVpXqWuNkZ8oJ2sRmK1nQ2wDz. Any deviation—like adding a newline after JrLX3vFw3qT2Y7nKx9tP2h6Z3vN2kDyJvE9mL2pGfBzQcRkYwTqZxN2wV1fPdE7sFm9kX4rRmTgVpXqWuNkZ8oJ2sRmK1nQ2wDz—invalidates it.

Why formatting matters

Mail servers validate DKIM by decoding the b tag and verifying the signature against the public key published in DNS. If the base64 decoding fails—due to trailing whitespace, incorrect padding, or line breaks—the server rejects the signature outright. This is not a soft failure; it’s a hard delivery block.

Standardizing your email headers is your best defense. RFC 6376 (the DKIM specification) defines the encoding and syntax precisely. You can review the full specification on the IETF’s official site here. This document is the definitive source for how DKIM headers should be structured.

If you're sending bulk email or building an email-sending system, validating the entire header stack—including the signature format—is essential. MailTester’s real-time email verification API helps catch these issues before they cost you in deliverability. You can test individual addresses for syntax, structure, and authentication readiness using our API. For large lists, bulk verification tools also scan for malformed DKIM records and other red flags across your entire list.

How to validate DKIM with correct base64 encoding format in email header

You can validate DKIM's base64 encoding by extracting the raw email header, locating the b= value in the DKIM-Signature field, confirming it uses only valid base64 characters (A–Z, a–z, 0–9, +, /, and = padding), and ensuring there are no line breaks or extra characters. Then decode it using a standard base64 decoder and check whether the result is a valid binary signature—any deviation indicates an encoding issue that can break authentication.

Step-by-step validation process

Retrieve the raw email source using IMAP, SMTP, or an email testing tool like MailTester’s inbox placement tester. The full header must be preserved to access the DKIM-Signature field exactly as it was transmitted.
Locate the DKIM-Signature header in the raw email. It will start with DKIM-Signature:. Look for the b= tag value, which contains the digital signature encoded in base64.
Verify the base64 format by checking that the string only contains valid characters: A–Z, a–z, 0–9, +, /, and = for padding. Any space, newline, or other character invalidates the encoding.
Check for formatting issues—DKIM signatures must be a single continuous string. No embedded line breaks or extra whitespace. If the value wraps across multiple lines, it’s incorrectly formatted.
Decode the signature using a reliable base64 decoder. The output should be a binary stream of fixed length (typically 256 or 512 bits, depending on the key size). The decoded result must match the expected format for the algorithm used (e.g., SHA-256).
If decoding fails or outputs invalid data, the base64 encoding is malformed. This could prevent mail servers from validating the DKIM signature, leading to rejected or marked emails.

Why validity matters

Invalid base64 encoding in DKIM breaks the chain of trust. Even a single incorrect character can mean the signature fails validation, resulting in emails marked as suspicious or rejected entirely. According to RFC 6376 (the DKIM standard), the signature must be encoded as a single, clean base64 string without whitespace or structure violations.

The 6 steps described in “Step-by-step validation process”, in order.

Tools like RFC 6376 and Spamhaus emphasize strict parsing during DKIM validation. If you're testing DKIM signatures at scale—especially before sending to large lists—using a tool that checks both format and behavior can prevent deliverability issues.

For teams automating verification, consider using MailTester’s verification API to check recipient addresses and validate header compliance in bulk, including DKIM-related header structure, before sending.

Common base64 encoding errors in DKIM signatures

DKIM signatures fail validation when base64 encoding is incorrect—most commonly due to missing padding, line breaks in the string, or invalid characters. Even small issues like a missing '=' or an extra space can cause validation to fail. You must ensure the encoded string is strictly compliant with RFC 6376, which mandates no breaks, no whitespace, and only valid base64 characters.

Common base64 encoding mistakes

Missing padding: Base64 strings must be padded with '=' to make their length divisible by 4. For example, 'abc123' is invalid; it must be 'abc123==' if it's 6 characters long.
Introducing line breaks: DKIM header values must not contain line breaks. Even a soft wrap in an email client’s display can break the signature. The entire base64 string must appear as a single, uninterrupted value.
Using spaces or tabs: Any whitespace inside the base64 string, or before/after the 'b=' tag, will cause parsing errors. The value must be clean and contiguous.
Including non-base64 characters: Hyphens, colons, quotes, or other symbols are not part of the base64 alphabet. These invalidate the signature regardless of content.
Incorrect character encoding: The digest used in DKIM must be generated with the same encoding as expected—typically ASCII or UTF-8. Using UTF-8 when the receiving server expects ASCII (or vice versa) causes hash mismatches.

These errors are especially common in email tools that generate DKIM signatures automatically but do not validate the output format. Even minor deviations from RFC 6376 compliance render the signature invalid.

How to verify your DKIM signature is correct

Let’s be clear: no automated system replaces human verification of key parts of your email setup. You can validate your DKIM signature using standard tools like RFC 6376, Section 3.4, which spells out the exact format. The signature must be a valid base64 string with no embedded line breaks, padding, or non-allowed characters.

Use our email checker to test individual addresses and validate the full email header structure, including DKIM signature formatting. It won’t catch every edge case in your signing process, but it can reveal malformed headers early—before they hurt your sender reputation.

If you're debugging a larger campaign, try our inbox placement tester to see whether your messages reach inboxes or get filtered. Poor DKIM formatting often leads to soft bounces or delivery failures.

Why you should test DKIM validation at scale

Testing DKIM validation at scale isn’t optional—it’s essential. A single misencoded DKIM signature using incorrect base64 formatting can trigger rejection across entire email batches, even if the rest of the message is valid. Automated verification catches these errors before they damage sender reputation, reduce inbox placement, or trigger blocks from ISPs like Gmail or Yahoo.

One flaw, many failures

DKIM relies on precise base64 encoding in the signature header. If the encoding is malformed—missing padding, incorrect character set, or broken line breaks—the entire verification fails. Since many email servers reject messages based on DKIM failure, a single bad signature in a 10,000-message campaign can cause delivery failure for all of them.

Even minor variations in how some email platforms handle encoding can lead to inconsistent validation outcomes. Without testing across real-world environments, you never know whether your DKIM signature will pass for every recipient.

Automated checks prevent real-world harm

Let’s be honest: manual header inspection isn’t scalable or reliable. You can’t spot subtle base64 encoding issues by eye, especially in bulk. Automated tools scan every outbound message, validate signature format against the DKIM standard (RFC 6376), and highlight deviations.

Real-time and bulk verification services—like MailTester’s bulk verification—can detect malformed DKIM signatures before they leave your system. By catching these issues during pre-send checks, you protect your sender reputation, avoid hard bounces, and maintain high inbox placement.

Some ISPs, like Google’s Postmaster Tools, flag inconsistent DKIM alignment as a red flag in sender reputation reports. A single failed DKIM test doesn't just impact that message—it can lower your overall score, leading to throttling or filtering.

That’s why testing at scale matters. It ensures your messages not only reach the inbox but are trusted. You don’t need a hundred thousand messages to benefit—just enough to find the flaw before it spreads.

As the IETF’s RFC 6376 makes clear, DKIM signatures must be base64-encoded with strict syntax rules. Deviation from those rules is not a minor glitch—it’s a delivery failure.

Using MailTester to verify DKIM and format correctness

You can validate DKIM signature correctness in email headers—including the base64 encoding format—using MailTester’s inbox-placement testing. It checks full headers during real inbox delivery tests, automatically confirming that the b= value adheres to RFC 6376’s base64 encoding rules. If the encoding is malformed, it flags the issue clearly, so you know when a signature fails due to format errors, not just missing authentication.

How MailTester evaluates DKIM in practice

When you run an inbox-placement test, MailTester receives the full email header, including the DKIM-Signature field, and parses it correctly.
It validates the base64 encoding of the b= value against the requirements in RFC 6376 section 3.4, checking for valid characters, padding, and structure.
If the b= value contains non-base64 characters (like spaces, line breaks, or invalid padding), MailTester reports it as a formatting issue, not a domain or key problem.
It doesn’t just report a failure—it tells you exactly what’s wrong. For example, "Malformed base64 in b= value: unescaped line break detected."
These checks happen during actual email delivery to real inboxes, so you’re testing behavior under real-world conditions, not just syntax.

Integration and workflow benefits

MailTester integrates with SendGrid, Mailchimp, and Klaviyo, letting you test DKIM and deliverability right after sending.
Use the inbox placement tester to send a message through your existing provider and see how DKIM performs in Gmail, Outlook, and other real mailboxes.
For ongoing validation, the verification API can check headers programmatically during build or deployment.
Even if your domain has valid DKIM keys, a single encoding flaw in the header can cause rejection. MailTester catches these subtle mistakes early.
With this level of technical precision, you reduce false positives—no more guessing if a bounce is due to a misencoded signature or a recipient filter.

How to fix misencoded DKIM signatures in practice

If your DKIM signature fails validation due to base64 encoding issues, it’s usually because your email system used a non-standard encoder or omitted proper padding. The fix is to ensure your email server or ESP relies on a library that follows RFC 4648 exactly—standard base64 with correct padding, no manual edits, and consistent output regardless of signing tool. Test every message before sending with a dedicated tool like MailTester to catch misencoded headers early.

Use a compliant DKIM signing library

Don’t rely on custom scripts to generate DKIM signatures unless you’ve audited them against RFC 4648.
Choose an ESP like SendGrid or Amazon SES that handles DKIM signing automatically and correctly.
If you manage your own signing, use a trusted library such as OpenSSL or a well-maintained open-source DKIM implementation.

Validate encoding and test early

Always verify your DKIM-signature header uses standard base64 encoding—no custom alphabets or missing padding.
Check that the b= value in the DKIM header is properly padded with = characters to make the length divisible by 4.
Never manually edit DKIM headers in raw email dumps—tiny changes break the signature.
Use automated tools or trusted platforms (like MailTester’s inbox placement tester) to validate messages before sending to production lists.
Run a real email deliverability check on your campaign setup to catch misencoded DKIM before it harms sender reputation.

Even a single missing padding character can cause DKIM to fail entirely. Tools like MailTester’s bulk verification can spot invalid or suspicious addresses and help ensure your messages align with industry standards—before they land in spam folders or trigger bounces.

What happens when DKIM base64 encoding is incorrect?

If your DKIM signature uses invalid base64 encoding, mail servers will reject the message outright—often resulting in a hard bounce. Even if delivery succeeds, the email may be flagged as spam because authentication fails. Over time, repeated failures hurt your sender reputation and increase the risk of domain blacklisting. If you enforce DMARC policies, messages with malformed DKIM will fail authentication and be either blocked or quarantined.

How incorrect base64 affects email delivery

Mail servers check DKIM signatures during acceptance. A malformed base64 string makes the signature invalid, causing the message to be rejected with a hard bounce.
Even if the email reaches the inbox, spam filters may flag it due to failed authentication, lowering inbox placement rates.
Repeated delivery failures from one domain can trigger reputation scoring drops. According to RFC 6376, DKIM signing must follow strict syntax, including correct base64 encoding of the signature value.
DMARC policies rely on valid DKIM and SPF results. If DKIM fails due to encoding, DMARC enforcement will cause the email to be rejected or quarantined.
Domain blacklisting becomes more likely when a sending domain repeatedly fails authentication checks, especially if those failures originate from a consistent source.

How to prevent this in practice

Always verify that the DKIM signature value section (d=, s=, and b=) in the header uses standard base64 encoding with no line breaks or padding issues.
Use a tool like MailTester’s email checker to validate individual addresses and test header-level authentication before sending.
When setting up bulk sends, run your list through bulk verification to catch invalid or malformed email addresses and reduce delivery risks.
Check your DNS records and signing process if your domain is consistently failing DMARC reports—encoding errors are a common root cause.
Keep your signing tools updated. Some older email platforms or scripts can mismeasure or improperly encode the signature value, especially when using custom or non-standard libraries.

DKIM vs SPF vs DMARC: How they work together

You need SPF, DKIM, and DMARC to work together to validate sender authenticity, ensure message integrity, and enforce policies. SPF checks if the sending IP is authorized. DKIM verifies the message wasn’t altered by signing it with a cryptographic key. DMARC uses both results to decide whether to accept, quarantine, or reject the email. If any one fails, inbox placement drops. You can test this stack with real email headers using MailTester’s inbox placement tool.

SPF: The IP Authorization Check

SPF confirms whether the server sending the email is on the domain’s approved list. It checks the envelope sender’s IP against the domain’s TXT record. If the IP isn’t authorized, the email fails SPF. This blocks spoofing from unauthorized servers, but it doesn’t protect message content.

DKIM: Content Integrity Through Cryptographic Signatures

DKIM signs parts of the email — like headers and body — using a private key stored on the sender’s server. When the recipient receives the email, they use the public key from the sender’s DNS to verify the signature. If the hash doesn’t match, the message was tampered with. This is why correct base64 encoding in the DKIM signature is critical: a single incorrect character breaks the verification. You can validate the format by checking the signature’s structure in the raw header, as defined in RFC 6376.

DMARC: The Policy Enforcer

DMARC doesn’t verify authentication alone — it depends on SPF and DKIM. It tells the receiving server what to do when either fails. You can set it to monitor only, quarantine messages, or reject them outright. DMARC also sends reports back to the sender, helping you monitor your domain’s use and detect potential abuse.

For strong deliverability, all three protocols must pass. Even if SPF passes and DKIM fails, DMARC can still reject the message if your policy is strict. That’s why consistent header formatting — including proper base64 encoding in DKIM signatures — is non-negotiable. A single malformed character in the signature can cause the entire authentication stack to collapse.

If you're validating DKIM signatures or testing full email authentication, you can analyze real headers with MailTester’s in-depth inbox placement tester, which checks SPF, DKIM, DMARC, and more. It’s built for teams who need accuracy, not just speed.

Best practices for maintaining strong DKIM authentication

You validate DKIM with correct base64 encoding by ensuring your signing tool uses standard RSA-SHA256 with proper padding and encoding, as defined in RFC 6376. Base64 must be applied to the canonicalized header and body content without line breaks or extra whitespace. Use consistent key length (2048 bits or higher) and verify the full signature chain, including the selector and domain, through tools like MailTester’s inbox placement tests or direct SMTP log analysis. Always test before sending at scale.

Implement consistent DKIM configuration

Use the same key length (2048 bits minimum) and algorithm (rsa-sha256) across all domains to avoid fragmentation in recipient validation.
Apply the same selector and DNS record structure consistently — a misconfigured selector or missing TXT record will break DKIM alignment.
Verify that your signing tool outputs base64 without line wrapping or embedded newlines; even a single extra character can invalidate the signature.

Proactively monitor and maintain DKIM integrity

Check every outgoing message before sending, especially in high-volume campaigns, to confirm DKIM headers are correctly generated and the body is canonicalized per RFC 6376.
Rotate DKIM keys every 6–12 months to limit exposure if a key is compromised — older keys should be removed from DNS after a transition period.
Monitor for failed DKIM checks using SMTP logs, third-party audit tools, or MailTester’s inbox placement testing service, which simulates real delivery across major providers and detects authentication failures in real-world environments.
Run periodic scans on your sending infrastructure to identify misconfigured or expired DKIM records before they impact deliverability.

DKIM failures don’t always trigger bounces, but they still hurt sender reputation. Even a single misaligned signal can reduce inbox placement, especially if other authentication checks (SPF, DMARC) are weak or inconsistent. Use tools that test both the raw header and the full end-to-end delivery path — not just a parsing check.

For teams sending large volumes, consider integrating your email system with a real-time verification API like MailTester’s API to validate addresses and detect high-risk patterns before they hit your sending pipeline. You can also use our inbox placement tester to evaluate how your DKIM configuration performs in practice. It’s not enough to generate a valid signature — it must survive real-world inspection.

Final takeaway: encode DKIM base64 correctly to ensure delivery

A single encoding error in the DKIM signature—incorrect padding, invalid line breaks, or wrong character set—can cause authentication to fail, leading to rejected or marked spam emails.

Automate verification to catch mistakes early

Manual checks are unreliable. Use tools that validate base64 format, line length (76 characters), padding, and character set compliance across entire email headers.

MailTester’s real-time API and bulk verification checks detect these issues before messages are sent, reducing bounce rates and protecting sender reputation.

Consistent DKIM implementation isn’t optional. It’s a foundational requirement for inbox placement and long-term deliverability.

Sources

DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

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

Frequently asked questions

What does 'b=' mean in a DKIM-Signature header?

The 'b=' tag contains the base64-encoded digital signature of the message's canonicalized content and headers. It's critical for DKIM validation.

Can a DKIM signature pass if base64 encoding is wrong?

No. Receiving mail servers reject messages with non-base64 or malformed 'b=' values, regardless of other authentication settings.

How do I know if my DKIM signature is properly encoded?

You can test it using a base64 decoder or an email validation tool like MailTester that checks header structure against RFC 6376.

Why does DKIM require base64 encoding?

Base64 encoding converts binary signature data into a safe ASCII string format, allowing reliable transmission across email systems.

Does MailTester check DKIM signature validity?

Yes, MailTester checks full DKIM-Signature headers, including base64 format, padding, and structure, to ensure compliance with standards.

What happens if DKIM fails but SPF passes?

DMARC may still reject the email if it’s configured to enforce DKIM failures. Even one failed check can lead to delivery failure.

How often should I test DKIM signatures?

Test every new email template and before sending to large lists. Use tools like MailTester for regular audits.

Can I manually fix a DKIM signature if it’s misencoded?

No. Manually editing DKIM headers is risky and may introduce errors. Use a compliant system to generate signatures.

Is it safe to use a custom base64 encoder for DKIM?

Only if it fully follows RFC 4648 with correct padding and no line breaks. Standard libraries are safer and more reliable.

Can a DKIM failure be caused by email content changes?

Yes. Even small changes to the message—like whitespace or line breaks—can alter the canonicalized body or headers, invalidating the signature.

What is the role of the 'bh' tag in DKIM?

The 'bh' tag holds a base64-encoded hash of the message body. It’s used to verify content hasn’t changed during transit.

Do all email providers validate DKIM base64 format?

Yes. Major providers like Gmail, Outlook, and Yahoo validate DKIM signatures fully, including proper base64 format and structure.