Gmail 550-5.7.26 unauthenticated error: causes and fixes

Gmail answers 550-5.7.26 when a message arrives without authentication it can tie to the domain in your From address: either neither SPF nor DKIM passed, or they passed for someone else's domain and your DMARC policy told Gmail to reject the mail. The fix is almost never "add another SPF include"; it is making DKIM sign with your own domain, and the envelope sender (Return-Path) sit on your domain too, so that at least one of them aligns with From.

What does Gmail's 550-5.7.26 error mean?

It is a permanent rejection (the leading 5) of mail that Gmail considers unauthenticated. Google's SMTP error reference lists three wordings under 5.7.26, and the exact sentence in your bounce tells you which of the three checks failed.

The 550- with a hyphen is not a different code. SMTP servers send multi-line replies as 550- on every line but the last, which uses 550 with a space, so the same error appears as "550-5.7.26" and "550 5.7.26" depending on where you copy it from.

As of November 2026, wording from Google's SMTP error reference.

Why you see it more often now: Gmail's email sender guidelines have required every sender to use SPF or DKIM since February 1, 2024, and bulk senders (more than 5,000 messages a day to Gmail) to use SPF, DKIM and DMARC with an aligned From domain. Google's sender guidelines FAQ says that starting November 2025 Gmail is "ramping up its enforcement on non-compliant traffic", with temporary and permanent rejections. Mail that used to land in spam now bounces.

For the background on what each record does, see our SPF, DKIM and DMARC explainer. This article is about the specific bounce and how to get rid of it.

How do you read Authentication-Results in "Show original"?

Send a message to a Gmail address you control, open it, choose More → Show original, and find the Authentication-Results: mx.google.com header. It records three verdicts and, more importantly, the three domains each verdict was about.

If the message bounced and never arrived, the bounce itself often quotes the same results; otherwise send the same mail to a Gmail inbox from a domain without a strict DMARC policy, or temporarily relax yours to p=none so the message is delivered and you can inspect it.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@relay.example.net header.s=s1 header.b=Ab12Cd34;
       spf=pass (google.com: domain of bounces+8812@mail.relay.example.net designates 203.0.113.25 as permitted sender) smtp.mailfrom="bounces+8812@mail.relay.example.net";
       dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=example.com

This is the classic 550-5.7.26 case: both SPF and DKIM say pass, yet DMARC fails. Read the domains, not the verdicts:

DMARC passes when at least one of SPF and DKIM passes and its domain aligns with header.from. Neither does here, so dmarc=fail, and because example.com publishes p=reject the result is dis=REJECT: the bounce.

💡 Tip: A message can carry several DKIM signatures. One aligned signature is enough, so look for a dkim=pass whose header.i ends with your own domain before changing anything else.

Why does mail sent through a relay fail DMARC?

Because out of the box most relays sign with their own domain and use their own bounce domain, so both checks pass for the relay, not for you. Alignment only happens once you give the relay your domain for at least one of the two.

The current DMARC specification, RFC 9989 (May 2026, replacing RFC 7489), defines two modes. Relaxed alignment, the default, accepts any domain with the same organizational domain, so bounce.example.com aligns with example.com. Strict alignment (aspf=s or adkim=s) needs an exact match. RFC 9989 finds the organizational domain with a DNS tree walk instead of the Public Suffix List; for ordinary domains the result is the same.

As of November 2026, alignment rules from RFC 9989.

Aim for the last-but-one row. DKIM alignment survives forwarding better than SPF (the next sections explain why), and SPF alignment gives you a second path when a DKIM signature gets broken by a gateway that rewrites the body.

Other typical causes of the same failure:

• A new sending service nobody added. A CRM, a helpdesk or an invoicing tool sends as @example.com with its own defaults. Every service that uses your From domain needs the same treatment.
• A From domain the sender doesn't own. Sending as @gmail.com or @yahoo.com through your own server can never align; both publish DMARC policies that reject or quarantine such mail.
• Strict alignment you didn't need. adkim=s; aspf=s fails when a relay signs with mail.example.com while From is example.com.
• A broken DKIM key. A TXT record split wrongly across strings, a key the panel truncated, or a selector the relay rotated: dkim=fail or dkim=neutral (body hash did not verify).

How do you fix 550-5.7.26 step by step?

Make DKIM sign with your domain, give the envelope sender your domain where the relay allows it, keep SPF valid for the envelope domain, and publish DMARC. Work through the steps in this order; each one is testable on its own.

1. List everything that sends as your domain

   Your marketing platform's relay, your mailbox provider (Google Workspace, Microsoft 365), transactional mail from your app, CRM, helpdesk, billing. DMARC aggregate reports (step 5) will show any you forgot.

2. Turn on DKIM with your own domain at every relay

   Each relay gives you either CNAME records pointing to keys it rotates, or a TXT record with a public key. Publish exactly what it shows, then verify in the relay's console. Google recommends 2048-bit keys where the provider supports them (sender guidelines).

3. Set a custom MAIL FROM (Return-Path) domain

   Most relays let you use a subdomain such as bounce.example.com as the envelope sender. They ask for an MX record (so bounces still reach them) and an SPF TXT record on that subdomain.

4. Fix SPF for the envelope domain

   One SPF record per domain, ending in ~all or -all, with no more than 10 DNS-querying mechanisms (include, a, mx, ptr, exists, redirect) under RFC 7208, section 4.6.4. Two SPF records on one name are a permerror, which counts as a fail.

5. Publish DMARC, starting with p=none

   A TXT record on _dmarc.example.com with a reporting address. Move to quarantine and reject once reports show every legitimate source aligned.

6. Retest

   Send to a Gmail test inbox and confirm dmarc=pass before resending anything to real subscribers.

Example records for a domain that sends through Google Workspace for staff mail and Amazon SES for newsletters (replace the tokens, region and report address with yours):

; SPF for the From domain (staff mail via Google Workspace)
example.com.                      TXT   "v=spf1 include:_spf.google.com ~all"

; Custom MAIL FROM subdomain for Amazon SES
bounce.example.com.               MX    10 feedback-smtp.eu-west-1.amazonses.com.
bounce.example.com.               TXT   "v=spf1 include:amazonses.com ~all"

; Easy DKIM: three CNAMEs from the SES console (one shown)
abc123token._domainkey.example.com. CNAME abc123token.dkim.amazonses.com.

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

The SES-specific details (sandbox, regions, SMTP credentials) are in our Amazon SES SMTP setup guide. Other relays name the same features differently: "custom return path", "bounce domain", "branded sending domain" or "domain authentication".

⚠️ Warning: Do not jump to p=reject to "be compliant". Gmail's bulk-sender rule accepts p=none; a strict policy published before every source is aligned is exactly what produces 550-5.7.26 for your own legitimate mail.

The full sequence for tightening DMARC, warming up and monitoring is in the email deliverability guide for self-hosted senders.

Why do forwarded messages and mailing lists bounce?

Forwarding sends your message from a new IP that is not in your SPF record, so SPF fails; mailing lists often change the subject or add a footer, which breaks your DKIM signature. With both gone, a strict DMARC policy rejects the forwarded copy.

Google's best practices for forwarding email to Gmail say that forwarded messages often fail SPF and that Gmail re-checks authentication itself. That is why an aligned DKIM signature matters more than SPF: an unmodified message keeps a valid signature across forwards.

ARC (Authenticated Received Chain, RFC 8617, an Experimental RFC) lets each intermediary record the authentication results it saw and seal them with its own signature. A receiver that trusts that intermediary can use the sealed results when the original checks no longer pass. ARC is added by forwarders and list servers, not by you as the original sender, and receivers decide on their own whether to trust a given sealer.

• If your own mail bounces after a forward: make sure DKIM aligns and that you don't modify messages after signing (some link-tracking or footer gateways do).
• If you run the forwarder or list: follow Google's advice to rewrite the envelope sender to your forwarding domain, keep SPF and DKIM for that domain, and avoid edits that break DKIM. List software commonly rewrites From to the list's own address for senders with strict DMARC policies.
• If it is a subscriber's private auto-forward: you cannot fix their setup; one bounce from such an address is not a sign that your authentication is broken.

How do you test that the fix worked?

Check DNS from outside, send one message to a Gmail test inbox, read Authentication-Results, and then follow Postmaster Tools for at least a week.

# 1. Records as the world sees them (one SPF record only)
dig +short TXT example.com | grep spf1
dig +short TXT bounce.example.com
dig +short TXT _dmarc.example.com
dig +short CNAME abc123token._domainkey.example.com

# 2. A test through the same relay and port your platform uses (swaks)
swaks --to you@gmail.com --from newsletter@example.com \
      --server email-smtp.eu-west-1.amazonaws.com --port 587 --tls \
      --auth LOGIN --auth-user "$SMTP_USER" --auth-password "$SMTP_PASS" \
      --header "Subject: DMARC alignment test"

A passing result looks like this, with your domain in all three places:

dkim=pass header.i=@example.com header.s=abc123token
spf=pass (google.com: domain of 0102018f-test@bounce.example.com designates 203.0.113.40 as permitted sender) smtp.mailfrom=bounce.example.com
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Google's Postmaster Tools compliance status dashboard shows whether your domain meets the sender guidelines (SPF, DKIM, and for bulk senders DMARC and one-click unsubscribe). Google notes the data uses a rolling average over several days and suggests checking again after 7 days, so don't expect it to turn green the hour you fix DNS. One-click unsubscribe is a separate requirement; see our RFC 8058 guide.

What if you never sent the message that bounced?

Then someone else put your domain in the From address, and Gmail did exactly what your DMARC policy asked. A bounce for a message you never sent is "backscatter": the forger's server delivered the rejection to the Return-Path it forged, which can be yours.

Check the bounce's quoted headers. A sending IP that belongs to none of your providers, a Message-ID format your systems don't use, or a subject you never wrote all point to spoofing. Your DMARC aggregate reports show the same thing in bulk: sources with your header.from that fail both SPF and DKIM.

• Don't loosen DMARC to make these bounces stop; p=reject is what protects your recipients from the forged mail.
• Filter or discard bounces to addresses you never use as a Return-Path.
• If the bounces name a real sender of yours that you had forgotten, that is step 1 of the fix above, not spoofing.

Persistent bounces from legitimate mail are a different topic: classifying hard and soft bounces and suppressing addresses is covered in our bounce management guide.

Fixing 550-5.7.26 when you send from NetSendo

NetSendo sends through the mailbox you connect (an SMTP relay such as Amazon SES or Mailgun, the Gmail API, SendGrid, or NMI, the NetSendo Mail Infrastructure), so authentication is set up at that provider and in your DNS. NetSendo publishes no SPF include of its own.

• Who signs DKIM: for SMTP, SendGrid and Gmail mailboxes the provider signs, not NetSendo; enable DKIM with your domain there. NMI generates 2048-bit DKIM keys and shows the DNS records to copy.
• Return-Path: since NetSendo 2.2.0 the sending mailbox's bounce address is set as the envelope sender on every send through SMTP and Gmail mailboxes, not only on automation sends. With a bounce mailbox on your own domain, SPF is checked for that domain, so its SPF record must allow the relay. SendGrid's API sets its own envelope sender, so use SendGrid's domain authentication instead. Some relays replace the envelope sender with their own bounce domain; check their custom MAIL FROM setting.
• Checks inside NetSendo: Deliverability Shield, part of the GOLD licence, re-checks SPF, DKIM and DMARC of verified domains. Since 2.8.0 you can enter the DKIM selector of relays such as Amazon SES that use per-domain tokens, and the DMARC generator starts at p=none with relaxed alignment. The DNS records themselves work on any licence, including the free SILVER licence.

Mailboxes, sending options and NMI are described in the configuration docs; installing NetSendo takes a few commands from the quick start.

Frequently asked questions

Sources

• Google Workspace: Gmail SMTP errors and codes
• Google: Email sender guidelines
• Google: Email sender guidelines FAQ
• Google: Postmaster Tools dashboards
• Gmail Help: Best practices for forwarding email to Gmail
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 7208: Sender Policy Framework (SPF)
• RFC 8617: Authenticated Received Chain (ARC)