Shared cPanel hosting concentrates thousands of senders on the same IP pools. One bad actor affects everyone. Here's the mechanics of why it happens and how to fix it.
If you've ever moved a client's email to a cPanel shared hosting account and watched their deliverability tank, you've experienced this problem. The mail technically sends. SPF might even pass. But the mail ends up in spam, or bounces with a 550 error and a reference to a blacklist you've never heard of.
The reason is structural, not configuration. Understanding why shared cPanel hosts are problematic for email delivery helps you explain it to clients and make better decisions about where to host.
Most cPanel shared hosting puts hundreds or thousands of domains on the same mail server IP addresses. Every one of those domains can send email. Some of them are spammy. Some are owned by people who got phished and had their accounts compromised. Some are abandoned domains that still receive and relay mail.
The mail receiving infrastructure at Gmail, Outlook, and others doesn't evaluate individual domain reputation in isolation — it evaluates the sending IP's reputation. If one of the thousand domains on your shared IP has been sending spam, every other domain on that IP pays for it.
Blacklists operate on the same principle. Spamhaus, Barracuda, SORBS — they list IP addresses. If your shared hosting IP gets listed because another customer's account was used to send a phishing campaign, your mail bounces until the host gets delisted. And getting delisted takes time, requires action from the hosting provider, and may happen again next week when the same IP gets abused again.
This isn't a hypothetical. It's the routine reality of shared hosting email.
Every IP address that sends mail should have a PTR (reverse DNS) record that resolves back to a hostname matching the sending domain. This is sometimes called RDNS, and it's one of the oldest and most consistently enforced checks in email delivery.
On shared cPanel hosts, the PTR record for the mail server IP belongs to the host, not to your domain. It typically resolves to something like server123.hostingcompany.com. Receiving mail servers check this, notice that the PTR hostname doesn't match the sending domain, and either reject the mail outright or apply a spam score.
You cannot fix this yourself. The PTR record is controlled by whoever owns the IP, which is the hosting company. Some hosts will set a PTR on request. Many won't because the infrastructure doesn't support per-customer PTR records on shared IPs.
cPanel adds every shared server to a default SPF record, or encourages customers to use their host's SPF include. The result is an SPF record that authorises a large range of IPs — the same IPs used by every other customer on the server.
This defeats one of SPF's purposes, which is to limit which servers can legitimately send mail from your domain. If your SPF record authorises include:hostingcompany.com and that resolves to hundreds of IP addresses, you've effectively authorised anyone on that shared infrastructure to send mail as you.
More practically: having a permissive SPF record doesn't cause your mail to fail SPF, but it does mean SPF provides no meaningful protection against spoofing. Receiving mail servers know this, and factor in SPF scope when calculating spam probability.
cPanel doesn't configure DMARC for you. The default state for a domain hosted on shared cPanel is no DMARC record, or a p=none record with no reporting address. Neither provides any enforcement.
Without DMARC at p=quarantine or p=reject, your domain can be freely spoofed. Anyone can send mail from you@yourdomain.com using any server, and as long as there's no DMARC policy to enforce, many receiving systems will deliver it.
This is the combination that causes deliverability problems at scale: shared IPs with poor reputation, PTR records that don't match, permissive SPF, no DMARC enforcement. Each of these alone is a yellow flag. Together, they explain why email from shared cPanel hosts consistently underperforms.
If you're on shared cPanel hosting and can't move immediately, there are partial fixes:
Use a dedicated transactional email service for important mail. Mailgun, Postmark, and Brevo all offer dedicated IP sending with proper PTR configuration. Route your critical mail through them with correct SPF and DKIM, and move your cPanel account's mail settings so it uses them as the smarthost.
Tighten your SPF record. Replace the broad include for your host with the specific services you actually use. A typical record might be: v=spf1 include:spf.mailgun.org include:_spf.google.com -all. The -all at the end rejects everything not on the list.
Add DKIM via your transactional provider. cPanel can generate DKIM keys but the signing is tied to the mail server that's sending. If you route through an ESP, configure their DKIM and align it to your sending domain.
Set a DMARC policy. Even starting at p=none with reporting addresses configured gives you visibility into what's happening. Move toward p=quarantine once you've confirmed all legitimate senders pass.
The root problem — shared IP reputation — can't be fully fixed without moving to dedicated sending infrastructure. For clients where email deliverability actually matters (e-commerce, professional services, anyone whose revenue depends on email), that's the right recommendation.
FXRM runs Zimbra email hosting on dedicated infrastructure with properly configured PTR records, DKIM signing, and DMARC enforcement on every domain. If your client's email is being blacklisted, talk to us about moving it.
Founded by Jon Morby, whose team has been running UK servers since 1992. Hosting built by engineers who care about deliverability and uptime.
Get in touch →Three records. Three different jobs. Most guides treat them as a checklist. This one explains what actually happens when each one fails — and why all three must work together.
Most email deliverability problems aren't content problems. They're infrastructure problems — a PTR mismatch, a DMARC policy set to none, a shared IP on a blacklist. Here's what's actually going wrong and what to do about it.
The team behind FXRM has been running email infrastructure since the early 1990s — from MMDF and Sendmail to Postfix and Zimbra. Here's what actually matters for getting mail delivered.