Fix Gmail 550 5.7.26 "This Mail Is Unauthenticated"

You send a password reset, an invoice, or a contact-form notification, and a few seconds later a bounce lands in your inbox: 550 5.7.26 This mail is unauthenticated. Or its close relative: 550-5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy. Either way, Gmail refused the message outright. It didn't go to spam. It never arrived.

The good news: this is almost always a DNS and configuration problem, not a content problem, and it can be fixed methodically.

What the 550 5.7.26 error means

Gmail uses the 5.7.26 code when it cannot authenticate a message. Google's SMTP error reference lists several variants, and the wording has changed over time, but they all come back to three mechanisms:

• SPF (Sender Policy Framework, RFC 7208) checks whether the IP address that delivered the message is authorized by the domain in the envelope sender (the MAIL FROM, also called Return-Path).
• DKIM (DomainKeys Identified Mail, RFC 6376) checks a cryptographic signature in the message headers against a public key published in DNS.
• DMARC (RFC 7489) ties the two together. It passes only if SPF or DKIM passes and the authenticated domain aligns with the domain in the visible From: header. The domain owner's DMARC policy (p=none, quarantine, or reject) tells receivers what to do when it fails.

Here is how the common variants map to causes:

• "This mail is unauthenticated" / "the sender is unauthenticated": neither SPF nor DKIM passed. Google's sender guidelines require every sender to authenticate with at least SPF or DKIM, and senders who send around 5,000 or more messages a day to Gmail need both, plus DMARC.
• "Unauthenticated email from domain is not accepted due to domain's DMARC policy": DMARC failed and the From domain publishes p=reject (or p=quarantine, depending on handling). SPF or DKIM may even have passed, but not for a domain aligned with the From address.
• An SPF hard-fail variant: the envelope sender's domain ends its SPF record with -all, and the sending IP isn't listed.

A 421 4.7.26 or 451 4.7.26 is the temporary version (rate limiting or a DNS lookup failure). The fix is the same.

Step-by-step diagnosis

1. Read the full bounce message

Open the non-delivery report and find Gmail's complete SMTP response. It names the domain that failed, which is often not the one you expected. Note three things:

• The domain in the From: header (what recipients see).
• The envelope sender / Return-Path domain (where bounces go).
• The server or service that actually handed the message to Gmail (look at the Received: headers or the "Reporting-MTA").

2. Check SPF

Look up the SPF record for the envelope sender domain. Run it through the SPF checker, or query it directly:

dig +short TXT example.com | grep spf1

Things to look for:

• No record at all. SPF can't pass without one.
• More than one v=spf1 record. RFC 7208 treats this as a permanent error, so SPF effectively fails. This is extremely common when a second service tells you to "add this SPF record" and you add a new one instead of editing the existing one.
• The sending service is missing. If your app sends through an ESP but your record only includes your web host, the ESP's IPs aren't authorized.
• Too many DNS lookups. SPF evaluation is limited to 10 DNS-querying mechanisms (include, a, mx, exists, redirect, and so on). Exceeding it produces a permanent error.

3. Check DKIM

DKIM keys live at selector._domainkey.example.com. You need the selector, which you can find in the DKIM-Signature: header of a sent message (the s= tag) or in your provider's dashboard. Plug the domain and selector into the DKIM checker, or run:

dig +short TXT google._domainkey.example.com

Common failures: the message isn't signed at all, the key was never published, the published key was truncated when pasted into the DNS panel, or the message is signed with the provider's own domain (for example d=sendgrid.net) instead of yours. That last one passes DKIM but won't align for DMARC.

4. Check DMARC

Your DMARC record lives at _dmarc.example.com. The DMARC checker will parse it and show the policy, alignment modes, and reporting addresses. If the bounce mentions "domain's DMARC policy," look closely at the p= value. A p=reject policy is doing its job; the real question is why your legitimate mail failed alignment.

5. Check alignment with the From domain

This step is often skipped, and it's usually where the problem lives. DMARC requires that the domain that passed SPF or DKIM matches the From: domain:

• SPF alignment compares the Return-Path domain with the From domain.
• DKIM alignment compares the d= domain in the signature with the From domain.

By default, DMARC uses relaxed alignment, so mail.example.com aligns with example.com. Strict mode (aspf=s or adkim=s) requires an exact match. A typical failure: your From address is noreply@example.com, the Return-Path is bounces@esp-provider.net, and the DKIM signature is d=esp-provider.net. Both SPF and DKIM pass, for the wrong domain, and DMARC fails.

6. Identify the sending service

• Shared hosting mail (cPanel, PHP mail()): the server's IP may not be in your SPF record, and DKIM is often disabled by default or signed for the server hostname rather than your domain. Check the hosting panel's email authentication or deliverability section.
• Transactional ESPs (SendGrid, Mailgun, Amazon SES, Postmark, Brevo, and similar): you usually need to complete their "domain authentication" step, which gives you CNAME or TXT records for DKIM and often a custom Return-Path subdomain. Until you do, mail is signed with their domain and won't align.
• Google Workspace: SPF needs include:_spf.google.com, and DKIM must be generated in the Admin console and then explicitly turned on after you publish the record. Publishing the TXT record alone doesn't start signing.

How to fix it

Merge SPF into a single record

If you send from Google Workspace and a transactional ESP, don't publish two records. Combine them into one:

; Wrong: two separate SPF records
example.com.  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  TXT  "v=spf1 include:sendgrid.net ~all"

; Right: one merged record
example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Use the exact include value your provider documents. Near the 10-lookup limit, remove includes for services you no longer use before trying "SPF flattening," which hard-codes IPs that can go stale.

Set up DKIM through your provider

You don't write DKIM keys by hand. Each provider generates them:

• Google Workspace: Admin console, then Apps, Google Workspace, Gmail, Authenticate email. Generate a key (2048-bit if your DNS host supports it), publish the TXT record at the selector it shows (by default google._domainkey), wait for DNS to propagate, then click Start authentication.
• ESPs: complete the domain authentication wizard. Most give you CNAME records like the following, which point to keys they rotate for you:

s1._domainkey.example.com.  CNAME  s1.domainkey.u1234.wl.sendgrid.net.

(The hostnames above are illustrative. Copy the exact values from your own dashboard.)

• Shared hosting: enable DKIM in the email deliverability tool and, if your DNS is hosted elsewhere such as Cloudflare, copy the generated TXT record there.

Publish a starter DMARC record

If you don't have DMARC yet, start in monitoring mode so you can see who sends as your domain without blocking anything:

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

You can build this with the DMARC generator. Once the aggregate reports show all your legitimate sources passing with alignment, move to p=quarantine and later p=reject. If p=reject is bouncing legitimate mail, you can temporarily relax it while you fix alignment, but that's a stopgap, not the fix.

Forwarding and mailing-list caveats

Some 5.7.26 bounces aren't your fault in the usual sense. When a message is forwarded (for example, a university alias forwarding to Gmail), the forwarding server's IP isn't in your SPF record, so SPF fails. DKIM usually survives forwarding as long as the message isn't modified, which is one big reason to sign with DKIM and not rely on SPF alone.

Mailing lists often add a subject tag or footer, which breaks DKIM. Modern list software compensates by rewriting the From header to the list's domain or adding ARC (Authenticated Received Chain) headers. If mail bounces only through a specific list or forwarder, the fix belongs to its operator.

Verify the fix

DNS changes can take time to propagate depending on the TTL, so wait a bit and recheck with the SPF, DKIM, and DMARC checkers. Then send a real test message to a Gmail address you control, open it, click the three-dot menu, and choose Show original. At the top, Gmail shows a summary:

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

You want all three to pass, and you want the DKIM domain to be yours (or a subdomain of yours), not your provider's. Repeat the test for every system that sends as your domain.

Quick checklist

1. Read the full bounce and note the From domain, Return-Path domain, and sending server.
2. Confirm exactly one SPF record exists and it includes every sending service.
3. Stay under 10 DNS lookups in SPF.
4. Enable DKIM signing with your own domain at every provider.
5. Publish a DMARC record, starting with p=none plus reporting.
6. Verify SPF or DKIM aligns with the From domain.
7. Send a test to Gmail and confirm SPF, DKIM, and DMARC show PASS in "Show original."
8. Tighten DMARC gradually once reports look clean.

FAQ

Do I need both SPF and DKIM to stop 550 5.7.26?

Google's minimum is SPF or DKIM; bulk senders need both plus DMARC. Set up both anyway: DKIM survives forwarding, and two aligned mechanisms give DMARC two chances to pass.

SPF and DKIM both pass, so why does DMARC still fail?

Almost always an alignment issue. SPF and DKIM passed for your email provider's domain, not for the domain in your From header. Complete the provider's custom domain authentication so DKIM signs with d=yourdomain.com, or set up a custom Return-Path on your domain.

Should I use ~all or -all in SPF?

With DMARC in place, DMARC decides the outcome. Many admins use ~all (softfail) so forwarded mail isn't rejected on SPF alone. Use -all only when your record lists every legitimate sender.

How long until the bounces stop?

It depends on your DNS TTLs. Once a test message shows PASS in "Show original," new messages should be accepted. Messages that already bounced must be resent.

Can I fix this from the recipient side?

Generally, no. The rejection happens during the SMTP conversation, before the message reaches anyone's inbox, so a Gmail user's filters or contacts can't override it. The owner of the sending domain has to fix authentication. If you're the recipient, forward the bounce text to the sender's IT team.