A website contact form does not email you on the visitor's behalf. When someone presses Send, the form builds a notification and your web server or website builder sends it, from its own address, to the recipient address in the form's settings. It goes wrong in three places: the receiving server does not trust that sender and junks or refuses it, spam buries it, or it lands in a shared mailbox where nobody treats it as theirs. The form's "message sent" screen tells you about none of these.
The short version
- Your website sends the notification, not the visitor. On WordPress it goes through wp_mail(), and WordPress says a true return value "does not automatically mean that the user received the email successfully".
- Receiving servers check three published records. SPF lists the servers allowed to send for your domain (RFC 7208), DKIM lets the domain "claim some responsibility for a message" with a signature (RFC 6376), and DMARC checks that one of them aligns with the domain in the visible From line (RFC 9989). Google requires SPF or DKIM from all senders to Gmail.
- Your domain belongs in From, the visitor in Reply-To. A notification "from" the visitor's address, sent by your web host, looks spoofed. Reply-To "indicates the address(es) to which the author of the message suggests that replies be sent" (RFC 5322), so pressing Reply still reaches them.
- A CAPTCHA tests the visitor, not the message. A polished sales pitch typed by a person, or by a tool driving a real browser, passes. The W3C notes that interactive challenges exclude many disabled people, and advises: "if a honeypot suffices, use a honeypot" (Inaccessibility of CAPTCHA).
- A shared info@ spreads responsibility until nobody holds it. Leavers' mailboxes, holidays, old forwarding rules and spam all hide enquiries without producing an error. Give each form one named owner and a fallback.
Where to start
- How form notifications are sent, and why they get rejected explains who really sends the notification and why receiving servers reject it.
- CAPTCHA on contact forms: is reCAPTCHA enough? covers what CAPTCHAs measure, what they cost real visitors and when one is worth it.
- Contact Form 7: what reCAPTCHA and Akismet actually cost you goes through each anti-spam layer in the plugin, in the order worth setting them up.
- Who should receive your website enquiries? Routing without info@ sets out how to give each form a named owner and cover absences.
- Contact form spam across client sites — an agency playbook turns the above into one process across many client sites.
Terms used here
- SPF: a DNS record listing the servers allowed to send mail for a domain.
- DKIM: a cryptographic signature on a message, checked against a public key the domain publishes in DNS.
- DMARC: a DNS record requiring SPF or DKIM to align with the visible From domain, and saying what to do with mail that fails.
- Reply-To: the header that decides where a reply goes.
- Honeypot: a form field hidden from people; a script that fills it in marks its own submission as automated.
- Recipient address: where a form emails its submissions, such as Mail → To in Contact Form 7 or Settings → Notifications → Send To Email Address in WPForms. Pointing it at a filtering service such as Humainbox needs no change to the site's code.
Related on this site
- Not receiving contact form submissions: what to check when nothing arrives.
- Contact form emails going to spam: the usual causes when notifications land in junk.
- Stop contact form spam without a CAPTCHA: cheap layers that cost genuine visitors nothing.
- Integrations: where each form builder keeps its recipient address.
- AI-written spam: why fluent messages pass filters built for crude spam.
Sources
- wp_mail() function reference, WordPress Developer Resources
- RFC 7208: Sender Policy Framework (SPF), IETF
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures, IETF
- RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), IETF
- RFC 5322: Internet Message Format, IETF
- Email sender guidelines, Google Gmail Help
- Inaccessibility of CAPTCHA, W3C