Learn · Fixing a bounce
550 5.7.26: what the bounce means and how to fix it
Your mail is bouncing right now with 550 5.7.26 and a line about unauthenticated email. The good news is that this code is unusually specific: it is always an authentication failure, never a spam judgement, never a blocklist, never a reputation problem. The awkward news is that two different failures share the code, they have opposite fixes, and the wording of your bounce tells you which one you have.
Read your bounce first
Find the message. It will look like one of these two:
550 5.7.26 Unauthenticated email from example.com is not
accepted due to domain's DMARC policy.…or:
550-5.7.26 Your email has been blocked because the sender is
unauthenticated. Gmail requires all senders to authenticate
with either SPF or DKIM.The first says a domain published a policy and you failed it. The second says you published nothing at all. Everything below splits on that.
What 5.7.26 never means: it is not a spam score, not a blocklist listing, not a rate limit, and not a content problem. Rewriting the subject line, removing links or waiting it out will not clear it. The receiver checked your authentication and it did not pass.
Case 1: "not accepted due to domain's DMARC policy"
The receiver looked up the domain in your From: header, found a DMARC record at quarantine or reject, checked whether your message authenticated for that domain, and it did not. So the receiver did exactly what the record asked.
The critical question is whose domain is in the From header, because that decides who can fix it.
If it's your own domain
You are sending through a service that is not authenticated for you. The service delivers the mail perfectly well — it just authenticates as itself, so nothing aligns to your domain and your own policy rejects it. Marketing platforms, CRMs, help desks, invoicing tools and form handlers all do this until you complete their domain-authentication step.
Two fixes, and you want both:
- Set up custom DKIM signing at the service. Almost every sending platform offers it — you publish a CNAME or two and its signatures start carrying your domain in the
d=tag. This is the fix that survives forwarding, so do it first. - Add the service to your SPF record, if it publishes an
include:. Watch your lookup budget while you do — see SPF PermError if adding one breaks the record.
Confirm both landed with the free DKIM checker and SPF record checker before you retry the send.
If it's somebody else's domain
This is the case that confuses people, and it is extremely common. Your application puts a customer's address in the From: header — a contact form that sends "from" the person who filled it in, a booking confirmation, a ticketing system relaying a reply. You are now sending as a domain you do not control, that domain publishes p=reject, and you will never be able to authenticate for it.
There is no DNS record that fixes this. The fix is to stop claiming to be them:
- Put your own domain in
From:—notifications@yourdomain.com. - Put their address in
Reply-To:, which is unauthenticated by design and does exactly what you wanted. - Keep their name in the display part if it helps:
From: "Jane Smith (via Acme) <notifications@yourdomain.com>".
Every well-behaved form and ticketing product does it this way. Anything still forging the sender's domain has been on borrowed time since DMARC enforcement became common.
Case 2: "the sender is unauthenticated"
This is the Gmail and Yahoo bulk-sender requirement, in force since February 2024 and enforced steadily since. It does not care about DMARC policies. It says your message arrived with neither a passing SPF result nor a valid DKIM signature, and that is now a hard floor.
Run your domain through the free DMARC checker — it reads live DNS and tells you in one pass which of the three records exists. Then, in order:
- Publish SPF if you have none. One TXT record at your domain root naming your mail provider, ending in
~allto start. - Turn on DKIM at your provider. It is rarely on by default — Google Workspace and Microsoft 365 both make you generate the key and then click a second button to start signing, and a key published but never activated is the most common version of this failure.
- Publish DMARC at
p=none. Not required to clear this bounce, but it is the only thing that will tell you whether the fix actually worked across every receiver rather than the one that bounced you.
Volume senders should also expect the rest of the 2024 requirements to be checked: a valid List-Unsubscribe header with one-click support, and a spam complaint rate kept below roughly 0.3%.
How long until it clears?
DNS propagation, then a retry. Most receivers see a new TXT record within minutes to an hour, though a previously cached negative answer can hold for as long as the old record's TTL. Nothing about the bounce is sticky — 5.7.26 is evaluated fresh on every message, so the first send after the record is live either works or produces the same bounce, and there is no penalty period to wait out.
If it still bounces after the records are confirmed live, the message is almost certainly going out through a path you have not authenticated: a second server, a relay, a scanning appliance, or an application that bypasses your mail provider entirely. Your DMARC aggregate reports name every one of those — that is precisely what they are for, and DMARC aggregate reports explained covers reading them.
Quick reference
| Your bounce says | Cause | Fix |
|---|---|---|
| "not accepted due to domain's DMARC policy", your domain in From | Sending service isn't authenticated for you | Custom DKIM at the service; add its SPF include if it has one |
| "not accepted due to domain's DMARC policy", someone else's domain in From | You're sending as a domain you don't control | Your domain in From, theirs in Reply-To. No DNS fix exists |
| "the sender is unauthenticated" | No SPF and no DKIM at all | Publish SPF, turn on DKIM signing, then add DMARC |
Free checks: DMARC checker SPF checker DKIM checker Report analyzer
Once the bounce is cleared, the useful question is what else sends as your domain — the tools nobody remembered, and the ones that were never yours. Publish a DMARC record with a rua= address and the reports will tell you.