Site email not sending
Your website talks to customers by email. Right now, it's talking to the void.
Order confirmations, lead notifications, password resets, receipts — the mail your website sends is business infrastructure. When it silently stops arriving, customers assume you ghosted them, and you assume it's been a quiet week. Both wrong.
Same-day diagnosis. Flat quote before any fix.
What’s actually happening
Website email fails silently by design: mail systems don't ring your phone when they discard a message as suspicious — they just discard it. And unauthenticated mail from a web server is the definition of suspicious, because it's technically identical to spoofing. Google and Microsoft have only tightened this; mail that skated through in 2020 dies quietly in 2026.
Authentication is the fix, and it's three DNS records doing three jobs: SPF lists who may send for your domain, DKIM cryptographically signs each message as genuinely yours, DMARC tells receivers what to do with mail that fails the first two. Set correctly — and paired with sending through a real mail service instead of the server's default — deliverability stops being a coin flip.
The usual causes, ranked
After twenty-seven years of these calls, the odds are well mapped. Start at the top.
No SPF/DKIM authentication
The dominant cause: the domain never told the internet who's allowed to send as it, so receivers guess — increasingly, against you.
Sending via the server's default PHP mail
Shared-hosting mail comes from IPs with the reputation of a payphone. Even authenticated, it's the wrong pipe for business mail.
A DNS change that broke existing records
Moved hosts, changed nameservers, added a service — and the old SPF record stopped covering the new sender. Worked last month; dying this month.
The domain or IP landed on a blocklist
Past spam from a shared IP, or a compromised site sending junk under your name. Diagnosable, and recoverable with cleanup plus authentication.
Strict receiver policies at one destination
Everything arrives except at one customer's corporate domain — their filters demand stricter authentication than you're publishing. Their rules; your records.
What you can safely try first
Nothing below can make things worse — that’s the selection criterion. Anything riskier belongs in professional hands, on a backup.
- 1
Send a test to a Gmail address
Gmail annotates: check spam, and use 'show original' to see SPF/DKIM/DMARC verdicts spelled out as pass or fail. Three lines of truth, free.
- 2
Check your DNS for the records
An SPF checker (or your DNS panel) shows whether the records exist and what they permit. Absent records is diagnosis complete; wrong records is close behind.
- 3
Inventory what the site sends and from where
Forms, store receipts, password resets — each may use a different method and address. The one that's failing tells you which pipe to fix.
Stop and call when…
- Test mail fails SPF or DKIM — DNS record work with syntax that punishes guessing
- You're on a blocklist — removal has a process, and re-listing is the amateur-hour outcome
- Order emails are failing on a live store — every silent hour is customer-service debt
From there it’s our job: same-day look, flat quote, and the $389 flat repair covers most cases of exactly this.
Form & Email Rescue — buy it now, skip the hunt.
Contact forms delivering again, order and notification emails reaching inboxes.
Covers form and site-email failure on one site: broken submissions, vanishing notifications, spam-folder exile. Includes deliverability setup (SPF/DKIM) where the fix needs it.
Questions we hear a lot.
Why did it work for years and stop now?
Receiver standards moved. Google and Microsoft now effectively require authentication they once merely preferred — enforcement tightened in waves, and each wave silently killed another tier of unauthenticated senders. Your mail didn't change; the bar did.
What are SPF, DKIM, and DMARC in one breath each?
SPF: the guest list of servers allowed to send for your domain. DKIM: a cryptographic signature proving the message is really yours and unaltered. DMARC: your published instruction for what receivers should do when the first two fail — and where to send the reports. Together they're your domain's ID card.
Should my website send through Gmail?
Through your own Gmail account, no — limits and lockouts make it a trap. Through a transactional mail service (Postmark, SES, and peers) with your domain authenticated, yes — that's the professional pipe, it's inexpensive, and it's exactly what we wire in the fix.
What does the $389 repair cover?
The full pipeline: authentication records set correctly, sending moved to a proper service, every site email (forms, receipts, resets) tested to real inboxes, and the records documented so the next DNS change doesn't quietly undo it.
Related symptoms & help
Errors travel in packs. If this one visited, check its friends.
Out of the void, into the inbox.
Send the symptom, get a same-day look and a flat quote from the developer who's fixed this exact thing more times than either of us can count.