A client rang us in August. Their enquiry form had been working fine for months. Then a customer phoned to ask why they’d been ignored for a fortnight.
No one had ignored anyone. The form was submitting properly. It showed its success message, saved the entry, sent the visitor to the thank-you page. The email that tells the team a new enquiry has landed was going nowhere.
This is the worst category of website fault. It throws no error. It shows up in no report. You find out when a customer gets annoyed enough to pick up the phone, and by then you’ve no idea how many others just went elsewhere.
Here’s what broke, how we found it, and why it had already happened once before to the same site.
What the client saw
An Auckland foreign exchange brokerage. Their site takes enquiries through a standard WordPress form, and those enquiries are the front end of their whole sales process. Somebody fills it in, the team gets an email, someone calls back.
From the outside everything looked healthy:
- The form submitted without complaint
- The success message appeared
- Entries were being stored in WordPress, all of them, in order
- The site itself was up and quick
Only the notification email had stopped. And because the entries kept saving, the evidence that anything was wrong sat inside the WordPress admin area, where nobody had a reason to look.
Second time in 14 months.
Why forms fail this quietly
Your website hands the email to a mail service and considers the job done. The delivering happens somewhere else, out of sight.
Everything after that handover is the receiving mail server’s decision. It can accept the message, bin it into spam, or drop it without telling anybody. From WordPress’s point of view the send succeeded in all three cases.
So “the form works” and “the form reaches a human” are two different tests. Most sites only ever get the first one checked.
The second thing worth knowing: email delivery is governed by your DNS records, not by your website. Those records tell the rest of the internet which services are allowed to send email using your domain name. Get them wrong and the best-built form in the world still goes silent.
How we traced it
We worked outward from the site, one layer at a time.
Were entries still saving? Yes. So the form logic and the database were both fine, which ruled out the plugin everyone assumed was guilty.
Was the site attempting to send? Yes. The mail plugin’s own log showed every notification recorded as sent successfully. That’s the giveaway. When a site reports success and the inbox stays empty, the fault is downstream of WordPress.
What did the domain’s DNS actually say? This is where it fell over.
The cause
The domain’s published sending policy and the way the site was really sending had drifted apart. Receiving mail servers were being told, by the domain’s own records, that mail arriving from this source wasn’t authorised. So they binned it. Correctly, and without a bounce message to anyone.
Two things made it likely to happen again.
The brokerage’s DNS lives on Cloudflare inside their own account and is managed by their IT contact, not by us. Fair enough, plenty of clients work that way. But it means website email depends on a system the website team doesn’t watch.
And the record at the centre of it was shared with two other services: their Microsoft 365 mailboxes and a separate transactional email provider. One line of text, three services relying on it, edited by whoever happened to be in there that quarter.
Both outages, the one in 2025 and this one, traced back to a DNS change made without anyone checking what else was leaning on that record.
What we did about it
Putting the old arrangement back would have held until the next DNS edit, so we rebuilt the sending path instead.
- Its own verified sender. Form email now goes out through Amazon SES with the domain verified directly, rather than borrowing a service that was set up years ago for something else.
- Its own path. We gave the site a dedicated sending subdomain, so website mail and staff mailboxes no longer share plumbing. Either can now be changed without knocking over the other.
- One record, extended. The shared policy record was widened to include the new sender while keeping both existing ones. Microsoft 365 and the other provider carried on working the entire time.
- Its own credentials. The site sends with keys scoped to this one client. If they ever need pulling, no other site notices.
- A locked sender address. Every notification now leaves as the same verified address regardless of what any individual form is configured to use, so a form built later by somebody else can’t quietly reintroduce the fault.
Then a real test enquiry through the live form, confirmed at the receiving mailbox. Not a log entry saying “sent”.
The part that matters more than the fix
It happened twice for the same underlying reason. Nothing was watching.
DNS sat with the client’s IT person. Website email depended on DNS. And no one owned the job of checking that those two facts still agreed with each other, so the site ran broken for weeks before a customer got cross enough to ring.
That gap is exactly what a maintenance retainer is meant to close. Sender records get checked on a schedule. A real test enquiry goes through the live form and somebody confirms it landed. When the client’s IT contact edits DNS, the website is in the conversation instead of finding out months later.
Uptime monitoring would not have caught any of this. The site was up the whole time.
The technical detail
For anyone who wants specifics, this is the shape of the working configuration.
SPF. A domain gets exactly one SPF record, however many services send on its behalf. Adding a sender means merging its include into the record that’s already there. Two SPF records is a permanent error that takes down every sender at once, which is why the instinct to “just add another line” is how sites break.
DKIM. Three CNAMEs published by the sending platform, letting the receiver verify the cryptographic signature on each message.
Custom MAIL FROM. A dedicated subdomain carrying its own MX and its own SPF TXT record. This is what gives you DMARC alignment on the envelope sender, and it stops website mail depending on the root domain’s mail setup.
Cloudflare proxy status. Host and mail records need to be grey-cloud, DNS only. Proxying them on this domain previously introduced AAAA records and blocked an SSL renewal on the www hostname.
Host IP sets. Worth auditing while you’re in there. On this domain the bare domain and the www hostname were pointed at two different sets of the host’s IP addresses, leaving the certificate for one of them stuck in pending validation. Both hostnames want the same set.
Credentials. One scoped sending user per site. Shared keys across a client portfolio mean a single rotation takes everybody down together.
If your enquiries have gone quiet
Work through these before assuming your form plugin is at fault:
- Are entries still saving in WordPress? If yes, the form is fine and you have an email problem.
- Does your mail plugin’s log show sends succeeding? If yes, the problem is your DNS or the receiving server.
- Has anyone touched your DNS in the last few months? Ask your IT contact directly. They may not connect a DNS edit to the website at all.
- Send a real test enquiry through the live form and go and look for it in the mailbox that’s supposed to receive it.
Then fix the reason you didn’t know. A form that stops silently is only expensive because of how long it stays broken.
If you’d rather have somebody checking this for you every month, that’s what our website care plans are for, and it’s part of ongoing WordPress support. If your forms have already gone quiet and you need it sorted this week, Quick Fix is the faster door. Or just get in touch and describe what you’re seeing.