"550 5.7.23 The message was rejected because of Sender Policy Framework violation" (SPF fail): how to fix it

What it means

The receiving server checked your domain's SPF record and found that the server which sent the email is not allowed to send for your domain. With Microsoft 365 and Exchange, the bounce looks like this:

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

Other servers use shorter wordings. The message usually looks like one of these:

550 5.7.1 SPF fail - not authorized
550 5.7.1 Rejected by SPF

SPF (Sender Policy Framework) is a TXT record in your domain's DNS that lists the servers allowed to send email for it. When a server that is not on the list sends, SPF "fails". If the record ends with -all ("reject anything else"), many receivers refuse the email straight away.

Why it happens

• A sender is missing from SPF. You started using a newsletter tool, a CRM, an online shop, a billing tool or a new email provider and did not add it.
• Your server's IP changed (new hosting, new VPS) and SPF still lists the old one.
• Two SPF records exist for the domain. That is invalid, and SPF fails for every sender.
• Too many lookups. SPF allows only 10 DNS lookups (each include:, a, mx counts). Above that, SPF gives an error that some receivers treat as a fail.
• Forwarding. The email was sent to an address that forwards to Microsoft 365 or another mailbox. The forwarding server is not in your SPF, so the check fails there.
• Someone else is spoofing your domain. In that case, the rejection is SPF doing its job.

How to check

1. Run a Delivmail test. From the same app or server that bounced, send an email to the unique address on the home page (/). The report shows the sending IP, the domain checked by SPF (the envelope sender, or Return-Path) and the SPF result with the reason.
2. Scan your domain. Use /domain-scanner to read your SPF record. It shows if there are two records, a syntax error or too many lookups.
3. Read the bounce headers. The bounce often contains a line such as Received-SPF: Fail with the IP that was checked.

How to fix it

1. Identify the sending service. The Delivmail report shows the IP. The service's documentation gives its SPF include, for example include:spf.protection.outlook.com for Microsoft 365 or include:_spf.google.com for Google Workspace.
2. Add it to your single SPF record. Edit the existing record, do not create a second one:

   v=spf1 include:spf.protection.outlook.com include:spf.newsletter-example.com ip4:203.0.113.10 -all

3. Merge duplicates. If you have two v=spf1 records, combine them into one.
4. Stay under 10 lookups. Remove services you no longer use. Replace a and mx with ip4: when you know the IP.
5. Consider ~all while you test. It marks unknown senders as suspicious instead of rejecting them. Go back to -all once everything passes.
6. Set up DKIM too. DKIM signs the email and survives forwarding. With DKIM and DMARC in place, receivers rely less on SPF alone.

If forwarding is the cause

Ask the person to forward differently (a mailbox rule that redirects with SRS, or collecting the mail directly), or make sure your emails are DKIM-signed so DMARC can still pass.

Check that it is fixed

Wait for the DNS change to spread (often minutes, up to the record's TTL, sometimes a few hours). Run the Domain scanner to confirm there is one valid SPF record, then send a new Delivmail test from the same service: SPF should show pass. Finally, resend the email to the address that bounced.