The support ticket that repeats itself
Every hosting support team has a version of this conversation. It happens multiple times a week.
"My contact form emails are not arriving."
The customer has a WordPress site on shared hosting. They installed a contact form plugin. They filled out the form themselves to test it. Nothing arrived in their inbox. They checked spam. Nothing. They assumed the form was broken, tried three other plugins, and still nothing.
The form is fine. The problem is how shared hosting handles email, and it is one of the most misunderstood parts of running a WordPress site.
How WordPress actually sends email
WordPress uses PHP's mail() function by default. When someone fills out your contact form or you get a WooCommerce order notification, WordPress tells PHP to send an email, and PHP hands it to the server's mail transfer agent — usually Sendmail or Postfix on a shared hosting server.
That email then goes out from your server's IP address, using whatever mail configuration your hosting provider has set up. And this is where the problems start.
On shared hosting, your site shares an IP address with potentially dozens or hundreds of other sites. If any of those sites sends spam — and on shared hosting, some of them inevitably do — that IP address gets flagged. Email providers like Gmail, Outlook, and Yahoo maintain blocklists of IP addresses with poor sending reputation.
Your perfectly legitimate contact form submission is being sent from an IP address that Gmail has already decided is suspicious. The email either lands in spam or gets silently rejected. You never see it. Your customer never sees the confirmation. Everyone assumes WordPress is broken.
The numbers that explain the problem
We see this pattern across our support operations at Hostao. Roughly 40% of "my email is not working" tickets on shared hosting are not email server problems at all — they are deliverability problems caused by shared IP reputation.
The default PHP mail() function sends email without authentication. No SPF alignment, no DKIM signing, no proper envelope sender. Even if your server's IP is clean, the email arrives without the authentication signals that modern email providers expect. Gmail has become increasingly aggressive about filtering unauthenticated email since their 2024 sender requirements update.
This is not a bug. It is a structural limitation of how shared hosting and PHP email interact.
What SPF, DKIM, and DMARC actually do
You have probably seen these acronyms. Here is what they mean in practice.
SPF (Sender Policy Framework) tells receiving mail servers which IP addresses are authorised to send email for your domain. If your SPF record says "only mail from these IPs is legitimate" and your shared hosting IP is not in that list, the email fails SPF checks.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to your outgoing email. The receiving server can verify that the email was actually sent by someone with access to your domain's DKIM key. PHP mail() on shared hosting typically does not sign emails with DKIM.
DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving servers what to do when SPF and DKIM checks fail. If your DMARC policy says "reject emails that fail authentication," and your WordPress emails fail both SPF and DKIM, they get rejected.
Without all three configured correctly, your WordPress emails are essentially unsigned letters with no return address. Modern mail providers treat them accordingly.
The actual fix: use an SMTP plugin
The solution is straightforward and has been the standard recommendation for years. Stop using PHP mail() and send WordPress emails through an authenticated SMTP connection instead.
An SMTP plugin (WP Mail SMTP, Post SMTP, FluentSMTP) lets you configure WordPress to send email through a proper mail service instead of through the server's local mail function.
Your options for the sending service:
Your hosting provider's SMTP. Most shared hosting plans include email hosting. You can configure WordPress to send through your hosting email account using SMTP authentication. This is better than PHP mail() because the email is authenticated, but you are still subject to the shared server's IP reputation.
A dedicated transactional email service. Services like Mailgun, SendGrid, Amazon SES, Brevo (formerly Sendinblue), or Postmark are purpose-built for sending transactional email. They maintain clean IP pools, handle authentication automatically, and provide delivery tracking. Most have free tiers that cover small WordPress sites — Brevo offers 300 emails/day free, Mailgun gives 1,000/month on the flex plan.
Gmail or Google Workspace SMTP. If you use Google Workspace for your business email, you can route WordPress emails through Google's SMTP servers. Google's sending reputation is excellent, so deliverability is high. The daily sending limit is 2,000 emails for Google Workspace accounts.
For most WordPress sites that send fewer than a few hundred emails per day (contact form submissions, WooCommerce notifications, user registrations), a transactional email service on a free tier is the right answer.
What about the hosting provider's role
This is where I will share an honest operational perspective.
Hosting providers can improve the situation but cannot fully solve it. At Hostao, we configure SPF records for customer domains, maintain server-level DKIM signing where possible, and monitor IP reputation across our shared hosting fleet. Our shared hosting plans — starting at $3/month with NVMe SSD storage and free SSL — include email hosting with Softaculous for easy WordPress management.
But shared IP reputation is a fundamental constraint. No matter how carefully a hosting provider manages their infrastructure, a shared environment means shared reputation. This is true for us and for every shared hosting provider.
The honest recommendation from a hosting provider: use your hosting email for receiving mail and a dedicated service for sending transactional email from WordPress. It is a ten-minute setup that eliminates 90% of email deliverability problems.
When to separate email hosting entirely
For businesses where email is critical — which is most businesses — there is a case for separating email hosting from web hosting entirely.
Google Workspace or Microsoft 365 for business email gives you enterprise-grade email infrastructure with excellent deliverability, regardless of what happens with your web hosting. Your MX records point to Google or Microsoft, your web hosting handles just the website.
- This separation means:
- Your email works even if your hosting goes down
- Your email reputation is independent of your hosting IP
- You get better spam filtering, better mobile apps, better collaboration tools
- Your hosting provider can focus on what they do best — serving your website fast
The downside is cost — Google Workspace starts at roughly $7/user/month. For a solopreneur, that is an easy decision. For a business with 20 employees, it adds up.
The WordPress email checklist
If you are running a WordPress site on shared hosting and you have not configured email properly, here is what to do today:
Install WP Mail SMTP or a similar plugin. Connect it to either your hosting provider's SMTP (minimum viable fix) or a transactional email service (better fix). Send a test email. Check that it arrives in your inbox, not spam.
Then set up SPF, DKIM, and DMARC records for your domain. Your hosting provider's support team can help with this — it involves adding DNS records, which takes five minutes if you know what to add.
Do not wait for a customer to tell you their contact form submission disappeared. By the time they tell you, they have probably already gone to your competitor.
For businesses that depend on customer communication through their website, consider connecting a WhatsApp channel as a backup contact method — it does not depend on email infrastructure at all, and customers increasingly prefer messaging over forms.
Image suggestion: a flowchart showing the path of a WordPress email — from PHP mail() through the server, hitting IP reputation check, SPF/DKIM check, and either landing in inbox or spam. A parallel path shows SMTP plugin routing through a transactional service directly to inbox.