550 5.7.1 Message Rejected Due to SPF: Causes and the Fix

A bounce that says 550 5.7.1 and mentions SPF means the receiving server looked up your domain's SPF record, checked the IP address that delivered the message against it, and found no match it was willing to accept. Gmail words the same failure as 550 5.7.26 and talks about authentication. The message is never queued or retried; it is refused at the door. The fix is almost always one of five things, and the bounce itself tells you which.

Quick answer

Open the bounce and find the IP address or hostname the receiver names. Then run your domain through the free SPF checker. If the record is missing, duplicated or over ten lookups, fix the record. If the record is fine, the IP in the bounce belongs to a service that is sending as your domain without being listed: a website form, a CRM, a newsletter tool, or a mail app sending through a different provider. List it or stop sending from it.

Read the bounce first

The receiver's rejection line names the sending IP and usually the check that failed. Three common shapes:

• 550 5.7.1 Message rejected due to SPF policy, or ... SPF check failed. A generic receiver: the delivering IP is not in your SPF record, or the record is broken.
• 550-5.7.26 This mail is unauthenticated... Gmail requires all senders to authenticate with either SPF or DKIM. Gmail: neither SPF nor DKIM passed for the domain in the From address.
• 550 5.7.1 ... SPF PermError or ... Too many DNS lookups. The record itself is invalid, so every message fails regardless of which server sent it.

The five causes

1. No SPF record. Many receivers now refuse mail from domains with no SPF and no DKIM. Publish one TXT records (short text lines in DNS used for email security) at the root of the domain; OquMail users use v=spf1 MX (Mail Exchanger — where incoming email is delivered) a:mail.oqumail.com ~all, as shown in the dashboard.
2. Two SPF records. A registrar wizard added one and you added another. Receivers return PermError and most score it as a fail. Merge them into a single record; see more than one SPF record found.
3. More than ten DNS lookups. Each include, a, MX (Mail Exchanger — where incoming email is delivered) and redirect costs one, including nested ones. The checker counts them; the fix is in too many DNS lookups.
4. A sender that is not listed. The IP in the bounce belongs to your website host, a CRM, an invoicing tool or a newsletter service that sends as your domain. Add that service with the include it documents, or send that mail from the service's own domain instead.
5. A mail app sending through someone else. Gmail's "Send mail as" and similar features deliver through Google's servers, which are not in your record. Add the mailbox to the app as a real IMAP/SMTP account using mail.oqumail.com on port 587 so mail leaves through the server your SPF lists.

Fix it in the right place

If the failing message came from your OquMail mailbox, the record in your dashboard already lists the sending server, so the problem is a broken record: fix causes 1 to 3. If it came from another service, the record is probably fine and the fix is cause 4 or 5. Do not react to a bounce by adding ip4 entries for every address you see; each guess is another lookup or another hole, and a record that lists the whole internet protects nothing.

Confirm the fix

1. Re-run the SPF checker. It should show one record, within the lookup limit, ending in ~all or -all.
2. Wait for the old record to expire from caches, usually under an hour.
3. Send a message from the mailbox or service that bounced to a Gmail address you control.
4. In Gmail open the message, choose Show original, and read the Authentication-Results line. You want SPF (Sender Policy Framework — a list of servers allowed to send email as your domain)=pass with your domain; our guide to reading authentication results explains the rest of that line.
5. If SPF (Sender Policy Framework — a list of servers allowed to send email as your domain) still fails, the IP shown next to the result is the one to look up: it tells you which service sent the message.

Common questions

SPF passes in Gmail but the other receiver still bounces. Why?

Some receivers reject on SPF alone while Gmail accepts a DKIM pass instead. Make sure the sending service signs with DKIM for your domain as well; with both in place, a DMARC-aware receiver will accept the message on either.

Will ~all instead of -all stop the bounces?

Sometimes, but it hides the real problem. A softfail is still a fail for DMARC alignment, and receivers increasingly treat it the same way. Fix the cause, then keep whichever all you prefer.

Does the bounce mean my domain is blacklisted?

No. An SPF rejection is about which server sent the message, not about reputation. A blocklist rejection names the list and the IP; see email blacklist check and removal for that case.

Want to see how your own domain is set up? Use the free SPF checker, DMARC checker and MX lookup: they run in your browser and store nothing.