Why Do Your Emails Go to Spam? Deliverability Checklist for Shared Hosting and VPS

If you run your website and email on shared hosting or a VPS, you have probably experienced this: invoices, order confirmations or newsletters that look perfectly legitimate still land in the spam folder. Sometimes they arrive for one customer but vanish for another. From the hosting side, we see the same patterns repeat: missing DNS records, misconfigured SMTP, poor list hygiene and IP reputation issues. The good news is that almost all of these can be diagnosed and fixed with a clear, methodical checklist. In this article we will walk through the main technical and non‑technical reasons why emails go to spam when you send from shared hosting or a VPS, and what to change step by step. We will keep the focus on practical checks you can actually perform in your control panel or server, so you can get your emails back into the inbox and keep them there.

How Spam Filters Really Judge Your Emails

Modern spam filters don’t look at a single factor. They score each email based on a combination of signals: who is sending it, what infrastructure they use, how the content looks, and how recipients interact over time. When you are sending from shared hosting or your own VPS, three layers matter most:

• Domain reputation – is your domain properly authenticated and historically trustworthy?
• IP reputation – what has been sent from the server IP before (by you or others)?
• Message and behavior signals – does the content look like spam, and do users open, click and keep your emails?

On shared hosting, you usually share an IP with many other customers, so your deliverability is directly affected by other senders’ behavior. On a VPS, the IP reputation is mostly under your control, but all the configuration work is also your responsibility. Understanding these trade‑offs is key to choosing the right fixes and the right hosting model for your email.

Step 1: Make Sure Your Domain and DNS Are Email‑Ready

Before you troubleshoot content or IP reputation, confirm that your domain’s DNS is correctly set up for email. Most spam filters will not trust mail from domains that lack basic authentication records.

Check MX Records

MX (Mail Exchanger) records tell the world which servers handle email for your domain.

• Use your registrar or hosting DNS panel to verify that MX records exist and point to the correct mail server name (for example, mail.example.com).
• Ensure there are no leftover MX records from old providers; multiple conflicting MX records can cause random deliverability problems.

If you are new to DNS concepts, our guide on what DNS records are and how A, MX and TXT records work is a helpful primer.

Set Up SPF Correctly

SPF (Sender Policy Framework) is a TXT record that lists which servers are allowed to send email for your domain. Receiving servers check SPF to detect forged senders.

• There should be exactly one SPF record for your domain (multiple SPF records break validation).
• Include the sending IP or host used by your shared hosting or VPS (e.g. via ip4:, ip6: or include: mechanisms).
• End the record with an appropriate qualifier, typically -all (hard fail) once you are sure the configuration is correct.

We explain SPF in depth, including examples for cPanel and VPS, in our article “SPF, DKIM and DMARC Explained for cPanel and VPS Email”.

Enable DKIM Signing

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message so receivers can verify that it was not modified and really comes from your domain.

• On shared hosting with cPanel or similar panels, enable DKIM in the email or authentication settings; this will generate the public key DKIM TXT record for you.
• On a VPS where you run your own MTA (e.g. Postfix + OpenDKIM), you must generate keys and publish the corresponding TXT record manually.
• Verify that your outgoing messages contain a DKIM-Signature: header.

Add a Basic DMARC Policy

DMARC (Domain‑based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It tells receivers what to do when SPF/DKIM checks fail and lets you receive reports about abuse of your domain.

• Start with a monitoring policy such as v=DMARC1; p=none; rua=mailto:[email protected].
• Make sure alignment is correct: the visible From: domain should match the domains used in SPF and DKIM.
• Later you can tighten the policy to p=quarantine or p=reject once you are confident everything legitimate passes SPF and DKIM.

For a friendly, step‑by‑step way to see how SPF, DKIM, DMARC and rDNS fit together from the inbox vs spam perspective, you can also read “Inbox or Spam? A Friendly, Step‑by‑Step Guide to SPF, DKIM, DMARC and rDNS”.

Step 2: Fix Server Identity, PTR (rDNS) and IP Reputation

Once your domain authentication is solid, the next big layer is your server and IP. This is where shared hosting and VPS behave very differently.

Understand Shared IP vs Dedicated IP

On most shared hosting plans, many customers send mail from the same IP address. If one of them sends spam, the shared IP can end up on blocklists, and your perfectly clean messages start hitting spam too. On a VPS, you typically have a dedicated IP that only you use. That gives you more control over reputation, but also more responsibility to configure things correctly and avoid bad practices that could harm it.

Set a Proper PTR (Reverse DNS) Record

Almost every major mailbox provider checks the PTR (reverse DNS) of the sending IP. The PTR should resolve to a hostname that in turn resolves back to the same IP and matches the HELO/EHLO the server uses when talking SMTP.

• On shared hosting, your provider usually manages PTR for you; you just need to use the recommended outbound hostname in your mail client.
• On a VPS, you must request or configure the PTR with your provider. Set it to something like mail.example.com and create matching A/AAAA records.
• Check that mail.example.com resolves to your IP, and that the PTR of that IP points back to mail.example.com.

We cover why this matters for email deliverability in detail in our article “What Is a PTR (Reverse DNS) Record?”.

Match HELO/EHLO to Your Hostname

When your mail server connects to another server, it identifies itself with a HELO/EHLO string (e.g. EHLO mail.example.com). Many receivers expect this to match the server’s forward and reverse DNS.

• On shared hosting, this is preconfigured; do not override it with custom HELO values at the application level.
• On a self‑managed VPS, set the hostname of the server to your mail hostname and configure your MTA to use it as the HELO/EHLO.
• A mismatch between HELO, PTR and A/AAAA records is a classic reason for spam scores to increase.

Monitor and Repair IP Reputation

Even with perfect DNS and HELO, your IP may still be on one or more blocklists due to past abuse (especially if it is a reused address). You should:

• Check major public blocklists to see if your IP or domain is listed.
• Investigate the cause (compromised script, weak password, old forwarder that relays spam).
• Fix the root problem first, then request delisting from each blocklist following their instructions.

We have a dedicated playbook on this topic: “Stuck on a Blocklist? The Friendly Playbook for Email Sender Reputation Recovery”, which walks through delisting and safe IP warm‑up in detail.

Don’t Forget IPv6 (If You Use It)

If your VPS or hosting account sends email over IPv6 as well as IPv4, you need to configure PTR, SPF and sometimes separate reputation monitoring for the IPv6 address. Deliverability over IPv6 is slightly stricter in some environments because providers want to fight abuse early. If you are unsure, you can temporarily disable sending over IPv6 until you have proper dual‑stack email authentication in place.

Step 3: SMTP Configuration Checklist on Shared Hosting and VPS

Even with DNS and IP identity sorted, bad SMTP configuration can push your emails into spam or cause them to be silently dropped. Use this checklist for your cPanel account or VPS.

Use Authenticated SMTP with TLS

Always send mail from your applications and email clients via authenticated SMTP using TLS encryption:

• Use the SMTP hostname recommended by your hosting provider, not the raw IP.
• Enable STARTTLS or SSL/TLS on port 465/587 so that the connection is encrypted.
• Do not allow open relays on a VPS; every outgoing message must be tied to an authenticated user or trusted web application.

Configure Web Applications Properly

Many websites (WordPress, WooCommerce, contact forms, CRM tools) send transactional email. Problems arise when they use PHP’s mail() function with defaults instead of your authenticated SMTP settings.

• In WordPress, use an SMTP plugin and configure it with the same credentials you use in your email client.
• Ensure the From: address belongs to your domain and matches SPF/DKIM configuration.
• Do not send from random addresses like [email protected] or unconfigured subdomains.

We discuss broader transactional email strategies for WordPress and WooCommerce in our guide on transactional email infrastructure for WordPress and WooCommerce.

Watch Your Sending Limits and Rates

Shared hosting servers often enforce per‑hour or per‑day sending limits to prevent abuse. Exceeding these limits can result in deferred emails or sudden bounces, which in turn look suspicious to remote spam filters.

• Know the per‑hour/per‑day limits for your hosting plan.
• Throttle bulk campaigns (newsletters, promotions) so they send gradually instead of in one huge burst.
• On a VPS, implement similar rate limiting yourself to avoid sudden volume spikes from scripts or compromised accounts.

Handle Bounces and SMTP Errors Properly

Ignoring bounce messages is one of the fastest ways to damage your reputation. You need to:

• Monitor bounce mailboxes or use your mailing tool’s bounce logs.
• Remove repeatedly bouncing addresses from your lists.
• Understand 4xx (temporary) vs 5xx (permanent) SMTP codes to know when to retry vs stop.

For a deeper look at what bounce messages and codes actually mean, see our article “SMTP Error Codes and Bounce Messages: Fixing 4xx–5xx Delivery Issues”.

Use Server‑Side Spam Filtering Wisely

On shared hosting, tools like SpamAssassin and RBL checks are used to filter incoming mail. Misconfigured filters can occasionally affect outgoing mail as well (for example, if you test deliveries between two accounts on the same server).

• Check that your outgoing messages are not being tagged as spam by your own SpamAssassin rules.
• Use a reasonable threshold; extremely aggressive scores can cause false positives.
• Use quarantine folders and logs to see why a message was scored high.

If you want a more structured approach, we have a step‑by‑step walkthrough of email spam filtering on cPanel with SpamAssassin and RBLs.

Step 4: Content, Lists and Engagement – The Human Side of Spam

Even with perfect infrastructure, bad sending practices can still push you into spam. Mail providers watch how people interact with your messages and how you build your lists.

Use Clean, Confirmed Opt‑In Lists

Never buy or scrape email lists. Users who did not explicitly ask to hear from you will ignore, delete or mark your emails as spam – all of which feed back into reputation systems.

• Use at least single opt‑in; double opt‑in is even better for high‑value lists.
• Keep evidence of consent (logs or timestamps) in case you are investigated by ISPs or regulators.
• Regularly remove inactive subscribers who have not opened or clicked in many campaigns.

Make Unsubscribing Easy

Hidden or broken unsubscribe links almost guarantee more spam complaints.

• Add a clear unsubscribe link to every bulk or marketing email.
• Process unsubscriptions quickly; do not continue sending for weeks.
• Consider offering a “preferences” page so users can choose which types of emails they want.

Avoid Classic Spam Triggers in Content

Spam filters look at language patterns, layout and links. While good infrastructure can compensate for some issues, repeatedly sending content that looks spammy will hurt long‑term deliverability.

• Avoid ALL CAPS subject lines, excessive exclamation marks and over‑promotional wording.
• Do not overstuff emails with images and almost no text; maintain a healthy text‑to‑image ratio.
• Use reputable link shorteners or, better, direct links using your own domain.
• Scan attachments for malware, and avoid sending large executable files altogether.

Keep a Consistent Sending Pattern

Mailbox providers prefer predictable senders. Wild spikes in volume or long periods of silence followed by massive campaigns can look like compromised accounts.

• Warm up new sending domains and IPs gradually (especially on a fresh VPS).
• Schedule regular newsletters instead of sending irregular bursts.
• Segement your audience so not every message goes to everyone all at once.

Step 5: Shared Hosting vs VPS – Which Is Better for Deliverability?

Both shared hosting and VPS can deliver excellent inbox rates if configured correctly, but each has different strengths and responsibilities.

When Shared Hosting Is Enough

Shared hosting works well when:

• Your sending volume is modest (order confirmations, occasional newsletters).
• You are comfortable letting the hosting provider manage IP reputation, PTR records and MTA setup.
• You do not need advanced routing rules, custom SMTP daemons or complex monitoring.

In this scenario, your main focus is to:

• Set up SPF, DKIM and DMARC correctly for your domain.
• Configure your web applications to use authenticated SMTP.
• Maintain clean lists and good content practices.

When a VPS Makes More Sense

A VPS becomes attractive when:

• You send higher volumes of email and may want a dedicated IP.
• You need fine‑grained control over MTA software (Postfix, Exim, etc.), rate limits and routing.
• You want to isolate email from your main shared hosting environment for security or compliance reasons.

With a VPS, you are responsible for:

• Maintaining the operating system and mail software.
• Setting PTR, SPF, DKIM, DMARC, HELO/EHLO and TLS settings correctly.
• Monitoring logs, blocklists and reputation over time.

If you are already feeling constrained by shared hosting resources in general, our guide on moving from shared hosting to a VPS without downtime explains how to plan that transition calmly.

Step 6: A Practical Deliverability Checklist You Can Follow Today

To make all of this easier to act on, here is a condensed checklist you can work through on your shared hosting account or VPS.

Domain & DNS

• Confirm MX records point to the correct mail server.
• Create or validate a single, correct SPF TXT record.
• Enable DKIM signing and verify DKIM headers on outgoing mail.
• Add a basic DMARC TXT record for monitoring (p=none to start).

Server Identity & IP

• On a VPS, set the server hostname to your mail hostname (e.g. mail.example.com).
• Configure the PTR record so your IP’s reverse DNS matches the hostname.
• Ensure the HELO/EHLO string matches the hostname and DNS.
• Check IP and domain against common blocklists and request delisting where necessary.
• If you send via IPv6, repeat these steps for your IPv6 address.

SMTP and Applications

• Use authenticated SMTP with TLS (ports 465 or 587) from all clients and web apps.
• Disable or avoid using raw PHP mail() without proper envelope sender settings.
• Set correct From: addresses that belong to your domain.
• Know your hosting plan’s sending limits; configure throttling for bulk sends.
• Monitor bounce messages and clean up invalid addresses regularly.

Content & Lists

• Use only opt‑in lists; never buy or scrape email addresses.
• Add clear unsubscribe links and honour requests quickly.
• Avoid spammy language, excessive images and suspicious links.
• Send at a steady, predictable rhythm, warming up new IPs and domains gradually.
• Encourage engagement by sending relevant, segmented content.

Monitoring & Continuous Improvement

• Periodically test messages with spam‑testing tools or seed inboxes.
• Track open and click rates; sudden drops can signal a new deliverability problem.
• Review DMARC reports to see who is sending on behalf of your domain.
• Check server logs for repeated SMTP errors and investigate patterns.

Bringing It All Together (and How We Can Help)

Email deliverability is rarely about a single magic switch. It is a combination of correct DNS records, a cleanly configured server, reasonable sending volume and genuine, wanted content. On shared hosting, you lean more on the provider for IP reputation and MTA configuration, but you still control authentication, application settings and list quality. On a VPS, you gain far more flexibility and isolation, while taking full responsibility for PTR, HELO, TLS and monitoring. The most reliable results come when all of these pieces are aligned and maintained over time rather than treated as a one‑off setup.

At dchost.com, we design our shared hosting, VPS and dedicated server solutions with these real‑world email needs in mind. If you are struggling with spam folder issues today, you can start by following this checklist and comparing each step with your current configuration. If you decide that it is time to separate your email from overloaded shared resources or move to a dedicated sending setup on a VPS, we can help you plan that transition, configure SPF/DKIM/DMARC and PTR correctly, and review logs together until your messages reach the inbox more consistently. You do not have to guess; you just need a clear, hosting‑aware deliverability plan and the right infrastructure underneath it.