Gmail 550 5.7.26: why your email bounced as unauthenticated, and how to fix it

What 550 5.7.26 means

550 is a permanent rejection, so the message was not delivered and retrying the same message will not help. 5.7.26 is Google's code for an authentication failure. Google's list of SMTP errors shows three different messages under this code, and the wording tells you which part is broken:

• "This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM." Neither SPF nor DKIM passed for this message.
• "The (E)MAIL FROM domain has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks." Your SPF record ends in -all, and the server that sent the message is not listed in it.
• "Unauthenticated email from your domain is not accepted due to domain's DMARC policy." Your DMARC record has a p=quarantine or p=reject policy, and the message failed DMARC, usually because SPF or DKIM did not pass for a domain that matches the From address.

Google also uses 421 4.7.26 for a temporary version, where messages are rate limited rather than rejected outright. Treat it as an early warning of the same problem.

The related codes for bulk senders

Since Google started enforcing its requirements for bulk senders, it has added more specific codes. If you see one of these, the message names the exact requirement you missed:

• 550 5.7.27: the message did not pass SPF.
• 550 5.7.30: the message did not pass DKIM.
• 550 5.7.40: the sending domain has no DMARC record, or the record does not specify a policy.
• 550 5.7.32: the From domain is not aligned with the domain that passed SPF or DKIM.
• 550 5.7.25: the sending IP has no valid PTR (reverse DNS) record. This is usually your provider's job, not yours.
• 550 5.7.29: the message was not sent over TLS.

Each one also has a temporary 421 4.7.x form. Google changes these messages from time to time, so check its current list of SMTP error messages if the wording you see differs.

Step 1: check what your domain publishes

Run your sending domain through the free checker. It looks up your SPF, DKIM, DMARC and MX records in one go. You are looking for:

• Exactly one SPF record, starting with v=spf1, that includes every service that sends as your domain, with no more than 10 DNS lookups. See SPF record too many lookups.
• A DKIM key published for the selector your mail provider uses. See DKIM selector not found in Google Workspace.
• A DMARC record at _dmarc.yourdomain.com that includes a p= tag. See DMARC policy for cold email.

Step 2: read the headers of a real message

DNS records can look right while the message itself still fails, for example when your sending tool signs with its own domain instead of yours. Send a message from the same mailbox and tool you use for outreach to a Gmail account you own. Open it, choose Show original, and read the SPF, DKIM and DMARC lines at the top.

All three should say PASS. Then check the domains: DMARC needs the domain that passed SPF or DKIM to match your From domain. If DKIM shows a domain belonging to your sending tool rather than your own, set up custom DKIM in that tool.

Step 3: fix the most common causes

1. You added a new sending tool or mailbox provider but did not add it to SPF or set up DKIM for it. Add its include to your existing SPF record and publish its DKIM key.
2. You have two SPF records on the same domain. Receivers treat that as an error. Merge them into one.
3. Your SPF record exceeds 10 lookups, which causes a permerror that counts as a fail. Remove includes you no longer use.
4. DKIM was never switched on. In Google Workspace, publishing the TXT record is not enough; you also have to click Start authentication in the admin console.
5. You moved DMARC to p=quarantine or p=reject before every sender passed. Go back to p=none while you fix the senders, then tighten it again.
6. You have no DMARC record at all, which triggers 5.7.40 for bulk senders. Publish at least v=DMARC1; p=none; with a reporting address you read.

Step 4: wait for DNS, then test again

DNS changes can take time to reach every resolver, depending on the record's TTL. Re-run the checker until it shows the new values, send another test to Gmail, and confirm all three checks pass before you resume a campaign. Messages that already bounced will not be retried, so resend only to people you still intend to contact, and remove anyone who has already asked you to stop.

Keep it from coming back

Authentication usually breaks quietly: someone edits DNS, a provider changes its include, or a new tool is connected without DKIM. A daily check of your records catches that before a campaign bounces. OutboxWatch's paid plans re-check SPF, DKIM, DMARC, MX and blacklists every day and flag changes, and the free checker is there for a quick look at any time. For the wider picture, see the cold email deliverability checklist.