The exact bounce
The "550 5.7.26 unauthenticated email" rejection comes from Gmail when a message fails to authenticate against the sending domain's DMARC policy. In a non-delivery report or SMTP transcript it reads:
550-5.7.26 Unauthenticated email from example.com is not accepted due to
550-5.7.26 domain's DMARC policy. Please visit
550-5.7.26 https://support.google.com/mail/answer/81126#authentication for
550-5.7.26 more information.
The "not accepted due to domain's DMARC policy" wording is the form many senders have seen for years and still describes the cause well. Google's current SMTP error reference at knowledge.workspace.google.com now phrases the permanent 550 5.7.26 entry as "This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM," and attaches the older "not accepted due to domain's DMARC policy" line to the temporary 421 4.7.26 variant. Either way, the operative word is "unauthenticated". Gmail completed DMARC evaluation, found no aligned pass, and applied the From domain's policy.
A related rejection uses code 5.7.1:
550-5.7.1 This message does not have authentication information or fails to
550-5.7.1 pass authentication checks. To best protect our users from spam, the
550-5.7.1 message has been blocked. Please visit
550-5.7.1 https://support.google.com/mail/answer/81126 for more information.
5.7.1 is a general policy and authentication code Gmail uses for more than one condition, so treat it as a starting point rather than a DMARC-specific signal. The embedded link to answer 81126 is Google's sender requirements page, which is the right place to start either way.
Why this happens: the 2024 bulk sender rules
Gmail and Yahoo published aligned sender requirements that took effect on February 1, 2024. Google's threshold for the full requirement set is sending more than 5,000 messages per day to Gmail accounts, per support.google.com/a/answer/81126. Yahoo's bulk sender program is aligned with Google's, documented at senders.yahooinc.com/best-practices, though Yahoo's published page does not restate the 5,000-per-day number.
For a bulk sender to Gmail, all of the following must hold. Yahoo requires the same authentication core for its bulk senders.
- Publish SPF and DKIM for the sending domain. Google asks for a DKIM key of at least 1024-bit and recommends 2048-bit.
- Publish a DMARC record on the From domain. The enforcement policy can be set to
p=none. - The domain in the
From:header must align with either the SPF domain or the DKIM domain. - For marketing or subscribed mail, support one-click unsubscribe with a
List-Unsubscribeheader andList-Unsubscribe-Post: List-Unsubscribe=One-Click. This mechanism is defined in RFC 8058; Yahoo names RFC 8058 on its page, while Google describes the headers without printing the RFC number. - Sending domains or IPs must have valid forward and reverse DNS (PTR) records.
- Transmit over a TLS connection (stated by Google; Yahoo's published page does not restate a TLS requirement).
- Keep the user-reported spam rate in Postmaster Tools below 0.10% and never reach 0.30% or higher (Google's wording). Yahoo states a 0.3% ceiling.
The 0.10% target and the 5,000-per-day number are Google's wording. Do not assume Yahoo publishes the same figures. Yahoo's page states only the 0.3% spam-rate ceiling.
Step 1: read the Authentication-Results
DMARC passes when at least one mechanism produces a pass that is in alignment. RFC 9989 section 5.3.5 puts it plainly: "If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check." Open a delivered or bounced copy of the message and read the Authentication-Results header the receiver stamped:
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=bounce.vendor.net;
dkim=pass header.d=vendor.net;
dmarc=fail (p=NONE) header.from=example.com
This is an unaligned pass. SPF passed for bounce.vendor.net and DKIM passed for vendor.net, but the visible From domain is example.com. Neither authenticated identity shares an organizational domain with example.com, so neither aligns, and dmarc=fail. The visible From: domain is the Author Domain that DMARC aligns the authenticated identifiers against, per RFC 9989 section 3.2.10. If you do not have a copy of the message, paste raw headers into the email header analyzer to get the same verdict.
Step 2: confirm the From domain has a DMARC record
Query the _dmarc TXT record for the exact domain in the From: header. The _dmarc label is mandatory, per RFC 9989 section 4.7.
dig +short TXT _dmarc.example.com
dig +short TXT _dmarc.example.com @1.1.1.1
nslookup -type=TXT _dmarc.example.com 8.8.8.8
A satisfying record can be as simple as monitoring mode:
v=DMARC1; p=none; rua=mailto:[email protected]
If the query returns nothing, the From domain has no DMARC record and you will see Gmail's requirement fail on the policy condition. Build a valid record with the DMARC record generator, then read no DMARC record found for the publish steps.
Step 3: fix SPF and DKIM alignment
The bounce almost always traces to alignment, not to a missing record. SPF aligns when the MAIL FROM (envelope) domain shares an organizational domain with the From domain. DKIM aligns when the signature d= domain shares an organizational domain with the From domain. RFC 9989 section 3.2.10 defines both. Relaxed mode (the default for adkim and aspf) compares organizational domains; strict mode requires an exact match.
Confirm what each domain publishes:
# SPF lives at the domain apex as a TXT record (RFC 7208 section 3.1)
dig +short TXT example.com @1.1.1.1
# DKIM needs the selector from the message's DKIM-Signature header
dig +short TXT selector1._domainkey.example.com @1.1.1.1
The fix depends on how the mail is sent:
- If the message is sent through an email service provider, authenticate your own domain inside that provider so DKIM signs with
d=example.comand theReturn-Pathsits under your domain. This is the single most common fix. See ESP mail fails DMARC for the per-provider steps. - If you send from your own infrastructure, add the sending IPs or includes to your SPF record, and enable DKIM signing on a selector under your domain.
- Send a fresh test message and confirm the new
Authentication-Resultsshows an aligned pass, for exampledkim=pass header.d=example.comwithdmarc=pass.
You only need one aligned pass. RFC 9989 section 5.3.5 uses OR logic: an aligned SPF pass or an aligned DKIM pass is enough. DKIM alignment is the more durable target because it survives forwarding, while SPF does not.
Step 4: meet the rest of the bulk sender checklist
Authentication clears the 5.7.26 rejection, but bulk mail can still be blocked or filtered if the other requirements are missing. Confirm each one:
-
One-click unsubscribe. Marketing mail needs both headers. The minimum is a
List-UnsubscribeURL plus the one-click post header. - Reverse DNS. Every sending IP needs a PTR record that resolves, and ideally forward-confirms back to the same IP.
- Spam rate. Watch the user-reported spam rate in Postmaster Tools at gmail.com/postmaster. A sustained climb toward 0.30% will undo good authentication.
The headers for one-click unsubscribe look like this:
List-Unsubscribe: <https://example.com/unsubscribe?id=abc>, <mailto:[email protected]>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Yahoo asks senders to honor unsubscribe requests within 2 days, per its best-practices page. A high complaint rate triggers a different failure mode, a temporary deferral rather than a 5.7.26 rejection. See high complaint rate deferrals if you are seeing 421 4.7.0 instead.
Validate the fix
After authenticating the domain inside your sending platform and updating DNS, wait at least one TTL, then re-check the published records:
dig +short TXT _dmarc.example.com @1.1.1.1
dig +short TXT example.com @8.8.8.8
Run the From domain through the DMARC checker for a read-only posture snapshot of the published DMARC and SPF records. Then send a fresh message to a Gmail address you control and open the headers: you want an aligned spf=pass or dkim=pass and a dmarc=pass.
Do not retry the old bounced message to test. DMARC is evaluated at delivery time against the DNS and headers that exist for that new attempt, so only a fresh send proves the fix. If you want to confirm alignment per sending platform in minutes instead of waiting roughly a day for aggregate reports, the Inbox Inspector receives a real campaign at a seed address and evaluates SPF, DKIM, DMARC, alignment, and final disposition itself.
Related fixes
- If the From domain has no policy published, read no DMARC record found.
- If mail through Mailchimp, SendGrid, or Klaviyo fails, read ESP mail fails DMARC.
- If the identifiers do not match the From domain, read DMARC alignment issues.
- If SPF returns permerror or too many lookups, read SPF errors.
- If a DKIM selector is missing or unsigned, read DKIM failures.
- For the deeper mechanics, read DMARC fail explained and why emails fail DMARC at Mailchimp, SendGrid, and Klaviyo.