Why does your DKIM signature fail due to unexpected headers?

You’re sending transactional emails with perfect SPF and DMARC setups. But the DKIM signature fails—no clear reason, just a vague error. Sounds familiar? The issue might be buried in a tiny detail: headers like Cc or Bcc included in your DKIM signing list.

DKIM doesn’t allow you to sign arbitrary headers. It strictly follows RFC 6376, which defines a canonical list of headers allowed in the signature. When a signing library adds Cc or Bcc to that list—headers not permitted by the standard—the signature is invalid. Mail servers see this and reject the email outright.

You’re not dealing with a misconfigured server. You’re using a library or tool that didn’t follow the spec. The result? Hard bounces, failed delivery, and a damaged sender reputation. Fixing this isn’t about tweaking configs—it’s about aligning with the actual standard.

Key takeaways

  • DKIM signatures must only include headers explicitly allowed in RFC 6376; Cc and Bcc are not permitted in the signing list.
  • Adding unexpected headers like Cc or Bcc to the signing list causes DKIM validation failure, leading to hard bounces or inbox filtering.
  • Mail servers reject signatures with non-standard headers—even if the email content is correct—because the signature is technically invalid.

What is the DKIM H-tag and why does it matter?

The DKIM H-tag specifies which email headers are included in the cryptographic signature, ensuring only those headers are verified when a message arrives. If the receiving server finds a header like Cc or Bcc listed in the H-tag but it wasn’t present in the original message, or if it was altered en route, the signature fails. This is why listing unstable or non-standard headers in the H-tag causes a dkim h tag error: unexpected fields like Cc or Bcc in signing list — they’re not part of the standard, predictable set.

How the H-tag works in practice

When you sign an email with DKIM, you choose which headers to hash using the H-tag. Only those headers are checked during verification. If a receiving server expects a Cc header in the signature list but it’s missing or modified, the signature fails — even if the body was untouched. This isn’t a flaw in the algorithm, but a consequence of misconfiguring the signing process.

Headers like From, To, Date, and Subject are stable and consistently present. But fields like Cc, Bcc, or custom headers may not appear in every message — or may be added by gateways, mail filters, or clients. These changes break the signature, since the hash no longer matches what the server expects.

According to RFC 6376 (the standard defining DKIM), the H-tag must list only headers that are stable and predictable across all instances. Including Cc or Bcc violates this principle because their presence depends on message recipients or sending tools — they’re not reliable for hashing.

Why this matters for deliverability

DKIM failures lead to lower sender reputation, higher bounce rates, and increased chances of inbox filtering. Even a single incorrectly signed header can trigger a rejection from major providers like Gmail or Outlook.

Let’s say you’re sending a campaign and your ESP mistakenly includes Bcc in the H-tag. If the Bcc is dropped by your mail server during routing — which is common — the recipient server sees a mismatch, flags the signature as invalid, and may flag your domain as suspicious. This isn’t uncommon: many large-scale senders have seen delivery drops from misconfigured H-tags during audits.

To avoid this, keep your H-tag minimal and focused on standard, core headers. Avoid adding dynamic or conditional fields like Cc or Bcc unless you’re certain they’ll always be present and unaltered. Use tools like MailTester’s email checker to validate sender configurations before you send.

RFC 6376: The official standard for DKIM header fields

DKIM’s H-tag error occurs when headers like Cc or Bcc appear in the signing list because RFC 6376 explicitly excludes these from signing. Section 5.4 defines the allowed headers, and only those present in the final delivered message and not subject to modification should be signed. Including Cc or Bcc violates this rule, causing signing failures or verification rejections.

What the RFC says about signing headers

Section 5.4 of RFC 6376 specifies the syntax for the H-tag, listing only headers that are guaranteed to be stable across delivery paths. Standard headers like From, To, Subject, Date, and Message-ID are valid for signing. Cc and Bcc are not only excluded—they’re explicitly forbidden because they may be altered, removed, or added by mail servers during transit.

Let’s be clear: DKIM signs headers that remain unchanged from the time of signing to the time of delivery. If a header is not present in the final message or could be modified en route, it must not be signed. This includes Cc and Bcc, which are often injected or filtered by forwarders, mailing lists, or spam filters. Signing them introduces risk, breaking DKIM validation.

Why this matters for email deliverability

When a DKIM signature includes an invalid header like Bcc, the receiving server sees a mismatch. The recipient’s DMARC policy may reject the email outright if the signature fails, even if the content is valid. This is a common reason for emails to bounce or land in spam folders.

Some misconfigured mail systems try to sign all headers, including Cc and Bcc, as a shortcut. That’s not how DKIM works. If you’re seeing “unexpected fields” errors, it’s likely the result of improper signing. The solution is to validate the H-tag list against RFC 6376's approved list and strip any excluded headers before signing.

Use tools that check DKIM configuration before sending. You can test how your messages are verified in real-world inboxes with MailTester’s inbox placement tool, which simulates delivery across major providers and flags signing issues early. This helps catch H-tag errors before they affect sender reputation.

How to fix DKIM H-tag errors: A step-by-step process

DKIM H-tag errors occur when your signature includes unexpected headers like Cc or Bcc in the signed list. To fix it, locate your mail server or ESP’s DKIM configuration, remove Cc and Bcc from the H-tag list, keep only standard headers like From, To, Subject, Date, Message-ID, and optionally Reply-To, re-sign the message, and verify the new signature using a tool like MxToolbox or a custom DKIM validator.

Diagnose the root cause

Your DKIM signature is failing because the list of signed headers in the H-tag contains non-standard or sensitive fields like Cc or Bcc. These headers are often ignored during message parsing or deliberately excluded by receiving servers. Including them in the signature list is technically allowed, but some validators interpret it as an error, especially if not aligned with RFC 6376.

Let’s check your configuration. Open your mail server or ESP (such as SendGrid, Amazon SES, or Microsoft 365) DKIM settings and locate the header field list — sometimes called "signed headers" or "H-tag".

Fix and re-sign

  1. Review your DKIM header list. Look for explicit inclusion of Cc or Bcc. These are rarely needed and can trigger signature validation issues.
  2. Delete Cc and Bcc from the H-tag list. You only need the core, stable headers: From, To, Subject, Date, Message-ID, and optionally Reply-To. These are the only ones required by standards like RFC 6376 to be signed consistently.
  3. Retain only essential headers. Including fields like List-Id, Delivered-To, or other non-essential headers increases the risk of failure if they change during transit, even when the content is valid.
  4. Re-sign the message. After updating the header list, re-sign the email. This ensures the signature is generated with the corrected, compliant list.
  5. Verify the new signature. Use a public validator like MxToolbox DKIM Validator or a custom parser to decode and confirm the signature now includes only valid fields. A properly formed signature should align with the standard and pass SPF/DKIM/DMARC checks.

For automated verification of your entire list, consider testing individual addresses using MailTester’s email checker to catch header-level issues before sending at scale.

A common mistake is including dynamically generated headers in the DKIM sign list. Keep the list predictable. If you're unsure, stick to the minimal set required by the RFC. It’s one of the most reliable ways to avoid H-tag errors.

Why signing Cc or Bcc breaks DKIM validation

DKIM fails when you include Cc or Bcc headers in the signing list because those headers can change during transit—automatically removed, modified, or rewritten by mail servers based on policies like Bcc-to-sender. If the receiving server sees different Cc/Bcc values than the sender, the hash of the message body or headers won’t match the DKIM signature, causing validation to fail. Even small discrepancies in header order or content break the integrity check.

Headers change in transit — but DKIM expects consistency

Let’s be clear: DKIM doesn’t just check if headers exist—it checks whether they’re identical between signing and verification. If your server signs the original Cc and Bcc values, but the receiving server sees them altered (or excluded entirely), the signature fails. For example, some providers auto-add a Bcc to the sender or strip all Bccs for privacy.

Many organizations use email routing policies that modify or remove these headers. A message sent through a corporate gateway might strip Bccs before delivery. The DKIM signature, however, was calculated with those headers present—so the verifier sees a mismatch. This is not a flaw in DKIM; it’s a limitation of signing mutable information.

Why you shouldn’t sign Cc or Bcc — the technical trade-off

Signing Cc or Bcc fields increases the risk of failure because they are not reliable across the delivery chain. The DKIM specification itself requires strict field consistency—if the signing and verifying servers don’t see the exact same headers in the same order, the signature is invalid.

That means including Cc or Bcc in the signature can reduce deliverability. You might think “I’m being thorough,” but you’re actually introducing a failure point. Best practice: sign only headers that are guaranteed to remain unchanged—like From, Subject, To, and Date. The RFC explicitly lists these as stable fields in Section 5.4.

Use tools to test your DKIM alignment before sending. You can validate the full email header structure—including which headers are signed—via inbox placement testing, where you send a real email to multiple inboxes and see how DKIM behaves across providers.

Common misconfigurations that trigger this error

You’ve likely seen the "DKIM h tag error: unexpected fields like Cc or Bcc in signing list" when your emails fail validation. This happens not because of the recipient’s server, but because your DKIM signature includes headers in the H tag that aren't supposed to be signed—like Cc or Bcc. These fields are often added during templating, copied without review, or mishandled when using generic signing configurations across different message types.

Generic header sets across channels

  • Using the same list of headers in your DKIM H tag for newsletters, transactional emails, and automated alerts leads to errors. A Bcc field may be present in one channel but not another, triggering mismatches during validation.
  • Let’s say your template signs To, From, Subject, Cc without checking the actual message. If the Bcc field is populated in one instance but not another, the signed header list will differ—and DKIM will fail, even if the message content is correct.
  • Use tools that validate header sets per channel. MailTester's bulk verification can flag inconsistent or invalid email addresses early, catching issues before they impact your DKIM configuration.

Following templates without review

  • Just because a DKIM setup works in a template doesn’t mean it’s safe to copy blindly. The H tag may include Bcc or Cc unintentionally, and including these in the signed list breaks DKIM.
  • DKIM signs only what’s listed in the H tag—not the full message body or all headers. If you accidentally include Bcc in the list, even if it's empty, you’ll hit this error. The signing process assumes the header list is stable and consistent.
  • Check your DKIM setup against RFC 6376, which defines how DKIM should sign a limited set of headers. Only include headers you’re sure will always be present and unaltered.
  • Don’t assume your mail server or provider handles header normalization. The H tag must reflect exactly what you intend to sign. Use real-time checks: MailTester's verification API can test individual messages with specific header sets for DKIM compatibility.
DKIM doesn’t care about all headers. It only cares about the ones explicitly listed in the H tag. If your list includes Bcc or Cc when they’re not in use, you’ll get a validation failure.

How to test your DKIM signature for header list compliance

You can catch dkim h tag errors caused by unexpected fields like Cc or Bcc by validating your DNS record, inspecting raw email headers from a test send, and comparing the listed headers against the official list in RFC 6376. Any deviation from the allowed set will break DKIM verification and hurt deliverability. Let’s walk through the steps.

Step 1: Validate your DNS DKIM record

Use a trusted tool like MxToolbox’s DKIM Record Checker to ensure your DNS record is correctly formatted and published. A single typo can cause DKIM to fail even if your signing logic is sound. This step verifies that receiving servers can find and read your public key.

Step 2: Send a test email and extract raw headers

Send a message from your domain using your configured signing setup. Then, check the raw message source (available in most webmails or via a mail client like Thunderbird). Look for the DKIM-Signature header, which contains the H= field.

  1. Copy the full DKIM-Signature header from the raw email output.
  2. Locate the H= tag, which lists the headers included in the signature.
  3. Ensure only headers from the standard set defined in RFC 6376 Section 3.5 are included—this includes From, To, Subject, Date, and others, but excludes Cc, Bcc, and custom headers unless intentionally added with proper alignment.
  4. Check for any unexpected fields. If Cc or Bcc appear in the list, your DKIM signature has been incorrectly configured, and the signature will fail validation on servers that enforce strict header compliance.

Step 3: Automate checks with a real-time verification tool

Manual header inspection takes time and increases the risk of missing edge cases. Tools like the MailTester Email Verification API can automatically detect issues like improper header lists during bulk send prep. It flags domains with misconfigured DKIM or header anomalies before you send, reducing bounces and inbox placement issues.

For ongoing monitoring, consider integrating MailTester’s verification process into your email workflow. This ensures every message sent maintains header compliance, especially when using dynamic content or merged fields. The tool also helps identify domains with catch-all or disposable address patterns that can degrade sender reputation.

Even a well-formed DKIM signature fails if the H= list includes headers not permitted by RFC 6376. It’s not just about correctness—it’s about consistency across all messages.

Once validated, repeat the test periodically, especially after changing templates or automating messages. Keeping your header list compliant is a baseline step in maintaining strong sender reputation and inbox placement.

You prevent DKIM h-tag errors—like unexpected fields such as Cc or Bcc in the signing list—by validating email headers before sending. MailTester’s real-time API checks not only syntax but also detects misconfigured headers that break DKIM alignment, reducing bounces and inbox placement drops caused by malformed or inconsistent signing.

Real-time validation catches header-level risks early

When you send email, every header matters. DKIM signing must include only specific fields—listed in the H= tag—like To, From, Subject. Including Cc or Bcc in that list breaks the signature alignment. MailTester’s real-time API audits headers during verification, flagging these unexpected fields before they damage your sender reputation.

It’s not enough to know an address is valid. A perfectly formatted address with a broken DKIM header setup will fail alignment checks at the receiving end. MailTester checks both the address and the full mail flow context—especially critical when using automated tools that auto-generate headers.

Integrations help you audit sender setup alongside list quality

Integration with platforms like SendGrid, Mailchimp, and Klaviyo lets you test your entire setup—domains, headers, and recipient lists—before launching campaigns. You’re not just cleaning your list; you’re ensuring the entire email flow is compliant with SMTP and DKIM standards.

For example, if your campaign tool automatically includes Bcc in the header but doesn’t exclude it from the H= tag, MailTester flags it during bulk verification. This helps stop issues before they hit spam traps or trigger rejection by major inbox providers.

Using the real-time API or bulk verification tool, you can catch patterns—a high failure rate on a domain might signal widespread DKIM misconfigurations in that sender setup, not just invalid addresses.

Even better, the in-app AI assistant helps you analyze raw headers. Paste a full email header, and it highlights unexpected fields like Cc or Bcc in the signing list, explaining why it matters. This is especially useful during onboarding or for legacy email systems where header logic may be unclear.

For the full technical context, see the DKIM specification in RFC 6376, which defines which header fields can be signed.

What happens when DKIM fails due to invalid H-tag?

When a DKIM signature includes unexpected headers like Cc or Bcc in the signing list, the receiving server rejects the signature because it violates the DKIM RFC specification. This triggers immediate suspicion: the message may be flagged as spoofed or misconfigured, often leading to delivery failure or spam filtering.

Why this triggers spam defenses

Spam filters look for strict adherence to email standards. An invalid H-tag—especially one including non-standard headers like Cc or Bcc—breaks the DKIM signature's integrity. Receiving servers, especially large providers like Gmail or Microsoft, treat this as a red flag. It’s a common sign of automated or poorly managed sending systems, which increases the chance of the email being marked as spam or blocked entirely.

DKIM is designed to verify that the message body and key headers haven’t been altered in transit. When the signing list contains headers not covered by the original specification—like Cc or Bcc—it creates a mismatch at verification time. This isn’t just a technical hiccup; it’s an actionable signal to filters that something is off. Even if the content is clean, the inconsistency can trigger anti-abuse logic.

How this affects your sender reputation

Repeated DKIM failures, even due to small misconfigurations like invalid H-tags, accumulate over time. Email service providers track error rates and sender behavior to assess trustworthiness. A pattern of failed DKIM signatures harms sender reputation, which directly impacts inbox placement. Even one flawed message can cause a temporary dip, but consistent issues can lead to long-term filtering or blacklisting.

According to the RFC 6376 (the official DKIM standard), only specific headers are permitted in the signature list unless explicitly defined by the sender. Including Cc or Bcc without proper alignment or authorization breaches this rule. You can verify your DKIM setup and catch these issues before sending using a tool that tests both syntax and alignment. Check individual addresses for valid configuration, or run a bulk verification to audit your entire list against deliverability issues before hitting send.

Let’s be clear: even small technical missteps in authentication—like a misplaced H-tag—can have outsized consequences. Fixing one bad signature might not save your reputation, but catching all of them before you send does.

Preventing DKIM errors before they hit production

You can prevent DKIM h= tag errors like "unexpected fields in signing list" by reviewing configurations before deployment, testing with automated tools during staging, and ensuring admins follow RFC 6376 guidelines—especially around which headers to sign. These steps catch issues early, before they impact deliverability or trigger spam filters.

Proactive configuration review

  • Implement mandatory configuration reviews for every email-sending system before going live.
  • Check that only required headers (like From, To, Subject, etc.) are listed in the DKIM h= tag—never include Cc, Bcc, or other non-standard headers.
  • Use a simple checklist to validate the h= field content against RFC 6376, section 5.4, which defines the canonicalization rules for header fields.

Automated testing in staging environments

  • Run automated verification tools during QA to simulate real-world DKIM signing behavior.
  • Use tools that validate the signed headers against the h= list and flag any mismatches or unexpected fields.
  • Test against a range of receiving mail servers—some interpret strict DKIM rules differently, so catching discrepancies early prevents production issues.

Let’s be clear: a single misconfigured h= tag can lead to signature failures, even if the rest of the DKIM setup is correct. The RFC 6376 specifies how header fields should be signed, and while the standard allows flexibility, it does not permit signing Cc or Bcc unless explicitly included. Many modern spam filters, including those used by Gmail and Yahoo, reject or flag messages with unexpected header signs.

Training administrators on this RFC isn't just good practice—it’s essential. Misunderstandings about which headers should be signed are among the top causes of DKIM failure in enterprise setups.

If you're checking your sender infrastructure for issues like this, you can test your full email flow with a real-world inbox placement check:

simulate real delivery and validate header signing before sending to real users.

Conclusion: Fixing DKIM H-tag errors is not optional

Including unexpected headers like Cc or Bcc in the DKIM-Signature header's H-tag breaks the cryptographic proof of integrity. This causes DKIM verification to fail, leading to reduced inbox placement and sender reputation damage.

The fix is straightforward: ensure only essential headers—such as From, To, Subject, and Date—are included in the H-tag. Double-check your signing configuration against RFC 6376 to confirm compliance and avoid subtle misconfigurations.

Tools like MailTester help you test the full delivery chain, not just email addresses. They validate not just syntax, but the real-world behavior of each component, from DNS records to header integrity.

Sources

Keep reading

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

Frequently asked questions

Why does DKIM fail when Cc or Bcc is in the H-tag?

DKIM signatures require consistent headers between signing and verification. Cc and Bcc may be modified or absent during transit, causing a hash mismatch and failure.

Can I sign the To header if it’s in the body instead of the header?

No. The To header must be in the message header, not the body. DKIM signs only headers, not message content.

Does DKIM sign the body of the email too?

DKIM can sign both headers and body, but only if explicitly configured. The body is signed by default in many setups, but headers must be listed correctly.

How do I check my DKIM H-tag in a real email?

Inspect the raw email headers, locate the DKIM-Signature field, and check the H= part to see which headers are signed.

Yes, but only if the field is guaranteed to be stable. Including Reply-To in the H-tag increases verification accuracy.

Can I use DKIM with transactional emails that include dynamic headers?

Yes, but only if all headers in the H-tag remain consistent across messages. Dynamic fields like Bcc should not be included.

What is the difference between SPF, DKIM, and DMARC?

SPF checks sender IP, DKIM validates message integrity with cryptographic signatures, and DMARC defines policies for handling failed SPF and DKIM checks.

Does MailTester test DKIM configuration?

MailTester does not directly validate DNS records or DKIM signatures, but it identifies domains with known deliverability risks and integrates with tools that do.

How can I test DKIM before sending to real users?

Send test emails to yourself or use tools like MxToolbox and MailTester’s inbox placement testing to check signal consistency before full deployment.

Are Cc and Bcc always excluded from DKIM signatures?

Yes, according to RFC 6376. These headers are not part of the standard set and may be altered during transit, making them unsafe to sign.

What happens if I ignore the H-tag error?

Your emails may be rejected or marked as spam. Over time, your sender reputation degrades, affecting all outbound mail.

Can DKIM validation fail even if the signature is correct?

Yes, if the H-tag includes unexpected or non-standard headers, or if the signing process does not follow the canonicalization rules.