The Bulk Sender Rules Changed. You Get Rejected Now, Not Filtered.

For twenty years the worst thing a mailbox provider did to a bad sender was put the message in a folder. That changed. Gmail, Yahoo and Microsoft now refuse non-compliant bulk mail at the SMTP level, and a refused message is not in a spam folder, it is nowhere.

For anyone running outbound this is the most consequential change in the mechanics of email in a decade, and it is straightforwardly good news for senders who do the work, because the failure finally shows up in your logs instead of silently costing you replies.

Who the rules apply to

The threshold is 5,000 messages a day to one provider's users, counted per sending domain. Cross it and the requirements are mandatory rather than advisory.

That number sounds high and is easier to reach than founders expect. It counts every message, so a sequence with four follow-ups multiplies your contact list by five, and it is per provider, so a list that is heavily Gmail hits the Google threshold long before your total volume looks large.

Below the threshold, the same signals still score you. You simply get filtered instead of rejected, which is the worse outcome because it is invisible.

The four requirements

1. SPF, DKIM and DMARC. All three.

SPF says which servers may send as your domain. DKIM signs each message so the receiver can verify it. DMARC tells the receiver what to do when either fails, and gives you reports.

The trap worth naming: SPF and DMARC without DKIM fails Google's requirement. Plenty of senders configured SPF years ago, added DMARC when they read about the change, and never signed anything. Google also checks alignment rather than mere presence, so a passing SPF record that authenticates a different domain than the one in the From header does not count.

Start DMARC at p=none, read the reports for a fortnight until you recognise everything that legitimately sends as you, then tighten. Going straight to p=reject reliably blocks something you forgot about.

2. A spam complaint rate below 0.3%

Below 0.1% is the number to actually aim at; 0.3% is where enforcement begins. The arithmetic is brutal at small scale: three complaints per thousand delivered puts you on the line.

This is why list quality is a deliverability problem rather than a marketing preference. Writing to people who have no plausible reason to care produces complaints, and complaints are the one signal you cannot argue with.

3. One-click unsubscribe, done properly

The requirement is RFC 8058: a List-Unsubscribe header and a List-Unsubscribe-Post header, which is what lets the mail client render its own unsubscribe control at the top of the message. It must work without making the recipient log in, and you must honour it within two days.

A link in the footer is not this. Keep the footer link too, but understand that the header version is the one being checked, and it is also the one that intercepts the person who would otherwise click Report Spam. Making leaving easy is the cheapest complaint-rate control there is.

4. Valid forward and reverse DNS, and TLS

Less discussed because most managed sending infrastructure handles it, but if you are sending from your own server, a PTR record that resolves and opportunistic TLS are both expected.

The thresholds, in one table

Why rejection is better than filtering

Counterintuitive, and true. A message filed in spam is delivered as far as your tooling is concerned: your dashboard shows a successful send, your bounce rate is clean, and your reply rate is mysteriously zero. You can spend a month rewriting subject lines to fix a DNS record.

A 550 is a bounce with a code and usually a link to the provider's documentation. It tells you exactly what is wrong on the first attempt. If your bounce rate jumped recently and the codes are 5xx, stop looking at your list and go and read your DNS.

What this means for a small sender

You are probably below the hard thresholds, and you should behave as though you are not, because the scoring is continuous and the cost of compliance is an afternoon.

Authenticate the sending domain properly, including DKIM. Put the RFC 8058 headers on every message. Watch the complaint rate rather than the open rate. Ramp new domains slowly enough that your sending pattern looks like a business rather than a burst.

None of it is difficult. All of it is the kind of work that does not happen when you also have a product to build, which is the honest argument for having something else do it. Operater's Sales agent buys and authenticates its own sending domains, warms them across about three weeks, puts one-click unsubscribe on every message, verifies addresses before sending, keeps daily volume inside provider limits, and stops sending from an address whose numbers turn bad rather than running it into the ground.

Which is worth saying plainly: none of that is secret, and a founder with a spare afternoon can do all of it by hand. The part that does not survive contact with a real week is doing it again every week, forever.