What Gmail 5.7.26 means
Gmail uses 5.7.26 for several permanent authentication-related rejections. The exact text in the SMTP response matters: it may point to unauthenticated mail, an SPF hard-fail mismatch or a DMARC policy decision.
A DNS scan can expose configuration issues that contribute to these rejections, but it cannot prove why one message was rejected. Confirm the result against the complete bounce and the message's Authentication-Results headers.
Common causes
SPF does not pass
The sending IP is absent from the evaluated SPF path, or a strict -all policy rejects it.
DKIM does not verify
The message is unsigned, the selector is missing, or the signature does not validate.
DMARC fails
Neither the SPF-authenticated domain nor the DKIM signing domain aligns with the visible From domain.
Domain policy rejects failures
A DMARC enforcement policy can tell receivers to reject mail that fails aligned authentication.
How to fix it
- Read the complete Gmail bounce and identify which authentication result is named.
- Authorize the actual sending service in one valid SPF record and stay within the DNS lookup limit.
- Enable DKIM in the sending provider, publish its exact selector and verify that outgoing mail is signed.
- Check DMARC alignment using headers from a real message; DNS records alone cannot establish message-level alignment.
- Retest after DNS propagation and compare the new authentication results with the original rejection.
FAQ
No. It checks public SPF, discoverable DKIM and DMARC signals that can contribute to 5.7.26. The exact bounce and message headers are needed to confirm the cause.
Yes. DMARC also requires the SPF-authenticated domain or a valid DKIM signing domain to align with the visible From domain.
DKIM selectors are chosen by the sending provider and are not discoverable generically. The scan tries known selectors when it can identify the provider, but custom selectors require message headers or provider settings.