Gmail refused your message because it couldn’t authenticate it: SPF didn’t pass and DKIM didn’t pass, or SPF failed against a record ending in -all, or the message failed DMARC and your domain’s policy says to reject it. Usually one sending service (a newsletter tool, CRM, help desk or web server) isn’t set up for your domain. Find out which variant you got, check your records below, then authorize that service.
Last verified 8 October 2026.
Google’s SMTP error reference lists three permanent errors under 550 5.7.26. The bracketed parts are filled in with your details.
550 5.7.26 This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass SPF [domain-name] with ip: [ip-address] = did not pass.
Neither check passed: no valid DKIM signature, and SPF didn’t pass for the Return-Path (envelope sender) domain from the IP that delivered the message. One passing check would have been enough. The bounce tells you which SPF domain and which IP Gmail checked: start there.
550 5.7.26 The (E)MAIL FROM domain [domain-name] has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks with the ip: [ip-address]. To best protect our users from spam and phishing, the message has been blocked.
The Return-Path domain’s SPF record ends in -all, and the sending IP isn’t covered by it, so SPF returned fail. RFC 7208 §2.6.4: “A ‘fail’ result is an explicit statement that the client is not authorized to use the domain in the given identity.” The usual cause is a sending service that was never added to the record.
550 5.7.26 Unauthenticated email from [domain-name] is not accepted due to domain's DMARC policy. Contact the administrator of [domain-name] domain if this was legitimate email.
The message failed DMARC, and the From: domain publishes an enforcing DMARC policy, usually p=reject. RFC 7489 §6.3: “reject: The Domain Owner wishes for Mail Receivers to reject email that fails the DMARC mechanism check.” Failing DMARC doesn’t mean SPF or DKIM failed: they may have passed for the sending service’s domain, which doesn’t count for yours. That is DMARC alignment.
Gmail also defers mail with 4.7.26, so your server retries:
421 4.7.26 This email has been rate limited because it is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.
451 4.7.26 Unauthenticated email from [domain-name] is not accepted due to domain's DMARC policy, but temporary DNS failures prevent authentication. Please contact the administrator of [domain-name] domain if this was a legitimate email.
The first has the same cause as variant 1. The second means a DNS lookup needed for SPF, DKIM or DMARC failed; see SPF TempError.
Bounce texts quoted from Google Workspace Help, Gmail SMTP errors and codes (trailing “For more information” and “To learn about the DMARC initiative” links left out; in the DMARC texts Google writes the domain as domain-name, without brackets); RFC quotes from RFC 7208 and RFC 7489 (checked 8 October 2026).
| “sender is unauthenticated” | Neither SPF nor DKIM passed. Compare the IP in the bounce with the SPF record of the domain it names, and check whether the service signs DKIM at all. |
|---|---|
| “hard fail policy (-all)” | SPF failed against a -all record. Add the sending service to the SPF record of the domain in the bounce. |
| “domain’s DMARC policy” | DMARC failed with an enforcing policy. SPF or DKIM may have passed, but not for your From: domain. Make the service sign DKIM with your domain. |
The domain in variants 1 and 2 is the Return-Path domain (SMTP MAIL FROM), which a sending service often sets to its own domain or a subdomain of yours, such as bounces.example.com. The domain in variant 3 is your From: domain.
Enter your From: domain (or the domain named in the bounce). The check runs in your browser against public DNS: it reads the SPF record, how it ends (-all or ~all), follows its includes to count DNS lookups and find a PermError, and reads the DMARC policy that applies.
DNS shows what your domain allows, not what happened to one message: this can’t see which IP sent the bounced mail or whether its DKIM signature verified. The bounce and the message headers show that.
What this can and can’t tell you: it reads DNS right now through Cloudflare’s public resolver (Google’s when Cloudflare’s fails). A lookup that fails is reported as unknown, never as a missing record. DKIM isn’t checked, because a DKIM key is published at a selector named only in the message’s DKIM-Signature header; check one with the DKIM key check. For the full A–F grade with DKIM selectors, MTA-STS and more, use the DMARC checker.
Google’s Email sender guidelines set the minimum for mail to personal Gmail accounts:
The guidelines FAQ defines a bulk sender as one “that sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period”, counting all mail from the same primary domain, and says only one of SPF or DKIM has to be aligned. It adds: “DMARC alignment isn’t required for forwarded or mailing list messages”. Since November 2025, it says, “Messages that fail to meet the email sender requirements will experience disruptions, including temporary and permanent rejections.” The full list, with Yahoo’s and Microsoft’s, is in bulk sender requirements.
Sources: Google, Email sender guidelines and Email sender guidelines FAQ (checked 8 October 2026).
You added a newsletter tool, CRM, help desk, invoicing app or a web server’s contact form, and it sends as your domain from its own servers. Gmail sees an IP your record doesn’t list. With ~all, SPF softfails; with -all, it fails (variant 2). Either way, without DKIM the message is unauthenticated (variant 1).
Fix: add the service’s include: (from its setup guide) to your one SPF record, for example v=spf1 include:_spf.google.com include:sendservice.example ~all. Never publish a second SPF record: two records are a PermError (merge them).
Many services sign every message with their own domain (d=service.example) until you add your domain in their settings and publish the DKIM records they give you, usually CNAMEs or a TXT record at <selector>._domainkey.yourdomain.com. Their signature verifies, but it isn’t aligned with your From: domain, so it doesn’t count for DMARC: RFC 7489 §3.1.1 says “merely bearing a valid signature is not enough to infer authenticity of the Author Domain.” Google’s guidelines: “If you use an email service provider, verify that they authenticate your domain’s email with SPF and DKIM.”
Fix: in the service’s domain or sender authentication settings, add your domain and publish its DKIM records. Then check that sent mail shows dkim=pass for your domain (Gmail writes it as header.i=@yourdomain.com; see Show original below). See DMARC alignment failed for the alignment rules.
A forwarder delivers from its own IP, which isn’t in your SPF record. Google: “Email forwarding can affect message authentication, and forwarded messages often fail SPF authentication. This is why we recommend you always set up DKIM authentication”. DKIM survives forwarding if nothing changes the message; a mailing list that edits the subject or adds a footer breaks it. RFC 7489 §10.5: “Transiting a Mediator often causes either the authentication to fail or Identifier Alignment to be lost.” Gmail also reads ARC: “If a forwarded message passes SPF or DKIM authentication, but ARC shows it previously failed authentication, Gmail treats the message as unauthenticated.”
Fix: sign all your mail with DKIM on your own domain, so it still passes after a plain forward. If you run the forwarder, follow Google’s best practices for forwarding email to Gmail (change the envelope sender to your forwarding domain, and don’t change the subject or body).
-all and an include is missingSame root cause as 1, but stricter: -all turns every unlisted server into an SPF fail, which is the exact wording of variant 2. Check which service owns the IP in the bounce, then whether your record names it: the DMARC checker lists the senders your record includes. If you’re mid-migration and aren’t sure every sender is listed, ~all is the safer ending until DKIM passes everywhere.
p=reject and a sender that isn’t alignedTo pass DMARC, SPF must pass for a Return-Path domain aligned with your From: domain, or DKIM must pass for an aligned d= domain. RFC 7489 §4.2: “A message satisfies the DMARC checks if at least one of the supported authentication mechanisms: 1. produces a ‘pass’ result, and 2. produces that result based on an identifier that is in alignment”. A service that uses its own Return-Path and signs with its own domain passes SPF and DKIM and still fails DMARC, and at p=reject Gmail refuses it (variant 3). Google’s DMARC troubleshooting page lists this bounce under “If valid outgoing messages fail DMARC”.
Gmail has a separate code for the same alignment gap, 4.7.32 / 5.7.32 (“isn't aligned with either the authenticated SPF or DKIM organizational domain”); see Gmail 5.7.32, which checks pasted headers.
Fix: set up DKIM with your domain at that service (cause 2) or a custom Return-Path on your domain. If valid mail is being refused right now, you can drop to p=none while you fix it, then go back up; see moving from none to reject.
Each include, a, mx, ptr, exists and redirect costs a DNS lookup, nested includes too. RFC 7208 §4.6.4: “SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation” and “If this limit is exceeded, the implementation MUST return ‘permerror’.” A permerror isn’t a pass, so SPF stops authenticating anything, and adding the service from cause 1 is often what tips a record over. Google’s SPF troubleshooting page sends spf=permerror to “Fix issues with too many DNS lookups”.
Fix: remove includes for services you no longer use and replace your own servers’ a/mx with ip4/ip6. See SPF too many DNS lookups, and for every other PermError cause, SPF PermError.
Sources: Email sender guidelines; Gmail Help, Best practices for forwarding email to Gmail and Check if your Gmail message is authenticated; Google Workspace Help, Troubleshoot DMARC issues and Troubleshoot SPF issues; RFC 7208 §4.6.4; RFC 7489 §3.1.1, §4.2, §10.5 (checked 8 October 2026).
whois on the IP) usually tells you: your mail provider, a marketing tool, your web host.include: to your one SPF record and stay at 10 lookups or fewer.If the sending IP has no reverse DNS, Gmail refuses it with a different code; see 550 5.7.25: no PTR record.
Send a message the same way the bounced one went (same service, same From: address) to a personal Gmail address you can open. Then, as Google describes it: open the email, “Next to Reply, click More” and choose Show original. The full header opens in a new window.
At the top, Gmail summarizes the checks in three lines, SPF, DKIM and DMARC, each with a result such as PASS or FAIL; the SPF line names the IP and the DKIM line the domain. In the header itself, find Authentication-Results, which looks like this for a message that passes:
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=s1 header.b=AbCd1234;
spf=pass (google.com: domain of bounces@example.com designates 192.0.2.25 as permitted sender) smtp.mailfrom=bounces@example.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.comdkim=pass with header.i or header.d on your domain: an aligned DKIM signature. If it shows the service’s domain instead, DKIM isn’t set up with yours (cause 2).spf=pass with smtp.mailfrom on your domain: an aligned SPF pass. softfail or fail means the sending IP isn’t in that domain’s record (causes 1 and 4); permerror, cause 6.dmarc=pass: at least one of the two passed and aligned. That is what stops variant 3.Google’s SPF troubleshooting page uses the same field: “Find the part of the message header that starts with Authentication-Results, and note the text following the entry spf.” Google’s DKIM troubleshooting page gives the same Show original steps, and suggests sending to another recipient such as a personal Gmail address if a test doesn’t pass, to rule out the receiving server.
Sources: Gmail Help, Trace an email with its full header; Google Workspace Help, Troubleshoot SPF issues and Troubleshoot DKIM issues (checked 8 October 2026). The header above is an illustration with documentation addresses.
Every sender to personal Gmail accounts needs SPF or DKIM. Senders of about 5,000 or more messages a day to personal Gmail accounts need SPF and DKIM and a DMARC record (p=none is enough), and the From: domain must be aligned with the SPF or the DKIM domain. Google recommends setting up all three either way.
A checker reads your DNS; Gmail checks the IP that actually delivered the message against the domain in its Return-Path. If the mail went out through a service that isn’t in your SPF record, or used that service’s own Return-Path domain, SPF fails or doesn’t count for your domain. The bounce names the SPF domain and IP it checked: compare those with your record.
It removes the hard-fail variant, but a softfail still isn’t a pass. Without a passing DKIM signature the same mail can then be refused as unauthenticated, or fail DMARC. The fix is to add the sending service to SPF and set up DKIM with your domain at that service.
A forwarding server delivers from its own IP, which isn’t in your SPF record, so forwarded mail often fails SPF. DKIM survives forwarding when the message isn’t changed, so Google recommends always signing with DKIM. A forwarder that changes the subject or body breaks DKIM too.
No. Gmail requires a DMARC record from bulk senders, and removing it drops the policy that tells receivers to reject mail forging your domain. If valid mail fails DMARC at p=reject, you can lower the policy to p=none while you fix the sending service, then raise it again once that service passes with an aligned SPF or DKIM domain.
If you manage domains for clients or brands, Email Security Signals checks a whole list and returns one row per domain with SPF (lookup count included), DMARC, DKIM across 57 common selectors plus any you add, and an A–F grade. $0.02 per graded domain ($20 per 1,000); invalid inputs, domains that don’t exist, DNS lookup failures and duplicates are free.
Check a list on the Apify Store →Related: DMARC alignment failed, Gmail 550 5.7.25 (no PTR record), Outlook 550 5.7.515, Yahoo 554 5.7.9, SPF PermError, bulk sender requirements and the free DMARC, SPF and DKIM checker.