Gmail Sender Guidelines & Bulk Sender Rules

Google’s sender guidelines took effect on February 1, 2024 and they split the world in two: every sender to Gmail has a baseline to meet, and anyone sending more than 5,000 messages per day to Gmail accounts has a stricter set on top. This page covers both, with the exact thresholds Google publishes.

One scope note first, because it trips people up: these rules govern personal Gmail accounts ending in @gmail.com or @googlemail.com. Google Workspace (work/school) recipients are not governed by this particular document.

The 60-second version

• Effective February 1, 2024. TLS for transmission was added in December 2023.
• All senders need at least SPF or DKIM, valid forward and reverse DNS (PTR), TLS, and a message that follows RFC 5322.
• Bulk senders (5,000+ messages/day) need both SPF and DKIM, a published DMARC policy (minimum p=none) that is aligned, and one-click unsubscribe (RFC 8058) on marketing and subscribed mail.
• The spam-complaint number is the one that bites: keep it below 0.10% in Postmaster Tools and never reach 0.30% or higher.
• DKIM keys must be at least 1024 bits; Google recommends 2048.

Who counts as a bulk sender

Google’s line is explicit:

“If you send more than 5,000 messages per day to Gmail accounts, follow the Requirements for sending 5,000 or more messages per day.”

The 5,000 is counted against Gmail accounts, per day. It is not a safe harbor - the all-sender requirements below are still expected of everyone - but crossing it puts you under the stricter set, and crossing it even briefly can trigger the bulk classification.

Requirements for all senders (from Feb 1, 2024)

Requirement	Rule
Authentication	At least SPF or DKIM set up for the sending domain
PTR / reverse DNS	Valid forward and reverse DNS; the sending IP must match the PTR hostname’s IP
TLS	Required for transmitting email (added December 2023)
Spam rate	Keep spam rates reported in Postmaster Tools low (see the threshold section)
Message format	Follow RFC 5322
No From: impersonation	Do not impersonate Gmail From: headers; Gmail enforces with DMARC quarantine

The PTR detail people miss

Google is specific about reverse DNS, and it is a two-way check:

“The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname… The same hostname must also have an A (for IPv4) or AAAA (for IPv6) record that resolves to the same public IP address used by the sending server.”

“The sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record.”

In plain terms: IP → PTR hostname, and that hostname → back to the same IP. A PTR that points to a hostname with no matching forward record fails.

Requirements for bulk senders (5,000+/day, from Feb 1, 2024)

Requirement	Rule
SPF	Required (both SPF and DKIM)
DKIM	Required; key minimum 1024 bits, 2048 recommended
DMARC	Required; minimum p=none is acceptable
DMARC alignment	From: domain must align with the SPF domain or the DKIM domain for direct mail
PTR / reverse DNS	Same as the all-sender requirement
TLS	Required
Spam rate	Keep it below 0.10%; never reach 0.30% (see below)
Message format	Follow RFC 5322
One-click unsubscribe	Required for marketing and subscribed messages

DKIM key length, quoted

“Sending to personal Gmail accounts requires a DKIM key of 1024 bits or longer. For security reasons, we recommend using a 2048-bit key if your domain provider supports this.”

The spam rate is the number that matters

This is the load-bearing threshold, so here is Google’s exact wording:

“Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher.”

“Maintaining a high spam rate leads to increased spam classification.”

Read as two distinct lines:

• 0.10% is the target. Stay under it and you are in good standing.
• 0.30% is the ceiling you must never touch. Reaching it leads to increased spam classification.

The rate is measured by Google Postmaster Tools, not by your own sending logs, which is why monitoring there is effectively mandatory.

One-click unsubscribe (RFC 8058)

For bulk senders, one-click unsubscribe is required on marketing and subscribed messages. It is implemented with two headers (RFC 2369 plus RFC 8058):

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

When the recipient clicks unsubscribe in Gmail, Google sends an HTTP POST to your List-Unsubscribe URL with the body List-Unsubscribe=One-Click. Your endpoint must accept that POST and process the opt-out without requiring the recipient to log in or take a second step. Google’s published guidance on this page does not state an explicit honor-timeframe SLA.

Google Postmaster Tools

Postmaster Tools (postmaster.google.com) is where Google exposes the data you are accountable for: spam rate, domain and IP reputation, authentication results, and delivery rates. Because the spam-rate thresholds are defined in terms of “spam rates reported in Postmaster Tools,” you cannot manage to them without monitoring there.

Gmail-specific SMTP errors worth recognizing

These are the codes Gmail returns when an authentication or reputation rule is in play:

4.7.28        Quota exceeded (DKIM, SPF, or IP quota)
5.7.26        Message does not pass authentication (DMARC-related)
421 4.7.0     Sending IP not on the allowed list
550 5.7.1     IP on suspended list
550-5.7.1     IPv6 PTR record missing / IPv6 guidelines violation

Note the IPv6 case: sending over IPv6 without a valid PTR is a hard 550-5.7.1, stricter than the IPv4 path.

Connection and quota behavior

Google publishes rate guidance worth knowing during a ramp or an incident:

“After 10 minutes, send emails from a single connection. If the single connection fails, wait another 10 minutes. If successful, increase the number of connections one at a time until your desired number of connections are established.”

And on how quotas are scoped:

“DKIM and SPF quotas are specific to your domain… The IP address quota is shared for all senders that use that IP address.”

That last point is the argument against shared IP pools: an IP-level quota is shared with every other sender on the same address, so their behavior affects your throughput.

Common mistakes

• Publishing p=none and treating DMARC as done. p=none is the minimum that satisfies the requirement; it does not stop spoofing. It is the floor, not the goal.
• One-click unsubscribe link in the body only. Bulk senders need the List-Unsubscribe / List-Unsubscribe-Post headers and a working POST endpoint, not just an in-body link.
• Ignoring the 0.10% target until 0.30% is near. By the time you reach the ceiling, classification has already shifted. 0.10% is the line to manage to.
• Sending over IPv6 without a matching PTR. That is the 550-5.7.1 path - cleaner to fix before you turn on IPv6.
• Not opening Postmaster Tools. The thresholds are defined by what Postmaster Tools reports; without it you are flying blind on the one number that matters.

What Egressif does

We meet Google’s bulk-sender bar as a matter of setup, not scramble: both SPF and DKIM published and aligned on your domain, DKIM at 2048 bits, DMARC published and watched, and one-click unsubscribe (RFC 8058) wired with a real POST endpoint on every marketing and subscribed stream. The sending IPs carry valid forward and reverse DNS that match, and we send over TLS. Because we run on owned infrastructure rather than a shared pool, the IP-level reputation and quota Google describes are ours to keep clean rather than something a neighbor can spend. We watch the spam rate in Postmaster Tools so a climb toward 0.10% is a signal we act on well before 0.30% is in sight. We do not promise an inbox - Google’s own guidance is that authentication proves accountability, and reputation and engagement decide placement.