It said “thanks”.
Nothing arrived.
A success message only proves one thing: your form handler accepted the submission and told the browser so. It is not evidence that an email was sent, that it was accepted by a mail server, or that it reached anyone. Those steps happen after the visitor's browser has finished, and they fail quietly.
So start by finding out whether the submission exists at all. If your form tool has a record of it, the form is fine and you have a mail problem — and mail problems are usually authentication, not spam. Work down the chain below in order.
Last updated 22 sep 2026 · Technical guidance, not a compatibility guarantee.
7 days free, then from $29/month. A payment method is required and $0 is charged today. Cancel before the trial ends and pay nothing.
The browser's job ends long before the email does.
Almost every confusing version of this problem comes from treating one chain as if it were two separate things, or two chains as if they were one. It is worth being precise about where the handover happens.
In the browser
The visitor clicks submit, the page validates the fields, a request goes to your form handler, and the handler answers. If that answer is a success, the page shows a thank-you message. Everything a script on your page can observe ends here.
After the browser
Your handler stores the entry and asks a mail server to send a notification. That server may accept it and then discard it, defer it, bounce it to an unmonitored address, or deliver it to a folder nobody opens. None of this is visible from the page, and the visitor was told it worked several seconds earlier.
Follow the message, in the order it travels.
Each step has a place you can look and a definite answer. Stop at the first one that is missing — that is where the message was lost, and checking the later steps will only confuse the picture.
Check whether the submission was stored
Most form tools keep their own record of every entry, separately from the email they send. Open that list first. If your submission is there, the form worked and you have a mail delivery problem — skip straight to the mail checks. If it is not there, the message never reached your form handler, and this is really a broken-submit problem instead.
Check the sending address, not just the recipient
Most silent mail loss comes from the from address. If your form sends as something like wordpress@yourdomain.com, receiving mail servers check whether your domain authorises that sender using SPF, DKIM and DMARC records. When it does not, well-run mail providers discard the message without a bounce and without putting it in spam. Nothing appears anywhere. Sending through a proper transactional mail provider, with those records set up, removes this entire category.
Read the mail provider's own log
If the form sends through a mail service, its dashboard will show accepted, delivered, deferred, bounced or dropped for every message. This is the single most decisive check on this page, because it tells you whether the problem is before or after your site. A message that never appears in that log was never handed over.
Check spam, and then the rules you forgot
Look in spam and quarantine for the exact recipient address. Then check forwarding rules, aliases and distribution lists — a shared address like info@ often forwards somewhere else, and forwarding frequently breaks the authentication checks above. Group mailboxes are also where a filter someone set up years ago quietly files enquiries away.
Check the CRM or automation step
If the form hands off to a CRM, helpdesk or automation tool, the handoff can fail on its own — a rotated API key, an expired connection, a required field the form stopped sending, or a plan limit reached. The form still reports success to the visitor, because from the browser's point of view the submission was accepted.
SiteAirbag cannot tell you that an email arrived.
This is the most common version of “my form is broken”, and it is mostly not a problem this product solves. Saying otherwise would be the easiest sale on this website and the fastest way to lose the customer afterwards.
What it observes
SiteAirbag runs in the visitor's browser. It sees the interaction, structural changes on the page, navigation, and the method, path, status and duration of requests — never their contents. When your form handler answers with a success, that is what it sees too.
What that means here
If the submission reached your handler and the handler said yes, SiteAirbag will correctly judge that run as a success — even if the notification email is later discarded. It has no visibility into your mail server, your spam filter or your CRM, and it never will from inside a browser.
What to use instead
For this symptom you want delivery-side evidence: a transactional mail provider with proper SPF, DKIM and DMARC records and a searchable log, or a monitor that checks an actual mailbox for receipt. Several form-monitoring products do exactly that, and for this problem they are the right tool.
Where SiteAirbag does help
The other half. When a submission never reaches your handler at all — blocked script, rejected request, failed validation, a confirmation that never renders — the visitor is still standing on the page, and a backup route can still catch the enquiry. How that works.
This one is worth getting right before you buy more traffic.
A form that accepts submissions and loses them downstream will pass every browser check, including ours. Fix the delivery chain first, then protect the part that happens in the visitor's browser.