Gmail 550 5.7.26 "This email has been blocked because the sender is unauthenticated" - How to Fix

Mail to Gmail bouncing with 550 5.7.26? Gmail rejected it because the message was unauthenticated. Check your domain in one pass to see which of SPF, DKIM or DMARC is the problem, then use the fixes below.

The Error

Gmail uses 550 5.7.26 for three different failures. The bounce text tells you which one you hit.

Neither SPF nor DKIM passed:

550-5.7.26 This email has been blocked because the sender is unauthenticated.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26
550-5.7.26  Authentication results:
550-5.7.26  DKIM = did not pass
550-5.7.26  SPF [example.com] with ip: [203.0.113.10] = did not pass
550-5.7.26
550-5.7.26  For instructions on setting up authentication, go to
550 5.7.26  https://support.google.com/mail/answer/81126#authentication - gsmtp

SPF hard fail:

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

DMARC policy:

550-5.7.26 Unauthenticated email from example.com is not accepted due to domain's
550-5.7.26 DMARC policy. Please contact the administrator of example.com domain if
550-5.7.26 this was a legitimate mail. To learn about the DMARC initiative, go to
550 5.7.26  https://support.google.com/mail/?p=DmarcRejection - gsmtp

The domain and IP in the bounce are the ones Gmail checked. The domain in the first two variants is the envelope sender (the Return-Path), which is not always the address in From:.

Why This Happens

Gmail requires every sender to pass SPF or DKIM, and since February 2024 anyone sending more than 5,000 messages a day to Gmail accounts must pass SPF, DKIM and publish DMARC, with the From: domain aligned to one of them. Gmail first rate-limited unauthenticated mail with temporary 4.7.26 deferrals. Now it rejects it with a permanent 550 5.7.26.

In order of how often each is the cause:

1. A sending service missing from SPF - a CRM, helpdesk or app server sending as your domain but not listed in the record
2. DKIM not turned on - Google Workspace and many platforms do not sign with your domain until you enable it
3. DMARC alignment failure - SPF and DKIM pass, but for the platform's domain rather than yours
4. Sending as a domain you do not control - a gmail.com or yahoo.com From: address sent through your own server hits that domain's DMARC p=reject
5. Forwarding - a forwarder breaks SPF by changing the IP and breaks DKIM by editing the message

Fix 1: Find Out What Failed

If you can get any message through to a Gmail address you control, open it, choose Show original, and read the summary:

SPF:   FAIL with IP 203.0.113.10
DKIM:  'FAIL' with domain example.com
DMARC: 'FAIL'

If every message is rejected, check the published records instead. The Email Deliverability Checker reads MX, SPF (syntax and the 10-lookup limit), DKIM at common selectors, DMARC and reverse DNS in one report. Or from a terminal:

dig +short TXT example.com | grep spf1
dig +short TXT google._domainkey.example.com
dig +short TXT _dmarc.example.com

Match the result to the bounce variant above, then go to the matching fix.

Fix 2: Authorise Every Sender in SPF

Publish exactly one SPF record at the domain root that lists every service sending as the domain:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

• Add the missing sender. The IP in the bounce tells you which system sent the rejected message. Find its provider's include value in their setup documentation.
• Stay under ten DNS lookups. Each include, a, mx and exists counts, including lookups nested inside includes. Over ten is a PermError and SPF fails everywhere. See SPF PermError: too many DNS lookups.
• Never publish two SPF records. Merge them.

The second bounce variant, the -all hard fail, means your record is doing its job against a sender you forgot. Add the sender. Do not loosen the record to +all.

Use the SPF Record Generator to build the record.

Fix 3: Sign With DKIM on Your Own Domain

DKIM is the more robust of the two: the signature travels with the message, so it survives forwarding where SPF does not.

For Google Workspace:

1. Admin console: Apps > Google Workspace > Gmail > Authenticate email
2. Generate a 2048-bit key and publish the TXT record at google._domainkey
3. Wait for DNS, then click Start authentication

For Microsoft 365, publish the two selector1 and selector2 CNAME records from the Defender portal and enable DKIM signing for the domain.

For every other platform (marketing, CRM, helpdesk), use its "authenticate your domain" or "custom DKIM" setting. Without it, the platform signs as itself, which passes DKIM but does nothing for your DMARC.

Gmail requires DKIM keys of at least 1024 bits. If the bounce says DKIM = did not pass while a key is published, see DKIM fail: no key for signature and DKIM body hash did not verify.

Fix 4: Publish DMARC and Align the Domains

Bulk senders must publish a DMARC record. p=none meets the requirement:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Publishing it does not make DMARC pass. DMARC passes only when SPF or DKIM passes for a domain that matches the From: address:

• DKIM alignment: the d= domain in the DKIM-Signature matches the From: domain. Fix it with custom DKIM at each platform (Fix 3).
• SPF alignment: the Return-Path domain matches the From: domain. Fix it with a custom bounce or return-path domain at the platform.

One aligned pass is enough. If SPF and DKIM both pass and DMARC still fails, this is the reason. See DMARC fail but SPF and DKIM pass. Build the record with the DMARC Record Generator.

If the bounce names a domain you do not own, such as gmail.com, you are sending as someone else's domain. Change the From: address to one on your own domain.

Fix 5: Forwarding and Mailing Lists

When mail is forwarded to Gmail, the forwarder's IP is not in the original sender's SPF record, so SPF fails. DKIM still passes if nothing edits the message. If a list adds a footer or a [list] subject tag, DKIM fails too, and a strict DMARC policy gets the copy rejected with 5.7.26.

Google's guidance for anyone running a forwarder, mailing list or inbound gateway:

• Rewrite the envelope sender to the forwarding domain, so SPF is checked against the forwarder
• Do not modify the body or the DKIM-signed headers (Subject, To, Cc, Date, Message-ID)
• Add ARC headers, which record the authentication results the forwarder saw. Gmail still runs its own checks, so ARC supports a pass but does not guarantee one
• Mailing lists should add a List-Id: header

If you are the original sender, the defence is DKIM on your own domain: an unmodified, aligned DKIM signature passes DMARC however many hops the message takes.

Verify the Fix

1. Re-run the Email Deliverability Checker and confirm SPF, DKIM and DMARC show no failures
2. Send a new message from the system that bounced to a Gmail address you control
3. Show original should read:

SPF:   PASS with IP 203.0.113.10
DKIM:  'PASS' with domain example.com
DMARC: 'PASS'

The domains on the DKIM line and in your From: address should match. Gmail does not retry rejected messages, so resend anything that bounced.

Prevention

• Add every new sending service to SPF and set up its custom DKIM before it sends its first message
• Keep a rua= address on your DMARC record and read the aggregate reports monthly. A new unaligned source shows up there before it shows up as bounces
• Stay under 8 SPF lookups to leave room for a provider adding a nested include
• Send bulk mail from a subdomain (for example news.example.com) so a marketing platform's problems cannot take down your main domain's mail
• Bulk senders also need one-click unsubscribe and a spam rate below 0.30% in Postmaster Tools. If authentication passes but mail is still blocked, the bounce usually becomes 550-5.7.1 "Message blocked", which is a reputation problem

Summary

1. Read the bounce: no SPF/DKIM pass, SPF hard fail, or DMARC policy
2. SPF: one record, every sender listed, ten lookups or fewer
3. DKIM: enable signing on your own domain at every platform, 2048-bit keys
4. DMARC: publish at least p=none and align SPF or DKIM with the From: domain
5. Forwarding: rewrite the envelope sender, leave signed content alone, add ARC
6. Verify: check the domain, then confirm with Show original