Gmail bounced it: 550 5.7.26 unauthenticated email

550 5.7.26 means the message got all the way to Google and was refused because it did not authenticate. Gmail requires every sender to pass SPF or DKIM. Read the rest of the bounce text before changing anything, because Google publishes three different 5.7.26 messages and they point at three different records.

This is the good kind of failure: the message came back with a code that tells you what to fix.

Which 5.7.26 did you get?

Google lists all three verbatim in its own SMTP error reference. Match your bounce against the first column.

Two neighbours on the same page get mistaken for this one. 550 5.7.24 is "The SPF record of the sending domain has one or more suspicious entries", a malformed record rather than a missing one, and 550 5.7.25 is a missing PTR record on the sending IP. If your code ends in 24 or 25, the fix is different.

What this is not

Ruling these out saves an hour.

• If your record is over the ten-lookup limit, or your domain has two SPF records, SPF produces permerror and cannot pass at all. That is SPF says permerror, too many DNS lookups, and it is the most common reason a record that looks correct does nothing.
• If nothing bounced and nothing arrived, you have a silent failure rather than a rejection, and the sign-in email never arrives traces it.
• If your own relay rejected the login before the message ever left, see 535 username and password not accepted.
• If the connection timed out, your host blocks the SMTP port.

Note the shape of the difference. Everything above happens on your side of the internet. 5.7.26 happens on Google's, which means your sending path works and only your DNS records are wrong.

Why did this start now?

Because the rules changed and then were enforced. Google's sender requirements, in force from 1 February 2024, oblige every sender to Gmail accounts to set up SPF or DKIM, publish valid forward and reverse DNS, use a TLS connection, keep spam complaints in Postmaster Tools below 0.3 per cent, and format messages to RFC 5322.

The first of the three bounce texts is a plain statement of that rule:

This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.

Google Workspace Admin Help, SMTP error reference

Above 5,000 messages a day to Gmail the bar rises: SPF and DKIM, plus a DMARC record. Google is explicit that the policy in that record can be permissive, saying the "enforcement policy can be set to none", so publishing DMARC is not the same as switching on rejection. At that volume the From domain must also align with either the SPF or the DKIM domain.

For a self-hosted support centre this fires at the worst moment. The first customer with a Gmail address votes on something, the notification goes out, and it bounces. Server Fault's question on exactly this stands at 37,299 views, and the DMARC-policy variant has its own question on Stack Overflow at 12,879. Both read through the Stack Exchange API on 23 August 2026.

How do you fix it?

Work through this in order. Most people are done after the second step.

• Find out which check failed, from the bounce text and from a real message. Send yourself a test at a Gmail address you control, open the original message, and read the Authentication-Results header. It names spf, dkim and dmarc separately with a result for each.
• Publish DKIM through your sending provider, if you have not. This is the strongest single fix, because DKIM survives forwarding where SPF does not, and Gmail's baseline requirement is satisfied by either check. Your provider issues a selector and a public key to publish as a TXT record.
• Add the sending service to your SPF record, or correct it if the service moved. Keep it to one record, with one v=spf1 and one all at the end.
• Check alignment if you have the DMARC variant. The domain in the visible From header must match the domain SPF authorised, or the one that signed with DKIM. A message from board@yourdomain.com signed by your provider's own domain passes DKIM and still fails DMARC.
• Confirm the records are actually being served to the outside world, not just saved in a control panel.

dig +short TXT yourdomain.com | grep spf1
dig +short TXT selector._domainkey.yourdomain.com
dig +short TXT _dmarc.yourdomain.com

To watch the whole exchange, including the rejection line itself, send a test message by hand and read Google's replies as they come back:

swaks --to you@gmail.com \
      --from board@yourdomain.com \
      --server smtp.provider.com:587 \
      --tls --auth LOGIN \
      --auth-user 'apikey' --auth-password 'secret'

How do you tell it worked?

Not by the absence of a bounce, which could just mean nobody has emailed a Gmail user today. Check all three of these.

• The headers of a real delivered message. spf=pass, dkim=pass and dmarc=pass in Authentication-Results is the only direct proof.
• Google Postmaster Tools, if you send at any volume. It reports your authentication rates and the spam rate you must keep below 0.3 per cent, and it is the only view of your domain Google's own filters use.
• Your DMARC reports. A DMARC record with a reporting address gets you daily aggregate reports naming every source sending as your domain, including the ones you forgot about.

If it did not work, the usual causes are DNS caching, a record saved on the wrong hostname, or a second SPF record left behind by an earlier attempt. Query a resolver you do not control before assuming the fix failed:

dig +short TXT yourdomain.com @8.8.8.8

One warning about the DMARC variant. If you set a strict policy before SPF and DKIM were reliably passing, moving back to p=none stops the rejections immediately and stops protecting your domain. Fix the alignment, confirm it in the reports, then tighten again.

What a support centre that sends nothing avoids

Worth naming once, at the end rather than in the middle of a fix. This bounce can only happen to a system that sends mail. Docket's free edition does not: it runs as static files plus two endpoints, with no SMTP client in the runtime, so there is no notification to be refused and no sending domain to authenticate. The paid tiers add email notifications, and at that point Gmail's rules apply to a Docket site exactly as they apply to anything else. There is no version of this where publishing the DNS records is optional. SMTP for self-hosted tools is the place to start on those.

Frequently asked questions