A visitor fills in the form, presses the button, sees “Thank you, we will be in touch.” But the request never reaches you. They wait for a call, you wait for clients, and nobody knows that something broke between the site and your inbox.
This is one of the nastiest failures, because from the outside the site looks fine. Below is where requests usually get lost, how to check it yourself, and what to ask the developer for so a loss does not go unnoticed.
Where requests get lost
- The email is sent but lands in spam, because the domain has no SPF, DKIM, and DMARC records
- The email goes to an old mailbox that nobody reads anymore
- The mailbox is full, or the mail service password changed and the site still has the old one
- A captcha or spam filter blocks people along with bots
- On a phone the form looks sent, but the request fails with an error the visitor never sees
- After a CMS or plugin update, the form handler stopped working
Almost none of these are visible to the visitor or the owner. So the form needs checking on a schedule, not “when something seems off.”
Mail from your domain: SPF, DKIM, and DMARC
When a site sends email on behalf of your domain, mail services check whether that server is allowed to. For this, the domain’s DNS holds SPF and DKIM records, and a DMARC record says what to do with messages that fail the check. Without them, a form email easily ends up in spam or does not arrive at all.
It is more reliable to send mail not from the hosting itself but through a mail service or your mailbox’s SMTP, where these records are set up by following their instructions. Ask the developer to show what the mail goes through and that the DNS records are verified.
A second channel
Email as the only path for a request is fragile. It helps when every request also arrives in Telegram: a work chat or a bot that forwards the request text. If email breaks, you still see the message.
Better still is when the request is also saved on the site side: in a database, a spreadsheet, or a CRM. Then even if both channels fail, it can be found and answered. It is a small addition, and it pays for itself with the first lost request you manage to recover.
Spam protection without losing people
Without protection a form quickly fills with junk, and a real request gets lost among ads. But a heavy captcha annoys people and turns some of them away. Quiet measures are usually enough:
- A hidden field that only bots fill in
- A check that the form was not sent a second after the page opened
- A limit on how many submissions one address can make in a short time
- An invisible captcha, if the simple measures are not enough
What the visitor sees
The “Thank you” message should appear only once the server has confirmed it received the request. If sending fails, the person should see a clear error and another way to reach you: a phone number, email, or Telegram. That way a request does not vanish silently.
Keep the fields to a minimum: name, contact, and the task. Every extra required field, especially on a phone, is one more reason to abandon the form.
How to test the form
- Send a test request from a phone on mobile data, not only from a computer
- Check that the email arrived in the inbox, not in spam, across several mail services
- Make sure the request also reached the second channel, if there is one
- Try sending the form with empty and invalid fields and look at the hints
- Repeat the test after every site update, and once a month for no reason
A test request takes a couple of minutes. That is cheaper than learning about the failure from a client who never got an answer.
How to build a landing page people actually leave requests on is covered in the note on landing page structure. A regular form check usually belongs to support after launch. If you want us to look at the form on your site, use the contact form.