Blog
Gmail 550 5.7.26: fix SPF and DMARC authentication failures
Reviewed by the Free Domain Mail editorial team · Updated
Gmail returns 550 5.7.26 when it rejects a message because the sender is not authenticated, SPF fails under a hard-fail policy, or the From domain's DMARC policy rejects unauthenticated mail. The exact sentence after the code identifies which path to investigate.
Read the complete bounce before editing DNS
Copy the full diagnostic line from the nondelivery report. Do not stop at 550 5.7.26. Gmail uses the same enhanced status code for several related failures, including SPF hard fail, missing authentication and DMARC rejection.
Record the visible From domain, envelope MAIL FROM domain, sending IP, DKIM signing domain and Authentication-Results values. Those fields show which identity failed. A change to an unrelated hostname will not repair the message path.
If Gmail reports an SPF hard fail
An SPF hard-fail message says that the MAIL FROM domain publishes -all but the sending IP did not pass. Find the service that submitted the message and confirm whether it is authorized to send for that exact MAIL FROM hostname.
Publish one SPF policy at the hostname. Merge legitimate providers into that policy instead of adding a second v=spf1 TXT record. Keep the policy within SPF's ten DNS-lookup limit, and remove abandoned senders rather than authorizing broad networks.
If Gmail says the message is unauthenticated
Google expects ordinary senders to pass SPF or DKIM and requires stronger authentication for bulk sending. A message can fail both when it leaves through an unlisted system and carries no valid DKIM signature for a domain controlled by the sender.
Fix the actual sending platform. Confirm its envelope domain is covered by SPF, enable its DKIM signing, and publish the provider-issued selector. Do not invent a selector or copy a public key from another account.
If DMARC policy caused the rejection
DMARC evaluates alignment with the visible From domain. SPF may pass for a provider-owned bounce domain and still be unaligned. DKIM may pass with a signing domain that does not align. At least one aligned method must pass.
Keep the From address on a domain you control. Configure a custom MAIL FROM domain when aligned SPF is part of the design, or use aligned DKIM. Review aggregate reports before increasing policy, but do not weaken a legitimate domain's policy merely to accommodate an unauthorized sender.
Check the domain in Free Domain Mail
Sign in, open Manage, choose Domains and select the connected domain. Review Allow sending for SPF and Authenticate sending for DKIM. Copy the records shown for that domain; the examples for freedomainmail.com describe the field layout only.
After DNS is saved, continue to Check and complete. Use SPF Checker for the envelope hostname and DKIM Checker with the selector from the provider. A passing public lookup proves publication, while a received message header proves the sending system used it.
Verify the repaired message
Send one low-volume test to Gmail through the same application and provider that failed. In Gmail, open Show original and confirm SPF, DKIM and DMARC results. Check that at least one passing authentication method aligns with the visible From domain.
If authentication passes but delivery still fails, read the new SMTP response. Rate limits, reputation, content policy and complaint signals require different fixes and should not be treated as an SPF problem.
Common mistakes to avoid
- Publishing two SPF records at the same hostname.
- Checking only the visible From domain when SPF evaluated a different MAIL FROM domain.
- Adding an include for a provider that did not send the rejected message.
- Copying a DKIM selector or key from another domain or account.
- Changing DMARC to p=none without fixing the unauthorized sending path.
- Retesting through a different service from the one that produced the bounce.
Frequently asked questions
Is Gmail 550 5.7.26 always an SPF error?
No. Gmail uses the code for several authentication failures. Read the complete diagnostic sentence to distinguish SPF hard fail, unauthenticated mail and DMARC rejection.
Can I fix it by changing -all to ~all?
That may change the SPF result, but it can hide an incomplete sender inventory. Authorize the legitimate sender and test alignment before changing enforcement.
Why can SPF pass while DMARC fails?
SPF can authenticate a MAIL FROM domain that does not align with the visible From domain. DMARC needs aligned SPF or aligned DKIM.
How long should I wait after changing DNS?
Wait for the previous TTL and verify the authoritative public answer. Waiting does not correct a duplicate SPF record, wrong hostname or missing sender.
Technical references
Primary specifications and provider documentation relevant to this guide: