Fix Gmail 550 5.7.26 Unauthenticated Email

What Gmail is rejecting

Gmail stopped the message before it reached the inbox. A 550 5.7.26 bounce means Gmail could not authenticate the sender well enough to accept the mail.

The first place to look is the bounce text. If it says the message is unauthenticated, treat it as an SPF, DKIM, or DMARC problem until the headers prove otherwise.

Google's sender guidelines require every sender to personal Gmail accounts to pass SPF or DKIM. Bulk senders, meaning senders that send more than 5,000 messages per day to personal Gmail accounts, must use SPF, DKIM, and DMARC. Google says unauthenticated messages may be marked as spam or rejected with a 5.7.26 error.

Do not change your copy, buy a new domain, or switch email platforms first. Prove that Gmail can tell who sent the message and that the authenticated domain matches the visible From domain.

Fast fix checklist

Work from DNS to message headers. SPF authorizes the sending server. DKIM signs the message. DMARC checks whether SPF or DKIM lines up with the From address.

• Publish one SPF TXT record for the sending domain. Include each real sender: Google Workspace, Microsoft 365, your help desk, CRM, billing app, and email platform.
• Keep SPF under the RFC 7208 limit of 10 DNS lookups. Includes inside includes count. If SPF needs more than 10 lookups, receivers can return permerror and SPF stops helping.
• Use ~all while you are still finding senders. Move to -all only after every real source is covered. Never publish +all.
• Turn on DKIM in every service that sends mail. Publish the selector record exactly as the provider gives it, usually at selector._domainkey.yourdomain.
• Send a fresh test message and check the headers. You want a DKIM-Signature header and an authentication result that says DKIM passed.
• Add DMARC at _dmarc.yourdomain. A safe first record is v=DMARC1; p=none; rua=mailto:dmarc@yourdomain. Read reports before moving to quarantine or reject.
• Check alignment. DMARC passes when SPF or DKIM passes and the authenticated domain aligns with the From domain the recipient sees.
• Check MX if the domain receives mail. Bad MX usually does not cause 5.7.26 by itself, but unmanaged DNS often means SPF, DKIM, or DMARC is broken too.
• For direct SMTP, check forward and reverse DNS. Google asks senders to have valid PTR and matching forward DNS records.

A free InboxRadar domain check can read live SPF, DKIM, DMARC, and MX records and point to the record most likely to be causing the rejection.

Why SPF can pass and Gmail can still reject

SPF checks the envelope sender, often called the return-path. Recipients see the From address. Those domains can be different.

Many email tools send through their own return-path domain until you set a custom bounce domain. Gmail may see SPF pass for the tool's domain, while your message shows news@example.com in the From header. DMARC needs the passing SPF domain or the passing DKIM domain to align with example.com.

DKIM is often the cleaner fix because it travels with the message. If your email platform signs with your domain, forwarding is less likely to break authentication. Use a 2048-bit DKIM key when your DNS host and mail provider support it. Google requires DKIM keys of at least 1024 bits for mail sent to personal Gmail accounts.

For the protocol rules, use RFC 7208 for SPF, RFC 6376 for DKIM, and RFC 7489 for DMARC. For mailbox-provider rules, use the current Google and Microsoft sender guidelines.

How to use DMARC reports

DMARC aggregate reports show which systems are sending as your domain and whether their SPF, DKIM, and alignment checks pass.

Start with p=none if you have several senders. Collect RUA reports, map each real source, then fix the missing ones. After your normal mail passes, move toward quarantine or reject. Use pct= only when you need a staged rollout.

The reports arrive as XML and are hard to read by hand. Use the free DMARC report reader to turn RUA files into source names, pass rates, and alignment failures.

After authentication passes

Authentication gets you past Gmail's identity check. It does not erase bad reputation.

Keep spam complaints low. Google tells senders to keep Postmaster Tools spam rates below 0.10% and avoid 0.30% or higher. Use TLS, valid Message-ID headers, honest From names, and one-click unsubscribe for marketing or subscribed bulk mail. Send only to people who asked for mail.

Shared IP reputation and blocklists can still hurt delivery after SPF, DKIM, and DMARC pass. Google says messages from blocklisted shared IPs are more likely to be marked as spam. Microsoft also checks SPF, DKIM, and DMARC, then weighs reputation, content, user complaints, and other signals. If Gmail rejects with 5.7.26 and Outlook sends mail to junk, fix authentication first, then check reputation.

AI search visibility check

If this page is your public fix doc, make sure AI search crawlers can reach and read it.

For live AI answers, allow the search crawlers that power the answer engines: OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews through the normal Search index, and Applebot for Apple Intelligence. Disallowing these in robots.txt removes you from that engine.

GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not remove you from live AI search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent.

A robots.txt file is a site's stated policy, not proof of what a crawler did. Perplexity-User and Bytespider are reported to ignore robots.txt, so use server logs as evidence and avoid claiming what a bot did without logs.

Only Googlebot documents JavaScript rendering. If your answer is client-side-only, other AI crawlers may miss it. Treat that as an undocumented risk, not proof that a named bot cannot run JavaScript. You can check access with the free AI visibility checker.