Gmail SMTP Error Codes Explained: 550 5.7.26, 5.7.1, 4.7.28 and What Fixes Each
Gmail is unusually precise about why it refuses a message. The bounce text names the failing check and links to the relevant guideline. Most people read the first line, search for it, and land on forum threads that guess. Here is what each code actually means, from a fleet where I see all of them, and what fixes it.
How to read the code
Every SMTP response is a three-digit status and an enhanced status code of the form class.subject.detail. The class is what matters first. 5xx is permanent: the message was rejected and retrying it unchanged will fail again. 4xx is temporary: Gmail is telling your server to try later, and your MTA or sending tool will normally do that for you. Within the enhanced code, 7 as the subject means security or policy, which is where nearly every deliverability failure lives.
Gmail appends a human-readable reason and a link to the guideline in its SMTP error reference. Read the whole line. The same status code covers several distinct problems and the text is what separates them.
550 5.7.26 — unauthenticated email is not accepted
The full text is usually "This mail has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM", or for bulk senders, "…requires all bulk email senders to authenticate with both SPF and DKIM". Since February 2024 this is the most common hard bounce on new domains.
It means the receiving side could not verify the message with SPF or DKIM — or, for a domain over the bulk threshold, could not verify it with both. Run the domain through the bulk sender checker. The three causes in order of frequency:
No DKIM on your domain. The sending tool signs with its own domain, or nothing signs at all. Set up a DKIM record on the From: domain — the DKIM checker will tell you whether one exists.
SPF over ten lookups. The record exists but returns permerror, which counts as no SPF. Count it with the lookup counter.
Alignment. SPF and DKIM pass, but on a domain that does not match the From: address. Gmail wants at least one of them aligned. This is a DMARC concept and the alignment post covers the fixes.
421 4.7.28 — unusual rate of unsolicited mail
"Our system has detected an unusual rate of unsolicited mail originating from your IP address / DKIM domain / sender domain. To protect our users from spam, mail sent from your domain has been temporarily rate limited." Note the three variants: IP, DKIM domain, sender domain. The one named is the one Gmail is scoring.
This is a throttle, not a rejection. Gmail accepts some of your mail and defers the rest. It fires when volume from a new or low-reputation source jumps, or when the spam-complaint rate on existing volume climbs. On a cold email fleet it almost always means the warmup was too fast or a bad list went out. The response is to cut volume by half immediately, hold for three days, and check the Postmaster Tools spam rate for the domain. Pushing through it makes it a 5.7.1.
The 4.7.28 variant that names your DKIM domain is the one to take most seriously. It means Gmail has attached reputation to the signing domain, which is exactly what you want in the long run and exactly what you cannot afford to burn.
550 5.7.1 — policy rejections
5.7.1 is a catch-all for "rejected by policy" and the text tells you which policy. "Our system has detected that this message is likely unsolicited mail" is a content and reputation verdict: the domain or IP has a poor history and the message looked like the mail that earned it. "The user or domain that you are sending to has a policy that prohibited the mail" is the recipient's own Workspace rules — a blocklist or an attachment filter — and nothing on your side changes it. "Unauthenticated email from … is not accepted due to domain's DMARC policy" means your own DMARC record says reject and the message failed it; that is your policy working correctly against a misconfigured sender.
For the reputation variant there is no quick fix. Stop sending to Gmail from that source, review what went out, and either rehabilitate slowly with engaged recipients or retire the domain. The recovery post is the full playbook.
550 5.7.25 — PTR record does not match
"The IP address sending this message does not have a PTR record setup, or the corresponding forward DNS entry does not point to the sending IP." Gmail requires every sending IP to have reverse DNS, and the hostname it resolves to must resolve back to the same IP. On Google Workspace and Microsoft 365 this is handled for you. On a VPS or a dedicated SMTP relay it is your job, and it is missed constantly because mail works fine to every other receiver. Check the IP with the PTR lookup.
The transient family: 421 4.7.0, 451 4.3.0, 452 4.2.2
421 4.7.0 "Try again later, closing connection" is Gmail's general back-off signal, often with no deeper meaning than a busy edge server. 451 4.3.0 is a temporary internal error on Google's side. 452 4.2.2 "The email account that you tried to reach is over quota" is the recipient's problem. All three are retried automatically and resolve themselves; if 4.7.0 becomes persistent on one domain, treat it as an early form of 4.7.28.
Recipient-side codes that are not your fault
550 5.1.1 "The email account that you tried to reach does not exist" is a bad address and should be removed from your list on the first occurrence — Gmail counts repeated attempts to dead addresses as a spam signal. 550 5.2.1 "The email account that you tried to reach is disabled" is the same in effect. Neither says anything about your reputation until you keep hitting them.
A triage order
When a Gmail bounce lands, check in this sequence: is it 4xx (wait) or 5xx (fix)? Does the text mention authentication, DMARC or PTR (a DNS fix you can make today)? Does it mention rate, unsolicited or reputation (a volume and list problem that takes days)? Does it name the recipient account (nothing to fix; clean the list)? Nine times out of ten the answer is in the first two lines, and the tools linked above confirm it in under a minute.
Decode a bounce you are holding
Paste the full failure notice into the bounce code decoder and it separates the address problems from the reputation blocks — the distinction this whole guide is about — and tells you whether to remove the address or stop sending.
Sources
- Gmail SMTP error reference — Google Workspace Admin Help
- Email sender guidelines — Google Workspace Admin Help
- RFC 3463 — Enhanced Mail System Status Codes — IETF
Tools for this
Bulk sender checkerCheck Gmail and Yahoo bulk sender rules.DKIM checkerFind signing keys without the selector.SPF lookup counterCount DNS lookups against the limit of ten.PTR lookupReverse DNS for any IP address.Frequently asked questions
What does 550 5.7.26 mean?
Gmail could not verify the message with SPF or DKIM on the From: domain — or, for bulk senders, with both. Fix authentication on the sending domain: publish DKIM, keep SPF under ten lookups, and make sure at least one of them aligns with the From: address.
Is 421 4.7.28 permanent?
No. It is a temporary rate limit. Cut volume, wait a few days, and it lifts if the spam rate is under control. Continuing to send at the same rate turns it into a permanent 5.7.1 rejection.
How long does a Gmail block last?
Rate limits typically ease within 24 to 72 hours of reduced, clean sending. Reputation-based 5.7.1 rejections have no fixed duration and depend on the domain earning positive engagement again, which can take weeks.
Why do I get 5.7.26 when SPF passes?
Because the bulk sender rules require SPF and DKIM together, or because the passing SPF is on a domain that does not align with your From: address. Check the Authentication-Results header on a delivered message with the header analyzer to see which domain each check passed on.