Why Is DKIM h Field List Syntax Critical for Email Deliverability?

You sent a perfectly crafted email. The content is clean, the timing is right, and the DNS records are set. But it lands in spam—or worse, vanishes silently. The culprit? A single misplaced character in the DKIM h field.

DKIM signatures are only as strong as their syntax. Even if your cryptographic key is valid, a malformed h field list breaks verification. Mail servers treat this as a critical failure—no exceptions.

The correct syntax for the DKIM h field list, defined in RFC 6376, dictates how header names must be ordered, separated, and encoded. Get it wrong, and the signature fails—regardless of everything else.

Key takeaways

  • The DKIM h field must list header names in lowercase, separated by colons, without spaces, and in the exact order they appear in the message.
  • Per RFC 6376, header names in the h field must be normalized—meaning the original case is discarded and the names are converted to lowercase before signing.
  • Any deviation, including extra spaces, mixed case, missing colons, or incorrect header order, results in signature verification failure, even with a valid cryptographic key.

What Is the DKIM h Field List According to RFC 6376?

The DKIM h field lists the header fields included in the cryptographic signature, with each name in lowercase and separated by a colon or space. It must be a valid, ordered sequence of header field names without extra delimiters. You must include only headers that are actually signed; missing or malformed entries break the signature’s integrity. For correctness, refer directly to the official specification at RFC 6376.

How the DKIM h Field Must Be Formatted

The h field isn’t just a list—it’s a precise requirement. Each header name must be in lowercase, exactly as it appears in the message. For example, from, to, subject. You can separate them with a colon (:) or a single space, but never both in the same list.

Let’s say you sign the from, to, and subject headers. The valid h field would be from:to:subject or from to subject. The order matters—headers are listed in the sequence they appear in the final signed message.

RFC 6376 specifies that the list must include only fields that are actually part of the canonicalized header block. Including extra headers like dkim-signature or received (which are generated in transit) will cause signature verification to fail. That’s why you can’t just guess—each header must match exactly how it appears in the final message.

Common mistakes include uppercase letters (From instead of from), missing a header that was signed, or adding non-header fields. Even a single typo breaks the signature. This is why thorough testing before sending is essential. Tools like bulk email verification help catch such issues before they lead to deliverability problems.

Why the h Field Matters for Deliverability

When a receiving server validates a DKIM signature, it uses the h field to determine which headers were signed. If the receiver finds any discrepancy in the header names or order, the signature fails. That leads to rejection or marking as spam.

Properly formatting the h field isn’t optional—it’s a core part of authenticating your domain. Misconfigured headers are a frequent cause of alignment failures, even when SPF and DKIM are otherwise correct. The RFC 6376 specification details these rules precisely, and compliance means your emails are taken seriously by mail providers.

The most reliable way to verify your DKIM setup is to test actual messages in a real inbox environment. Use inbox placement testing to see how your signed messages land across domains like Gmail, Outlook, and Yahoo—with or without DKIM errors flagged. That’s the real test of correctness.

How to Format the h Field List Correctly per RFC 6376

The correct syntax for the DKIM h field list requires lowercase header names, separated by a single colon or space, with no colons inside the field names. Avoid mixed case, commas, or multiple delimiters. Valid: from:subject:to. Invalid: From:Subject:To, from,subject,to, or from : subject. Use lowercase only and avoid extra punctuation.

Follow the RFC 6376 specification precisely

  • Use only lowercase header names: from, subject, to, date, cc, reply-to, etc. Uppercase or mixed case breaks the DKIM signature validation.
  • Separate field names with a single colon : or a single space — never both. from:subject:to is valid; from : subject is not.
  • Do not include a colon inside the field names. The colon is a delimiter, not part of the header name. from:subject is correct; from:subject: introduces an invalid trailing colon.
  • Avoid comma separation. from,subject,to is not valid DKIM syntax. Comma use is not defined in RFC 6376.
  • Do not insert spaces around colons unless using space as the delimiter. from : subject must be either from:subject or from subject.
  • Verify header field order only if required by your signing policy — the h field order determines how the signed headers are processed, so it must be consistent.
  • For full validation, refer to the official specification: RFC 6376 defines the syntax and processing rules.

Real-world implications of wrong formatting

Even a single incorrect character in the h field list can cause DKIM verification to fail. This triggers spam filters or rejection in mail servers that check DKIM integrity. A mismatch between the signed headers and those listed in h results in a failed signature, even if the email content is valid.

Let’s say you sign from:subject:to but the email header includes From: with capital F. The validator sees a mismatch. DKIM verification fails. Your sender reputation takes a hit. Even if your content is clean, delivery drops.

Use a tool like MailTester’s email checker to test individual addresses and verify if your email headers, including DKIM setup, are correctly structured before sending. It catches syntax issues early, helping maintain reliable deliverability.

Common DKIM h Field Syntax Errors That Break Deliverability

According to RFC 6376, the h field in DKIM signatures must list header names in lowercase, separated by colons, with no extra punctuation or whitespace. Using mixed case, trailing colons, incorrect delimiters, or unauthorized headers causes signature validation to fail, leading to deliverability issues. Even one wrong character breaks the entire signature. You can catch these errors early with a real-time verification tool.

Incorrect Header Name Case

  • DKIM requires all header names in the h field to be lowercase. Using From or Subject instead of from or subject fails validation.
  • Even a single uppercase letter breaks the algorithm's strict case sensitivity. Tools like RFC 6376 enforce this strictly.

Improper Delimiters and Whitespace

  • Delimit header names with a single colon (:), not commas (,) or spaces. A mix like from,subject:to is invalid.
  • Never add leading or trailing colons. :from:subject: produces a malformed header list and causes the signature to fail.
  • Whitespace between names or colons is not allowed. from : subject is rejected by validators.

Using Non-Standard or Unlisted Headers

  • Only headers explicitly named in the h field are signed. Including X-Auth-User or other non-standard headers without listing them breaks the signature.
  • Headers not in the h field are ignored during verification. Forcing them into the signature without inclusion causes a reject.
  • If you're using custom headers, ensure they are included in the h list using lowercase and proper colons: x-auth-user:from:subject.
Even minor syntax errors in the h field result in DKIM failures. One misstep, and your email may be flagged as spam or rejected outright.

Let’s be clear: DKIM isn’t forgiving. A single misstep in header naming, order, or delimiter usage can break deliverability. Use a tool that validates actual sending environments, not just syntax. Test your DKIM setup in real inbox conditions with MailTester’s inbox placement feature before sending to live audiences.

RFC 6376 Section 6.1: Validating the h Field List Syntax

The h field in a DKIM signature must list only valid header field names, as defined by RFC 5322. Each name must follow the exact syntax rules for header fields—no extra spaces, no special characters beyond allowed punctuation, and no unquoted tokens. The order of headers in the list does not influence verification, but the syntax must be flawless to pass validation. You can check this directly using tools like MailTester’s email checker to test individual addresses.

What Constitutes a Valid Header Name

Header field names must match the format specified in RFC 5322: they start with a letter, followed by letters, digits, or hyphens, and are case-insensitive. For example, Subject, From, and Content-Type are valid. But names like From- (hyphen at the end) or From: (extra punctuation) are not. You might think whitespace is harmless, but even a single space before or after a header name breaks the syntax. Let’s be clear: Subject is correct; Subject or Subject: is not.

Each header name in the h field must be syntactically valid, meaning it must not contain unescaped special characters like ;, ,, or + unless part of a structured field value. The list is comma-separated, with no spaces required after commas. So From,Subject is valid, but From , Subject is not. RFC 6376 does not require ordering, so Subject,From and From,Subject are equally acceptable—what matters is that each name is correctly formed.

How This Affects Real-World DKIM Signing

When sending emails, your email infrastructure must generate the h field by parsing the actual headers in the message and including only those that match the standards. If a header name is malformed or contains invalid characters—say, from a third-party system or a poorly formatted email client—it will invalidate the signature even if the content is correct.

For organizations using email marketing platforms, it’s critical to ensure that the DKIM signing process respects RFC 6376. If your tool doesn’t validate the h field structure, you risk failing authentication and being blocked by receiving mail servers. You can use MailTester’s real-time verification API to test DKIM signing accuracy at scale—especially useful when auditing or auditing bulk campaigns.

Ultimately, compliance with RFC 5322 and RFC 6376 isn’t just about passing a technical check. It’s about ensuring reliable delivery and protecting sender reputation. A single syntax error in the h field can result in failed authentication, even if the rest of the message is legitimate.

How to Test DKIM h Field Syntax in Practice

You can test DKIM h field syntax in practice by validating your DKIM headers during actual email sends using real-time tools, inspecting raw email headers for correct formatting, and sending test messages to inbox-placement services that analyze full signatures. The h field must list only the headers present in the signed message body, in the exact order and format specified in RFC 6376.

Validate DKIM Headers in Real Time

  1. Use a real-time verification tool like MailTester's API to check DKIM header structure before sending. This allows you to catch malformed h fields early in your workflow, especially when processing large volumes.
  2. Send test emails through your SMTP provider and configure DKIM signing correctly. Let the signature be generated with the exact headers you intend to sign, ensuring no extra or missing entries.
  3. Use RFC 6376, the official specification for DKIM, as your reference: the h field must contain only the header names listed in the signature, separated by colons, in the order they appear in the raw message.

Inspect and Verify Using Raw Headers

  1. After sending, retrieve the full raw email headers using a mail client with raw view (like Gmail’s "Show Original") or tools like MxToolbox. Look for the DKIM-Signature: header and verify the h= field matches the headers in your message.
  2. Check that header names are lowercase, correctly spaced (no extra spaces), and that the entire list aligns with the actual headers in the email body—especially those like from, to, subject, and date.
  3. Send test messages to an inbox-placement tool such as MailTester’s inbox tester. These tools analyze full DKIM signatures, including the h field, and can flag syntax errors like incorrect header ordering or invalid syntax.

Malformed h fields are a common cause of DKIM failures. Even a single extra space or mismatched header name can result in rejection by receiving servers. Double-check against RFC 6376’s requirements: no quoting, no duplicates, only listed headers that exist in the message. Consistency between signature and actual email headers is non-negotiable.

When the h field is malformed, even a valid private key cannot produce a valid signature. The recipient’s server will reject it outright.

For bulk email operations, use MailTester’s bulk verification to test lists for DKIM compliance at scale. This helps identify problematic sender configurations or poorly formatted mail streams before they harm your reputation.

What Happens When the h Field List Is Invalid?

If the h field in a DKIM signature contains incorrect syntax—such as missing required headers, malformed names, or invalid characters—the receiving server will reject the DKIM signature with a "signature verification failed" error. Even if SPF and DMARC pass, a failed DKIM check signals to email providers that the message may have been tampered with or poorly authenticated. This impacts sender reputation, increasing the chance your email lands in spam, gets throttled, or is outright rejected by major providers like Gmail, Yahoo, or Microsoft.

Why the h Field Matters

The h field lists the headers used to generate the DKIM signature. If it's malformed—say, it includes a header name with a space or non-ASCII character, or omits a required header like From or Date—the signing and verification processes become inconsistent. DKIM relies on strict agreement between the signing and verification ends. Any mismatch here triggers failure.

According to RFC 6376, the h field must include only valid header field names, and each name must be case-insensitive (though the canonical form is lowercase). It cannot contain duplicate entries, and names must not include non-printable characters. This standard ensures reliable verification across systems. You can review the full specification at RFC 6376.

Consequences in Practice

Even a single invalid header in the h field can break the signature. Providers like Gmail and Microsoft do not interpret this as a minor issue—they treat it as a signal of poor mailing hygiene. This can cause your messages to be flagged as suspicious, even if the content and sender reputation are otherwise solid.

Over time, repeated DKIM signature failures lower your sender reputation. ISPs monitor this across your IP and domain. Once reputation drops, deliverability drops with it. You might see inbox placement fall from 95% to below 60%, or worse, hit throttling that limits your send volume.

Let’s say you're sending newsletters. A misconfigured h field might not stop every message, but enough failures create a pattern recognized by filtering systems. Even if SPF passes and DMARC is enforced, a failing DKIM signature overrides that. The receiving server has a choice: trust a signature verification failure, or block it.

Tools like MailTester help catch these issues early. Its email checker and inbox placement tests validate the full authentication chain, helping you diagnose problems before they hurt deliverability. For bulk senders, bulk verification and the verification API ensure your list is cleaned and your authentication setup is sound across domains.

Best Practices for Building Reliable DKIM Signatures

According to RFC 6376, the h field in a DKIM signature must list header names in lowercase. Always verify your DKIM syntax matches this standard—using tools that test against real-world validation rules. Include only headers essential to message content, and validate every signature before sending at scale. This reduces parsing errors, improves deliverability, and protects sender reputation.

Keep It Standard: Field Names Must Be Lowercase

  • Always use lowercase for header field names in the h field—subject, not Subject or subject. RFC 6376 mandates this to ensure interoperability.
  • Mixing cases in the h field causes validation failure at the receiving end, even if the rest of the signature is correct.
  • Double-check any automated signing process: libraries or frameworks may uppercase headers by default.

Validate Early, Validate Often

  • Test every DKIM signature against known standards before sending to a large audience. A single syntax flaw can trigger spam filters or outright rejection.
  • Use tools with real-time validation—like MailTester’s email checker—to catch issues such as incorrect field formatting, missing required headers, or malformed hash values.
  • Don’t rely on your email service provider’s internal validation alone. External validation surfaces edge cases missed in automated pipelines.
  • Include only headers strictly necessary to the content—e.g., from, to, subject, date. Adding unnecessary headers like user-agent or content-type increases risk without benefit.
  • Over-including headers creates a larger attack surface and can trigger strict validation checks, especially in systems using DKIM policy enforcement.

For teams sending bulk or mission-critical email, integrate DKIM validation into your pre-send workflow. Tools like MailTester’s real-time verification API can validate DKIM correctness at scale, catching syntax errors early. This is not optional. It’s a baseline of reliable email delivery. The RFC is clear—stick to it.

RFC 6376 defines the technical specifics of DKIM, including the h field syntax. The standard is unambiguous: lowercase only. No exceptions.

According to RFC 6376, the DKIM h field must list header fields in the canonical order, separated by colons, and must include all headers used in the signature’s calculation. MailTester validates this syntax in real time, catching common errors like missing or malformed header names—ensuring your DKIM records are compliant before they impact deliverability.

Full DKIM Header Validation in Inbox-Placement Testing

When you run an inbox-placement test with MailTester, the system doesn’t just check if the email lands in the inbox—it verifies the full DKIM signature, including the h field, against the standards set in RFC 6376. This means you’re not just guessing whether your signature works—you’re seeing if it’s built correctly. If the header list is missing a required field or uses an incorrect format, the test will flag it, helping you avoid automatic rejection due to signature failure.

Proactive Checks Across Your Entire Email List

Let’s say you’re preparing a campaign and want to ensure every recipient’s domain supports proper DKIM. MailTester’s bulk list verification scans thousands of addresses at once, identifying domains with weak or missing DKIM practices. You’ll see which domains are likely to reject or mark your email as spam due to poor authentication, so you can clean your list before sending.

The real-time API, accessible via MailTester’s verification API, performs the same syntax checks on individual emails during send testing. It validates each header, ensures the h field follows RFC 6376 requirements, and returns a detailed response—so you know exactly what’s wrong if a signature fails.

If you’re debugging a failed DKIM signature, the in-app AI assistant offers context-aware suggestions. It doesn’t just say “syntax error”—it might point out that the h field is missing received or from when required, or that header names are improperly case-sensitive. This helps you resolve issues faster without needing to parse the RFC yourself.

You can integrate this workflow with your CRM or ESP via MailTester’s integrations, so every list you send through HubSpot, Klaviyo, or SendGrid gets pre-verified for authentication issues. This isn’t just a check—it’s a proactive defense against low deliverability and reputation loss.

DKIM is one of the core elements of trusted email delivery. By validating its structure down to the h field, MailTester ensures you’re not just sending mail—you’re sending mail that proves its legitimacy.

Key Takeaway: Syntax Matters, Even in Cryptographic Headers

A single incorrect character in the DKIM h field list — a misplaced space, an invalid token, or an unsupported header name — can cause verification to fail, even if the cryptographic signature is correct.

According to RFC 6376, the h field list must follow strict syntax rules. Deviations, no matter how minor, are treated as non-compliant, which means your messages risk being rejected or marked as suspicious by receivers.

How to Stay Compliant

  • Always validate the full DKIM header structure before sending.
  • Use tools that check both syntax and compliance with RFC 6376, not just basic format.
  • Test your emails in real inbox environments to catch issues before they impact delivery.

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 'h' field in DKIM mean?

The 'h' field in a DKIM signature lists the header fields included in the cryptographic hash. It must use lowercase names, separated by colons or spaces, per RFC 6376.

Can I use mixed case in the DKIM h field?

No. All header names in the h field must be lowercase. Using uppercase or mixed case results in signature failure.

What happens if I include extra spaces in the h field list?

Extra spaces, especially leading, trailing, or between fields, cause the DKIM signature to fail validation. Only single spaces or colons are allowed as separators.

Does the order of headers in the h field matter?

No. The order within the h field does not affect DKIM verification, but syntax correctness does.

Can I include custom headers in the DKIM h field?

Yes, but only if they are included in the h field list. Custom headers must still be lowercase and correctly delimited.

How do I test my DKIM h field syntax?

Send test emails and inspect raw headers, or use services like MailTester to validate DKIM structure and syntax in real time.

Why does my email pass SPF but fail DKIM?

SPF and DKIM are independent checks. A failed DKIM signature often stems from invalid syntax in the h field, like incorrect casing or delimiter use.

Does RFC 6376 require a specific DKIM header order?

No. The order of DKIM headers in the message is not defined by RFC 6376. Only the h field list syntax and cryptographic integrity matter.

Can DKIM fail due to header field names not being in the h list?

Yes. If a header used in the signature is not listed in the h field, the verification will fail, even if cryptographic keys are correct.

How accurate is MailTester at detecting DKIM syntax errors?

MailTester's verification process has 98.9% accuracy, including detection of common DKIM syntax issues like invalid h field formatting.