Gmail 5.7.26 error: why Gmail says your email is unauthenticated

Quick answer

Gmail 5.7.26 means Gmail rejected the message because sender authentication did not satisfy its policy for that message. Check SPF, DKIM, and DMARC together. A valid DNS record is not enough if the real sending platform is not authorized, not signing, or not aligned with the visible From domain.

What Gmail 5.7.26 usually means

Gmail 5.7.26 is an authentication-focused rejection. In plain language, Gmail is saying: this message claims to be from a domain, but the technical proof was missing, invalid, or not aligned enough to accept the message.

Google's sender guidelines explicitly connect unauthenticated mail to possible spam placement or rejection with a 5.7.26 error. Treat the code as an authentication evidence path first, not as a generic deliverability complaint.

The fix is not usually a subject-line tweak. Start by proving that the domain's public records match the way mail is actually sent. SPF must authorize the real outbound servers. DKIM must be enabled by the sending platform and publish a usable public key. DMARC must find aligned SPF or aligned DKIM for the visible From domain.

If you recently changed ESPs, added a newsletter platform, moved DNS, started using Google Workspace or Microsoft 365, or changed the From domain, this error often appears because the new sending path was not fully authenticated.

Step 1: Identify the domain Gmail rejected

The domain that matters is usually the visible From domain, not necessarily the provider you used to send. If the message says it is from news@example.com, then Gmail evaluates whether example.com is authenticated and aligned.

Do not only check the domain of the mail server. An ESP may send from its own infrastructure while authenticating your domain through DNS records. The configuration has to connect those two things.

If you have the full bounce message, keep it. The exact text can identify whether Gmail complained about missing authentication, failed authentication, DMARC policy, rate, or another policy issue.

Step 2: Check SPF for the real outbound sender

SPF authorizes outbound mail sources through a DNS TXT record as described by RFC 7208. A correct SPF record for one platform does not authorize every platform you use.

Common SPF causes of Gmail 5.7.26 include:

• No SPF record at all.
• Multiple SPF records for the same domain.
• A syntax error that makes SPF invalid.
• The real ESP or mail host is missing from the record.
• Too many DNS lookups, causing SPF PermError.
• Confusing MX records with outbound senders.

If you use several platforms, merge their authorized mechanisms into one SPF record. Do not publish multiple separate SPF TXT records. Receivers generally treat multiple SPF records as an SPF failure condition.

Step 3: Check DKIM signing, not only the DNS key

DKIM, defined in RFC 6376, requires two parts: DNS publishes the key, and the sending platform signs the message. A DKIM record can exist while real mail is still unsigned.

Check whether your sending platform has DKIM enabled for the same domain users see in the From address. For Google Workspace, Microsoft 365, and most ESPs, this usually means adding provider-specific DNS records and then turning on authentication inside the provider admin UI.

If DKIM fails while the DNS record looks right, inspect a real message header. The selector might be wrong, the platform might be signing with a different domain, or forwarding/message modification might be breaking the signature.

Step 4: Check DMARC alignment

DMARC, defined in RFC 7489, is where many "but SPF and DKIM pass" cases break. DMARC does not only ask whether SPF or DKIM passed. It asks whether the domain that passed aligns with the visible From domain.

For Gmail 5.7.26, this matters because a third-party sender may authenticate itself correctly but not authenticate your domain. That can still fail the visible sender's DMARC requirement.

Examples:

• SPF passes for a return-path domain owned by your ESP, but that domain does not align with your From domain.
• DKIM passes for esp.example.net, but the message From domain is example.com.
• Your DMARC record is strict while a legitimate sender is still configured with a non-aligned domain.

The safest fix is to configure the ESP to authenticate your domain directly, usually through custom DKIM and a provider-approved return-path or bounce domain.

Step 5: Check whether DNS has propagated

DNS changes are not instant for every resolver. If you just added SPF, DKIM, or DMARC, Gmail and other receivers may still see cached older data until TTLs expire.

That said, do not assume every 5.7.26 is propagation. Recheck the record from an external tool. If the public record still looks wrong, fix DNS. If the public record looks right, inspect the real sending platform and message headers.

Step 6: Do not resend the same failed campaign blindly

Repeatedly sending the same failing message can make the incident noisier. Fix authentication first, then test with a small number of messages and inspect headers. If the mail passes authentication but still filters to spam, you have moved from an authentication rejection problem to a reputation/content/engagement problem.

That second problem needs different evidence: Gmail message headers, Google Postmaster Tools, complaint data, list quality, sending-volume history, and message content review.

How to fix Gmail 5.7.26

1. Run a full domain report for the visible From domain.
2. Fix SPF so one TXT record authorizes the real outbound platform.
3. Enable DKIM signing for the visible From domain in the sending platform.
4. Publish or correct DMARC after SPF/DKIM are in place.
5. Confirm DMARC alignment, not only SPF/DKIM pass.
6. Wait for DNS TTL where needed, then send a small test.
7. Inspect Gmail headers to verify spf=pass, dkim=pass, and dmarc=pass.

What this does not prove

Fixing 5.7.26 does not guarantee inbox placement. It fixes an authentication rejection path. Gmail can still filter accepted mail based on reputation, complaint rate, sending velocity, recipient behavior, and content.

Relaymetry checks the public technical baseline. It cannot see Gmail's private reputation model, your subscriber engagement, or the exact content classifier result for a campaign.

FAQ

Does 5.7.26 always mean DMARC failed?

No. It can involve SPF, DKIM, DMARC, or the relationship between them. DMARC alignment is common, but check all three.

Can SPF pass and Gmail still reject with 5.7.26?

Yes. SPF might pass for a domain that does not align with the visible From domain, or DKIM/DMARC may still fail.

Do I need both SPF and DKIM?

For modern sender requirements, you should configure both where possible. DMARC can pass with either aligned SPF or aligned DKIM, but relying on one path leaves less margin for forwarding, provider changes, and strict receiver policies.

Should I delete DMARC to stop the rejection?

Do not remove DMARC as a first fix. Correct authentication and alignment instead. Removing DMARC can reduce protection against spoofing and may conflict with sender requirements.

Related guides

• Why Gmail rejects emails — full pillar diagnostic
• SPF, DKIM, and DMARC pass but Gmail sends email to spam — when auth passes but placement fails
• New domain emails going to Gmail spam — reputation builders for new domains
• SPF Checker — validate SPF authorization
• DKIM Checker — inspect DKIM signing
• DMARC Checker — DMARC policy + alignment