Two different 5.7.26 bounces
Read the text after the code. Gmail uses 5.7.26 for two distinct failures, and they have different fixes:
550-5.7.26 This mail is unauthenticated, which poses a security risk to the 550-5.7.26 sender and Gmail users, and has been blocked. The sender must 550-5.7.26 authenticate with at least one of SPF or DKIM.
Unauthenticated: neither SPF nor DKIM passed for the message. Gmail has nothing to link it to your domain at all.
550-5.7.26 Unauthenticated email from example.com is not accepted due to 550-5.7.26 domain's DMARC policy.
DMARC policy: SPF or DKIM may have passed, but not for a domain that aligns with the From address, and your own DMARC record says to reject such mail. Gmail is doing what you asked.
A 421 4.7.26 is the temporary form, used while a sender is being rate limited for the same reasons. Treat it as a warning that the 550 is coming.
What the rules require
| Requirement | Everyone | Bulk senders (5,000+ a day to Gmail) |
|---|---|---|
| SPF or DKIM passes | Yes, at least one | Both |
| DMARC record published | Recommended | Yes, p=none is enough |
| From domain aligned with SPF or DKIM | Recommended | Yes |
| Forward and reverse DNS for sending IPs | Yes | Yes |
| TLS for transmission | Yes | Yes |
| Spam complaint rate | Under 0.3% | Under 0.3%, ideally under 0.1% |
| One-click unsubscribe (RFC 8058) on marketing mail | No | Yes |
Yahoo's requirements are essentially the same, and Microsoft's consumer mail (Outlook.com, Hotmail) began enforcing similar rules for high-volume senders in 2025 with its own code, 550 5.7.515. Fixing one fixes all three.
Find the cause
Run your sending domain (the one in the From address) through the email deliverability checker. For the unauthenticated bounce, look at:
- SPF. Is there a record, is it valid, and is it under the ten-lookup limit? A record over the limit is a PermError, which receivers treat as no SPF at all. This is the most common hidden cause: the record looks fine and does nothing. The lookup limit guide shows how to get back under.
- Is the sender in SPF at all? A new CRM, helpdesk, invoicing tool or website form sending as your domain, from servers your SPF does not list. The fix is to add the provider's include, or better, send through a subdomain dedicated to that provider.
- DKIM. Does the provider sign with your domain? The checker looks for keys at common selectors; if the provider uses a custom selector, find its
s=value in a real message'sDKIM-Signatureheader and check that the key exists at<selector>._domainkey.example.com.
For the DMARC policy bounce, the question is alignment. Open a message that was delivered somewhere (or a DMARC aggregate report) and read Authentication-Results:
spf=pass smtp.mailfrom=bounces.provider.compasses, but for the provider's domain, not yours. It does not align.dkim=pass header.d=provider.comalso passes for the wrong domain. Most providers can sign as your domain once you publish the CNAMEs or keys they give you; until you do, they sign as themselves.
DMARC needs at least one of those to pass for example.com (or a subdomain of it, with the default relaxed alignment). SPF vs DKIM vs DMARC walks through alignment with examples.
The other requirements
- Reverse DNS. The sending IP needs a PTR record, and that name must resolve back to the same IP. Look up the IP from a bounce's
Receivedheader in the ASN and IP lookup, which shows its PTR. Shared provider IPs have this already; your own servers may not. - A DMARC record. If you send in bulk and have none, publish
v=DMARC1; p=none; rua=mailto:[email protected]today. It changes nothing about delivery for legitimate mail and satisfies the rule. Then use the reports to move on, as in DMARC none vs quarantine vs reject. - Unsubscribe headers. Marketing mail needs both
List-Unsubscribewith an HTTPS URL andList-Unsubscribe-Post: List-Unsubscribe=One-Click. Any mainstream email platform can add them; it is a setting, not DNS. - Complaint rate. Only Google Postmaster Tools shows it. Register the domain there if you send any volume to Gmail.
Before you change DNS
Do not respond to a DMARC bounce by weakening the policy unless you have to. The bounce means the policy is working: something is sending as you without authentication. Fix that sender and the policy can stay. For a quick overall view, Domain Health grades SPF, DKIM and DMARC alongside DNS, TLS and HTTP in one run.