550 5.7.23" spf check failed and gmail rejected legitimate sender mail

TL;DR

Fix the SPF authorisation first: find every IP and service that sends as your domain, rebuild the SPF record so those senders are included without exceeding the lookup limit, and republish it in DNS. Then resend and confirm Gmail accepts the message. A 550 5.7.23 bounce means Gmail evaluated SPF, got a fail, and your DMARC policy told it to reject, so no content change will help until the envelope sender is authorised.

"550 5.7.23" spf check failed and gmail rejected legitimate sender mail

Use this when

• Gmail returns 550 5.7.23 for mail from your domain or a vendor sending as you.
• Authentication-Results on the bounce or a test message show spf=fail.
• The sender is legitimate and should be authorised to send as your domain.

Not for this skill when

• SPF passes but DMARC still fails on alignment. Use the alignment skill instead.
• The mail is unwanted or from a sender you do not recognise. Treat it as spoofing, not a deliverability fault.

Steps

1. Pull the full bounce and read the Authentication-Results and the reported sending IP, then list which service owns that IP. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the sending IP is matched to a named service in your inventory
2. Query your current SPF record and expand every include by hand, counting DNS lookups and checking that the failing IP is actually covered. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: you can point to the mechanism that should cover the IP, or confirm none does
3. Add the missing sender with an include for the vendor published SPF record or a narrow ip4 mechanism, and remove stale includes so the total stays at ten lookups or fewer. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: a lookup count shows ten or fewer and no permerror appears in an SPF checker
4. Wait for DNS propagation, then send a fresh test to a Gmail mailbox and read the delivered headers. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the test shows spf=pass and no 550 bounce is returned
5. Check DMARC aggregate reports for the next two days for the same source. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: reports show the source passing SPF and DMARC with no new fail volume

Why it happens

SPF authorises servers for the envelope sender domain, and Gmail enforces the result together with your DMARC policy. Legitimate mail fails most often after a quiet change: a new vendor, a migrated gateway, or a new IP range starts sending before DNS is updated, or an old include is removed during cleanup. Because the policy is reject, a plain SPF fail that would once have landed in spam now becomes a hard bounce at the door.

Variants and edge cases

550 5.7.23 gmail spf fail legitimate mail bounce

The bounce-code phrasing admins search from the non-delivery report rather than from a header.

gmail rejected mail spf check failed how to authorise sender

The how-to variant used when the vendor name is known but the record change is not.

spf fail dmarc reject gmail 5.7.23 after vendor change

The change-linked variant that appears after a migration or a new sending service.

Compatibility: RFC 7208 SPF, RFC 7489 DMARC, Gmail sender guidelines, Microsoft 365 and Google Workspace sending services.

Edge cases to check:

• A subdomain sender needs its own SPF record; fixing the root record alone does not authorise it.
• Third party senders that use their own envelope domain pass SPF on their domain, so DMARC then depends on DKIM alignment instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_x6abLBAvk5ywpG21waPA8Q