What does a DKIM verification error with 'H= header contains unexpected whitespace' actually mean?

You sent an email, it passed SPF and DKIM key checks, but still got rejected. The bounce report says: H= header contains unexpected whitespace. You’re not imagining it—this error is real, and it’s triggered by something that looks trivial: a space.

Even one extra space before, after, or between header names in the DKIM-Signature header breaks the strict format defined in RFC 6376. Receiving servers don’t interpret this as a "minor formatting issue"—they reject the signature outright. It’s not about the content of the email. It’s about how the signature’s header list was written.

This error is easy to miss in automated systems, especially during bulk sends or when using third-party tools that don’t enforce RFC-level validation. Knowing exactly what goes wrong—and how to prevent it—means fewer failed deliveries and stronger sender reputation.

Key takeaways

  • DKIM signatures must list headers in the H= field with no spaces—only periods as separators, as defined in RFC 6376.
  • Even one leading, trailing, or internal space in the H= value causes signature rejection by compliant mail servers.
  • Verification tools should validate DKIM syntax at the header-level, not just at key or domain alignment.

Why does unexpected whitespace in H= break DKIM validation?

You get a DKIM verification error when the H= header contains unexpected whitespace because DKIM relies on exact canonicalization of header fields. Even a single space or newline in the listed headers inside H= changes the computed signature, causing the receiving server to reject the email. The signature must match the canonicalized header list exactly — no deviations allowed.

The rigid rules of header canonicalization

Digital signatures in DKIM depend on precise, reproducible formatting. The receiving server recalculates the expected signature using the same header canonicalization rules: stripping unnecessary whitespace, normalizing line endings, and preserving only the intended header names. If your H= field lists From: To: Subject: with a space after the colon, or includes a space between header names like From : To :, the canonicalized version differs from the signed version.

Let’s say your message includes H=From: To: Subject: but has a trailing space, making it H=From: To: Subject: . That extra space alters the string hash used during signature verification. Even if the email content is correct, this mismatch breaks authentication — you’ve signed one string, but the receiver computed the signature from a different one.

How receivers catch these mismatches

Receiving servers apply the same canonicalization rules as the signing server. They parse the H= field, extract the listed headers, normalize them, and recompute the signature hash. If the result doesn’t match the one in the DKIM signature, the authentication fails — and spam filters or blocking systems often treat that as a red flag. The error message may say “unexpected whitespace” or “header mismatch” depending on the server’s enforcement.

Beyond just DKIM, this precision prevents tampering. If a single character changed, the signature would no longer be valid. This is why it’s critical not to rely on email clients or automation tools that modify headers without preserving the original structure.

For a real-world example, the DKIM RFC (6376) specifies that header field names are stripped of leading and trailing whitespace. The H= field must be exactly as signed. If your email service provider or ESP introduces whitespace or line breaks during relay, it can break validation — even if the rest of the message is correct.

Proper DKIM setup requires rigorous validation at every stage. Use tools like MailTester’s email checker to test individual addresses and verify header integrity before sending to high-value lists.

How to diagnose and correct H= header whitespace issues in your email setup

A DKIM verification error with "H= header contains unexpected whitespace" means your DKIM-Signature header includes spaces between header names, which violates RFC 6376. Only periods (.) should separate header names in the H= field. Correct it by inspecting your raw email, ensuring no extra spaces are inserted during header construction, and validating the H= value using tools like MxToolbox or MailTester’s real-time API before sending.

Detect the issue in your email source

Start with the raw email source. Look for the DKIM-Signature header and examine the H= value. It should list only header names separated by periods, with no spaces — for example, H=from:to:subject:date;. If you see spaces like H=from :to :subject;, that’s the error. This is a strict requirement in the DKIM specification (RFC 6376, Section 4.2).

Fix the root cause in your email system

  1. Inspect your email server or library code — if you're using PHPMailer, Django’s mail system, or Node.js nodemailer, double-check how you build the headers. A misconfigured loop or string concatenation can insert spaces. For example, joining header names with " + " + " instead of "." can break DKIM.
  2. Check third-party service documentation — SendGrid, Mailgun, and Amazon SES handle canonicalization automatically. However, their defaults might not align with your setup. Confirm whether they apply whitespace sanitization before signing. Some services apply fixes in transit, but relying on this is risky if you're doing custom signing.
  3. Validate the H= field using a testing tool — use a service like MxToolbox’s DKIM lookup or MailTester's real-time API to test a sample message before sending. These tools reveal formatting issues in the DKIM-Signature header without sending emails to real users.
  4. Test in isolation — disable any mail client or template engine for a moment. Send a test message using a minimal script that builds headers manually. If the error disappears, you’ve isolated the problem to your library or framework.
  5. Update your signature generation — ensure all header names in the H= field are lowercased and strictly separated by periods. Do not include leading/trailing whitespace. Use a known-good list: from:to:subject:date:content-type.

DKIM is a cornerstone of email authentication. A single space in the H= field can cause a signature to fail, even if everything else is correct. Fixing this requires attention to detail in header construction — and validation before sending. The cost of ignoring it is lower inbox placement, higher bounce rates, and damaged sender reputation. Use real tools to catch issues early.

Even a single whitespace error in the H= field breaks DKIM, no matter how strong the rest of your setup is.

What tools can verify DKIM-Signature headers for format correctness?

You can verify DKIM-Signature header format correctness using MailTester’s real-time verification API, which checks for anomalies like unexpected whitespace in the H= field and returns structured feedback. MxToolbox’s DKIM checker simulates real-world SMTP validation, and RFC 6376 defines the canonicalization rules you must follow to ensure proper syntax. No email client or webmail app can be trusted to catch format errors—only tools that parse the full header structure will spot issues like malformed H= values.

MailTester’s API catches subtle header flaws

Let’s be clear: DKIM verification errors caused by whitespace in the H= header aren’t caught by most tools. MailTester’s real-time verification API detects these anomalies during delivery simulation and returns precise, actionable results. The API parses the full DKIM-Signature header and reports whether fields like H= contain unexpected spaces, trailing newlines, or improperly quoted values—common mistakes that can cause signature rejection.

This level of detail is why you should use the verification API for production systems. Unlike many bulk tools, it validates the canonicalized output of the header, not just the presence of a signature. It flags formatting issues that break parsing at receiving servers, even when the signature appears syntactically correct to a human eye.

External validators and the real standard

When testing DKIM signatures in production or staging environments, MxToolbox’s DKIM checker is among the most reliable for real SMTP-style validation. It processes the full message and applies the exact canonicalization rules specified in RFC 6376, which defines how headers should be normalized before signing. For example, it expects the H= field to list header names in lowercase, separated by colons, with no extraneous whitespace between them.

That said, tools like Gmail or Outlook aren’t designed for diagnostics—they only show whether a signature passed or failed. They don’t report format-specific problems like invalid spaces in H= or malformed signature values. Relying on them for debugging is like checking the engine light without looking at the error code.

Common sources of whitespace in H= headers during email generation

DKIM verification errors with "h= header contains unexpected whitespace" usually stem from malformed header lists—especially spaces before or after header names during email construction. This happens when libraries, templates, or plugins improperly format the header array, violating RFC 6376's strict spacing rules. Let’s break down the real culprits.

Library or code-level header array issues

  • Using a mail library that doesn’t validate header formatting—like passing unescaped or improperly structured header arrays—can introduce invalid whitespace.
  • Some libraries expect header lists to be cleanly joined with colons, but if you manually join items with '; ' or ' ' instead, the resulting H= value will contain spaces that DKIM rejects.
  • Consider using a well-documented library like PHPMailer or Nodemailer—both enforce correct header syntax by default.

Template or plugin misconfigurations

  • Templates that append spaces before or after header names—like "Subject: " instead of Subject:—can break DKIM.
  • Content Management Systems (CMS) or ESP plugins that inject headers without parsing spacing rules (e.g., appending extra whitespace from a UI form) often trigger this error.
  • Use a tool like MailTester’s email checker to verify individual addresses and spot formatting issues at scale before sending.
  • Never auto-generate header lists via string concatenation if you can’t guarantee the format. Parse and rebuild them with a structured array instead.

Even a single space in an H= list makes the signature invalid. The standard specifies that header names must be separated by single semicolons with no adjacent spaces, per RFC 6376 section 3.4. This isn’t a tolerance—it’s a hard rule. You can’t rely on email providers to fix it. The error doesn’t appear in headers; it shows up as a failed verification on the receiving end. Let’s not guess—we can test it. Use MailTester’s bulk verification to catch these issues early in your sender workflows. It’s not about guesswork. It’s about catching errors before they hit inboxes.

How to prevent H= whitespace errors in future email campaigns

Prevent DKIM verification errors caused by unexpected whitespace in the H= header by validating email headers before sending. Use a real-time API to check for malformed syntax, enforce consistent header formatting with regex validation, rely on properly maintained email libraries, and test campaigns end-to-end with inbox placement and list hygiene tools. These steps stop errors before they affect deliverability.

Build checks into your workflow

  • Use MailTester’s real-time verification API to catch header issues like H= whitespace before sending. It checks the full DKIM signature structure, including the H= field, using current standards.
  • Implement pre-send validation that ensures the H= field matches the RFC 6376 requirement: ^[a-zA-Z0-9-]+(\.[a-zA-Z0-9-]+)*$. This prohibits spaces, special characters, and malformed domain segments.
  • Choose email libraries with strong DKIM support, such as OpenDKIM or libopendkim, which are tested and maintained by the email infrastructure community.

Test and verify at scale

  • Run bulk list verification using MailTester’s email list verify tool before campaigns. This catches invalid or malformed addresses early, reducing the chance of DKIM errors from bad data.
  • Include inbox placement testing with MailTester’s inbox tester to simulate real-world delivery conditions. This confirms your messages pass DKIM checks and land in inboxes, not junk folders.
  • Automate checks into your campaign workflow using MailTester’s integrations with SendGrid, HubSpot, Klaviyo, and more. This ensures every sending system validates headers consistently.
DKIM failures due to malformed headers are preventable when you treat header syntax like code—not a free-form string.

While DKIM verification is an industry-standard practice for authentication, it’s only effective when implemented exactly. Even one whitespace character in the H= header can break the signature. Let automated validation and proven libraries do the work—your reputation depends on it.

How MailTester helps catch DKIM formatting issues before sending

You can catch DKIM verification errors caused by unexpected whitespace in the H= header field—like those with broken DKIM policies—before they cause bounces or spam flags. MailTester’s real-time API checks the full email envelope, including headers and signature structure, and flags exact issues with clear feedback on which field and position contains the error, so you fix it immediately. No guesswork.

Full-envelope validation catches DKIM flaws early

DKIM signing requires precise header formatting. Even a single extra space in a field like H= can invalidate the signature. MailTester’s verification process parses the entire header structure during real-time checks, not just the email address. It validates both the syntactic correctness of DKIM headers and the integrity of the cryptographic signature. This catches issues that many basic tools miss.

When a H= header contains unexpected whitespace, MailTester returns a specific error message listing the affected header fields and the exact position of the invalid space. This level of detail lets developers and senders debug quickly. For example, a common issue is a missing newline or a trailing space in a DKIM-Signature header field. MailTester highlights these with precision, reducing time spent tracing obscure server-side failures.

Scale verification with bulk checks and integrations

When you’re managing thousands of subscriber emails, manually reviewing DKIM headers isn’t feasible. MailTester’s bulk verification feature scans large lists and identifies addresses tied to servers with broken DKIM policies—often the root cause of delivery failures. It returns detailed results including verification status, mailbox type, and header-level issues, so you can filter out risky addresses before sending.

Integrations with SendGrid, Mailchimp, HubSpot, and Klaviyo allow you to validate sender-side DKIM and header hygiene at scale. Every new address added to your campaign is checked in real time via API. You can catch flawed headers early, before they hit the inbox. This proactive approach reduces hard bounces, maintains sender reputation, and improves inbox placement.

For a deeper look at how header formatting impacts deliverability, the DKIM specification defines the correct structure for signature headers. Misalignment with these standards is a frequent source of delivery problems. You can test your own email flows with tools like the inbox placement tester or verify individual addresses using the email checker. For teams automating verification, the real-time verification API integrates directly into your workflow.

When DKIM failures due to whitespace might be ignored or tolerated

Some receiving servers tolerate minor whitespace inconsistencies in DKIM signatures—especially in the h= header—because they use lenient parsing. But this isn’t reliable: even if a message slips through today, it might fail tomorrow on another server. Don’t assume leniency means safety; it’s a gap in enforcement, not a standard.

Why some servers accept the error

Mail systems built on older or less strict parsing rules may overlook extra spaces or line breaks in the DKIM h= tag. This happens because some implementations prioritize delivery over strict RFC compliance. As a result, a message with a h= header contains unexpected whitespace error might still land in inboxes—even if it technically fails validation.

This leniency isn’t universal. Many modern servers enforce the standard rigorously. The DKIM specification clearly outlines syntax rules, including how headers must be formatted. Deviations, even small ones like trailing spaces, are considered invalid by strict parsers.

Why leniency is risky

Let’s be clear: depending on overlooked whitespace is dangerous. It violates RFC standards and can lead to inconsistent results. One day, your message passes. The next, it fails—without changing anything on your end—because a receiving server upgraded its validation logic. You won’t know why.

Older or misconfigured mail servers might fail silently, rejecting your message without a clear error. Some don’t even return a bounce; the sender gets no signal, and delivery fails with no trace. That’s especially harmful for bulk campaigns where undeliverable messages go unnoticed.

If you’re checking list health, verifying sender reputation, or testing inbox placement, don’t rely on exceptions. Use tools that catch these errors early. You can test how your messages will be validated across real-world conditions by running a DKIM and SPF inbox placement test with MailTester. It checks actual delivery paths, not just syntax.

Why fixing H= whitespace fixes more than just DKIM

Fixing H= whitespace in DKIM signatures isn’t just about compliance—it clears a technical hurdle that impacts sender reputation, inbox placement, and long-term deliverability. When your DKIM header contains unexpected spaces, even a single misformatted character, mail servers reject the signature, breaking authentication. This rejection signals poor technical hygiene, which spam filters correlate with higher risk—leading to lower inbox placement, even for legitimate senders.

Authentication hygiene affects more than one protocol

DKIM is only one layer of email authentication. When your H= header is malformed, it often indicates broader issues in how you generate or validate headers across your sending stack. Senders with inconsistent or broken DKIM often also have misconfigured SPF or DMARC policies, which compound deliverability issues. Fixing a single whitespace error can uncover systemic problems that degrade sender reputation over time.

Strict mailbox providers like Gmail, Outlook, and Yahoo routinely reject messages with any DKIM signature failure, regardless of content. A failure here doesn't just cause a bounce—it may trigger rate-limiting, quarantine, or even temporary blocklists. These systems treat repeated authentication failures as red flags, even if the email is legitimate.

It’s not just rejection—it’s long-term reputation damage

Mailbox providers use signals like authentication success rate, header consistency, and response latency to assess sender reliability. A persistent DKIM signature error, even minor like whitespace in H=, gets logged. Over time, repeated issues reduce your sender score. High-volume senders see throttling; smaller ones hit sending limits or inbox placement drops.

Correctly formatted DKIM headers also improve trust with infrastructure providers like MxToolbox or Spamhaus that evaluate mail hygiene. While neither service confirms individual header whitespace, their diagnostic tools reveal authentication failures that correlate with poor sender reputation. You can test your setup using MxToolbox or verify the structure of your DKIM signature against RFC 6376, the technical standard for DKIM.

Let’s be clear: fixing H= whitespace isn’t just about ticking a box. It’s about showing mailbox providers that you follow standards consistently. This consistency reduces bounce rates, especially with providers that enforce strict verification. If you're sending at scale, tools like MailTester's bulk verification can catch misformatted headers in your list before they cause delivery issues.

Final checklist: ensure your DKIM H= header is clean and valid

A single space or invalid character in the H= field can cause a DKIM verification error. The header must be strictly formatted to match the specification.

Verify the H= field syntax

  • Remove all spaces before, after, or within header names (e.g., "From" not " From " or "From ").
  • Ensure header names are lowercase and use only ASCII letters, digits, and hyphens (e.g., "subject", not "Subject" or "x-custom-header").
  • Use only a single period as the separator between header names (e.g., "from.to.subject", not "from, to, subject" or "from to subject").

Test your final DKIM signature output using MailTester’s real-time verification API. It checks the full DKIM signature, including the H= field, for compliance with RFC 6376.

For large sending volumes, use bulk verification to scan entire lists. This helps identify recurring issues and validates consistency across high-volume senders.

Sources

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 the DKIM error 'H= header contains unexpected whitespace' mean?

It means the DKIM-Signature header's H= field includes spaces that violate the canonicalization rules defined in RFC 6376, causing signature verification to fail.

Can a single space in the H= field break DKIM validation?

Yes — even one leading, trailing, or intra-field space will cause the canonicalized header list to differ from the recipient’s computed version, resulting in a failure.

How do I check if my H= header has whitespace issues?

Inspect the raw email source: look for the DKIM-Signature header and verify the H= value contains only header names separated by periods, with no spaces.

Does MailTester detect H= whitespace errors in DKIM signatures?

Yes — MailTester’s real-time API and bulk verification checks validate header formatting, including H= field structure, and reports anomalies with precision.

Are some email providers lenient with H= whitespace?

Some servers may accept misformatted H= values due to poor implementation, but this behavior is inconsistent and unreliable.

Why does DKIM fail even if the public key matches?

DKIM relies on exact agreement in canonicalized header content; whitespace in H= alters the signature’s scope, causing a mismatch even with correct keys.

Can a missing or extra header name in H= break DKIM?

Yes — if the H= list does not exactly match the headers included in the signature, verification fails, regardless of whitespace.

How can I test DKIM signatures before sending?

Use MailTester’s real-time API or tools like MxToolbox to validate a signature’s structure, including H= field formatting, before sending to real users.

Does the H= field include the DKIM-Signature header itself?

No — H= includes only the message headers included in the signature; the DKIM-Signature header is excluded from the list.

Is there a public list of DKIM errors by provider?

No — error reporting is not standardized. Most providers only indicate a failure, not the specific reason like whitespace in H=.