Growth & Support
Why Your Website’s Emails Land in Spam, and How to Fix It for Good
Order confirmations, password resets and contact-form notifications are the emails a business cannot afford to lose. Most are lost to three missing DNS records. Here is how to find out where yours go, and fix it.
"The customer says they never got the confirmation." "Our contact form has not sent anything for a week." "Password resets are going to junk." These are the three complaints behind almost every deliverability job we take on, and they usually share a cause: the website is sending email in a way that mail providers no longer trust.
Our email deliverability service fixes the plumbing. This guide explains what the plumbing is, so you can see whether yours is leaking before you call anyone.
The Three Records Every Domain Needs
Gmail, Outlook and Yahoo now expect three DNS records from anyone sending email in your domain's name. Without them, your messages are treated as probable forgery.
- SPF lists which servers may send mail for your domain. If your website sends from the web server and your staff send from Google Workspace, both must be in the record. One record, not two.
- DKIM adds a signature to each message that proves it was not altered. Your email provider gives you a key to publish; the website's sending service needs its own.
- DMARC tells receivers what to do when SPF or DKIM fail, and sends you reports. Start with a monitoring policy, read the reports for two weeks, then tighten.
Checking takes ten minutes. Missing or broken records are the cause in roughly two thirds of the cases we see.
Why PHP mail() From Shared Hosting Fails
WordPress, WooCommerce and most PHP applications send email through the web server by default. On shared hosting that server's address is shared with hundreds of other sites, some of them sending spam, so its reputation is poor. The message also usually fails SPF because the web server is not in your record. It may arrive, it may land in junk, it may vanish. You will not know which.
The fix is to send through a dedicated transactional email service with your own authenticated domain, over SMTP or an API. The site itself does not change; a small plugin or a few lines of configuration route the mail, and every message is logged so "did it send?" has an answer.
Transactional Email Is Not Newsletter Email
Order confirmations, receipts, password resets and booking reminders are transactional: one recipient, triggered by their own action, expected immediately. Newsletters are marketing: many recipients, scheduled, optional. Sending both through the same service and address drags the transactional mail down with the marketing mail's complaints and unsubscribes.
Keep them apart: a transactional service on a subdomain such as mail.yourdomain.com, and a marketing platform on its own. The reputation of the address that sends your receipts should be the cleanest thing you own. Stores we build with WooCommerce or through our payment and subscription integrations are set up this way from day one, because a missing receipt is a refund request waiting to happen.
Test Where the Mail Actually Lands
"It arrived in my inbox" proves nothing; your own provider trusts you. Inbox placement testing sends the same message to seeded addresses at each major provider and reports where it landed and why. We run this before and after changes and keep the headers, so the improvement is documented rather than assumed. For a store or a booking system this is the single most useful number in the whole exercise.
Content and Volume Still Matter
Authentication earns you a hearing; it does not guarantee the inbox. Messages that are all image, link to unrelated domains, or go out in a sudden burst from a new address still raise flags. Warm up a new sending domain gradually, keep a plain-text part in every message, and make sure every link points at your own domain. The same discipline that keeps a site healthy under a maintenance plan keeps its email trusted.
The Silent Failure: Forms That Send Nothing
Contact forms fail quietly. A plugin update changes a setting, the host blocks outbound port 25, or a record expires, and enquiries stop arriving with no error on the screen. Monitor it: a weekly test submission, a log of sent messages, and an alert when the log goes quiet. If yours has already gone quiet, our troubleshooting service will find out when it stopped and what you missed.
A Checklist to Take to Your Hosting Panel
- One SPF record covering every sender, under the lookup limit.
- DKIM for every service that sends, including the website.
- DMARC with reports going somewhere a human reads.
- Website mail routed through a transactional service, logged.
- Marketing mail on a separate address and platform.
- A placement test on file, and a monitor on the contact form.
Hosting and DNS changes are easy to get subtly wrong, so if your domain is managed through several providers our hosting and DNS management team can consolidate it first. Or send us your domain name: the first check is free and takes less time than reading this article.
