Quick answer
An Outlook 5.7.5 bounce is an SPF authorization failure. Microsoft looked up the SPF record of your envelope sender domain, did not find the connecting IP in the authorized list, and refused the message because the domain publishes a hardfail policy. The usual fix is to add the real outbound sending platform to your SPF record, or to repair a record that has crossed the 10-lookup limit and now returns permerror. Confirm the published record and check that every platform you actually send from appears in the resolved mechanism list.
What the 5.7.5 code means
The 5.7.x enhanced status code family signals a security or policy rejection rather than a routing or mailbox error, and 5.7.5 names an SPF failure directly. When Microsoft refuses a message it returns a Non-Delivery Report, also called an NDR or bounce, and the enhanced status code inside that report names the subsystem that refused the message. A 5.7.5 code tells you the failure is in SPF, which the sender controls directly through DNS. You can fix it yourself, as you can 5.7.135. That sets it apart from the reputation-driven 5.7.500 and 5.7.501 codes and the recipient-policy 5.7.1 code, which the Outlook pillar describes.
Keep the full NDR text rather than a paraphrase. The human-readable diagnostic line that sits alongside the 5.7.5 code often names the failing domain or carries a remediation URL, and that line tells you which sending identity Microsoft evaluated.
Why Outlook returns 5.7.5
SPF is a DNS TXT record that authorizes which servers can send mail using the domain's envelope sender identity, defined in RFC 7208. Exchange Online Protection, the filter in front of every Microsoft 365 mailbox, looks up the SPF record of the envelope sender domain and checks whether the connecting IP is on the authorized list. When the IP is absent and the domain publishes a hardfail policy with -all, the result is a strong negative signal that often produces an outright rejection rather than spam-folder placement.
A 5.7.5 usually comes from one of three things. The most common is an SPF record that omits the real outbound platform, which happens after a migration to a new sending service that was never added to the record. The next is an SPF record that has crossed the 10-DNS-lookup limit defined in RFC 7208 section 4.6.4 and now returns permerror, which most receivers treat as a non-pass. The last is two separate v=spf1 records published on the same name, which invalidates both and also returns permerror.
A point that catches many senders is that SPF authenticates the envelope sender domain, also called the return-path or MailFrom domain, not the visible From domain. When you send through an email platform, the envelope sender is often a domain the platform controls. SPF can pass for that platform domain while still failing to help your visible From domain, which is an alignment problem covered by Outlook 5.7.135.
How to diagnose a 5.7.5
Start with the record itself. Resolve the SPF TXT record at your envelope sender domain and read it. Confirm there is exactly one record beginning with v=spf1, and confirm that the platform sending the bounced mail appears either as a direct ip4: or ip6: entry or inside an include: mechanism. The Relaymetry SPF checker resolves the record, expands every include: recursively, and reports the total lookup count so you can see whether the record exceeds the 10-lookup budget.
Then read a real header if you have one. The Authentication-Results header on a delivered or bounced message records spf=fail, spf=permerror, or spf=pass, along with the envelope domain SPF was evaluated against. A permerror result points at the lookup-limit or duplicate-record cause. A fail result points at a missing sending platform. The two have different fixes, so working out which one occurred saves a wasted edit.
What to change
The fix depends on which cause the diagnosis found. A missing platform is fixed by adding the platform's published include: mechanism to your single SPF record. A permerror from too many lookups is fixed by reducing the lookup count, usually by removing platforms you no longer use and replacing stable-IP senders with direct ip4: entries that cost zero lookups. A duplicate record is fixed by merging every legitimate mechanism into one v=spf1 record and deleting the rest. After any change, allow the record's TTL to expire before retesting, because receivers may serve the old record from cache until then.