Gmail rejects your mail with 550-5.7.26: unauthenticated email is not accepted due to the domain's DMARC policy

Hi, it's BlueByte. Messages your application sent without trouble last week are coming back from Gmail with 550 5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy. Internal mail still flows, so your mail server is not broken — Gmail is enforcing a policy your own domain published. We'll walk through the message variants, what Gmail checks before it accepts anything, how to read the headers and DNS to find which check failed, the fix for each cause, and how to tighten DMARC later without bouncing your own mail.

The bounce text, and the variant that means something else

Two strings show up here, and they are not the same problem. The first:

550 5.7.26 Unauthenticated email from example.com is not accepted due to
domain's DMARC policy.

Google documents that sentence as the bounce an outgoing message gets when it fails DMARC. Your own mail server usually wraps it in a delivery-status report, and the bounce often continues with a line pointing at the domain's administrator, so the exact wording around it varies by relay.

Your domain publishes a DMARC policy, the message failed DMARC, and Gmail did what the policy asked. The second variant reads This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. That one is not about your policy — the message carried no usable authentication, and it is refused under Gmail's baseline sender requirements whether or not a _dmarc record exists. Reading which sentence you got saves an hour in the wrong place.

What Gmail checks before it accepts anything

Since 1 February 2024, Google requires every sender to set up SPF or DKIM for their sending domains, keep spam rates below 0.3%, use a TLS connection for transmitting email, publish valid forward and reverse DNS records for sending domains or IPs, and format messages according to RFC 5322 with a single From: header carrying one address. Senders of more than 5,000 messages a day to Gmail accounts have additional requirements: SPF and DKIM and DMARC together, with the domain in the From: header aligned with either the SPF domain or the DKIM domain, plus one-click unsubscribe on marketing and subscribed messages.

Alignment is the part that surprises people. A message can pass SPF cleanly and still fail DMARC, because SPF validates the envelope sender — the MAIL FROM that becomes the Return-Path — while DMARC compares the header From: domain against whichever domain actually passed. Relay through a vendor that rewrites the Return-Path to its own bounce domain and SPF passes for the vendor, aligning with nothing of yours.

Read the Authentication-Results header to see which check failed

Send one test message down the same path to a Gmail account you control. Under p=quarantine it lands in spam, where the headers are still readable; under p=reject you need a test domain without enforcement, or your aggregate reports instead. Open the message, choose Show original, and read the top of the header block. Field order and the parenthetical comments differ between receivers, so read the values rather than matching the layout:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounces@vendor.example designates
           198.51.100.20 as permitted sender) smtp.mailfrom=bounces@vendor.example;
       dkim=fail (body hash did not verify) header.i=@example.com;
       dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=example.com

Read it line by line. SPF passed — but for vendor.example, not for the header.from domain. DKIM was present and failed on the body hash. Nothing aligned, so dmarc=fail, and dis=REJECT records the disposition Gmail applied. Google's Admin Toolbox parses this for you with its Messageheader tool if you would rather not read it raw.

Query the three DNS records yourself

The header says which check failed; DNS says why. Three lookups, run from outside your own network so you see what a receiver sees:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com

"v=spf1 include:_spf.google.com include:mail.vendor.example ~all"
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Check three things against the header you just read. Is the sending service represented in the SPF record at all? Does the DKIM selector your signer uses actually resolve — a signature naming a selector with no published key cannot verify, however correct the signing is. And are adkim and aspf set to s, which demands strict alignment and refuses the subdomain matches relaxed mode would accept? An empty answer for _dmarc rules the policy variant out, and sends you back to the baseline-authentication bounce.

Fix the cause the header named

Three causes, three fixes:

• The sending source is not authorized. Confirm that every sending IP address and domain you use appears in the SPF record, then re-send. This is the usual answer when a vendor, a new app server or a migrated relay was added without anyone touching DNS.
• DKIM does not verify. Either the published key does not match what the signer uses — check that the DKIM key in DNS is the one you added — or the message was modified in transit or after signing, which a mailing list footer or a link-rewriting gateway does on every message. dkim=fail (body hash did not verify) is the modification case; a selector that does not resolve is the publishing case.
• Both pass, for somebody else's domain. The alignment case. The durable fix is to have the vendor sign with a DKIM selector published under your domain, usually via a CNAME they give you, so the signing domain aligns with your From: whatever the Return-Path says.

A worked example: an invoicing app that started bouncing on a Monday

A finance team's invoicing app has relayed through a third-party service for two years. On Monday every invoice to a Gmail recipient bounces with 5.7.26, while invoices to the company's own Microsoft 365 users arrive normally. The test message shows spf=pass for the vendor's bounce domain, dkim=neutral, dmarc=fail, header.from=example.com. dig +short TXT _dmarc.example.com explains the timing: the security team moved the policy from p=none to p=reject over the weekend. The app had never been aligned — it had simply never been enforced against. The fix is the vendor's DKIM CNAME published under example.com so the signature aligns, verified with a dig against the new selector and then a live send. While DNS propagates, dropping back to p=none for a day stops the bouncing at once.

Verify with a real send, then with the reports

A DNS lookup is not proof — the receiving side has to agree. Send again to a Gmail address you control and check that the header reads dmarc=pass, with either spf=pass or dkim=pass on a domain matching header.from. Then let the reports do the rest: the rua address in your DMARC record receives daily reports identifying which messages failed, which is how you find the sender you forgot about rather than the one that bounced loudly.

Keep it from coming back: report first, enforce second

Most 5.7.26 outages are self-inflicted, and the order of operations prevents them. Publish a policy that only asks for reports, collect them until every legitimate sender shows up aligned — invoicing, ticketing, CRM, monitoring, the marketing platform nobody told you about — and only then tighten to quarantine and reject. Keep a list of which service signs with which selector; that list is what you will want the next time a vendor rotates a key.

How 5.7.26 differs from 5.7.25, 5.7.1 and the 4.7.28 throttles

5.7.25 is reverse DNS, not authentication: the message was blocked because the sending IP address has no PTR record, or the forwarding DNS entry does not reference the sending IP. Fixing SPF will not touch it. 5.7.1 is a family of policy rejections — the sending or receiving domain has a policy prohibiting the mail, or the message has a missing or invalid From: header, no Message-ID, or otherwise fails RFC 5322 — so it points at the message or the recipient's rules, not at your DNS. One more distinction worth holding onto: a 4.7.28 throttle is temporary and a well-behaved sender retries through it, while every code here beginning 5 is permanent and needs a change from you.

Next time Gmail bounces you with 5.7.26, walk these checks back in order: which of the two sentences you actually received, what the Authentication-Results header says about spf, dkim and dmarc, what your three TXT records contain, and which one of them does not match the sender you are troubleshooting.