What causes Gmail TempFail errors and how to troubleshoot them?
Published 5 Jul 2025
Updated 20 Oct 2026
15 min read
Summarize with
Updated on 20 Oct 2026: We clarified Gmail TempFail retry handling and SMTP sign-in errors, and corrected the bulk-sender requirements.
Gmail TempFail errors are temporary SMTP 4xx failures, often called soft bounces in sending reports. Gmail is telling your SMTP server to queue the message and try again later; rate-related replies also require slower sending. The most common causes are rate limiting, low IP or domain reputation, failed SPF or DKIM, missing or mismatched rDNS and PTR, temporary DNS failures, Gmail system load, recipient receiving limits or full mailboxes, suspicious content or URL signals, missing TLS, and unmet bulk-sender requirements such as DMARC alignment.
Troubleshooting starts with the SMTP transcript or MTA log, then matches that evidence to authentication, reputation, and sending-rate signals. For a real-message check during the investigation, send a controlled sample through the email tester and compare the resulting authentication headers with Gmail's reply. A sample sent through a different IP or signing configuration does not verify the deferred stream.
Direct answer
A Gmail TempFail is normally a retryable delivery event. Your SMTP server should keep the message in the queue, use exponential backoff, and reduce Gmail concurrency for rate-related failures. A later permanent rejection or expiry of the queue lifetime can produce a final non-delivery report. A 4xx reply does not guarantee eventual delivery.
Why Gmail returns TempFail
Gmail uses temporary failures when it wants the sender to retry later or change behavior before trying again. The word TempFail covers several SMTP replies, so the exact cause depends on the enhanced status code and text attached to the event. Google documents many examples in its Gmail SMTP codes, including rate limits, authentication failures, PTR issues, TLS requirements, timeouts, and server-busy conditions.
- Rate pressure: Gmail sees an unusual volume pattern by IP, netblock, DKIM domain, SPF domain, URL domain, Message-ID, or recipient account.
- Authentication failure: SPF or DKIM does not pass, or bulk mail lacks a DMARC record, a DMARC policy, or alignment with the visible From domain.
- DNS weakness: The sending IP has no PTR record, forward DNS does not match, or Gmail encounters a temporary DNS lookup failure.
- Reputation signal: Gmail does not trust the IP, domain, content, or link domain enough to accept the current rate.
- Recipient limit: A recipient receives messages too quickly or has no storage left, even when the wider sending pattern looks normal. Workspace relay quotas can also produce temporary failures.
|
|
|
|---|---|---|
421 4.7.28 | Unusual rate | Full reply naming the affected IP or domain, then queue growth |
421 4.7.30 | DKIM did not pass | Actual DKIM selector and signature on the failed stream |
421 4.7.27 | SPF did not pass | Connecting IP and envelope sender SPF result |
421 4.7.29 | TLS missing | TLS negotiation in the SMTP transcript |
421 4.7.32 | DMARC alignment | Visible From domain and the passing SPF or DKIM domain |
421 4.7.40 | DMARC record or policy | DMARC TXT record and valid p= policy |
451 4.7.23 | PTR issue | PTR hostname and its forward A or AAAA records |
450 4.2.1 | Recipient rate or relay quota | Full reply: recipient receiving rate or Workspace relay quota |
451 4.7.26 | Temporary DNS failure prevents authentication | DNS response errors for the domains named in the reply |
452 4.2.2 | Recipient storage exhausted | Ask the recipient to free account storage |
421 4.4.5 | Gmail server busy | Queue and retry with backoff |
Common Gmail temporary SMTP signals. Read the full reply because one code can describe different causes.
Where the error appears in SMTP
Gmail can return a temporary reply at connection setup, during RCPT TO recipient handling, or after the message body is sent at the end of DATA. The stage matters: a RCPT TO deferral affects that recipient, while a temporary reply after DATA defers the message for the recipients accepted in that transaction. Content checks require the message body; recipient checks can happen earlier.
Abbreviated Gmail TempFail examples, retain the full reply in your logstext
421 4.7.28 Gmail has detected an unusual rate of email. 421 4.7.30 DKIM authentication did not pass. 451 4.7.23 Sending IP has PTR or forward DNS issues. 450 4.2.1 Recipient is receiving email too quickly.
When the MTA receives a 4xx delivery reply, it should keep the deferred recipients in queue and retry with exponential backoff. A 421 reply closes the connection, so a later retry needs a new connection. A final 250 reply after DATA means Gmail accepted the message; do not resend it solely because QUIT or connection shutdown later fails. Spreading attempts over longer intervals prevents a retry storm. Immediate resends repeat the traffic pattern that triggered the TempFail and can prolong rate limiting.
Healthy sender behavior
- Queue handling: The message stays queued after a 4xx reply.
- Retry policy: Backoff increases after repeated Gmail deferrals.
- Traffic control: Gmail concurrency and rate are reduced quickly.
Risky sender behavior
- Bounce handling: A temporary reply is treated as a hard bounce.
- Retry policy: Retries happen too fast after Gmail says wait.
- Traffic control: All Gmail traffic keeps flowing at the same rate.
Illustrative queue evidence, field names depend on the MTAtext
status=deferred remote=gmail-smtp-in.l.google.com reply=421 4.7.28 Try again later queue_id=ABC123 retry_delay=15m
Troubleshoot Gmail SMTP sign-in failures
If an app fails while signing in to smtp.gmail.com, investigate SMTP authentication separately from delivery to Gmail recipients. A 454 4.7.0 reply during AUTH indicates a temporary sign-in problem or too many sign-in attempts. Google distinguishes these replies in its SMTP error reference. SPF and DKIM do not control account sign-in.
- Check the connection settings. For smtp.gmail.com, use port 587 with STARTTLS or port 465 with implicit TLS, and the full Gmail or Workspace email address as the username.
- Use OAuth 2.0 when the application supports it. For a client that cannot use OAuth, an app password requires 2-Step Verification and an account whose security settings permit app passwords. A normal account password is not a substitute.
- Back off after 454 4.7.0 instead of looping through sign-in attempts. For a Workspace SMTP relay, reuse authenticated connections where supported rather than authenticating again for every message.
- Treat a 535 username/password rejection as an account authorization problem. Correct the credentials or OAuth authorization before trying the same request again; changing SPF or DMARC will not fix SMTP AUTH.
Gmail account sending quotas are separate from inbound delivery throttling. An app password does not increase those quotas; use the full reply to identify which limit is affected.
Why reports and logs disagree
Gmail Postmaster Tools can show a high TempFail rate when the first sending log has no matching deferrals. Its Delivery errors dashboard measures temporary failures and rejections among SPF- or DKIM-authenticated messages sent to personal Gmail accounts. Compare that scope with your logs before comparing percentages; forwarded or replayed messages can generate errors on infrastructure you do not operate.
Postmaster Tools uses UTC and is not real time: data typically updates within 24 hours, sometimes longer. Low-volume days can have incomplete data for privacy reasons. A blank dashboard does not establish that delivery succeeded.
Example Gmail Postmaster Tools delivery errors with rate limit and authentication failures.
- Different log path: A connection-level refusal can be logged by the MTA, load balancer, NAT gateway, or egress firewall. This explains local delivery gaps, but a failure before authentication does not by itself explain an authenticated-message dashboard spike.
- Domain-based reporting: Gmail reporting can group by a domain identity, while SMTP logs are grouped by server, IP, campaign, or visible From address.
- Envelope sender gap: Traffic can use a domain in the SMTP MAIL FROM value without using it in the visible From header, so a search limited to visible From values can miss it.
- Replay traffic: A valid DKIM-signed message can be resent through other infrastructure if the signed fields still verify, creating domain reputation signals absent from the sender's own logs.
- Forwarded mail: A recipient can forward your message back to Gmail. The forwarding server receives the later deferral, so it is absent from your outbound SMTP logs.
Do not trust one dashboard alone
When Gmail reporting and SMTP logs disagree, map the same date range across queues, connection logs, bounce logs, authentication reports, NAT egress IPs, and sender domains before changing DNS or pausing mail.
How to troubleshoot Gmail TempFail errors
The fastest path is to prove whether Gmail is deferring the mail, refusing the connection before SMTP, or reporting a domain signal generated elsewhere. This order separates operational fixes from authentication fixes.
Gmail TempFail troubleshooting steps: check SMTP logs and queues, verify authentication, reduce sending rate, and monitor recovery.
- Find the SMTP reply: Search for Gmail MX hosts, status deferred, and 4xx replies across all sending nodes. Retain the timestamp and time zone, remote MX, sending IP, queue ID, affected recipient, SMTP stage, enhanced status code, and complete reply text.
- Check connection logs: If delivery logs are clean, inspect connection setup failures, timeouts, firewall denies, and local MTA-generated errors.
- Group by identity: Break the problem down by IP, HELO name, envelope sender, visible From domain, DKIM d= domain, SPF domain, and URL domain.
- Verify authentication: Check SPF pass, DKIM pass, and DMARC domain alignment for the exact deferred stream. If it has no delivered sample, combine the SMTP transcript with its sending IP, DNS records, and signing configuration; a rejected message has no recipient-side headers to inspect.
- Reduce pressure: Lower Gmail concurrency, reduce per-recipient rate, separate bulk mail by engagement, and stop immediate retries.
- Watch recovery: Track deferred counts, oldest queue age, accepted rate, and complaint rate as sending resumes. Review Postmaster Tools signals over the following days and allow for reporting delays.
For broad DNS and authentication checks, the domain health checker checks DMARC, SPF, DKIM, and related records in one place. When the reply names SPF, validate the record with the SPF checker before editing DNS.
If temporary failures persist after the named faults are fixed, preserve representative full replies and queue IDs for escalation. Ask the sending provider to inspect shared IP activity, or report a delivery issue in Postmaster Tools when the domain is verified and meets Gmail's sender requirements.
Authentication checks that matter
A TempFail that mentions SPF, DKIM, DMARC, or unauthenticated mail needs message-level evidence. Testing only the domain's DNS records is not enough. Gmail judges the message it received, including the connecting IP, envelope sender, visible From header, DKIM selector, and signature body hash.
Illustrative DNS records, replace placeholders before publishingdns
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:d@example.com" example.com. TXT "v=spf1 include:_spf.example.net -all" s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=BASE64KEY"
DMARC monitoring matters because Gmail TempFail events can sit beside a wider identity problem. A sender can have a valid DNS record while one stream fails because it uses a different return-path domain, a stale DKIM selector, an unapproved sending IP, or a path that exceeds SPF's 10 DNS-lookup limit. Suped's DMARC monitoring workflow connects those source-level details to specific remediation steps.
Common mistake
A 100% DMARC pass rate covers only the messages in those reports. A DMARC pass requires a passing SPF or DKIM result with DMARC alignment; it does not prove that both passed or that every deferred SMTP attempt appears in the reports.
For DKIM-related Gmail errors, check the selector used by the failed stream, not only the expected selector. A provider migration can leave one stream signing with an old selector while the main marketing or transactional mail remains clean. For PTR-related replies, verify that the actual sending IPv4 or IPv6 address resolves to a hostname whose A or AAAA record includes that address. Request PTR changes through the IP owner or hosting provider.
Meet Gmail's sender requirements
Gmail's published sender requirements apply to mail delivered to personal accounts ending in @gmail.com or @googlemail.com. Google Workspace recipient domains can also apply tenant policies and receiving limits, so confirm whether the deferred recipient is a personal Gmail account or a Workspace account before treating every TempFail as the same policy problem.
- All senders: Use SPF or DKIM, valid forward and reverse DNS, TLS for SMTP, and RFC 5322 message formatting.
- Bulk senders: Google classifies senders reaching close to 5,000 messages or more to personal Gmail accounts within 24 hours as bulk senders, counting the primary domain and its subdomains together. This status is permanent once reached. Use SPF and DKIM, publish DMARC with at least p=none, and ensure DMARC alignment between the visible From domain and a passing SPF or DKIM domain for direct mail.
- Subscription mail: Bulk marketing and subscribed messages need RFC 8058 one-click unsubscribe using List-Unsubscribe and List-Unsubscribe-Post headers, plus a visible unsubscribe link in the body. Honor unsubscribe requests within 48 hours.
- Spam rate: Keep the Gmail Postmaster Tools spam rate below 0.3%. Google's guidance recommends staying below 0.1% and avoiding 0.3% or higher.
Requirements are not a rate guarantee
Meeting every published requirement does not guarantee a fixed acceptance rate. Gmail also evaluates sending history, recipient feedback, content, shared IP activity, sudden volume changes, and the identity named in the SMTP reply.
How to reduce TempFail quickly
For rate-related TempFail errors, the short-term fix is to send more slowly to Gmail. Authentication failures, DNS errors, and full recipient mailboxes need the specific fix named in the reply. Apply throttling while correcting the underlying fault, and monitor whether the queue clears before messages expire.
Gmail TempFail queue triage
Prioritize the age and growth of the deferred queue alongside the exact SMTP error. A low failure percentage still needs action when messages approach expiry.
Deferrals clearing
Queue age stable
Queued messages are accepted on later attempts and the backlog shrinks.
Backlog growing
Queue age rising
Reduce pressure for rate-related replies and investigate the named fault.
Messages nearing expiry
Delivery at risk
Escalate the fault and protect time-sensitive mail before retries end.
- Throttle Gmail first: Reduce concurrent connections and cap throughput by the affected sending IP and Google MX destination until the queue stops growing. Include Workspace recipient domains that share the affected Google MX destination, rather than limiting only addresses ending in @gmail.com.
- Protect engaged mail: Prioritize transactional and highly engaged recipients while pausing cold or low-engagement batches.
- Fix identity drift: Make sure each stream uses the correct envelope sender, DKIM selector, return path, HELO, and sending IP.
- Check reputation: Review complaint rate, spam placement, domain reputation, IP reputation, and blocklist (blacklist) status.
- Prevent retry storms: Do not re-inject the same deferred mail as new mail. Keep it in queue with controlled retry timing.
For 421 4.7.28
For 4.7.28 rate limits, Google recommends pausing affected Gmail sending for at least 10 minutes. Identify the IP, SPF domain, or DKIM domain quota named in the reply; if it names none, assume all three are affected. Restart with one connection. If it fails, wait another 10 minutes; if it succeeds, add connections one at a time while monitoring SMTP errors. This is a recovery test, not a guaranteed resolution time.
For further rate limit exceeded troubleshooting, reduce the burst and check the reputation signals associated with the identity in Gmail's reply. A clean blocklist check does not establish that Gmail trusts the sender.
Use Suped to investigate authentication failures
Suped is our DMARC reporting and email authentication platform. For Gmail TempFail investigations, use its DMARC source data, SPF and DKIM checks, and failure alerts to investigate the sending identity named in an SMTP reply. SMTP queue evidence and the full delivery response still come from the sending infrastructure.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
A practical Suped workflow is to add the domain, identify legitimate sending sources, check SPF and DKIM health, and use the issue view for remediation steps. Compare authentication failures with the affected stream and incident window before changing DNS. Apply sending-rate changes in the MTA or sending provider; DMARC reports do not contain Gmail's SMTP transcripts.
Best practical use
Use Suped to confirm which sources are legitimate, which ones fail authentication, which IPs or domains need reputation attention, and which TempFail-related fixes have been applied. This avoids simultaneous DNS and sending changes that make Gmail's response harder to attribute.
Views from the trenches
Best practices
Keep Gmail retry queues separate so rate limits do not delay mail to unrelated domains.
Track Gmail TempFail by IP, DKIM domain, SPF domain, URL domain, and recipient pattern.
Throttle Gmail traffic quickly, then rebuild volume after deferrals stay low for days.
Common pitfalls
Treating 4xx replies as final bounces drops retryable mail and suppresses valid recipients.
DMARC reports do not include every SMTP attempt or temporary connection failure in your logs.
Retrying too aggressively after a 421 reply can extend Gmail rate limiting instead.
Expert tips
Correlate Postmaster spikes with MTA queues before changing DNS or sender identity.
Check rDNS and forward DNS first when Gmail mentions PTR, IP reputation, or limits.
Use small Gmail cohorts during warmup so recipient-level pressure is easier to see.
Marketer view
Marketer from Email Geeks says a Gmail TempFail should usually appear as a 4xx deferral, often during recipient handling or after the message body has been sent, before final acceptance.
2023-11-28 - Email Geeks
Marketer view
Marketer from Email Geeks says sending too many messages to one Gmail recipient can trigger deferrals even when wider domain reputation looks healthy.
2023-11-28 - Email Geeks
