How do you fix “550 5.7.26 This mail is unauthenticated... unauthenticated email is not accepted”?
Updated July 3, 2026
This bounce means Gmail rejected your message because it passed neither SPF nor DKIM. Google now refuses mail it can't authenticate at all.
Why this happens
Since early 2024, Google requires every sender to authenticate with at least SPF or DKIM, and bulk senders to have both plus DMARC. A 550 5.7.26 rejection means the specific message arrived with no passing authentication: the sending IP wasn't in your SPF record, and there was no valid DKIM signature for your domain.
The most common cause is a sending source nobody set up properly: a CRM, billing system, or notification service that sends “from” your domain but was never added to SPF and never given a DKIM key. It worked for years because Gmail used to accept unauthenticated mail with a spam penalty; now it rejects it outright.
Forwarding triggers it too. When someone forwards your mail, SPF breaks (the forwarder's IP isn't yours), and if your DKIM signature also broke in transit, the forwarded copy arrives fully unauthenticated and Gmail bounces it back to the forwarder.
How to fix it
- 1
Identify which system sent the bounced mail
Read the bounce: it names the sending IP. Match that IP to a service: your mail platform, CRM, helpdesk, or an app server sending directly. The fix is per-source, so you need to know exactly what sent it.
- 2
Add the source to your SPF record
Add the provider's include: mechanism (or the server's ip4: address) to the SPF record on your From domain. Check the provider's docs for the exact include, and run our SPF checker afterward to make sure you haven't blown past the 10-lookup limit.
- 3
Set up DKIM for the source
In the sending service's settings, enable DKIM signing for your domain and publish the CNAME or TXT records it gives you. DKIM matters more than SPF here because it survives forwarding: a message with valid DKIM won't hit 5.7.26 even when SPF breaks.
- 4
Publish a DMARC record if you don't have one
Gmail requires DMARC for bulk senders and treats a missing record as a negative signal for everyone. Start with v=DMARC1; p=none; rua=mailto:your-reports-address so you get visibility without risking legitimate mail.
- 5
Verify the fix
Send a test from the fixed source to a Gmail mailbox and open “Show original”: you want spf=pass and dkim=pass in the Authentication-Results. Then confirm your records with our DMARC checker.
Verify the fix
Run the check that corresponds to this error. You'll see the same red/amber/green verdicts mailbox providers effectively apply.
Open the DMARC checker →Preventing it next time
5.7.26 bounces usually mean one forgotten sending source, and the next one is a matter of time: every new tool your team connects is a new chance to send unauthenticated mail. DMARCPath watches your aggregate reports and flags any source sending as your domain without passing SPF or DKIM, so you fix it before Gmail starts bouncing and before customers notice missing invoices.
Frequently asked questions
- Why did this start suddenly when nothing changed on my end?
- Google tightened enforcement in stages starting February 2024. Mail that used to land in spam with no authentication now gets rejected at the door. Your setup didn't change. Gmail's tolerance did.
- Do I need both SPF and DKIM to fix this?
- One passing check stops the bounce, but set up both. SPF alone breaks on forwarding, and if you send 5,000+ messages a day to Gmail, Google requires SPF, DKIM, and DMARC together.
- I got this bounce for mail I never sent. What's happening?
- Someone is spoofing your domain, and Gmail is rejecting their unauthenticated forgeries, which is the system working. Publish a DMARC record and move toward p=reject so every receiver treats spoofed mail this way.
Catch this before your customers do
DMARCPath watches your domain's authentication continuously and alerts you the day something breaks, not the week a customer mentions your emails stopped arriving. One domain free.
Start monitoring free →