Why Emails Go to Spam on 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. Common causes include missing DNS records, misconfigured SMTP, poor list hygiene and IP reputation issues. A methodical checklist can help identify and address these problems, though inbox placement remains the recipient provider’s decision. 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 improve your chances of reaching the inbox.

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 self‑managed VPS sending directly from its own IP, you have more control over sending practices and configuration, but may inherit the IP’s prior reputation. 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. Missing authentication can lead to spam placement or rejection; requirements vary by receiving provider and sending volume.

Check MX Records

MX (Mail Exchanger) records tell the world which servers receive email for your domain; they do not authenticate your outgoing messages.

• 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).
• Remove obsolete MX records from old providers. Multiple MX records are normal for redundancy, but every listed server must be intended to receive mail for your domain; stale entries can misroute incoming mail.

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 published as a TXT record authorizing sending IPs for the envelope MAIL FROM domain, or the HELO identity when applicable. It does not authenticate the visible From: address by itself.

• There should be exactly one SPF policy TXT record at each domain name evaluated by SPF (multiple SPF policies at that name break validation).
• Authorize the actual outbound IPs with ip4: or ip6:, or use the sending provider’s documented include: domain. An include evaluates another domain’s SPF policy; it is not a generic SMTP hostname lookup. Keep DNS-causing SPF terms within the limit of 10 across evaluation, including nested includes.
• End a policy that lists all authorized senders with an appropriate catch-all mechanism, typically -all (hard fail), once you are sure every legitimate sending service is covered.

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 outgoing messages. Successful verification establishes the signing domain’s responsibility and checks the signed headers and body under DKIM’s canonicalization rules; it does not prove the human sender’s identity or that the content is safe.

• On shared hosting with cPanel or similar panels, use the available DKIM settings to enable signing and obtain the public key TXT record. Confirm that the record is published at your authoritative DNS provider, especially if DNS is hosted elsewhere.
• On a VPS where you run your own MTA (e.g. Postfix + OpenDKIM), configure outgoing signing, generate keys and publish the corresponding public key TXT record, manually or through suitable management tooling.
• Verify that your outgoing messages contain a DKIM-Signature: header, then inspect the receiving provider’s authentication results to confirm DKIM passes for the intended signing domain.

Add a Basic DMARC Policy

DMARC (Domain‑based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It requests receiver handling when neither SPF nor DKIM passes with alignment to the visible From: domain, and supports reports about authentication results and domain use. Receivers also apply their own filtering policies.

• Start with a monitoring policy such as v=DMARC1; p=none; rua=mailto:dmarc@example.com, published as a TXT record at _dmarc.example.com. Replace the example domain and reporting address with your own; use a mailbox or service that can receive aggregate reports. An external reporting domain must authorize receipt in DNS.
• Make sure alignment is correct: DMARC needs at least one passing SPF or DKIM identity aligned with the visible From: domain. Relaxed alignment compares organizational domains; strict alignment requires an exact domain match.
• Later, consider p=quarantine or p=reject only after reports show legitimate mail passes DMARC, including forwarded and mailing-list traffic. General-purpose domains with mailing-list users should not publish reject. Domains using reject must apply valid DKIM rather than rely only on SPF. Inbox delivery is not guaranteed by a DMARC pass.

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 legitimate messages may be rejected or placed in 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

Major mailbox providers such as Gmail require valid forward and reverse DNS for sending IPs. The PTR (reverse DNS) should point to a hostname whose A or AAAA record resolves back to that IP. Using that hostname for outbound HELO/EHLO keeps the server identity consistent.

• On shared hosting, your provider usually manages PTR for the outbound sending IP. Use its recommended SMTP submission hostname, but ask the provider to investigate missing or mismatched outbound PTR records; a mail-client hostname change does not repair them.
• 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, the provider normally configures the outbound mail server’s HELO/EHLO; an application’s submission HELO does not set the provider’s outbound identity.
• 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. Requirements and filtering can differ between IPv4 and IPv6. If IPv6 sending is not ready, temporarily restrict outbound mail to a correctly configured IPv4 path rather than disabling IPv6 for unrelated services.

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

For remote mail submission from your applications and email clients, use authenticated SMTP with TLS encryption:

• Use the SMTP hostname recommended by your hosting provider, not the raw IP.
• Use the provider’s specified port and encryption mode: typically STARTTLS on port 587 or implicit TLS on port 465.
• Do not allow open relays on a VPS: restrict clients’ permission to relay mail to third-party domains to authenticated users and explicitly trusted clients. Accepting incoming mail for domains your server serves is not the same as granting relay permission.

Configure Web Applications Properly

Many websites (WordPress, WooCommerce, contact forms, CRM tools) send transactional email. Problems can arise when PHP’s mail() function hands messages to a local mail system with incorrect sender, signing or delivery settings. Authenticated SMTP provides an explicit submission path, but the receiving mail service still needs correct configuration.

• In WordPress, use an SMTP plugin with credentials dedicated to the application where supported, rather than reusing your personal mailbox credentials.
• Ensure the visible From: address uses a domain you control. For DMARC to pass, that domain must align with at least one successfully authenticated SPF envelope-sender domain or DKIM signing domain.
• Do not send from random addresses like no-reply@server.local 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. These local delivery failures do not by themselves tell remote spam filters that your mail is suspicious.

• 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 can leave delivery problems unresolved and lead to repeated sends to invalid addresses. You need to:

• Monitor bounce mailboxes or use your mailing tool’s bounce logs.
• Suppress addresses confirmed invalid by permanent bounces; investigate temporary failures and policy rejections rather than treating every bounce as an invalid address.
• 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. For deliveries between two accounts on the same server, a message you send may encounter the destination account’s incoming filters. That is not evidence of an outbound filtering problem or of how an external provider will classify it.

• For local test deliveries, check the receiving account’s spam folder and filtering logs. Check outbound filter logs separately if your server filters outgoing mail.
• 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 may ignore, delete or mark your emails as spam. Spam complaints can damage reputation; providers differ in how they use other engagement signals.

• Use double opt‑in to confirm that subscribers control the addresses they submit.
• Keep evidence of consent (logs or timestamps) in case you are investigated by ISPs or regulators.
• Review inactive subscribers and suppress those who remain unengaged after a suitable re‑engagement campaign; do not rely on open tracking alone to determine inactivity.

Make Unsubscribing Easy

Hidden or broken unsubscribe links can lead to more spam complaints.

• Add a clear unsubscribe link to every bulk or marketing email. For marketing and subscribed messages covered by Gmail’s bulk-sender rules, also implement one-click unsubscribe; a body link alone is not sufficient.
• 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. Correct infrastructure does not make misleading content or suspicious links safe; repeatedly sending such content can hurt long‑term deliverability.

• Avoid ALL CAPS subject lines, excessive exclamation marks and over‑promotional wording.
• Do not put essential information only in images; include readable text so the message remains useful when images are blocked.
• Use reputable link shorteners or, better, direct links using your own domain.
• Scan attachments for malware, and avoid sending 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.
• Segment 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. Confirm that the chosen plan’s sending policies and quotas permit your intended traffic.
• You need fine‑grained control over MTA software (Postfix, Exim, etc.), rate limits and routing. For direct delivery to recipient mail servers, verify that the chosen provider and plan permit outbound TCP port 25 and that server and network firewalls allow it; submission ports 465/587 are not substitutes for direct server-to-server delivery. If outbound port 25 is unavailable, consider an authorized SMTP relay service that permits your traffic, and meet its connection, TLS, authentication, quota and domain-verification requirements. With an external relay, the service manages the receiving provider-facing outbound IP, PTR and HELO/EHLO; configure SPF authorization and DKIM signing according to the service’s instructions.
• You want to isolate email from your main shared hosting environment for security or compliance reasons.

With a self-managed VPS mail server, 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 confirm successful verification at a receiving service, not merely the presence of a DKIM-Signature header.
• Add a basic DMARC TXT record for monitoring (p=none to start), with an aggregate-report destination you monitor; the policy alone does not request reports.

Server Identity & IP

• On a VPS, set the server hostname to your mail hostname (e.g. mail.example.com).
• Arrange the PTR record through the IP provider so the sending IP’s reverse DNS matches the mail hostname, and ensure that hostname’s A or AAAA record resolves back to the sending IP.
• Ensure the HELO/EHLO string matches the hostname and DNS.
• Check IP and domain against common blocklists, resolve the cause of any listing, and follow the list operator’s delisting process where necessary.
• If you send via IPv6, repeat these steps for your IPv6 address.

SMTP and Applications

• For remote submission from clients and web apps, use authenticated SMTP with the provider’s specified TLS mode and port, typically 465 or 587.
• 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. For marketing or subscribed messages covered by Gmail’s bulk-sender rules, also support one-click unsubscribe.
• 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 identify sending sources and authentication or alignment failures, including possible unauthorized use of your domain.
• Check server logs for repeated SMTP errors and investigate patterns.

Bringing It All Together

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 self-managed VPS, you gain more flexibility and isolation, while taking responsibility for arranging PTR records and managing 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.

When comparing shared hosting, VPS and dedicated server options, assess sending limits, DNS controls and mail-server management responsibilities. 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 to separate email from shared resources or move to a dedicated sending setup on a VPS, plan the SPF/DKIM/DMARC and PTR configuration and assign responsibility for log review before migrating. Confirm what migration and mail-configuration support is included in the chosen plan; changing infrastructure alone does not guarantee inbox placement.