A visitor fills in the contact form on your website, clicks send and sees a thank-you message. You never hear about it. Or a customer phones to ask why you ignored their enquiry, and when you test the form yourself you get a red error box, or a green success message followed by silence.
On a WordPress site the form itself is rarely the broken part. The broken part is how the website sends email. A form plugin builds the message and hands it to WordPress, WordPress hands it to the web server, and the web server tries to get it into an inbox that has every reason to distrust it. Each handoff can fail without anyone being told. The sections below follow that chain from the website outwards.
Read what the form says after you press send
Submit the form yourself and note the exact response. With Contact Form 7, the plugin's FAQ explains what each colour means, and it narrows the search immediately.
- Green border, 'Thank you for your message. It has been sent.': Contact Form 7 says this means the PHP function for sending mail completed successfully. The mail left the plugin and was lost later. Go to causes one to three.
- Red border, 'There was an error trying to send your message.': sending failed outright. Contact Form 7's advice is to contact your host, who can check the error logs. Start with cause one and cause two.
- Orange border, same wording: the submission was treated as suspected spam and the email was not sent. Contact Form 7 uses one message for both cases on purpose, so look at the border, not the words, and review your spam protection settings.
- WPForms or another plugin shows its confirmation message and nothing arrives: treat it like the green case. A confirmation only tells you the form was submitted, not that the email got anywhere.
Cause 1: The server's PHP mail() isn't delivering
Out of the box, WordPress sends every email, including your form notifications, through PHP's mail() function on the web server. WordPress's own troubleshooting FAQ says that if the server has no working mail setup, the mail will never send. WPForms' notification troubleshooting guide puts it more bluntly: the most common reason for not getting emails is that your hosting server is not configured to use the PHP mail() function, and some web servers do not support the default WordPress mailing function at all.
The trap is that nothing tells you. WordPress's developer documentation for wp_mail says a successful return does not automatically mean the email was received; it only means the request was processed without errors.
The reliable fix is to stop relying on the server and send through a real mailbox instead, using SMTP. WPForms' own docs say: 'To resolve email delivery issues, we recommend using SMTP to send emails in WordPress.'
- Create or choose a mailbox on your own domain, for example the one your email host gave you for website@ or noreply@ your domain.
- Install an SMTP plugin (WPForms' documentation points to its sister plugin, WP Mail SMTP) and enter that mailbox's SMTP server, port and login, or connect your email provider if the plugin supports it.
- Send the plugin's test email to an address at a different provider from your own, and confirm it lands in the inbox, not just that the plugin reports success.
- Then submit your contact form again. Form plugins send through WordPress, so once WordPress uses SMTP, the form does too.
Cause 2: The From address isn't on your domain
Every form plugin lets you set who the notification is 'from', and the tempting choice is the visitor's own address so you can hit reply. That is the setting that gets the most mail dropped. The receiving server sees a message claiming to come from someone@gmail.com that was actually sent by your web host, which is exactly what a forgery looks like. Google's sender guidelines tell senders not to impersonate Gmail From headers, and say Gmail applies a DMARC quarantine policy to them.
WordPress's FAQ makes the same point from the server side: by default WordPress sends as wordpress@ your domain, which is fine, but if you set the From address to something like a Gmail address, the mail may not send, because gmail.com is not a domain your mail server handles.
- Contact Form 7: open the form, go to the 'Mail' tab and put an address on your site's domain in 'From'. If you see the configuration error 'Sender email address does not belong to the site domain.', this is what it is warning about.
- Still in Contact Form 7, add 'Reply-To: [your-email]' on its own line in 'Additional headers', where your-email is the name of the form's email field. Contact Form 7's docs recommend making that field required, because an empty value breaks the header. Header names can't contain spaces, so 'Reply To:' is invalid.
- WPForms: open the form, go to 'Settings' then 'Notifications', and set 'From Email' to an address that matches your website's domain. WPForms' guide says it shouldn't be the same address as 'Send To Email Address', and that only one address belongs in 'From Email'.
- Put the visitor's email field in the notification's Reply-To setting instead, so replying still goes to them.
Cause 3: Your domain doesn't authenticate the mail (SPF and DKIM)
Even with a From address on your domain, mail servers want proof that the server sending it is allowed to. Google's sender guidelines require everyone sending to Gmail accounts, since February 1, 2024, to set up SPF or DKIM for their sending domain, to have valid forward and reverse DNS for the sending server, and to use TLS. For the message to pass DMARC, Google says the domain in the From header must be aligned with either the SPF domain or the DKIM domain. Senders of more than 5,000 messages a day also need DMARC, but a contact form is nowhere near that.
Check what is actually happening rather than guessing. Send a notification to a Gmail address, open it, and click the down arrow below the sender's name. Google's help says an authenticated message shows a 'Mailed by' domain and a 'Signed by' domain, and that a question mark next to the sender's name means the message isn't authenticated. In other mail apps, look for the 'Authentication-Results' header and check for 'spf=pass' or 'dkim=pass'. WordPress's FAQ suggests the same check using its 'Forgot Password' email.
- If you send through SMTP from a mailbox at your email provider, follow that provider's instructions to add its SPF and DKIM records to your domain's DNS.
- If the website sends directly from the web host, ask the host whether SPF and DKIM are set up for that server on your domain. WordPress's FAQ notes there is a fair chance your host chose not to sign with DKIM.
- Google's SPF help says each domain can have only one SPF record, so add a new sender to the existing record rather than creating a second one.
Cause 4: The notification itself is switched off or misrouted
Sometimes the server is fine and the plugin was never asked to send to you. These checks take two minutes.
- WPForms: in 'Settings' then 'Notifications', make sure 'Enable Notifications' is on and each notification shows as active. If a notification uses conditional logic, it only sends when the condition is met.
- WPForms: check 'Send To Email Address' for typos and missing commas between addresses, which its guide lists as a cause of failed delivery.
- WPForms: go to 'WPForms', then 'Settings', the 'Email' tab, and in the 'Sending' section make sure 'Optimize Email Sending' is off, then click 'Save Settings'.
- Contact Form 7: in the 'Mail' tab, check the 'To' field. Note that its configuration validator only checks syntax; it does not send a test, so a clean validator doesn't prove delivery.
Cause 5: It arrived, and a filter moved it
If the authentication check passes and you still see nothing, search your mailbox for the form's subject line across all folders, including spam and archive. Contact Form 7's FAQ names spam filters as a common reason a green-border message never shows up. If you find them in spam, fixing causes two and three is what keeps them out for good; marking one as 'not spam' only teaches your own mailbox.
Prevent it next time: keep a copy that doesn't depend on email
Email will always be the fragile half of a contact form, so make sure every submission is also saved somewhere you can look.
- Contact Form 7 doesn't store submissions on its own. Install its companion plugin Flamingo, which saves them to your database; you'll find them under 'Flamingo' and 'Inbound Messages'. It only saves submissions from the moment it is active.
- WPForms Lite doesn't save entries to your WordPress database. Turn on 'Enable Entry Backups' under 'WPForms', 'Settings', 'General' so Lite Connect backs up new entries. WPForms says backed-up entries are kept for one year and can be restored to your dashboard after upgrading to a paid license.
- After any change to your host, DNS, theme or plugins, submit the form yourself to an address at a different provider and check it arrived.
- Set a monthly reminder to send one test submission. A form that broke quietly in spring is otherwise discovered in autumn, by a customer.
If you'd rather not depend on the email at all
OneSol forms can be embedded on any website, respondents need no account, and every submission lands in your OneSol dashboard as well as your inbox, so a lost email doesn't lose the lead. It's free to start, and file uploads up to 5 MB are supported.