What the receiver is telling you
Since February 2024 Gmail refuses mail that passes neither SPF nor DKIM, and for senders over about 5,000 messages a day it requires both plus DMARC. This code is that rule. The message arrived with no valid DKIM signature and an SPF result that was not pass for the envelope domain. The bounce text usually names which checks were run and what they returned, which is the fastest diagnostic you will get from Google.
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
- Read the Authentication results line in the bounce. It says which of SPF and DKIM failed and for which domain.
- DKIM did not pass: the sending tool is not signing, or the selector's public key is not in DNS, or the key was rotated. Check with the DKIM checker.
- SPF did not pass: the sending IP is not in the envelope domain's SPF record. Check with the SPF checker.
- Bulk senders: publish a DMARC record (p=none is enough to satisfy the requirement) and make sure one of SPF or DKIM aligns with the From domain.
don't Do not treat this as a Gmail-only quirk. Yahoo enforces the same rules, and Microsoft began enforcing them in 2025.
Decode the whole bounce
Paste the complete failure notice — every code and the receiver's wording — and get each part explained together.
Common questions
Do I need both SPF and DKIM to pass?
For under 5,000 messages a day to Gmail, one of them. Over that, both, plus DMARC and alignment. In practice set up all three regardless.
It says DKIM did not pass but I have a DKIM record — why?
The tool is signing with a different selector or domain than the one you published, or the key was rotated. The DKIM checker finds the keys that are actually there; compare against the s= in your headers.
Often seen alongside
Related reading
If this is the thing going wrong
The pages explain it. If you would rather it was simply fixed, that is the work I do.