550 5.7.26: Gmail Says the Sender Is Unauthenticated

A 550 5.7.26 bounce means Gmail refused your email because it could not confirm it really came from your domain. It happens to businesses whose domain’s email records are missing, out of date or don’t cover every system that sends email for them. The fix is on your side, in your domain’s DNS records, not in the email itself.

The bounce usually comes from ‘Mail Delivery Subsystem’ and contains one of three messages, each starting 550 5.7.26. At the time of writing (last checked 6 October 2026), Google’s wording is:

1. Neither SPF nor DKIM passed

550 5.7.26 This email has been blocked because the sender is
unauthenticated. Gmail requires all senders to authenticate with
either SPF or DKIM. Authentication results: DKIM = did not pass
SPF [yourbusiness.co.uk] with ip: [192.0.2.10] = did not pass.

2. Your SPF record says ‘hard fail’ and SPF failed

550 5.7.26 The (E)MAIL FROM domain [yourbusiness.co.uk] has an SPF
record with a hard fail policy (-all) but it fails to pass SPF checks
with the ip: [192.0.2.10]. To best protect our users from spam and
phishing, the message has been blocked.

3. Your DMARC policy says refuse

550 5.7.26 Unauthenticated email from yourbusiness.co.uk is not
accepted due to domain's DMARC policy. Contact the administrator of
yourbusiness.co.uk domain if this was legitimate email.

Google usually adds a sentence pointing to one of its help pages, and the line breaks vary. The code 5.7.26 is what matters. If you see 421 4.7.26 or 451 4.7.26 instead, Gmail has held your email back for now for the same reason; fix it the same way before it becomes a refusal.

Gmail checks every email against three records published on the sender’s domain: SPF (which servers may send for the domain), DKIM (a digital signature) and DMARC (the domain’s policy for emails that fail). Since February 2024, Gmail requires every sender to pass SPF or DKIM, and senders of large volumes to pass both and have DMARC.

Message 1 means your email passed neither SPF nor DKIM. Message 2 means your SPF record ends in -all, which tells receivers to refuse anything not on the list, and the server that sent this email was not on it. Message 3 means the email failed your own domain’s DMARC policy, which tells Gmail to refuse such emails. In every case Gmail is following the rules your domain’s records set, and rewriting the email will not help.

If someone emailing you gets this bounce, the problem is on their side, with their domain’s records. Point them to this page.

1. Something new sends email as your domain. An invoicing, booking or CRM system, a newsletter tool or a new email provider sends emails ‘from’ your address, but your SPF record doesn’t list it and DKIM wasn’t set up for it. This is the most common cause. It usually affects only the emails that system sends, while your normal email still arrives.
2. DKIM was never switched on. Microsoft 365 and Google Workspace both sign emails with their own domain until you switch on DKIM for yours. Email works without it, so it is easy to miss. My guide to spam after moving to Microsoft 365 or Google Workspace shows how to switch it on.
3. Your SPF record is broken or out of date. Two SPF records on one domain, a typing error, or a record that still names the old provider after a move. Two SPF records make both invalid. If the record ends in -all, anything it misses is refused outright (message 2).
4. The email was forwarded. If an address forwards email on to a Gmail address, the forwarded copy arrives from the forwarding server, not the original sender’s, so SPF fails. If DKIM doesn’t survive the forwarding either, Gmail may refuse it. This explains bounces that only happen for one forwarded address.
5. A strict DMARC policy before everything was ready. If your domain’s DMARC record says p=quarantine or p=reject while some system still sends without passing SPF or DKIM, those emails are refused.

1. Read the full bounce. Note which address sent the email, which system it came from (your normal mailbox, a website form, an app) and which of the three messages above you got.
2. List everything that sends email as your domain: your email provider, your website, accounts or booking software, any newsletter tool, and devices such as scanners.
3. Check your SPF record. Use any free DNS lookup tool to view the TXT records on your domain. There must be exactly one starting v=spf1, and it must include every service on your list, for example include:_spf.google.com for Google Workspace or include:spf.protection.outlook.com for Microsoft 365. Each service’s help pages give its own value.
4. Switch on DKIM for each service. Each one gives you a record to add to your DNS, usually named with ._domainkey. Copy it exactly.
5. Check your DMARC record. If you have none, start with v=DMARC1; p=none; rua=mailto:you@yourbusiness.co.uk, which monitors without blocking. If you have p=quarantine or p=reject, fix steps 3 and 4 first.
6. For forwarded email, stop forwarding to Gmail where you can. Make the address an alias in your main mailbox, or add the account to Gmail directly instead of forwarding.

DNS changes usually take effect within an hour, and occasionally up to 48 hours.

1. Send a normal email from the address that bounced to a personal Gmail address.
2. In Gmail, open it, click the three dots and choose ‘Show original’.
3. Near the top, Gmail shows SPF, DKIM and DMARC. You want PASS for all three, with your own domain named next to DKIM.

Repeat the test for each system that sends as your domain, such as your website’s contact form. My guide to reading email headers explains the details.

If your domain has one email provider and nothing else sends for it, the steps above are usually a 15-minute job. It gets harder when several systems send as your domain, when you can’t find where your DNS is managed, or when the bounces only affect some emails. That is when an outside check saves time.

• Why emails bounce, for other bounce codes.
• What is SPF, DKIM and DMARC?, for how the three records work together.
• Google, Yahoo and Microsoft email rules, for what each provider expects.

Need help fixing this?

I provide:

• Free initial assessment
• Clear explanation of the issue
• Fixed-price solutions
• UK-based support

Forward me the 5.7.26 bounce and I’ll find which record is failing and put it right.