Gmail, Yahoo and Outlook bulk sender rules, and CAN-SPAM

What changed, and when

Both providers announced in late 2023 and began enforcing in February 2024. Google’s guidelines date the whole bulk list to 1 February 2024, one-click unsubscribe included; the later date often quoted is from Google’s own FAQ, and it is narrower than it sounds — senders who already carried an unsubscribe link were given until 1 June 2024 to make it one-click. Both providers maintain the list on their own sender pages, which are the primary sources for this page.

None of the individual requirements was new. SPF has been specified since 2014 in RFC 7208, DKIM since 2011 in RFC 6376, DMARC since 2015 in RFC 7489, and the one-click unsubscribe header since 2017 in RFC 8058. What changed was the consequence. Before February 2024 an unauthenticated message from a small sender was filtered on the balance of other evidence; since then it may be marked as spam or rejected outright, and a Gmail rejection carries a 5.7.26 error saying so.

Microsoft followed in April 2025 for Outlook.com, the consumer service behind outlook.com, hotmail.com and live.com addresses. From 5 May 2025 a domain sending more than 5,000 messages a day there must pass SPF and DKIM and publish a DMARC record of at least p=none that aligns with one of them, and mail that fails is rejected with a 550 5.7.515 error. Microsoft also recommends a working unsubscribe link, a From or Reply-To address that can receive replies, and regular removal of addresses that bounce, without making them conditions.

The second change is subtler and has done more work. By publishing a numeric complaint threshold, both providers turned a reputation system nobody could see into one number a sender can look up. That number is not on your sending dashboard and never will be — your provider is not told it — but it is free on each mailbox operator’s own postmaster dashboard to whoever proves they control the domain.

Who counts as a bulk sender

Google defines a bulk sender as one sending close to 5,000 messages or more in a single day to personal Gmail accounts from the same domain, and its guidelines state that once a domain has done that it is treated as a bulk sender from then on. Three details in that sentence do most of the work. It is counted per domain, so splitting a send across subdomains is not a way under the line. It counts personal Gmail accounts, not mail to organisations using Google Workspace. And it is a day’s volume, not a month’s, so one launch puts you over permanently.

The authentication floor is separate and applies to everyone at any volume. Google and Yahoo both ask every sender for SPF or DKIM on the domain it sends from; the bulk list asks for both, plus DMARC. Unauthenticated mail may be marked as spam or rejected whether you send five messages or fifty thousand. This is the part most often misread, because the announcements were written around the word bulk and the hardest consequence in them applies to the smallest sender.

So the practical reading for somebody running a course to a few hundred people is that the whole list applies. You will cross the bulk line on a good month, the threshold is permanent once crossed, and none of the work is anything you would want to do reactively — a DNS record published in a hurry during an incident is how a sending domain ends up misconfigured for a year.

The requirements, and how to check each one yourself

Each of these is verifiable from outside, with a DNS lookup or by reading the raw source of a message you sent to yourself, and that is the reason to go through them one at a time rather than trusting a settings page that says “verified”. A sending tool reporting a domain as verified is reporting that it can send as the domain, which is not the same claim as any of the rows below.

The one that catches people out is alignment. Mail can pass SPF and pass DKIM and still fail DMARC, because both passes were on your provider’s domain while the From line the reader sees is yours. That is the default state with a good many sending services until the domain setup is finished, and it looks identical to success everywhere except in the Authentication-Results header and a DMARC report. The deliverability guide sets out the order to publish the records in; this page is only about which of them the requirements ask for.

The headers, and what each one does

Two headers do the work, and a one-click unsubscribe requires both. List-Unsubscribe on its own predates RFC 8058 and offers exits a client may present; List-Unsubscribe-Post is the header that declares the https URI safe to POST to without asking the reader anything further. A message with the first and not the second does not have one-click unsubscribe, whatever the sending dashboard says.

The two-day rule

Google and Yahoo both require that an unsubscribe request be honoured within two days. That is a much shorter clock than the 10 business days the United States CAN-SPAM Act allows, and since the providers enforce theirs by filtering your mail rather than by writing to you, theirs is the one that decides whether you have a problem.

Two days is the outer limit and there is no reason to use it. An unsubscribe is a single row and the send is asynchronous, so the honest implementation removes the address before it answers the request, which makes the window irrelevant. The senders who need the two days are the ones running an export to a spreadsheet and an import back, and that arrangement is also how somebody gets mailed after they left.

What the clock really protects against is the worst complaint there is. A message that arrives after somebody asked to leave does not produce another unsubscribe; it produces a spam button press, from a reader who now believes you ignored them. Those are the complaints that move a complaint rate fastest.

What failing looks like from your side, which is mostly nothing

Only authentication can fail loudly. Gmail may reject unauthenticated mail at the door with a 5.7.26 error, and Outlook.com rejects mail from a high-volume domain that fails its checks with 550 5.7.515; your provider surfaces either as a bounce, and a bounce is something you can see. Gmail may equally file the same message as spam, and then it fails as quietly as everything else.

Failing on alignment, on the unsubscribe header or on the complaint rate does not produce an error, a warning or a notification. The mail is accepted, counted as delivered by your sending tool, and filed into a spam folder. Your delivery rate stays at ninety-nine per cent and your open rate falls slowly enough to be mistaken for seasonality. This is the single most important thing to understand about these rules: compliance is not something you will be told about, in either direction.

Which is why the complaint rate is worth looking at on a schedule rather than when something feels wrong. Watch the trend against your own history, per provider, weekly. A move from 0.02 per cent to 0.08 per cent is a warning even though both figures are inside the threshold, and at small volumes the arithmetic is unforgiving: at a thousand delivered messages, three complaints is already 0.3 per cent, and at two hundred a single complaint is more than that. A small sender has no statistical cushion, only a structural one.

What a small sender should actually do about it

The whole list is an afternoon of work done once, and almost all of it is done in DNS and in a settings page rather than in your writing. The order below is deliberate: the authentication comes first because it is the part that fails loudly, and the structural protections come last because they are the ones that keep the complaint rate where it needs to be without further attention.

In this order, once, and then checked once a year:

• Send from a subdomain reserved for it rather than from the root domain. A burned subdomain is retired and replaced in an afternoon; a burned root domain takes your invoices and password resets with it.
• Publish SPF, set up DKIM signing with your own domain in the signature rather than your provider’s, and publish a DMARC record at p=none with a report address you will actually read.
• Send a message to an address you control and read the Authentication-Results header for all three, particularly dmarc=pass, which is the only one that reports alignment.
• Confirm the one-click unsubscribe header is present and that the endpoint answers a POST with a bare 200 rather than redirecting, because a redirect there silently fails the specification.
• Claim the domain on each provider’s postmaster dashboard, and put a weekly look at the complaint rate somewhere you will see it.
• Require a confirmation click before anything but the confirmation email is sent, and suppress a hard bounce on the first failure. These two are what keep the complaint rate low structurally, rather than by vigilance.

The seven requirements, in the FTC’s own order

CAN-SPAM is a United States law rather than a mailbox provider’s rule, and it applies to every commercial email at any volume, one message included. The FTC’s compliance guide lists seven main requirements. Six of them are things in the message, and the seventh is about anybody you pay to send it. The table below is that list with what each one means for a small sender.

The footer, written out

Here is the whole of what CAN-SPAM asks for in the message, as text you can paste and fill in. Put it at the foot of every email in the course, including day one, and keep it as real text rather than an image so that it survives a client with images off.

The footer, line by line:

• You are getting this because you signed up for [the course title] at [your site] on [the date]. That sentence is not required by the statute, and it is the single most effective line for stopping a spam complaint from somebody who has forgotten.
• [Your name or business name], [street address or registered post office box], [city, region, postcode, country]. A real physical postal address, required in every commercial message.
• Unsubscribe: [one link, plain visible text, no login, no reason required]. Honoured immediately in practice, well inside the 10 business days the law allows and the two days the large mailbox providers require.

What the rules do not say

None of the three providers requires a confirmation step. There is no double opt-in requirement in any of their documents, and anyone telling you Gmail now demands it is describing an implication rather than a rule. The implication is real — complaints come overwhelmingly from people who do not recognise the sender, so a confirmed list sits far below the threshold almost by construction — but the requirement is the threshold, not the mechanism, and the guide to single and double opt-in argues the mechanism on its own merits.

Nor does any of them publish a warm-up ramp, a volume cap, a content rule, a list of forbidden words, or a requirement to use any particular sending service. What there is on warming a new domain, and the shape most senders use, is in the deliverability guide.

And nothing in either document is a legal requirement. These are the terms on which two private companies accept mail, enforced by the only mechanism that matters to a sender, which is whether the mail arrives. The law is a separate floor with separate contents — a working unsubscribe honoured in a stated window, a real postal address, an accurate From line, and for readers in the European Union a consent record you can produce. CAN-SPAM’s part of it is set out above, and the GDPR guide covers the European part. Meeting the provider requirements does not discharge the legal ones, and meeting the legal ones does not get your mail delivered.