SMTP vs API: Complete Developer Guide
Complete technical guide comparing SMTP vs API for sending emails. Includes code examples, performance benchmarks, and decision framework for developers.
Akash Bhadange • 11/12/2025 • engineering
Akash Bhadange • 1/27/2026 • engineering
You probably already include an unsubscribe link somewhere in your email footer. It's required by law, and every email marketing guide tells you to put one there. That's not what this article is about.
This is about the List-Unsubscribe header, a completely separate mechanism that works behind the scenes. You've seen its effect even if you didn't know what caused it: that "Unsubscribe" link Gmail shows at the top of emails, right next to the sender's name. Or the unsubscribe banner Apple Mail displays before you even scroll down. That's not coming from your footer link. That's the List-Unsubscribe header at work.
The footer link and the header serve the same purpose, but they work differently. Your footer link is visible in the email body and requires the recipient to scroll down, find it, click it, and probably go through a confirmation page. The List-Unsubscribe header is invisible metadata that email clients read and use to surface a native, one-click unsubscribe option right in their interface.
And here's the thing: since February 2024, Gmail and Yahoo require it for bulk senders. It's no longer optional.
Using AutoSend? You can skip most of this article. AutoSend automatically adds the correct List-Unsubscribe and List-Unsubscribe-Post headers to all your marketing emails, handles the one-click POST requests, and keeps your suppression list updated. But if you want to understand what's happening under the hood, keep reading.
The List-Unsubscribe header is hidden metadata included in your email's headers that tells email clients how recipients can unsubscribe from your mailing list. Recipients never see the header itself, but email clients like Gmail, Outlook, and Apple Mail read it and use the information to display their own unsubscribe buttons.
Here's what it looks like in raw email headers:
List-Unsubscribe: <mailto:[email protected]?subject=Unsubscribe>, <https://example.com/unsubscribe?id=abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickThe header was originally defined in RFC 2369 back in 1998 as part of a set of headers for mailing lists. It's been around for decades, but its importance has grown significantly as inbox providers have made it a key factor in deliverability decisions.
In February 2024, Gmail and Yahoo rolled out new sender requirements that made List-Unsubscribe mandatory for bulk senders. If you send more than 5,000 emails per day to Gmail or Yahoo addresses, you must include a working one-click unsubscribe mechanism. Fail to comply, and your emails face throttling, spam folder placement, or outright rejection.
Beyond compliance, the header affects your sender reputation in ways that aren't immediately obvious. When unsubscribing is easy, people unsubscribe. When it's hard, they hit the spam button instead. Spam complaints hurt your reputation far more than unsubscribes ever will. Including the header also signals to inbox providers that you're following best practices, which builds trust. And a clean list of engaged subscribers beats a bloated list of people who would leave if they could figure out how.
From the recipient's perspective, a visible unsubscribe option builds trust. It says "we're not trying to trap you." Ironically, making it easy to leave often makes people more likely to stay.
The List-Unsubscribe header supports two methods, and you can (and should) include both.
The first is the mailto method, which looks like this:
List-Unsubscribe: <mailto:[email protected]?subject=Unsubscribe&body=user123>This creates an email-based unsubscribe. When triggered, the recipient's email client sends an email to your specified address. Your system then processes that incoming email and removes the subscriber. It's simple to implement and works even if your web server is down, but it requires you to monitor an inbox and process incoming emails, which can be slower and clunkier than the alternative.
The second is the HTTPS method:
List-Unsubscribe: <https://yourdomain.com/unsubscribe?token=abc123>This provides a URL endpoint that handles the unsubscribe. The email client makes an HTTP request to this URL to process the unsubscription. It's faster, easier to implement in modern systems, and can include confirmation pages or preference centers. The downside is that it requires your web server to be available.
Most email experts recommend including both methods in a single header:
List-Unsubscribe: <mailto:[email protected]>, <https://yourdomain.com/unsub?id=token>This ensures compatibility across all email clients. The client will choose whichever method it prefers.
Here's where things get more specific. Gmail and Yahoo's 2024 requirements don't just want any unsubscribe mechanism. They want one-click unsubscribe, which requires an additional header:
List-Unsubscribe-Post: List-Unsubscribe=One-ClickWhen this header is present alongside an HTTPS List-Unsubscribe URL, it tells email clients that your endpoint supports RFC 8058's one-click unsubscribe protocol.
The way it works is straightforward. The email client sees both headers. When the user clicks "Unsubscribe," the client sends a POST request to your URL. The POST body contains List-Unsubscribe=One-Click. Your server processes the request and removes the subscriber. No confirmation page, no extra clicks, no friction.
Your HTTPS endpoint needs to accept POST requests, look for the List-Unsubscribe=One-Click parameter in the request body, process the unsubscription without requiring user interaction, and return an HTTP 200 status code on success. It should also handle the request idempotently, meaning multiple clicks shouldn't cause errors.
Here's a basic example in Node.js:
app.post('/unsubscribe', (req, res) => {
const token = req.query.token;
const isOneClick = req.body === 'List-Unsubscribe=One-Click';
if (!token) {
return res.status(400).send('Missing token');
}
const subscriber = validateUnsubscribeToken(token);
if (!subscriber) {
return res.status(400).send('Invalid token');
}
unsubscribeUser(subscriber.email);
if (isOneClick) {
return res.status(200).send('Unsubscribed');
}
res.render('unsubscribe-confirmation', { email: subscriber.email });
});Gmail shows an "Unsubscribe" link next to the sender's name at the top of the email. For senders meeting their requirements, clicking this triggers the one-click unsubscribe without leaving Gmail. Gmail strongly prefers the HTTPS method with List-Unsubscribe-Post. If only mailto is provided, they'll still show the option but may require additional confirmation.
Apple Mail displays an "Unsubscribe" banner at the top of emails that include the header and supports both mailto and HTTPS methods.
Outlook shows an unsubscribe option in the email header area. Microsoft's implementation supports both methods but has historically been more reliable with mailto.
Yahoo displays an "Unsubscribe" link in the email header. Like Gmail, they now require one-click unsubscribe for bulk senders.
The unsubscribe mechanism needs to be secure to prevent abuse.
Never use plain email addresses in your unsubscribe URLs. Instead, use unique, expiring tokens like https://yourdomain.com/unsubscribe?token=a7f8b2c9d4e1f6a3. The token should be unique per subscriber (and ideally per email), cryptographically secure so it can't be guessed, and optionally expire after a reasonable period. On your backend, the token maps to the subscriber's email.
You should also implement rate limiting on your unsubscribe endpoint to prevent abuse. Something like 100 requests per IP per 15 minutes is reasonable. And log all unsubscribe requests for compliance and debugging: timestamp, email address or token, source IP, method used, and success or failure status.
The most common mistake is requiring login to unsubscribe. Your unsubscribe process should never require the recipient to log in or create an account. This violates the spirit of easy unsubscription and may not comply with regulations like GDPR and CAN-SPAM.
Another frequent problem is unsubscribe links that don't work. It sounds obvious, but test your unsubscribe links. A broken unsubscribe link means frustrated recipients hitting the spam button instead.
Some senders also fail to actually honor the request. When someone unsubscribes, actually unsubscribe them. Immediately. Don't send "we're sorry to see you go" emails. Don't take 10 business days to process. Just stop emailing them.
One-click means one click. Don't redirect users to a preference center where they have to make choices. Process the unsubscribe immediately, then optionally show a confirmation with preference options.
And make sure your unsubscribe URL uses HTTPS, not HTTP. Email clients won't trust HTTP endpoints, and it exposes the unsubscribe token to interception.
Before going live, verify your headers are correct.
Most email clients let you view raw message headers. In Gmail, click the three dots and select "Show original." Look for the List-Unsubscribe and List-Unsubscribe-Post headers.
Tools like Mail Tester (mail-tester.com) will analyze your email headers and flag any issues with your List-Unsubscribe implementation.
Send test emails to your own Gmail, Yahoo, and Outlook accounts. Verify that the unsubscribe option appears in the UI, that clicking it triggers the correct behavior, and that the unsubscription is actually processed.
You can also test your endpoint directly with curl:
curl -X POST "https://yourdomain.com/unsubscribe?token=testtoken" \
-d "List-Unsubscribe=One-Click" \
-H "Content-Type: application/x-www-form-urlencoded"The List-Unsubscribe header helps with compliance, but it's not a complete solution.
CAN-SPAM in the United States requires a clear unsubscribe mechanism in commercial emails. The List-Unsubscribe header satisfies this, but you must still include a visible unsubscribe link in the email body. GDPR in the European Union requires easy withdrawal of consent, and one-click unsubscribe aligns well with this requirement. Canada's CASL requires an unsubscribe mechanism that's "readily performed," which the List-Unsubscribe header fits.
The important thing to remember is that you should always include a visible unsubscribe link in your email footer in addition to the header. The header enhances the experience, but the in-body link is required by most regulations.
Include List-Unsubscribe on marketing emails, newsletters, promotional campaigns, product announcements, and any bulk email where recipients signed up.
Don't include it on transactional emails like order confirmations, password resets, security alerts, and mandatory notifications. Transactional emails shouldn't have an unsubscribe option because recipients need to receive them regardless of preference. Including it on these emails can actually confuse recipients and create support issues.
The List-Unsubscribe header used to be a nice-to-have. Now it's table stakes. Gmail and Yahoo have made that clear with their 2024 requirements, and other providers are likely to follow.
Getting it right means including both mailto and HTTPS methods in List-Unsubscribe, adding List-Unsubscribe-Post for one-click support, building an endpoint that handles POST requests properly, using secure token-based URLs, actually processing unsubscribes immediately, and testing across major email clients.
It's not complicated, but there are enough details to get wrong that it trips up a lot of senders.
One last thing:
Gmail doesn't show the unsubscribe button on every email that includes the List-Unsubscribe header. It uses its own criteria to decide when to display it. Generally, your domain needs a decent sender reputation, proper authentication (SPF, DKIM, and DMARC all passing), and you need to be sending at least 5,000 emails/day to Gmail addresses to be classified as a bulk sender. New senders or those with lower volume might not see the button appear right away. Gmail also won't show it if it detects the email is transactional rather than promotional. There's no way to force it - you just need to follow best practices and give it time.
Related Articles
SMTP vs API: Complete Developer Guide
Complete technical guide comparing SMTP vs API for sending emails. Includes code examples, performance benchmarks, and decision framework for developers.
Akash Bhadange • 11/12/2025 • engineering
Why AutoSend Doesn’t Have a Free Plan
How protecting deliverability, reliability, and focus shaped our decision to not offer the free plan.
Akash Bhadange • 11/11/2025 • engineering
Avoid These 5 Mistakes While Sending Transactional Emails
Learn the common mistakes teams make when sending transactional emails and how to fix them for better deliverability, clarity, and compliance.
Akash Bhadange • 10/14/2025 • engineering
Why Gmail Says Your Emails "Appear Suspicious" (And How to Fix It)
Gmail marking your emails as suspicious? Fix DMARC strict alignment with this SPF, DKIM, and DMARC DNS configuration guide.
Akash Bhadange • 1/7/2026 • how to guide

Start sending better emails today!
Transactional emails, marketing campaigns, and everything in between. No clutter. No surprises. Just fast and reliable deliverability.