DKIM H Field List Best Practices

Why DKIM H field formatting matters for inbox delivery

You’ve set up DKIM correctly—DNS records are in place, your key is generated, and your email passes basic checks. But your messages still get flagged as spam or bounce silently. The issue isn’t your key or your DNS. It’s the H field list in your DKIM signature.

Even a single misformatted header name can break DKIM validation. The RFC doesn’t allow flexibility here. If your H field omits a required header or formats it improperly—like adding extra spaces, using inconsistent casing, or misordering fields—mail servers reject the signature, no matter how strong your infrastructure is.

Think of the DKIM H field like a passport stamp: it must contain exact, ordered information. One typo, one extra space, and the entire system treats the document as invalid. This is why strict formatting isn’t optional—it’s the difference between inbox delivery and rejection.

Key takeaways

The DKIM H field must list only headers explicitly mentioned in RFC 6376, and in the exact order they appear in the message.
Whitespace between header names in the H field must be a single space; multiple spaces or line breaks cause validation failure.
Header names in the H field must use lowercase, as specified by RFC 6376, and must not include trailing colons or other punctuation.

What does RFC 6376 actually require for the DKIM-H field list?

According to RFC 6376, the DKIM-H field must list only the headers actually signed, in the exact order they appear in the message, with each name in lowercase and no colon. The list uses colons as delimiters with no spaces or extra punctuation. Getting this wrong breaks RFC compliance and risks signature failure or rejection by recipient servers.

Follow the RFC step by step

List only headers that are actually signed. Do not include headers like “Received” or “DKIM-Signature” unless your signing process explicitly covers them. Including extra headers can cause a signature validation failure even if the rest of the signature is correct.
Use lowercase header names only. Header names like “From” or “Subject” must be written as “from” and “subject”. Case matters in DKIM, and uppercase or mixed case violates RFC 6376.
Exclude the colon separator. Never write “From:” or “Subject:”. Just use the raw header name like “from” or “date” in the list. The colon is implied by the list format—it’s not part of the header name.
Preserve the exact order from the message. If “From” appears before “To” in the actual message headers, it must appear before “To” in the h= list. Reordering breaks the verification process.
Delimit with colons, no spaces. Use straight colons to separate entries: from:to:subject:date. No spaces after colons. No commas, no semicolons. Invalid delimiters break parsing.

Why this matters in practice

If your DKIM-H list deviates even slightly from RFC 6376, receiving servers may reject the message. Some mail systems will silently reject unsigned content or mark the envelope as suspicious. This impacts deliverability and harms sender reputation.

The 5 steps described in “Follow the RFC step by step”, in order.

For example, if you include “From:” instead of “from”, or insert a space after a colon, the signature fails validation—even if all other fields are correct. These aren’t subtle edge cases—they’re common mistakes that directly break compliance.

Check your signing tool’s output against the actual header order in a raw message. The message header order is final. You can use tools like RFC 6376 or MXToolbox to analyze a DKIM signature and verify the header list.

Use real-world verification before sending bulk mail. If you're building or testing DKIM signing, run your output through a tool like MailTester’s inbox placement test to see how your headers and signatures hold up in real email environments.

Common mistakes in DKIM H field list formatting

You’re likely violating RFC 6376 if your DKIM H field includes headers like 'Received' or 'Authentication-Results'—these aren’t signed and can break validation. Using mixed case (e.g., 'Subject', 'From'), spaces between header names ('From:Subject'), or full header syntax ('From:') instead of lowercase bare names (like 'from') is also non-compliant. Omitting an actual signed header or including one that wasn’t signed leads to signature failures. Stick to the standard: only signed headers, all lowercase, colon-separated, no extra whitespace.

What to avoid in the DKIM H field

Adding non-signed headers like Received, Authentication-Results, or DKIM-Signature—they’re not part of the digest and are ignored, but including them can still confuse validators.
Using uppercase or mixed case (e.g., From, Subject) instead of lowercase (from, subject). RFC 6376 requires all header names to be lowercase.
Adding spaces between header names in the H field, such as from:subject instead of from:subject. This breaks parsing and causes signature validation to fail.
Omitting a header that is actually in the signature or including one that wasn’t signed. The H field must match exactly what’s in the body and headers—no deviations.
Using full header syntax like From: or Message-ID: instead of just the name. The H field expects bare names, not full header lines.

How to get it right

Let’s say your email includes From:, To:, and Subject:. The DKIM H field must list them as from:to:subject—lowercase, no colons beyond the separator, no spaces. No extras. No missed entries. The DKIM specification explicitly defines this format.

If you're building a system that signs email at scale, validating your H field formatting early prevents bounces and deliverability issues. You can test individual email headers and signature structures using our inbox placement tester, which checks how your DKIM-signed messages appear across major providers.

The exact syntax rules from RFC 6376: Section 5.6

You must list only lowercase header field names in the h= tag, separated by colons, in the same order they appear in the canonicalized message body. Only headers present in the canonicalized body can be signed—excluding any from h= that weren’t included in the signature. This ensures strict RFC 6376 compliance and prevents signature verification failures.

Header field list rules in practice

Let’s break down how the h= field must be structured. The specification is precise: each field name must be lowercase, and the order must mirror the actual order in the final canonicalized message body. If an email’s From: header comes before To: in the body, then from must precede to in the h= list. No exceptions.

Headers not present in the canonicalized message body cannot be included in h=, even if they were originally in the raw email. This includes headers stripped during canonicalization (e.g., Received: or DKIM-Signature:), which are excluded from the signed content. Including such headers in h= violates RFC 6376 and causes a signature failure at the receiving end.

Requirement	Description	Example
Field names must be lowercase	Use `from`, not `From` or `FROM`	`h=from:to:subject`
Order must match the message body	Follow the sequence as they appear after canonicalization	If `Subject:` comes after `To:`, list `to:subject`
Only canonicalized headers appear in `h=`	If a header like `Received:` is removed during canonicalization, it cannot be signed	Do not include `received` in `h=` if it was stripped out
Excluded headers must not be listed	If a header is not signed, it cannot be referenced in `h=`	Never list `dkim-signature` or `authentication-results` in `h=`

These rules aren’t optional. They’re defined in the official RFC 6376, Section 5.6, which sets the standard for DKIM signing. Misformatting the h= field is one of the most common causes of failed DKIM validation.

When building DKIM signatures manually—or validating them—always refer back to the original message body in canonical form. Tools like MailTester’s API can verify DKIM-related syntax during email testing, helping you catch these alignment issues before sending a campaign.

How to verify your DKIM H field list is RFC compliant

Use a DKIM validator that checks both structure and signature logic against RFC 6376. Test with real inbound mail using tools like MxToolbox or a logging-enabled mail server. Compare your DKIM output against known compliant signatures from trusted senders. Then, validate the full email envelope and header using MailTester’s real-time verification API to catch issues early.

Step-by-step validation process

Validate DKIM structure using an RFC 6376-compliant tool. Not all validators check signature logic — only those that test both the header field list format and the signing process meet the standard. Tools like MxToolbox or open-source validators based on the RFC can confirm whether your h= field follows the correct syntax, including proper field ordering and escaping.
Test with real inbound mail through logging or monitoring tools. Simulate actual delivery by sending test emails to a mailbox with full header logging. Use a tool like MxToolbox to check the full header trace, including DKIM signature alignment. Real-world behavior often exposes issues not caught in static validation.
Compare your DKIM fields against known good implementations. Pull headers from messages sent by verified senders (e.g., major newsletters, trusted platforms). Look at their h= fields — what fields are included, in what order, and how are they delimited? RFC 6376 requires field names to be in a specific order, and skipping required headers (like from or subject) invalidates the signature.
Use MailTester’s real-time verification API to test the full email envelope. This API checks not just the DKIM signature, but the entire header structure, including the h= field, before sending. It confirms proper formatting, canonicalization, and alignment with domain policies. With no expiry on credits, you can run this repeatedly during development or deployment. Test your DKIM fields live with the API.

Why correctness matters

Even one incorrectly ordered or escaped field in the h= list breaks DKIM validation. Mail servers reject messages with invalid signatures, leading to high bounce rates and poor sender reputation. A correctly formed list ensures alignment between the signature and the actual headers received, which is the core requirement of RFC 6376.

Use MailTester to test both individual addresses and bulk lists. Its email checker helps you validate single addresses before sending, while its advanced inbox placement tests reveal deliverability risks tied to DKIM configuration.

Why header order is critical in DKIM H fields

DKIM signatures rely on the exact order of headers in the message. If a header listed in the DKIM H field appears in a different position than expected—say, moved by a mail relay or MTA—the canonicalization process will detect the mismatch, and the signature fails. Even one misplaced header breaks validation, regardless of how otherwise correct the signature is.

The role of canonicalization

DKIM uses canonicalization to standardize headers before signing and validating. The "relaxed" and "simple" schemes both depend on the order of headers in the message. With relaxed canonicalization, whitespace and line breaks are normalized, but header order remains strictly enforced.

Let’s say your DKIM H field includes From, To, and Date. If your MTA inserts a Received header before Date in the final message, but Date was signed in its original position, the signature can no longer match the canonicalized result.

This order sensitivity is baked into the RFC 6376 specification, which defines DKIM’s core behavior. You can review the exact rules in Section 3.4 of the standard, where canonicalization is detailed. While most implementations follow the specification closely, real-world systems often introduce subtle header reordering—especially in complex routing environments.

Common issues in practice

Even minor changes to your message can trigger failures. A header added by a security filter, a transport agent, or a content filter may shift the order unexpectedly. This is especially common in large-scale email platforms where multiple systems modify the message.

For example, a mailing list processor might prepend a List-Id header after the initial headers are signed, breaking alignment. Or an ESP like SendGrid or AWS SES might insert headers during transit without accounting for DKIM header order requirements.

It's not enough to sign the right headers. You must ensure they appear in the exact order expected by the signing mechanism. That’s why you must validate your DMARC and DKIM configurations at every stage of delivery. Tools like inbox placement testing can simulate real-world delivery and expose alignment issues before they cause delivery failures.

The impact of missing or extra headers in the H field

Missing a header in the H field that’s actually included in the signature breaks DKIM validation. Adding an extra header not present in the message causes strict servers to reject it. Even if SPF and DMARC pass, non-compliant DKIM signatures are rejected by modern mail servers — most common in enterprise-grade systems. You must sign exactly what’s in the message.

Common pitfalls in H field formatting

Include only headers that actually appear in the message’s final form — no assumptions about what should be there.
Ensure the H field lists every header used in the signature, even if it’s empty (e.g., From, Subject), because missing it fails validation.
Do not add headers not present in the original message, such as DKIM-Signature or Received — these are not part of the signing scope and cause rejection.
Whitespace, case, and order matter: headers must be in the exact sequence and format used in the final message, including correct capitalization.

Why strict validators block non-compliant signatures

Modern mail servers apply RFC 6376 (DKIM) with strict enforcement. The DKIM specification requires that the H field match the actual, delivered headers exactly. Even a single missing or extra header triggers failure. This is especially true for senders using automated systems that inject headers during routing.

Let’s say your system adds a X-Queue-ID header after signing — that’s not in the original message and shouldn’t be in the H field. Or if you drop a To field before sending but forgot to update the H field, validation fails. These mismatches are caught during the cryptographic check before any delivery decision is made.

Many mail servers, especially those used by large providers, now reject messages with any DKIM misalignment — even if SPF and DMARC pass. You can validate this behavior using real inbox tests. Use MailTester’s inbox placement tool to simulate real-world delivery and catch these issues before they hurt your deliverability.

How MailTester’s inbox-placement testing helps catch DKIM issues

You can catch DKIM signature issues early with MailTester’s inbox-placement testing, which examines the H field list in DKIM signatures for RFC 6376 compliance—ensuring header order, correct casing, and mandatory inclusion. It flags problems like improper header sorting or missing required fields, all without needing to decrypt the signature. This prevents delivery failures caused by DMARC or SPF rejection due to DKIM structure flaws.

Header-level inspection detects real-world DKIM problems

Many email systems don’t just validate the DKIM signature—it’s also critical that the header field list (H field) matches the signed content exactly. MailTester’s real-time deliverability test includes a deep inspection of the DKIM header, checking both the order and spelling of the headers listed. Even a single misordered or incorrectly capitalized header can invalidate the signature, leading to delivery failures.

Standard email infrastructure expects the H field to follow the exact format outlined in RFC 6376. This means the list must include all headers that were signed, in the correct case, and in the order they appear in the message. MailTester checks these constraints automatically, identifying issues like “From” being listed as “from” or “Subject” appearing before “To” when it shouldn’t. The test simulates how real receivers evaluate DKIM, giving you an accurate preview of inbox placement risk.

Unlike some tools that only return a yes/no on signature validity, MailTester returns detailed feedback about the exact nature of any DKIM flaw—such as “unexpected header order” or “incorrect case in H field”—without requiring you to decrypt the signature. This insight helps you debug the root cause directly in your mail server or sending platform. You don’t need to parse base64 or guess what went wrong.

For example, if your ESP adds a custom header like X-Tracking-ID to messages but doesn’t include it in the H field, MailTester will catch it. This is a common oversight during integration with CRM or marketing systems. By surfacing it before sending to real users, you reduce the chance of your messages being blocked by receivers that enforce strict DKIM validation.

Use MailTester’s inbox placement test to validate DKIM compliance across real-world email providers, or integrate the real-time verification API into your workflow for automated checks on every new address. Both tools include this header-level scrutiny, helping you maintain sender reputation and improve inbox placement before volume increases.

For context, the IETF’s RFC 6376 remains the definitive standard for DKIM, and many mail providers still enforce it strictly. Testing against the spec—rather than just a pass/fail rule—is how you future-proof your outbound email. Tools that skip this layer risk missing subtle errors that only appear in production.

Best practices for automating DKIM H field list correctness

To ensure RFC 6376 compliance in your DKIM H field list, use a trusted signing library that strictly follows the specification, validate header order before signing, test every signature with a full validation tool, and verify your headers using an automated system like MailTester’s API before sending. This prevents alignment errors and keeps deliverability high.

Automate header list validation and signing

Use a consistent DKIM signing library—OpenDKIM or DKIM-Filter—that implements RFC 6376 exactly. Custom implementations often miss edge cases like trailing whitespace or incorrect header ordering.
Never assume header order. Before signing, extract and sort the headers in the exact sequence your email will be sent, using a canonicalization method like "simple" or "relaxed". The order must match the final raw message.
Validate each DKIM signature immediately after generation using a tool that checks the full signature against the header list and body. Even a single missing or extraneous header breaks signature verification.

Embed verification into your workflow

Log every outgoing email’s DKIM signature and header list in a test environment. Use tools like MxToolbox or Spamhaus to test public headers and signatures, but only for real messages sent to test domains.
Integrate MailTester’s verification API into your sending workflow. It checks not just deliverability but also verifies that headers used in DKIM signing are properly ordered and canonicalized, catching issues before delivery.
Run automated inbox tests with MailTester’s inbox placement tool to confirm that properly signed emails land in inboxes, not spam folders, under real-world conditions.

Even a single incorrect header in the DKIM H field list can cause a signature to fail, leading to rejection by receiving servers—even if the rest of the message is flawless.

DKIM compliance is not optional — it’s a gatekeeper

Even with flawless SPF and DMARC configurations, a single malformed DKIM signature can trigger rejection or send a message to spam folders. The receiving server is unlikely to look past a DKIM failure if it violates RFC standards.

Mail servers that enforce strict RFC compliance drop messages with invalid H field formatting. This isn’t a preference — it’s a technical requirement. Misformatted headers break the cryptographic chain and invalidate the entire authentication process.

Consistent, correct H field formatting isn’t a bonus—it’s the baseline. Without it, even well-intended email campaigns fail to reach inboxes.

Sources

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

Keep reading

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

Frequently asked questions

What happens if my DKIM H field list is not RFC compliant?

The signature fails validation. The receiving server may reject the message or flag it as spam, even if SPF and DMARC pass. This harms sender reputation and inbox placement.

Can I include 'Message-ID' or 'Received' in the DKIM H field list?

Only if those headers are actually included in the signature. Typically, 'Message-ID' is excluded. 'Received' headers are never signed or included in the H field list.

Does the H field list need to include every header in the email?

No. Only headers that are part of the signature must be listed. Omitting non-signed headers is correct and required.

What’s the difference between 'h=from:subject' and 'h=From:Subject'?

The first is correct. All header names in the DKIM H field must be lowercase. Uppercase variants violate RFC 6376 and cause signature failure.

How do I test if my DKIM signature is valid?

Use tools like MxToolbox or MailTester’s inbox-placement testing. These validate the full DKIM signature against RFC 6376, including header order and formatting.

Does MailTester check DKIM signatures during verification?

Yes. MailTester's real-time verification API inspects DKIM headers as part of deliverability testing, flagging malformed H fields and validating signature structure.

Can I use an AI assistant to fix DKIM H field formatting?

Not directly. But MailTester’s in-app AI assistant can help identify issues in email headers during inbox-placement tests and suggest fixes based on RFC rules.

Why do some DKIM validators accept non-compliant H fields?

Some older or lenient validators may tolerate minor deviations. But strict receivers, especially in enterprise and mobile email, enforce RFC compliance. Relying on leniency is risky.

Is DKIM header order the same as the order in the email source?

Yes — in the 'relaxed' or 'simple' canonicalization. The H field list must reflect the actual order headers appear in the message, not the order they are processed.

Do I need to sign the 'To' or 'Cc' headers for DKIM to work?

They can be signed, but are not required. The decision depends on your signing policy. Just ensure any included header is listed in the H field, in lowercase and order.

How often should I audit my DKIM H field formatting?

Anytime you change your email signing process. Audits should be part of regular deliverability testing. Use MailTester’s API to automate checks across bulk sends.

Is there a tool to automatically generate the correct DKIM H field list?

Yes — most compliant signing libraries (like OpenDKIM) generate the list based on actual headers used in the signature. Manual generation is error-prone.