Mail that sends without errors but never reaches the inbox is almost always a configuration problem. Work through these in order and stop when you find the cause.
1. Read the headers of a message that failed
This is the fastest diagnosis available and most people skip it. Send a message to an account you control at a large provider, open it, and view the original or raw source.
Look for the Authentication-Results header:
spf=pass ... dkim=pass ... dmarc=pass
Any fail or none there tells you exactly which record to fix, and you can stop reading this article at the relevant section below.
2. SPF
spf=fail or none means the receiving server could not confirm your server is allowed to send for your domain.
$ dig example.com TXT +shortYou need exactly one record starting v=spf1. Two SPF records is a common cause and it invalidates both. If you send from your own server only, v=spf1 mx -all is enough.
3. DKIM
dkim=fail or none means your messages are unsigned, or the public key in DNS does not match what the server signs with.
Your mail platform generates the key and shows you the record to publish. The selector is part of the record name, for example default._domainkey.example.com. Publish exactly what the platform gives you, including the long key value, unbroken.
$ dig default._domainkey.example.com TXT +shortIf that returns nothing, the record was never published or the selector name is wrong.
4. Reverse DNS
Check that your IP resolves to a hostname and that hostname resolves back:
$ dig -x 203.0.113.10 +short $ dig mail.example.com A +short
The pair must agree. Generic provider hostnames or an empty result are both treated as spam signals. On a D4 VPS you can fix this yourself; see our reverse DNS guide.
Do the same for your IPv6 address if the server sends over IPv6.
5. Blocklists
Check your IP against the public blocklists. Several free web checkers query dozens of lists at once, including one hosted by poste.io.
If you are listed, read why. Most lists publish the reason and a delisting form. Common causes: the IP was used for spam by a previous holder, your server was briefly an open relay, or a compromised account sent a burst of mail.
Fix the cause before requesting delisting, or you will be relisted within days.
6. Content and volume
If authentication passes and you are not listed, the problem is behaviour rather than configuration:
- Sudden volume from a new IP looks like a spam run. Ramp up over weeks.
- Mail nobody asked for generates complaints, and complaints outweigh everything else.
- Messages that are one large image with a link score badly. So do link shorteners and mismatched display names.
- A missing or broken unsubscribe link on bulk mail is a strong negative signal.
7. Set up DMARC reporting
Add a DMARC record with a reporting address and you stop guessing:
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
Within a day or two you receive XML reports from the large providers showing how many of your messages passed and failed, and from which IPs. That turns guesswork into a list of things to fix.
One provider rejecting you is not the same as a broken server
If mail lands fine at three providers and goes to spam at a fourth, your configuration is probably right and that provider simply does not trust your IP yet. Keep sending real mail at a steady rate. If every provider junks you, it is configuration, and it is in sections 2 to 5.
Quick reference
| Symptom | Check |
|---|---|
spf=fail | One v=spf1 record only |
dkim=none | DKIM record published, selector correct |
dmarc=fail | SPF or DKIM must pass and align |
| Rejected on connect | Blocklist, or missing reverse DNS |
| Spam at one provider only | Reputation; keep sending steadily |
| No idea | Add DMARC reporting and read the reports |
Where to go next
Fix the failing check, then send a fresh test and read the headers again. If everything passes and mail still goes to spam, the remaining variable is reputation, which only volume discipline and time improve.