When Gmail rejects a message with 550 5.7.26, it is telling you that the message could not be authenticated, so it will not accept it. The text varies slightly. One common version says "This message does not have authentication information or fails to pass authentication checks (SPF or DKIM)". Another says "This mail is unauthenticated, which poses a security risk to the sender and Gmail users, and has been blocked." A third, aimed at larger senders, adds that the message must also pass DMARC. In every case the cause sits in your domain's DNS records or in the way your sending system signs mail, not in Gmail itself. This guide explains what the rejection checks, how to find which check failed by reading the headers, the usual fixes for each cause and a short plan for bulk senders. For the wider list of Gmail rules, see Gmail, Yahoo and Outlook bulk sender requirements.
What Gmail checks before it accepts mail
Gmail looks at three kinds of evidence. SPF asks whether the server that delivered the message is listed in the SPF record of the domain used in the envelope sender (the Return-Path). DKIM asks whether the message carries a valid cryptographic signature from a domain whose public key is in DNS. DMARC asks whether at least one of those two checks passed and was aligned with the domain in the visible From address, and then applies the policy the domain owner published. For all senders, Gmail expects at least SPF or DKIM to pass. For senders who send large volumes to Gmail, the rules are stricter: SPF, DKIM and DMARC must all be set up, with alignment. Our guides on DMARC alignment and email authentication explain the ideas in more depth.
The reply code is permanent, which means the message is not queued for a later retry. If your sending system treats it as a hard failure, the recipient may also be added to a suppression list, so fix the cause before you send again.
Find out which check failed
Do not guess. Send a test message from the same system and the same From address to a Gmail account you control, then open the original message. In Gmail, choose the three-dot menu and then "Show original". The summary at the top shows SPF, DKIM and DMARC as PASS or FAIL with the domain used for each. Below it, the Authentication-Results header gives the details. If the message was rejected and never arrived, use a different test route: send to a Gmail address from a similar path that is accepted, or read the bounce text and your provider's delivery log, which often contains the full reply from Gmail.
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=mg1 header.b=AbCdEf12;
spf=pass (google.com: domain of [email protected] designates 203.0.113.10 as permitted sender) [email protected];
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.comRead each line for three facts: did it pass, which domain was tested and does that domain match the From domain. A pass for a domain that differs from the From domain does not count for DMARC. Our guide to reading email headers shows how to find these lines, and use the SPF, DKIM and DMARC checker to test the records of the domain itself.
Causes and fixes
| What you see | Likely cause | Fix |
|---|---|---|
| spf=fail or softfail, and no DKIM | The sending server is not in the SPF record, or the Return-Path domain has no SPF record | Add the include your provider gives you to the SPF record of the Return-Path domain and keep the record under the 10 DNS lookup limit |
| spf=pass but dmarc=fail | SPF passed for another domain, for example the provider's bounce domain, so it is not aligned | Use a custom Return-Path or enable DKIM signing with your own domain so one method aligns |
| dkim=none | The message was not signed at all | Turn on DKIM signing for your domain in the sending system and publish the DKIM record |
| dkim=fail (signature or key problem) | Wrong selector, a missing or truncated DNS record, or the key was rotated | Publish the exact selector record, check for broken line splits and test again |
| dkim=fail (body hash did not verify) | Something changed the message after it was signed | Find the system that edits mail after signing, or sign last. See the DKIM body hash guide |
| dmarc=fail with p=reject | The domain publishes a strict policy and nothing aligned | Fix alignment first, then keep the policy. Do not loosen it to hide the problem |
| No SPF or DKIM records exist at all | New domain or a domain used by a new tool without setup | Complete the domain setup in your provider before sending |
| Mail forwarded from another address | Forwarding breaks SPF and can alter the message | Rely on DKIM, and read how forwarding and ARC work |
The most common real-world case today is a domain that sends mainly through one provider but also sends from a second tool that was never authenticated: a CRM, a help desk, an invoicing system or a form plug-in. The main provider is set up correctly, so most mail passes. The second tool sends as your domain without a signature, and Gmail rejects exactly that stream. Look at which system produced the failing messages before you change records for the one that works.
Fixing SPF without breaking it
An SPF record is one TXT record that starts with v=spf1. A domain must have exactly one. If you add a second SPF record instead of editing the first, receivers see a permanent error and SPF fails for everything. Put every authorised sender into the single record using include: entries, and end it with ~all or -all. Count the DNS lookups: each include, a, mx and redirect counts, and the total may not exceed ten. A record that goes over the limit returns a permerror. Our guides on SPF records and the 10-lookup limit show how to count and reduce lookups.
Fixing DKIM
DKIM needs two things: a sending system that signs, and a public key in DNS under a selector. Your provider gives you the selector name and the record to publish, usually a TXT or CNAME record at selector._domainkey.yourdomain.com. Publish it exactly, wait for DNS to update and verify it. Common errors are a DNS provider that automatically appends the domain so the record name is doubled, a value broken across lines, and a record added to the wrong zone. Use a key length of at least 1024 bits, and prefer 2048 where your DNS host allows long TXT values. Our guide DKIM records: how to create and test them walks through it.
Fixing alignment so DMARC passes
DMARC passes when either SPF or DKIM passes and the domain that passed matches the visible From domain. With relaxed alignment, a subdomain of the From domain also matches. This is where providers differ. If you send as [email protected] but the Return-Path is a provider domain, SPF passes for the provider and does not align. The usual solution is DKIM signing with example.com or a subdomain, which aligns on its own. A custom Return-Path domain also aligns SPF. We describe the steps in custom Return-Path and tracking domain alignment.
If you send in bulk to Gmail
Gmail's sender guidelines apply to anyone, but they are enforced more strictly for senders who send in volume to personal Gmail addresses. Check each item below, because a missing one produces 550 or 421 responses even when SPF and DKIM pass.
- SPF and DKIM both pass, and the From domain aligns with at least one of them.
- A DMARC record exists, at least
p=none, with a working reporting address. - Marketing and subscribed mail supports one-click unsubscribe with the
List-UnsubscribeandList-Unsubscribe-Postheaders. - Reverse DNS for sending IPs matches a forward lookup, and the connection uses TLS.
- The user-reported spam rate in Google Postmaster Tools stays low. Google advises staying under 0.1% and never reaching 0.3%.
- Messages are formatted to the Internet Message Format standard, with a valid From, Date and Message-ID.
See Google Postmaster Tools setup to watch spam rate and authentication results, and one-click unsubscribe for the headers.
What to do right after you fix it
- Send a new test to a Gmail address and confirm SPF, DKIM and DMARC all show PASS with the right domains.
- Resend the rejected messages only after the test passes. Do not retry thousands of messages while the records are still wrong.
- Check your suppression list. If rejected addresses were suppressed automatically, remove them once you confirm they are valid.
- Monitor DMARC aggregate reports for a week to find other senders that use your domain without authentication.
- Add a calendar reminder to recheck DNS after any change of provider, DNS host or email tool.
Authentication is not a one-time setup. New tools, new subdomains and DNS migrations can break it quietly, and Gmail will show you only a rejection. A weekly look at DMARC reports is the cheapest way to see a failure before your customers do.
Check your domain in seconds Look up your SPF, DKIM and DMARC records and see what receivers see.
References and further reading
Frequently asked questions
What does 550 5.7.26 mean in Gmail?
Gmail rejected the message because it could not be authenticated. SPF and DKIM did not pass, or DMARC alignment failed, so the message was blocked at the SMTP stage.
Is 550 5.7.26 temporary?
No. It is a permanent rejection. Fix the authentication and send again, because Gmail will not retry the same message for you.
Do I need all of SPF, DKIM and DMARC?
Gmail requires SPF or DKIM from every sender. Bulk senders need SPF, DKIM and DMARC with alignment, so setting up all three is the safe choice.
Why does only some of my mail fail?
Usually one tool sends as your domain without being authenticated, such as a CRM or help desk. Check the headers of the failing messages to see which system sent them.
Can I fix this by making my DMARC policy weaker?
A weaker policy does not fix a missing SPF or DKIM pass. Fix the authentication and alignment, then choose a policy based on your risk.