550 5.7.23: your mail failed SPF, and how to fix it

What the bounce means

A 550 5.7.23 rejection from Microsoft 365 means the receiving server checked SPF and your message failed: the sending IP is not authorized by the SPF record of your envelope domain. Microsoft describes it as “the destination email system uses SPF to validate inbound mail, and an issue affects your SPF configuration,” and the bounce reads:

550 5.7.23 The message was rejected because of Sender Policy
Framework violation

Gmail returns its own codes for the same failure on bulk mail:

550-5.7.27 This message was blocked because it didn't pass SPF
authentication. Gmail requires bulk email senders to authenticate
their email with SPF. Authentication results: SPF with [ip-address]
= did not pass

421-4.7.27 Your email has been rate limited because SPF authentication
didn't pass for this message. Gmail requires all bulk email senders
to authenticate their email with SPF.

The 5.7.27 is a permanent block; the 4.7.27is the temporary, rate-limited version of the same problem. Both apply to Gmail's bulk-sender rules (roughly 5,000+ messages a day to Gmail, in force since February 2024).

SPF checks the envelope, not the From you see

This trips people up. SPF validates the envelope sender (the Return-Path / MAIL FROM domain), not the From: address shown in the mail client (RFC 7208). So the SPF record being checked is the one on whatever domain your sending service uses as its return-path. If a service sends with its own envelope domain, its SPF is what is checked. That is also why a message can pass SPF here and still fail DMARC: DMARC additionally requires that the passing identity align with your visible From: domain.

What causes it

• A legitimate sending IP or service is not in your SPF record (most common). You added an ESP, relay, or on-premises server, but never added its IP or include: to the SPF record, so SPF returns fail.
• The Microsoft High Risk Delivery Pool (when you send from Microsoft 365). If Microsoft flags one of your outbound messages as spam, it routes the message through a separate pool of IPs that are notin your SPF. Microsoft is explicit: “Messages in the High Risk Delivery Pool won't pass SPF checks, and therefore won't be accepted by the destination email organization.”
• An unprovisioned domain in your Microsoft 365 tenant. Sending for a domain you own but have not added and verified in the tenant; Microsoft rate-limits mail from unprovisioned domains.
• Forwarding or relaying that changes the connecting IP to one outside your SPF.

How to fix it

• Check your SPF record. Run the SPF checker (or any public SPF checker) and confirm the record exists, is a single v=spf1 record, and lists every service you send through.
• Find the failing IP.Read the bounce's diagnostic details or the message's Received-SPF header. If it is anything other than pass, that is the sending IP to authorize.
• Add the IP or the provider's include: to your one SPF record. A domain may publish only one SPF record; every sender goes in that one.
• Use ~all, not -all, until you are sure. Keep a softfail (~all, a tilde) while you confirm every legitimate sender is covered. Tighten to -all (a hyphen, hardfail) only after that, or you turn a missing include into a hard rejection.
• On Microsoft 365 specifically:provision every domain you own in the tenant, add any on-premises sending IPs to each domain's SPF, and confirm the message was not sent through the High Risk Delivery Pool (turn on outbound spam notifications; if it was a false positive, contact support).
• Allow time. DNS changes can take 24 to 48 hours to take effect everywhere.

SPF fail is not the same as too many lookups, or DMARC

Three different problems get blamed on each other. Fix the right one:

• This page, SPF fail (5.7.23 / 5.7.27): SPF was evaluated and the sending IP is not authorized. The fix is to add the sender to your record.
• SPF PermError (“too many DNS lookups”): your record needs more than 10 DNS lookups, so it cannot be evaluated at all. That is a record you have to shrink, not a missing IP. See SPF PermError: too many DNS lookups.
• DMARC rejection (550 5.7.1 / 5.7.509 on Microsoft, 5.7.26 on Gmail): the message failed DMARC, which keys off your visible From: domain and alignment, not the envelope. See 550 5.7.1: rejected per DMARC policy.

How to confirm it is fixed

• Re-run the SPF checker and confirm the sending IP is now covered and the record is under the 10-lookup limit.
• Send a test, open the original, and confirm Authentication-Results shows spf=pass for the sending IP. The header analyzer reads it in plain English.
• Watch your DMARC reports: the source that was failing SPF should start passing.

Frequently asked

Does 550 5.7.23 mean my SPF record is broken?

Not necessarily. It means SPF was checked and the sending IP was not authorized by your record, usually because a legitimate service is not listed in it. A separate problem, an SPF record that needs more than 10 DNS lookups, returns permerror and has a different fix.

Which domain's SPF is being checked?

The envelope sender (the Return-Path / MAIL FROM domain), not the From:address you see in the message. If a service sends with its own envelope domain, that domain's SPF is what is checked, which is also why a message can pass SPF here and still fail DMARC on alignment.

I send through Microsoft 365 and still get 5.7.23, why?

A common cause is the High Risk Delivery Pool. If Microsoft flags one of your outbound messages as spam, it sends it through a separate pool of IPs that are not in your SPF, so the destination's SPF check fails. Turn on outbound spam notifications to catch it, and contact support if it is a false positive.

Should I use -all or ~all in my SPF record?

Use ~all (softfail) until you are certain every legitimate sender is in your SPF record. Tighten to -all (hardfail) only after that, or you risk turning a missing include into a hard rejection. The symbol is a tilde, not a hyphen.