Gmail '550 5.7.26' Error: What It Means and How to Fix It

The 550 5.7.26 error is Gmail's permanent rejection of a message that failed its sender-authentication requirements — usually missing or misaligned SPF, DKIM, or DMARC. Since November 2025, Gmail rejects this mail outright instead of deferring it, so the only fix is correcting your DNS authentication records and alignment. This guide decodes every variant of the bounce and walks you through the fix step by step.

Why the 550 5.7.26 error suddenly appeared everywhere

Before late 2025, Gmail handled non-compliant bulk mail with temporary failures. You'd see a 421 4.7.x deferral, your ESP would retry, and some of the mail eventually got through. That grace period is over.

Since November 2025, Gmail enforces its sender requirements with permanent 5xx rejections. A 5xx code tells the sending server: do not retry, this message is dead. That's why thousands of senders saw the same bounce string land in their logs overnight — the policy didn't change much, the consequence did.

Microsoft made a similar move in May 2025 for Outlook/Hotmail, and Yahoo has been scoring senders on domain reputation since April 2025. So a fix for 550 5.7.26 usually fixes rejections at the other major mailbox providers too.

If you haven't read the full rule set yet, start with our breakdown of the Gmail and Yahoo bulk sender rules — it covers the 5,000-messages-per-day threshold that turns "recommended" into "required."

What does the 550 5.7.26 error actually mean?

SMTP error codes have two parts that matter:

• 550 — permanent failure. The receiving server will not accept the message, ever, in its current state. Retrying changes nothing.
• 5.7.26 — the enhanced status code. 5.7.x is the "security/policy" family. .26 specifically means the message failed authentication requirements.

The full bounce text from Gmail looks something like this:

550 5.7.26 This mail is unauthenticated, which poses a security risk to the
sender and Gmail users, and has been blocked. The sender must authenticate
with at least one of SPF or DKIM. For this message, DKIM checks did not pass
and SPF check for [example.com] did not pass with ip: [203.0.113.10]. The
sender should visit https://support.google.com/mail/answer/81126 for
instructions on setting up authentication.

Read that text carefully. Gmail tells you which check failed and which IP was evaluated. That's your debugging starting point — most people skip it and go straight to randomly editing DNS records.

Every 550 5.7.26 variant, decoded

Gmail uses several message bodies under the same status code. Here's what each one is telling you:

550 5.7.26 vs 550 5.7.1: don't confuse them

A common misdiagnosis. `550 5.7.1` is a different rejection family — it's Gmail telling you the sending IP or domain has a reputation or rate-limit problem ("Our system has detected an unusual rate of unsolicited mail"). Authentication fixes won't touch a 5.7.1; you need to reduce volume, clean your list, and rebuild reputation. `5.7.26` is purely about authentication and alignment. Check which code you actually have before changing anything.

Worked example: reading a real bounce DSN

Here's an anonymized delivery status notification, the kind your MTA or ESP logs:

Reporting-MTA: dns; mail.mysaas.com
Arrival-Date: Mon, 12 Jan 2026 09:14:02 +0000

Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.7.26
Remote-MTA: dns; gmail-smtp-in.l.google.com (142.250.x.x)
Diagnostic-Code: smtp; 550-5.7.26 This mail is unauthenticated, which poses a
 550-5.7.26 security risk to the sender and Gmail users, and has been blocked.
 550 5.7.26 For this message, DKIM checks did not pass and SPF check for
 550 5.7.26 [mail.mysaas.com] did not pass with ip: [198.51.100.22].

Reading it line by line:

1. `Status: 5.7.26` — permanent, authentication-related. No retry logic will help.
2. `DKIM checks did not pass` — either no DKIM signature was present, or the signature didn't verify (bad selector, key mismatch, or a relay modified the message after signing).
3. `SPF check for [mail.mysaas.com] did not pass with ip: [198.51.100.22]` — Gmail evaluated SPF against the envelope-from domain mail.mysaas.com, and the sending IP 198.51.100.22 isn't authorized in that domain's SPF record. Note the bracketed domain: it's the MAIL FROM domain, not necessarily your visible From domain.
4. The IP 198.51.100.22 — check whose IP this is. If it's your CRM, your transactional provider, or a forgotten legacy server, that sender is missing from your SPF record.

This one bounce already gives you the fix list: authorize 198.51.100.22 in SPF for the bounce domain, and get DKIM signing working on that path.

The 550 5.7.26 decision tree

Work through these in order. Stop at the first failure — fixing later steps won't help if an earlier one is broken.

Step 1: Read the sub-text of the bounce

Does it say "unauthenticated," "fails DMARC evaluation," or "PTR record"? That routes you to the right branch below.

Step 2: Does SPF pass for the sending IP?

Look up your record:

dig TXT yourdomain.com +short

You want one (and only one) v=spf1 record that includes every service sending as your domain. Then verify the specific IP from the bounce is covered.

Try it: Paste your domain into the free SPF checker — it expands every include, flags records over the 10-DNS-lookup limit, and shows whether a given IP passes.

Step 3: Does DKIM verify?

Send a message and inspect the DKIM-Signature header, then check the public key:

dig TXT <selector>._domainkey.yourdomain.com +short

Common failures: the selector in the signature doesn't exist in DNS, the key was rotated and DNS wasn't updated, or an intermediate relay (mailing list, security gateway) rewrote the body and broke the signature.

Try it: The free DKIM checker validates the selector and key format instantly.

Step 4: Does DMARC pass — with alignment?

This is where bulk senders (5,000+ messages/day to Gmail) usually get caught. SPF and DKIM can both "pass" while DMARC still fails, because DMARC requires alignment: the domain that passed must match the visible From: domain.

• SPF alignment: the envelope-from (Return-Path) domain must match the From: domain. Relaxed mode allows subdomains of the same organizational domain.
• DKIM alignment: the d= domain in the DKIM signature must match the From: domain. This is the one that survives forwarding, so it's the one to prioritize.

Classic failure: your ESP signs DKIM with d=esp-mail.net and sends with a bounce domain of bounce.esp-mail.net. SPF and DKIM both pass — for their domain, not yours. DMARC sees no alignment and your p=reject (or Gmail's bulk-sender policy) kills the message. The fix is configuring your ESP to sign with d=yourdomain.com and use a custom return path on your domain.

Try it: Check your record with the free DMARC checker. For a deeper alignment walkthrough, see SPF, DKIM, and DMARC explained.

Step 5: Is your complaint rate under control?

Even with perfect authentication, Gmail's bulk-sender rules require a spam complaint rate below 0.1% in Google Postmaster Tools, and you should treat 0.3% as the absolute ceiling. Above that, authentication alone won't save you. Check Postmaster before assuming this is a DNS problem.

Step 6: Is volume or reverse DNS the issue?

If the bounce mentions PTR, verify forward-confirmed reverse DNS:

dig -x 198.51.100.22 +short   # must return a hostname
dig <that-hostname> +short    # must return 198.51.100.22

Both directions must match, and the PTR hostname shouldn't look auto-generated (198-51-100-22.pool.isp.net is a red flag). If you send over IPv6, this check is mandatory, not optional.

The fixes, with exact DNS records

Fix 1: Publish or correct SPF

One TXT record at the apex, covering every legitimate sender:

yourdomain.com.  IN TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.22 -all"

Rules that actually matter:

• Exactly one v=spf1 record per domain. Two records = SPF permerror = fail.
• Stay under 10 DNS lookups. Every include:, a, mx, and redirect counts. If you're over, remove dead vendors or flatten carefully.
• Use -all (hard fail) or ~all (soft fail). Never +all, and ?all is pointless.

Fix 2: Get DKIM signing working on every sending path

Publish the public key your ESP gives you:

s1._domainkey.yourdomain.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…"

Then confirm the ESP signs with d=yourdomain.com — not their own domain. If you run your own MTA, sign with a 2048-bit RSA key and rotate selectors at least annually.

Fix 3: Publish DMARC and make it aligned

Minimum viable record for bulk senders:

_dmarc.yourdomain.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Note that p=none is the floor for Gmail's bulk-sender requirements, not the goal. The real goal is p=quarantine then p=reject once you've verified every legitimate sending source passes alignment. Rushing to reject before auditing sources is how you break your own invoicing system. Our DMARC rollout guide from none to reject has the staged plan.

Fix 4: Repair reverse DNS

Contact your hosting provider or ESP to set the PTR record for your sending IP to a hostname you own (e.g., mail.yourdomain.com), then add an A record for that hostname pointing back to the IP. On shared ESP IPs this is handled for you — if the bounce shows an ESP IP with a PTR complaint, open a ticket with them instead.

Fix 5: Add one-click unsubscribe (bulk senders)

Not a 5.7.26 fix directly, but a hard Gmail requirement that's often missing from the same setups. Marketing and subscribed mail must include:

List-Unsubscribe: <https://yourdomain.com/unsub?u=abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The RFC 8058 one-click POST must work — Gmail tests it.

Verify the fix before you resend

Don't learn from production bounces. Run the full check first:

1. Re-check SPF, DKIM, and DMARC with the tools linked above.
2. Confirm alignment: the d= domain and the Return-Path domain must match your From: domain.
3. Check Postmaster Tools for domain reputation and complaint rate.
4. Send a real test and read the Authentication-Results header — you want spf=pass, dkim=pass, and dmarc=pass with your domain on each line.

Try it: The WillItInbox Gmail sender-compliance checker audits your domain against Gmail's bulk-sender rules in one pass — no signup needed. For the end-to-end check, send a real test email and get 70+ checks across authentication, DNS, headers, and content, with a 0–100 score and prioritized fixes in about 15 seconds. A 550 5.7.26 that survives that test isn't an authentication problem anymore — it's reputation, and that's a different playbook (see why emails land in spam).

550 5.7.26 prevention checklist

• [ ] One SPF record, under 10 lookups, every sending service included
• [ ] DKIM signing on every sending path (ESP, transactional, CRM, helpdesk, your own MTA), signed with d=yourdomain.com
• [ ] DMARC published at _dmarc.yourdomain.com, aligned, with rua reporting so you see failures before Gmail does
• [ ] Valid forward-confirmed PTR on every sending IP (mandatory on IPv6)
• [ ] Complaint rate < 0.1% in Postmaster Tools
• [ ] One-click List-Unsubscribe-Post on all marketing/subscribed mail
• [ ] Quarterly audit of sending sources — new tools get added to your stack all the time, and each one is a potential unauthenticated path