Contact forms that send email: preventing spam and abuse

Rule 3: clean every value that touches a header#

• Reject or strip carriage returns and line feeds from any field that goes into a header: name, subject, email.
• Use your email library's functions to set headers, which should refuse line breaks, instead of building the message by string concatenation.
• Validate the address format, with a modest length limit. See signup email validation.
• Escape the message body before inserting it into HTML. Prefer a plain-text email for form submissions.

Rule 4: slow down the bots#

Combine a few cheap measures.

• Rate limit by IP address and by a session or cookie, for example a handful of submissions per hour. Return a clear error when exceeded. See handling 429 and rate limits for the client side of the same idea.
• A honeypot field. Add a field hidden from people with CSS and give it an attractive name such as website. Bots fill it in and humans do not. Drop those submissions silently.
• A timing check. A form submitted within a second of loading was filled in by a program. Store a signed timestamp in the form and compare.
• A challenge. If bots still get through, add a CAPTCHA or an invisible challenge service. Choose one that works for people with disabilities, and test it on a phone.
• Block obvious abuse. Reject messages with many links, known spam phrases or oversized bodies.

Start with the cheap ones. Add a challenge only if the problem justifies the friction.

Rule 5: be careful with confirmations#

An automatic "Thanks, we got your message" email to the submitter is friendly, and it is also the easiest way to be used as a backscatter cannon.

• Prefer showing a confirmation on the page instead of sending an email.
• If you send one, send it only after the bot checks pass, limit it to one per address per day and include the text of nothing the visitor wrote.
• Never include a link or content that a visitor controls.
• Do not send confirmations to addresses that bounced before. See hard vs soft bounces.

Rule 6: keep the form off the main sending path#

Give form mail its own sending identity.

• Use a separate address, and ideally a separate subdomain or API key, so that abuse cannot damage your product mail. See a sending subdomain strategy.
• Use an API key with the narrowest scope, and keep it out of the browser. See email API key security.
• Set low daily limits for the form's sender, so abuse hits a ceiling.
• Queue messages and handle failures asynchronously, so a mail outage does not lose submissions or slow the page.

Monitor and alert#

• Count submissions per hour and alert on spikes.
• Log accepted and rejected submissions with the reason, not the full content.
• Watch bounces and complaints for the form's sender.
• Review a sample of what arrives. New bot patterns show up there first.

Privacy and retention#

A form stores personal data: names, addresses and whatever people type. Say how you use it, keep it only as long as needed and delete old submissions. Do not log message bodies in places that many people can read.

Testing checklist#

• The recipient cannot be changed from the client
• A name containing a line break and Bcc: does not add a header
• The visitor's address is in Reply-To, not From
• A hundred rapid submissions are rate limited
• A filled honeypot is dropped
• Confirmation emails cannot be used against a third party
• Alerts fire on a spike

Key takeaways#

• A contact form is an internet-facing email endpoint and needs the same care as an API.
• Fix the recipient on the server, send from your own domain and put the visitor in Reply-To.
• Strip line breaks from anything that enters a header.
• Use rate limits, a honeypot and timing checks before a CAPTCHA.
• Be cautious with confirmations and separate form mail from your product's sending.