550 5.7.26 Sender Is Unauthenticated: The Gmail Bounce and the Fix
Gmail rejects mail with 550 5.7.26 when neither SPF nor DKIM passes for your domain. What each line of the bounce means, the usual causes, and the fix.
Since February 2024 Gmail refuses mail that is not authenticated, and it says so plainly: "550-5.7.26 This mail has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM." The bounce then prints the result of both checks, so it also tells you what to fix. This page reads the bounce line by line, lists the four setups that produce it, and gives the records that make it stop.
Quick answer
Publish an SPF record that includes the server that actually sent the message, and a DKIM record so the provider can sign your mail. Either one passing for your domain is enough to clear 5.7.26; both passing plus a DMARC record is the proper fix. If the bounce mentions your DMARC policy instead, the message was sent from somewhere your DMARC does not cover; send it through your real mail provider or add that sender to SPF and DKIM.
Reading the bounce
- "DKIM = did not pass": the message carried no DKIM signature for your domain, or the signature did not verify. The sender either does not sign, or signs with a key that is not in your DNS.
- "SPF [yourdomain.com] with ip: [1.2.3.4] = did not pass": the IP that handed the message to Gmail is not listed in your SPF record. The IP is printed; look it up to see whose server it is.
- "Unauthenticated email from yourdomain.com is not accepted due to domain's DMARC policy": your DMARC record says reject (or quarantine) and the message failed both checks. Same causes, stricter outcome.
- "The MAIL FROM domain has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks": the envelope sender domain uses -all and the sending IP is not in it.
- A related code, 550-5.7.25, says the sending IP has no PTR (reverse DNS) record. That is a server problem, not a DNS record on your domain; hosted providers already have PTR set.
The four setups that cause it
- Mail sent from a website, CRM or invoicing tool "from" your address through that tool's servers. Those servers are not in your SPF and cannot sign with your DKIM key.
- A mail app still pointed at a previous provider's SMTP server after you moved the domain. The old server's IP is no longer in SPF.
- The domain has an MX and a mailbox but the SPF and DKIM records were never added, or were added at the wrong DNS host.
- A forwarder in the path. Mail forwarded from an old address to Gmail loses SPF (the forwarder's IP is not in the original sender's SPF), and if DKIM was never there either, Gmail rejects it.
Free business email on your own domain
OquMail gives you up to 15 mailboxes on your domain — free — with guided SPF/DKIM/DMARC, webmail, IMAP/SMTP for any mail app, and a send API. Setup is a few DNS records; changes usually take effect within minutes, occasionally up to 48 hours. Start at oqumail.com.
Fix it
- Open the OquMail dashboard, select the domain and copy the SPF and DKIM records. SPF goes on a TXT records (short text lines in DNS used for email security) at the root, value v=spf1 MX (Mail Exchanger — where incoming email is delivered) a:mail.oqumail.com ~all. DKIM goes on a TXT record at the selector name ending in ._domainkey.
- Add a DMARC record too: a TXT records (short text lines in DNS used for email security) at _dmarc starting v=DMARC1; p=none; with a rua= address you read. Reports arrive from Gmail within a day and show every source sending as your domain.
- Point every mail app at mail.oqumail.com, port 587, STARTTLS, with the mailbox login. Mail that leaves through your provider is covered by both records.
- For a website or tool that sends as your address, either switch it to send through the mailbox (SMTP or the API) or, if it must use its own servers, add its include to SPF and publish the DKIM key it gives you. Keep SPF under the 10-lookup limit while you do it.
- Send a test to a Gmail address and open Show original: SPF, DKIM and DMARC should all show PASS with your domain beside them.
The forwarding case
If the bounce came from a message someone forwarded to Gmail, the fix is on the forwarder's side: use SRS (sender rewriting) or deliver the forwarded mail from an address on the forwarding domain. If you are the one forwarding your own old address to Gmail, stop forwarding and add the mailbox to Gmail or a mail app over IMAP instead; forwarded mail has been unreliable since the 2024 rules.
Common questions
SPF passes. Why does Gmail still say unauthenticated?
Check which domain passed. SPF on the envelope sender (often the provider's bounce domain) does not count unless it matches the From domain. The bounce prints the SPF domain it evaluated; if that is not your domain, the From address and the envelope sender differ.
Do I need both SPF and DKIM?
Gmail requires one for ordinary senders and both for anyone sending 5,000 or more messages a day. Set up both anyway: SPF breaks on forwarding, DKIM survives it, and DMARC needs at least one aligned pass.
How fast does the rejection stop?
As soon as the records are visible in DNS, usually within minutes of adding them. Gmail evaluates each message on arrival; there is no reputation penalty to wait out for a 5.7.26.
Want to see how your own domain is set up? Use the free SPF checker, DMARC checker and MX lookup: they run in your browser and store nothing.