The bulk sender rules are not new any more. Most shops still fail one of them.

In February 2024 Google and Yahoo started enforcing a shared set of requirements for bulk senders. Microsoft announced equivalent rules for its consumer Outlook domains, with enforcement from May 2025. None of this is controversial any more, and yet a majority of the shops we look at fail at least one item — usually the same one.

The requirements, in plain language

1. SPF and DKIM on every sending domain. Both, not either. DKIM must sign with a key you control, usually 2048-bit.
2. A DMARC record on the organisational domain. p=none is enough to satisfy the requirement, but it protects nothing on its own.
3. Alignment. The visible From: domain has to align with the domain that passed SPF or DKIM. This is the item that fails silently.
4. One-click unsubscribe for commercial mail: the List-Unsubscribe and List-Unsubscribe-Post headers per RFC 8058, honoured within two days.
5. A visible unsubscribe link in the body as well. The header does not replace it.
6. Spam complaint rate below 0.3 % as measured in Google Postmaster Tools, with 0.1 % as the level to actually design for.
7. Valid forward and reverse DNS on the sending IP, and TLS for transmission.
8. No impersonation of Gmail or the mailbox provider in your From header.

The threshold that triggers “bulk sender” status at Google is around 5,000 messages a day to Gmail addresses. It is worth noting that this is per day, not per campaign, and that a mid-sized shop crosses it on the day of a sale without anyone deciding to.

The item that breaks quietly: alignment

A message can pass SPF and still fail DMARC. This happens constantly when a shop sends from news@shop.com through a platform whose envelope sender is bounces@platform.net. SPF passes — for the platform's domain. DMARC asks a different question: does the domain that passed match the one the recipient sees? If not, the message is unauthenticated as far as the policy is concerned.

The fix is either a custom return-path (a CNAME your provider gives you) or DKIM signing with your own domain key. Do both. Then check a real delivered message rather than a configuration screen: open any message in Gmail, choose Show original, and confirm you see SPF, DKIM and DMARC all reporting PASS with your own domain in the header.from field.

Moving DMARC past p=none

p=none only asks for reports. It is a monitoring mode, not a policy, and it stops nobody from spoofing your domain. The progression that works:

1. Publish p=none with a rua address and read the aggregate reports for two to four weeks.
2. Identify every legitimate source: the shop platform, the email platform, the helpdesk, the invoicing system, the CRM, and whatever marketing ran a campaign from three years ago.
3. Authenticate each one properly, or stop it sending as your domain.
4. Move to p=quarantine; pct=25, then raise the percentage, then p=reject.

Most shops stall at step two, because the aggregate reports reveal a system nobody remembers setting up. That discovery is the actual value of DMARC.

The complaint rate is a design constraint

0.3 % sounds generous until you translate it: three complaints per thousand delivered messages. One badly targeted campaign to a dormant segment can exceed it in an afternoon, and recovery is not instant — reputation is measured over a rolling window, so a single bad day taxes the following weeks.

• Suppress addresses with no engagement in the last 6–12 months before a large send, not after.
• Watch the rate per campaign in Postmaster Tools, not the monthly average.
• Treat a spike as a content and targeting problem first. It almost never is a technical one.

A verification pass you can do today

1. Send a campaign to a personal Gmail address and read the original headers. All three checks must pass, aligned to your domain.
2. Confirm the unsubscribe control appears at the top of the message in Gmail's interface — that is the header working.
3. Register the domain in Google Postmaster Tools and Microsoft SNDS. Without them you are guessing.
4. Check that your reverse DNS resolves and matches forward DNS.
5. Search your DNS for orphaned SPF includes from services you stopped using. Every include is a permission you are still granting.

None of this improves a bad campaign. It only removes the reasons a good one gets filtered, which is the whole job of deliverability work.