Gmail 550 5.7.26 unauthenticated email: meaning and fix

Gmail uses 550 5.7.26 for three documented failures, and it does not deliver that message. Either SPF and DKIM both failed, SPF failed under a -all policy, or the domain's DMARC policy refused the message.

Each case needs a different DNS or signing fix. After the fix, send a new message: a 5yz reply is permanent, and the client "SHOULD NOT repeat the exact request" (RFC 5321).

What the reply means

The reply carries two codes. 550 is the basic SMTP code, which RFC 5321 uses for "mailbox not found, no access, or command rejected for policy reasons". Here it is a policy rejection.

5.7.26 is the enhanced status code. In RFC 3463, class 5 is a permanent failure and subject 7 is security or policy. RFC 7372 registers X.7.26 for a message that failed more than one authentication check, and adds: "The particular mechanisms that failed are not specified." The code alone does not tell you which check failed, so read Gmail's text.

The code is about how your domain authenticates the message, not about whether the mailbox exists. For a missing mailbox, see 550 5.1.1 user unknown.

How the reply looks in a bounce

A long reply spans several lines, and RFC 5321, section 4.2.1, says every line "except the last" starts with the reply code followed by a hyphen. Gmail adds gsmtp to all its errors (Gmail SMTP error list). The domains below are examples. Gmail may break the lines in a different place:

550-5.7.26 This email has been blocked because the sender is unauthenticated.550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.550-5.7.26 Authentication results: DKIM = did not pass SPF [example.com] with550-5.7.26 ip: [203.0.113.25] = did not pass. For instructions on setting up550 5.7.26 authentication, go to Email sender guidelines. gsmtp

Read the sentence after the code

Gmail's SMTP error list documents three 550 5.7.26 sentences. Match the text you received against them.

Neither SPF nor DKIM passed

Gmail writes: "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."

Both checks failed, and Gmail needs at least one to pass for every sender. The English Gmail Help list and the Google Workspace version of the list both start with "This email". A stored bounce may still say "This mail", so search for both.

SPF failed under a hard-fail policy

Gmail writes: "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 domain (MAIL FROM) publishes an SPF record that ends in -all. The IP address that connected to Gmail is not authorized by that record. In RFC 7208, an SPF fail means "the client is not authorized to use the domain in the given identity."

The DMARC policy refused the message

Gmail writes: "Unauthenticated email from domain-name is not accepted due to domain's DMARC policy."

The DMARC policy for that From domain refused the message. The policy record can be on the From domain or on its organizational domain. The SMTP catalog says "legitimate email", and Google's troubleshooting page says "a legitimate mail", so search for both.

Google's DMARC troubleshooting page says outgoing messages "must pass either SPF or DKIM". DMARC adds a second rule: the domain that passed must align with the From domain. If neither SPF nor any valid DKIM signature passes with an aligned domain, DMARC fails; Authentication-Results reports dmarc=fail.

Find the failing check in Authentication-Results

Gmail does not accept the message, so it never adds an Authentication-Results header you can read. Send the same kind of message, from the same system, to a mailbox that accepts it. Open the full message source and find the Authentication-Results header. This header is an example, not a captured message:

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

Read three pairs of values:

• spf= and smtp.mailfrom= give the SPF result and the envelope sender domain that SPF checked.
• dkim= and header.d= give the DKIM result and the signing domain.
• dmarc= and header.from= give the DMARC result and the visible From domain.

In the example, DKIM passes for mailer.example.net and SPF passes for bounces.mailer.example.net, but the From domain is example.com. Neither passing domain aligns, so DMARC fails.

RFC 9989, which replaced RFC 7489 in May 2026, is the current DMARC standard. Under it, DMARC passes only with identifier alignment. Relaxed alignment needs the same organizational domain, so bounces.example.com aligns with example.com. Strict alignment needs the exact same domain.

Your DMARC aggregate reports group those SPF, DKIM, and DMARC results by sending IP. Move DMARC from p=none to p=reject shows how to read them.

Fix each case

Make SPF or DKIM pass

One passing check clears this 550 5.7.26 sentence, but set up both. A bulk sender who sets up only one can still get 5.7.27 or 5.7.30.

Publish SPF at the envelope sender domain, and list every address that sends for it, IPv4 and IPv6:

example.com.  TXT  "v=spf1 ip4:203.0.113.25 ip6:2001:db8::25 -all"

Sign each message with DKIM, and publish the public key at <selector>._domainkey.<domain>. Use the selector and domain that your signer puts in the signature. Here the selector is s1:

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

DKIM lets a domain "claim some responsibility for a message" (RFC 6376), but signatures "can fail to verify through no fault of the Signer". When no signature verifies, RFC 6376 says the verifier SHOULD NOT treat that message differently from a message with no signature. So "DKIM = did not pass" can mean a missing signature or a broken one; check for both.

If you send through Sendtier, Domains lists the three records a sending domain needs: a DKIM key, a return-path CNAME and a DMARC record.

Add the sending IP to SPF

Gmail names the domain after "MAIL FROM domain" and the address after "with the ip:". Add that address, or your mail service's include:, to the record at that domain. Edit the existing record instead of adding a second one:

; Before: the new server 203.0.113.40 is missingexample.com.  TXT  "v=spf1 ip4:203.0.113.25 -all"
; Afterexample.com.  TXT  "v=spf1 ip4:203.0.113.25 ip4:203.0.113.40 -all"

If the server connects over IPv6, the record needs that address too, with an ip6: term.

Align a passing domain with From

Make DKIM or SPF pass with a domain under your From domain. M3AAWG advises: "Sign all outbound mail with a domain that aligns with the RFC5322.From domain." Its 2026 sender practices say DMARC passes when "either the RFC5321.From (SPF) domain or the DKIM signing domain aligns with the RFC5322.From domain".

• DKIM: sign with d=example.com, or with a subdomain of it, and publish the key under that domain.
• SPF: set the envelope sender to a subdomain of your From domain. For example, use a CNAME to your mail service's bounce host:

s1._domainkey.example.com.  TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."bounces.example.com.        CNAME  bounces.mailer.example.net.

Publish the SPF record on the CNAME target, not on bounces.example.com, because a CNAME cannot share that name with a TXT record.

If you need a weaker policy while you fix a source, Move DMARC from p=none to p=reject explains how to step back.

Verify the fix

1. Check that DNS returns the new records:

   dig +short TXT example.comdig +short TXT s1._domainkey.example.comdig +short CNAME bounces.example.comdig +short TXT _dmarc.example.com

2. If you changed an existing record, wait until its old TTL has passed.

3. Send a new message to a Gmail address you control. Do not resend the rejected message unchanged.

4. Open the received message source. Check for dmarc=pass, and a pass for SPF or DKIM on a domain that aligns with header.from:

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

5. If the message still bounces, compare the new reply sentence with the three cases above.

Forwarded mail and mailing lists

Google's Best practices for forwarding email to Gmail say: "Gmail doesn't automatically authenticate forwarded messages that previously passed authentication." The forwarder's server, not yours, connects to Gmail, and the page notes that "forwarded messages often fail SPF authentication."

For a relayed message, RFC 9989 says "it will most likely fail SPF checks unless the RFC5321.MailFrom address is rewritten by the relaying MTA". The RFC adds: "DKIM signatures will generally remain valid in these relay situations." Changing the body or a signed header can still break them.

As the original sender, sign with an aligned DKIM key (Align a passing domain with From). Google says: "For forwarded messages, DKIM authentication is especially important". RFC 9989 is firmer: domains that publish p=reject "MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages."

If you run the forwarder, Google recommends:

• Rewrite the envelope sender to your forwarding domain.
• Avoid changing the body and the DKIM-signed headers.
• Add an X-Forwarded-For: or X-Forwarded-To: header.

RFC 9989 says "mail forwarded through mailing lists with unmodified From: header lines is frequently rejected". Some list software therefore rewrites From, for example to the list's own address.

Authenticated Received Chain (ARC) is defined in RFC 8617, an Experimental RFC from July 2019. RFC 9989 mentions it, but says "none of the methods have become widely used." Microsoft 365 admins can configure trusted ARC sealers; Microsoft says "ARC preserves the original email authentication information at the email service."

Gmail's sender guidelines apply their From alignment rule to direct email. Gmail, Yahoo and Microsoft sender requirements explains which senders it covers.

Related Gmail codes

The same Gmail list has two temporary replies with the .26 detail:

421 4.7.27 and 550 5.7.27 are Gmail's bulk-sender SPF codes. 421 4.7.30 and 550 5.7.30 are its bulk-sender DKIM codes. From alignment is 421 4.7.32 when Gmail rate-limits the message, and 421 5.7.32 when Gmail blocks it. Gmail, Yahoo and Microsoft sender requirements covers them with the bulk-sender rules.

Microsoft and Yahoo

Yahoo's SMTP error page and the Exchange Online NDR catalog have no 5.7.26 entry, and they report authentication failures with other codes.

Microsoft's 4.7.26 has a different meaning from Gmail's. Microsoft's DMARC page says: "A message passes DMARC if one or both of the described SPF or DKIM checks pass." Those described checks include alignment with the From domain. Yahoo's error page says not to retry a message that returns a 5xx error. For Outlook.com consumer mailboxes, see the sender requirements guide.

Sources were checked on 22 October 2026: Gmail SMTP error list, Gmail forwarding best practices, Gmail sender guidelines, Google DMARC troubleshooting, RFC 5321, RFC 3463, RFC 7372, RFC 7208, RFC 6376, RFC 9989, RFC 8617, M3AAWG 2020, M3AAWG 2026, Exchange Online NDR catalog, Microsoft DMARC page and Microsoft trusted ARC sealers.