The Bulk Sender Checklist for Gmail, Yahoo and Microsoft

For about twenty years, email authentication was advice. You were encouraged to publish SPF, told DKIM was a good idea, and nothing much happened if you ignored both. In February 2024 that ended: Google and Yahoo began enforcing a shared set of requirements for bulk senders, and Microsoft announced equivalent rules for its consumer Outlook and Hotmail mailboxes in 2025.

The requirements are not difficult. What makes them dangerous is that failing them does not produce a clear error. Mail is filed as spam or rejected with a generic message, and the sending platform still reports a successful send.

Who counts as a "bulk sender"

Google defines the threshold as roughly 5,000 messages a day to Gmail accounts, counted per sending domain. Yahoo has not published a numeric threshold, and Microsoft's announcement follows the same shape as Google's.

Three things make the threshold less useful than it looks. It is counted across everything sent from your domain, so transactional and marketing mail combine. It can be crossed by a single campaign and then apply to you. And the smaller requirements — authentication in particular — are applied to all senders regardless of volume, with unauthenticated mail treated more harshly every year.

The checklist

1. SPF and DKIM, not one or the other

Every message must be authenticated. For bulk senders both mechanisms are expected to be in place, and the message must carry a valid DKIM signature. SPF alone is not enough, because it does not survive forwarding.

example.com                       TXT  "v=spf1 include:_spf.google.com -all"
selector1._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."

Use 2048-bit keys where your platform supports them, and rotate them periodically by publishing a new selector before switching.

2. A DMARC record, at minimum p=none

A published DMARC policy is required. p=none satisfies the requirement, though it protects nobody on its own:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Publish it with a reporting address so the data starts accumulating, then work towards enforcement using the staged rollout plan.

3. Alignment with the visible From address

This is the item most often missed. The domain that passes SPF or DKIM must align with the domain in the From: header. A platform sending on your behalf with its own bounce domain and its own DKIM signature passes its own checks and fails yours.

4. One-click unsubscribe for marketing mail

Commercial and subscribed messages must offer one-click unsubscribe as described in RFC 8058. That means two headers, not just the older link-only form:

List-Unsubscribe: <https://example.com/unsubscribe?id=abc123>, <mailto:unsubscribe@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The request must be honoured within two days, and the unsubscribe link in the message body stays: the header is in addition to it, not a replacement. Most reputable platforms add these headers automatically — verify rather than assume, particularly for mail your own application sends.

5. A spam-complaint rate you actually watch

Google's published guidance asks senders to keep the spam-complaint rate reported in Postmaster Tools below 0.10% and states it must never reach 0.30%. Complaints are driven by list quality and expectation, not by content: buying lists, adding people who never asked, and mailing dormant addresses are the usual causes.

6. Valid reverse DNS on every sending IP

Each IP you send from needs a PTR record, and that host name must resolve back to the same IP — forward-confirmed reverse DNS. If you send through a platform this is the vendor's responsibility; if you run your own server, it is yours and is set at your hosting provider, not in your own zone. The detail is covered in why mail servers judge your IP by its PTR.

7. TLS in transit

Connections must offer TLS via STARTTLS. Every current mail platform does this; it is worth verifying if you run your own server or an appliance that has not been touched in years.

8. Well-formed messages, and no impersonation

Messages must comply with RFC 5322 formatting, use a valid resolvable From domain, and must not put a Gmail address in the From header of mail sent from your own infrastructure — a practice Google's rules specifically target.

What breaks without it

• Unauthenticated mail is filed, not bounced. You lose the feedback loop entirely: the platform says delivered, and nobody sees the message.
• No DMARC record means bulk mail is rejected outright by providers enforcing the rules, regardless of how clean your list is.
• Missing one-click unsubscribe raises complaints. People who cannot find an unsubscribe button press the spam button instead, which damages the reputation of every message you send, transactional included.
• A crossed complaint threshold is slow to repair. Reputation recovers gradually; the mail you lose while it does is gone.
• Missing PTR records cause connections to be throttled or refused before your content is ever evaluated.

How to check it in 30 seconds

Run an Email Health report. It covers the DNS-visible half of the list in one pass: SPF including the lookup count, DKIM for common selectors, DMARC policy and alignment, MX records, reverse DNS for each mail server, TLS support, and blacklist status.

For the message-level items — the unsubscribe headers, the authentication results a receiver actually recorded — send yourself a copy of a real campaign and paste its headers into the Email Header Analyzer. That is the only way to confirm what your platform is really sending, as opposed to what its settings page claims.

Fix it

Then keep it that way

Every item on this list is a piece of configuration that can be changed by someone who is not thinking about deliverability: a DNS record edited during a migration, a DKIM key rotated on one platform but not published, a reverse DNS entry lost when a server is rebuilt, a new marketing tool added without an SPF entry.

StatusDNS re-checks the DNS-visible requirements — SPF and its lookup count, DKIM keys, DMARC policy, MX records, reverse DNS and blacklist status — on a schedule, and alerts you by email, Slack or webhook when a record changes or a passing check starts failing. The requirements only have to be met once; staying compliant is the part that needs watching.