Somewhere in a junk folder there may be an enquiry from eight months ago. Nobody chose to ignore it. The form worked, the message sent, and a filter somewhere decided it looked like something nobody had asked for.
This is one of the quieter ways a website loses money, because it leaves no trace anywhere you would think to look. Analytics shows the visit. The form shows a submission. Your inbox shows nothing, and the customer, hearing nothing back, rings somebody else.
When someone says they never heard anything, two different things may have happened: the notification never reached you, or it reached you, you replied, and your reply never reached them. Both present as silence and the fix for one does nothing for the other, so it is worth knowing which you have before rebuilding a form that was never the problem.
First prove the mail is being sent at all
Not every missing enquiry is a filtering problem. Forms also stop working outright, usually because something around them changed rather than because anyone touched the website — a new mail provider, a plugin update, an address belonging to someone who has since left. A form posting into nowhere looks exactly like a form whose mail is being junked.
So test it properly before going near a DNS record. Twenty minutes tells you which problem you are solving:
- —Submit the form yourself from a phone on mobile data rather than from your own desk, so you are not testing a cached version of the page
- —Use an address you can actually open, and check its junk folder as well as its inbox — in Gmail, Promotions and Spam; in Outlook, Junk and Other
- —Confirm the address the form posts to still exists and still belongs to somebody who reads it
- —Ask whoever maintains the site whether anything changed around the date the enquiries stopped
Mail from a website is unauthenticated until someone authorises it
If the mail is being sent and being filtered, the cause is almost always authentication. Three records in your domain's DNS decide whether a receiving server believes a message claiming to come from you.
SPF is a list of the servers allowed to send mail as your domain. DKIM adds a cryptographic signature, so a receiver can tell the message was not forged on the way. DMARC tells receivers what to do when neither lines up, and sends you reports naming everything sending mail in your name. It is three lines of text in a DNS panel, not exotic engineering.
The part people miss is that your website is a new sender — a server, somewhere, sending mail that claims to come from your domain. Unless whoever built the site added it to those records, it is an unknown machine impersonating you, and modern filters treat it accordingly.
The commonest fault: the form pretends to be the customer
Here is the fault we find most often, and it is well intentioned. The form sets the sender of the notification to the visitor's own email address, so that hitting reply in your inbox goes straight back to them.
It is convenient and it fails immediately. Your website is not authorised to send mail as gmail.com, or as the enquirer's company domain, so the check fails the moment the message arrives — on a well configured mailbox, enough on its own to put the enquiry in spam.
The fix is a one-line change for whoever maintains the site: send the notification from an address on your own domain, which your records do authorise, and put the visitor's address in the reply-to field. Hitting reply still reaches the customer, nothing about your inbox changes, and the message stops looking forged.
Where the mail leaves from matters as much as what it says
The second common fault is the route. Plenty of sites hand their mail to whatever the web server offers, which on shared hosting means sending from an address shared with hundreds of other sites whose behaviour you do not control. That reputation is not yours and you cannot improve it. Worse, the method usually reports success as soon as the message is handed over, so mail refused later never comes back to you as a failure.
The better arrangement is to send through a service that signs for your domain: the Google Workspace or Microsoft 365 account you already pay for, or a dedicated service built for automated messages. Authorise it in your SPF record, set up its signing key, and the mail arrives looking like what it is.
One caution. Every sender has to be listed, and SPF has a hard limit on how long a chain of lookups it will follow, so stacking up providers over the years quietly breaks the record for all of them. Add senders deliberately, and remove the ones you no longer use.
The half that usually costs more: your replies
If notifications arrive and customers still say they heard nothing, the problem has moved to your own outgoing mail. It matters more, because this is the quote nobody read rather than the enquiry nobody saw.
The same three records govern it. A domain with no proper authentication sends mail that works most of the time and then fails against one provider rather than all of them, in a pattern nobody spots. Most of your customers are on Gmail or on an Outlook, Hotmail or Live address, so one provider deciding against you covers a large share of the people you need to reach.
Two habits make it worse. Sending business mail from a free consumer address while your website advertises something different gives both the customer and the filter a mismatch to worry about. And attaching a quote to a first reply, to someone who has never had mail from you before, is the combination filters are most suspicious of — a short message with the figures in the body gets through more reliably.
One related point, and it is not legal advice: replying to someone who asked you a question is not marketing, so it needs no consent. Adding them to a mailing list afterwards is a different thing with its own rules, and the ICO publishes free guidance on where that line sits.
What has changed, and what has not
None of this is new, but the consequence of ignoring it has hardened. Google and Yahoo began requiring authentication from senders of large volumes of mail, and Microsoft followed, refusing unauthenticated bulk mail to Outlook, Hotmail and Live addresses rather than filing it in junk. Those thresholds sit far above anything a small business sends, so the rules themselves are not about you.
The direction is. Unauthenticated mail used to be junked, which at least left it somewhere a customer might find it. Increasingly it is refused outright, and a refusal is invisible to the person who sent it. The failure mode has become quieter, which is the part worth acting on.
An honest limit, though: authentication is necessary rather than sufficient, and no DNS record obliges a filter to like your message. What it does is remove the commonest reason for ordinary mail to be thrown away, which on most sites we look at is the whole problem.
An afternoon's work, in roughly this order
If you want to tackle this yourself, or hand a list to whoever looks after your site, this is the order that wastes the least time:
- —Run your domain through one of the free SPF, DKIM and DMARC checkers and keep the result, so you can tell later whether anything improved
- —Fix the sender on your form mail — your own domain as the sender, the enquirer in reply-to
- —Route that mail through a service authorised to sign for your domain rather than through the web server
- —Publish a DMARC record set to monitoring only, then read the reports for a few weeks before tightening it — jumping straight to a strict policy is the usual way a business stops its own invoices from arriving
- —Check where enquiries land, and whether anybody opens that inbox at the weekend
How we handle it
Every site we build sends its enquiry mail from the client's own domain through an authenticated service, with the enquirer in reply-to, a confirmation to the customer, and the DNS records set up as part of launch rather than left for someone to discover. It is unglamorous work, and it is the difference between a form that collects enquiries and one that appears to.
If somebody else built your site and you suspect enquiries are going missing, tell us the domain and we will check what your records say and where the form mail leaves from. Often the answer is a sender address and one DNS record rather than anything to do with the website, and when that is the answer we would rather tell you than sell you a rebuild.