Gmail's stricter enforcement: reading its 4xx and 5xx replies

550-5.7.26 Unauthenticated email from example.com is not accepted due to
550-5.7.26 domain's DMARC policy. Please contact the administrator of
550 5.7.26 example.com domain if this was a legitimate mail. ...

Triage: what to do with each class#

Temporary failures (4xx)#

Your sending system should retry automatically with backoff. Do not treat a 4xx as a bounce, and do not suppress the recipient. But do not ignore it either:

• A few deferrals spread across many recipients during a busy hour are often rate limiting. Back off and let retries succeed.
• Many deferrals with authentication text mean Gmail is warning you before rejecting. Fix the cause before retries run out and the deferrals turn into bounces.
• Persistent deferrals for one IP suggest a reputation or reverse DNS problem specific to that IP.

Permanent failures (5xx)#

The message will not be delivered. Your system should stop retrying and record a bounce. The important distinction is whether the failure is about the recipient or about you:

• 5.1.1 (bad mailbox) is about the recipient: suppress the address.
• 5.7.x policy and authentication failures are about your sending setup: do not suppress the recipient. The address is fine; your mail is the problem. Suppressing recipients on authentication failures quietly destroys your list.

That rule alone prevents a lot of damage. Classify bounces using the enhanced status code, not just the first digit.

A worked investigation#

Suppose your logs show a sudden rise in 550 5.7.26 replies from Gmail for mail from your billing system.

1. Isolate the stream. All failures share the From address [email protected] and come through one vendor.
2. Send a test from that vendor to a personal Gmail account. If it is rejected, check the bounce; if delivered, look at "Show original."
3. Read the authentication results. Suppose SPF passed for mail.vendor.example and DKIM passed for vendor.example. Neither aligns with example.com, so DMARC fails.
4. Check recent changes. Your DMARC policy moved from none to quarantine last week, so Gmail now acts on the failure.
5. Fix it. Enable custom-domain DKIM in the vendor's settings, publish the CNAMEs, and confirm a test message shows aligned DKIM.
6. Confirm in data. Watch the 5.7.26 count fall and DMARC aggregate reports show aligned passes for the vendor's IPs.

Instrument your sending system#

To catch these quickly, log every SMTP reply from Gmail with:

• The full status code and enhanced status code.
• The sending domain, IP and stream (transactional, marketing, a specific vendor).
• The first line of the reply text.

Then alert on rates, not counts: the share of Gmail-bound messages receiving 4xx or 5xx replies with subject code 7, compared with a rolling baseline. If you send through a provider, their webhooks or event logs usually include the remote server's reply; capture it rather than just "bounced."

Prevention checklist#

• SPF and DKIM for every sending domain, aligned with the From domain.
• DMARC published; policy changes made only after reports show all sources passing.
• Valid PTR and forward DNS for every IP you operate.
• TLS on all outbound connections.
• One-click unsubscribe headers on marketing mail, signed by DKIM.
• Spam rate monitored in Postmaster Tools.
• Bounce classification based on enhanced status codes, never suppressing recipients for 5.7.x policy failures.

Key takeaways#

• Since November 2025, Gmail rejects or defers more non-compliant mail instead of only filtering it.
• 4xx replies mean retry and investigate; 5xx replies mean stop and fix.
• Enhanced status codes with subject 7 point at policy and authentication problems on your side.
• Never suppress recipients because of your own authentication failures.
• Log full reply codes and alert on rising rates so warnings are caught before they turn into bounces.