Contact Form Spam: Your Receipt Can Send Someone Else's Message
Contact form autoresponder abuse can send visitor text to someone who never visited. Review the first email's content and destination, including its greeting.
Your contact-form autoresponder can send spam to someone who never visited your site if it puts visitor-controlled text into email sent to a supplied address. Contact Form 7 documents the chosen-destination risk; Postmark already describes reflected comments and Name-field abuse.[1][2]
Typing an email address proves neither mailbox ownership nor permission to send arbitrary text. Even a properly validated bot challenge does not establish those things.[3] Before adding another incoming-spam filter, decide what your first outgoing message may say and who can trigger it.
Your receipt can carry more than the Message field
An address and a name can look like bookkeeping. In an outgoing template, they can control different parts of the same message.
Contact Form 7's warning gives a concrete configuration: a visitor-email tag such as [your-email] in To, Cc, or Bcc. The documentation says the tag is replaced by the address the visitor enters, and the template email is sent there.[1]
Now consider what else the template repeats. Under "Don't Accidentally Send Spam," Postmark describes a bot putting spam content into a Name field. A receipt that omits Message can still relay submitted text through its greeting.[2]
_Illustrative path from Contact Form 7 documentation and Postmark advice, not a reproduced email send._[1][2]
This is outgoing email reflection: visitor text and a supplied destination meet in a site-generated message. Ordinary template substitution explains this email reflection attack; sender impersonation and header injection are not required. It is separate from the AI problem of visitor text and instruction authority.
A practical extension is to inspect the subject and every other dynamic string too. Removing the submitted message leaves an incomplete review if another field still supplies outgoing prose.
The evidence here is documentation and Postmark's published account. No installed configuration, live endpoint, provider log, or delivery receipt was inspected, and no email was sent for this article. The diagram is illustrative, not a captured exploit. What, then, does a passed bot challenge establish about those two inputs?
A passed challenge answers a different question
Cloudflare requires server-side Siteverify validation to complete a Turnstile integration. A widget on the page is not the complete check. Its tokens are single-use and valid for 300 seconds.[3] Those are properties of a challenge token, not an email-ownership flow.
Compare that contract with the separate checks in AWS SES guidance. The middle column below paraphrases the documentation; the last column is our analysis of its limits for the same receipt.[3][4]
| Check | Documented assertion or recommendation | Limit for this receipt, our analysis |
|---|---|---|
| Server-validated challenge | Siteverify completes the Turnstile check.[3] | It does not verify ownership of the supplied mailbox. |
| Address syntax and MX checks | AWS recommends checking address format and domain mail records.[4] | A plausible destination does not establish who supplied it or whether its owner wanted this text. |
| Sender-domain authentication | AWS discusses sending-domain authentication and DKIM message integrity.[4] | A genuine sending identity does not authorize the visitor's prose. |
| Confirmed subscription | AWS recommends confirmation before ongoing subscription mail.[4] | That later confirmation cannot establish that the initial send was requested. |
Subscription confirmation creates the awkward case. The recipient must receive a first email before they can click its link.
Double opt-in still needs a first email
A rule against every first email to an unverified address would make double opt-in impossible. AWS explicitly recommends sending a confirmation link when someone signs up and withholding subsequent subscription mail until they click it.[4] A contact receipt and a subscription confirmation serve different jobs, but both face a first send before a recipient response.
That is the strongest objection to a blanket ban. The narrower rule is to decline unrestricted content relay, not every necessary first email.
Read AWS beside Contact Form 7. One describes an initial confirmation; the other advises avoiding arbitrary-recipient configurations unless necessary.[1][4] These positions are compatible when necessity and message content get separate decisions. Keeping a useful confirmation does not require letting an anonymous visitor choose its prose.
The timing yields an important limit. The click can gate ongoing subscription mail; it cannot retroactively establish that the mailbox owner requested the initial email. That is reasoning from the documented sequence, not a measured failure of double opt-in.[4]
Consider a hypothetical first confirmation with fixed site-written wording and a site-generated confirmation link. Here, "fixed content" means no copied visitor prose. The link can vary. Removing the submitted Name from the greeting, along with other copied text, restricts what a visitor can make that template say. It does not show that the destination was entered by its owner. This example explains the proposed restriction; it was not tested.
_Analysis of AWS guidance: confirmation gates ongoing subscription mail; the initial send still needs its own policy._[4][1]
A mistyped or maliciously supplied address can still get an unwanted initial message. Repeated triggering remains a separate risk even if each message contains only the site's words. That residual risk follows from the destination rule; it is not an observed result here.[1]
A necessary fixed-content first message with correctly verified bot controls may be proportionate for a small site. Retain monitoring and proportionate rate controls as additional recommendations, not evidence that abuse has been eliminated.[1][2] The remaining decision is about this particular receipt: is email needed, and what can the visitor make it do?
Choose the first message before adding another filter
Contact Form 7's necessity warning and AWS's caution about unchecked user-defined input point toward a review of the outgoing message itself.[1][4] Start your contact form email security review with the first message's destination rule and complete template. This is a practical recommendation from the comparison, not a tested prevention method.
If the only job is to acknowledge submission, consider an on-page response without email. You lose the inbox copy but avoid that optional outgoing send. If email is necessary, prefer site-written content without copied visitor prose, accepting less personalization and the remaining unwanted-trigger risk. An authenticated workflow with a verified recipient and defined permission is a different option where the task allows it, with extra friction and implementation work.
Keep form completion and friction separate from outgoing-mail permission. A Name may earn its place on the form without earning a place in the receipt.
Before approving an initial template, review its local rendering and ask:
- Where do To, Cc, and Bcc get their values?
- Which parts of the greeting, subject, body, or less-visible template branches include visitor text?
- Who watches repeated sends and provider abuse signals?
Make the follow-up someone's job. The related discussion of who owns the next site issue addresses that handoff.
This review is best suited to anonymous forms with optional receipts or first-contact email. If a form sends only to a fixed, controlled internal destination, it lacks this same arbitrary-third-party path. Forwarding and later handling remain outside that conclusion. This is not a full antispam design, a platform security verdict, or a legal consent assessment. A static template is not global safety proof.
Send this explanation to whoever maintains your form email so you can decide which submitted fields the receipt should repeat.
References
- Takayuki Miyoshi, Contact Form 7, "Unsafe email config is used without sufficient protection." Inspected 2026-10-25; page publication/update date not established. Documents visitor-email substitution in To, Cc and Bcc, and the limits of spam-protection modules. No installed configuration was inspected. https://contactform7.com/configuration-errors/unsafe-email-without-protection/
- Jordan Dibb, Postmark, "When Spambots Attack: Protecting Your Forms From Abuse" (published 2020-01-29, updated 2022-03-16; inspected 2026-10-25). "Don't Accidentally Send Spam" describes reflected form content and a Name-field example. Published provider account, not a raw submission or delivery record independently inspected here. https://postmarkapp.com/blog/when-spambots-attack-protecting-your-forms-from-abuse
- Cloudflare, "Validate the token," Turnstile documentation (displayed update 2026-10-22; inspected 2026-10-25). Server-side Siteverify requirement and single-use, 300-second tokens. The displayed update is not evidence of a newly introduced requirement or a measured protection rate. https://developers.cloudflare.com/turnstile/get-started/server-side-validation/
- Amazon Web Services, "Maintaining a positive sender reputation," Amazon SES Developer Guide. Inspected 2026-10-25; page publication/update date not established. "Authentication" and "Building and maintaining your lists" cover sender authentication, address checks, double opt-in and caution about unchecked user-defined input. Guidance, not a prevention guarantee. https://docs.aws.amazon.com/ses/latest/dg/tips-and-best-practices.html