Email errors

550 5.7.26: read which authentication check failed, then fix it

Gmail uses 550 5.7.26 for three different authentication failures. Read the text after the code, then fix SPF, DKIM or DMARC alignment for that sender.

By Updated Last verified

On this page
  1. Read the full error text
  2. The sender is unauthenticated
  3. SPF hard fail
  4. DMARC policy
  5. The 4.7.26 variants
  6. Check your DNS and the message
  7. Sources

The Gmail SMTP error reference (opens in a new tab) lists 550 5.7.26 with three different texts, each for a different authentication failure: neither SPF nor DKIM passed, the MAIL FROM domain's SPF record has a hard fail policy (-all) and SPF failed, or the message was not accepted due to the domain's DMARC policy. Read the text after the code to see which one you have, then fix authentication for the service that sent the message.

Read the full error text

The three 550 5.7.26 texts in Google's reference (opens in a new tab), shortened to their first sentence:

Text after 550 5.7.26 What failed Section below
"This email has been blocked because the sender is unauthenticated." Neither DKIM nor SPF passed Sender unauthenticated
"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]." SPF fail on a -all record SPF hard fail
"Unauthenticated email from domain-name is not accepted due to domain's DMARC policy." DMARC DMARC policy

Gmail adds gsmtp to all of its errors. Google also lists two 4.7.26 texts: a 451 where temporary DNS failures prevent authentication against the domain's DMARC policy, and a 421 where an unauthenticated message is rate limited.

The first digit matters. Under RFC 3463 (opens in a new tab), a 5.x.x code is a permanent failure, one not likely to be resolved by resending the message in its current form, while a 4.x.x code is a persistent transient failure, where sending in the future may be successful. The middle 7 marks a security or policy status. In RFC 5321 (opens in a new tab), a 5yz reply is a permanent negative completion reply, and the SMTP client should not repeat the exact request. Fix the cause before you send again.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account

The sender is unauthenticated

This text means DKIM did not pass and SPF did not pass for the message. Gmail's error reference (opens in a new tab) adds that Gmail requires all senders to authenticate with either SPF or DKIM, and the bounce shows the authentication results with the SPF domain and the sending IP address.

Google's sender guidelines (opens in a new tab) set the same floor for everyone who sends to Gmail: set up SPF or DKIM email authentication for your sending domains.

The bounce shows the SPF domain and the sending IP address. Use them to find the service that sent the message, then:

  • SPF lets receivers test whether the sending server is authorized to use the MAIL FROM domain, under RFC 7208 (opens in a new tab). If that service is missing from the domain's SPF record, the SPF record generator builds a record from the services that send for your domain, with an estimate against the 10 DNS lookup limit.
  • DKIM associates a domain with the message so the domain can claim responsibility for it, under RFC 6376 (opens in a new tab). Turn on DKIM signing in the sending service. If the header shows dkim=fail, DKIM fail covers how to read the reason in brackets and fix the message path, the DNS record or the key.

SPF hard fail

This Gmail text (opens in a new tab) names the MAIL FROM domain: its SPF record has a hard fail policy (-all), and the message failed SPF checks with the sending IP address. Under RFC 7208 (opens in a new tab), a fail result is an explicit statement that the client is not authorized to use the domain in the given identity.

RFC 9989 (opens in a new tab) explains why this can block mail that would otherwise pass. An SPF hard fail prefix such as -all can cause a message to be rejected early in the SMTP transaction, before any DMARC processing takes place, if it fails SPF. Messages that might otherwise pass DMARC on an aligned DKIM signature can be rejected solely due to the SPF fail. Those early rejections never appear in DMARC aggregate reports.

Two things to check:

  • Your SPF record against your senders. If the service that sent from the IP address in the bounce is not in the MAIL FROM domain's SPF record, add it.
  • The message was forwarded. Google's forwarding guidance (opens in a new tab) notes that forwarded messages often fail SPF authentication. If you run the forwarding server, change the envelope sender to reference your forwarding domain.

SPF hard fail covers what -all and ~all each do and how DMARC changes the choice.

DMARC policy

This Gmail text (opens in a new tab) says unauthenticated email from the domain is not accepted due to the domain's DMARC policy. Under RFC 9989 (opens in a new tab), a message passes the DMARC check if one or more of its authenticated identifiers align with the Author Domain. Google's sender guidelines (opens in a new tab) put it in practical terms: messages must be authenticated by SPF or DKIM, or both, and the authenticating domain must be the same domain that appears in the From header.

So a message can pass SPF or DKIM and still fail DMARC, when the domain that passed is not the From domain. DMARC fail covers how to read dmarc=fail in the Authentication-Results header and how to fix SPF and DKIM alignment for services and forwarded mail.

Forwarding affects this branch too. Google's forwarding guidance (opens in a new tab) makes two points here: DKIM authentication is especially important for forwarded messages, and changes to message contents can cause messages to fail DKIM.

Google's text asks the sender to contact the administrator of the domain if this was legitimate email. If that administrator is you, fix the sender's authentication and alignment first. DMARC policy not enabled covers whether p=none affects delivery and the safe order to move to quarantine or reject.

The 4.7.26 variants

Both 4.7.26 texts carry a 4.x.x code, which RFC 3463 (opens in a new tab) defines as a persistent transient failure: sending in the future may be successful. In the 451 text, temporary DNS failures prevent authentication. RFC 9989 (opens in a new tab) covers this case: when the DNS queries needed for DMARC validation do not complete, the message cannot be considered to pass or fail the DMARC check. A 4yz reply is a transient negative completion reply in RFC 5321 (opens in a new tab): the error condition is temporary, and the action may be requested again.

The 421 text rate limits a message because it is unauthenticated. Like the first 550 5.7.26 text, it says Gmail requires all senders to authenticate with either SPF or DKIM, in Gmail's error reference (opens in a new tab).

Check your DNS and the message

The free SPF, DKIM and DMARC check reads your domain's public DNS records. For SPF it flags a missing record, a rule that lets anyone send (+all) or decides nothing (?all), a soft fail (~all), and a record close to or over the 10 DNS lookup limit. For DKIM it looks for keys under commonly used selectors, and for DMARC it flags a missing record, a policy of none, no reporting address, a policy that covers only part of your email, and subdomains left at none.

A DNS finding shows how your domain is set up. It does not show where a particular message landed.

Sources

Tools for this

Frequently asked questions

Does every 550 5.7.26 error mean the same thing?

No. Gmail uses it for three texts: the sender is unauthenticated because neither SPF nor DKIM passed, the MAIL FROM domain has an SPF hard fail policy and failed SPF, or the message failed the domain's DMARC policy.

Can a message with an aligned DKIM signature still be rejected for SPF?

Yes. An SPF -all can get a message that fails SPF rejected early in the SMTP transaction, before any DMARC processing, even if it would otherwise pass DMARC on an aligned DKIM signature.

How is 4.7.26 different from 5.7.26?

A 4.x code is a temporary failure and sending again later may succeed. A 5.x code is permanent, and resending the message unchanged is not likely to work.

Check your domain now

See the SPF, DKIM and DMARC records your domain publishes and what to fix first. Free, no account needed.

Create a free account