If you need to add an unsubscribe link to email, do more than place a hyperlink in the footer. A dependable implementation gives recipients a clear way to stop promotional mail, immediately records their preference, and exposes the right message headers for mailbox providers that support native one-click unsubscribe controls.

An unsubscribe mechanism is a compliance requirement for many commercial email programs, but it is also a deliverability control. When people cannot easily leave a mailing list, they are more likely to mark messages as spam. That complaint signal can hurt inbox placement for future mail, including mail recipients actually want.

This guide explains how to build unsubscribe links and one-click headers for any sending stack: a transactional email API, an SMTP relay, a self-hosted mail transfer agent, or a marketing platform. The examples use example.com and show the underlying behavior rather than assuming a particular provider dashboard or template editor.

What an unsubscribe link should do

An unsubscribe link is a recipient-specific URL in an email that lets a person stop receiving a category of non-essential messages. In most cases, the link should identify the recipient and the subscription list without asking them to log in, type an address, solve a CAPTCHA, or search through account settings.

A complete unsubscribe system has three connected parts:

A visible body link in the HTML and plain-text versions of the message.
A server-side preference and suppression system that stores the opt-out and checks it before future sends.
List-Unsubscribe headers that let supporting mailbox providers offer an unsubscribe control in their own interface.

The visible link and the email headers solve different problems. The footer link works in every client that renders the email. The headers let inbox providers such as Gmail and Yahoo offer a native unsubscribe action near the sender details. Do not treat one as a replacement for the other.

For commercial email in the United States, the FTC says messages need a clear and conspicuous explanation of how recipients can opt out of future marketing email, including an easy Internet-based method. A preference center may offer category-level choices, but it must also offer a way to stop all marketing messages from the sender. The FTC also says opt-out requests must be honored within 10 business days; operationally, your system should apply the suppression immediately.

Not every email needs the same treatment. A password-reset email, login code, payment receipt, critical service notice, or security alert is usually transactional or operational rather than promotional. Do not attach a marketing-list unsubscribe action to a password reset merely because both messages use the same infrastructure. Instead, maintain clear message classifications and subscription scopes.

Decide which messages need an unsubscribe option

Before adding code, classify each email stream. The right unsubscribe behavior depends on why the recipient is receiving the message and what they agreed to receive.

Marketing and subscribed messages

Newsletter editions, product announcements, event promotions, lifecycle campaigns, sales offers, blog digests, and feature updates normally need an unsubscribe option. These messages should contain:

A visible unsubscribe link in the body.
A plain-text unsubscribe URL or instruction.
A List-Unsubscribe header.
An HTTPS one-click unsubscribe endpoint and List-Unsubscribe-Post header when you send marketing or subscribed email at scale.

Google’s sender guidelines require senders that send more than 5,000 messages per day to Gmail accounts to support one-click unsubscribe for marketing and subscribed messages. Yahoo similarly asks senders to implement a functioning list-unsubscribe header and make the body unsubscribe link clearly visible. Even if your current volume is lower, implementing the standard from the start avoids a rushed migration later.

Transactional and operational messages

Receipts, account confirmations, password resets, two-factor authentication codes, outage notices, and legally required notices should generally continue to reach the recipient even if they opted out of a marketing newsletter. A global marketing suppression must not accidentally stop a security alert.

That does not mean transactional classification is a loophole for promotion. A receipt with a large promotional module, or an account alert sent primarily to drive a sale, may be treated as commercial depending on its primary purpose and applicable law. Keep promotional content separate from essential email whenever possible.

Preference scopes are better than one Boolean

Avoid a database design that has only unsubscribed = true. Real programs need scopes. A person might want to stop weekly product updates while continuing to receive billing notifications and a monthly account summary.

A useful model can include:

marketing_global — suppress all promotional email.
newsletter_product — suppress one newsletter or product stream.
events — suppress webinar and event invitations.
product_tips — suppress educational or onboarding campaigns.
transactional — usually not user-unsubscribable, except where the message type is optional.

A global unsubscribe link should write a global marketing suppression. A category-specific link may write a narrower suppression, but the destination page must make the global option easy to find and use.

Add a visible unsubscribe link in the email footer

The most universal implementation is an HTTPS link in the HTML body. Put it where recipients expect it: generally in the footer, in readable text, with adequate contrast and enough surrounding space to tap on mobile.

Here is a practical HTML example:

<p style="font-size: 12px; line-height: 18px; color: #5f6368;">
  You are receiving this email because you subscribed to Product Updates.
  <a href="https://unsubscribe.example.com/u/eyJhbGciOiJIUzI1NiJ9...">
    Unsubscribe from Product Updates
  </a>
  or
  <a href="https://preferences.example.com/p/eyJhbGciOiJIUzI1NiJ9...">
    manage your email preferences
  </a>.
</p>

Use descriptive anchor text. “Unsubscribe from Product Updates” tells people exactly what will happen; “Manage preferences” signals a separate destination. Avoid vague wording such as “Update,” “Settings,” or an icon with no accessible label.

The URL should be recipient-specific. A generic URL such as https://example.com/unsubscribe can work only if the page can safely identify the recipient without forcing unnecessary friction. In email, an opaque signed token is usually the most reliable approach.

Include an equivalent option in the plain-text MIME part. Some recipients use text-only clients, security gateways may inspect the text part, and a valid alternative also makes the message more accessible.

You are receiving Product Updates from Example Co.

Unsubscribe from Product Updates:
https://unsubscribe.example.com/u/eyJhbGciOiJIUzI1NiJ9...

Manage preferences:
https://preferences.example.com/p/eyJhbGciOiJIUzI1NiJ9...

Do not hide the unsubscribe link using tiny type, low-contrast colors, image-only content, a long wall of legal text, or a sequence of redirects. A link that technically exists but is difficult to find is likely to create complaints and can create compliance risk.

Use a stable, branded HTTPS hostname

A dedicated hostname such as unsubscribe.example.com is easy to understand and simple to operate. It can point at the same application as your main website, but separating the hostname makes routing, logging, security review, and monitoring clearer.

For example, if your application is behind a load balancer at 203.0.113.42, a basic DNS record might look like this:

unsubscribe.example.com.  300  IN  A      203.0.113.42
preferences.example.com.  300  IN  CNAME  app.example-host.net.

Use the record type and destination your hosting provider actually gives you. The A record example uses an RFC 5737 documentation IP address, not a real production server address. If your provider gives you a CNAME, include the final trailing dot when your DNS interface expects fully qualified names.

TLS is mandatory in practice for unsubscribe URLs. Never send recipients to an http:// endpoint that exposes their preference token in transit, browser history, proxy logs, or referrer data.

Create a secure recipient token

An unsubscribe URL needs to tell your server who is opting out and, often, which list they are leaving. It should do that without exposing the recipient’s email address or a predictable database ID.

A poor implementation looks like this:

https://example.com/unsubscribe?email=alex@example.net
https://example.com/unsubscribe?user_id=1842

The first leaks personally identifiable information into logs, analytics systems, browser history, and forwarded email. The second is easy to alter if identifiers are sequential. Neither is a good default.

Use an opaque token instead. Two common approaches are:

Random database token: Generate a cryptographically random value, store a hash of it with the recipient and subscription scope, and look it up when the request arrives.
Signed token: Encode a minimal payload such as a recipient ID, list ID, token version, and expiration, then sign it with an HMAC or private key. Verify the signature before using the claims.

A random token might produce a URL like:

https://unsubscribe.example.com/u/7d10w5aOvkLgr2bIwj1RZn8dwksD2PRr

A signed token can be shorter to manage operationally because it may not require a per-email lookup before validation. However, it should still avoid putting raw email addresses, names, or customer data in the payload. Encoded is not encrypted.

Token rules that prevent common failures

Your token design should follow these rules:

Generate tokens with a cryptographically secure random generator.
Make tokens unguessable and long enough to resist brute force.
Bind the token to a recipient and unsubscribe scope.
Version token formats so future migrations do not invalidate old messages unexpectedly.
Make processing idempotent: repeated requests produce the same end state.
Consider a long expiration or a non-expiring lookup token for body links, because recipients can click weeks after delivery.
Do not include the email address, campaign name, or internal IDs in readable query parameters.
Avoid adding the full unsubscribe URL to third-party analytics or ad-tracking systems.

An unsubscribe request is a privacy-sensitive action. Log enough information to audit it—time, scope, token identifier, delivery stream, and request result—but do not indiscriminately store the complete token in application logs.

Build the unsubscribe endpoint correctly

The endpoint must support two related but distinct flows: a browser visit from the visible footer link and a programmatic POST request from a mailbox provider using one-click unsubscribe.

Browser GET: show a confirmation or preference page

A recipient who clicks the footer link in their email client normally opens a browser with an HTTP GET request. A GET request should not silently unsubscribe the user because email security scanners, link previewers, and privacy tools may fetch links automatically.

A sensible browser flow is:

Receive GET /u/{token}.
Validate the token without changing subscription state.
Display a simple page naming the subscription category.
Let the person choose “Unsubscribe” or “Manage preferences.”
Process the actual browser form submission as POST.
Display a confirmation page after success.

For a global marketing link, the confirmation control should be clear:

<form action="/u/7d10w5aOvkLgr2bIwj1RZn8dwksD2PRr" method="post">
  <button type="submit">Unsubscribe me from marketing email</button>
</form>

You can show optional feedback after the unsubscribe decision, but do not require a survey before completing it. If you offer a preference center, make the global stop-all-marketing option equally clear.

One-click POST: unsubscribe with no additional user action

RFC 8058 defines the one-click mechanism used with the List-Unsubscribe-Post header. When an eligible mailbox provider presents its own unsubscribe action and the recipient confirms it in that interface, the provider sends a POST request to the HTTPS URL in your List-Unsubscribe header.

That endpoint must complete the requested opt-out without requiring a browser session, password, CSRF token, CAPTCHA, JavaScript, cookie consent prompt, redirect chain, or another confirmation page. It is a machine-to-machine request, not a web form visit.

A representative request looks like this:

POST /u/7d10w5aOvkLgr2bIwj1RZn8dwksD2PRr HTTP/1.1
Host: unsubscribe.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26

List-Unsubscribe=One-Click

Your handler should validate the token, apply the appropriate suppression, record the event, and return success quickly. A 200 OK response with a minimal body is a safe choice. 204 No Content is also a successful HTTP response, but a simple 200 OK is easier to inspect during testing.

HTTP/1.1 200 OK
Content-Type: text/plain; charset=utf-8
Cache-Control: no-store

Unsubscribed

For a valid token that was already processed, return a successful response too. Idempotency matters because a mailbox provider or network intermediary can retry a request. Do not return an error simply because the recipient is already suppressed.

Handle errors deliberately

Use ordinary HTTP semantics for situations that truly require them:

200 OK — request processed successfully, including an already-suppressed recipient.
400 Bad Request — malformed form body or missing expected field.
403 Forbidden — token signature is invalid or request is not authorized.
404 Not Found or 410 Gone — token is unknown or permanently expired; use carefully because revealing token validity can aid probing.
405 Method Not Allowed — unsupported method, such as PUT.
429 Too Many Requests — abusive request rate; avoid rate limits so aggressive that legitimate mailbox-provider requests fail.
500, 502, or 503 — genuine temporary server failures; alert on these because failed one-click requests can become a deliverability problem.

Do not redirect a one-click request to a login page or a general marketing page. A 302 Found response is not a successful unsubscribe. The endpoint must perform the suppression itself.

Add List-Unsubscribe and one-click headers

The visible footer link is essential, but it does not by itself implement mailbox-provider one-click unsubscribe. For that, add standards-based headers to each applicable message.

RFC 2369 defines the List-Unsubscribe header. It contains one or more angle-bracketed URLs that describe how to leave a list. RFC 8058 adds List-Unsubscribe-Post, which signals that the HTTPS URL supports the standardized one-click POST flow.

Use this header pair for marketing or subscribed email:

List-Unsubscribe: <https://unsubscribe.example.com/u/7d10w5aOvkLgr2bIwj1RZn8dwksD2PRr>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The HTTPS URL must be enclosed in angle brackets. Do not put spaces inside the brackets. The List-Unsubscribe-Post value is exactly List-Unsubscribe=One-Click.

You may include a mailto: fallback as an additional option in the List-Unsubscribe header:

List-Unsubscribe: <https://unsubscribe.example.com/u/7d10w5aOvkLgr2bIwj1RZn8dwksD2PRr>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The HTTPS endpoint is the important component for modern one-click behavior. A mailto: method can be useful as a fallback, but it creates an inbound-email workflow that must be monitored and processed reliably. It does not replace a compliant one-click HTTPS POST endpoint for senders subject to mailbox-provider one-click requirements.

Sign the headers with DKIM

RFC 8058 requires the relevant unsubscribe headers to be covered by a valid DKIM signature. This matters because the headers instruct a receiving system to change a recipient’s subscription status; they should not be modifiable in transit.

If you manage DKIM yourself, ensure the DKIM h= list includes both header names:

h=from:to:subject:date:message-id:list-unsubscribe:list-unsubscribe-post;

The exact full DKIM signature will be generated by your mail system. Do not manually assemble it. If an email provider signs messages for you, confirm that custom List-Unsubscribe headers are preserved and included in the signing process.

When a REST API allows arbitrary message headers, the payload conceptually resembles this:

{
  "from": "Example Co <news@example.com>",
  "to": ["recipient@example.net"],
  "subject": "Your weekly product update",
  "html": "<p>...</p>",
  "text": "...",
  "headers": {
    "List-Unsubscribe": "<https://unsubscribe.example.com/u/7d10w5aOvkLgr2bIwj1RZn8dwksD2PRr>",
    "List-Unsubscribe-Post": "List-Unsubscribe=One-Click"
  }
}

This is illustrative JSON, not a universal provider schema. API field names vary. With SMTP, the headers are inserted into the RFC 5322 message header block before the blank line that separates headers from the body. Check your provider’s email API setup reference or SMTP documentation for its supported custom-header mechanism and whether it preserves headers through delivery.

Connect unsubscribes to your sending pipeline

Adding a link is only half the work. Your sending application must check the resulting suppression before every campaign or automated marketing send.

A dependable send path works like this:

Resolve the recipient’s current suppression state and consent status.
Determine the message classification and subscription scope.
Stop the send if a global marketing suppression applies.
Stop the send if the recipient opted out of the narrower scope.
Generate recipient-specific body and header URLs only after the message is approved to send.
Send through your REST API or SMTP relay.
Store the provider message identifier, campaign identifier, subscription scope, and token version for troubleshooting.

Do not depend on a campaign platform’s list removal alone if other systems can send from the same brand. A marketing opt-out needs to reach every sender: your CRM, product notification service, customer-success tool, event platform, and any internal application that sends promotional email.

Keep a suppression ledger

Store unsubscribe records as durable events rather than only overwriting a single Boolean. A simple table might include:

suppression_id
recipient_id
email_normalized
scope
status
source
requested_at
processed_at
message_id
token_version
ip_hash

source might be footer_link, list_unsubscribe_post, preference_center, support_request, or complaint_feedback_loop. An event history helps support teams answer “Why did this person stop receiving mail?” and helps engineering identify whether a provider-triggered one-click path is working.

Email addresses should be normalized consistently before lookup. At minimum, trim accidental whitespace and normalize the domain portion according to your system’s rules. Do not apply aggressive provider-specific transformations, such as removing dots from all Gmail addresses, unless you fully understand the implications for your audience and identity model.

Do not send a marketing confirmation email

After a person opts out, display a browser confirmation page if appropriate, but do not send a new promotional “You have been unsubscribed” email. That message can itself violate the person’s preference or create an unnecessary complaint. If there is a genuine account-level reason to confirm a change, keep it strictly operational and consider whether it is needed at all.

Authenticate the sending domain and protect alignment

Unsubscribe controls work best as part of a healthy sending program. Mailbox providers evaluate authentication, complaint rates, content, engagement, and infrastructure—not just the presence of a footer link.

For bulk senders to Gmail, Google’s guidelines call for SPF, DKIM, and DMARC, as well as TLS and valid forward and reverse DNS for sending infrastructure. Yahoo’s sender guidance also emphasizes list-unsubscribe support, visible body links, authentication, and low complaint rates.

Example SPF, DKIM, and DMARC records

Your exact DNS records depend on your sending provider. Do not copy an include: value unless it belongs to the service that actually sends mail for your domain. These are syntax examples only.

example.com.  3600  IN  TXT  "v=spf1 include:spf.email-provider.example -all"

s1._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s; pct=100"

SPF authorizes sending infrastructure for the envelope sender domain. DKIM cryptographically signs selected message headers and body content. DMARC checks whether SPF or DKIM passes with alignment to the visible From: domain. The unsubscribe hostname does not need to be the same as the From: domain, but it should be recognizable, secured with TLS, and controlled by your organization.

Use MXToolbox, dig, nslookup, or your DNS provider’s record inspector to verify published records. For example:

dig TXT example.com +short
dig TXT s1._domainkey.example.com +short
dig TXT _dmarc.example.com +short

Do not confuse DNS authentication records with unsubscribe headers. SPF, DKIM, and DMARC live in DNS. List-Unsubscribe and List-Unsubscribe-Post live inside each email message.

Test the full flow before a campaign

Testing only the footer link in a browser is not enough. You need to test the rendered message, raw headers, one-click endpoint, data writes, suppression enforcement, and the next attempted send.

Message-level tests

Send a test message to accounts you control at several mailbox providers. In the received message, use “show original,” “view source,” or the client’s equivalent and verify:

The HTML footer contains the correct recipient-specific link.
The plain-text part has an accessible unsubscribe option.
List-Unsubscribe contains a valid HTTPS URL inside angle brackets.
List-Unsubscribe-Post is present and exactly formatted.
The DKIM signature passes and includes the unsubscribe headers where your implementation controls signing.
The From domain, DKIM domain, and return-path configuration match your authentication plan.

Mail-tester.com can be useful for inspecting message structure, spam indicators, and authentication signals in a controlled test. It is not a substitute for production monitoring, but it can quickly expose malformed headers or missing text parts.

Endpoint tests

Test the one-click handler with curl. Use a non-production test recipient or a disposable subscription scope so you do not accidentally suppress a real customer.

curl -i -X POST \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data "List-Unsubscribe=One-Click" \
  "https://unsubscribe.example.com/u/7d10w5aOvkLgr2bIwj1RZn8dwksD2PRr"

Expected result: a fast 200 OK response and a durable suppression record. Repeat the request. It should still succeed without creating duplicate records, throwing an error, or changing the outcome.

Then attempt to enqueue another marketing message to that recipient and scope. The send should be rejected by your own application before it reaches the API or SMTP relay. Record that internal outcome as a suppression, not as an SMTP delivery failure.

SMTP and API delivery tests

A successful submission response does not prove inbox delivery. In SMTP, 250 2.0.0 after message acceptance generally means the receiving server accepted the message for delivery, not that a person saw it. A temporary 4xx response may be retried according to your queue policy. A permanent 5xx response should normally not be retried unchanged.

For an HTTP email API, a 202 Accepted often means the provider accepted the request for processing, while a 200 OK or 201 Created may indicate a synchronous success depending on the API. Check the provider documentation; HTTP status meanings at submission time are not the same as mailbox delivery or inbox placement.

Test failure cases too: expired token, malformed token, duplicate request, unavailable database, invalid list scope, and unexpected GET prefetch. Your monitoring should alert on elevated 5xx rates at the unsubscribe endpoint, because that can prevent compliance-critical requests from being recorded.

Avoid the unsubscribe mistakes that cause complaints

Small implementation mistakes can make a technically present unsubscribe option ineffective. The following failures appear often in production systems.

Requiring login or extra identity verification

A recipient should not need to remember a password to stop marketing email. The emailed token is already the authorization for that narrow action. If someone forwards the email, the token can be used by the recipient of the forward, so keep its permission limited to the intended subscription change and do not grant account access.

Using GET to unsubscribe automatically

Do not treat a browser GET as proof that a human wanted to opt out. Security scanners and link-preview systems fetch URLs. Reserve automatic no-interaction suppression for the RFC 8058 POST request, and ensure the posted token is tied to a header that was DKIM-signed.

Forgetting the plain-text message part

An HTML-only message can leave some recipients without a workable link. Include a clean text part with the unsubscribe URL and a simple explanation of the subscription.

Redirecting the one-click request

A one-click POST must complete at the URL advertised in the header. Do not redirect it through analytics, a consent manager, a geographic routing page, or a sign-in wall. If you need internal tracking, perform it server-side after receiving the request.

Sending from systems that do not share suppression data

The recipient clicks unsubscribe from a newsletter but still gets product campaigns from another tool. This is one of the fastest ways to produce spam complaints. Route all promotional senders through a shared suppression service or synchronize suppression events in near real time.

Treating complaint feedback as optional data

When a mailbox provider supplies complaint feedback, process it as a high-priority suppression signal. A complaint is an explicit indication that the recipient does not want the mail. Continuing to send can damage reputation quickly.

Letting links expire too soon

Messages can sit in an inbox for months. A short-lived link may be appropriate for a sensitive account action, but marketing unsubscribe links should remain useful for a reasonable period. If a token expires, offer a low-friction fallback that can identify the recipient safely without forcing a login.

Monitor unsubscribe health and deliverability

An unsubscribe system is not “set and forget.” Monitor it as an operational service with availability, correctness, and business metrics.

Track at least these measurements:

Footer-link clicks and successful opt-outs.
One-click POST requests and successful responses.
Endpoint latency, 4xx rates, and 5xx rates.
Suppression checks that prevent sends.
Duplicate or already-suppressed requests.
Spam-complaint rate by stream, campaign, and sending domain.
Unsubscribe rate by stream and campaign.
Delivery, deferral, bounce, and inbox-placement trends after a campaign.

An increase in unsubscribes is not automatically bad. It can mean your link is easier to use, your segmentation is improving, or a campaign reached people who no longer want that category. The more concerning signal is a high complaint rate combined with low unsubscribe use, which can indicate that people cannot find or trust the opt-out path.

Compare streams rather than looking only at one account-wide number. A low-volume executive newsletter, a high-frequency product digest, and a re-engagement campaign have different expected unsubscribe behavior. Sudden changes should be investigated alongside audience source, send frequency, content changes, and deliverability data.

A practical implementation checklist

Use this checklist before enabling a marketing send:

Conclusion

To add an unsubscribe link to email correctly, build a complete preference system rather than a decorative footer. Put a readable, recipient-specific HTTPS link in both HTML and text content; store the resulting opt-out immediately; check suppression data before every future marketing send; and add the standards-based List-Unsubscribe and List-Unsubscribe-Post headers for mailbox-provider one-click support.

The best unsubscribe experience is simple for recipients and strict for your infrastructure. People should be able to leave a list in seconds. Your application should make it impossible for an opted-out recipient to be added back to the same marketing stream by a different campaign tool, SMTP sender, or API integration.

FAQ

Does every email need an unsubscribe link?

No. Marketing and subscribed messages need a clear opt-out path. Essential transactional messages such as password resets, receipts, and security alerts generally should not be suppressed by a marketing unsubscribe request. Keep those streams separate and avoid disguising promotional messages as transactional mail.

Is a footer link enough for one-click unsubscribe?

No. A visible footer link is necessary, but it is different from mailbox-provider one-click unsubscribe. For the standardized one-click flow, include List-Unsubscribe with an HTTPS URL and List-Unsubscribe-Post: List-Unsubscribe=One-Click, then accept the corresponding POST request without further interaction.

Should an unsubscribe link use GET or POST?

Use GET to show a browser confirmation or preference page. Use POST to change subscription state. This protects recipients from automated link scanners that may fetch URLs. The RFC 8058 one-click endpoint is also POST-based.

Can I include a preference center instead of an unsubscribe link?

You can offer a preference center, and it is useful for category-level choices. However, marketing email should still make a complete opt-out easy and obvious. Do not make recipients navigate multiple pages, log in, or complete a survey before they can stop all promotional messages.

How quickly should I honor an unsubscribe request?

Apply the suppression immediately in your sending systems. The U.S. CAN-SPAM framework allows up to 10 business days to honor an opt-out request, while Yahoo’s sender guidance says to honor unsubscribes within two days. Immediate processing is safer for compliance, recipient experience, and deliverability.

How to Add an Unsubscribe Link to Email (Code + Headers)