Contact Form 7 emails usually go missing because of how WordPress sends them, not because of the form itself. By default WordPress hands the message to the PHP mail function on your web server, and WP Mail SMTP says that without proper authentication those messages either land in spam or disappear. Below you get a diagnosis checklist ordered from most to least likely cause, the SMTP fix and the DNS records that go with it, the spam-filter trap, a way to keep a copy of every enquiry, and how forms on headless sites sidestep the whole problem.
Why Contact Form 7 emails go missing
Contact Form 7 doesn't send email itself. It builds the message and hands it to WordPress, which sends it with wp_mail(). Out of the box, according to the WP Mail SMTP listing, WordPress uses the PHP mail function for anything generated by WordPress or a contact form plugin. That function sends the message through the server that hosts your site. That server often cannot prove who the mail is really from.
Receiving servers check for that proof. The same listing says Gmail, Yahoo, Office 365 and Zoho check whether mail comes from a genuine sender, and when the authentication isn't there, mail goes to spam or vanishes. It also claims most WordPress hosting companies don't have their servers properly configured for PHP mail. Treat that as a vendor claim, because the vendor sells the fix, and as a common pattern, not as a verdict on any particular host. Plenty of hosts handle mail perfectly well.
The forum evidence points the same way. In a May 2024 support thread, a moderator's read was that WordPress was probably sending emails directly without authentication, and the mail server recognised that and filed them as spam. The person who asked had already changed the From address, marked it as VIP and written a mail rule. Still junk. That tells you something: when your own inbox rules don't help, the fault sits upstream of your inbox.
One more data point. Contact Form 7 shows 10+ million active installations on its WordPress.org listing. Another plugin's listing says more than 5 million, so the sources disagree on the number, but either way it is a large install base. That means the same failure gets reported in a hundred different ways.
Quick checks before you touch anything else
Spend five minutes here before reading a single DNS record.
Read the response message
Contact Form 7's own FAQ is blunt: a red border means the plugin tried to send with wp_mail() and it failed, and you need to find the actual reason. The same page covers the opposite case, a green 'Thank you for your message. It has been sent.' where the mail never arrives. There is also a wrinkle: the default message 'There was an error trying to send your message.' appears both when sending failed for any reason and when spam activity was detected. That sentence alone can't tell you which problem you have.
Check the Mail tab
Open Contact, choose the form, then open the Mail tab. Two fields matter most. The To address must be a mailbox you actually read, with no typo. The From address should use your own domain. A From address that uses the visitor's email looks like forgery to a receiving server, because, technically, it is. Put the visitor's address in a Reply-To header instead, so you can still hit reply.
Look in spam, then think about timing
Check the junk folder of the receiving mailbox, and any filtering rules on it. If the messages are there, you have a deliverability problem rather than a delivery problem. That needs a different fix.
The diagnosis checklist, most likely cause first
- The Mail tab is wrong. Check: To address, From address, a stray typo. Fix: use a real address on your domain in From, and move the visitor's address to Reply-To.
- The message is in junk. Check: spam folder, quarantine, shared-mailbox rules. Fix: if it's there, go to step 4. Marking senders as safe rarely holds for unauthenticated mail.
- The form shows a red border. Check: the response message and Contact Form 7's FAQ entry on it. Fix: this means
wp_mail()failed, so the problem sits with the site's mail setup. Go to step 4. - WordPress is sending by PHP mail with no authentication. Check: are you using an SMTP plugin or a mail service at all? Fix: install one and send a test email (next section).
- DNS records are missing or wrong. Check: SPF, DKIM and DMARC on the sending domain. Fix: add the records your mail provider gives you.
- A spam filter is rejecting real messages. Check: temporarily turn off the captcha or Akismet integration and resubmit. Fix: adjust the integration, don't leave the form unprotected.
- Something else on the site is interfering. Check: switch to a default theme, deactivate other plugins, clear caches. Fix: reactivate one at a time until it breaks again.
- A recent update changed something. Check: your PHP version against the plugin's stated requirement. Fix: see the FAQ below.
Most people stop at step 4. That's usually correct. The checklist is ordered for a reason: don't buy a mail service to fix a typo.
The reliable fix: authenticated sending and DNS records
The reliable repair is to stop using unauthenticated PHP mail. Send through SMTP, or through a transactional email service, a service built for sending automated mail like form notifications, using a plugin such as WP Mail SMTP. Per its listing, the plugin reconfigures wp_mail() to use SMTP host credentials or a mail provider. With the provider integrations it recommends, mail goes via the provider's direct API, which the listing says works even when your web host blocks SMTP ports.
A few honest notes on the plugin:
- Mailer choice. The listing marks SendLayer, SMTP.com and Brevo as recommended. Microsoft One-Click Setup, Amazon SES and Zoho Mail are marked Pro. Gmail SMTP, Mailgun, SendGrid, Postmark and others are in the free list.
- Free allowances. The listing quotes 300 free emails a day for Brevo and up to 100 a day for SendGrid. Those are figures the plugin vendor states, so check each provider's own page before relying on them. A contact form on a small site sends a handful of messages, so limits rarely bite, but you should know where they are.
- Conflict of interest. It's owned and maintained by the team behind WPForms, a competing form builder. That doesn't stop it working with Contact Form 7, and it's what the vendor's own Contact Form 7 article is about. Other SMTP plugins exist if you'd rather not use it.
- Logging is paid. Email logging, resending, alerts and a backup connection are listed as Pro features, a separate paid plugin. The free version sends. It doesn't keep a record.
The setup is small. Pick a mailer, set the From address to one on a domain you control, send the test email from the plugin, then submit your real form. The plugin also runs a domain check: when you send a test email and at the end of the Setup Wizard, it sends the From address, mailer and sending domain off to check the domain's DNS records, and Tools > Site Health shows the last result. Know that if you care where your data goes.
SPF, DKIM and DMARC in plain terms
These are three DNS records, and they're what turns 'sent' into 'trusted'.
- SPF lists which servers are allowed to send mail for your domain.
- DKIM adds a signature to each message, checked against a public key you publish in DNS.
- DMARC tells receiving servers what to do when those checks fail, and where to send reports.
Your mail provider's setup screen gives you the exact records to paste, so I won't invent any here. One practical point: if your domain already has an SPF record, edit it rather than adding a second. The DNS lives wherever your domain's nameservers point, which might be your registrar, your host or a service like Cloudflare. Not sure? Look at the nameservers first. It saves a lot of editing in the wrong dashboard.
Spam filters and false positives
Contact Form 7 can be paired with spam protection such as reCAPTCHA and Akismet. That is sensible, genuinely, a public form with no protection attracts junk quickly. But any filter that scores submissions can score a real one wrongly, and then your enquiry is quietly dropped. Remember the FAQ point from earlier: the same on screen error covers both mail failure and spam detection.
The test is simple. Turn the integration off for a moment, submit a realistic message from a different device, and see if it arrives. If it does, the filter was the problem. Loosen it, don't delete it.
Here are the places a legitimate message can get dropped:
- The captcha scores the visitor as a bot, and the form refuses it
- Akismet marks the message as spam before it reaches the mail step
- A caching or optimisation plugin breaks the script the form needs
- The receiving mailbox filters it after delivery
Sometimes it is none of those. One forum thread describes the error 'Failed to send your message. Please try later or contact the administrator by another method.' with an AJAX status of 200 and reCAPTCHA v3 working. The plugin author, Takayuki Miyoshi, asked for the theme and plugins, suggested switching to the default theme, deactivating other plugins and clearing caches, and noted that a failure logged with SMTP on or off suggests SMTP is unlikely to be the cause. Boring advice. Often the right advice.
Keep a copy of every submission
Most owners learn this too late: email is a notification, not a record. If the mail fails, the enquiry is gone, and the visitor saw a polite 'sent' message. You'll never know.
The fix is to store every submission in the database as well. Plenty of Contact Form 7 add-ons do this. As one example, the Contact Form to Any API plugin lists saving Contact Form 7 submissions to the database, with export to CSV, Excel, PDF and print. It can also send submissions to remote APIs, a CRM, say, by POST or GET, with up to 5 API connections. Its 3.0.6 release, dated 8 July 2026, added email notifications on API request failures and an automatic log cleanup with a default of 90 days.
That last detail is a useful reminder. Stored enquiries are personal data, so decide how long you keep them. A saved entry only helps if somebody opens the list now and then, so put a recurring check in the calendar. The paid WP Mail SMTP Pro log mentioned earlier records sent emails, which is handy, but it isn't the same thing as storing what the visitor submitted.
How headless and static sites handle forms
A static or headless site has no PHP and no wp_mail(). The form posts somewhere else: an endpoint run by a form service such as Formspree, a hosting platform's native form handling, or a serverless function you write. The submission is stored first. Email becomes one notification among several, not the only copy.
Netlify Forms is a clear example. After you enable form detection, adding data-netlify="true" or a netlify attribute to an HTML form lets you receive submissions in the Netlify site admin panel, with no extra API call or JavaScript. A few specifics from the docs:
- Submitting by AJAX needs a URL-encoded body. Netlify Forms does not support JSON form data at this time.
- File uploads allow one file per field, a form request maximum of 8 MB, and a 30-second timeout.
- If your form is rendered by JavaScript or a server framework such as Next.js, you must include an HTML form that meets Netlify's criteria, because its build finds forms by parsing the site's HTML.
Notifications are separate from storage. Per the notifications docs, they can go to email, webhooks or a Slack workspace, for one form or all forms. By default the emails come from formresponses@netlify.com, and replies go to that address unless you add an input named email, which sets the Reply-to value. Same lesson as before: even here, a notification email has quirks you'd want to test.
If you're deciding whether a form setup like this suits your site, the WordPress stack advisor is a quick way to see where your current build sits.
When staying on WordPress is right
For most small business sites, staying put is fine. A contact form is a small feature. If you add authenticated sending, correct DNS records and a stored copy of each entry, WordPress forms are as dependable as anyone else's. Moving platforms to fix a mail problem is like replacing the car because the indicator bulb went. If you're curious about the wider question, there's a piece on leaving WordPress and a roundup of alternatives, but neither is a reason to rush.
FAQ
My SMTP test email works but the form still doesn't send. Why?
That means mail leaves your site fine, so the fault is somewhere between the form and wp_mail(). Forum users report exactly this. One said the SMTP test email was OK but no form sent, and removing the captcha didn't help. Another reported that, after routing mail through WP Mail SMTP, other emails worked but Contact Form 7 didn't deliver on three forms, and the plugin author's first question was where the form sat on the site, see the thread from May 2026. Follow the isolation steps: default theme, other plugins off, caches cleared.
Do I need WP Mail SMTP Pro?
No, not to fix delivery. The free plugin does the sending. Pro is a separate paid plugin that adds email logging, resending, alerts and a backup connection. It's worth considering if you want a record of failures, but a database add-on for the submissions covers the lost lead risk too.
My forms stopped right after an update. Could it be PHP?
Possibly. The plugin listing shows PHP 8.3 or higher as a requirement for version 6.2.3. Two reviewers on the listing say the minimum rose from 7.4 to 8.3 in version 6.2, and one reports an auto update breaking a site that ran PHP 8.0. Those are user reports, not a maintainer statement. Check your PHP version in your hosting control panel, and take a backup before updating anything.
The most useful fact: Contact Form 7 hands mail to WordPress, and WordPress by default sends it unauthenticated through PHP mail, so authenticated SMTP plus correct DNS records fixes the usual case. The sharpest caveat is that email alone is never a record, so store each submission as well. If the fix doesn't work, suspect the form's environment, not the mail server.