Why your cPanel emails go to spam, and the four checks that fix it

Someone sends an invoice from the company address, the customer never sees it, and two weeks later there is an awkward phone call. This is one of the most common problems I get asked about, and it is almost never mysterious. Mail from a self-hosted or cPanel server ends up in spam for one of four reasons, and you can check all four in about ten minutes.

The important thing to understand first: receiving mail servers are not judging the content of your message nearly as much as you think. They are asking a much simpler question: can this sender prove it is allowed to send as this domain? If the answer is unclear, the message goes to junk regardless of how professionally it is written.

Check 1: SPF, is the server allowed to send for the domain?

SPF is a DNS TXT record listing which servers may send mail using your domain. If it is missing, receivers have nothing to verify against. If it is wrong, verification actively fails, which is worse than absent.

dig +short TXT example.com | grep spf1

You want exactly one record starting v=spf1. Two SPF records is a permanent error: receivers treat the domain as having no valid policy at all, and this happens constantly when someone adds Google Workspace without removing the hosting provider's original record.

A workable record for a cPanel server that also sends through Google Workspace looks like this:

v=spf1 +a +mx include:_spf.google.com ~all

Two details that catch people out:

• The ten-lookup limit. Every include, a, mx and redirect costs a DNS lookup, and SPF permits ten in total. Stack up Google, a CRM, a newsletter tool and a helpdesk and you will silently exceed it. Once you do, the whole record returns permerror and stops working, including for the senders that used to pass.
• Use ~all (softfail) rather than -all (hardfail) until DMARC reporting has confirmed every legitimate sender is covered. Hardfail on an incomplete record is how internal mail disappears.

Check 2: DKIM, is the message cryptographically signed?

DKIM adds a signature to outgoing mail that the receiver verifies against a public key published in your DNS. This matters more than SPF for a reason people often miss: SPF breaks on forwarding. When a recipient auto-forwards your message, the forwarding server becomes the sender, SPF fails, and without DKIM the message has no surviving authentication at all.

In WHM, DKIM lives under Email Deliverability. cPanel will generate the key and show you the record to publish. Verify it resolved:

dig +short TXT default._domainkey.example.com

Note the selector. CPanel usually uses default, Google Workspace uses google, and third-party senders each use their own. Multiple selectors coexisting is fine and expected. That is the design.

Check 3: reverse DNS, does the IP identify itself honestly?

Reverse DNS maps your server's IP address back to a hostname. Major providers check that this exists and that it matches the hostname the server announces in its HELO. If it is missing, or still set to the generic hostname your VPS provider assigned, that is a meaningful negative signal.

# What does the IP claim to be?
dig +short -x 203.0.113.10

# It should resolve back to the same address
dig +short mail.example.com

Those two must agree. This is called forward-confirmed reverse DNS. Reverse DNS is set by whoever controls the IP, meaning your hosting provider, not you. It is a support ticket, not a DNS record you can add yourself.

Check 4: is the IP on a blocklist?

If the first three are correct and mail is still being rejected, check the IP's reputation. On shared hosting this is frequently not your fault, another account on the same IP was compromised and sent spam, and the whole address got listed.

Check against the major lists (Spamhaus, Barracuda, SpamCop). If you are listed, the delisting request is usually straightforward, but it will only stick if the underlying cause is fixed. Delisting a server that is still sending spam through a compromised script is a wasted afternoon, so before requesting removal, check the mail queue for messages you did not send.

# How large is the queue, and who is sending?
exim -bpc
exim -bp | head -50

# Messages per script, the fastest way to spot a compromised file
grep "cwd=" /var/log/exim_mainlog | awk -F"cwd=" '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -rn | head

That last command is the one I run first on any server with a deliverability problem. If a single directory is responsible for thousands of messages, you do not have a DNS problem. You have a compromised site, and that is a different job.

Then add DMARC, but start at p=none

DMARC ties SPF and DKIM together and tells receivers what to do when both fail. Just as usefully, it makes them send you reports about mail claiming to be from your domain.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1

p=none changes nothing about delivery. It only turns on reporting. Leave it there for a few weeks and read what arrives, almost every organisation discovers at least one legitimate sender nobody remembered, typically a CRM or an old contact form. Fix those, then move to p=quarantine, and only then to p=reject.

The order that matters

If you only have an hour, do these in this sequence. Each one builds on the last:

1. Confirm there is exactly one SPF record and it covers every legitimate sender.
2. Enable DKIM signing and verify the record resolves from outside the server.
3. Ask your host to set reverse DNS to match the server's mail hostname.
4. Check blocklists, and if listed, find the cause before requesting delisting.
5. Publish DMARC at p=none, read reports for a few weeks, then tighten.

One broader recommendation. If email genuinely matters to the business, consider not hosting it on the same server as the website at all. Separating them means a site compromise cannot take your mail down or poison your sending reputation, and dedicated mailbox providers handle filtering and storage better than a self-hosted setup realistically will. I cover the trade-offs on the email and DNS configuration page.

Written by Irfan Bhat, web developer & server engineer, currently technical support & development at ElySpace. More about me, or get in touch if this raised a question.