Gmail and Yahoo Sender Requirements: A Practical Checklist

In February 2024, Gmail and Yahoo started enforcing a set of sender requirements that had been "best practice" for years. Nothing in them is exotic, but they turned authentication and complaint rates from nice-to-haves into conditions for reaching the inbox. If you send any meaningful volume to personal Gmail or Yahoo addresses, these rules apply to you.

This post covers what the requirements are, which ones apply to every sender and which only to bulk senders, and where list hygiene fits. I've kept to the well-documented parts. The exact enforcement details change over time, so treat Google's and Yahoo's own sender guidelines as the final word.

Who counts as a "bulk sender"?

Google defines a bulk sender as one that sends close to 5,000 or more messages to personal Gmail accounts within 24 hours. Messages from the same primary domain count together, and once you've crossed that line, Google treats you as a bulk sender going forward, even on quieter days.

Yahoo doesn't publish a precise number in the same way but applies essentially the same requirements to bulk senders.

The important nuance: several requirements apply to all senders, not just bulk ones. Small senders don't get a pass on authentication.

The requirements at a glance

Let me go through the ones that trip people up.

SPF and DKIM

SPF is a DNS TXT record listing which servers may send mail for your domain. DKIM adds a cryptographic signature to each message, verified against a public key in your DNS. For all senders, at least one must pass. For bulk senders, both must.

Common gaps I see:

• The ESP sends with its own domain in the Return-Path, so SPF passes for their domain, not yours. That's fine for SPF itself but doesn't help DMARC alignment.
• DKIM is set up for the main ESP but not for the CRM, helpdesk or invoicing tool that also sends as your domain.
• The SPF record has too many include: lookups and exceeds the 10 DNS lookup limit, so it fails with a permerror.

If you want the background on all three protocols, read SPF, DKIM and DMARC explained. You can check your records with the SPF checker and DKIM checker.

DMARC and alignment

Bulk senders must publish a DMARC record. The minimum is p=none, which doesn't block anything but proves you have a policy and lets you receive reports:

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

The part people miss is alignment. DMARC passes only if SPF or DKIM passes for the same domain as the visible From address. If your newsletter says From: news@example.com but DKIM is signed with d=esp-mail.net and the Return-Path is on the ESP's domain, both checks can pass and DMARC still fails. The fix is usually custom DKIM (signing with d=example.com) in your ESP's settings.

Once you're at p=none and reports look clean, you can move towards quarantine and reject. I wrote a step-by-step for that in moving DMARC from none to quarantine to reject. The DMARC checker shows what you currently publish.

One-click unsubscribe

Marketing and subscribed messages from bulk senders need one-click unsubscribe as defined in RFC 8058. In practice that means two headers:

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

The mail client sends a POST to the HTTPS URL, and you must honor it without asking the user to log in or confirm. Both providers expect unsubscribes to be processed within two days. You also still need a visible unsubscribe link in the message body.

Transactional mail (password resets, receipts) doesn't need this. Most ESPs add these headers automatically for marketing sends, but check a raw message to be sure, especially if you send through your own SMTP setup.

Spam complaint rate

This is the requirement that ends up hurting the most senders. Google asks senders to keep the spam rate reported in Postmaster Tools below 0.3%, and recommends staying below 0.1%. Yahoo uses the same 0.3% threshold. The rate is measured as complaints relative to messages delivered to the inbox, so it's per real recipient, not per list.

You can't fake your way around this. The things that move it:

• Sending only to people who asked for your mail.
• Making unsubscribing easier than hitting "Report spam".
• Setting expectations at signup (what you'll send and how often).
• Not mailing people who haven't engaged in a long time.

Set up Google Postmaster Tools for your domain. It's the only reliable way to see the number Google actually uses.

PTR records and TLS

Sending IPs need valid forward and reverse DNS: the IP's PTR record should resolve to a hostname, and that hostname should resolve back to the IP. If you use an ESP, they handle this. If you run your own mail server, check it with the reverse DNS lookup.

TLS for the SMTP connection is required. Every mainstream ESP does this by default.

Where list hygiene fits

The requirements don't mention bounce rates directly, but bounces and complaints come from the same place: sending to addresses that shouldn't be on your list. A few ways bad data shows up in these metrics:

• Hard bounces from dead or mistyped addresses are one of the clearest signals to mailbox providers that a sender isn't maintaining its list. High bounce rates damage reputation, which makes the spam folder more likely, which drives complaints.
• Spam traps are addresses that never belong to a real person. Hitting them hurts reputation even without a complaint.
• Old, scraped or bought lists produce both bounces and complaints, because the recipients never asked for your email.
• Typos at signup (gmial.com) mean the real person never gets your confirmation email and may later report your mail as spam when they sign up again.

Verification doesn't replace consent, but it removes the addresses that were never going to work. I'd verify at signup with a fast check, verify imported lists before the first send, and re-verify lists that haven't been mailed in months. The reduce email bounce rate post goes into that in more detail.

Checklist

• [ ] SPF record exists, includes every service that sends as your domain, stays under 10 lookups
• [ ] DKIM set up with your own domain for every sending service (ESP, CRM, helpdesk, billing)
• [ ] DMARC record published, at least p=none with rua reporting
• [ ] From domain aligns with the DKIM d= domain (or the SPF Return-Path domain)
• [ ] Sending IPs have matching forward and reverse DNS
• [ ] TLS on all outbound SMTP
• [ ] List-Unsubscribe and List-Unsubscribe-Post headers on marketing mail
• [ ] Unsubscribes processed within two days
• [ ] Visible unsubscribe link in marketing emails
• [ ] Google Postmaster Tools set up; spam rate well under 0.3%, ideally under 0.1%
• [ ] New and imported addresses verified before the first send

Check your domain

The fastest way to see where you stand on the DNS side is the free domain health checker. It checks SPF, DKIM, DMARC, MX, BIMI and PTR in one go. For list quality, MailRambo's API gives you 100 free checks a month, and the developer docs show how to verify single addresses or batches of up to 200.