Why Does Your DKIM Signature's Base64 Length Matter?

You send a perfectly crafted email. Your SPF passes. The domain is valid. Yet it lands in spam—or worse, is rejected outright. One invisible flaw may be to blame: a DKIM signature with a base64-encoded 'b=' tag that’s too short, too long, or malformed.

DKIM signs emails using cryptographic hashing, then encodes the result in base64. The 'b=' tag in the DKIM-Signature header must contain the exact, complete base64 string derived from that hash. Even a single missing byte breaks validation—no matter how clean your sender setup looks.

An email verification API that checks b= DKIM signature for correct base64 length catches these errors before they cost you deliverability. It’s not a luxury. It’s basic hygiene for any sender who wants to land in inboxes, not junk folders.

Key takeaways

  • Digital signatures require exact base64 encoding lengths to pass validation—missing or extra characters break DKIM.
  • Even valid domains and working SPF can fail delivery if the DKIM 'b=' value has incorrect base64 length.
  • An email verification API that validates DKIM base64 length prevents authentication failures before messages are sent.

Can an Email Verification API Detect Malformed Base64 in Your DKIM b= Tag?

Yes — a capable email verification API can detect malformed Base64 in your DKIM b= tag by parsing the raw email header, extracting the signature value, and validating its encoding, length, and structure against the expected standard. It checks for truncation, incorrect padding, or invalid characters that would break the signature verification process.

How the Check Works Under the Hood

When you send an email, the DKIM signature includes a b= tag containing a Base64-encoded hash of the signed content. The API doesn’t just check whether the field exists — it examines the full value as it appears in the raw header. It validates that the string is properly Base64-encoded, meaning it only contains characters from the Base64 alphabet (A–Z, a–z, 0–9, +, /) and ends with the correct padding (one or two = signs, depending on length).

If the signature is truncated — for example, cut off in the middle of a long string — or padded improperly (like missing a necessary = sign), the API flags it as invalid or risky. These errors prevent recipients from verifying the signature, which can lead to your emails being rejected or marked as suspicious.

Why This Matters for Deliverability

DKIM is a core part of email authentication. A malformed b= tag means the signature fails to verify at the receiving end, breaking one of the key trust signals that ISPs use to assess sender legitimacy. Even if your SPF and DMARC are set up correctly, a broken DKIM signature can still cause inbox placement issues.

Tools like MailTester’s real-time verification API analyze the raw header structure of the email, including the b= value, to catch these issues before they impact your sending reputation. It’s not just checking if an address exists — it’s validating the integrity of your full email infrastructure.

For the full picture, you can also test actual inbox placement and review how your messages appear in real inboxes. MailTester’s inbox placement test simulates delivery across real providers, showing you how your DKIM-signed emails are treated in practice. This helps you catch signature issues that might not show up in simpler validation tools.

Base64 validation is defined in RFC 4648, which outlines the correct encoding scheme and rules for padding. Misaligned or malformed encoding violates this standard and undermines your authentication stack. Any system that claims to verify email authenticity should be inspecting this detail — it’s not optional for serious deliverability hygiene.

How MailTester’s API Validates the DKIM b= Base64 Length

MailTester’s real-time verification API checks the DKIM b= signature by decoding its base64 content and verifying the resulting length against the expected size for the signing algorithm. If the decoded data is malformed or wrong-sized, the signature fails, flagging the email as potentially forged or misconfigured. This prevents spoofed messages from slipping through.

Step-by-step: How the Check Works

  1. Extract the full DKIM header from the email during real-time verification. The API doesn’t just check the address — it reads the full message header, including the DKIM signature block.
  2. Parse the b= field and isolate the base64-encoded signature value. This is the core of the DKIM verification — the data that should match the sender’s private key.
  3. Attempt full base64 decoding. If decoding fails (due to invalid characters, padding, or malformed input), the signature is instantly invalid. This catches common errors in email generation tools.
  4. Verify the decoded length. The API checks that the decoded binary data matches the expected size for the hash algorithm. For example, SHA-256 produces 32 bytes, which translates to roughly 43 base64 characters. A mismatch means the signature is compromised.
  5. Validate against algorithm standards. The system cross-references the hash algorithm (e.g., sha256) from the a= tag to confirm the data length. If the length doesn’t align — say, 64 base64 chars for a SHA-256 → 32-byte output — it’s rejected. [RFC 6376](https://tools.ietf.org/html/rfc6376) defines these rules in detail.

Why This Matters

Many systems only check if a DKIM signature exists — not if it’s correct. A signature with the right format but incorrect length may pass basic checks but still be invalid. MailTester catches these subtle flaws.

Malformed or truncated signatures often come from misconfigured email servers or poorly implemented bulk senders. The API doesn’t guess — it enforces RFC standards, ensuring only properly signed emails pass.

For developers, this level of detail is crucial when integrating email verification into workflows. You’re not just checking if an address exists — you’re verifying the authenticity of the sender itself.

Use our real-time verification API to test DKIM signatures and other email health metrics at scale. With 98.9% accuracy, it’s a reliable check before you send.

What Happens When DKIM Base64 Is Incorrect?

When the b= DKIM signature contains malformed Base64 data—such as incorrect padding, invalid characters, or wrong length—the receiving server cannot verify the signature. Even if SPF and DMARC align, a failed DKIM check signals potential misconfiguration or spoofing, which can trigger spam filters, delay inbox placement, or result in outright rejection. This is a common red flag for receiving systems that rely on cryptographic validation, including those used by Gmail and Microsoft Outlook.

How Misconfigured DKIM Impacts Deliverability

DKIM is designed to prove a message wasn’t altered in transit, but it only works if the b= value is correctly encoded. If the Base64 string is truncated, padded incorrectly, or contains non-Base64 characters, the signature fails validation. Receiving servers treat this as a reliability risk. Even a single failure can reduce sender reputation—especially if repeated across multiple emails.

Many mail providers, including those operating large-scale systems like Yahoo or Outlook, assign higher spam scores to senders whose DKIM fails consistently. This isn’t just about technical correctness; it’s about trust. A failed DKIM doesn’t automatically mark a message as spam, but it contributes to a cumulative signal that lowers the overall trust score of your sending domain.

Let’s say you send a newsletter with a valid SPF record and a DMARC policy set to none. Despite that, if the DKIM b= value is malformed due to a typo in your signing process, the receiving server will still reject the signature. This doesn’t mean your email gets marked as spam—immediately—but it does mean the system sees an inconsistency. High volumes of such messages signal poor sender hygiene.

Some systems treat DKIM failures as strong indicators of spoofing attempts or misconfigured infrastructure. For example, a report from the Anti-Phishing Working Group (APWG) notes that improperly signed emails are among the top indicators of phishing campaigns, even when other authentication passes. This makes DKIM integrity more than just a technical detail—it’s a gatekeeper of inbox trust.

If you’re validating email addresses before sending, a simple check won’t catch malformed DKIM. But tools like MailTester’s real-time verification API integrate deeper checks into your workflow, catching many of these edge cases before they impact deliverability. With over 98.9% accuracy, it’s not just about domain validity—it’s about whether the sending infrastructure is aligned with technical standards.

Even if you don’t control your signing process, validating the recipient domain and confirming proper DKIM alignment at the time of sending helps reduce the chances of failure. Tools that can test for real-time SMTP delivery and verify headers—including DKIM—are essential for maintaining clean send rates and avoiding unnecessary bounces or spam markings.

DKIM Base64 Format: The Technical Standard

DKIM signatures use base64 encoding as defined in RFC 4648, which specifies a 64-character set: A–Z, a–z, 0–9, +, /, and = for padding. The encoded string must be a multiple of 4 characters long; otherwise, it’s invalid. After decoding, the result must match the expected output size of the signing algorithm—e.g., SHA-256 produces 32 bytes, which translates to exactly 43 base64 characters when properly padded. If the length or decoded size doesn’t match, the signature fails verification.

Base64 Rules and RFC 4648

Base64 isn’t just a notation—it's a standardized encoding defined in RFC 4648. This specification governs how binary data is serialized into ASCII for transmission in email headers, like DKIM-Signature. The alphabet is fixed: uppercase and lowercase letters, digits, plus + and /. Each character represents 6 bits of information, so 4 characters encode 24 bits (3 bytes). Hence, the total length of the base64 string must be divisible by 4 to maintain alignment. If it isn’t, the signature is malformed and cannot be trusted.

Length vs. Decoded Size: The Validation Check

Let’s say you’re validating a DKIM signature using SHA-256. The hash output is always 32 bytes. When encoded in base64, that’s 32 × 8 = 256 bits. Since each base64 character represents 6 bits, you need 256 / 6 ≈ 42.67 characters—round up and pad to 43. So, after adding the final = padding, the full length should be 44 characters, with the actual base64 content being 43. Any deviation breaks the structure. If a signature is 45 characters long, or decodes to something other than 32 bytes, it’s not valid—even if the characters are correct.

Many email verification systems, including MailTester’s real-time verification API, perform these checks automatically. This ensures that not only is the address valid, but any DKIM signature attached to it meets the technical standard. You’re not just checking if an email exists—you’re validating whether it’s cryptographically signed correctly. That’s critical for detecting spoofing and maintaining sender reputation.

This validation is part of the broader email ecosystem governed by standards like RFC 6376 (DKIM), which builds on earlier work like RFC 4648. These are not optional; they’re the foundation of trust in digital mail. You can explore how this fits into a full deliverability test at MailTester’s inbox placement tool, which evaluates both format and reputation across real inboxes.

How MailTester Detects Invalid Base64 in b= Tags

You can trust MailTester’s email verification API to catch malformed DKIM signatures by checking the b= tag’s base64 encoding in real time. It parses the full DKIM header, validates syntax (no invalid characters, correct padding, length divisible by 4), and cross-checks the decoded payload length against expected sizes for the hash algorithm—flagging signatures that fail any of these tests.

What the API Checks in Real Time

  • It parses the full DKIM-Signature header from the email, not just the b= value.
  • It verifies that the b= value uses only valid base64 characters (A–Z, a–z, 0–9, +, /, =).
  • It ensures the string ends with correct padding: one or two = signs, never more.
  • It checks that the total length of the b= value is a multiple of 4—required by base64 encoding rules.
  • It decodes the value and compares its length to the expected size for the specified hash algorithm (e.g., 20 bytes for SHA-1, 32 for SHA-256).

Why Malformed Base64 Matters

Digital signatures with malformed base64 fail verification. An invalid encoding can come from a flawed signing process, truncated data, or malicious intent. The DKIM specification requires strict adherence to base64 encoding rules. If a receiver attempts to decode a string that’s not properly padded or contains invalid characters, the signature is rejected outright.

MailTester doesn’t just check if a b= tag exists—it validates whether it’s a complete, correct, and usable signature. This is critical for sender reputation: sending emails with malformed DKIM signatures harms deliverability, even if the address is technically valid.

For teams integrating authentication checks directly into their workflows, you can use the real-time verification API to detect these issues before sending. Whether you're building a marketing platform, validating user signup emails, or auditing an entire list, our API returns actionable feedback on technical validity—no guesswork.

What Other Signature Checks Does MailTester Perform?

MailTester’s email verification API validates DKIM signatures beyond just base64 length — it checks every required tag in the header, ensures domain alignment, verifies selector consistency, and confirms header field inclusion is correct and ordered. This deeper inspection helps catch spoofing attempts and alignment issues that could hurt deliverability.

Core DKIM Header Validation

  • Confirms that the DKIM-Signature header contains all required tags: d= (domain), s= (selector), b= (signature), and v= (version).
  • Verifies that the d= domain matches the sending domain in the SMTP envelope (envelope-from), preventing spoofing via domain mismatch.
  • Tests for consistent use of the same selector (s=) across messages from the same domain, flagging anomalies that suggest misconfiguration or attempted abuse.
  • Checks that the h= tag lists all signed header fields in the correct order, which is essential for signature validation — an incorrect or missing field breaks the signature.

Aligning with Industry Standards

These checks follow the core requirements outlined in RFC 6376, the definitive standard for DKIM. While many tools only validate that a signature exists, MailTester ensures it’s properly constructed and aligned — a critical difference when assessing sender reputation and inbox placement.

Let’s say you’re sending a campaign and want to ensure your DKIM isn’t just present but actually effective. A correct signature with the right fields, order, and domain match means your message is more likely to pass strict mailbox filters. You can test this in real time with our email verification API or validate entire lists using bulk verification, both of which include full DKIM integrity checks.

DKIM doesn’t just sign — it validates. A malformed or misaligned signature will fail delivery even if it appears to exist.

These are the checks that matter when you’re trying to avoid bounces, prevent blacklisting, and maintain sender reputation. They’re not optional. They’re built into every verification MailTester performs.

Email Verification API: More Than Just Syntax

An email verification API that checks b= DKIM signature for correct base64 length does more than validate syntax—it confirms whether the signature is structurally sound, aligns with the domain’s public key, and is part of a functional email delivery chain. Without this layer, you might pass a signature as valid while it’s actually broken, forged, or mismapped, leading to rejected messages or damaged sender reputation.

Beyond Syntax: Real-World Deliverability Signals

Let’s be clear: a valid DKIM signature isn't just about correct base64 encoding. It must also match the domain’s published public key and be properly aligned with the sending domain (SPF or sender domain). A signature with correct syntax but a mismatched key is still invalid—not just in theory, but in practice. A robust API like MailTester’s goes further by combining this check with active DNS validation, MX lookups, and real-time SMTP testing.

It’s not enough to detect a syntactically correct b= field. The same check might pass on a catch-all domain or a role-based email like admin@ or support@—addresses that accept mail but don’t represent real users. A strong API distinguishes these scenarios by testing whether the address resolves to a real mailbox. This prevents sending to non-deliverable or placeholder accounts.

Verdicts Based on Full Context, Not Isolated Checks

Only when you cross-reference syntax checks with live infrastructure signals can you derive a meaningful verdict. A valid address means both the format and delivery path are verified. An invalid result flags a malformed address or an unreachable domain. A catch-all verdict identifies a domain that accepts all incoming mail—no matter the local part—useful to flag but risky to send to. A risky result may indicate weak DKIM alignment, a suspicious header, or a known disposable domain.

Industry standards like RFC 6376 (which defines DKIM) and DNS-based validation practices (from tools like MxToolbox or Spamhaus) support this layered defense. You can’t rely on syntax alone—modern email systems do the same.

To test your list or integrate real-time checks, try MailTester’s email verification API or validate a single address before sending with the email checker. These tools reflect the full state of an email, including signature integrity.

Integrating with MailTester’s Real-Time API for DKIM Checks

You can use MailTester’s real-time API to validate email addresses and verify DKIM signatures on the fly, checking for correct base64 encoding length and header integrity. The API returns detailed feedback on the DKIM status, including whether the signature is properly formatted, which matters for inbox placement and sender authentication. Integrations with Mailchimp, SendGrid, HubSpot, and Klaviyo enable automated checks without custom code.

How to Use the API for DKIM Verification

  1. Send a POST request to MailTester’s API endpoint with a JSON payload containing the email and (optionally) the sender domain. The endpoint validates the address and parses the full DKIM header structure to check encoding length and syntax.
  2. Parse the DKIM result in the response. You’ll see a verification code—valid, invalid, risky—along with a detailed breakdown of the DKIM signature, including its base64 length, key size, and whether the signature matches the expected format. A malformed or truncated base64 string will trigger a risky or invalid status.
  3. Handle the response in your application logic. For example, if the DKIM signature appears valid but uses an unsupported hash algorithm, flag it for review. If the base64 length is outside expected bounds (e.g., too short for the key size), it’s likely forged or corrupted.
  4. Use the results to filter your list. Block addresses with invalid or suspicious DKIM structures before sending. This reduces bounces, improves sender reputation, and improves deliverability over time.
  5. Integrate with your platform using one of the built-in connectors for Mailchimp, SendGrid, HubSpot, or Klaviyo. These integrate via webhooks and pre-built workflows so you don’t need to code every step. See how it works.

Why DKIM Verification Matters

DKIM is a core email authentication standard. According to RFC 6376, a valid DKIM signature must use proper base64 encoding and match the cryptographic key size. Malformed signatures—especially those with incorrect length—often indicate spoofing or relay issues. These are flagged by ISPs and often lead to inbox filtering or blocking.

MailTester checks the full DKIM header structure, not just presence. If the signature is missing, truncated, or has an invalid base64 length, the API returns a detailed error. This lets you catch issues early—before sending—to protect your sending reputation. Use this during onboarding, list hygiene, or automated email campaigns.

You can also verify your own messages with MailTester’s inbox placement tool to see how likely a message is to reach the inbox, including how DKIM compliance affects delivery.

Why Base64 Length Verification Is Part of List Hygiene

You don't need to check DKIM base64 length to spot invalid emails—but doing it helps catch real problems that hurt deliverability. Malformed DKIM signatures often mean your sending domain has misconfigured authentication, not that the inbox is dead. Still, sending to addresses with broken signatures can erode your sender reputation. Regular verification of both addresses and their signatures is a core part of maintaining a clean, trusted list.

DKIM Signatures Are a Signal, Not Just a Check

DKIM isn’t just about verifying a signature—it’s also a reflection of how consistently your domain sends mail. A malformed base64-encoded signature, particularly one with an incorrect length, is a red flag. It usually means the signing process failed, often due to incorrect key length, incorrect header inclusion, or a misconfigured mail server. These aren’t errors in the email address itself, but they signal weak or inconsistent sending practices.

Even if the address is valid, a broken signature can cause inbound filters to treat your messages as suspicious. Gmail, Outlook, and other major providers evaluate DKIM as part of their overall spam scoring. A single consistently broken signature across your domain can trigger reputation penalties, leading to increased inbox placement drops—even if only a few addresses are affected.

How Real-Time Verification Keeps Your List Clean

Let’s be clear: you can't fix DKIM failures through email list verification alone. But you *can* detect them. An email verification API that checks base64 length goes beyond "valid/invalid"—it exposes structural flaws in your sending infrastructure, even if the email address is technically correct.

That’s why running bulk checks through a tool like MailTester’s email list verification or testing individual addresses via the email checker isn’t just about removing bad addresses. It’s about spotting weak authentication before it harms your domain’s reputation. This is especially important for senders using automated tools, email platforms, or third-party systems where misconfiguration is common.

The same applies to inbox placement tests. If your DKIM signature fails due to base64 length issues, your test results may show low inbox placement—even if your content is fine. Inbox placement testing can help reveal if technical errors, not content, are the root cause of delivery failures.

Authentication and list hygiene are two sides of the same coin. RFC 6376, the standard defining DKIM, specifies strict requirements for key lengths and encoding—base64 must be correct, or the signature is invalid. Tools that validate this part of the chain help you maintain compliance, not just accuracy. It's not about catching every typo. It's about preventing small technical issues from turning into big deliverability problems.

MailTester’s Accuracy: How It Handles DKIM Validation

MailTester’s email verification API achieves 98.9% accuracy in real-world deployments, including the detection of syntactically invalid DKIM signatures.

This includes checks for base64 encoding violations and incorrect signature lengths, which are common indicators of tampered or malformed DKIM records.

Why It Works

  • Validation is not limited to passive DNS lookups.
  • MailTester performs active SMTP handshakes and analyzes email headers in context.
  • This prevents false positives from outdated or non-functional DNS records.

By combining protocol-level checks with real-time infrastructure probing, MailTester reduces deliverability risks tied to invalid cryptographic signatures.

Sources

Keep reading

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

Frequently asked questions

Does an email verification API check DKIM signature formatting?

Yes — a high-quality API like MailTester checks the full DKIM header, including the 'b=' tag’s base64 encoding, length, and validity.

What happens if the DKIM b= tag has incorrect base64 length?

The DKIM signature fails verification. Even if the address is valid, the email may be rejected or marked as spam.

Can base64 in DKIM be too long or too short?

Yes. Too short means the hash wasn’t fully encoded. Too long means padding or data was added incorrectly. Both break validation.

Why does base64 length depend on the hashing algorithm?

Different algorithms produce different-sized outputs. SHA-256 produces 32 bytes, which converts to about 43 base64 characters when padded.

How can I test if my DKIM signature is valid?

Use MailTester’s API to verify the full header. It will check base64 syntax, length, and decoding success for the 'b=' value.

Do all email verification tools check DKIM b= length?

No. Most only check email syntax or MX records. Few parse headers to validate DKIM structure and base64 correctness.

Is invalid base64 in b= a sign of a compromised domain?

Not necessarily. It usually indicates misconfiguration, not compromise. Still, malformed signatures can be exploited by attackers.

Can an email pass SPF but fail DKIM?

Yes — SPF and DKIM are independent checks. A pass on one does not guarantee a pass on the other.

How does MailTester handle catch-all domains with bad DKIM?

It still verifies the address. If DKIM is invalid, the verdict may be 'risky' or 'invalid' depending on the overall context.

Does MailTester check email signatures before sending?

Yes — the real-time API validates signatures as part of the verification process, helping prevent sending with broken DKIM.