Your contact form sends mail

In a weekly check-in this week, a client mentioned in passing that their website contact form had been used by someone outside the company to send email. The sender address in those messages belonged to an unrelated construction firm. Nobody had broken into anything. Someone had filled in a form, and the form had done what forms on that kind of site do: it sent a message, from the client's domain, to an address it was given.

Nobody thinks of it as a sending system

A contact form is filed under "website". It was set up by whoever built the site, it has a plugin name, and its job, as everyone understands it, is to receive. But almost every form of this kind also sends: a notification to the team, and very often a confirmation copy to the address the visitor typed in — "thank you for your message, here is what you wrote".

That second mail is the problem. It goes out from the company's own domain, carries the company's own authentication, and is addressed to whatever was entered in the email field. Its body contains whatever was entered in the message field. From the outside, that is an open relay with a rate limit of "however often someone clicks submit".

In this case the precise mechanism is still being looked at, and I will not guess at it here. The pattern does not depend on it. Either the form sends a copy to an address a stranger chooses, or it takes a stranger's address and puts it somewhere a mail program treats as authoritative. Both turn a receiving tool into a sending one.

What it costs, and who pays

The direct damage is small and diffuse: a few messages that someone did not ask for, in the name of a company they have never heard of. The indirect damage lands on the domain. Mail providers judge a sender by what it sends. A domain that has spent months building a clean reputation for newsletters, event invitations and customer mail now also sends messages that recipients mark as spam, and it does so with valid signatures, so there is no way for a filter to tell the two apart.

There is a second, quieter cost. The third party whose address was used will see bounces, complaints or confused replies, and the only name in the headers is yours.

I had the same field in my own product

Looking at this made me reread the checkout of my own visibility scan, which I had hardened two days earlier for different reasons. The fields there — company name, category, domain, a list of brand keywords — all end up somewhere downstream: in prompts to AI providers, in the report, in alerts, and in the subject lines of customer emails. Until that week they went there unshortened and unchecked.

Two of the things that had actually happened: a pasted URL in the domain field produced a wrong report, because the tool compared against a string that could never match. And an email address typed into the domain field ended up, unredacted, in the server's logs. Neither was an attack. Both were a field doing something nobody had decided it should do.

The repair was plain: limits per field, the domain normalised and refused if it contains an at-sign, whitespace or control characters, and every value that reaches a mail header cleaned again at that point, because older records written before the check still exist.

What to check on your own site

• List every form that triggers an email, including the ones in plugins nobody has opened since launch.
• For each one, find out who receives mail. If the answer includes "the address the visitor typed in", switch that copy off or make sure the visitor has to confirm before anything else is sent there.
• Never let a form field become the sender. The sender is always your address; the visitor's address belongs in a reply-to header at most, and only after it has been validated.
• Put a rate limit on the form itself, not only on the mail system behind it.
• Look at a sample of what the form sent last month. Not what was submitted — what went out.