Why does an order confirmation the customer is waiting for still end up in spam? Because Gmail and Yahoo judge the sending domain on its authentication and its complaint rate. Transactional emails (order confirmations, password resets, invoices) sent automatically after a user action get no free pass: an unauthenticated domain, or a spam rate near 0.30% in Postmaster Tools, puts them at risk of the spam folder. Google asks senders to stay under 0.10%. This guide lists the settings to check, with the thresholds published by Google and Yahoo, reviewed in October 2026.
Why does an expected email land in spam?
A password reset goes through the same filters as a promotion: they weigh domain authentication, IP history, complaint volume and bounce rate. Four causes come up again and again. The domain is not authenticated. Marketing and transactional sends share one reputation, so a badly targeted campaign hurts your order confirmations. Forms accept fake or mistyped addresses, and every faulty signup produces a hard bounce. Finally, volume swings sharply from one day to the next, typically around Black Friday (November 28 in 2025).
The sections below follow the order in which these causes get fixed. The content of the message (subject line, layout) has its own article: the 5 essential practices for transactional emails.
What Gmail and Yahoo have required since 2024
Since February 1, 2024, every sender writing to Gmail must authenticate its domain with SPF or DKIM, publish a valid PTR record (reverse DNS), encrypt delivery with TLS and keep its spam rate under 0.3% in Postmaster Tools. Above 5,000 messages a day to personal Gmail accounts, SPF, DKIM and DMARC all become mandatory, with the From header domain aligned to the SPF or DKIM domain. Messages must also follow the RFC 5322 format. The DMARC policy can stay at p=none.
According to the Google sender guidelines FAQ, the 5,000 messages are counted per primary domain: 2,500 sends from example.com and 2,500 from promo.example.com add up to 5,000. Google counts every message from the same primary domain, transactional ones included. A separate subdomain isolates the reputation of each flow but does not lift the DMARC requirement.
“Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher.” (Google email sender guidelines)
Yahoo sets the same 0.3% limit since February 2024 and strongly recommends a rua tag in the DMARC record to receive reports (Yahoo Sender Hub). Yahoo’s Complaint Feedback Loop lets you track complaints once DKIM is in place.
SPF, DKIM, DMARC: the 3 DNS records to publish
These 3 protocols are published as TXT records in DNS and standardized in RFC 7208 (SPF, 2014), RFC 6376 (DKIM, 2011) and RFC 7489 (DMARC, 2015). SPF lists the servers allowed to send for your domain. DKIM signs each message with a key the recipient checks in DNS. DMARC says what to do when both fail and where to send the reports.
At your DNS host, create a TXT record on _dmarc.yourdomain.com with the value v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com and a TTL of 3600 seconds. Check the publication with dig TXT _dmarc.yourdomain.com. Let it run for 14 to 28 days, read the aggregate reports, then move to quarantine once all your legitimate sources pass. Jumping straight to reject silently cuts off a forgotten tool (CRM or billing).
One trap from the field: each sending tool adds its own include to the SPF record. RFC 7208 caps an evaluation at 10 DNS lookups, nested includes counted. Beyond that, SPF returns a permanent error and the check fails.
Separate subdomain, dedicated IP or shared IP
Use a separate subdomain in every case. A dedicated IP only pays off if your sending is steady. Split the flows from day one: notifications.yourdomain.com for transactional mail and news.yourdomain.com for marketing. Then check the IP’s PTR with the Dig tool in Google Admin Toolbox (toolbox.googleapps.com). Yahoo advises against sending marketing from the same IPs as transactional mail, because each IP carries its own reputation.
| Criterion | Transactional | Marketing |
|---|---|---|
| Trigger | User action (order, signup, forgotten password) | Sender’s decision (newsletter, promotion) |
| Recommended sending domain | notifications.yourdomain.com | news.yourdomain.com |
| One-click unsubscribe (RFC 8058) | Excluded from the Gmail requirement | Required for bulk senders |
| Gmail 5,000-message count | Counted per primary domain | Counted per primary domain |
| IP | Dedicated if volume is steady, otherwise a shared IP pool from a reputable provider | Separate from the transactional IP |
| Consequence of a block | Customers get no reset link and no invoice | A lost campaign |
With a few hundred messages a day and weekend pauses, a dedicated IP’s history stays thin: a shared pool well managed by a serious sending provider usually performs better. Also avoid using a company mailbox address as the application sender, and avoid “noreply” addresses nobody monitors. Google also asks senders not to spoof Gmail From headers: an application sending with a gmail.com address breaks that rule.
Warming up a dedicated IP without getting throttled
Google asks you to start with a low volume to engaged recipients, raise it gradually without doubling overnight, and watch server responses and the spam rate. Gmail typically rejects messages with the SMTP code 4.7.28 when it detects an unusual rate of unsolicited mail from the IP: cut the volume instead of retrying in a loop.
A practical tip for a transactional flow: route the most expected mails first (order confirmation, login link) through the new IP, then add secondary notifications in steps. IP warming for a dedicated IP usually takes several weeks, with daily steps you can monitor in Google Postmaster Tools.
One-click unsubscribe: transactional mail is excluded
Google reserves one-click unsubscribe for marketing and promotional messages, with a June 1, 2024 deadline for senders that already offered an unsubscribe link. It names password resets, reservation confirmations and form confirmations as examples of excluded transactional mail. For your newsletters, Google recommends processing each request within 48 hours. On the technical side, the List-Unsubscribe header is implemented following RFC 8058.
One nuance remains: the recipient decides what kind of message it is. An order confirmation carrying a promotional banner can be read as marketing and then reported as spam.
What matters in the message itself
Use a recognizable sender whose address accepts replies (why to ban noreply addresses). Write a subject line that states the event (“Your order #4821 is confirmed”), with a tracking link on your own domain.
Monitoring: the signals that come before the spam folder
Sender reputation rarely collapses all at once. 4 signals come first, and each deserves a weekly look.
Google Postmaster Tools comes first: it shows your domain’s spam rate on the Gmail side. Aim for under 0.10%. Since June 2024, a bulk sender above 0.30% is no longer eligible for mitigations, which only return after 7 consecutive days under that threshold (Google FAQ cited above). An internal alert at 0.20% leaves some margin.
Bounces come next. A hard bounce (nonexistent address) should trigger immediate removal of the address. A soft bounce (full mailbox, server unavailable) is retried a few times before giving up. Non-delivery reports (NDRs) give the exact code for each refusal: a 5.x.x code signals a permanent failure, a 4.x.x code a temporary one, following the enhanced SMTP status code standard. Gmail’s 4.7.28, seen earlier, belongs to the second family. Archive these codes by recipient domain to spot the one that is limiting you.
Blocklist presence counts too. Query your sending IP and domain against the main blocklists on a regular basis: a block often shows up there before it weighs on your statistics.
That leaves spam traps, addresses with no real user that anti-spam organizations monitor to catch sends to poorly maintained lists. They slip into old or imported lists. The remedy is list hygiene: remove inactive contacts and verify addresses before sending to filter out those that would bounce. Run a sample of your database through verification before your next big send: the share of invalid addresses shows up immediately.
The technical checklist before going live
- SPF published, a single TXT line, 10 DNS lookups at most.
- DKIM active on the sending domain, key tested.
- DMARC at p=none with a rua address, tightened after reading the reports.
- Separate subdomain for transactional mail, PTR and forward DNS consistent.
- Dedicated IP only if volume is steady, with a ramp-up plan.
- Delivery encrypted with TLS from the server or platform.
- No promotional content in purely transactional mails, which are exempt from the one-click unsubscribe requirement.
- Spam rate under 0.10% in Postmaster Tools, with an internal alert at 0.20% (rule of thumb).
- Hard bounces removed on first occurrence.
- Weekly check of blocklists and non-delivery reports.
- Addresses verified when a list is imported, and inactive contacts cleaned out.
- A real send tested by seed testing or with Mail-tester before every change of sending tool.
Frequently asked questions
My volume to Gmail is low: does this apply to me?
Yes, for the baseline requirements. Under 5,000 messages a day, DMARC is not mandatory; the other requirements still apply: SPF or DKIM authentication, TLS, PTR and a spam rate under 0.3%. The 0.10% bar applies to everyone.
How long does it take to rebuild a damaged reputation?
Google says improvements in spam rate take time to show up in rankings. Expect several weeks, as an estimate. A bulk sender becomes eligible for mitigations again after 7 consecutive days under 0.3% (rule in force since June 2024).
Does a Mail-tester score of 10/10 guarantee the inbox?
No. Mail-tester grades a message out of 10: this one-off test checks authentication and content for a single send, plus a pass of the IP through blocklists. It says nothing about sending history or how recipients behave at Gmail. Pair it with Postmaster Tools monitoring.
Can I send my transactional mail from a Gmail mailbox?
It is not suitable. A mailbox has no sending API and does not report bounces in a usable way. Go through a sending platform that signs with DKIM on your own domain.
How to check your setup in two minutes
To check your own setup, send a test message to a Gmail address, open the “Show original” menu and confirm that SPF, DKIM and DMARC all show PASS. The email deliverability guide extends this checklist to inbox placement.
