What Does 550 5.7.26 Mean, and How Do I Fix It?

The three 550 5.7.26 texts

Google's SMTP error reference (updated October 13, 2026) lists three bounces with this code. The words after the code tell you which one you have:

The softer versions come first. Gmail answers 421 4.7.26 ("rate limited because it is unauthenticated"), 421 4.7.27 (SPF) and 421 4.7.30 (DKIM) while it is still deferring the mail. If you see those, fix the records before they turn into 550s. The email bounce decoder tells the variants apart from the pasted bounce.

Why it happens to cold email setups

• The sending tool signs DKIM with its own domain. DKIM passes for d=sendtool.com, but that does not count for your From domain under DMARC.

• SPF lists the old provider. You moved mailboxes to a new SMTP host and the record still includes only the previous one, ending in -all.

• Two SPF records. A second v=spf1 TXT record makes SPF return PermError, which fails like no record at all. See SPF PermError.

• DMARC set to reject too early. A copied p=reject turns every authentication slip into a hard bounce. See why DMARC fails.

• A forwarded or relayed copy. Mail forwarded from another server can fail SPF at Gmail. This is the case most forum threads about 5.7.26 describe.

How to fix it

1. Read the bounce text and match it to the table above.

2. Check the domain with the SPF, DKIM and DMARC checker: one SPF record, under 10 lookups, the sending server included; a DKIM key at the selector your tool uses; a DMARC record.

3. Sign DKIM with your own domain. In the sending tool, publish its DKIM key on your domain and turn signing on. This alone fixes the DMARC variant for most senders, because an aligned DKIM pass is enough for DMARC.

4. Send a test to a Gmail address and open Show original. spf=pass, dkim=pass header.d=yourdomain.com and dmarc=pass mean the fix worked; the email header analyzer reads it for you.

5. Add the bounced recipients back gradually. The bounced recipients never saw the email; add them back to the campaign at the normal daily pace.

If the domain must keep p=reject (it protects a brand), fix alignment first and only then return to reject. Gmail's own delivery-error guidance suggests p=none to "still deliver messages that don't pass DMARC" while you investigate.

What we recommend at Outreach2day

We publish SPF, DKIM and DMARC on every domain we set up and sign DKIM with the customer's own domain, so the three 5.7.26 texts do not come from our mailboxes. If you send through another tool from domains you set up yourself, run the checker after every change of provider.