Inboxpass All guides

Guides

Gmail 5.7.26 and other authentication bounces

3 November 2026

A Gmail bounce with 5.7.26 means Gmail could not authenticate the message: SPF and DKIM both failed, or DMARC failed under a policy that asks for rejection. The related codes narrow it down. x.7.27 is SPF, x.7.30 is DKIM, and x.7.32 means the From domain does not match the domain that passed. A code that starts with 4 is a temporary rate limit. A code that starts with 5 is a block. In each case the fix is in your DNS or in the way a sending tool is set up, not in the message itself.

Google says it began ramping up enforcement on noncompliant mail in November 2025, so these bounces are more common than they were. If you want the records checked for you, a $129 Snapshot reads SPF, DKIM, and DMARC from public DNS and lists the fixes in order, within 24 hours.

The codes, in Google’s words

Google’s Gmail SMTP errors and codes page lists the full text. These are the ones tied to authentication:

Google’s sender guidelines FAQ groups them the same way: the 4.x versions mean Gmail is temporarily rate limiting, and the 5.x versions mean Gmail blocked the message.

First, find out who sent it

Before you change any record, work out which service sent the bounced message. A domain with a mailbox provider, a newsletter platform, and a store usually has three different paths to Gmail, and only one of them is broken.

5.7.26 or 4.7.26: unauthenticated

Gmail could not verify the message at all. For every sender, Gmail requires SPF or DKIM. For bulk senders (close to 5,000 messages a day or more to personal Gmail accounts), it requires both, plus DMARC.

Common causes:

Fix: set up DKIM on your own domain for that service, and add it to SPF if it sends with your domain in the envelope. DKIM is the one to prioritize. It survives more forwarding, and for most third-party senders it is the check that lets DMARC pass.

5.7.26 with "DMARC policy"

This version means your DMARC record is at quarantine or reject, and the message failed DMARC. Gmail is following the policy you published.

That is DMARC doing its job when the sender is a spoofer. When the sender is your own tool, it means the tool passes neither SPF nor DKIM on a domain that matches your From address. Our guide to why DMARC fails covers alignment in detail.

Fix the sender, not the policy. Setting DMARC back to p=none stops the bounces but also stops the protection. Drop back only for a short time if real customer mail is bouncing and you cannot fix the sender today. Then fix it and move back up.

If the bounce says 451 4.7.26 with temporary DNS failures, Gmail could not look up your records at the time. Check that your DNS host is answering. If it is, the message will usually go through on retry.

4.7.27 or 5.7.27: SPF failed

SPF did not pass for the envelope sender domain. Gmail lists this as a requirement for bulk senders, who need SPF and DKIM both.

The SPF record guide covers building one record that lists every sender.

4.7.30 or 5.7.30: DKIM failed

A DKIM signature was present but did not verify, or the message needed DKIM and had none that passed. Common causes:

4.7.32 or 5.7.32: From header not aligned

SPF or DKIM passed, but on a different domain from the one in your From address. This is the most common surprise. A newsletter platform that signs with its own domain passes DKIM, and a service that uses its own bounce domain passes SPF, yet neither counts for your domain.

Fix: set up the service’s custom domain authentication, so it signs DKIM with d= your domain, or uses a return-path on your domain. Mailchimp and Klaviyo specifics are in our Mailchimp and Klaviyo guide. Alignment can be relaxed: a subdomain of your From domain counts unless your DMARC record sets strict alignment.

5.7.25 and 4.7.23: no PTR record

The sending IP has no reverse DNS name, or the name does not point back to the IP. If you use a mailbox provider or a newsletter platform, this is their setting, not yours. Report it to them. If you run your own mail server, set the PTR with whoever owns the IP, usually your host or ISP.

When the bounce is from a forwarded message

Mail that was forwarded through another server, a mailing list, or an old alias can fail SPF at Gmail even when your setup is correct, because the forwarder’s IP is not in your SPF record. DKIM usually survives plain forwarding. This is one more reason to make sure every service signs with DKIM on your domain.

Check the fix

  1. Publish the change and confirm it with a DNS lookup.
  2. Send a test from the same service to a Gmail address. In Show original, SPF, DKIM, and DMARC should each say PASS, with your domain shown.
  3. Watch DMARC reports and Postmaster Tools for a few days. Google’s FAQ says rejection reasons are visible in Postmaster Tools too.

Sources