Gmail 550 5.7.26 and Other Authentication Bounce Codes Explained

Brand Protection

Introduction

Gmail's 550 5.7.26 bounce means Gmail refused your message because it failed authentication. It comes in three variants: neither SPF nor DKIM passed, SPF failed against a -all record, or the message failed DMARC and the From domain publishes an enforcing policy. Read the text after the code to know which one you have, then fix that check.

Gmail also uses a family of related codes, each pointing at one control: 5.7.27 for SPF, 5.7.30 for DKIM, 5.7.32 for alignment and 5.7.40 for a missing DMARC record, with 4.7.x twins for temporary rate limiting. This guide lists every authentication-related code in Google's official Gmail SMTP errors and codes reference (last updated 26 October 2026), the fix for each, and a triage order for MSPs handling bounces across many client tenants. It is the Gmail companion to our Microsoft 550 5.7.515 guide; the policy background is in Google and Yahoo sender requirements and the protocol itself in the DMARC guide.

Key takeaways

• 550 5.7.26 has three different meanings. The sentence after the code tells you whether the problem is "no authentication at all", an SPF hard fail, or the sender's own DMARC policy.
• A 5.7.x code is a permanent rejection; the matching 4.7.x code is a temporary rate limit. Treat a run of 4.7.x codes as a warning that rejections are next.
• Google's reference uses 4.7.40 and 5.7.40 for a missing DMARC record, while its sender guidelines FAQ uses 4.7.31. Both point to the same fix.
• 504 5.7.40 with "Unrecognized authentication type" is an SMTP AUTH login error, not a DMARC problem.
• For MSPs, the sending platform decides the fix: Microsoft 365, Google Workspace, an email service provider (ESP) or an on-premises relay. Identify it first.

What does Gmail error 550 5.7.26 mean?

It means Gmail permanently rejected the message during the SMTP conversation because authentication failed. Google's reference lists three distinct texts under the same code, and each needs a different fix, so never stop reading at the number.

The three variants, quoted from Google's reference (placeholders in italics on Google's page are shown here in brackets):

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.

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.

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.

What each variant tells you:

1. "The sender is unauthenticated": neither SPF nor DKIM passed for this message. Google's email sender guidelines require every sender, not only bulk senders, to set up SPF or DKIM, and say that messages that are not authenticated "might be marked as spam or rejected with a 5.7.26 error."
2. "Hard fail policy (-all)": the envelope sender (Return-Path) domain publishes -all and the sending IP is not in the record. DKIM may still have passed; Gmail blocked on the explicit SPF instruction.
3. "Due to domain's DMARC policy": the message failed DMARC and the From domain publishes an enforcing policy (in practice p=reject). Google's page on controlling unauthenticated mail from your domain explains that Google honours strict sender policies. This is your own policy being enforced, not a Gmail bulk-sender rule.

The third variant is the one that most often catches MSPs mid-project: a client moves to p=reject and a forgotten platform starts bouncing. It is the reason to finish source discovery before enforcement, as covered in how to move from monitoring to enforcement safely.

Which Gmail codes relate to authentication?

Google's reference lists roughly a dozen authentication-related codes. Each 5.7.x block has a 4.7.x rate-limit twin with the same cause, so the fix is the same; only the urgency differs. This table quotes the opening sentence of each entry.

Two oddities in Google's page are worth knowing. The 5.7.32 entry is listed with a 421 reply code even though its text says the message "was blocked", so check the bounce you actually received for the leading digit. And the 5.7.27 and 5.7.30 entries add "Gmail requires bulk email senders to authenticate their email with SPF" (or DKIM), followed by an "Authentication results" line, which confirms the bulk-sender rules are the trigger.

Why do some sources say 4.7.31 for a missing DMARC record?

Google's email sender guidelines FAQ lists 4.7.31 for "the sending domain doesn't have a DMARC record", while the SMTP error reference uses 4.7.40 and 5.7.40 for the same condition and has no 4.7.31 entry. The fix is identical: publish a DMARC record with a policy. Search logs for both codes when auditing.

Which similar codes are not authentication problems?

Several Gmail codes look related but are not about SPF, DKIM or DMARC. Ruling them out early saves a wasted DNS change:

• 504 5.7.40 "Unrecognized authentication type." and "XOAUTH is no longer supported." are SMTP AUTH (login) errors from a client or device sending through Gmail's servers.
• 421 4.7.28 and 550 5.7.28 report an unusual rate of unsolicited mail from your IP or DKIM domain: a reputation issue, although authentication still has to be in order.
• 421 4.7.29 and 550 5.7.29 mean the message was not sent over TLS.
• 530 5.7.0 "Authentication required." is again SMTP AUTH, not message authentication.

How do I read a Gmail bounce?

Start with the three-part status code, then the explanatory sentence, then the "Authentication results" line if there is one. Gmail appends gsmtp to all its errors (and gcdp to errors from administrator-created custom rules), which confirms the rejection came from Google rather than your own gateway.

A non-delivery report usually shows the remote server's response in a multi-line form like this (illustrative, with example values):

Remote server returned: 550-5.7.26 This email has been blocked because the
550-5.7.26 sender is unauthenticated. Gmail requires all senders to
550-5.7.26 authenticate with either SPF or DKIM.
550-5.7.26  Authentication results:
550-5.7.26  DKIM = did not pass
550-5.7.26  SPF [bounce.example.com] with ip: [203.0.113.25] = did not pass
550 5.7.26 ... - gsmtp

Read it like this:

• First digit: 5 is permanent, 4 is temporary. Senders retry 4xx responses; a 5xx response ends delivery.
• The domain in the SPF result is the Return-Path domain, not necessarily the From domain. Here it is bounce.example.com.
• The IP address identifies the sending platform. Look it up against the client's known senders.
• "DKIM = did not pass" with no domain usually means no signature was present at all.

How do I check the headers of a message that did arrive?

Send a test from the same platform to a personal Gmail account you control, open it, click More next to Reply and choose Show original, as described in Google's trace an email with its full header page. Then read the Authentication-Results header. A failing third-party send looks like this (illustrative):

Authentication-Results: mx.google.com;
  dkim=pass header.i=@esp-mail.example;
  spf=pass smtp.mailfrom=bounce.esp-mail.example;
  dmarc=fail header.from=example.com

SPF and DKIM both passed, but for esp-mail.example. Neither matches example.com, so DMARC fails: the pattern behind 5.7.32 and the DMARC-policy variant of 5.7.26. Why DMARC fails when SPF passes explains it in depth, and our email header analyzer puts the three domains side by side. Google's own Admin Toolbox Messageheader tool also reads a pasted header.

How do I fix each Gmail authentication bounce?

Fix the control the code names, on the platform that sent the message. Google's DMARC troubleshooting guidance boils down to the same checks: the message must pass SPF or DKIM, and the authenticated domain must align with the From address.

Fixing 5.7.27 and 4.7.27 (SPF)

The sending IP is not authorised by the SPF record of the Return-Path domain, or the record is broken.

1. Find the Return-Path domain in the bounce or a test header.
2. Add the platform's documented include: or the server's ip4: address to that domain's record.
3. Check the record stays within 10 DNS lookups; a permerror from too many lookups fails SPF for every sender. See SPF too many DNS lookups.

example.com. TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.25 ~all"

Remember that SPF passing for the platform's own bounce domain does nothing for DMARC. If the platform supports a custom Return-Path under your domain, set it up.

Fixing 5.7.30 and 4.7.30 (DKIM)

The message carried no valid DKIM signature. Enable signing with your own domain on the sending platform and publish the selector record it gives you. Check the published key matches exactly; a truncated TXT record or a CNAME pointing to the wrong target fails verification. DKIM selectors explained shows how to find which selector a message used.

Fixing 5.7.32 and 4.7.32 (alignment)

SPF or DKIM passed, but for a domain that does not share the Organizational Domain of the From address. Under RFC 9989, DMARC counts only an aligned pass. The durable fix is DKIM signed with d= set to your domain (or a subdomain of it), because DKIM alignment survives forwarding where SPF does not. A custom Return-Path such as bounce.example.com adds SPF alignment as a second path. DMARC alignment explained covers relaxed and strict modes.

Fixing 5.7.40 and 4.7.40 (no DMARC record)

Publish a DMARC record for the From domain with a policy tag. p=none meets Google's bulk-sender requirement:

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

Validate it with the DMARC checker. A record without p=, or one published at the wrong name, triggers the same code.

Fixing the DMARC-policy variant of 5.7.26

The domain already enforces DMARC and this source is not aligned. You have two options: fix alignment for the failing source (the right answer), or temporarily relax the policy while you do. Under RFC 9989 there is no percentage ramp: pct was removed, so the choice is between policy levels (p=none, p=quarantine, p=reject). If you step back, record why and set a date to return. If the bounces come from forwarded mail rather than your own platforms, see ARC explained, because Google notes that forwarded messages often fail SPF and that content changes can break DKIM.

How should an MSP triage Gmail bounces across client tenants?

Work from the client's sending platform outward, because the platform decides who can change what. Identify the tenant type first, then the code, then the fix.

A practical order of work across a portfolio:

1. Collect the codes. Ask service desks to log the full Gmail response text, not just "bounced". The variant matters.
2. Rule out the non-authentication codes listed above (504 5.7.40, 530 5.7.0, 5.7.29).
3. Match the IP to a platform. The SPF result line gives the sending IP; compare it with the client's known sources.
4. Check DMARC aggregate reports. They show every source sending as the domain to Gmail with SPF and DKIM results and alignment, which finds the senders nobody listed. DMARC aggregate reports explained shows what to look for.
5. Fix under change control, with client approval for each DNS change, then send a test to a personal Gmail account and confirm dmarc=pass in Show original.
6. Watch for 4.7.x codes. Google says that starting November 2025 it began "ramping up its enforcement on non-compliant traffic", with "temporary and permanent rejections". A domain getting rate limited today is a domain that may be rejected next.

A multi-tenant platform such as DMARC AI for MSPs processes the aggregate reports per client domain, so step 4 becomes a per-client view rather than a pile of XML files. Google Postmaster Tools adds a compliance status dashboard per verified domain, with checks such as "SPF and DKIM authentication" and "DMARC authentication" marked "Compliant" or "Needs work".

For UK clients, the same fixes line up with the NCSC's email security guidance, which recommends SPF, DKIM and DMARC as baseline anti-spoofing controls. Stopping Gmail bounces and reaching a defensible DMARC position are the same piece of work.

How do Gmail's codes compare with Microsoft's?

Microsoft's Outlook.com uses a single code, 550 5.7.515, for all high-volume authentication failures, so you must read the headers to see which check failed. Gmail splits the same failures into separate codes per control, which makes the bounce itself more diagnostic. The underlying requirements match closely: SPF, DKIM, DMARC at p=none or stronger, and alignment. A domain fixed for one is usually most of the way there for the other; the 5.7.515 guide covers the Microsoft side.

FAQ

Does 550 5.7.26 only affect bulk senders?

No. Google's sender guidelines require every sender to use SPF or DKIM and say unauthenticated messages can be rejected with 5.7.26. The DMARC-policy variant applies whenever your own domain enforces DMARC (typically p=reject) and a message fails. Bulk senders face the stricter SPF-and-DKIM, alignment and DMARC record checks.

Is p=none enough to stop Gmail bounces?

p=none satisfies Google's requirement to publish DMARC, which clears 5.7.40. It does not fix 5.7.27, 5.7.30 or 5.7.32, because those report failing SPF, DKIM or alignment. Those need the platform configured correctly. p=none also does not protect the domain from spoofing; plan the move to enforcement.

Why do I get 5.7.26 when my SPF record is correct?

Usually because SPF passed for a different domain. Many platforms use their own Return-Path, so your record never gets checked, and if DKIM is unsigned or signed with the platform's domain, nothing authenticates as you. Check which domain appears after "SPF" in the bounce, then set up DKIM with your own domain.

Will Google support remove a 5.7.26 block?

There is no block to remove: each message is evaluated on its authentication results. Once SPF or DKIM passes and aligns, new messages from that source are judged on that basis. Google also notes that senders missing a DMARC record or exceeding a 0.3% spam rate are ineligible for delivery support and mitigation.

Should I retry messages that got a 4.7.x code?

Sending servers retry 4xx responses automatically, so some messages will deliver late. Retries do not fix the cause, though. Treat repeated 4.7.27, 4.7.30, 4.7.32 or 4.7.40 codes as a deadline: fix the named control before the same traffic starts receiving permanent 5.7.x rejections.

Related reading

• Google and Yahoo sender requirements: what DMARC means for businesses
• Microsoft 550 5.7.515: fixing Outlook.com authentication rejections
• Why DMARC fails when SPF passes
• DMARC for Google Workspace clients: an MSP implementation guide
• How to read email headers: an MSP guide