Excubitor

All guides · Updated: 2026-10-18

Email bounced with “550 5.7.26”: what Gmail is telling you

550 5.7.26 is Gmail's way of saying: I couldn't confirm this email really comes from who it claims to be, so I refused it. It's a permanent rejection: the email isn't retried. The cause is almost always in the sender's domain, and that's where it gets fixed.

Across the 1,500 small-business sites we checked, the two most common causes of this error were frequent: 1 in 17 had a broken SPF, and half of the domains with email on Google Workspace had never turned on DKIM.

First: which of the three messages did you get?

The code is the same, but the message after it changes. Look in the bounce for one of these phrases:

Got a bounce for an email you never sent? Then someone tried to send in your domain's name, and your DMARC stopped it. It's working: there's nothing to fix.

Step 1: find out which service sent the email

The error rarely comes from your mailbox. It almost always comes from something else that sends in your name: newsletters, invoices, your online store, your website's form, a CRM. Look at the bounced email and ask: where did this one come from?

Every service that sends as your domain has to be allowed in SPF or, better, sign with DKIM on behalf of your domain. Each service's help calls this “domain authentication”.

Step 2: if the message is about the sender or SPF

  1. Add the service to your SPF: the include: it gives you goes into the SPF record you already have, never into a second record.
  2. Turn on that service's DKIM with your domain, following its help (usually one or two CNAME or TXT records).
  3. Send the email again.

Changing -all to ~all makes the second message go away, but fixes nothing: the email still has no valid SPF or DKIM, and it still goes to spam or gets refused. Fix the service, not the all.

Two SPF records or more than 10 lookups: how to tidy up SPF

DKIM on Google Workspace, step by step

DKIM on Microsoft 365, step by step

Step 3: if the message is about the DMARC policy

Your DMARC is doing its job, but it caught a genuine email. The fix is the same as step 2: the service that sent it has to sign with DKIM on behalf of your domain (or pass SPF with your domain).

If it's urgent (your invoices are bouncing, say), you can set DMARC to p=none while you fix it, and go back to quarantine right after:

Type
TXT
Name (host)
_dmarc
Value
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com

Don't forget to go back: at p=none, anyone can send fake email in your name again with nothing to stop it.

DMARC: from p=none to p=quarantine, when and how

The neighbours: 5.7.27, 5.7.30 and the 4.7.x codes

“Bulk” means more than 5,000 emails a day to Gmail accounts. Below that, one of the two (SPF or DKIM) passing is enough, but having both is what keeps these errors away.

Step 4: confirm

Send a test email from the service that failed to a Gmail account of yours. Open it, click the three dots and “Show original”. At the top you'll see SPF, DKIM and DMARC, each with PASS or FAIL.

And check the domain: Excubitor tells you whether SPF is broken, whether Google or Microsoft DKIM is switched off and where your DMARC stands, with the evidence for each.

Mistakes we see often

So you don't have to check again

These errors show up the day someone adds a new service or touches the DNS. Excubitor can watch the domain every week and email you only when something changes. Free for 1 domain: run the check and press “Notify me”.