Bulk sender rules and the small sender

In late 2023 Google and Yahoo announced requirements for bulk senders that took effect during 2024. The headline threshold was five thousand messages a day to their users, which sounds like somebody else's problem if your website sends a dozen form notifications a week.

It is somebody else's threshold, but not somebody else's standard. What the announcement really did was publish, in plain language, the criteria receivers had been applying informally for years. Authenticate your mail. Do not send to people who did not ask. Keep complaints low. Make unsubscribing trivial for anything promotional.

The requirements Google enforces are documented in its email sender guidelines, and the interesting part for a small sender is not the bulk section. It is the general section, which applies to everyone and always did.

Three of them apply to you regardless of volume, and they are the ones worth acting on.

Authentication comes first: mail should have valid SPF and DKIM, aligned under DMARC. Valid forward and reverse DNS on the sending host comes second, which is your host's responsibility but your problem when it is wrong. Third, messages should be recognisably legitimate mail, formatted properly, from a consistent address, not assembled by string concatenation in a way that produces malformed headers.

The unsubscribe requirements and the complaint rate thresholds are genuinely about bulk marketing. A form notification you send to yourself is not marketing, and nobody is going to mark it as spam except you.

There is an unfair asymmetry here that is worth stating plainly. A large sender that meets the requirements accumulates a reputation, and reputation buys tolerance. A site sending eleven messages a month never accumulates anything.

That means every individual message is evaluated much more on its intrinsic signals, because there is no history to fall back on. Authentication stops being one factor among many and becomes close to the only factor you control.

It also means a single bad week can matter more. If a spam run somewhere forges your domain, or your shared host earns a poor reputation from an unrelated site, you have no track record to outweigh it. This is the strongest practical argument for publishing a DMARC policy even at trivial volumes: it is the mechanism by which you tell receivers to disregard mail that is not really yours.

Many small businesses receive mail at an address that forwards elsewhere. Enquiries go to an address at the company domain, which forwards to a personal mailbox at a large consumer provider.

Forwarding breaks SPF by design, because the forwarding server is not listed in the original sender's record. A valid DKIM signature survives forwarding and rescues the message, which is a concrete reason to make sure DKIM is in place rather than relying on SPF alone.

If your notifications arrive fine at the company address but vanish after the forward, this is almost always the explanation, and it is one of the few delivery problems where the fix is on the receiving side rather than the sending side.

The requirement that attracted the most attention was one-click unsubscribe for commercial mail. It is worth being clear about scope, because the requirement has been over-applied by nervous senders.

It concerns subscribed messages: newsletters, promotions, announcements. A notification telling you that someone filled in your contact form is not that, and neither is a receipt or a password reset. Adding unsubscribe headers to your own internal notifications achieves nothing except confusion.

Where it does bite is the moment a form feeds a mailing list. If your signup form subscribes people to something you send regularly, everything you send them from that point is in scope, and the rules about consent and easy exit apply in full.

The deepest change in the guidelines is not technical at all. It is the insistence that recipients wanted the mail, which pushes the problem back to the moment of collection.

A form that adds every enquiry to a newsletter without asking produces exactly the complaint pattern the rules punish. A pre-ticked box produces the same result more slowly. The reliable version is an unticked box with plain wording, and a record of the choice stored alongside the submission so you can demonstrate it later.

That record is easy to keep when submissions land as rows: consent is a column, with a timestamp beside it, in the same place as everything else about the lead.

1. Publish SPF listing every service that sends as your domain.
2. Enable DKIM signing wherever your mail actually leaves from.
3. Publish DMARC in monitoring mode and read the reports for a month.
4. Send notifications From your own domain, never the visitor's.
5. Keep marketing consent separate from enquiry handling, and record it.
6. Re-test after any migration, because that is when working setups break.

None of that requires a compliance project. It is an afternoon, most of which is waiting for DNS to propagate.

The step people skip is the inventory that has to come before the first line. You cannot write an SPF record that lists every sender until you know who every sender is, and the list is reliably longer than anyone expects. Accounting software, the booking tool, a form plugin sending through its own relay, a recruiter platform somebody trialled. Each one was authorised by a different person at a different time, and none of them appears in a place you would think to look. Working from the DMARC reports is the fastest way to find them, which is the real argument for turning monitoring on before you change anything else.

Even a perfectly configured small sender has no guarantee of inbox placement. The guidelines describe the floor, not a contract. Meeting them makes you eligible for delivery; it does not oblige a receiver to deliver.

This is not cynicism, it is the design. Filtering exists because senders cannot be trusted collectively, and no amount of correctness on your side removes the receiver's discretion.

Which is the practical reason to keep the record and the notification separate. If the record is a row in a spreadsheet, an undelivered notification costs you an hour of awareness. If the notification is the record, it costs you the lead.

The reasonable position is to do the work and then stop worrying about it. Authenticate properly, send from your own domain, keep consent clean, and accept that the last mile belongs to somebody else.

Then arrange your pipeline so that the last mile is not load-bearing. When a submission is written straight into a spreadsheet, the delivery log tells you it arrived, and the email is a convenience that alerts you faster. When the two are the same thing, every filtering decision made by a company you have no relationship with is a decision about your revenue.

For the full chain behind a single notification, the six links piece walks through where it breaks.

You are not a bulk sender and the thresholds are not aimed at you. The standards underneath them are, and they were the standards before the announcement made them explicit.

Authenticate, be consistent, ask before you subscribe anyone, and keep a record that survives a bad delivery day. That is the whole of it.

Do the bulk rules apply to me at low volume?

Is the five thousand a day threshold per provider?

Do I need unsubscribe links on contact form notifications?

My forwarded address loses messages. What fixes it?

Does a transactional email service make me compliant?

What is the fastest way to check where I stand?

Should I publish a strict DMARC policy right away?