The form is the easy half
Ask an AI builder for a contact form and you get one in a single pass. Labels, two validation rules, a dropdown, a consent checkbox, a confirmation message — these are standard patterns and models reproduce them reliably. In a demo the form works: you submit it, a message appears, the page thanks you.
What the demo cannot show you is what happens after the submit button. The page’s job ends at a successful request; the message then travels through your hosting provider’s mail setup, the DNS records of your domain and the filtering rules of the receiving mail server. Three separate systems, none of them part of the page, and each one can quietly drop the message.
The failure is silent by design. The visitor reads “thank you, we will reply within 24 hours” and moves on. Nobody on your side receives anything. Often the first sign is a customer asking why you never answered their enquiry — days after they sent it.
What decides whether an enquiry actually arrives
Three DNS records decide most of it: SPF, DKIM and DMARC. SPF lists the servers allowed to send mail as your domain. DKIM signs the message so the receiver can check that nothing was altered in transit. DMARC ties the two together: it compares the visible From: domain with the signing domain and tells the receiver what to do when they disagree. When these records are missing or wrong — the normal state of a site deployed by a tool that never touches your DNS — the receiving server has no reason to trust the message, and filtering it is the default answer.
The sending address is the second trap. A form that sends from no-reply@yourdomain through the hosting provider’s shared server is asking to be filtered: that server is not listed in your SPF record, the domain has no DKIM key, and the reply-to mailbox is one nobody reads. Receiving providers also weigh sender reputation, so a domain that has never sent mail before starts with no trust at all.
And sometimes the mail never leaves the building. Some shared hosts block outgoing mail entirely to keep spam under control, and a form plugin that calls the server’s own mail function treats a blocked send exactly like a successful one. In that case there is no message sitting in any spam folder to find — the message never existed.
Why your own test always gets through
Testing from your own inbox proves almost nothing. You open your own mail every day, so your own provider has learned to trust you, and messages between addresses on the same domain share that history. Your test also arrives seconds after you interacted with the site, from the patterns and the network you always use. The question that matters is what a first-time sender looks like to someone who has never received mail from your domain — and your own address cannot answer that.
A test that passes on the office network flatters the result as well. Internal routing, live sessions and addresses you have emailed before all push the message towards the inbox. The spam folder of an address outside your company is the only honest test surface, and it is also the one most teams never open.
This is the pattern behind most reports of a “broken form”: a week of successful internal tests, then real enquiries that never show up in anyone’s inbox. The form itself was never the problem — the path after it was, and no internal test was ever going to reveal it.
A 15-minute verification checklist
Send one enquiry from an address that has never contacted you. A personal Gmail address if the company runs on Microsoft 365, or the other way round. This single test tells you more than a week of internal checks.
Open the received message and read its headers. Most mail clients expose them under “show original” or “view source”. Find the Authentication-Results line: you want SPF pass, DKIM pass and DMARC pass on that line. A fail or a missing result there explains most silent losses.
Check your DNS records. An SPF record that includes the server or service actually sending for you, a published DKIM record, and a DMARC record — even a permissive one with p=none and a report address — so failures arrive as reports instead of as silence.
Send through an authenticated route. Point the form at your mail provider’s SMTP credentials or a transactional mail service instead of the server’s own mail function, and set the reply-to address to a monitored mailbox. Ask whoever runs the site to log send failures: a submission that cannot be delivered should alert a person, not disappear.
Repeat the test from a second provider after a few hours. One pass proves a path exists; two passes from different networks prove it holds.
Delivery is part of building the website
A contact form is not finished when it submits — it is finished when the enquiry reaches a person. That makes delivery a build-time concern: the DNS records, the sending route and one external test belong in the same checklist as the layout and the mobile view. AI is very good at generating the form and indifferent to what happens after it, so asking for the page and asking for verified delivery are two different requests.
Run the fifteen-minute check before the site goes live rather than after the first lost enquiry. It costs nothing, and it turns the most expensive silent failure on a small-business website — a customer who wrote to you and concluded you ignored them — into a problem you solved in an afternoon.
Related service: Websites and web applications