Email Bounced With 550 5.7.23? What It Means for Your Business

The fix for 550 5.7.23 is your SPF record. The server you sent to checked whether your mail server is allowed to send for your domain, the answer was no, and it refused the message. Correct the SPF record so it lists every service that sends as you, keep it to one record under 10 DNS lookups, and resend. Most businesses can do that in under an hour.

What does 550 5.7.23 mean?

The 550 5.7.23 code means the receiving mail system rejected your message because of a Sender Policy Framework (SPF) violation. Microsoft's NDR reference for 5.7.23 gives the full text as "The message was rejected because of Sender Policy Framework violation" and says the bounce "most likely indicates a Sender policy framework (SPF) configuration issue." The 550 at the front marks it as permanent. The message will not retry.

You usually get this bounce from Microsoft 365 after it tried to hand your message to an outside server. According to the same Microsoft page, the "Diagnostic information for administrators" section of the bounce holds the original error from that outside server, so read it first. It often names the IP address that failed.

What does a 550 5.7.23 bounce mean for my business?

A 550 5.7.23 bounce means a customer never got your quote, invoice or reply, and you may not notice. You think the estimate went out. The customer thinks you never followed up. And it rarely stops at one message: every email from the same system fails the same way until the record is fixed.

Why is my domain failing SPF?

Your domain fails SPF when the server that sent the message is not listed in your SPF record, or when the record itself is broken. Four causes cover most cases:

• A sender is missing. Your invoicing app, CRM, website form or copier sends as your domain, but its include or IP address is not in the record.
• Two SPF records. Only one SPF record is allowed per domain. A second one, often left behind by an old provider, breaks both.
• Too many lookups. The SPF standard, RFC 7208, says SPF checks "MUST limit the total number of those terms to 10." Each include counts, and includes inside includes count too. Go over 10 and the check errors out.
• An on-site server. Microsoft's fix list says to add "your on-premises IPs, if any, to the SPF record of any domains you send for."

How do I fix 550 5.7.23 step by step?

You fix 550 5.7.23 by making your one SPF record match the real list of services that send as your domain. Microsoft's steps, in plain order:

1. Look up your current record. Use a public SPF checker, as Microsoft recommends, or run your domain through the free email security check.
2. List every sender. Mailbox (Microsoft 365 or Google Workspace), invoicing, CRM, website form, newsletter, scanner. Each one needs to be covered.
3. Merge into one record. For Microsoft 365 the include is include:spf.protection.outlook.com. Add each other service's documented include, then end with ~all or -all.
4. Count lookups. If the checker reports more than 10, drop includes for tools you no longer use, or move a bulk sender to a subdomain.
5. Add every domain to Microsoft 365. Microsoft's page says to "provision all of the domains you own," because it limits mail from domains a tenant has not added.
6. Check for spam routing. Microsoft notes that outbound mail flagged as spam goes through its High Risk Delivery Pool, and "Messages in the High Risk Delivery Pool won't pass SPF checks." If one user's mail keeps failing, check whether that account was flagged or compromised.
7. Resend and confirm. After DNS updates, send a test to the same recipient and check the headers for spf=pass.

To confirm the cause before you change anything, paste the whole bounce into the free reader on the 550 5.7.23 page at postmortem.report. It runs in your browser and names the error.

Is SPF alone enough to stop the bounces?

No. SPF alone fixes this bounce, but it is not enough to keep your mail flowing. SPF breaks when mail is forwarded, and big inbox providers now check DKIM and DMARC too. The gap is common locally: a Parallax Intelligence check found 79.2% of 847 businesses that email from their own domain (1,527 checked) have no DMARC enforcement in Southwest Michigan. Got a different code in your bounce? The email rejection error codes guide lists every code with its own fix page.

When should you get help with an SPF bounce?

You should get help when the record is already near 10 lookups, or when you cannot tell which service is sending the failed mail. Both take some digging through headers and DMARC reports. If you run a business in Battle Creek, Kalamazoo or anywhere in Southwest Michigan and want it handled, the Parallax DMARC audit service finds every sender, rebuilds SPF, sets up DKIM and DMARC, and rolls protection out so nothing breaks. Call (269) 460-1772 or use the contact form and tell us what the bounce says.