Gmail 550 5.7.26 Sender Is Unauthenticated: What It Means and How to Fix It

Quick answer

Gmail returns 550 5.7.26 when a message to a Gmail account fails its authentication checks. Google lists three different messages under this one code, so read the text after it:

1. This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Neither SPF nor DKIM passed. Authorize the sending server in SPF and turn on DKIM signing.
2. 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]. The envelope sender's SPF record ends in -all and doesn't list the IP that sent the message. Add that server (or its provider's include) to SPF, or send through a server that is already listed.
3. Unauthenticated email from domain-name is not accepted due to domain's DMARC policy. The message failed DMARC and Gmail applied the From domain's DMARC policy. Make SPF or DKIM pass with a domain that aligns with the From address.

If you send 5,000 or more messages a day to personal Gmail accounts, Gmail also checks the bulk sender rules and uses separate codes for each one: SPF (5.7.27), DKIM (5.7.30), DMARC record (5.7.40), alignment (5.7.32), PTR (5.7.25) and TLS (5.7.29), each with a 4.7.x rate-limit version. Start with the Email Deliverability Checker to see SPF, DKIM, DMARC and MX for your domain in one pass.

What the bounce means

Since 1 February 2024, Google's Email sender guidelines require everyone who sends to personal Gmail accounts (addresses ending in @gmail.com or @googlemail.com) to set up SPF or DKIM, have valid forward and reverse DNS (PTR) for sending IPs, use TLS, keep the Postmaster Tools spam rate below 0.3% and follow RFC 5322. Senders of 5,000 or more messages a day need SPF and DKIM, a DMARC record (a policy of p=none is enough), a From domain aligned with the SPF or DKIM domain, and one-click unsubscribe for marketing mail. The guidelines say messages that aren't authenticated might be marked as spam or rejected with a 5.7.26 error, and Google's FAQ says that from November 2025 Gmail is ramping up enforcement, with temporary and permanent rejections for mail that doesn't meet the requirements. The bulk sender requirements checklist covers every rule side by side with Yahoo and Outlook.com.

• 4.7.x vs 5.7.x. Google's 4.7.x messages say your email has been rate limited or temporarily rejected: your server keeps the message and retries. 5.7.x messages say it was blocked: the message bounces back to the sender.
• Where you see it. Gmail rejects the message during the SMTP conversation, so the error reaches you as a bounce (non-delivery report) from your own mail server or sending service, quoting Gmail's reply. Google adds gsmtp to all of its error messages, and gcdp when the error comes from a custom rule a Google Workspace administrator created.
• Who it applies to. Google's FAQ says the sender guidelines and their enforcement apply only to mail sent to personal Gmail accounts, not to Google Workspace accounts. The guidelines apply to everyone sending to Gmail, including Google Workspace users.
• Wording changes. Google edits these messages from time to time, and its pages show placeholders such as domain-name and ip-address where your bounce has real values. The text below is quoted as Google listed it on 18 October 2026; match on the status code first and the wording second.

Gmail authentication bounce codes

These are the codes on Google's Gmail SMTP errors and codes page that relate to authentication, DNS and the sender requirements, with the reply code Google lists next to each. Google's text is shortened to the part that says what failed.

Google's page also lists 504 5.7.40 (Unrecognized authentication type, XOAUTH is no longer supported). Those are about logging in to Google's SMTP service, not about your domain's DMARC record.

How to tell which check failed

1. Read the whole bounce. Find the status code (5.7.26, 5.7.27 and so on) and the sentence after it. For the unauthenticated 5.7.26 message, Google includes the results it saw, in the form Authentication results: DKIM = did not pass SPF [domain-name] with ip: [ip-address] = did not pass. That gives you the SPF domain (the envelope sender) and the sending IP Gmail checked. The IP is often not the one you expect: a backup server, an on-premises relay, a scanner or an app sending directly.
2. Get a copy that was delivered. A rejected message never reaches a Gmail mailbox, so there are no Authentication-Results headers to read for it. Send the same kind of message, through the same path, to a mailbox that accepts it, for example at another provider, and copy its full headers (in Gmail: Show original; the Email Header Analyzer page explains where to find them in Outlook). Paste them into the analyzer.
3. Compare the three domains. An illustrative example (each receiver words this differently):

   Authentication-Results: mx.receiver.example;
     dkim=pass header.d=esp-mail.example header.s=s1;
     spf=pass smtp.mailfrom=bounces.esp.example;
     dmarc=fail header.from=example.com

   Here SPF and DKIM both pass, but for the sending service's domains, so nothing aligns with example.com in From. Google's FAQ says the sending domain's DMARC policy generally applies to messages that fail DMARC, so with a reject policy this can come back as the DMARC-policy 5.7.26; for a bulk sender it can also be 4.7.32/5.7.32. If spf=fail and dkim is missing or failed, it is the unauthenticated 5.7.26.
4. Use your DMARC reports. Aggregate reports show every IP sending as your domain and whether SPF and DKIM passed and aligned. Load a few days of them into the DMARC Report Analyzer to find the server or service behind the bounces.
5. Check the recipient side. The MX Record Lookup shows whether a recipient domain is hosted by Google. An error ending in gcdp came from that organization's own Google Workspace rules, not from the Gmail sender requirements.

Fix 1: SPF

• Publish exactly one TXT record starting with v=spf1 at the domain used in the envelope sender (Return-Path), listing every server and service that sends for it. Google's guidelines say third-party senders missing from SPF are more likely to be marked as spam. Build it with the SPF Record Builder and check it with the SPF Record Checker.
• For the -all variant of 5.7.26, take the IP from the bounce and check whether the record covers it. If it doesn't, add the server (or its provider's include) or route that mail through an authorized server.
• Stay within 10 DNS lookups: past that, SPF returns permerror, which counts as a failure. See how to fix SPF too many DNS lookups. Microsoft 365 and Google Workspace admins can follow SPF for Microsoft 365 or SPF, DKIM and DMARC for Google Workspace.

Fix 2: DKIM signed with your own domain

• Turn on DKIM at every platform that sends as your domain, with d= set to your domain or a subdomain of it, so the signature can align with From. A service signing only with its own domain passes DKIM but not alignment. Google's guidelines require a DKIM key of at least 1024 bits for personal Gmail accounts and recommend 2048 bits.
• Check published selectors and key length with the DKIM Checker. Platform steps: DKIM for Microsoft 365 and Google Workspace.
• If DKIM is set up but your test copy shows dkim=fail or permerror, use the guide for the failure you see: body hash did not verify, signature did not verify or no key for signature.

Fix 3: a DMARC record (5.7.40, 4.7.40)

Bulk senders need a DMARC TXT record at _dmarc.yourdomain with a policy. Google says p=none is enough to meet the requirement:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Generate one with the DMARC Record Generator and confirm Gmail will find a policy with the DMARC Record Checker (one record, starts with v=DMARC1, has a p= tag). Google's DMARC setup page recommends that SPF and DKIM have been authenticating your mail for at least 48 hours before you turn DMARC on. For a staged move to quarantine and reject, see DMARC for Microsoft 365.

Fix 4: alignment (5.7.32, 4.7.32 and the DMARC-policy 5.7.26)

Google's FAQ says the organizational domain in the From header must be aligned with the SPF organizational domain or the DKIM organizational domain; only one has to align, though Google recommends aligning both and says alignment with both will likely become a requirement. In DMARC's default relaxed mode, news.example.com aligns with example.com.

• Aligned DKIM: have each sending service sign with your domain (usually by publishing CNAME or TXT records it gives you). This is the fix that also survives forwarding.
• Aligned SPF: set a custom return-path or bounce domain under your domain at the service, so smtp.mailfrom matches your From domain.
• The DMARC-policy 5.7.26: your own policy is doing its job: the message claimed your domain without passing aligned SPF or DKIM. Google's help for this bounce suggests that users sending from another email app make sure the outgoing server matches the address they send from. Fix the sender rather than weakening the policy; going back to p=none stops the rejections but also stops protecting the domain.

The DMARC fail with SPF pass guide walks through relaxed vs strict alignment and third-party senders in detail.

Fix 5: PTR and forward-confirmed reverse DNS (5.7.25, 4.7.23)

Google's requirement: the sending server's public IP must have a PTR record that resolves to a hostname, and that hostname must have an A (IPv4) or AAAA (IPv6) record that resolves back to the same IP.

# Reverse lookup: which hostname does the IP point to?
dig +short -x 203.0.113.25

# Forward lookup: does that hostname point back to the same IP?
dig +short A mail.example.com
dig +short AAAA mail.example.com

# Windows
Resolve-DnsName -Name 203.0.113.25 -Type PTR
Resolve-DnsName -Name mail.example.com -Type A

Or paste the IP into the DNS Lookup tool, which runs the reverse lookup and the forward check in one step. The PTR record lives in the IP owner's reverse zone, so you usually ask your hosting, cloud or internet provider to set it, not your domain's DNS host. Google Workspace, Microsoft 365 and large sending services usually manage this for their own IPs; it matters for your own servers and dedicated IPs, and for IPv6 too if your server sends over IPv6.

Fix 6: TLS (5.7.29, 4.7.29)

Gmail requires bulk senders to use TLS for SMTP connections, and the general guidelines list TLS for all senders. These errors mean your server delivered to Gmail without upgrading the connection with STARTTLS. Turn on outbound (client-side) TLS in your mail server, for example smtp_tls_security_level = may in Postfix, and check that any appliance, application or relay that delivers straight to Gmail supports it. Your server's delivery logs show whether each connection used TLS. MTA-STS and TLS-RPT protect mail sent to your domain, so they don't fix this error.

Fix 7: forwarding and relays

Forwarding changes the sending IP, so SPF often fails for forwarded mail. Google's Best practices for forwarding email to Gmail recommends:

• changing the envelope sender to your forwarding domain, and including all forwarding servers in that domain's SPF record;
• keeping the original DKIM signature intact: don't modify the Subject, other signed headers such as To, Cc, Date and Message-ID, the MIME boundaries or the body (including re-encoding);
• adding an X-Forwarded-For: or X-Forwarded-To: header so receivers know the message was forwarded.

Google notes that Gmail runs its own authentication checks on forwarded messages rather than trusting earlier results, and that DKIM is especially important for mail that gets forwarded. Its FAQ says the DMARC alignment requirement for bulk senders doesn't apply to forwarded or mailing list messages. If your own relay or smart host sends mail for other systems (printers, apps, an on-premises server), make sure that relay is in SPF and signs DKIM with your domain.

If you see 4.7.28 or 5.7.28 (rate limits)

These aren't authentication failures, but they often show up during the same clean-up. Google's sender guidelines say that when you get 4.7.28: stop sending for at least 10 minutes, identify the cause, and if the error doesn't say whether your DKIM, SPF or IP quota was exceeded, assume all three are affected. After 10 minutes send over a single connection, wait another 10 minutes if that fails, and add connections one at a time once it works. Monitor spam rate and reputation in Postmaster Tools.

Verify the fix

1. Run the domain through the Email Deliverability Checker, then check the individual records with the SPF Record Checker, DKIM Checker and DMARC Record Checker.
2. After a DNS change, confirm public resolvers see the new record with the DNS Propagation Checker.
3. Send a new message through each path that bounced to a Gmail account, choose Show original, and paste the headers into the Email Header Analyzer. Look for spf=pass and dkim=pass with a domain matching From, and dmarc=pass.
4. Watch a week of aggregate reports in the DMARC Report Analyzer: every legitimate source should pass aligned SPF or DKIM. Bulk senders can also check the Compliance status dashboard in Google Postmaster Tools.

Audit hundreds of domains at once

Need SPF, DMARC and MX checks across a whole client list? Run the Bulk SPF / DMARC / MX Auditor on Apify ($2 per 1,000 domains).

Related tools and guides

Check SPF, DKIM, DMARC and MX in one pass with the Email Deliverability Checker, then fix records with the SPF Record Checker, DKIM Checker and DMARC Record Checker. Read a test message with the Email Header Analyzer, find unknown senders with the DMARC Report Analyzer and see who hosts a recipient domain with MX Record Lookup. Related guides: bulk sender requirements, Outlook.com 550 5.7.515, DMARC fail with SPF pass (alignment), SPF, DKIM and DMARC for Google Workspace, SPF too many DNS lookups, DKIM body hash did not verify, DKIM signature did not verify and DKIM no key for signature.

FAQ

What does Gmail error 550 5.7.26 mean?

Gmail blocked the message because it failed authentication. Google lists three messages under 550 5.7.26: the sender is unauthenticated (neither SPF nor DKIM passed), the envelope sender domain has an SPF -all policy that the sending IP fails, or the message failed the From domain's DMARC policy. Read the text after the code to tell which one you have.

Why does Gmail say unauthenticated when my SPF record is correct?

SPF is checked against the envelope sender domain and the IP that actually connected, so a correct record for your main domain does not help mail sent from an unlisted server or with a service's own bounce domain. For the DMARC-policy 5.7.26 and 5.7.32, SPF or DKIM must also pass for a domain aligned with the From address.

What is the difference between Gmail 4.7.x and 5.7.x errors?

Google words the 4.7.x messages as rate limiting or temporary rejection, so your server keeps the message and retries later. The 5.7.x messages say the message was blocked, so it bounces back to the sender. Both point at the same requirement, such as 4.7.30 and 5.7.30 for DKIM.

Do the Gmail sender requirements apply to Google Workspace recipients?

No. Google says its sender guidelines and their enforcement apply only to mail sent to personal Gmail accounts, not to Google Workspace accounts. They do apply to Google Workspace users sending to Gmail. Errors ending in gcdp come from a custom rule set by the receiving Workspace administrator.

How do I stop 5.7.26 bounces for forwarded email?

Sign mail with DKIM using your own domain, because DKIM usually survives forwarding while SPF does not. If you run the forwarder, Google recommends rewriting the envelope sender to the forwarding domain, listing the forwarding servers in its SPF record, not changing signed headers or the body, and adding an X-Forwarded-For or X-Forwarded-To header.

Want the full kit?

Runbooks, checklists and helpdesk templates: IT Admin Packs on Gumroad.