550 5.7.26: Blocked because the sender is unauthenticated

550 5.7.26 from Gmail means your message was blocked for failing authentication. SPF and DKIM do not pass, or your domain's DMARC policy tells receivers to reject the failures. It is the permanent version of 421 4.7.26.

Bounce type
Hard bounce (permanent)
Usually caused on
Your sending side
Terlido report label
Blocked by the provider

What the standard says

RFC 5321 defines 550 as "mailbox unavailable", which includes refusals for policy reasons. RFC 7372 defines X.7.26 as "Multiple authentication checks failed": the authentication checks that were tried did not give the receiver enough to trust the message. Class 5 means the refusal is permanent.

What the mailbox providers say

  • Gmail (550 5.7.26): “This email has been blocked because the sender is unauthenticated...” Source
  • Gmail (550 5.7.26): “Unauthenticated email from domain-name is not accepted due to domain's DMARC policy...” Source

Common causes

  • Neither SPF nor DKIM passes for the message.
  • The domain publishes a DMARC policy of reject or quarantine, and the message fails alignment.
  • The From domain differs from the domain used in SPF and DKIM, so alignment fails.
  • A tool or service sends on your behalf without being authorized in your DNS.
  • Gmail's rules for bulk senders require authentication, and mail that skips it is blocked.
  • A recent change of email platform where the new tool signs with its own domain instead of yours.

How to fix it

  • Set up SPF and DKIM for the exact domain in the From address.
  • Publish a DMARC record and check that at least one of SPF or DKIM aligns with the From domain.
  • Find every service that sends as your domain and authorize each one in DNS.
  • Read the headers of a test message in Gmail and confirm that SPF, DKIM and DMARC show pass.
  • Check each sending tool for a setting that lets you sign with your own domain, and turn it on.
  • Add DMARC reporting so you receive data about which senders fail, and fix them one by one.

Is it a deliverability problem?

Yes, and it is one of the clearest ones. It states that the authentication of your domain is failing. Fix it before you send more, because the same failure affects every large receiver that checks authentication. Large receivers require sender authentication for bulk mail, so this problem will not fix itself. If you only saw the 421 version so far, treat this block as the next step of the same story. Authentication done once and done well stops both.

How Terlido handles it

When a bounce message for this code arrives in a connected mailbox, Terlido reads the status code. An enhanced code that starts with 5 is a hard bounce. In the campaign Reports tab this one is grouped as "Blocked by the provider".

On a hard bounce Terlido adds the address to the workspace blocklist with the reason "hard bounce", so no campaign emails it again. The lead stops in that campaign as bounced, its lead score goes down by 15, and the bounce counts toward the campaign's bounce rate.

Once a campaign has at least 20 sends, it pauses itself when hard bounces divided by sends goes over the campaign's maximum bounce rate. The default is 5%. If the cause was on your side and you fixed it, you can remove the entry on the Blocklist page of your account settings and try again.

Terlido treats every 5.x.x code as a hard bounce, so it blocklists the recipient even when the real cause is your own sending setup. After you fix the sending side, remove the entry from the blocklist if you want to contact that person again.

Check the domain behind the bounce

The free domain checker runs live SPF, DKIM, DMARC, MX and blocklist lookups and explains each result in plain English.

Free tools that help

Related error codes

Sources

Connect a mailbox.
Your domain's score lands today.

It costs nothing and doesn't depend on anyone else being on the platform. Warmup runs free on every plan, forever.

Start free
14 days at Multichannel limits, then the Free plan. No card, at any point.