Home/Email deliverability
Email deliverability
Your invoices are in someone's spam folder.
When website email lands in spam, the cause is almost always authentication: the receiving server cannot verify that your web server is allowed to send as your domain.
Fixing it means configuring SPF, DKIM and DMARC correctly, sending application mail through an authenticated relay, and then reading the reports. That work is included with hosting here rather than sold as an extra.
The cause
Filters aren't judging your writing.
A contact form notification, an invoice, a password reset — these are sent by your web server, not by the mailbox you read your email in. To a receiving mail server, a message claiming to be from your domain but arriving from a server your domain never authorised looks identical to a spoofing attempt. So it gets filed accordingly.
This is why the usual advice fails. Rewriting the subject line does nothing. Asking recipients to whitelist you fixes one recipient. The problem is in DNS, and it stays broken until someone changes DNS.
It also gets worse quietly. Every tool you add that sends as your domain — a CRM, an invoicing platform, a newsletter service, a booking system — needs authorising too. Most businesses accumulate several and authorise none of them.
The fix
Four records, then the monitoring.
SPF
One correct record listing every service that legitimately sends as your domain — and nothing that doesn't. One record, not several: a second one invalidates both.
DKIM
Signing keys published and rotated, so receiving servers can verify the message came from you and arrived unaltered.
DMARC
Policy published in monitoring mode first, reports read, then tightened to quarantine or reject once every legitimate sender is passing.
Relay
Application mail handed to an authenticated relay with delivery logs, instead of leaving directly from a web server with no sending reputation.
Common questions
Deliverability, answered.
Why do my website emails go to spam?
Almost always because the receiving server cannot verify the mail is really from you. Contact forms, invoices and password resets are sent by your web server, and unless SPF, DKIM and DMARC are configured to authorise that server, the message arrives unauthenticated. Filters treat unauthenticated mail claiming to be from a real domain as exactly what spoofing looks like.
What are SPF, DKIM and DMARC?
SPF is a DNS record listing which servers are allowed to send mail as your domain. DKIM adds a cryptographic signature to each message so a receiver can confirm it was not altered and did come from you. DMARC ties the two together, tells receivers what to do when a message fails, and can send you reports on who is sending as your domain. You need all three.
Will fixing DNS records alone solve it?
Usually most of the way. The remaining causes are reputation and content: a shared IP that someone else damaged, a domain with no sending history, mail that looks like bulk marketing, or a list with bad addresses on it. Authentication is the part that must be right first, because nothing else can be diagnosed until it is.
What is an authenticated relay and do I need one?
It is a dedicated mail service your application hands messages to instead of sending them directly from the web server. It signs and delivers them from IP addresses with an established reputation, and gives you logs showing what was accepted, deferred or bounced. For any site sending invoices, receipts or password resets, it is worth having.
How do I know if my email is authenticated correctly?
Send a message to an account you control and inspect the received headers for SPF, DKIM and DMARC results — all three should show a pass. A DMARC policy with reporting turned on will also show you every source sending as your domain, which regularly surfaces a forgotten service nobody knew was still running.
Does this apply to Microsoft 365 or Google Workspace?
Yes. Your mailbox provider handles mail your staff send, but your website, CRM, invoicing and marketing tools each send as your domain too. Every one of them has to be authorised in your records, and this is the most common reason mail from a correctly configured mailbox provider still fails.
Tell us what you're running.
You'll get a straight answer about whether we're the right fit — including when we're not.