Every website sends mail. Order confirmations, password resets, contact form submissions, booking reminders — website transactional email is the category nobody plans for and everybody depends on, and it's usually configured once by whoever built the site and never examined again.
Then customers stop receiving order confirmations, and it turns out they've been going to spam for eight months. This page covers why that happens regardless of which platform you're on, and the arrangement that prevents it.
Why Website Transactional Email Fails Quietly
The default configuration on most platforms sends mail directly from the web server, using whatever mail function the language provides. It works in testing, because you're checking your own inbox and your own provider trusts you.
It fails in production for a reason that has nothing to do with your code. The web server has no sending reputation, its IP address is shared with whatever else the host runs, and the message claims to come from your domain while originating somewhere your domain never authorized. Receiving providers treat exactly that pattern as forgery, because most of the time it is — Google's sender guidelines require authentication for precisely this reason.
The failure is silent from your side. The site reports the mail as sent, the logs show no error, and nothing indicates that the message was filed as junk at the far end. Website transactional email is uniquely bad at telling you it isn't working, which is why the discovery is usually a customer complaint months later.
The Same Problem on Every Platform
This isn't a WordPress problem, though WordPress gets blamed for it most often because it's the most common. The mechanism is identical everywhere.
WordPress uses PHP's mail function by default, which means direct-from-server sending with all of the above. An SMTP plugin replaces it, and that's the standard fix.
Shopify, Wix and Squarespace send their own transactional mail from their infrastructure, which is generally well-maintained. What they don't do reliably is let you send from your own domain with proper authentication unless you configure it, so mail claiming to be from you may not be verifiably from you.
Webflow, Ghost and custom applications vary, but the pattern holds: whatever sends by default is rarely authenticated against your domain.
The consistent fix across all of them is routing website transactional email through an authenticated SMTP connection on a domain whose DNS says that connection is allowed to send.
The Three-Part Fix
Three pieces, and all three are needed — two out of three produces mail that still lands in spam.
An SMTP account to send through. Rather than the web server sending directly, the site authenticates to a mail server and hands the message over. Every platform supports this, either natively or through a plugin.
DNS that authorizes it. An SPF record naming the sending server, and DKIM signing so the message carries a verifiable signature. Without these, authenticated sending still looks unauthorized to the recipient. Our guides to SPF and DKIM cover the records themselves.
A sending address that exists. Mail from noreply@yourdomain.com where no such mailbox exists is a small but real negative signal, and it means replies vanish. Creating the mailbox costs nothing here, since mailboxes aren't billed per seat.
Separating It From Your Correspondence
The arrangement worth adopting once you're past a certain volume is sending website transactional email on a path of its own.
Automated mail and human mail behave differently and are judged differently. A burst of five hundred password resets after a security incident looks nothing like a person writing emails, and if both leave through the same path, the automated traffic's reputation becomes your correspondence's reputation.
Per-domain SMTP profiles make the separation straightforward: point the domain your application sends from at one route, and the domain your people write from at another. A problem on one side then stays on that side. The mechanics are in custom SMTP per domain.
Some businesses go further and use a separate subdomain for automated mail entirely, which isolates the reputation completely at the cost of a slightly less tidy From address. Whether that's worth it depends on volume.
Where a Transactional Provider Is the Right Answer
Being straight about the boundary: at genuine volume, dedicated transactional services exist for good reasons.
If you're sending tens of thousands of messages a day, you want per-message delivery events, webhook callbacks on bounces, template management and detailed analytics. Those are the products' entire purpose, and no mail host does them as well.
Our daily limits are sized for correspondence rather than campaigns — 1,000 messages per mailbox per day on Starter, up to 2,500 on Agency. Website transactional email for a small shop or a booking system fits inside that comfortably. A high-volume platform does not, and the right architecture there is a transactional provider attached through a custom SMTP profile, which keeps your mail hosting and your bulk sending separate without needing two mail providers.
Checking It Actually Works
The most valuable habit is verifying rather than assuming, because this category fails silently.
Trigger a real message — place a test order, request a password reset — and send it to addresses at two different major providers. Open the headers and confirm SPF passed, DKIM passed, and DMARC reports alignment. All three passing means the configuration is genuinely done.
Then repeat that check quarterly, and immediately after anyone touches DNS or changes hosting. Website transactional email breaks most often not when it's set up but when something adjacent to it changes, and nobody thinks to re-test the order confirmations after moving a nameserver.
If messages are arriving but landing in spam, the domain's own delivery statistics and any DMARC reports will usually name the cause faster than guessing at content changes.
