Gmail & Yahoo Bulk Sender Requirements: Setup Checklist

In February 2024, Gmail and Yahoo started enforcing a new set of rules for anyone who sends email to their users. If your password reset emails suddenly land in spam, or your newsletter gets bounced with a cryptic 5xx error, there is a good chance one of these requirements is the reason. Most of them are DNS records and headers you can set up in an afternoon.

This guide walks through what Google and Yahoo actually require, which rules apply to every sender and which only apply to bulk senders, and how to verify each one. Everything here is based on Google's Email sender guidelines and its FAQ, plus Yahoo's Sender Best Practices page.

Who counts as a bulk sender?

Google defines a bulk sender as one that sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period. Two details in Google's FAQ matter a lot for small businesses:

• Volume is counted per primary domain. All messages sent from the same primary domain count together, including subdomains. Mail from news.example.com and app.example.com adds up toward the same total as example.com.
• Bulk status is permanent. According to Google, bulk sender status doesn't expire. If you hit the threshold once, for example during a big product launch, you are treated as a bulk sender from then on, even if your volume drops.

Yahoo's best practices page lists bulk sender requirements too, but it does not publish a specific numeric threshold. If you send marketing email at any real scale, set things up as if you were a bulk sender; the extra work is small.

What applies to everyone

Even if you only send a handful of messages a day, Google's guidelines require all senders to:

• Set up SPF or DKIM for the sending domain.
• Have valid forward and reverse DNS (a PTR record) for sending domains or IPs.
• Use a TLS connection when transmitting email.
• Keep the spam rate reported in Postmaster Tools below 0.3%.
• Format messages according to RFC 5322.
• Not impersonate Gmail From: headers.

Yahoo's list for all senders is very similar: SPF or DKIM at minimum, a spam rate below 0.3%, valid forward and reverse DNS for sending IPs, and compliance with RFC 5321 and RFC 5322. Yahoo's best practices page doesn't list TLS explicitly, but since Gmail requires it, you need it anyway.

What bulk senders must add

On top of everything above, bulk senders need:

• Both SPF and DKIM, not just one of them.
• A DMARC record for the sending domain. The policy can be p=none.
• Alignment: the domain in the From: header must align with either the SPF domain or the DKIM domain.
• One-click unsubscribe for marketing and subscribed messages, plus a clearly visible unsubscribe link in the body.

Yahoo adds that unsubscribes must be honored within 2 days. Google's FAQ says requests should be processed within 48 hours. Same deadline, different wording.

The requirement-by-requirement checklist

1. SPF

SPF is a TXT record on your domain that lists which servers may send mail for it. A typical record looks like this:

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Common mistakes: publishing two separate SPF records (only one is allowed), exceeding the 10 DNS lookup limit with too many include: mechanisms, and forgetting to add a new email service when you start using it. Check your record with the SPF Checker, which flags syntax errors and lookup counts.

2. DKIM

DKIM adds a cryptographic signature to each message. Your email provider gives you a public key to publish as a TXT (or CNAME) record under a selector, such as s1._domainkey.example.com. Google's guidelines call for a key of at least 1024 bits; use 2048 if your provider supports it.

To verify, look up the selector with the DKIM Checker, then send a test message to a Gmail account, open it, choose "Show original," and confirm it says DKIM: 'PASS' with your domain.

3. DMARC

DMARC tells receivers what to do when SPF and DKIM don't line up with your From: domain, and where to send reports. The minimum record Google and Yahoo accept for bulk senders is:

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

p=none means "monitor only." It won't block anything, but it gives you aggregate reports showing who is sending as your domain. Once those reports show all your legitimate sources passing, you can move toward p=quarantine or p=reject. Build a record with the DMARC Generator and confirm it is published correctly with the DMARC Checker.

4. Alignment

This is the requirement people miss most often. Passing SPF or DKIM isn't enough; the domain that passes has to match the domain in your visible From: header. Google's FAQ says the organizational domains must align, so a DKIM signature for mail.example.com aligns with From: hello@example.com.

The classic failure: your app sends through an email service with From: hello@example.com, but the message is DKIM-signed with the provider's own domain and the envelope sender (Return-Path) is also the provider's domain. SPF and DKIM both pass, but neither aligns, so DMARC fails. The fix is to set up "domain authentication" or a "custom return-path" in your provider's dashboard so signatures use your domain.

To verify, check "Show original" in Gmail. You want to see DMARC: 'PASS'.

5. Forward and reverse DNS (PTR)

The IP address that connects to Gmail needs a PTR record that resolves to a hostname, and that hostname needs to resolve back to the same IP. You can check from a terminal:

dig -x 203.0.113.10 +short
# mail.example.com.
dig mail.example.com +short
# 203.0.113.10

If you use a hosted email service or ESP, they handle this for you. If you run your own mail server on a VPS, you usually set the PTR record in your hosting provider's control panel, not in your domain's DNS.

6. TLS

Your sending server must use TLS when it delivers to Gmail. Mainstream ESPs and hosted mailboxes already do. For a self-hosted Postfix or Exim server, make sure opportunistic TLS is enabled for outbound mail. To check, open a test message in Gmail and expand the message details under the sender name; the "security" line shows whether standard TLS encryption was used.

7. One-click unsubscribe (RFC 8058)

Marketing and subscribed messages need two headers. The first gives the unsubscribe URL; the second tells the mailbox provider it can unsubscribe the user with a single POST request, without the user visiting a page:

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

Your endpoint must accept a POST to that URL and unsubscribe the user right away, without asking them to log in or confirm. Use a unique, hard-to-guess token per recipient, and include these headers in the DKIM signature so they can't be tampered with. You still need a visible unsubscribe link in the email body as well.

According to Google's FAQ, one-click unsubscribe applies to marketing and promotional messages; transactional messages such as password resets and order receipts are excluded.

8. Spam rate monitoring

Google asks senders to keep their user-reported spam rate below 0.1% and never let it reach 0.3%. The FAQ also says senders at 0.3% or higher become ineligible for mitigation until the rate stays below 0.3% for 7 consecutive days.

Verify your domain in Google Postmaster Tools (postmaster.google.com) to see your spam rate, authentication results, and compliance status. For Yahoo, its best practices page recommends enrolling in the Complaint Feedback Loop so you get a copy of each spam complaint.

Practical setup for common situations

Shared hosting mail (cPanel and similar)

Most cPanel hosts have an "Email Deliverability" section that shows whether SPF and DKIM are valid and can install the records for you. Two things to watch: if your DNS is managed somewhere else, such as Cloudflare, you have to copy those records over manually; and the PTR for a shared server IP belongs to the hosting company, so you can't change it. Shared IPs are fine for low-volume mail but risky for newsletters, since other sites on the same IP affect your reputation.

Transactional email from a web app (Laravel/PHP)

For password resets, signup confirmations, and invoices, a transactional ESP or an authenticated SMTP relay is usually the safest choice. In Laravel, that comes down to a few .env values:

MAIL_MAILER=smtp
MAIL_HOST=smtp.your-provider.com
MAIL_PORT=587
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS=no-reply@example.com
MAIL_FROM_NAME="Example App"

The key detail is that MAIL_FROM_ADDRESS must use a domain you have authenticated with that provider. If your From address is @example.com but you haven't added the provider's DKIM records to example.com, you'll fail alignment. Avoid PHP's bare mail() function on a web server, since it often sends without DKIM and from an IP with no matching PTR.

Consider sending transactional mail from a subdomain, such as mail.example.com, with its own DKIM keys. It keeps setup tidy, though it still counts toward the same primary-domain volume in Google's bulk sender math.

Newsletters and marketing email

Most newsletter platforms add List-Unsubscribe and List-Unsubscribe-Post headers automatically, but only after you authenticate your own domain with them. If you send a newsletter from your own app, add the headers yourself. In Laravel you can do it in a Mailable:

use Illuminate\Mail\Mailables\Headers;

public function headers(): Headers
{
    $url = route('newsletter.unsubscribe', ['token' => $this->subscriber->token]);

    return new Headers(text: [
        'List-Unsubscribe' => '<' . $url . '>',
        'List-Unsubscribe-Post' => 'List-Unsubscribe=One-Click',
    ]);
}

Make sure the unsubscribe route accepts POST and is excluded from CSRF protection, because the mailbox provider will call it directly. Only mail people who opted in, and remove addresses that bounce.

Quick checklist

1. SPF record published, single record, under 10 lookups.
2. DKIM enabled with your own domain, key of 1024 bits or more.
3. DMARC record at _dmarc with at least p=none and a rua address.
4. Gmail "Show original" shows SPF, DKIM, and DMARC all passing.
5. Sending IP has matching forward and reverse DNS.
6. Outbound mail uses TLS.
7. Marketing emails include List-Unsubscribe, List-Unsubscribe-Post, and a visible link.
8. Unsubscribes processed within 48 hours.
9. Domain verified in Google Postmaster Tools, spam rate below 0.1%.

FAQ

I send fewer than 5,000 emails a day. Do I need DMARC?

Under Google's guidelines, DMARC is only mandatory for bulk senders, but you still need SPF or DKIM, valid DNS, and TLS. Since a single big send can make you a bulk sender permanently, adding a p=none DMARC record now is cheap insurance.

Do transactional emails need one-click unsubscribe?

No. Google's FAQ says the requirement applies to marketing and promotional messages, and transactional messages are excluded. Authentication and alignment still apply to them.

Is p=none really enough?

For meeting Gmail and Yahoo's requirements, yes. Both accept p=none as the minimum. It doesn't protect your domain from spoofing, though, so use the reports to move to a stricter policy over time.

Why does Postmaster Tools show no data for my domain?

Postmaster Tools only displays data once your domain sends enough daily volume to Gmail users. Low-volume senders often see empty dashboards, which doesn't mean anything is wrong.

Do subdomains count separately toward the 5,000 limit?

No. Google counts all messages from the same primary domain together, including subdomains.