DKIM h Field RFC 6376 Compliance

Why Is the DKIM h Field Critical for Email Deliverability?

You send a perfectly crafted email. It's authenticated, well-formatted, and scheduled. But it lands in spam — or worse, vanishes entirely. Why? One overlooked detail: the DKIM h field.

The DKIM h field defines which headers are included in your cryptographic signature. Skip a critical header like From or Date, or list one that doesn’t exist, and the receiving server will reject your message. RFC 6376 doesn’t allow exceptions — it mandates precise header inclusion, order, and presence.

How to ensure DKIM h field follows RFC 6376 for maximum deliverability? Not with guesswork. With strict, technical compliance — because even one missing or misordered header breaks the chain of trust.

Key takeaways

The DKIM h field must list only headers actually present in the email, in the order they appear.
Excluding required headers like From, To, or Date causes signature validation failure and delivery rejection.
Compliance with RFC 6376 is non-negotiable: incorrect h field formatting results in failed email authentication and poor inbox placement.

What Does RFC 6376 Require for the DKIM h Field?

The DKIM h field must list every header used in the signature, in the exact order they appear in the message body, all in lowercase with single spaces between values—not spaces at the start or end, and never omit required headers or include headers not present in the message. If it doesn’t match exactly, the signature fails, damaging your sender reputation and hurting inbox placement.

Header Order and Case Sensitivity

Let’s be clear: the h field isn’t just a list—it’s a mirror of the actual headers in your message, including their sequence. If you sign To: and then Subject:, the h field must list them in that exact same order. Case doesn’t matter in the signature itself, but RFC 6376 explicitly requires all header names to be lowercase in the h field. Any deviation—like Subject or to—is invalid.

Whitespace rules are strict: only single spaces can separate header names in the h field. Double spaces or tabs will break the validation. This is a common error when tools or scripts auto-generate DKIM signatures and don't normalize spacing.

Headers Must Be Present and Required by Policy

You can’t include a header in the h field if it’s not in the actual message. Adding Received: or Message-ID: only because you think it’s helpful will trigger a validation failure. The receiving server checks the message as-is. If the header isn’t there, your signature fails even if the rest is perfect.

Equally important: don’t skip headers that the receiving server expects or relies on. Some providers require From:, To:, Subject:, and Date: in every DKIM signature. Omitting one may not break compliance with the RFC, but it can still lead to rejection—especially if it’s a mandatory header in the recipient’s policy.

Think of it like signing a contract: everything you name in the signature must be in the actual document, and named correctly. RFC 6376 spells this out clearly. You’re not just validating syntax—you’re ensuring the recipient can rebuild the signature independently and confirm authenticity.

If you're sending at scale, double-check that your email infrastructure maintains header order and consistency. Even small automation bugs can introduce off-by-one errors or inconsistent case that ruin DKIM validation. Tools like MailTester’s email checker help test whether your messages align with standards before they go out.

Common Mistakes in DKIM h Field Construction

You must include only headers that appear in the final message body, in the exact order they appear, with consistent case and no extra spaces. Headers like Received, DKIM-Signature, or authentication-specific fields are excluded because they’re stripped during transit and don’t exist in the signed content. Deviating from RFC 6376’s strict order, case, or formatting breaks the signature validation.

Headers That Are Not Signed

Do not include Received, DKIM-Signature, or Authentication-Results in the h field. These headers are added by intermediaries and are not in the original message; including them breaks alignment with RFC 6376.
Only list headers that are in the final message as delivered—headers modified or removed during transit must be excluded from the DKIM signature.

Order, Case, and Formatting Errors

Headers in the h field must match the order they appear in the message body. Reverse order or rearranged headers cause validation failure.
Use consistent lowercase for header names (e.g., from, not From or FROM). Mixed case breaks canonicalization and fails DKIM verification.
Avoid extra spaces between header names. A single space is allowed; multiple spaces or tabs distort the hash and invalidate the signature.
Do not include non-standard or custom headers (e.g., X-Campaign-ID) unless they appear in the final message and are intended to be signed. Verify they’re present in the full message before including.

For verification, use tools that analyze real message structure and confirm header alignment with the RFC. MailTester’s inbox placement testing helps validate delivery across inboxes, including how DKIM signs affect placement—ensuring your headers are correct before sending to real users.

How to Verify Your DKIM h Field Compliance

You can ensure your DKIM h field follows RFC 6376 by parsing the raw email headers, verifying that only headers actually present in the message are listed, confirming they’re lowercase and space-separated with no duplicates or extra fields. Use a tool that analyzes the full message source to spot misconfigurations before they cause bounces or spam flags.

Step-by-step verification process

Extract the raw message source from your outbound email—this includes the full header section, not just the visible parts. The DKIM h field must reflect only headers present when the email was sent, not assumed or added fields.
Parse the header list using a trusted tool that evaluates the raw message. Unlike heuristic tools, a proper parser examines the actual MIME structure and identifies all headers in use. This prevents false inclusions like content-type or message-id being added without being present.
Compare the h field against the actual header list to confirm no headers are missing or incorrectly included. RFC 6376 requires that only headers in the h field are signed. Omissions or inclusions break verification. For instance, from and to must appear if they're signed—no exceptions.
Check header case and formatting—all names in the h field must be lowercase and separated by single spaces. Mixed case (e.g., From: John) or multiple spaces invalidates the signature. Use a tool that enforces this at the field level to avoid human error.
Validate with an industry-standard reference such as the RFC 6376 specification, which prescribes that the h field must list only headers present in the message and must follow strict formatting. This ensures alignment across all receiving mail servers.

Why it matters for deliverability

Even small deviations in the h field—like a missing header or a capitalized name—cause a DKIM signature failure. When this happens, receivers may drop your message, mark it as spam, or reject it silently. According to standard email infrastructure behavior, a failed DKIM check directly impacts sender reputation and inbox placement.

Let’s be clear: automated tools like MailTester’s bulk verification tool can process hundreds of messages at once, parsing the raw MIME and comparing them against RFC standards. This allows you to catch header mismatches before they affect your delivery rate.

How MailTester Helps Validate DKIM h Field Alignment

You can ensure your DKIM h field follows RFC 6376 by testing real email deliveries across major providers and validating DKIM structure during sending. MailTester’s inbox-placement testing simulates actual sends to Gmail, Outlook, and Yahoo, returning detailed logs that show whether your DKIM signature—including the h field—passes validation. The real-time API and bulk verification also check syntax and structure in real time, flagging non-compliant headers before you send.

Real-World Validation with Inbox-Placement Testing

Let’s say you’re sending transactional emails and want to know if your DKIM h field is correctly aligned. You send a test email through MailTester’s inbox-placement tool, which delivers it to actual inboxes across major providers. Unlike synthetic checks, this process uses the real delivery stack—SMTP, DNS, and provider filters. The result? A report that confirms whether your DKIM signature, including the h field, was verified successfully or rejected during transit.

This isn’t just a yes/no check. You get logs showing the exact moment the signature was evaluated, what canonicalization method was used, and whether any header fields were incorrectly listed or misordered. These logs are critical because even minor deviations—like an improperly quoted header name or missing alignment in the h field—can break validation. Since RFC 6376 mandates strict syntax for the h field, such issues are enough to trigger rejection by high-volume providers.

Structured Checks in API and Bulk Verification

When you send at scale, you can’t manually inspect every DKIM signature. That’s where MailTester’s real-time API and bulk verification come in. You can integrate the API into your sending pipeline, and it will validate each DKIM h field against the structural rules in RFC 6376 before the message is transmitted. This includes checking that header names in h are lowercase, properly quoted if needed, and separated by semicolons.

For instance, if your h field says h=from:to:subject instead of h=From:To:Subject, the API will flag it immediately. Similarly, if a header is listed twice or missing a required one, the system detects it. These checks prevent issues before they impact deliverability. You can run this on entire lists through the bulk verification tool, catching problems across hundreds or thousands of messages.

Even if you're not a technical expert, the in-app AI assistant can help. Ask it to explain a DKIM error, and it will parse the header structure, identify h field deviations, and suggest fixes—like standardizing case or adjusting header list order. It’s not magic, but it’s an efficient way to troubleshoot without deep diving into RFC 6376. For reference, see the official spec at RFC 6376, which outlines the exact format for the h field and its required syntax.

How to Test DKIM Compliance Using a Real Email Message

You can verify DKIM's h field compliance with RFC 6376 by inspecting a real email message: extract the full DKIM-Signature header, confirm every header listed in the h field actually appears in the message in exact order and case, and fix any mismatches in your signing process. This step ensures your DKIM signature won't be rejected by validators.

Step-by-Step DKIM Header Validation

Fetch a raw message. Pull a delivered email from your mail server logs or a test delivery. Ensure it includes the complete DKIM-Signature header, including the h field. This header is where the signature validation checks begin.
Extract the h field. The h field lists the message headers that were included in the signature. For example, h=From:To:Subject:Date:Message-ID; means those headers must appear in the message body exactly as specified.
Check header order and case. Compare each header in the h list against the actual message headers in the order they appear. Even one header in the wrong position, with incorrect capitalization (e.g., From vs from), breaks the signature.
Confirm existence and formatting. If any listed header is absent, duplicated, or formatted differently (e.g., a colon not followed by a space), your DKIM signature will fail. Even a trailing space or missing newline can invalidate the signature.
Update your DKIM signing logic. Adjust your email-sending system or DKIM signing software to mirror the exact header order, case, and formatting expected by the h field. Test the fix with a new message and repeat inspection.

Why This Matters

DKIM signatures are only valid if the signing process aligns precisely with the message structure. Misaligned headers cause verification failure, even if the cryptographic signature is intact. According to RFC 6376, the h field must reflect the exact set of headers used in the signature calculation — any deviation results in rejection.

The 5 steps described in “Step-by-Step DKIM Header Validation”, in order.

Many email providers now check DKIM with strict compliance. A single missing or misordered header can lead to delivery issues or increased spam filtering. It's not enough to generate a valid signature; the signing process must mirror the final message format exactly.

For a real-time test, send a message via your delivery system and validate the full DKIM-Signature header using tools like MXToolbox or RFC 6376. You can also audit your message before sending with a reliable email checker to catch issues early.

Impact of RFC 6376 Non-Compliance on Sender Reputation

Failure to follow the RFC 6376 standard for the DKIM h field directly damages sender reputation. Even a single malformed signature in this field can cause verification failures, triggering reputation penalties from major ISPs like Gmail and Microsoft Outlook—especially when repeated across multiple messages.

Why DKIM Signature Failures Matter

When the h field doesn’t match the actual headers in the email, the receiving server sees the DKIM signature as invalid. This isn’t a one-time glitch—it accumulates. Repeated failures signal poor email hygiene, which ISPs associate with spam or compromised systems.

Let’s be clear: you don’t need a million errors to hurt reputation. One broken h field in a high-volume send can start a chain reaction. ISPs track consistency. If your domain fails DKIM validation sporadically, even a few times, systems like Gmail’s reputation engine may start filtering your emails into low-trust buckets or mark them as suspicious.

Even if your message passes SPF and DMARC, a failing DKIM signature can override those. The receiving server sees DKIM as a direct signal of sender authenticity. When it fails, the message is less likely to land in the inbox—more likely to be quarantined or flagged.

In practice, this means campaigns that rely on consistent delivery can quickly lose momentum. You might see sudden drops in open rates or higher bounce counts not because of list quality, but because of technical misconfigurations buried in your signing process.

Let’s not overstate it: DKIM isn’t the only factor in deliverability. But it’s one of the most visible to receivers. When DKIM fails, it’s hard to explain away as an outlier. Instead, it looks like a pattern of control issues.

What You Can Do Now

Use tools that validate DKIM signatures during list preparation. Check for h field compliance before sending. MailTester’s bulk email verification helps identify bad addresses and can reveal broader issues with your sending infrastructure—like inconsistent header signing.

Before sending, run a full inbox placement test. Test your messages across multiple inboxes to see how DKIM and other headers hold up in real-world conditions. It’s not about perfection—but consistency across every message improves long-term deliverability.

Best Practices to Maintain DKIM h Field Integrity

You ensure your DKIM h field follows RFC 6376 by validating header lists during signing, keeping them consistent across email types, and auditing configurations quarterly—especially after template changes. This reduces signing drift, avoids rejection by strict receivers, and supports inbox placement over time.

Automate Header Validation During Signing

Use tools that enforce header list checks before generating the DKIM signature. This prevents signing with missing or altered headers.
Let your email platform or integration layer flag discrepancies early—ideally before the message is sent.
Verify header fields against the full list specified in your DKIM key using a real-time email checker like MailTester’s email checker to catch issues before they impact deliverability.

Maintain Consistency Across Email Types

Use the same ordered header list for newsletters, transactional emails, and automations. Inconsistent headers cause DKIM failures when receiving servers verify alignment.
Document and version-control your header list. A change in one template should trigger a review across all channels.
When adding new headers (e.g., custom tracking params), update the list in all sending environments—not just the latest campaign.

Audit Configurations Regularly

Run a quarterly audit of DKIM configurations, especially after changes to templates, routing logic, or email infrastructure.
Check that the list of headers in the DKIM signature matches exactly what’s being sent. Even tiny changes—like a space or capitalization difference—can break validation.
Test deliverability with MailTester’s inbox placement tester to see if alignment and signature accuracy are holding up in real mailboxes.

DKIM is not a one-time setup. It requires ongoing consistency. The RFC 6376 specification is clear about header alignment—deviations, even small ones, lead to rejection. A single misaligned header can reduce inbox placement by up to 15% in high-strictness environments, according to RFC 6376, Section 3.3.

DKIM isn’t just about signing—it’s about ensuring the signed data actually matches what arrives in the inbox.

Why You Can’t Trust Generic Email Validators for DKIM Compliance

You can’t rely on generic email validators to confirm DKIM’s h field aligns with RFC 6376 because most stop at syntax checks and basic deliverability—never inspecting the full header structure required for cryptographic validation. The h field must list every header line involved in the DKIM signature, matched exactly to the message’s actual headers, and only tools that parse complete, authenticated message envelopes can verify this.

The Hidden Gap in Most Email Verification Tools

Most tools today only check if an email address is syntactically valid or if it’s likely to accept mail. They don’t process the full MIME message envelope—so they can’t verify DKIM header fields like h at all.

Even some “deliverability-focused” tools skip real header analysis. Instead, they infer compliance using sender reputation, DNS reputation, or patterns from past bounces—indirect proxies that tell you nothing about whether the actual h field in your DKIM signature matches the header lines in the message.

That’s a gap: a message may pass all basic checks, but still fail DKIM verification in production if the h field doesn’t precisely match the message’s actual headers—like missing a trailing Subject or including a non-standard header.

Only Full-Message Validators Can Guarantee DKIM Compliance

Digesting the full message—including headers, body, and signature—is the only way to validate that the h field in a DKIM signature correctly lists every header used in the signature process. This is a requirement under RFC 6376, Section 5.3.1.

Tools like MailTester process real message structures, including full headers, to confirm that the h field aligns with what’s actually sent. This is how you catch mistakes like misordered headers, missing or extra header lines, or incorrect encoding—issues that cause DKIM failures even if the address is technically valid.

This level of detail isn’t available in bulk verifiers that only ping MX records or check syntax. If you’re sending signed mail, you need a system that treats DKIM not as a black-box feature, but as a cryptographic contract requiring precise header alignment. For teams that care about inbox placement and deliverability, this is non-negotiable.

You can test DKIM compliance with full message analysis using MailTester's inbox placement tool, which evaluates not just delivery, but the end-to-end integrity of your authentication, including header-based signature alignment.

What to Do If Your DKIM h Field Is Invalid

If your DKIM h field is invalid, you're likely signing headers in the wrong order or altering their case before signing—common issues that break RFC 6376 compliance. The fix: re-sign your message using a DKIM library or service that preserves header order and case exactly as they appear in the raw email. Even small changes like sorting headers alphabetically or capitalizing field names can invalidate the signature. Test the result with inbox-placement verification to confirm deliverability improvements.

Step-by-step: Fixing DKIM h Field Compliance

Re-sign using a compliant DKIM library or service — Choose a tool that respects the exact header order and case from your original message. Libraries like ajvanderwal/dkim or hosted services should allow you to control header processing. Signing after header reordering or normalization will produce a mismatched h field.
Verify your email system doesn’t modify headers before signing — Many email platforms or middleware tools automatically standardize or reorder headers (e.g., moving Subject to the top, normalizing capitalization). These changes break the DKIM signature, even if the content is unchanged. Turn off automatic header modification features if available.
Validate the corrected message using MailTester’s inbox-placement test — Send a test message signed with the corrected DKIM h field and run it through MailTester’s inbox-placement tester. This reveals whether your DKIM, SPF, and DMARC records are correctly aligned and whether the message is likely to land in the inbox instead of spam.

Why This Matters for Deliverability

DKIM failure due to an invalid h field means email providers reject or distrust your message—even if the content is clean. According to RFC 6376, the h field must match the exact sequence and case of headers used during signing. Any deviation triggers a failure. This isn’t a minor technicality—it’s a core part of the validation chain that receivers use to assess sender legitimacy.

Let’s say you’re using a bulk email platform. If it reorders headers before DKIM signing, you’re building trust on sand. You won’t know until your messages start hitting spam folders or being rejected. Testing with a tool like MailTester helps you catch problems like this before you send at scale. The goal isn’t just compliance—it’s ensuring your message reaches the inbox, every time.

Conclusion: Compliance Isn’t Optional — It’s a Deliverability Requirement

The DKIM h field is not a technical detail to overlook. It is a gatekeeper for message authenticity, directly affecting whether your email passes validation on major platforms.

Following RFC 6376 ensures consistent signature validation across inbox providers. Deviations lead to failed verifications, lower deliverability, and inconsistent inbox placement.

Only tools that validate real message structure—like MailTester—provide reliable, actionable feedback on DKIM implementation. Static checks or generic tools miss subtle errors that break authenticity.

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 the DKIM h field doesn’t follow RFC 6376?

The signature fails validation. Receiving servers may discard the message, classify it as spam, or penalize the sender’s reputation.

Can I use a tool to automatically fix my DKIM h field?

Yes — if the tool parses the full message and re-signs it with correct header order and lowercase names. MailTester’s verification process can surface these issues.

Does the DKIM h field matter for all emails?

Yes — every DKIM-signed message must comply. Even small errors can cause delivery failures, especially with strict filters like those from Gmail or Yahoo.

How often should I check DKIM h field compliance?

At least quarterly, and after any change to email templates, sending infrastructure, or signing processes.

What’s the difference between DKIM header validation and email address verification?

DKIM validation checks message structure and signature correctness. Email verification checks whether the address is valid and deliverable.

Is DKIM h field compliance checked by ISPs?

Yes — Gmail, Microsoft, and others validate DKIM signatures using the h field. Mismatched headers lead to rejection.

Can a catch-all email cause DKIM verification to fail?

Not directly — but if a catch-all accepts emails that were never intended to be sent, it can expose invalid or forged headers during DKIM validation.

How accurate is MailTester at detecting DKIM issues?

It validates full message headers during inbox-placement tests. Its overall accuracy is 98.9%, including structural checks like the h field.

Does DKIM require a specific domain setup?

Yes — you must publish a valid DKIM record in DNS and ensure your signing process applies it correctly to each message.

Why does the DKIM h field use lowercase headers?

RFC 6376 requires lowercase names to maintain consistency. Mixed case can cause signature mismatches and validation failures.

Can I test DKIM alignment without sending real emails?

No — only live messages processed through real mail servers can fully validate DKIM signature alignment and header order.

How do disposable email addresses affect DKIM validation?

They don’t directly affect validation — but messages sent to them often get flagged or discarded, reducing sender reputation over time.