How Alias handles unsubscribe links
Most marketing email is required by law to include an unsubscribe link or email address. The two standards in play here are RFC 2369 (a List-Unsubscribe: header that points to a mailto: and/or https:// URL) and RFC 8058 (a one-click POST companion that Gmail and Outlook surface as the "Unsubscribe" button next to the sender name).
When Alias forwards an email to your real inbox, we rewrite both of those headers to point at our own proxy before the message reaches you. That extra hop matters for privacy.
Why we rewrite the link
If we forwarded the unsubscribe link unchanged, two things go wrong:
mailto:opens your real mail client and sends the unsubscribe email from your real address. The sender now has your real inbox - the very thing your alias was meant to hide.https://URLs and one-click POSTs still target the sender's domain, while theFrom:header on the forwarded message has been rewritten to your alias domain. Gmail flags that mismatch as a soft negative signal, and the email lands in Promotions or Spam more often than it should.
By rewriting the link to https://api.mxalias.com/unsubscribe/<token>, both problems disappear:
- The
mailto:flow goes through Alias instead of your client. - The one-click POST and From: domain now agree.
What happens for each method
The rewrite is type-aware. Three flavors exist; here is exactly what Alias does with each:
mailto:
Alias generates a unique token, stores the original mailto: recipient and subject, and rewrites the link. When you click it, Alias sends the unsubscribe email from your alias address to the original recipient. Your real inbox never participates. We log the result so you can see what happened.
https one-click POST (RFC 8058)
When Gmail's "Unsubscribe" button calls our proxy, we forward that POST to the sender's URL with body=List-Unsubscribe=One-Click. We never follow redirects (RFC 8058 explicitly forbids it), and we strip cookies, Authorization, and Referer. We also refuse to talk to private IPs (127/8, 10/8, 172.16/12, 192.168/16, 169.254/16, IPv6 loopback / ULA / link-local) - if a sender's URL resolves there, we return a 502.
https user-clicked link (RFC 2369)
When you actually click the link in your email client, Alias responds with 302 Found to the original URL plus Referrer-Policy: no-referrer. The browser takes over from there - you complete the sender's normal opt-out flow with all of its preference centers and downgrade options intact. Your IP reaches the sender's site (it always does for any unsubscribe link, including those from inboxes without Alias), but your real email is never sent, and the sender does not learn that the click came through Alias.
Privacy summary
| What gets exposed | Without Alias | With Alias |
|---|---|---|
Your real email when clicking mailto: | Yes | No |
| Your real email when submitting a one-click | No | No |
| Your IP when visiting an https opt-out page | Yes | Yes |
| Confirmation that you opened the email | Maybe | Maybe |
Alias does not eliminate every signal - the only way to do that is to never click the link - but it closes the most damaging gap (the mailto: real-email leak) and aligns From/DKIM with the unsubscribe domain so the message keeps landing in your normal inbox while you stay subscribed-or-not on your terms.
Frequently asked questions
Why did I see "mxalias.com" flash by before landing on the sender's unsubscribe page?
That's the https passthrough doing its job. We mark your click in our system (so you can review your unsubscribe history later), then 302 you straight to the sender's page where you complete the rest of the flow.
The page says "we sent your unsubscribe request" but I'm still getting emails.
Senders process unsubscribes asynchronously. Most stop within 10 days; some take 30. If you're still getting them after a month, click the link again - or block the sender directly in your inbox.
What if the sender's unsubscribe URL is broken?
You'll see the failure page. Click the link in the email a second time to retry; we'll attempt the dispatch again from a clean state. If the sender's server is permanently down, the 30-day retention window will eventually let you forget about it.
Does Alias keep a record of what I unsubscribed from?
Each unsubscribe token lives for 180 days, which gives you a window to look back at past requests in your dashboard. After that the row is purged.