Gmail 550 5.7.26: three different bounces, three different fixes
Gmail's 550 5.7.26 covers three rejections: no SPF or DKIM pass, a DMARC policy failure, or an SPF -all hard fail. Read the text after the code to pick the fix.
On this page(9 sections)
- What does 550 5.7.26 mean?
- Which of the three 5.7.26 messages did you get?
- Cause 1: What if neither SPF nor DKIM passed?
- Cause 2: What if it says the domain's DMARC policy blocked it?
- Cause 3: What if it complains about an SPF hard fail (-all)?
- Does forwarding cause 5.7.26?
- A ten-minute triage you can follow
- Common mistakes
- Bottom line
A Gmail 550 5.7.26 bounce means Gmail refused your message because it could not trust who sent it. The code alone does not tell you why: Google's own Gmail SMTP error reference lists three different messages under 5.7.26, and each one points at a different part of your DNS. Read the sentence after the code first, then pick the fix below.
What does 550 5.7.26 mean?
It is a permanent rejection (the 5 class) with a security or policy reason (subject 7, per RFC 3463) where the detail 26 is Gmail's way of saying "unauthenticated." Google's sender guidelines state that all senders need SPF or DKIM, and that unauthenticated mail "might be marked as spam or rejected with a 5.7.26 error." Authentication here means a pass, not just a record that exists.
Do not retry a 5.7.26 and hope. A permanent bounce will fail again until something in DNS or in the sending path changes.
Which of the three 5.7.26 messages did you get?
Match the text in your bounce to this table. The wording comes from Google's error reference at the time of writing.
| Text in the bounce | What failed | Fix first |
|---|---|---|
| "This email has been blocked because the sender is unauthenticated." | Neither SPF nor DKIM passed | Get one of them passing, ideally both |
| "Unauthenticated email from domain is not accepted due to domain's DMARC policy." | DMARC failed and your policy asks receivers to act | Get an aligned SPF or DKIM pass |
| "The (E)MAIL FROM domain domain has an SPF record with a hard fail policy (-all)." | The sending IP is not in your SPF record | Add the sender to SPF, or send through a sender that is |
Notice that the second row is the only one where the From domain's DMARC record is the trigger. The first and third can happen to a domain that has no DMARC record at all.
Cause 1: What if neither SPF nor DKIM passed?
Gmail saw no passing SPF and no passing DKIM, so there was nothing to authenticate the message with. This is common with a brand-new sending tool, a server that sends directly without a signing step, or a DKIM key that was never published.
Check the message you sent, not your DNS in the abstract. Open a delivered copy (send the same message to a Gmail address you control and use "Show original"), and read the Authentication-Results header. Our guide to reading Authentication-Results headers explains each field. You are looking for spf=pass or dkim=pass.
Typical culprits:
- The DKIM selector in the signature does not match a published DNS record, or the record was split or pasted wrongly. See DKIM 2048-bit TXT strings.
- A middlebox changed the body after signing, so the signature fails. See DKIM body hash did not verify.
- You have two SPF records, which turns SPF into a
permerror. See multiple SPF records and permerror.
Cause 2: What if it says the domain's DMARC policy blocked it?
DMARC is the policy layer on top of SPF and DKIM. Per RFC 7489, a message passes DMARC only if SPF or DKIM passes and the passing domain aligns with the domain in the From header. Alignment is the part people miss: SPF can pass for a vendor's bounce domain and DKIM can pass for the vendor's own signing domain, yet DMARC still fails because neither is your domain.
If your policy is p=quarantine or p=reject, Gmail acts on that failure and cites your DMARC policy in the bounce. The fix is not to loosen the policy. It is to make one mechanism align:
- Find the failing source in your DMARC aggregate reports (how to read them).
- Configure that vendor to sign DKIM with a key on your domain (usually two CNAME or TXT records they give you).
- Resend a test and confirm
dmarc=passwithheader.fromequal to your domain. - Only then consider the case closed. Alignment modes, relaxed and strict explains what counts as a match.
Google's reference also lists a temporary variant, 4.7.26, where the message says DMARC could not be evaluated because of temporary DNS failures. That is a retry-later case, not a configuration error, but check that your DNS provider and your authoritative nameservers answer reliably.
Cause 3: What if it complains about an SPF hard fail (-all)?
Here Gmail names the envelope sender domain (the MAIL FROM, also called the Return-Path) and says its SPF record ends in -all, the hard fail mechanism, and the connecting IP is not authorized. With -all, you told the world to reject anything not listed.
Look up the exact domain Gmail names, not only your visible From domain. A vendor often uses its own MAIL FROM domain, and in that case their SPF record, not yours, is the one being evaluated. Compare the connecting IP in the bounce (or the Received lines) with the record:
dig +short TXT example.com | grep spf1
v=spf1 include:_spf.google.com include:mail.vendor.example -all
If the sender is yours, add its include: or IP and remember the ten-lookup limit (SPF 10 DNS lookup limit). If you are unsure which senders exist, do not guess: audit them from DMARC reports first. For the difference between -all and ~all, see SPF softfail vs fail.
Does forwarding cause 5.7.26?
It can. When a message is forwarded without rewriting, SPF is checked against the forwarder's IP and fails, and a mailing list that edits the subject or body can break DKIM. Google's guidelines ask forwarders to make sure forwarded messages are authenticated. If your bounce comes from a message that was forwarded into Gmail, the fix belongs with the forwarding service, not your DNS. Our posts on why forwarding breaks and DMARC, forwarding and ARC cover the mechanics.
A ten-minute triage you can follow
- Copy the full bounce text and note which of the three sentences it contains.
- Send one test message from the same system to a Gmail address you own.
- Open "Show original" and read the SPF, DKIM and DMARC results and the domains beside them.
- Cause 1: make SPF or DKIM pass. Cause 2: make one of them align with your From domain. Cause 3: authorize the sending IP in the SPF record of the domain Gmail named.
- Send another test, confirm all three results, then resend the bounced mail.
- Watch your reports for a day to catch any other sender with the same gap.
Common mistakes
- Editing DMARC to
p=noneto make the bounce go away. It may stop this rejection, but it removes protection and does not fix the unauthenticated sender. - Checking the wrong domain. The From domain, the envelope sender and the DKIM
d=domain can all differ. - Trusting "record exists" tools. A record that validates in a checker can still fail for the actual sending IP or selector.
- Fixing DNS and testing immediately. Allow for your record's TTL before judging the result (DNS TTL and authentication changes).
Bottom line
550 5.7.26 is one code with three meanings. If the bounce says "sender is unauthenticated," make SPF or DKIM pass. If it cites your DMARC policy, get an aligned pass. If it names an SPF -all, authorize the sending IP in the right domain's record. Test with a real message and the headers Gmail shows you, and fix the failing sender rather than weakening your policy.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
