"We haven't had an enquiry in three weeks"
A client calls. Their enquiries from the website have dried up. The developer submits the contact form and it says thank you. The email never arrives. The site was sending through the server's own mail function, and the client's email provider has started rejecting or spam-foldering messages that do not pass authentication checks.
The developer fixes it by moving the site to a proper sending service. Then she wonders how many other client sites send email the same way. Nobody knows. There is no way to tell, short of testing every form on every site by hand.
Why forms fail silently
- Many sites send mail through the web server, which receiving providers increasingly distrust.
- Mail authentication records for the client's domain are set by whoever manages their DNS, and they change.
- The form plugin shows a success message whether or not the email arrives.
- Clients do not know how many enquiries to expect, so a quiet spell does not alarm them.
- Hosting moves, plugin updates and changes at the client's email provider can all break delivery.
A contact form that shows a thank-you message is not proof that anyone received the enquiry. Most monitoring only checks that the page loads.
What lost enquiries cost
The client loses leads, which is the main reason they paid for a website. The agency's reputation suffers, even when the cause was a DNS change made by someone else. Fixing it after weeks of lost enquiries is a hard conversation, and the enquiries that were lost cannot be recovered unless they were stored somewhere.
The form monitoring we build
- Every form on your client sites is listed with where it should deliver.
- Forms are moved to a transactional email service, such as Postmark, SendGrid or Mailgun, or to the client's Microsoft 365 or Google Workspace through proper authenticated sending.
- Each form stores a copy of every submission in the site database or a central store, so nothing is lost even if email fails.
- A scheduled test submits each form with a clearly marked test entry and checks it arrives at a monitored mailbox, and that the real delivery was accepted by the sending service.
- Mail authentication records for each client domain are checked regularly, and changes are flagged.
- Bounces and rejections reported by the sending service are collected per site.
- Any failure alerts the developer responsible for the site, with the reason where known.
| Failure | How it is caught |
|---|---|
| Mail rejected by the receiving provider | Bounce reported by the sending service |
| Authentication records changed | Scheduled DNS check |
| Plugin update broke the form | Scheduled test submission fails |
| Email arriving in spam | Test mailbox placement check |
| Everything else | Stored submissions mean nothing is lost |
Test submissions are marked so the client can filter them out. You decide how often to test each site.
When a form breaks now
A client's IT company changes their DNS and removes a mail record. The next morning's test fails for that site, and the developer gets an alert saying authentication is failing. She sends the IT company the right record. The client never misses an enquiry, because the submissions in between were stored and forwarded once delivery was fixed.
Could your client forms be failing now?
- Client sites send form emails through the web server's own mail function.
- You have no way to know if a form stopped delivering.
- Form submissions are not stored anywhere except email.
- Clients have reported quiet spells that turned out to be broken forms.
- DNS for client domains is managed by other people.