Key takeaways
- 550 5.7.26 is a permanent rejection by Gmail linked to authentication.
- One version means the message passed neither SPF nor DKIM; the other means it failed your own DMARC policy.
- Read the full bounce text to know which case you are in.
- The usual fix is DKIM signing on your own domain in every tool that sends for you.
- Gmail has been tightening enforcement since late 2025, so errors that were warnings can become rejections.
In this guide
- The two versions of the error
- Version A: the sender is unauthenticated
- Version B: the message failed your DMARC policy
- Forwarded mail and 5.7.26
- How to check authentication in Gmail
- Why these errors increased
- Related Gmail authentication codes
- Real example: a contact form that broke DMARC
- Where to find the bounce text
- Prevention checklist before changing DMARC
- Version A vs version B at a glance
- Temporary deferrals before rejections
- Checklist to stop 5.7.26 bounces
- Frequently asked questions
The two versions of the error
Gmail uses the code 550 5.7.26 for authentication-related rejections. The text after the code tells you which situation you are in. The two most common versions are:
| Version | Typical text (shortened) | What it means |
|---|---|---|
| A. Unauthenticated sender | "This mail has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM." | The message passed neither SPF nor DKIM |
| B. DMARC policy failure | "Unauthenticated email from yourbrand.com is not accepted due to domain's DMARC policy." | The message failed DMARC, and your domain's policy is quarantine or reject |
Read the complete bounce message in your platform's report or in the bounce email. The wording tells you where to look.
Version A: the sender is unauthenticated
Neither SPF nor DKIM passed for this message. This usually happens when:
- A tool sends with your domain but is not in your SPF record and does not sign DKIM (a website contact form, a shop plugin, a CRM, an old server).
- Your SPF record is broken (two records, or more than 10 lookups). See fixing SPF PermError.
- DKIM records were deleted during a DNS change or a domain transfer.
How to fix it
- Identify the sending system from the bounce (which campaign, which notification).
- Add it to SPF if it sends from its own servers with your domain in the envelope sender.
- Enable DKIM on your domain in that system, and publish the records it provides.
- Test by sending a message to a Gmail address and checking "Show original": SPF or DKIM must show PASS.
Version B: the message failed your DMARC policy
Here, your own DMARC record (p=quarantine or p=reject) tells Gmail what to do with mail that fails DMARC, and Gmail applies it. DMARC fails when neither SPF nor DKIM passes with a domain aligned to the From address.
The classic case: your email platform signs DKIM with its own domain, and SPF passes for its bounce domain. Both technically pass, but neither aligns with yourbrand.com. DMARC fails, and your reject policy blocks your own newsletter.
How to fix it
- Check the headers of a message from the failing stream: look at
d=in the DKIM signature and the domain in the SPF result. - Authenticate your domain in the sending tool so DKIM is signed with your domain. This is the most robust fix.
- Use your DMARC reports to find all sources failing alignment; see how to read DMARC reports.
- If business-critical mail is blocked right now, you can temporarily set
p=nonewhile you fix the source, then return to your stricter policy. Do not leave it at none indefinitely.
Forwarded mail and 5.7.26
Sometimes the bounce does not come from your direct send but from a forwarding step: a subscriber's address forwards to Gmail, SPF breaks during forwarding, and DKIM was missing or broken. With aligned DKIM, most forwarded mail still passes. See why forwarded emails fail DMARC.
How to check authentication in Gmail
- Send a message from the stream you want to test to a Gmail address you can access.
- Open it, click the three dots next to Reply, and choose Show original.
- At the top, Gmail shows SPF, DKIM and DMARC with PASS or FAIL, and the domains involved.
- For DKIM, check that the domain shown is yours. For DMARC, PASS is what you need.
If the message never arrives, the bounce text in your platform is your only clue. Gmail's delivery errors dashboard in Postmaster Tools can also show the share of mail rejected for authentication reasons.
Why these errors increased
Since February 2024, Gmail has required all senders to authenticate, and bulk senders to publish DMARC and align. Google has said it began ramping up enforcement on non-compliant traffic in November 2025, with temporary and permanent rejections. Problems that used to send mail to spam are now more likely to produce hard bounces like 5.7.26.
Related Gmail authentication codes
| Code | Typical meaning |
|---|---|
| 550 5.7.26 | Unauthenticated, or failed the domain's DMARC policy |
| 550 5.7.1 | Rejected for policy or likely spam reasons |
| 421 4.7.x | Temporary deferral: rate limiting, reputation or authentication issue to fix before retry |
Microsoft has its own equivalent for authentication failures: see Outlook 550 5.7.515.
Real example: a contact form that broke DMARC
A business moved its DMARC policy to p=reject. Two days later, the sales team noticed that website contact requests no longer arrived in their Gmail inboxes. The website's contact form sent notifications "from" the company domain through the web server, with no DKIM and an IP not listed in SPF. Gmail rejected them with 550 5.7.26, applying the company's own DMARC policy.
The fix: configure the website to send through an authenticated email service (SMTP with DKIM on the domain), or send the notification from a different, dedicated address. The lesson: list every system that sends with your domain before enforcing DMARC. Your DMARC reports show them all, including the ones nobody remembers.
Where to find the bounce text
- Email platforms: campaign report, bounces section, details per contact.
- Your own mailbox: a "Delivery Status Notification" email with the error in the body.
- Websites and applications: the mail logs of the server or the transactional email service dashboard.
- Postmaster Tools: the delivery errors chart shows the share of rejected traffic, not individual messages.
Prevention checklist before changing DMARC
- At least two weeks of DMARC reports at
p=nonereviewed - Every legitimate source passes with aligned DKIM or aligned SPF
- Website, shop and SaaS notifications tested with "Show original"
- Team informed of the change date, with a contact for issues
- Bounce reports monitored daily for a week after the change
Following this list before each policy change prevents almost every self-inflicted 5.7.26 incident.
Version A vs version B at a glance
| A: unauthenticated | B: DMARC policy | |
|---|---|---|
| SPF | Fails or missing | May pass, but not aligned |
| DKIM | Fails or missing | May pass, but not aligned |
| Your DMARC policy | Any | quarantine or reject |
| Main fix | Add SPF/DKIM for the sending system | Align DKIM with your From domain |
Temporary deferrals before rejections
Before permanent 5.7.26 rejections, some senders see temporary errors (codes starting with 4) for the same messages, meaning Gmail asks the sending server to try again later. Platforms retry automatically, so these errors often go unnoticed. If your platform reports many deferred messages to Gmail, treat it as an early warning: check authentication immediately, before the deferrals turn into hard bounces and suppressed contacts. Postmaster Tools' delivery errors chart helps you spot this trend.
Checklist to stop 5.7.26 bounces
- Read the full bounce text to know whether it is version A or B
- Identify the exact system sending the bounced messages
- SPF: one valid record, under 10 lookups, including that system if needed
- DKIM: signed with your own domain in every sending tool
- DMARC: aligned results for all legitimate sources in reports
- Temporary p=none only if critical mail is blocked, then tighten again
- Retest with "Show original" after each change
For the complete foundation, see SPF, DKIM and DMARC explained.
Frequently asked questions
What does "unauthenticated email is not accepted due to domain's DMARC policy" mean?
Your domain publishes a DMARC policy of quarantine or reject, and this message failed DMARC. Gmail applied your own policy and rejected it.
Can a forwarded email trigger 5.7.26?
Yes. Forwarding can break SPF, and if DKIM is missing or broken, DMARC fails. Aligned DKIM is the best protection.
Why do only some of my emails bounce with 5.7.26?
Usually one sending service is not authenticated, for example a CRM, invoicing tool or website contact form. Find it in your DMARC reports.
Should I set DMARC to p=none to stop the bounces?
Only temporarily if business-critical mail is blocked. The real fix is authenticating the failing source, then returning to your stricter policy.
How do I check whether my email passes authentication?
Send a message to a Gmail address, open it, choose "Show original", and read the SPF, DKIM and DMARC results.
