How can SPF/DKIM misconfigurations cause indirect bounces?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
Your emails are bouncing, the recipient address is valid, your content looks fine, and yet the rejections keep coming. That's the signature of an authentication misconfiguration. The problem isn't the destination. It's your own setup.
Here's what's actually happening. When a receiving mail server gets your message, it runs three checks: SPF, DKIM, and DMARC. If SPF or DKIM fail, and your DMARC policy is set to reject or quarantine, the server doesn't just let the message through and flag it. It bounces it back. The address exists. Your content would have been fine. Your configuration killed the delivery.
That's why these are called indirect bounces. The fix isn't on the recipient's end at all. It's yours.
SPF failures happen when the IP address you're sending from isn't listed in your SPF record. This is common when you add a new ESP, switch servers, or start using a third-party tool that sends on your behalf. The new sending IP isn't in your record yet, SPF fails, and if DMARC is enforced, you get a rejection.
DKIM failures are a bit different. They happen when the public key in your DNS doesn't match the private key used to sign the message, or when the key isn't published at all. Signature verification fails, DMARC alignment breaks, and the receiver's policy takes over.
The bounce codes you'll see in both cases tend to be 550 5.7.x variants, often with language like "Authentication failed", "DMARC policy violation", or explicit mentions of SPF, DKIM, or DMARC in the rejection message. If you're reading bounce logs and seeing those strings, authentication is your first stop, not reputation.
To diagnose it, start with these steps:
- Check your SPF record and confirm every IP or sending service you use is covered. Don't forget ESPs, CRMs, and any transactional tools that send from your domain.
- Verify your DKIM public key is published correctly in DNS. A mismatch between what's in DNS and what your mail server is signing with will fail every time.
- Check what your DMARC policy is actually set to. If it's
rejectand you've got auth failures, you're bouncing real mail. Drop tononetemporarily to stop the bleeding, fix the config, then work back up. - Read the full SMTP transcript from a bounced message. The rejection reason is usually right there.
Now you can check your SPF record in seconds with our free SPF checker, or run your DKIM signature through our DKIM record lookup. If something looks off and you're not sure what to fix, the SOS hotline is free. No pitch, just help.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.