CAN-SPAM & One-Click Unsubscribe (RFC 8058) for Outreach Email (2026)

What CAN-SPAM actually requires

The CAN-SPAM Act of 2003 — Pub. L. No. 108-187, 117 Stat. 2699, signed 16 December 2003 and effective 1 January 2004 — is codified at 15 U.S.C. §§ 7701–7713. The operative duties live in 15 U.S.C. § 7704(a), and there are five of them. None is difficult. All five are load- bearing, and a message that satisfies four is still unlawful.

Two of these trip up outreach programs more than the others. The physical postal address is not decorative and not optional — the FTC accepts a current street address, a Post Office box accurately registered with the United States Postal Service, or a private mailbox accurately registered with a commercial mail receiving agency established under USPS regulations. A company that has never published an address has no compliant way to send commercial email at all, which is a strange thing to discover on send day.

The second is what the law does not say. CAN-SPAM is an opt-out regime. It does not require consent before the first message, does not require a prior business relationship, and does not restrict the time of day you may send — that last one is a TCPA concept for phone channels, and importing it into email is a misreading rather than extra caution.

The opt-out mechanics: 10 days, 30 days, and no friction

Three separate clocks and one anti-friction rule govern the opt-out, and they are frequently conflated.

• 10 business days to stop sending. Under § 7704(a)(4) it is unlawful to send a commercial email more than 10 business days after the recipient asks you to stop. This is a deadline, not an allowance — nothing entitles you to the intervening sends.
• 30 days of mechanism uptime. Under § 7704(a)(3) the opt-out mechanism must remain capable of receiving requests for no less than 30 days after the original message was transmitted. An unsubscribe link that 404s three weeks after a campaign ends is a violation of the statute even if nobody clicks it.
• No fee, no interrogation, no maze. 16 C.F.R. § 316.5 forbids requiring the recipient to pay any fee, to provide any information other than their email address and opt-out preferences, or to take any step except sending a reply email or visiting a single Internet web page. A login-walled preference center, or a form demanding a reason, is outside the rule.

The § 316.5 sentence is the one that quietly makes RFC 8058 a natural fit rather than a burden: the law already caps the opt-out at a single web page with no additional information demanded. One-click is simply that requirement taken to its limit — zero pages and zero fields.

RFC 8058: what one-click unsubscribe actually is

One-click unsubscribe is a mail-header mechanism, specified in RFC 8058, that lets a mailbox provider render an unsubscribe control beside the sender’s name and complete the opt-out with a single HTTPS POST — without the recipient opening the message, loading a landing page, or confirming a second time.

The header itself is older than the one-click mechanism. RFC 2369 (July 1998) introduced List-Unsubscribe as a way to advertise an unsubscribe URI. That created a problem: mail software sometimes fetches URLs found in header fields, and a fetch of an unsubscribe URI is an accidental unsubscribe. Senders defended themselves by putting a confirmation page behind the link — which reintroduced the friction the header was supposed to remove.

RFC 8058— “Signaling One-Click Functionality for List Email Headers”, by J. Levine and T. Herkula, published January 2017 on the Standards Track — resolves it by distinguishing the HTTP verb. Two headers ride on the message:

List-Unsubscribe: <https://example.com/u?t=SIGNED_TOKEN>, <mailto:unsub@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The mailbox provider sees List-Unsubscribe-Post, renders a native unsubscribe control next to the sender name, and — when the user clicks it — issues an HTTP POST to the HTTPS URI with List-Unsubscribe=One-Click in the body, as application/x-www-form-urlencoded or multipart/form-data. The sender acts on it immediately, with no confirmation step.

The verb is the entire safety mechanism — and it is worth being exact about what the RFC does and does not say here, because this is where most write-ups overreach. RFC 8058 contains no rule forbidding a GET from unsubscribing. Its introduction names the problem — “anti-spam software often fetches all resources in mail header fields automatically, without any action by the user” — and § 3.1 answers it not by prohibiting anything but by defining one-click solely over POST, a verb those automated fetchers do not issue. Keeping GET inert therefore follows from the design rather than from a normative sentence, and it still matters: link scanners, security appliances, and prefetchers all issue GETs, and a GET-triggered opt-out means a corporate mail filter can silently unsubscribe an entire company. Two constraints the RFC does state normatively are routinely missed in implementations: the sender “MUST NOT return an HTTPS redirect, since redirected POST actions have historically not worked reliably”, and the URI should contain an opaque identifier or another hard-to-forge component identifying the list and recipient — otherwise the endpoint is an enumeration surface for unsubscribing addresses you do not own.

Why Gmail and Yahoo made a 2017 RFC mandatory in 2024

No statute requires one-click unsubscribe. The mailbox providers do, and they reach further than the FTC does, because they can simply stop delivering your mail.

Since 1 February 2024, Google has required senders of more than 5,000 messages per day to Gmail accounts to meet a defined set of sender requirements. Google’s guidelines state that “Marketing messages and subscribed messages must support one-click unsubscribe, and include a clearly visible unsubscribe link in the message body”, and point to RFC 2369 and RFC 8058 for the header syntax. Senders who already had an unsubscribe link were given until 1 June 2024 to implement one-click. Yahoo announced matching requirements on the same timeline. The rest of the bulk-sender bar:

1. 1.Authenticate with SPF, DKIM, and DMARC. Bulk senders need all three; DMARC needs a policy of at least p=none.
2. 2.Keep spam rates below 0.30%. Google’s requirement is to “keep spam rates reported in Postmaster Tools below 0.30%”. That is a rate you cannot see without enrolling in Postmaster Tools, which makes enrollment a de facto requirement of its own.
3. 3.Marketing mail only. One-click is required for marketing and promotional messages. Transactional mail — password resets, reservation confirmations, form-submission receipts — is excluded.

One number is worth stating carefully, because it is widely misquoted. Google’s published sender requirements do not set a deadline for processing an unsubscribe; its sender-guidelines FAQ recommendsfulfilling requests within 48 hours. So the binding legal deadline remains CAN-SPAM’s 10 business days, while the practical deliverability expectation is roughly two days. Both are ceilings. Neither is a reason to wait: the cheapest place to enforce an opt-out is a suppression check immediately before the next send, which makes both clocks moot.

What it costs

CAN-SPAM has no private right of action for ordinary recipients. Enforcement runs through the FTC: 15 U.S.C. § 7706(a) provides that the Act “shall be enforced by the Commission as if the violation of this chapter were an unfair or deceptive act or practice proscribed under section 18(a)(1)(B) of the Federal Trade Commission Act”. That routing matters: CAN-SPAM has no dedicated line in the FTC’s penalty schedule at 16 C.F.R. § 1.98, because the penalty it borrows is the FTC Act’s.

The FTC states the figure plainly in its compliance guide for business: “Each separate email in violation of the law is subject to penalties of up to $53,088, and more than one person may be held responsible for violations.” That maximum tracks the inflation adjustment in 16 C.F.R. § 1.98, effective 17 January 2025, made under the Federal Civil Penalties Inflation Adjustment Act Improvements Act of 2015.

The exposure is structural rather than dramatic, and it is the same arithmetic that makes TCPA quiet-hours claims expensive: per message. A 20,000-address campaign that ships without a postal address in the footer is not one violation — it is 20,000 of them, and the ceiling is a number with five digits attached to each. Automation is what converts a single misconfiguration into a five-figure multiplier, which is why the compliance surface belongs in the send path itself rather than in a checklist someone runs before a campaign.

What CAN-SPAM is not

Four honest boundaries, because a compliance page that overstates its subject is worse than none.

• It is not a consent regime. CAN-SPAM permits the first message without permission. The GDPR and the EU/UK ePrivacy rules do not — a lawful basis is needed before you send at all, and the American opt-out model is no defense there. Recipient location decides which regime governs, not where your company sits.
• It has no B2B exemption. Any message whose primary purpose is commercial advertisement or promotion is covered. A cold sales email to a work address is a commercial message with the full set of duties attached.
• It says nothing about time of day. Quiet hours are a TCPA construct for telephone solicitations (47 C.F.R. § 64.1200(c)(1)). Email has no equivalent, in any U.S. jurisdiction.
• It does not require one-click. RFC 8058 is not in the statute. It is required by Gmail and Yahoo as a condition of delivery, which for most senders is the more immediate constraint — the FTC may never look at your campaign, but Gmail evaluates every message.

How Veera handles unsubscribe and suppression

Stated plainly first, because the ordering matters: email outreach is a channel Veera is still activating, not one that is live today. Veera’s AI voice calling is the channel that is live; SMS and WhatsApp outreach are being activated alongside email. In-call WhatsApp document delivery — sending a brochure or quote while a call is in progress — is the one send path already running next to voice. What follows describes the unsubscribe machinery that is built and tested against the rules above, not a campaign you can start tomorrow.

Five properties do the work:

1. 1.Both RFC 8058 headers, on every outreach email. List-Unsubscribe carries the HTTPS URI first and a mailto second; List-Unsubscribe-Post carries the exact List-Unsubscribe=One-Click value. The visible footer link points at the same signed URL as the header, so the human path and the provider path cannot disagree.
2. 2.Suppression is checked before the send, not after. Every outreach email tests the address against the client-scoped suppression list first and skips the send if it is listed. An opt-out therefore takes effect on the next send rather than somewhere inside the 10 business days § 7704(a)(4) allows. The same check guards the phone channels against their own opt-out lists.
3. 3.The token is signed, so the endpoint is not enumerable. The unsubscribe URL carries an HMAC-SHA256-signed payload identifying the organization, client, and address, compared in constant time. Without the signing key you cannot forge an unsubscribe for an address you do not control — the “hard-to-forge component” RFC 8058’s security considerations ask for.
4. 4.GET confirms, POST unsubscribes, nothing redirects. A GET renders a minimal confirmation page and writes nothing, so a link scanner or prefetcher cannot opt anyone out. Only a POST carrying the One-Click directive writes a suppression, and it writes it through the same path every other opt-out source uses rather than a parallel one. The endpoint returns no 3xx at all, per the RFC.
5. 5.Missing compliance config skips the send. If the unsubscribe signing key is unbound, or the organization has not recorded a physical postal address, the send is skipped rather than dispatched without a working opt-out or the address § 7704(a)(5) requires. A dropped message is a recoverable failure; a non-compliant one is not.

Scope, stated honestly. These are controls, not a certification, and this page is not legal advice. Veera enforces TCPA quiet hours per call and timezone-aware on its phone channels, honors CAN-SPAM one-click unsubscribe with suppression checked before every send, and honors GDPR Article 17 erasure requests when they are made — none of which amounts to a blanket claim that any program built on it is compliant. Your sending domain, your consent posture, your postal address, and your list provenance are yours.

Veera syncs into the CRM an agency already runs — GoHighLevel or HubSpot — rather than replacing it, so opt-outs and outreach outcomes land on the contact record where the rest of the team already works. Veera is free to start.

Frequently asked questions

Related reading

• AI calling compliance — the hub: consent, quiet hours, disclosure, and suppression across every outreach channel
• TCPA quiet hours for AI calls — the 8am–9pm local-time rule that governs phone channels — and never touches email
• Do-not-call lists and suppression — the phone-side counterpart: the National Registry and internal do-not-call lists
• What is an AI Business Aide? — the category this sits inside
• AI outreach CRM for agencies — how outreach and the CRM of record fit together
• Verified lead discovery — where a list comes from, and why provenance decides your compliance posture
• In-call WhatsApp delivery — sending documents during a live AI call