Gmail and Yahoo bulk sender requirements for your app emails

Gmail and Yahoo have applied stricter rules to bulk senders since February 2024. Google calls you a bulk sender if you send close to 5,000 or more messages to personal Gmail accounts in 24 hours. Bulk senders must:

• authenticate with SPF and DKIM, and publish a DMARC record (p=none is the minimum),
• make sure the visible From domain aligns with the SPF or DKIM domain,
• add one-click unsubscribe to marketing emails and honor opt-outs within two days,
• keep the spam complaint rate below 0.3%, and aim for under 0.1%.

Smaller senders still need SPF or DKIM, valid reverse DNS, TLS and a spam rate below 0.3%.

This article explains each rule as Google and Yahoo state it today, with links. It also covers what the rules mean for app emails like password resets and receipts, and a few launch problems we hit at LuneaMail that no rule mentions.

Who counts as a bulk sender

Google's sender guidelines FAQ defines a bulk sender as one that "sends close to 5,000 messages or more to personal Gmail accounts" within 24 hours. Two details in that FAQ matter for startups:

1. "Messages sent from the same primary domain count toward the 5,000 limit." Your app emails, newsletter and product updates all add up if they share example.com, even when they use different subdomains.
2. "Senders who meet the above criteria at least once are permanently considered bulk senders." One busy launch day is enough. You don't go back.

Yahoo's Sender Hub does not publish a volume number. Treat the bulk rules as your baseline from the first email. They are not hard to meet, and an early-stage SaaS can cross the line in a single launch.

The rules side by side

These are the requirements as Google's email sender guidelines and Yahoo's best practices state them on 24 October 2026.

Requirement	All senders	Bulk senders
Authentication	SPF or DKIM	SPF and DKIM
DMARC	Not required	Required; policy can be p=none
From alignment	Not required	From domain aligned with the SPF or DKIM domain
Forward and reverse DNS (PTR)	Required	Required
TLS connection	Required (Google)	Required (Google)
Message format	RFC 5322 (Yahoo also lists RFC 5321)	Same
Spam rate	Below 0.3%	Below 0.3%
One-click unsubscribe	Not required	Marketing and subscribed messages
Honor unsubscribes	Not stated	Within 2 days (Yahoo), 48 hours (Google)

A few terms. PTR (reverse DNS) maps the sending server's IP address back to a name. Your email provider handles PTR and TLS for you, so as a SaaS team you mostly own the other rows. Alignment means the domain people see in the From address matches the domain that passed SPF or DKIM. Yahoo says "relaxed alignment is acceptable", so mail.example.com can align with example.com. Google judges it at the organizational-domain level and only needs SPF or DKIM to align, not both.

Google adds one more DKIM detail: sending to personal Gmail accounts "requires a DKIM key of 1024 bits or longer". Any current ESP meets this.

If you haven't set up the records yet, our SPF, DKIM and DMARC setup guide walks through it with example DNS records.

What the rules mean for app emails

Your SaaS sends two kinds of email:

• Transactional: password resets, verification links, receipts, license keys, security alerts. One person triggered them.
• Marketing or subscribed: newsletters, product announcements, onboarding drips, promotions.

The authentication rules, the alignment rule and the spam-rate limit apply to both. The volume counts both too.

The unsubscribe rule is different. Google's FAQ says: "One-click unsubscribe is required only for marketing and promotional messages." It gives password resets and reservation confirmations as examples of transactional messages that don't need it. So your password reset email doesn't need an unsubscribe header. Your weekly product update does.

Be honest about the line. A "receipt" that is half promotion is a marketing email. If you're unsure, add the header. It costs nothing.

One-click unsubscribe (RFC 8058)

One-click unsubscribe means the mail app shows an "Unsubscribe" button next to your sender name. One click, no login, no "are you sure" page. It works through two email headers defined in RFC 8058:

List-Unsubscribe: <https://example.com/unsubscribe/one-click/abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The URL must be https. When the person clicks, their mail provider sends a POST request to it, with no cookies or login. Your server must unsubscribe them from that request alone. RFC 8058 says the URL should contain a hard-to-forge identifier, so use a unique token per recipient, not their email address in plain text.

Google also requires "a clearly visible unsubscribe link in the message body". The header and the link work together. Yahoo calls the RFC 8058 POST method "highly recommended" and asks you to honor unsubscribes within 2 days. Google recommends 48 hours.

According to Google's FAQ, a missing one-click header does not cause automatic rejection. But people who can't unsubscribe easily press "Report spam" instead, and that hurts the next rule.

Spam rate: aim for 0.1%, never reach 0.3%

The spam rate is the share of your emails that recipients mark as spam. Google says to "keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher". That is 1 complaint per 1,000 emails as a target, and 3 per 1,000 as the hard limit. Google calculates it daily. Yahoo calculates its rate "based on mail delivered to the inbox".

To watch your Gmail numbers, add your domain to Google Postmaster Tools.

What keeps the rate low:

• Email only people who signed up, and send what they signed up for.
• Make unsubscribing easier than reporting spam.
• Stop emailing addresses that bounce or complain. Automatically, forever.
• Don't judge engagement by open rates alone (see below).

Opens can lie

Apple Mail Privacy Protection loads every email automatically, including the tracking pixel. Those "opens" are not people reading. If you count them, inactive contacts look engaged and you keep emailing them, which pushes up complaints. When we built LuneaMail's analytics, we stored those opens separately as machine opens. We also stopped counting clicks on unsubscribe and other footer links as engagement. A click on "Unsubscribe" is not interest.

What happens if you don't comply

Google's FAQ says: "Starting November 2025, Gmail is ramping up its enforcement on non-compliant traffic." Enforcement is "gradual and progressive", and faster for new domains. In practice:

• Temporary errors (4.7.x): Gmail delays the message. The error code tells you which requirement failed.
• Permanent errors (5.7.x): the message is blocked.
• Messages may also go straight to spam.

If your spam rate spikes, Google only offers mitigation once it stays below 0.3% for 7 consecutive days. Microsoft announced its own requirements for high-volume senders to Outlook in 2025. Read that post too if many of your users have Outlook.com addresses.

The launch problem no rule mentions: your provider's plan

You can pass every rule above and still send nothing. This happened to us during LuneaMail's launch.

We sent through SendGrid. The account was on a free trial. The trial ended without us noticing, and SendGrid started refusing mail with a "Maximum credits exceeded" error. Every email stopped, including the ones that matter most: password resets and sign-up verification links. That means a new user can't confirm their account, and a locked-out user can't get back in.

Before launch, check:

• Your email provider's plan, its monthly and daily limits, and when any trial ends
• What happens at the limit: a hard stop or overage billing
• An alert when sending fails, not just when the provider emails you
• That a password reset and a sign-up email arrive in a real Gmail and Yahoo inbox

From the LuneaMail team: When you build your own email sending, you also take on the job of making sure it actually gets delivered. Authentication, unsubscribes, spam rates and your provider's limits all become your problem, and you usually find a gap only when someone doesn't get an email they were waiting for. That's a huge undertaking for a team that just wants to send a few branded emails, and a large part of why we built LuneaMail.

Common mistakes

• Sending from @gmail.com through an ESP. Google's guidelines say "Don't impersonate Gmail From: headers" and point to Gmail's DMARC quarantine policy. Use an address on your own domain.
• Unsubscribe link with no header. The body link alone doesn't give the one-click button.
• An unsubscribe page that needs a login. It is not one click, and people report spam instead.
• Treating onboarding drips as transactional. If it promotes features or upgrades, it's marketing.
• Not suppressing bounces and complaints. Every repeat send to a complainer adds to your spam rate.
• Trusting open rates. Apple's automatic opens make dead lists look alive.

How LuneaMail handles this

We built these rules into LuneaMail's send path, so a campaign can't go out without them:

• Every campaign and automation email carries List-Unsubscribe and List-Unsubscribe-Post: List-Unsubscribe=One-Click headers, plus a visible unsubscribe link in the footer.
• The footer includes your postal address. LuneaMail won't send a campaign until you add one in Settings › Brand kit.
• From addresses at free mailbox providers like Gmail, Yahoo or Outlook are refused for campaigns. You send from your own domain, which you can authenticate in Settings › Domains.
• The workspace owner must confirm their email address before sending to a list.
• Unsubscribes, bounces and spam complaints are suppressed automatically.
• Apple's automatic opens are counted as machine opens, not real opens, and footer-link clicks don't count as engagement.

App emails like receipts and license keys go through the same authenticated domain with the transactional email API. See the features page and the developer docs for details.