An unsubscribe link in the message body, a List-Unsubscribe header and the one-click mechanism are related but different features. A diagnostic should identify which mechanism the sender actually emitted and whether the required signed headers are present. Merely seeing the word unsubscribe in the source does not establish a working one-click implementation.
Read the two fields together
RFC 2369 defines List-Unsubscribe as a list command field containing URLs for leaving a list. It can describe methods such as mailto or HTTPS. RFC 8058 adds List-Unsubscribe-Post for the one-click mechanism. The latter uses the value List-Unsubscribe=One-Click, with an HTTPS URI in List-Unsubscribe. A mailto option alone is not the RFC 8058 HTTPS mechanism. RFC 2369 section 3.2, RFC 8058 section 3.
The one-click receiver sends an HTTPS POST with the specified unsubscribe value. A routine GET to inspect a URL must not itself perform the RFC 8058 unsubscribe action. This distinction matters because link scanners may fetch URLs without a person intending to leave a list. Do not turn diagnostic inspection into an unauthorized subscription change.
Check the signing requirement
RFC 8058 requires a valid DKIM signature covering both List-Unsubscribe and List-Unsubscribe-Post. Finding the two field names in a signature's h= list is a useful structural check, but it does not prove that the signature verifies.
Preserve the original signed message for an actual verification. Multiple signatures and repeated header fields require careful selection; a naive substring search can mistake an unrelated signature for the one that satisfies the requirement. Keep signing coverage, cryptographic validation and endpoint behavior as separate checks.
Use a controlled example
Consider a hypothetical message with the correct two header values. Its only valid signature covers From and Subject but not the unsubscribe fields. A second signature lists both fields but fails verification. This message has both a DKIM pass and apparent coverage somewhere in its source, yet neither signature satisfies the combined RFC 8058 requirement.
The next step is to identify or create, through an approved sender change, a signature that both verifies and covers the two fields. No signature was verified or subscription changed for this teaching example. Even a subsequently verified covering signature would leave HTTPS endpoint behavior and next-send suppression untested.
For an authorized end-to-end test, use a dedicated test subscription and the sender's supported test environment. Verify a valid signature, send the intended POST and confirm the test subscription's state through the service's own evidence. RFC 8058 prohibits HTTPS redirects and excludes cookies, HTTP authorization and other request context from the POST. The receiver must obtain user consent before posting. Record any redirect or login requirement as a defect instead of clicking through; the endpoint must complete the unsubscribe without additional interaction.
Protect subscriber identifiers
Unsubscribe URLs often contain a recipient-specific token. Treat the full URL as potentially capable of changing that person's subscription. Redact or replace the token in a general diagnostic copy, preserve the untouched message privately, and do not paste the live URL into public tickets or automated fetchers.
Close with an explicit checklist: fields present, correct syntax, covering signature verified, and authorized endpoint test completed or not performed. Provider bulk-sender eligibility and unsubscribe interface display are separate product questions. A standards-level header check does not guarantee that any mailbox provider will display a particular button.
Report each layer independently
If headers are present but signature validation is unavailable, report a structural finding only. If verification passes but no authorized endpoint test occurred, leave behavior untested. Record the exact final sample and the evidence needed for the next layer.