What the receiver is telling you

The receiver checked your envelope-from domain's SPF record against the connecting IP and got a hard fail (-all) or a policy that enforces SPF alone. Either the IP is not in the record — a new sending service that was never added, a tool switched to a new IP pool, a relay that does not appear in include: — or the record is broken: over ten lookups, two records on the same name, a syntax error. On a domain with -all, any of these turns every message from the unlisted source into a bounce.

Why a policy block must not be treated as a bad address

Sending tools file every 5xx under "bounced", and the natural reflex is to scrub the address. For a policy block that is exactly wrong. The recipient exists and would have received the mail; the receiver refused it because of your domain, IP, authentication or content. Scrubbing throws away a lead and leaves the cause in place, so the next send produces the same block against the next thousand addresses. The right response is to stop sending from the affected domain, find what the receiver named, fix it, and resume at low volume.

What to do

1. Run the SPF checker on the envelope-from domain. Look for the connecting IP in the expanded record.
2. If the tool or provider is missing, add its include: mechanism. If that pushes you over ten lookups, flatten or remove stale includes.
3. Two SPF records on one name is a permerror and fails everything — merge them.
4. Until fixed, mail from that source will fail at every receiver that enforces SPF.

don't Do not switch to +all or ?all to stop the bounces. That authorises the world to send as you and DMARC will still fail.

Decode the whole bounce

Paste the complete failure notice — every code and the receiver's wording — and get each part explained together.

Common questions