How to fix Gmail errors for SPF authentication, unauthenticated senders, and PTR records?
Updated on 21 Oct 2026: We corrected Gmail error-code explanations and added practical checks for authentication and reverse DNS failures.
Treat each Gmail error as a separate signal. For SPF authentication failures, make sure the sending IP is authorized by the envelope sender domain's SPF record and that the record stays within the 10 DNS lookup limit. For unauthenticated sender blocks, read the full response and check SPF, DKIM, and any applicable DMARC policy. Bulk senders need SPF, DKIM, and DMARC, with one passing authentication method meeting DMARC's domain-matching rules for the visible From domain. For PTR errors, ask the IP owner to publish reverse DNS, then confirm that the PTR hostname points back to the same sending IP.
Do not start by assuming Gmail has a global incident. Gmail's messages usually identify the failing layer: SPF, combined authentication, or reverse DNS. An isolated failure on otherwise healthy traffic can result from a transient DNS or network resolution issue. A repeatable pattern by sending IP, envelope sender, hostname, or provider points to a configuration problem that needs a fix.
The three Gmail signals
These examples point to different layers. SPF checks sender authorization, the unauthenticated sender response reports the combined authentication result, and PTR errors concern sending infrastructure.
Common Gmail errors
421-4.7.27 SPF authentication didn't pass 421-4.7.26 This email has been rate limited because it is unauthenticated 451-4.7.23 The sending IP does not have a PTR record
What each Gmail error means
Gmail separates temporary deferrals from permanent rejections. SMTP replies beginning with 4 leave the message queued for retry; use increasing retry delays and correct the reported problem. Replies beginning with 5 are permanent failures for that delivery attempt. Correct the cause before submitting a new message.
Google's sender guidelines require all senders to use SPF or DKIM, and bulk senders to use SPF, DKIM, and DMARC. The SMTP error guide lists SPF, unauthenticated sender, suspicious SPF, and PTR failures as authentication or infrastructure problems.
These requirements apply when sending to personal Gmail accounts. Google treats a primary domain as a bulk sender after it sends close to 5,000 messages in a 24-hour period, with subdomain traffic counted together. Bulk sender status does not expire. Google began ramping up enforcement against non-compliant traffic in November 2025, including temporary and permanent rejections. Google documents the threshold and permanent classification in its sender guidelines FAQ.
|
|
|
|---|---|---|
421 4.7.27 or 550 5.7.27 | SPF failed | Authorize the source |
421 4.7.26 | No SPF or DKIM pass | Fix SPF or DKIM |
550 5.7.26 | Unauthenticated sender, SPF hard fail, or DMARC rejection | Follow the complete diagnostic |
451 4.7.26 | DMARC authentication blocked by temporary DNS failures | Check DNS resolution and retry |
421 4.7.32 | From domain does not match a passing SPF or DKIM domain | Check DMARC alignment and custom sending domains |
451 4.7.24 or 550 5.7.24 | Suspicious SPF entries | Audit the SPF record |
451 4.7.23 or 550 5.7.25 | PTR missing or mismatched | Fix reverse and forward DNS |
Read the Gmail code and complete diagnostic together to choose the first fix.
A small number of these errors on high-volume traffic does not prove the entire sending setup is broken. Check the rate and clustering. An isolated failure can result from a transient resolver or route issue. A spike on one IP, sending domain, or mail stream needs investigation.
Read Gmail's authentication results
In Gmail on the web, open a delivered test message, click More beside Reply, and choose "Show original". Google's header instructions show the steps. Inspect the Authentication-Results header added by mx.google.com. For rejected mail, use the complete bounce and the sending server's SMTP logs; there is no delivered Gmail copy to inspect.
Simplified header example: SPF fails while DKIM and DMARC passtext
From: sender@example.com Return-Path: <bounce@bounce.example.com> Authentication-Results: mx.google.com; spf=fail smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com header.s=s1; dmarc=pass header.from=example.com
Here, repair SPF at bounce.example.com. The passing DKIM domain matches the visible From domain, so DMARC passes. A bulk sender must still repair SPF. If both methods pass but DMARC fails, check the authenticated domains against the From domain.
|
|
|---|---|
none | Missing SPF record or an unusable sender domain |
fail or softfail | The connecting IP did not obtain an SPF pass |
temperror | A transient evaluation error, usually DNS |
permerror | Invalid syntax, multiple SPF records, or exceeded lookup limits |
Fix Gmail SPF authentication failures
For 421-4.7.27 or 550-5.7.27, the failing domain is usually the envelope sender domain, also called MAIL FROM or Return-Path. The visible From address matters for DMARC, but SPF checks the connecting IP against the domain used in the SMTP envelope. When MAIL FROM is empty, SPF uses the HELO or EHLO domain instead.
Check the exact IP in the bounce, then verify whether that IP is covered by the SPF record for the domain named in Gmail's authentication result. A clean SPF record has one v=spf1 TXT record, includes every legitimate sender, avoids broad mechanisms that authorize too much, and ends with a policy that matches the rollout stage.
- Find the domain: Read the Gmail authentication result and identify the SPF domain it checked.
- Add the sender's approved include or the actual public outbound IP range. Authorize Google's servers only when Google sends that mail.
- Remove conflicts: Publish only one SPF TXT record at the domain.
- Count DNS-querying terms across the full evaluation path, including nested includes, and keep the total at 10 or fewer.
- Test the change: Send a new message and confirm Gmail reports SPF as pass.
The ip4 and ip6 mechanisms do not consume the 10-term limit. Adding SPF's discouraged ptr mechanism does not create reverse DNS. The SPF specification defines these limits.
Simple SPF example
example.com. 3600 IN TXT "v=spf1 ip4:203.0.113.25 -all"
The example uses a documentation IP address; replace it with your actual outbound IP before publishing. If the record is already long, do not keep stacking includes until Gmail stops rejecting mail. Check the record with the SPF checker, then decide whether it needs cleanup, sender removal, or managed flattening.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
For teams with many senders, Suped's Hosted SPF provides a central authorized-sender list, keeps the published record short, and tracks changes that might otherwise create an SPF lookup failure.
Fix suspicious SPF entries
Gmail uses 451-4.7.24 for a temporary rate limit and 550-5.7.24 for a permanent block when the sending domain's SPF record has one or more suspicious entries. This differs from a normal SPF failure. Adding the sending IP alone will not resolve a record that still contains unsafe or malformed authorization.
Google does not publish a complete list of entries that trigger this response, so audit the full SPF evaluation path instead of guessing at one mechanism. Review the top-level record and every nested include or redirect.
- Remove unsafe authorization: Replace +all and other unnecessarily broad mechanisms with explicit senders.
- Check included domains: Remove obsolete, untrusted, or non-resolving includes and redirects.
- Validate syntax: Correct duplicate SPF records, invalid mechanisms, and misplaced qualifiers.
- Retest the full path: Confirm the record resolves within 10 DNS lookups and authorizes only active senders.
Do not weaken SPF as a shortcut
Changing the record to a permissive policy can hide an authorization mistake without fixing it. Keep the scope narrow, remove stale dependencies, and send a new Gmail test after DNS caches update.
Fix unauthenticated sender blocks
For 421-4.7.26, Gmail is rate limiting unauthenticated mail. A 550-5.7.26 response has several meanings: neither SPF nor DKIM passed, the envelope sender's -all policy failed, or the visible From domain's DMARC policy caused rejection. Read the full response before changing DNS. Google lists these variants in its SMTP error guide.
Enable DKIM signing with a domain that matches the visible From domain, then repair SPF for the envelope sender domain. Direct bulk mail needs both SPF and DKIM to pass, plus a DMARC record. DMARC alignment requires one passing method to share the From domain's organizational domain in relaxed mode, or match the exact domain in strict mode. Configure a custom Return-Path or custom DKIM domain when a sending service uses its own domain.
Broken path
- SPF source: The sending IP is missing from the envelope sender's SPF record.
- DKIM state: The message has no valid DKIM signature aligned with the From domain.
- DMARC result: Neither SPF nor DKIM gives DMARC a passing domain match.
Fixed path
- SPF source: The envelope sender domain authorizes the exact sending source.
- DKIM state: The active selector publishes a valid key and the signature verifies.
- DMARC result: The From domain matches a passing SPF or DKIM domain under the configured DMARC rules.
For a DKIM failure, use the signature's s= selector and d= domain to locate selector._domainkey.domain in DNS. Publish the sender's exact TXT key or CNAME and enable signing in the sending service. Gmail requires RSA DKIM keys of at least 1024 bits and recommends 2048 bits. A DMARC policy of p=none meets Gmail's minimum bulk-sender policy requirement; add rua reporting to investigate failures. These requirements are covered in Google's sender guidelines.
Forwarding can also break SPF because Gmail sees the forwarder's IP rather than the original sender's IP. If direct messages pass but forwarded copies fail, verify DKIM survival and DMARC alignment before editing an SPF record that already authorizes the direct sending path. Sender Rewriting Scheme (SRS) can give the rewritten envelope sender an SPF pass, but that domain usually differs from the original From domain. SRS alone does not restore SPF-based DMARC alignment. Preserve the original DKIM signature and avoid changing signed content, as described in Google's forwarding guidance.
For related Gmail wording, the SPF unauthorized error usually has the same root cause: the connecting mail system is not permitted by the domain's SPF policy.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's issue view groups failed sources, shows whether SPF, DKIM, and DMARC are failing, and provides specific fix steps. This reduces the need to read raw aggregate reports line by line when one sending service uses several IP ranges.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's domain health check reviews published SPF, DKIM, and DMARC records after a sender migration or infrastructure change. Compare those DNS results with the exact Gmail SMTP diagnostic and message headers to confirm the sending path.
Fix PTR and forward DNS
For 451-4.7.23 or 550-5.7.25, SPF is not the first place to work. Gmail is deferring or blocking the sending IP because reverse DNS is missing or the PTR hostname does not resolve back to the same IP. PTR records are controlled by the IP owner, usually the hosting provider, cloud provider, or network operator, not by the normal DNS zone for the sending domain.
PTR fixes happen at the IP owner
Adding an A record in the sending domain's DNS zone does not create reverse DNS. The IP owner must set the PTR record, then forward DNS for that PTR hostname must point back to the sending IP.
Forward-confirmed reverse DNS checkbash
dig -x 203.0.113.25 +short dig mail.example.com A +short # Repeat for the actual outbound IPv6 address, if used dig -x 2001:db8::25 +short dig mail.example.com AAAA +short
- Check reverse: Publish a stable PTR hostname for each public sending IP.
- Check forward: That hostname must resolve back to the same IPv4 or IPv6 address.
- Check identity: Use a hostname under a domain you control or a provider-hosted name.
- Check SMTP identity: Configure each server with a valid fully qualified HELO or EHLO hostname, preferably matching its PTR hostname.
For IPv6 delivery, the PTR hostname needs an AAAA record that resolves to the exact public IPv6 address used by the sending server. Gmail also requires the IPv6 mail stream to meet its authentication rules, so correct reverse DNS does not replace SPF or DKIM. The addresses in the commands are documentation examples; test the public IP Gmail names in the bounce. The generic 550 5.7.1 response can also name IPv6 PTR and authentication failures. On shared sending infrastructure, give the provider the affected IP and complete response so it can repair reverse DNS.
Gmail PTR record troubleshooting with reverse DNS and forward DNS checks.
Separate configuration errors from DNS noise
The hardest part is deciding whether a handful of Gmail failures means the records are wrong. Use a simple rule: if failures cluster around one source, domain, IP, region, or DNS provider, treat the pattern as a real fault. If an isolated error is spread across otherwise passing mail, investigate DNS reliability without making rushed DNS changes.
DNS can fail in ways that do not appear in one local query. Recursive resolvers cache different answers, routing paths differ, authoritative nameservers enforce rate limits, and stale delegation data can create intermittent lookups. Check both message samples and aggregate behavior before changing SPF, DKIM, or PTR records. Compare answers across the authoritative nameservers and recursive resolvers; allow cached answers to expire according to the previous TTL.
Gmail authentication response bands
Use isolation, clustering, and repeatability to decide the next action.
Monitor
Isolated sample
One isolated error among passing traffic
Investigate
Repeated cluster
Failures repeat for one source or IP
Fix now
Sustained failure
The same stream receives consistent blocks
For Gmail-specific monitoring, separate SMTP bounce logs, DMARC aggregate reports, and Google Postmaster Tools data. Bounce logs show the immediate rejection. DMARC reports show which sources fail over time. In Postmaster Tools v2, review Authentication, Compliance status, and Delivery errors. Domain Reputation and IP Reputation dashboards are absent from v2, and dashboard updates are not real time. Google explains the dashboard changes in its Postmaster Tools transition notice.
- Save SMTP responses for rejected mail and Gmail headers for delivered tests from the same stream.
- Group failures: Bucket errors by IP, envelope sender, DKIM domain, and hostname.
- Compare timing: Look for a spike after DNS, routing, or sending platform changes.
- Honor temporary deferrals with increasing retry delays and resume volume gradually after the error rate drops.
If SPF lookup limits are part of the pattern, SPF flattening helps when change detection is included. Static flattening without monitoring can become stale when a sender changes IP ranges.
Track authentication fixes with Suped
Suped connects Gmail error investigation to DMARC evidence and DNS fix work. A sending source can have an SPF miss, a DKIM selector issue, a DMARC domain mismatch, and a blocklist (blacklist) reputation concern at the same time. Suped groups those checks in one workflow alongside the DNS consoles and mail logs needed to make the changes.
Manual workflow
- Evidence: Collect SMTP logs, headers, DNS answers, and DMARC reports separately.
- Fix timing: DNS edits depend on whoever controls the zone or IP allocation.
- Risk: Small SPF changes can create lookup failures or authorize the wrong source.
Suped workflow
- Evidence: DMARC results and sending-source data help identify which source needs repair.
- Fix timing: Hosted SPF and Hosted DMARC reduce routine DNS edit delays.
- Risk: Issue detection and alerts show what changed before failures grow.
Use Suped's issue detection to identify the failing source and track the DNS or sending-service fix. Compare the result with Gmail's next SMTP response and a fresh test message.
Practical operating rule
Use Suped to group SPF, DKIM, DMARC, hosted record, and reputation evidence. Use the raw Gmail SMTP error to decide which layer to fix first.
For more context on Gmail's wording, the related Gmail SPF error messages page explains common variants and why Gmail uses temporary deferrals in some cases and permanent blocks in others.
Views from the trenches
Best practices
Start with Gmail's exact code, then verify SPF, DKIM, DMARC, and PTR separately.
Track error rates by IP and sender before changing records that already pass in tests.
Confirm reverse DNS with a forward lookup before escalating a Gmail delivery issue.
Common pitfalls
Do not treat every isolated Gmail deferral as proof that SPF is broken globally.
Do not add SPF includes blindly, because nested lookups can create new Gmail failures.
Do not edit normal DNS for PTR issues because the IP owner controls reverse DNS records.
Expert tips
Keep a clean sample set of failed and passed Gmail messages from the same sender.
Use DMARC aggregate data to determine whether a failing source is real or transient.
When an error spike clears, document the IP, reverse DNS, and DNS provider status.
Expert view
Expert from Email Geeks says that if SPF passes and reverse DNS exists, the next place to inspect is DNS reliability, including whether records fail to resolve consistently.
2025-08-22 - Email Geeks
Marketer view
Marketer from Email Geeks says the right starting point is to trust Gmail's error text and use it as the troubleshooting map, rather than assuming a broad Gmail issue.
2025-08-22 - Email Geeks
Verify delivery after DNS changes
After cached DNS answers expire, send fresh test mail through the same application and outbound relay, confirm Gmail's authentication results, then watch production traffic by source and IP. Authentication passing does not guarantee inbox placement; Gmail also evaluates sender reputation and recipient feedback. If failures return to isolated levels, keep monitoring. If Gmail continues to block one source, pause that stream and fix the underlying DNS or authentication path before scaling traffic again.
Frequently asked questions
It means Gmail temporarily rate limited the message because SPF did not pass. Check the envelope sender domain, authorize the connecting IP, and keep the SPF record within the 10 DNS lookup limit.
Read the complete code first. For 421-4.7.26, make SPF or DKIM pass. For direct bulk mail, both must authenticate, DMARC must be published, and at least one passing authentication method must meet DMARC's domain-matching rules for the visible From domain.
Google uses 550-5.7.26 for an unauthenticated sender, an SPF hard fail, or rejection under the visible From domain's DMARC policy. Read the complete diagnostic, then repair the named authentication check or domain match.
Usually no. The IP owner controls PTR records. The PTR hostname also needs a forward A or AAAA record pointing to the sending IP, published by whoever controls that hostname's DNS zone. On shared infrastructure, ask the sending provider to make the change.
Changing -all to ~all does not produce an SPF pass or repair a missing sender. Authorize legitimate sources and fix DNS evaluation errors first. Choose the final qualifier according to the domain's policy rather than weakening it to clear a Gmail error.
An isolated failure can happen because of a transient DNS or network resolution issue. Repeated failures clustered by IP, sender, or domain need investigation.
