550 5.7.26 — unauthenticated email
A bounce arrives and it is unusually blunt:
550-5.7.26 Unauthenticated email from example.com is not accepted due to
550-5.7.26 domain's DMARC policy. Please contact the administrator of
550-5.7.26 example.com domain if this was a legitimate mail.That Gmail rejection is saying something specific. Read it carefully, because the wording is precise and it is easy to blame the wrong party. Gmail is not saying your message is spam, and it is not saying its own filters disliked it. It is saying: this message claimed to be from example.com, it failed authentication, and example.com's own published policy asks us to reject that.
The receiver is doing exactly what the domain told it to do.
The same rejection appears with slightly different wording depending on the receiver — unauthenticated email is not accepted, or this message does not meet IP authentication requirements — but the cause behind all of them is the same: nothing in the message authenticated as the domain in the From address.
Two very different situations
Everything depends on whether that domain is yours.
If the domain is yours, some legitimate sender of yours is not authenticated, and your policy is now enforcing. This is the usual case, and it is the good kind of problem: enforcement is working, it has just caught a sender you did not know about.
If the domain is not yours — you are forwarding, or running a mailing list, or relaying mail for a client — then the message is failing because their policy is enforcing and your relay broke the authentication. Rewriting the envelope-from is not enough; the fix is on the sending domain's side, or in how your list handles enforcing domains. Why SPF fails on forwarded mail covers that shape.
The rest of this page assumes the domain is yours.
Why it appeared now
Almost always one of three:
- You raised your DMARC policy to
p=quarantineorp=reject, and a sender that was quietly failing all along is now visible. - A sender changed. A platform migration, a new tenant, a rotated DKIM key that was never published.
- Nothing changed on your side. The Gmail bulk sender requirements have demanded authentication since 2024, and enforcement of those requirements has tightened over time.
If it is the first, the message is not a surprise — it is the outcome you asked for. The question is which sender.
Do not fix this by lowering your DMARC policy. Rolling back to p=none makes the bounce stop and leaves your domain spoofable again. Fix the sender, then keep the policy.
Finding the sender
The bounce itself is not much help — it tells you the destination, not which of your systems sent it. The reports are.
- Note the time and the recipient domain from the bounce.
- Open the failing sources for that window. Unknown sending sources is normally where the culprit shows up, because a sender producing 5.7.26 bounces is by definition one that is not authenticated.
- Match the sending IP or provider from the report to a system you recognise. Sending sources, grouped by provider does that translation for you.
The usual suspects are the systems nobody thinks of as email: the ticketing tool, the invoicing platform, the monitoring alerts, the CRM that sends "on behalf of" a person.
Fixing it, in order
1. Authenticate the sender properly. At the platform, complete domain authentication so it signs with your domain — this is the step that makes DKIM aligned, and aligned DKIM is what survives forwarding. It is usually called "authenticate your domain", "branded sending" or "custom DKIM". See What is a DKIM selector? for what you are publishing.
2. Add the sender to SPF if it needs it. Only if the platform documents it; watch the ten-lookup limit as you go.
3. Verify alignment, not just "pass". A valid DKIM signature earns nothing if d= is the provider's domain rather than yours. This is the most common reason a sender still fails after somebody "turned DKIM on" — DMARC alignment explained.
4. Confirm from the next reports. DMARC reports arrive daily, so the proof that a fix worked shows up within about a day.
The related codes
| Code | What it means |
|---|---|
5.7.26 | Unauthenticated mail, rejected because of the From domain's DMARC policy |
5.7.1 | A general policy rejection — often authentication, but also reputation or content |
5.7.25 | The sending IP's reverse DNS does not resolve, or does not match |
5.7.26 is the most specific and therefore the most useful of the three: it names authentication as the cause, and it names the domain whose policy applies.
If the sender genuinely cannot be authenticated
Occasionally a system cannot be made to sign as your domain — old on-premise software, a vendor with no DKIM support. Two honest options:
- Move it to a subdomain with its own authentication, so it stops borrowing your primary domain's reputation and policy.
- Have it send as its own domain and put your address in
Reply-To, which is not spoofing and needs no policy exception.
What is not an option is a permanent hole in your primary domain's policy. Getting to enforcement is the point; the sequence is in DMARC policy: none, quarantine, reject.