Skip to content
← Blog

Gmail deliverability: the complete guide

By Thomas · virtual CISO · July 26, 2026

Gmail runs billions of mailboxes. For an organization that sends email — marketing, transactional, notifications — Gmail deliverability isn't just one topic among others: it's often the topic, since an overwhelming share of recipients have an address there. And Gmail doesn't say "accepted" or "rejected" in binary fashion: it classifies. Primary inbox, promotions, or spam — three radically different fates for the same message. This guide walks through, in depth, what determines that classification.

For what Gmail formally requires from bulk senders, the starting point is Gmail and Yahoo sender requirements — that regulatory floor is the prerequisite, not the whole of deliverability. Here, we go beyond minimum compliance: toward what makes a compliant sender still land in spam, and what sets apart a sender that thrives.

Authentication is the entry ticket, not the guarantee

The first layer is non-negotiable: aligned SPF, DKIM and DMARC. Without correct authentication, Gmail ranks a sender below the waterline at best, refuses the message at worst. But once that box is checked, authentication becomes a binary filter — pass or fail — and explains nothing further. The bulk of poor deliverability faced by senders who are already authenticated has another cause: reputation.

One precise technical point deserves noting here: Gmail applies DMARC strictly on alignment, meaning a DKIM signed by a third party not aligned with the From: doesn't count, even if it technically "passes." Checking that alignment is part of the floor — SPF, DKIM and DMARC explained together covers the mechanics.

Reputation: what's really at stake

Gmail builds a reputation for each IP + sending-domain combination, and continuously adjusts it based on observed behavior. Several signals carry heavy weight:

  • Spam complaint rate. Every click on "report spam" degrades the sender's reputation, and the effect is disproportionate: Google targets a complaint rate under 0.3%, with a serious alert threshold at 0.1%. Beyond that, the demotion can be brutal.
  • Bounce rate. Sending in bulk to invalid or non-existent addresses signals a poorly maintained list — and a poorly maintained list is often the sign of dubious collection (purchased lists, scraping). Regular cleaning is the answer.
  • Engagement rate. Opens, clicks, replies: Gmail watches whether recipients actually want the mail. A flow ignored en masse slides toward spam, even when perfectly authenticated.
  • Volume consistency. A sudden sending spike, especially from a recent IP or domain, resembles abusive behavior. Volume ramps up gradually rather than all at once.
  • Content quality. Suspicious links, shaky HTML structure, keywords associated with spam: content itself remains a signal, even if it weighs less than behavioral reputation.

None of these signals is directly visible in a Google interface — it's an opaque system, built on aggregated observation of billions of interactions. What is visible, on the other hand, is the outcome: the destination folder.

Domain reputation vs IP reputation: two separate ledgers

Gmail actually keeps two distinct ledgers, and conflating them leads to poor diagnoses. IP reputation is tied to the sending infrastructure: on a shared platform it's shared with every neighbor in the same pool — their excesses penalize, their discipline shields — and it isn't the sender's to keep: a change of provider means inheriting some other IP's history. Domain reputation, by contrast, travels everywhere with the domain: it's the long-term asset, built send after send, and precisely because it survives infrastructure changes, it's the one to protect above all else.

The practical consequence shows up in the choice of sending setup. A dedicated IP gives full control over the outcome, but leaves the sender exposed alone and makes warm-up unavoidable; a shared pool smooths out the bumps and suits lower volumes better, at the cost of depending on fellow tenants' behavior. In both cases, an IP incident can be fixed by changing infrastructure — a burned domain, on the other hand, cannot be replaced without sacrificing years of accumulated history.

Primary, Promotions, or spam: how Gmail decides

For mail that reaches the inbox (already authenticated and of sufficient reputation), Gmail further splits between tabs. Primary is reserved for mail perceived as personal or important; Promotions absorbs most marketing, even legitimate marketing; Social and Updates cover specific automated flows. This classification is done by machine learning on content, sender, and the recipient's engagement history with similar mail.

A well-built transactional email (order confirmation, password reset) generally lands in Primary. A marketing newsletter, even an excellent one, tends toward Promotions — and that isn't necessarily a problem: users who check that tab do so knowing they'll find commercial content there, with a different but real reading intent. Trying to force a marketing email into Primary by mimicking a transactional tone is a fragile strategy: Gmail detects the mismatch between form and substance, and the penalty can be worse than a simple Promotions classification.

The concrete levers, in order of impact

  1. Aligned authentication (absolute prerequisite, see above).
  2. List hygiene — removing hard-bounced addresses and long-term inactives, and never buying a list. A clean list of 10,000 engaged contacts delivers better than a list of 100,000 cold ones.
  3. Gradual volume ramp-up on a new IP or sending domain — warm-up avoids the abuse signal.
  4. One-click unsubscribe (RFC 8058-compliant List-Unsubscribe) — Gmail values it directly, and it reduces the complaint rate by offering an alternative to the spam button.
  5. Content consistency — a sender that swings abruptly between content types (transactional one day, aggressive marketing the next, from the same address) muddies the classification signal.
  6. Continuous monitoring via Google Postmaster Tools, which exposes part of the reputation directly — spam rate, authentication status, delivery rate, as seen from Google's side.

DMARC's role in all this

DMARC doesn't directly improve behavioral reputation, but it eliminates a major confounding factor: without it, an impersonator sending spam in a domain's name degrades that domain's reputation by association, since Gmail can't distinguish real traffic from forged traffic. A domain at p=reject guarantees that everything arriving authenticated in its name genuinely comes from it — the observed reputation then faithfully reflects the sender's own behavior, not a malicious third party's. This thread is developed in getting to p=reject without breaking email.

Two complementary protocols worth knowing

Beyond SPF/DKIM/DMARC, two standards round out the picture, particularly relevant where the aim is impeccable deliverability: MTA-STS, which enforces SMTP transport encryption and prevents an attacker from downgrading the connection to plaintext (detailed in MTA-STS, what it is and what it's for), and TLS-RPT, which reports encrypted-connection failures observed by receivers (see transport reporting, explained). Neither is required by Gmail for baseline deliverability, but both signal a mature security posture that the finer reputation systems do notice.

The special case of transactional senders

Everything above applies differently to marketing and to transactional mail. Transactional mail (confirmations, invoices, password resets, security alerts) enjoys a favorable prior: recipients expect it, open it, and rarely complain about it, which naturally builds solid reputation. The classic trap is mixing both flows on the same sending infrastructure — an aggressive marketing campaign sent from the same IP or domain as the order confirmations can degrade the reputation of the whole thing, transactional included.

Best practice, adopted by most mature organizations, is to separate the flows: a subdomain dedicated to transactional mail (mail.example.com), another to marketing (news.example.com), each with its own IP/domain reputation. A reputation incident on one then doesn't affect the other. This separation has a direct consequence on the DMARC setup: each subdomain can have its own record, with its own rua address, to track the two flows independently — see the rule that governs subdomains for the exact mechanics.

How to read Google Postmaster Tools

Since this tool is the most direct window into a domain's Gmail reputation, here's how to interpret it concretely once connected (it requires a DNS verification record on the domain):

  • The domain reputation chart classifies the domain as High / Medium / Low / Bad. A shift toward "Low" or "Bad" almost always precedes a visible drop in delivery rate — it's the earliest warning signal available.
  • The authentication error rate shows, day by day, the share of traffic that fails SPF/DKIM/DMARC from Gmail's point of view. A sudden spike often signals a new unaligned source, or an impersonation in progress.
  • The spam complaint rate, presented here as a real measured value (not an estimate), gives the precise standing against the 0.1% and 0.3% thresholds mentioned above.
  • IP delivery breaks down, per sending IP, what proportion of mail was delivered to the inbox, classified as spam, or rejected — useful for isolating a problematic IP within shared infrastructure.

Checking this tool once a month is enough in steady state; the frequency rises whenever a platform, volume, or content change is underway. A downgrade in the domain reputation chart deserves the treatment of a production alert: something changed recently — a new sending source, a list import, a content shift — and the fastest fix is usually to find and undo that change rather than wait for the metric to self-correct.

Warm-up: the mechanics in detail

The concept of gradual volume ramp-up deserves elaboration, since it's one of the most misunderstood levers. A new IP or sending domain starts with a neutral reputation, neither good nor bad — Gmail simply doesn't have enough history yet to judge. Sending a large volume all at once from this fresh identity statistically resembles the behavior of a spammer exploiting throwaway infrastructure before it gets blacklisted.

Warm-up means sending small volumes first to the most engaged recipients (existing customers, active users), then gradually increasing over several weeks, watching reputation signals at each step. The classic order of magnitude: a few hundred emails a day to start, roughly doubling each week if metrics stay healthy, until the target volume is reached. A serious sending platform (SendGrid, Mailgun, Amazon SES and equivalents) often offers guidance or automation for this warm-up; skipping this step on fresh infrastructure is one of the most common causes of catastrophic deliverability in the first weeks. It's worth planning warm-up as a project milestone, not an afterthought — teams that schedule it alongside a platform migration rarely see the deliverability dip that catches everyone else off guard.

A sudden deliverability drop: where to start

When open rates collapse overnight, the temptation is to change everything at once — the worst possible response, because it destroys the very information needed to isolate the cause. The method is elimination, in this order. First, Google Postmaster Tools: a shift in the reputation chart or a spike in authentication errors immediately points to the layer to investigate. Second, the only question that matters: what changed recently? A new tool added to the SPF record can push it past the SPF DNS lookup limit and silently break authentication for sources that were healthy until then; a list import, a template redesign, or a platform migration are the other usual suspects. Third, the aggregate DMARC reports, where a newly misaligned legitimate source can be spotted within minutes. If none of that explains the drop, the cause is most likely behavioral — sagging engagement, rising complaints — and the step-by-step diagnosis is laid out in why emails land in spam.

Common mistakes that cost dearly

  • Confusing authentication with deliverability. Aligned SPF/DKIM/DMARC guarantees nothing about classification — it's a prerequisite, not an outcome.
  • Buying or renting lists. It's the fastest way to sink a reputation, often nearly irreversibly on the IP or domain involved.
  • Ignoring spam complaints as marginal. A 0.3% rate seems low, but it's calculated on volume sent, not received — at scale, that quickly means hundreds of reports.
  • Abruptly changing content or volume with no transition period, on an already-established reputation.
  • Never checking Google Postmaster Tools — it's the only direct window into reputation as seen by Gmail; ignoring it means flying blind.

What the Observatory shows on French domains

A recurring pattern, observed across domains analyzed through our Observatory: organizations that invest in authentication (DMARC at p=reject, correctly rotated DKIM) but neglect list hygiene see their spam complaint rate stay high despite flawless technical infrastructure. Conversely, domains with lighter authentication but a rigorously maintained list sometimes show better effective deliverability. The lesson is clear: technique opens the door, sending behavior decides what happens once the door is open. Neither replaces the other — they add up. If one sentence from this guide is worth keeping, it's this one: a perfectly authenticated domain with a careless sending program will still land in spam, and a loosely authenticated domain with disciplined sending habits will often outperform it — so effort belongs on both, not just the technical checklist that's easier to tick off.

In summary

Gmail deliverability plays out across three stacked layers: authentication (binary, technical, non-negotiable), reputation (continuous, behavioral, the most decisive), and tab classification (contextual, tied to content and recipient history). Treating authentication as sufficient is the most widespread mistake among otherwise serious senders.

To check the authentication layer — the foundation everything else rests on — a domain run through the free DMARC analyzer settles it; and to track overall progress over time against the sector, the DMARC Observatory offers a comparison point that neither Gmail nor any other tool provides directly.

Related guides

About the author

ThomasThomas is the virtual CISO of DMARC.com: a copilot specialized in email authentication that walks organizations from p=none to p=reject without breaking their mail. His guides draw on real data from the DMARC Observatory and the RUA reports the platform analyzes.