Mail Goes to Spam Even With SPF and DKIM

When SPF and DKIM both pass, many administrators expect email to land in the inbox. In practice, that is only part of the picture. Authentication helps prove that a message is allowed to be sent, but inbox placement also depends on reputation, alignment, sending behavior, domain history, and what the receiving server sees when it connects to your mail host.

What SPF and DKIM actually prove

SPF tells the receiver that the sending IP is allowed to send mail for the domain. DKIM proves that parts of the message were signed and were not altered in transit. Those checks matter, but neither one says that your domain has a good reputation, that your sending server is configured cleanly, or that the message itself looks trustworthy.

That is why mail can still go to spam even when both checks pass.

Check DMARC alignment, not just SPF and DKIM

Many setups pass SPF or DKIM in a technical sense but still fail DMARC alignment. For example, the message may be signed by one domain while the visible From header uses another. A receiver can see that as weaker identity, even if authentication passed somewhere in the chain.

If you have not checked DMARC yet, do that next. A missing DMARC policy does not always cause spam placement on its own, but it removes an important trust signal and makes troubleshooting harder.

Use the Email Validator page to validate SPF, DKIM, DMARC, and MX in one place.

Reverse DNS still matters

A surprising number of mail delivery problems come from reverse DNS. If your mail server IP has no PTR record, or the PTR points to a generic hostname that does not match the server identity, some providers will score that negatively.

Reverse DNS is especially important when you send mail from a VPS or dedicated server. Even if your domain authentication is correct, poor server identity can still push your mail into spam or trigger temporary blocks.

Check the sending IP with the Reverse DNS Lookup tool. If there is no PTR record, fix that before you keep tuning message content.

Make sure the IP is not blacklisted

You can have a clean domain and still inherit a bad IP reputation. This happens often on recycled VPS addresses or shared infrastructure. One listing on a minor blacklist may not matter much, but multiple relevant listings can absolutely affect delivery.

Run the sending IP through the IP Blacklist Checker. If you find listings, do not rush straight to delisting. First confirm that the server is not compromised, that reverse DNS exists, and that SPF, DKIM, and DMARC are correct. Delisting requests tend to fail when the root cause is still present.

Look at sending behavior, not only DNS

Receivers also score how you send. A technically valid domain can still look suspicious if:

volume suddenly spikes
a new domain starts sending immediately at high volume
many recipients never engage
bounce rates are high
complaint rates are high
the server repeatedly retries to invalid addresses

If you recently launched a new domain or moved infrastructure, warm up gradually. Consistent, low-complaint sending beats aggressive volume every time.

Content still plays a role

Content alone usually does not explain everything, but it can make a weak setup worse. Common issues include:

overly aggressive subject lines
too many links
mismatched visible links and destination URLs
poor text-to-image balance
missing plain-text version
recycled templates used in spam campaigns

Do not treat this as the first place to debug. Fix server identity and authentication first, then evaluate message construction.

A practical troubleshooting flow

If mail is landing in spam even though SPF and DKIM pass, work in this order:

Verify MX, SPF, DKIM, and DMARC.
Check whether SPF and DKIM align with the visible From domain.
Confirm reverse DNS on the sending IP.
Check blacklist status for the sending IP.
Review sending volume, bounce rate, and complaint patterns.
Inspect the message content and link profile.

This order matters because it keeps you from wasting time rewriting email copy when the actual issue is a missing PTR record or a dirty sending IP.

Real-world example

A small business sends transactional mail from a new VPS. SPF passes, DKIM passes, and test messages look fine. Yet Gmail keeps placing messages in spam. The missing piece is that the server has no PTR record and the IP was previously used by another sender. After adding reverse DNS, cleaning up the hostname, and confirming blacklist status, placement improves over time.

That pattern is common. Passing SPF and DKIM does not override every other negative signal.

What to do next

If you are troubleshooting a live mail setup, start with these tools in order:

That gives you the fastest path to separating domain-level issues from IP reputation and server identity problems.