Preventing Email Spam and Blacklisting on Your Hosting Account

Overview

Email spam issues and IP blacklisting are two of the most common problems we see on hosting accounts. If your emails are landing in junk folders, bouncing back with delivery errors, or simply disappearing, a blacklisted IP or missing email authentication is usually the cause.

This happens on all hosting types — shared, VPS, and dedicated. On Shared Hosting, your outgoing mail shares an IP with other accounts on the same server, which means a neighbour’s compromised site can drag your sender reputation down too. On a VPS or dedicated server, you own the IP — so your reputation is entirely in your hands.

This article covers the full process: setting up proper email authentication, tightening your server’s mail configuration, monitoring your reputation, and recovering if you’ve already been blacklisted.

Prerequisites

• Access to your cPanel or WHM account (cPanel version 110+ recommended)
• Access to your domain’s DNS zone (via cPanel Zone Editor or your external DNS provider)
• Admin or reseller access if you’re managing multiple accounts in WHM
• A working outbound mail setup — confirm your mail server hostname resolves correctly before starting
• If you’re on a VPS or dedicated server, root SSH access is needed for some steps

Step-by-Step Instructions

Step 1: Set Up an SPF Record

SPF (Sender Policy Framework) tells receiving mail servers which IP addresses are allowed to send email on behalf of your domain. Without it, anyone can spoof your address — and spam filters will treat your mail with suspicion.

1. Log in to cPanel and go to Zone Editor under the Domains section.
2. Click Manage next to your domain.
3. Click + Add Record, set the type to TXT, and enter your SPF value. A basic record for cPanel’s mail server looks like this:

v=spf1 +a +mx +ip4:YOUR.SERVER.IP ~all

Replace YOUR.SERVER.IP with your actual server IP. If you send through a third-party service like Mailchimp or SendGrid, you’ll need to include their SPF mechanisms too — check their documentation for the exact include: tag to add.

📝 Note: The ~all (softfail) is a safer starting point than -all (hardfail) while you’re testing. Switch to -all once you’ve confirmed all your sending sources are covered.

⚠ Warning: Don’t create more than one SPF TXT record for the same domain. Multiple SPF records cause an SPF permerror and will break authentication entirely. Merge everything into a single record.

Step 2: Enable DKIM Signing

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing messages. Receiving servers verify the signature against a public key published in your DNS. It’s one of the strongest signals that your mail is legitimate.

1. In cPanel, go to Email > Email Deliverability.
2. Find your domain in the list. If DKIM shows a warning or is missing, click Repair.
3. cPanel will generate a 2048-bit DKIM key and install the DNS record automatically if your DNS is managed locally. If your DNS is external, copy the TXT record value shown and add it manually at your DNS provider.

📝 Note: The DKIM DNS record name will look like default._domainkey.yourdomain.com. Give it up to 24 hours to propagate before testing.

Step 3: Configure a DMARC Policy

DMARC builds on SPF and DKIM. It tells receiving servers what to do when a message fails both checks — reject it, quarantine it, or just report it. It also gives you visibility into who’s sending mail using your domain.

Add a TXT record to your DNS zone with the name _dmarc.yourdomain.com and a value like:

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

Start with p=none (monitor only). Once you’ve reviewed the reports and confirmed your legitimate mail is passing, move to p=quarantine and eventually p=reject.

📝 Note: The rua address receives aggregate reports (daily summaries). The ruf address receives forensic reports per failed message. Not all providers send forensic reports, so don’t rely solely on ruf data.

Step 4: Set a Reverse DNS (PTR) Record

This one is missed constantly, and it causes a surprising number of delivery failures. A PTR record maps your server’s IP address back to a hostname. Many mail servers will reject or heavily penalise mail from IPs without a matching PTR record.

If you’re on a Host & Tech VPS or dedicated server, you can set your PTR record through the client portal under your server’s IP management section. The PTR value should match the hostname in your mail server configuration — typically something like mail.yourdomain.com.

To verify it’s set correctly, run:

dig -x YOUR.SERVER.IP +short

The output should return your mail hostname. If it returns nothing or the wrong value, the PTR record isn’t propagated yet or wasn’t set correctly.

Step 5: Limit and Monitor Outgoing Mail

Compromised WordPress installs and contact forms are the most common source of spam on shared and VPS hosting. A single infected plugin can blast thousands of messages in an hour before you notice anything is wrong.

1. In WHM, go to Server Configuration > Tweak Settings and find the Mail tab. Set a per-domain hourly email limit — 200–500 is reasonable for most small sites.
2. Review outgoing mail logs regularly. On cPanel servers, they’re at /var/log/exim_mainlog. Filter by a specific domain like this:

grep "yourdomain.com" /var/log/exim_mainlog | tail -100

3. If you’re running WordPress, install a plugin like WP Mail SMTP and route mail through an authenticated SMTP relay (Mailgun, Postmark, etc.) instead of PHP’s mail() function. Direct mail() calls bypass most spam checks and are a liability.

⚠ Warning: If you see thousands of outbound messages from nobody@yourdomain.com or an unknown sender in your Exim logs, your server has likely been compromised or a script is being abused. Isolate the account immediately and scan for malware before doing anything else.

Step 6: Check and Submit Delisting Requests

If you’re already blacklisted, authentication fixes alone won’t resolve it — you need to actively request removal.

1. Check your IP at MXToolbox Blacklist Check and MultiRBL.
2. For each blacklist you appear on, visit their site and follow their delisting process. Spamhaus, Barracuda, and SORBS each have their own forms.
3. Before submitting a delisting request, make sure you’ve actually fixed the underlying issue. Submitting a request while the spam is still flowing will get you re-listed within hours and can result in a longer cooldown period.

Common Issues & Troubleshooting

Emails passing SPF but still going to spam

SPF alone isn’t enough. If DKIM isn’t set up or the signature isn’t validating, major providers like Gmail and Outlook will still treat your mail with low trust. Check the email headers of a test message — look for dkim=pass in the Authentication-Results header. If it shows dkim=fail or dkim=none, go back to Step 2. Also check that your From: domain matches the domain in your DKIM signature (the d= tag).

DKIM record not found after adding it

This is almost always a DNS propagation delay or a formatting error in the record value. Some DNS providers split long TXT records incorrectly. Verify the record using:

dig TXT default._domainkey.yourdomain.com +short

If you get no output or a malformed result, check that the record was saved as a single TXT string without extra line breaks. cPanel’s Email Deliverability tool will flag this under the repair prompt.

Hitting a Spamhaus PBL listing

The Spamhaus Policy Block List (PBL) lists IP ranges that shouldn’t be sending direct-to-MX email — typically residential ISPs and dynamic IP ranges. If your VPS IP is on the PBL, it usually means the IP was previously assigned to a dynamic range. You can request removal directly at the Spamhaus PBL removal page. The fix is quick, but you should also verify your PTR record is set (Step 4) before submitting.

Outgoing mail throttled or deferred by Gmail or Outlook

If you’re seeing 421 or 450 temporary deferral errors in your Exim logs when sending to Gmail or Microsoft domains, your IP reputation is low — not necessarily blacklisted, but not trusted yet either. This happens on new IPs that haven’t built up a sending history. The fix is gradual: send smaller volumes, ensure authentication is complete, and avoid sudden spikes. Microsoft’s Sender Support portal lets you submit a mitigation request if the deferral is persistent.

Contact form sending spam without your knowledge

Contact forms that don’t use CAPTCHA or rate limiting are trivially abused by bots. I’ve seen servers get blacklisted within a day of a new unprotected form going live. Add Google reCAPTCHA v3 or hCaptcha to all public forms, and consider adding a honeypot field. In WordPress, plugins like Gravity Forms and Fluent Forms have built-in spam protection — enable it. Check your Exim logs for a sudden spike from www-data or the web server user, which is the giveaway for form abuse.

FAQ