Your SPF, DKIM, and DMARC records are all green, but mail still isn't landing — it's bouncing with something like 550 5.7.1 Service unavailable, Client host blocked, or just disappearing into recipients' spam folders. That's not a DNS authentication problem. That's your server's IP address sitting on a blacklist. Here's how to confirm it, get it removed, and stop it coming back.
Symptom: what an IP blacklist actually looks like
A blacklisted (or "listed"/"RBL") IP shows up differently than a broken SPF record. Watch for:
- Bounce-backs mentioning
blocked,blacklist,reputation, or a specific list name like Spamhaus, SORBS, or Barracuda — e.g.550 5.7.1 Client host [x.x.x.x] blocked using zen.spamhaus.org - Mail to some domains goes through fine (Gmail, say) but consistently fails to others (Outlook, Yahoo, a corporate mail server)
- All outgoing mail from every mailbox on the server is affected — not just one account
- The problem started suddenly, often right after a spike in outbound mail volume you didn't send
If SPF, DKIM, and DMARC all pass (check with a tool like mail-tester.com) and you're still bouncing, the IP itself — not your DNS records — is the problem.
Cause: why your server's IP ends up on a blocklist
Blocklists exist to stop spam at the network level, and they don't care whose fault it is — only that mail from that IP looked abusive. The usual culprits:
A compromised email account or WordPress site
By far the most common cause. Someone guessed a weak email password, or a WordPress site got hacked and a contact-form plugin is being used to blast spam through wp_mail(). The server keeps sending, the recipients keep marking it as spam, and a blocklist eventually notices the pattern.
A missing or mismatched PTR (reverse DNS) record
Every mail server your IP sends to checks reverse DNS — does the IP resolve back to a hostname that matches what your server claims to be? If there's no PTR record, or it points to something generic like a data-center default, several receivers (Outlook and corporate mail gateways especially) will flag or reject the mail outright, and it looks identical to a blacklist issue.
A noisy neighbor on shared hosting
On shared IP hosting, one account sending spam can get the whole IP listed — including your perfectly clean domain. This is the one cause that isn't really "your" mistake, but it's still your mail that stops arriving.
Genuinely high bounce or complaint rates
Sending a large newsletter to a stale list racks up bounces and spam-button clicks fast. Cross a threshold and providers start listing the sending IP automatically, regardless of your authentication setup.
Fix: step by step
Step 1: Confirm you're actually listed
Don't guess — check. Run your server's IP through a multi-list checker:
dig +short mail.yourdomain.com
# note the IP, then check it at:
# https://mxtoolbox.com/blacklists.aspx
# https://www.dnsbl.info/These scan 100+ blocklists at once and tell you exactly which ones flagged you, plus a direct link to each one's delisting form. Save that list — you'll need it in Step 4.
Step 2: Find and stop the source before requesting removal
Getting delisted while the spam is still going out is pointless — you'll be back on the list within hours. On a cPanel account or VPS, check the outbound mail queue:
# cPanel/WHM (as root via SSH)
exim -bp | exiwhat
# count queued messages per sender
exim -bp | grep '<' | awk '{print $4}' | sort | uniq -c | sort -rnA huge queue from one mailbox or one WordPress account is your source. From there:
- Reset the password on any compromised email account immediately, and check its Sent folder and webmail login history for logins from unfamiliar IPs
- If it's coming from a WordPress site, scan for malware, check for unfamiliar admin users, and disable any contact-form or SMTP plugin until it's clean — see our WordPress hacked recovery guide for the full cleanup steps
- Flush the current queue once the source is shut off:
exim -bpr | grep '<' | awk '{print $3}' | xargs -n1 exim -Mrm(double-check the queue contents first, this is destructive)
Step 3: Check and fix the PTR record
Ask your host to confirm the PTR record for your server's IP resolves to your mail hostname. You can check it yourself:
dig -x YOUR.SERVER.IP.ADDRESS +shortIt should return something like mail.yourdomain.com. — if it returns nothing, or a generic hosting-provider hostname, ask your provider to set it correctly. On a Getwebup VPS this is a quick support ticket; PTR records live at the IP allocation level, not in your domain's DNS zone, so you can't set this yourself via cPanel's Zone Editor.
Step 4: Request delisting from each blocklist
Once the source is shut down and the queue is clear, submit a removal request to each list that flagged you. Most are free and self-service; a few are automatic once the underlying issue clears.
| Blocklist | Typical delisting time | Notes |
|---|---|---|
| Spamhaus (ZEN/SBL) | Minutes to a few hours | Free self-service form; explain the cause briefly, don't over-explain |
| Barracuda | Up to 24 hours | Requires a valid business email for the request |
| SORBS | Auto-expires, or request removal | Some listings there just age out on their own |
| Microsoft (Outlook/Hotmail) | 24–48 hours | Use the Microsoft SNDS/JMRP portal, not a generic blocklist form |
| Google Postmaster Tools | Reputation rebuilds over days | Not a delisting form — it's a reputation dashboard, monitor it here |
Keep the explanation short and factual in every form: what happened, what you fixed, and that it won't recur. Vague or defensive submissions get rejected more often than honest ones.
Step 5: Confirm removal and retest
Re-run the same multi-list check from Step 1 after 24–48 hours. Send a real test email to a Gmail and an Outlook address and check the headers arrive clean, not just that it "didn't bounce" — a message can land without bouncing and still sit in spam.
Prevention: keep it from happening again
- Turn on 2FA and strong passwords for every email account and WordPress admin login — compromised credentials are the single biggest repeat cause
- Keep WordPress core, plugins, and themes updated, and remove any plugin you're not actively using
- Set outbound rate limits if your host allows it, so one script or account can't blast thousands of messages before anyone notices
- Monitor Google Postmaster Tools and Spamhaus's own lookup page monthly if you send any volume of mail — catching a listing early keeps the cleanup small
- Ask about a dedicated IP if you're on shared hosting and this keeps happening because of other tenants, not you
- Keep SPF, DKIM, and DMARC correctly published — they won't stop an IP-level block, but they make legitimate mail easier for receivers to trust once you're clean again
If you're on Getwebup hosting or VPS and can't get a PTR record changed yourself, or you want us to check your outbound mail queue for you, open a support ticket with the IP address and any bounce message you've received — we can usually confirm the cause within minutes.