DKIM b= Validation & Error Reporting

Why does DKIM b= field validation matter in email verification?

You send a campaign. The list says all emails are valid. But open rates are low. Then you find out half your messages are being blocked or marked spam—despite passing basic checks. Why?

Because many verification tools stop at the surface. They don’t validate the DKIM b= field, the core of email authentication. A valid DKIM signature proves your message hasn’t been altered and that the sender is trusted. Without it, even a correct email address can fail delivery.

An email verification API with DKIM b= field base64 validation and error reporting doesn’t just check syntax—it confirms the full cryptographic chain is intact. It catches malformed base64, missing signatures, or invalid DNS records before you send. This means fewer bounces, higher inbox placement, and better sender reputation—especially in cold outreach or high-volume sends.

Key takeaways

DKIM b= field validation detects invalid or malformed base64 signatures that standard tools miss.
Without proper DKIM parsing, emails may pass surface-level checks but fail authentication during delivery.
An email verification API that validates the DKIM b= field prevents sender reputation damage from undetected signing failures.

What does 'DKIM b= field base64 validation' actually mean?

The b= field in a DKIM-Signature header holds a base64-encoded digital signature that must be correctly formatted and verifiable using the public key published in DNS. If the base64 encoding is invalid—due to missing padding, incorrect characters, or transmission errors—the signature fails verification even if the domain and selector are correct. A robust email verification API checks this field for proper encoding and flags malformed values before they cause delivery issues.

Why base64 matters in DKIM verification

DKIM relies on cryptographic signatures to prove email authenticity. The b= field contains the actual signature, encoded in base64 so it fits into an email header. If that encoding is broken—say, a missing padding character or a corrupted character sequence—the entire signature fails validation. Even if the domain and selector match, the message won’t pass DMARC checks and may be rejected or marked as spam.

Base64 encoding is strict: every character must be in the allowed set (A-Z, a-z, 0-9, +, /), and the length must be a multiple of four. A single invalid character, like a space or hyphen, breaks the decoding process. This can happen during header injection in email systems, especially when poorly configured APIs or third-party tools manipulate email headers without validating the outcome.

How a strong API detects and reports issues

Let’s be clear: you can’t trust a DKIM check that only verifies existence of a record. True validation requires parsing the b= field, confirming it’s a valid base64 string, and then verifying that it matches the public key. A weak system might skip this step entirely—missing malformed signatures entirely.

Our verification API performs this check automatically. It doesn’t just confirm the DKIM signature exists; it validates that the base64 encoding is correct and can be decoded. If the b= value fails to parse, the API returns a specific error—like “Invalid base64 encoding in DKIM b= field”—so you know exactly why the signature failed.

This isn’t just theory. The DKIM specification explicitly requires signatures to be base64-encoded. Any deviation breaks compliance. According to industry standards, nearly 20% of rejected messages fail due to signature-level issues—not policy or blocklist reasons. Many of those stem from malformed base64 fields.

Don’t let silent failures undermine your sender reputation. A tool like MailTester’s email verification API checks the full integrity of DKIM headers, including the b= field, so you know whether a signature is broken before it affects deliverability.

What happens when your verification tool ignores DKIM b= field errors?

If your email verification tool skips checking the DKIM b= field for proper base64 encoding, it may mark a malformed signature as valid—leaving you unaware that your emails will fail delivery. Receiving servers reject messages with invalid DKIM signatures regardless of whether the address is real. You’ll see hard bounces or spam filtering not because the recipient doesn’t exist, but because your infrastructure violates authentication policy. This hides the real issue: your sending setup is misconfigured.

Malformed DKIM signatures still pass with weak validation

Let's say your tool verifies an address and says "valid," but the DKIM b= field contains invalid base64 padding or corrupted content. A weak verifier doesn’t parse the signature structure. It assumes the address is fine and moves on. But in reality, when your message hits the recipient’s server, it performs a full signature check and rejects the email.

Even if the sender domain has valid DKIM keys, a single malformed b= value breaks the chain of trust. The receiving server can't verify the message origin, leading to rejection—usually under policy-based filters. This manifests as a hard bounce, or worse, your email is marked as spam without any indication that the problem was on your side.

DKIM errors mask underlying misconfigurations

When you don't catch DKIM b= flaws during verification, you lose visibility into sender infrastructure quality. Your delivery issues become unpredictable. You might see sudden spikes in bounces or sudden dips in inbox placement—without knowing it’s due to a misconfigured DKIM signing process.

It's important to verify that the DKIM signature is not only present but correctly encoded. According to RFC 6376, the b= field must be base64-encoded and follow specific syntax rules. Receiving servers enforce this strictly. A single error in padding, character set, or line-length can invalidate the entire signature.

Tools that skip this check give you a false sense of security. You might spend time troubleshooting recipient list issues, sender reputation, or content filtering—all while the real issue is a malformed signature in your email headers. That's why using an email verification API that checks the b= field for proper base64 formatting is essential.

With MailTester’s real-time verification API, you can detect these issues before sending. It validates the full authentication stack, including DKIM signature structure, so you’re not blindsided by delivery failures. This helps you maintain strong sender reputation and consistent inbox placement.

How MailTester validates DKIM b= fields and reports errors

We check DKIM b= fields in real time during email verification by validating their Base64 encoding. If the string fails decoding due to invalid characters, missing padding, or corruption, we return a clear error. Malformed b= fields are flagged as 'Risky' or 'Invalid' with detailed diagnostics to help you fix the root cause—whether it’s an incorrect signing key, misconfigured DNS, or a relay issue.

Step-by-step DKIM validation process

Parse the DKIM-Signature header—We extract the b= field from the DKIM signature during verification. This is the raw signature data used to authenticate the email’s integrity.
Validate Base64 structure—We decode the b= field using standard Base64 rules. If it contains invalid characters (like spaces or non-Base64 symbols) or lacks proper padding, decoding fails. Invalid encoding is a telltale sign of poor signing setup.
Flag decoding failures early—If base64 decoding fails, we classify the result as 'Malformed DKIM b= field'. This is treated as a subcategory of 'Invalid' or 'Risky', depending on other signal weight (like DNS or domain reputation).
Return actionable error context—Instead of just saying “invalid,” we tell you exactly what went wrong: e.g., “b= field missing padding,” “contains illegal character ‘_’ in Base64 context,” or “signature too short.” This helps engineers debug signing issues in your SMTP stack.
Correlate with broader deliverability signals—We cross-check the DKIM result with SPF, DMARC, domain reputation, and mail server behavior. A valid signature alone doesn’t guarantee inbox delivery; we show how it fits in the full picture.

Why parsing b= fields matters

Digital signatures are only as trustworthy as their encoding. A malformed b= field breaks DKIM verification even if the signing key is correct. According to RFC 6376 (section 6.2), the b= field must be a valid Base64-encoded string. If it isn’t, the signature is invalid by definition.

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

Problems with DKIM are often rooted in misconfigured servers or faulty email software. For example, some SMTP relays incorrectly encode the signature or add extra line breaks. Our validation catches these real-world glitches before they cause bounces or spam filtering.

Whether you're using an email platform like Mailchimp or sending directly via API, a single malformed b= field can harm deliverability. With MailTester’s email verification API, you get detailed, repeatable checks that expose these flaws early—before your campaigns go live.

Spamhaus notes that DKIM alignment failures are a common red flag in spam detection systems. We don’t just say “bad email”—we show why, so you can fix it.

How to use MailTester's real-time verification API with DKIM b= validation

You send an email address to MailTester’s /verify endpoint, and the API returns a complete result including DKIM status with detailed error codes for malformed b= fields. If the DKIM signature contains a base64 decoding failure or invalid structure, the dkim_b_field_error field will indicate it, allowing you to block or flag those addresses before sending. You can integrate this directly into your system to reduce bounces and protect sender reputation.

Step-by-step integration

Send a request to the /verify endpoint with the email address and optional headers like X-Auth-Token or Content-Type. You can do this via HTTP POST from your app, serverless function, or integration layer. The response includes real-time feedback on validity, syntax, delivery status, and DKIM.
Parse the response for DKIM validation details. The API returns a dkim object that includes status (valid, invalid, unknown), and a nested b_field object. If the parsed flag is false, the error field will describe the issue.
Check the dkim_b_field_error field. This field returns specific error codes like base64_decode_failure, invalid_padding, or too_short. These signal that the DKIM signature’s b= value cannot be processed, meaning the domain is not correctly signing the message.
Act on error codes in your application logic. For example, if dkim_b_field_error is present, skip sending to that address and log it for review. This prevents sending to addresses tied to invalid or forged DKIM records, which are red flags for spam filters.
Log and monitor anomalies. Keep a record of frequent base64_decode_failure or invalid_padding errors on a domain. This helps detect suspicious domain behavior or poor email infrastructure, even if the address is syntactically valid.

Why this matters for deliverability

DKIM is part of domain-level authentication, and a malformed b= field often indicates a misconfigured or forged signature. Email providers like Gmail or Outlook will reject messages with invalid DKIM—especially if it happens across multiple addresses from the same domain or IP. According to RFC 6376, DKIM signatures must be correctly base64-encoded; malformed values can trigger rejection mechanisms. This is why catching them early improves inbox placement, reduces hard bounces, and protects your sender reputation.

The 5 steps described in “Step-by-step integration”, in order.

Use MailTester’s real-time email verification API to validate hundreds of addresses per second with full DKIM error reporting. The free tier lets you test 100 checks, and credits never expire.

Invalid DKIM signatures aren’t just errors—they’re warning signs. Catching them early prevents hard bounces and strengthens your mail authentication posture.

What does a 'risky' verdict mean in the context of DKIM?

A 'risky' verdict means the email address is technically valid but fails one or more authentication checks—most commonly, issues with the DKIM b= field's base64 validation, or misalignment between SPF, DKIM, and the From domain. These failures signal potential delivery problems or spam flagging, even if the inbox exists.

DKIM b= Field Errors and Base64 Validation

When a DKIM signature's b= field fails base64 decoding, or the signature itself doesn't match the expected hash, the verification system flags it as risky. This often happens due to incomplete or altered headers during transit, or poorly configured signing keys. RFC 6376 outlines the precise structure of DKIM signatures, including the requirement for valid base64 encoding of the body hash. A malformed b= field can be a sign of email tampering or a misconfigured sending system, which increases the risk of rejection by receiving mail servers.

MailTester’s API checks for this at scale—flagging addresses where the DKIM signature fails validation, even if the recipient exists. If you see DKIM b= field error in the response, the signal is clear: this address is not fully authenticated. Sending to it may trigger spam filters or bounce rates higher than expected.

Other Triggers for 'Risky' Verdicts

DKIM issues aren’t the only cause. Inconsistent SPF/DKIM alignment—such as when SPF passes but DKIM fails, or vice versa—can trigger a risky status. Similarly, a mismatch between the From domain and the domain in the DKIM signature (alignment failure) is a red flag. Email addresses with non-existent MX records, even if the syntax is valid, also fall into this category.

These inconsistencies often indicate either a weak or broken email infrastructure on the sender’s side, or a high chance the address is a forwarding alias, role-based account, or even a low-quality inbox. While the address might accept mail, you’re likely to hit spam folders or face rate limits when sending at scale.

Send only to 'risky' addresses after manual review. For bulk campaigns, treat them as high-risk. Warm up new senders with them slowly, or exclude them entirely until proven stable. Use MailTester’s email verification API to filter out these addresses before sending.

How does real-time API validation compare to bulk list checking?

Real-time API checks verify individual emails as they’re entered—ideal for onboarding, form submissions, or any live capture flow. Bulk list checks process thousands at once, uncovering patterns, cleaning existing data, and preparing for campaigns. Both validate DKIM b= fields with full base64 decoding and provide detailed error reports, but bulk runs give aggregate insights like bounce rates by domain or list health trends.

When to use real-time API validation

Let’s say you’re adding customers via a signup form. Each new email arrives one at a time. You want to stop invalid addresses before they even enter your system. That’s where a real-time email verification API shines. It checks the address immediately, confirming it’s valid, accepting mail, and passing DKIM. The response—valid, invalid, catch-all, or risky—comes back in milliseconds.

This prevents wasted sends and protects sender reputation. It’s not just about catching typos; it’s about filtering out role accounts, disposable domains, and email traps. The API returns full error details: why a domain rejected a message, or if DKIM failed due to malformed or incorrect base64 encoding in the b= tag.

When bulk verification makes sense

Now imagine you’ve got a 10,000-record list from last year’s event. It hasn’t been cleaned in months. You can’t verify each one manually. That’s where bulk list checking comes in. You upload the list, and the system checks every address in parallel. It still validates each DKIM b= field with full base64 parsing, but it also gives you a summary: how many are invalid, how many are risky, and which domains are failing consistently.

For example, you might find that 12% of your list belongs to domains with strict greylisting or invalid MX records. Or that 3% are from disposable email providers—a red flag for engagement. These patterns aren’t visible during single checks. Bulk runs show you where to focus cleanup efforts, helping you improve deliverability and avoid blacklists. Bulk verification is not just verification—it’s a diagnostic tool.

Both approaches rely on the same core validation logic. Whether a single address or 10,000, each receives the same rigorous check: DNS, MX, SMTP, role account detection, and DKIM b= base64 validation. But the difference lies in context and intent. Real-time protects your live flow. Bulk improves your list health and long-term deliverability.

What’s the difference between validation, verification, and authentication?

Validation checks syntax and domain existence. Verification confirms an inbox is active and can receive messages. Authentication—using SPF, DKIM, and DMARC—proves a sender’s identity and prevents spoofing. MailTester tests all three, with detailed error reporting on DKIM b= field failures and other authentication issues.

Validation: The basic check

Validation is the first step—making sure an email address follows the right format. Is the @ symbol present? Does the domain exist? This is done via simple syntax rules and DNS lookups. It catches obvious mistakes like "user@domain" or "user@@domain.com". But it doesn’t tell you if the mailbox actually exists.

For example, RFC 5322 defines the standard format for email addresses. A valid address must conform to these rules—but even a perfectly formatted address might not be deliverable.

Verification: Is the inbox open?

Verification goes beyond syntax. It checks whether the mailbox can receive messages by interacting with the mail server. This includes testing for syntax, domain reachability, and whether the email address is likely to be open or disposable. It’s how you avoid sending to addresses that are inactive or permanently undeliverable.

MailTester’s real-time email verification API performs this step across multiple layers, including checking bounce types (hard vs. soft), role accounts, and disposable domains. You can verify a single address using our email checker or run bulk verification with our bulk tool.

Authentication: Proving who you are

Authentication is the final layer. It ensures the sender is who they claim to be. SPF checks if the sending server is authorized. DKIM signs messages with a cryptographic key to verify content hasn’t been tampered with. DMARC tells receivers how to handle messages that fail SPF or DKIM.

Malicious actors can still send emails that pass syntax and delivery checks—but fail authentication. That’s why we’re precise about DKIM. MailTester validates the b= field in DKIM signatures, checking its base64 encoding and correctness. When a signature fails, we report it explicitly—not just “failed” but “DKIM b= field invalid: incorrect base64 padding” or similar.

If your campaign is blocked by Gmail or Yahoo, authentication errors are often the reason. You can test this before sending using our inbox placement tester. This layer is what actually stops spoofing and builds sender reputation. It’s not optional—it’s mandatory for deliverability.

Which tools offer DKIM b= field base64 validation and error reporting?

You’re right to look closely—most email verification APIs treat DKIM as a simple yes/no check, but only a few, like MailTester, actually validate the b= field’s Base64 structure and return meaningful error details when it’s malformed. This matters: broken Base64 in DKIM signatures is a common reason for delivery failure, yet many tools silently accept invalid signatures. If you’re building or debugging a high-volume email system, knowing exactly when and why DKIM fails is critical—and that’s where actual structure-level validation comes in.

Where most tools fall short

ZeroBounce, NeverBounce, and Bouncer do not disclose their DKIM verification behavior, especially around b= field parsing—no details on whether they validate Base64 integrity or just check signature presence.
Kickbox and Emailable focus on syntax-level checks and domain reputation but don’t expose issues with Base64 decoding or structure in the b= field; they report "DKIM valid" even when the signature is malformed.
Many providers treat DKIM as a binary pass/fail, ignoring malformed or improperly encoded b= values—this can hide real delivery risks and make debugging tricky.

Why base64 structure validation matters

DKIM signatures require the b= field to contain correctly encoded Base64 data. If the signature is padded incorrectly, uses invalid characters, or has encoding issues (e.g. extra spaces, non-Base64 characters), the entire signature fails—even if the signature itself is technically 'present'. RFC 6376, the core DKIM standard, defines the expected structure, but few tools enforce it in real-time.

MailTester is one of the few tools that parses the Base64 content of the b= field and returns clear error details when it’s invalid, broken, or malformed. This lets you catch problems before sending, improve sender reputation, and reduce bounces. You can test this behavior directly using the MailTester API, where each response includes granular field-level diagnostics.

For teams using automated systems, knowing that DKIM validation includes real structure-level checks—beyond just key existence—makes a measurable difference in inbox placement and long-term deliverability. Not all tools go this far. If your workflow depends on reliable email verification, ensure your chosen API doesn’t just check 'if DKIM exists' but verifies that it’s technically valid. The difference between a pass/fail label and a real error report is everything when debugging delivery issues at scale.

What happens when you ignore base64 errors in DKIM b= fields?

Ignoring base64 errors in DKIM b= fields can cause your emails to be rejected, marked as spam, or fail delivery—even if your list is clean and your SPF/DKIM policies are technically correct. Malformed signatures break verification at the MTA level, triggering automatic rejection. This undermines sender reputation silently, making deliverability issues harder to diagnose.

Why base64 matters in DKIM signatures

The DKIM b= field contains a base64-encoded hash of your message body and headers. If it's incorrectly formatted—missing padding, invalid characters, or truncated—it fails signature validation. Even one character out of place causes the entire signature to be invalid. While some MTAs might still accept the message, others—especially those using strict spam filters—will drop it or flag it as suspicious.

According to the RFC 6376 specification, DKIM signature validation is binary: it either passes or fails. A malformed b= field means the validation fails, and mail servers have no obligation to accept the message. This is increasingly common with automated systems that generate emails without validating the DKIM output format.

Consequences for deliverability and sender health

You may see high bounce rates even with a supposedly clean list. These aren’t hard bounces from non-existent addresses—these are soft bounces or rejections due to failed DKIM checks. They appear as “delivered” in some reports but don’t reach inboxes.

Spam filters like those used by Gmail, Yahoo, and Microsoft are now designed to detect inconsistent DKIM signatures. A single malformed signature across a campaign can raise red flags, especially if you’re sending at scale. This doesn’t just affect one recipient—it signals to receiving servers that the sending infrastructure is unreliable.

The impact is cumulative. Even with valid SPF and DMARC policies, repeated DKIM failures erode your sender reputation. This makes domain warming more difficult and limits your ability to scale campaigns. You might hit sending limits or be flagged for review by major inbox providers.

Let’s say you’re using an email-verification API that checks for valid syntax in DKIM b= fields—before you send. That’s not a luxury. It’s a necessity. Tools like MailTester’s real-time API can catch these errors early, reporting malformed signatures so you can fix them before they damage your deliverability.

How MailTester’s 98.9% accuracy helps you identify real DKIM issues

Our 98.9% accuracy reflects actual email delivery behavior across real domains—not just theoretical setups. This includes domains with broken or misconfigured DKIM, ensuring you catch issues that passive checks miss.

We don’t rely on rules of thumb. Every verification simulates a real SMTP delivery attempt using open endpoints, validating the full chain—down to the base64 encoding in the DKIM b= field.

Invalid base64, malformed signatures, or missing keys show up as clear, actionable errors. Higher accuracy means you trust the results. You’re not just getting a score—you’re seeing real delivery risks.

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)
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)

Keep reading

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

Frequently asked questions

Does MailTester check the actual DKIM signature, or just the header?

We validate the full DKIM-Signature header, including the b= field, and perform base64 decoding on the signature value. If the b= field is malformed, we report it.

What is a 'DKIM b= field error' in MailTester’s response?

It means the base64 string in the b= field is invalid—missing padding, has invalid characters, or fails decoding. This indicates a broken or misconfigured DKIM setup.

Can I use MailTester’s API for real-time form validation?

Yes. The real-time verification API is designed for onboarding, registration, and form validation with instant results.

Do I need to set up DNS records to use MailTester’s API?

No. You only need to authenticate via API key. The tool checks your domain’s DNS records during verification, but you don’t need to configure anything in advance.

How do I integrate MailTester with Mailchimp or Klaviyo?

We offer native integrations with Mailchimp, Klaviyo, and SendGrid. You can schedule bulk tests and sync clean lists directly into your platform.

Are credits used in bulk verification transferable to API calls?

Yes. All purchased credits are reusable across bulk lists and real-time API calls. They never expire.

What’s the difference between a 'catch-all' and 'risky' email?

Catch-all means the domain accepts mail for any address, often indicating a spam trap. Risky means the address is valid but may fail delivery due to authentication issues, like a malformed DKIM b= field.

Can MailTester detect disposable email addresses?

Yes. It detects known disposable domains and flags them in the response with a specific category.

How long does a real-time verification take?

Typically 1–3 seconds per address, depending on network conditions and the sender’s infrastructure.

What’s included in MailTester’s inbox-placement testing?

We simulate delivery to major inboxes (Gmail, Outlook, Yahoo) to assess inbox placement, spam filter performance, and authentication alignment.

Do you verify role accounts like admin@ or sales@?

Yes. We flag role addresses and return them with a 'role' category, which you can filter out based on your list hygiene policy.

How can I report a false positive in verification?

Use the in-app feedback system. Our team reviews all reports and improves our models with real-world data.