Make unsubscribe and preference journeys understandable

Begin with the reader’s intended action

A person may want fewer messages, different topics or no further marketing messages from a particular publication. Give those actions distinct meanings. A preference page can be useful, but it should not make a straightforward request to stop depend on answering a survey or finding a hidden control.

Explain the scope of each option. If several publications share a system, make clear whether an action concerns one edition or a broader set of marketing messages. That is a product-design question that needs an explicit answer from the operator, not an assumption made by the page designer.

Keep the email control and the website journey connected

The unsubscribe link in an email and the preference controls on a website can be different entry points into the same operation. Check that both resolve to the correct publication and that the recorded result is available to the sending system. A visible confirmation without an effective stop state is an operational failure.

For systems implementing one-click unsubscribe headers, RFC 8058 specifies an HTTPS POST mechanism with List-Unsubscribe and List-Unsubscribe-Post, and requirements including DKIM coverage. A footer link by itself is not an implementation of that protocol. Use your provider’s supported feature and verify the resulting message instead of improvising a public action URL.

Google’s email sender guidelines are one provider’s published expectations for senders. Read the current version for its scope; this guide does not restate any threshold or requirement from it.

Worked example: two editions and one clear stop

Imagine a publisher offering a general digest and an optional specialist briefing. A preference screen can identify both choices and explain what the reader currently receives. The request to stop the general digest should be recorded against that edition and should produce a result that the person can understand.

If there is also a clear option to stop all the publisher’s relevant marketing emails, label its scope. Keep unrelated service communications under their own appropriate processes instead of making a broad technical checkbox silently decide every possible relationship. The example is operational design guidance, not legal advice about a particular organisation.

Decision matrix for the invented publisher

The matrix below is a suggested workflow for an invented publisher, here called Northfield Notes, with a general digest and an optional specialist briefing. The scope of each option is a proposed product decision, written down so that the page designer is not left guessing. It does not soften the stop: once a reader chooses an option, that scope stops completely, including anything already queued.

• Stop the general digest. Proposed scope: the general digest only. Recorded against: that edition. Stops: every future issue and any automated message that belongs to it. Continues: the specialist briefing, if the reader receives it. The reader is told which edition has stopped and which, if any, continue.
• Stop the specialist briefing. Proposed scope: the briefing only. Recorded against: the briefing. Stops: briefing issues and its automated messages. Continues: the general digest. The reader is told the same three things.
• Stop all marketing from the publisher. Proposed scope: every marketing edition and promotional sequence from Northfield Notes, listed by name on the page. Continues: unrelated service communications, which follow their own process, such as a reply to a support enquiry (see the contact versus subscribe guide for keeping an enquiry separate from a subscription). The reader is told which editions are covered and that service messages are separate.
• Change topics or frequency. This is not a stop. It is recorded as a preference on the same record, and the stop options stay visible on the same page, never placed behind a survey or this choice. Frequency appears only if the publisher really offers it.
• One-click request from the email itself. Proposed scope: the edition the email belongs to, so a one-click request in a digest issue stops the digest. If the provider supports RFC 8058 headers, this request arrives by HTTPS POST rather than through a page, and the same recorded result applies. A footer URL on its own is not that mechanism; verify the provider’s supported feature on a test message.

A repeated request

Readers click twice, return to an old email or submit a preference form a second time, so the matrix needs rows for repeats. Test each of them on controlled accounts.

• Same stop requested again: no change. The page restates the result, for example that the general digest has already stopped, and does not turn anything back on or ask the reader to justify the request.
• Narrow stop, then broad stop: if the reader stops the general digest and later chooses all marketing, the broader scope applies. Both choices are recorded and the later one covers every edition.
• Broad stop, then a link from an older digest email: the contact stays stopped and the page says so. Resuming is by a fresh explicit request through the signup path, with its confirmation step if the setup has one.
• Link no longer valid: the page explains plainly that the link has expired or cannot be matched, and gives a working route to ask for a stop that does not require a survey.

The automation queue

Apply the stop to future marketing dispatches within its scope, including messages still waiting in a queue. Do not promise recall of a message already handed to a delivery service; establish what stage it reached and check the provider’s behaviour. The rows below show what the invented publisher expects when a stop arrives while items are queued. Whether a service removes queued items or checks the contact again when each is due depends on the service and setup, so each row is a requirement to verify with controlled accounts.

• A scheduled issue of the general digest, and the reader has just stopped the digest: exclude the contact before dispatch. Check the current stop state before releasing the message, rather than relying only on a list prepared earlier.
• A queued welcome step for the specialist briefing, and the reader stopped only the briefing: the step does not send, and the general digest is unaffected.
• A queued welcome step for the digest, and the reader chose all marketing: it does not send, nor does any other promotional step within that all-marketing scope.
• An automation that would start from a later event, such as choosing a topic, when the contact is stopped for that scope: it does not start, because entry reads the stop state.
• A service message already queued, such as a reply to a support enquiry: it follows its own process and is not used to carry promotion to someone who has stopped marketing.

Test that the result reaches the sending process

Use controlled accounts to exercise an email link, a preference change and any supported one-click mechanism. Check the current subscriber state and the conditions governing queued or automated messages. A report that refreshes later should not be treated as the authority for whether the next campaign may include that contact.

Review what happens when a link is followed again and when it is no longer valid. Keep recipient-specific identifiers out of public examples. Do not publish an operational unsubscribe link as a demonstration, because following or processing it could affect someone else’s subscription.

Treat stops as useful evidence

An unsubscribe is a clear change in the relationship and can also prompt an editorial review of the original promise, the relevance of recent issues and the way the person joined. It should not automatically be described as a technical defect or an invitation to send another promotional sequence.

The lifecycle guide shows where a stop belongs in the broader state map. For links belonging to a service you no longer operate, use the retired-link guide rather than taking over an old provider’s preference or subscription actions. For the sending side, the deliverability guide and the editorial calendar guide are the related pages.