SMTP error code · permanent failure (5xx)

SMTP error 550 5.7.26: unauthenticated email is not accepted

Samuel Chenard

By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 16, 2026

550 5.7.26 is Gmail's permanent rejection for unauthenticated email: your message failed both SPF and DKIM, or failed the sending domain's DMARC policy, so Google refused it outright. It's a sender-side problem: publish correct SPF and DKIM for every service that sends as your domain, and Gmail accepts the mail again.

550 5.7.26 at a glance
Code550 5.7.26
ClassPermanent (5xx): the message was refused and will not retry
CategoryAuthentication
Side at faultSender
Auth-relatedYes (SPF/DKIM/DMARC)

What the bounce actually says

The exact wording varies by provider. These are the documented strings, verbatim. Match yours to pin down which variant you hit.

Gmail (Google Workspace) — no passing SPF or DKIM

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. For instructions on setting up authentication, go to Email sender guidelines.

Source: knowledge.workspace.google.com

Gmail (Google Workspace) — SPF hard fail

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. For more information, go to Email sender guidelines.

Source: knowledge.workspace.google.com

Gmail (Google Workspace) — DMARC policy rejection

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. To learn about the DMARC initiative, go to Control unauthenticated email from your domain.

Source: knowledge.workspace.google.com

Why you're seeing 550 5.7.26

Since February 2024, Gmail requires every sender to authenticate with SPF or DKIM, and bulk senders to pass both, plus DMARC. 550 5.7.26 is what enforcement looks like: Google checked the connecting IP against your domain's SPF record, checked the message for a valid DKIM signature, and neither passed. The bounce text tells you which variant you hit: a plain double failure, an SPF -all hard fail, or a rejection ordered by your own domain's DMARC policy. In every case the receiving side is working as designed; the fix is entirely in your DNS and your sending setup.

Likely causes, ranked

Likely causeWhat's happening
The sending service isn't in your SPF recordThe most common trigger. A CRM, invoicing app, ticketing system, or new mail server sends as your domain, but your SPF record doesn't include its IPs. Gmail checks the connecting IP against SPF, finds no match and, with no passing DKIM to fall back on, blocks the message.
DKIM signing is off, or signs the wrong domainThe service sends without a DKIM signature, or signs with its own default domain (like `sendgrid.net`) instead of yours. Gmail sees `DKIM = did not pass` for your domain even though a signature technically exists.
No SPF or DKIM published at allNew domains and hand-built mail servers often skip authentication entirely. Before 2024 this mail was merely spam-foldered; under Gmail's sender requirements it's now rejected at the door.
SPF hard fail (-all) with an unlisted IPYour SPF record ends in `-all`, which explicitly tells receivers to refuse mail from any IP not listed. Gmail takes you at your word. This is the second bounce variant. Google's docs cite only SPF for this variant; in practice senders report it can fire even alongside a valid DKIM signature.
Your own DMARC policy ordered the rejectionThe third variant. Your domain publishes `p=reject` or `p=quarantine`, and this message failed both aligned SPF and aligned DKIM, so Gmail did exactly what your policy asked. Legitimate mail hitting this means a real sending source was never authenticated before enforcement.
Forwarding broke SPFA forwarder re-sends the message from its own IP, which your SPF record doesn't cover. Without a surviving DKIM signature the forwarded copy arrives unauthenticated and gets blocked.

How to fix 550 5.7.26

  1. Check the sending domain's DMARC, SPF, and DKIM in one pass

    Run the domain from the bounced message's From address through the free DMARC checker below. It shows whether SPF and DKIM records exist, what your DMARC policy currently orders receivers to do, and which of the three the bounce variant points at.

    Run the check now

    Enter the sending domain and the check runs instantly on the next page. Free, no signup.

  2. Add every sending service to your SPF record

    List each platform that sends as your domain (mail host, CRM, billing, marketing, monitoring) and make sure your SPF record includes each one's documented include: or IP range. Verify the result with the free SPF checker at /tools/spf and stay under the 10-DNS-lookup limit.

  3. Turn on DKIM signing for your domain at each service

    In each service's settings, generate DKIM keys for your domain (not the provider's default), publish the CNAME or TXT records they give you, and enable signing. Confirm the selector resolves with the DKIM checker at /tools/dkim.

  4. Confirm alignment with your From domain

    Gmail's DMARC variant only clears when the domain that passes SPF or DKIM matches the visible From domain. A passing signature for sendgrid.net doesn't help mail sent as yourdomain.com. Set the custom return-path and signing domain each provider offers.

  5. Send a test to a Gmail mailbox and read the headers

    After DNS propagates (minutes to a few hours), send a test to any Gmail address, open Show original, and check for spf=pass, dkim=pass, and dmarc=pass. The free email header analyzer at /tools/email-header-analyzer parses the raw headers for you.

  6. Re-send the failed mail and monitor DMARC reports

    Once headers show passes, re-send whatever bounced: 550 is permanent, so nothing retries on its own. Then keep DMARC aggregate reports flowing so the next unauthenticated sender shows up in a report instead of a bounce.

Related free tools: SPF checker · DKIM checker · Email security score

Authentication is the fix, not a workaround

Every path out of 550 5.7.26 runs through the same three DNS records: SPF, DKIM, and DMARC. Mailbox providers no longer treat them as best practice; they're the entry ticket, and a domain that drifts out of alignment starts bouncing again without anyone changing a thing on your side.

The durable fix is enforcement: publish correct records, watch the DMARC reports for senders you missed, and move the domain to p=reject so receivers drop spoofed mail instead of bouncing yours.

Enforce it — don't just monitor it

Palisade's AI agent takes domains all the way to enforcement: hosted SPF, DKIM, DMARC, and MTA-STS records, DMARC reports monitored continuously, and policies advanced to p=reject automatically. Your first domain is free, and the full product is open for 15 days, no card.

Start free trialBook a demo

Free 15-day trial · No credit card · Your own domain free forever (NFR)

Why it matters for MSPs

One 550 5.7.26 bounce is a DNS fix; fifty client domains hitting Gmail's sender requirements at once is a Monday morning. Every tenant with an unauthenticated line-of-business app (the invoicing tool, the scan-to-email copier, the legacy CRM) is one Gmail update away from this ticket, and hand-auditing SPF and DKIM across a managed fleet doesn't scale. Palisade hosts and manages the SPF, DKIM, and DMARC records for every client domain, spots unauthenticated senders in the DMARC reports before Gmail bounces them, and walks each domain to p=reject automatically. It plugs into ConnectWise, HaloPSA, and Autotask so the fix lands in your existing workflow, and your own MSP domain is a free NFR domain you can prove it on first.

Frequently asked questions

Google's sender requirements (rolled out from February 2024) made SPF-or-DKIM authentication mandatory for all senders, and SPF-plus-DKIM-plus-DMARC mandatory for bulk senders. Mail that used to land in spam folders now gets rejected outright. If nothing changed on your side, a sending service you never authenticated finally met enforcement.

No. It's purely an authentication verdict: Gmail is saying it can't verify the mail came from your domain, not that your IP has a bad history. That's good news: you don't need a delisting request, just correct SPF and DKIM records in DNS.

Gmail requires at least one to pass for all senders, and both (plus DMARC) if you send 5,000+ messages a day to personal Gmail accounts. Set up both regardless: SPF breaks under forwarding, DKIM survives it, and DMARC alignment needs at least one of them passing with your From domain.

SPF and DKIM records typically propagate within minutes to a few hours, depending on your DNS TTLs. Because 550 is a permanent failure, the original message won't retry by itself. Verify a test message shows spf=pass and dkim=pass in its headers, then re-send.

Related error codes

550 5.7.509550 5.7.23DKIM verification failure (550)554 5.7.1421 4.7.0p=reject-all vs ~alldmarc=fail
Email deliverability, fixed: the full guide