Why Real Form Submissions Get Marked as Spam (and How to Get Them Back)

Check the spam folder first, then check whether the verdict was about the message or about the sender. Message-based false positives (links, keywords, a short body) are a tuning problem you can fix in a setting. Sender-based ones — where the filter has decided your address or your visitor's address is untrustworthy — keep firing no matter what the message says, and they are the ones that quietly eat real enquiries for weeks.

Full disclosure: ShipMyForm is our product, and the second half describes a bug we shipped and fixed in October 2026. The failure modes in the first half apply to any filtered form on any backend.

The number nobody measures

Every form backend advertises how much spam it caught. None of them advertise how much real mail they ate, because neither they nor you can see it without looking.

The asymmetry is the whole problem. A spam message that reaches you costs a few seconds of annoyance, and you know it happened. A quote request that silently went to the spam folder can cost you the customer, and you never find out. One is visible and cheap; the other is invisible and expensive. Yet almost all filter tuning optimises the visible one.

So before changing any setting, do the thing almost nobody does: open your spam folder and read a week of it. Sort every item into "should have reached me" and "correctly caught". That ratio is the only number that tells you whether your filter is set correctly, and most people have never calculated it.

Why testing your own form is the worst case

If you are reading this because your own test submission went to spam, that is not a coincidence. Testing is close to the hardest thing for a filter to get right, for three reasons that compound.

A test message carries no information. Real enquiries have a subject, a request, specifics. Tests say "test", "asdf", "hello". A content classifier scores by what the text tells it, and these tell it nothing, so they land in the uncertain middle where the filter has to guess.

Testing looks mechanical. Many filters treat a submission sent within a second or two of the page loading as automated, because that is what a bot does. It is also what you do when you reload the page, paste a value and hit submit. On some systems — ours included — that is treated as near-certain evidence of a bot.

And then the verdict can stick to you. This is the part that turns an annoyance into a real problem. Filters that track sender reputation record the verdict against the address and IP that sent it. A handful of tests judged as spam become a handful of votes against you. Cross the threshold and the filter stops reading your messages at all — it recognises the sender and files them.

A bug we shipped, and what it teaches

In October 2026 a customer told us that real enquiries to their contact form were landing in spam — including one from the person who built the form. They had turned their spam filtering down to the lowest setting to make their form usable at all, which is a workaround, not a fix.

The cause was a mismatch between two correct-looking pieces of code. Our classifier marks a sender as untrustworthy only when two independent sites have seen them misbehave — a sensible rule, designed so that one site cannot blacklist a sender for everyone else. But we issue the classifier one key per form, not per customer. A customer with eight forms was eight "independent sites" as far as that rule was concerned.

So a person wiring up their own forms would test two of them, trip the fast-submission rule both times, and in doing so provide the "two independent sites agree" corroboration — about themselves. After five such observations their address was filtered on identity alone, on every form they owned, with the content no longer read at all.

There was a second-order effect that made it worse. A reputation verdict scores very high, and our rule for adding a message to the known-spam fingerprint index only excluded verdicts based on metadata. Reputation was not on that list. So a legitimate "please schedule a call" message, filtered because of who sent it, was filed as known spam content — and then the same ordinary wording from anyone, on any customer's form, matched it.

The fixes were small once the cause was clear: count distinct customers rather than distinct keys, add reputation to the list of verdicts that must never index the message text, and never filter a submission from a verified member of the form's own account. The last one is the general lesson, and it is not specific to us:

Filtering exists to protect an owner's inbox from strangers. The owner is not a stranger.

What to check, in order

If real submissions are being filtered, work through these before changing a threshold.

1. Read the spam folder. Establish whether you have a false-positive problem at all, and how big. Everything else is guesswork until you have.

2. Find out why each one was filtered. A good backend tells you. If yours gives you a score and nothing else, you cannot distinguish the fixable causes from the structural ones, and that is worth knowing about your backend.

3. Separate message-based from sender-based. Keywords, link counts and message length are message-based: a setting change fixes them. Reputation, rate and duplicate detection are sender-based: they need the record cleared, not the dial turned.

4. Check your own blocklist. An old entry — a keyword that is now a legitimate industry term, a domain you blocked during an attack — catches real mail silently and forever. This is the most common self-inflicted cause and the easiest to miss.

5. Mark things "not spam", then verify it changed anything. Ask your provider whether corrections are fed back as training signal or merely move the row. If corrections do nothing, a recurring false positive recurs forever.

6. Only then, loosen the filter. And prefer a setting that flags rather than hides. A flagged submission still reaches you and lets you judge; a hidden one relies on you remembering to check.

Choose the failure you can afford

The useful question is not "how strict should my filter be" but "which mistake can I live with".

For a high-volume form where spam is genuinely unmanageable, a strict filter and a weekly spam-folder review is reasonable. For most small sites — a consultancy, a restaurant, a conference registration page — the arithmetic runs the other way. A dozen spam messages a week cost a minute. One missed enquiry costs a customer, and it costs it silently.

That asymmetry is why we think a filter should be able to be turned down, and why the loosest setting still leaves the defences that have no false positives — a hidden field no human ever fills, rate limits that stop floods — switched on. Those protect you without ever being wrong about a real person. Thresholds and classifiers are judgement calls, and judgement calls are yours to make.

If you want to see how ours behaves before trusting it with anything, send a few real submissions through a form and read the spam folder honestly. That is the same advice we would give about any backend, including the ones we compete with.