[ Deliverability & sender rules ]

Unsubscribe handling and DKIM coverage of the required headers

Ensure a valid DKIM signature covers both unsubscribe fields, then verify that downstream processing preserves the signed operation.

By the EmailAuth research team · 3 min read

[ Key points ]

  • Ensure a valid DKIM signature covers both unsubscribe fields, then verify that downstream processing preserves the signed operation.
  • The same valid DKIM signature must cover both unsubscribe fields; do not combine one signature’s pass with another’s coverage.
On this page

A message can have a valid DKIM signature while its unsubscribe fields are unsigned. That is a meaningful gap: a receiver verifying the message has not necessarily verified the advertised opt-out action. Inspect the signature's coverage, not only a generic DKIM pass label.

Locate the signature that protects the operation

RFC 8058 requires at least one valid DKIM signature covering List-Unsubscribe and List-Unsubscribe-Post. Both fields must appear in the h= tag of that valid signature. A missing required signature is a reason for the receiver not to offer one-click unsubscribe under the specification. RFC 8058 section 4.

A message may carry multiple signatures. Do not combine the validity of one with the header coverage of another and call the pair sufficient. Identify a single valid signature that covers the required fields, then retain its signer, selector and verification result. This is separate from checking which signature contributes to DMARC alignment.

Place the headers before the relevant signing step

Map the message construction pipeline: application template, list processing, gateway transformations, signer and final outbound route. If a service adds the unsubscribe fields after signing, an earlier signature may remain valid without covering them. The fix is to place the fields before the appropriate signature or ensure a later valid signature covers them.

Read the final emitted message. RFC 6376 defines the h= list and header selection rules, including how repeated field names are handled. A string search for “list-unsubscribe” anywhere in the message is not a coverage test. Duplicate fields and transformations require careful inspection of the actual signature input. RFC 6376 sections 3.5 and 5.4.

Distinguish signed and unsigned changes

Imagine a controlled test message whose otherwise valid signature covers both unsubscribe fields. Changing the signed URI to a different value changes the signed input; under normal DKIM verification, the original signature no longer validates that altered input. By contrast, a signature that omits both fields can remain valid after those unsigned values change. This explains why a generic pass cannot authenticate every field.

These are protocol-based expectations, not an executed cryptographic fixture. An actual authorized mutation test needs exact original bytes, the selected signature and the correct verification key. An injected test key demonstrates only that test’s cryptographic relationship, not public DNS provenance or the historical receiving result. Preserve the original and mutate a separate copy.

Check the whole signed path

After fixing coverage, resend an authorized test message through the intended route and verify at the receiving side. Link rewriting, gateway edits or a later list processor can change a covered field. Preserve the pre-transformation and final samples when possible so the owner can locate the first stage where verification diverges.

Avoid solving the problem by simply removing the fields from h=. That can make the signature easier to preserve while leaving the RFC 8058 requirement unmet. If a gateway must transform the action, coordinate the final signing boundary and ensure the transformed URI still maps to the correct recipient and list.

Complete the operational check

Signature coverage authenticates the advertised fields; it does not prove the endpoint performs the requested suppression. Use a controlled subscription to test the POST and downstream next-send exclusion separately. Conversely, a working endpoint does not repair missing signature coverage.

The closure record should identify the valid covering signature, exact final message, endpoint scope and observed suppression result. Keep provider UI display as a separate observation rather than a promised consequence of correct signing.

Retain a signature-specific closure record

Record the final message, signer, selector, the two covered fields and the verification outcome for that particular signature. Record endpoint and suppression results separately. If a later gateway mutates the fields, repair the signing boundary rather than dropping required coverage.

[ Takeaway ]

Ensure a valid DKIM signature covers both unsubscribe fields, then verify that downstream processing preserves the signed operation.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Verify the final covering signature

Pipeline order determines what is protected.

Next steps

  1. Inspect h= and validity together.
  2. Trace downstream mutations.
  3. Retest through the intended route.

CISO / SecOps

Preserve action integrity

An unsigned opt-out target can change without invalidating unrelated coverage.

Next steps

  1. Review duplicate headers.
  2. Protect production keys.
  3. Use isolated mutation fixtures.

Founder / Non-technical

Require evidence beyond a pass badge

A valid signature can omit the important fields.

Next steps

  1. Ask for coverage evidence.
  2. Assign gateway ownership.
  3. Separate signing and suppression acceptance.

[ FAQs ]

Frequently asked questions

Does DKIM pass prove unsubscribe headers are covered?

No. Inspect the h= list of the valid signature.

Can coverage from one signature be combined with another’s validity?

No. A valid signature must itself cover both required fields.

Should the headers be added after signing?

Not unless a later valid signature covers them.

Why test a URL mutation?

It shows whether the signature actually protects the advertised unsubscribe target.

What does the mutation example predict?

Changing the covered URI changes signed input; changing an omitted field can leave an otherwise valid signature intact. These are expectations, not recorded verification results.

Would an injected test key prove public DNS authorization?

No. A test-key verification establishes only the tested cryptographic relationship, not DNS provenance or a historical receiver result.

Can removing the fields from h= solve RFC 8058 compliance?

No. It removes the required coverage even if a signature remains valid.

Does signature coverage prove suppression works?

No. Test endpoint behavior and downstream exclusion separately.

[ Sources ]

Sources

  1. RFC 8058 One-Click Unsubscribe

    Sections §3.1 · §3.2 · §4 · §5 · §6

  2. RFC 6376 DKIM

    Sections §3.5 · §5.4 · §6.1

  3. RFC 9989 DMARC

    Sections §4.4 · §5.3.5

[ Glossary ]

Glossary

Header coverage
The specific message fields included in a DKIM signature’s signed input.
h= tag
The DKIM signature tag listing signed header field names.
Signing boundary
The pipeline point after which protected message content must remain verifiable.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base