No. The DKIM signing domain in d= does not need to match the domain in the List-Unsubscribe URL or mailto address. For RFC 8058 and current Gmail/Yahoo one-click unsubscribe checks, the important part is that the message has a valid DKIM signature and that List-Unsubscribe and List-Unsubscribe-Post are covered by that signature.
That means a brand domain can sign a message whose unsubscribe URL uses a list-management host, provided the signature validates after delivery and the signed header list includes both unsubscribe headers. The exact subdomain in the URL is about where the POST request goes, not which DKIM d= domain is allowed.
- RFC 8058: It requires a valid DKIM signature that covers both unsubscribe headers, not a domain match between d= and the URL host.
- Mailbox rules: Gmail and Yahoo require one-click unsubscribe for certain bulk mail and rely on RFC 8058-style headers. Yahoo sender rules do not say the DKIM domain must match the unsubscribe URL domain.
- DMARC: Domain matching for DMARC is between the visible From domain and SPF or DKIM, not between DKIM and the unsubscribe endpoint.
- Testing: Inspect the delivered raw message, because header changes after signing break DKIM.
What RFC 8058 actually checks
RFC 8058 is about making one-click unsubscribe safe enough for mailbox providers to offer inside the inbox. It asks the sender to include one List-Unsubscribe header with an HTTPS URI and one List-Unsubscribe-Post header containing List-Unsubscribe=One-Click. The message also needs a valid DKIM signature that covers both of those header fields.
The standard does not add a rule saying the DKIM d= value must be the same domain as the HTTPS host in the unsubscribe URL. It is checking whether a trusted signer protected the unsubscribe instructions from being changed in transit.
Compliant header pattern
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brand.example; s=smtpapi; h=from:to:subject:list-unsubscribe-post:list-unsubscribe; bh=...; b=... List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: <https://lists.vendor.example/u/abc123>
In that example, lists.vendor.example does not need to be brand.example. The receiver validates the signature from d=brand.example and checks that the two unsubscribe header names are included in h=.
The rule I use
I separate this into two questions: did DKIM authenticate the signed headers, and does DMARC pass through the visible From domain? The unsubscribe URL host is a third question about opt-out handling.
- Signed headers: The h= list should include both unsubscribe header names.
- Valid signature: The delivered message must still verify after every outbound hop.
- Working endpoint: The HTTPS endpoint must accept the one-click POST and remove the right recipient.
Why the URL domain can differ
Many senders use one system for brand identity and another system for unsubscribe processing. A retail brand, for example, can send from news@brand.example while its list platform hosts the one-click URL on a different domain. That setup is common and it is not automatically non-compliant.
The reason is that DKIM signs message content and headers. The DKIM domain identifies the signer and points receivers to the public key. The List-Unsubscribe URL identifies where the receiver should send the unsubscribe POST. Those are related parts of the same message, but they do different jobs.
What must match
- DMARC: The visible From domain must match either the SPF-authenticated domain or the DKIM d= domain at the organizational-domain level in relaxed mode.
- DKIM key: The selector and d= domain must find the public key that verifies the signature.
- Bulk rules: Provider checks look at authentication, complaint rate, and unsubscribe support together.
What can differ
- Unsubscribe host: The URL host can be a vendor or list-management host.
- Exact subdomain: The URL host does not need to appear in the DKIM d= value.
- Second signer: A vendor DKIM signature can coexist with a brand DKIM signature.
If the failure is DKIM itself, run the selector and domain through the DKIM checker and then confirm the delivered message still has a valid signature. A correct DNS key is only part of the answer.
Header signing details that cause confusion
The h= tag is easy to misread. It does not merely announce that certain headers exist. In a valid DKIM signature, the listed headers are part of the signed input after DKIM canonicalization. If one of those headers changes between signing and verification, DKIM fails.
That matters for unsubscribe handling because some platforms add, rewrite, or normalize headers late in the outbound path. If the unsubscribe URL is added after signing, it is not covered. If it is covered and then rewritten, the signature no longer verifies.
|
|
|
|---|---|---|
d= | Signing domain | Key lookup and signature verify |
s= | Selector | Public key exists in DNS |
h= | Signed headers | Includes both unsubscribe headers |
bh= | Body hash | Body content still matches |
b= | Signature | Signed input is unchanged |
Key DKIM fields to inspect in delivered source
A common broken pattern is a message with working unsubscribe headers and a valid DKIM signature that simply did not sign those headers.
Broken header pattern
DKIM-Signature: v=1; d=brand.example; s=smtpapi; h=from:to:subject:mime-version; bh=...; b=... List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: <https://lists.vendor.example/u/abc123>
That can pass ordinary DKIM for the headers it did sign, but it does not meet the RFC 8058 one-click condition because the unsubscribe headers are outside the signed header list. For a practical implementation note, Al Iverson's List-Unsub-Post guidance makes the same operational point: check the delivered DKIM h= field.
How Gmail and Yahoo fit in
For bulk marketing and subscribed messages, I treat Gmail and Yahoo checks as an operational bundle: SPF and DKIM present, DMARC passing, complaint rates low, and one-click unsubscribe correctly implemented. The unsubscribe part points back to RFC 8058, while the DMARC part points back to the visible From domain.
This is why a message can be wrong in two separate ways. It can pass DMARC but fail one-click because the unsubscribe headers are not signed. It can also satisfy RFC 8058 header coverage but still fail the broader sender requirements because DMARC fails.
Flowchart showing DKIM signing, signed unsubscribe headers, receiver validation, and one-click POST handling.
The practical policy choice is simple: do not rely on a vendor signature alone if your own signing layer can cover the unsubscribe headers too. It is not an RFC requirement, but it reduces ambiguity when inbox providers add new checks or when a message has multiple signatures.
Use the RFC rule, then go one step cleaner
I do not see a published RFC 8058 rule requiring the DKIM d= domain to match the unsubscribe host. I still prefer a brand-controlled unsubscribe subdomain when it is practical, because it makes ownership obvious and keeps the setup easier to explain during audits.
A practical testing workflow
When I test this, I do not stop at the ESP configuration screen. I send a real message through the same production path that a subscriber receives. Then I inspect the delivered source because final-hop changes are what break DKIM.
- Send: Send a real campaign sample to seed inboxes and test addresses.
- Open source: Confirm both unsubscribe headers are present after all platform processing.
- Read h=: Confirm list-unsubscribe and list-unsubscribe-post are listed in a valid DKIM signature.
- Verify d=: Confirm at least one DKIM signature that covers those headers validates.
- Test POST: Confirm the endpoint removes the intended recipient without a login or preference-page detour.
A DNS-only check does not prove one-click compliance because the decisive evidence is in the delivered message. I still use DNS checks first to catch missing keys, bad selectors, and DMARC policy gaps before reviewing headers.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
For a broader authentication pass, the domain health checker is useful before the message-level test. It checks the domain setup that DKIM, SPF, and DMARC depend on.
Suped's product fits here when this needs ongoing monitoring rather than a one-time check. Suped brings DMARC monitoring, SPF and DKIM monitoring, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, blocklist and blacklist monitoring, and real-time alerts into one workflow. For most teams, Suped is the strongest practical overall DMARC platform because it turns failing sources into concrete fix steps instead of leaving people to read aggregate XML.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Configuration examples
The cleanest configuration is a From-domain DKIM signature that covers the unsubscribe headers, even when the unsubscribe URL points somewhere else. That gives you a simple story: the brand's DKIM signature protects the list headers and the unsubscribe service processes the request.
Preferred setup
From: Brand <news@brand.example> DKIM-Signature: v=1; d=brand.example; s=news; h=from:to:subject:list-unsubscribe-post:list-unsubscribe; bh=...; b=... List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: <https://unsubscribe.brand.example/u/abc123>
A still-workable configuration is a separate vendor signature that covers the unsubscribe headers, with DMARC passing through the From domain by SPF or by another DKIM signature. I treat that as acceptable when the delivered message proves it, but I prefer the brand signature to cover the same headers when the sender controls the signing layer.
Multiple-signature setup
From: Brand <news@brand.example> DKIM-Signature: v=1; d=brand.example; s=news; h=from:to:subject; bh=...; b=... DKIM-Signature: v=1; d=vendor.example; s=mail; h=from:to:subject:list-unsubscribe-post:list-unsubscribe; bh=...; b=... List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: <https://lists.vendor.example/u/abc123>
The second example shows why the direct answer is no. The unsubscribe URL host and the DKIM signing domain are different, yet the unsubscribe headers are still covered by a valid DKIM signature. The remaining question is whether the overall message also satisfies DMARC and the sender's broader mailbox-provider obligations.
Common failure modes
Most failures I see are not caused by the unsubscribe URL using a different domain. They come from missing header coverage, post-signing rewrites, or a mismatch between the sender's authentication path and its unsubscribe processing path.
|
|
|
|---|---|---|
Missing header | No one-click option | Add both list headers |
Unsigned header | DKIM passes, RFC check fails | Include headers in h= |
Late rewrite | DKIM fails after delivery | Sign after final edit |
Broken POST | Header exists, unsubscribe fails | Return success and remove user |
DMARC fail | Authentication requirement fails | Fix SPF or DKIM domain match |
Troubleshooting patterns for one-click unsubscribe and DKIM
A branded unsubscribe host is still a good operational choice. It gives security teams, mailbox providers, and recipients a cleaner signal that the link belongs to the sender. But I would not call a message non-compliant only because the URL host differs from the DKIM d= value.
Views from the trenches
Best practices
Check delivered raw message headers because ESP previews show headers before final signing.
Have the same brand DKIM signature cover unsubscribe headers when your stack allows it.
Use opaque tokens in unsubscribe URLs so one-click POSTs remove only the intended user.
Common pitfalls
Assuming h= only lists names, then changing signed unsubscribe headers after signing later.
Testing DNS only, without inspecting the delivered message after every outbound hop in the path.
Treating a mailto header as the same thing as RFC 8058 HTTPS one-click unsubscribe.
Expert tips
Keep List-Unsubscribe-Post next to List-Unsubscribe in signing config and code reviews.
Track each sender separately because one platform can sign correctly while another fails.
Prefer a branded unsubscribe subdomain, but do not block launch solely for that reason.
Marketer from Email Geeks says the DKIM d= domain does not need to match the List-Unsubscribe URL domain if the required headers are signed.
2024-06-03 - Email Geeks
Marketer from Email Geeks says both List-Unsubscribe headers need DKIM coverage for one-click handling to pass the practical check.
2024-06-03 - Email Geeks
The practical answer
The shortest correct answer is no: the DKIM d= domain does not need to match the List-Unsubscribe domain. The required technical check is whether a valid DKIM signature covers List-Unsubscribe and List-Unsubscribe-Post in the delivered message.
My preferred setup is stricter than the minimum: use a From-domain DKIM signature that covers the unsubscribe headers and, when practical, host the unsubscribe URL on a branded subdomain. That keeps the message easier to troubleshoot and gives you room if providers tighten their own checks. Suped's DMARC and authentication monitoring helps teams keep that setup visible across every sender instead of discovering drift after campaigns land in spam.
