Someone fills out your contact form, gets the green “Thank you for your message” confirmation, and then... nothing shows up in your inbox. Not in spam, not anywhere. Contact Form 7 (CF7) is one of the most popular WordPress form plugins precisely because it's lightweight — but that lightness comes at a cost: it hands the email off to PHP's mail() function and basically forgets about it. If that handoff fails silently, you never find out unless you go looking.
Symptom: The Form Reports Success, But No Email Arrives
This is the confusing part. CF7 shows the success message almost every time, even when the email was never delivered. That's because CF7's confirmation just means the plugin handed the message to WordPress's mail function without an immediate PHP error — it doesn't mean the receiving mail server actually accepted or delivered it.
Common variations of this symptom:
- Emails worked for months, then stopped after a plugin or theme update
- Emails only fail for certain domains (Gmail works, your business Outlook doesn't, or vice versa)
- You get a red error banner instead of the green success message
- Test submissions from the admin's own email work, but real visitor submissions don't
Cause: Where the Message Actually Breaks
Almost every CF7 delivery failure comes from one of these four places:
| Cause | What's happening |
|---|---|
| From/Sender mismatch | CF7's default sender field uses the visitor's own email or a made-up address on your domain. Receiving servers see this as spoofing and drop it. |
| No SPF/DKIM alignment | PHP mail() sends as your domain, but SPF/DKIM either isn't set up or doesn't match the sending server, so it gets flagged as forged. |
| Exim rejecting the message | cPanel's mail server (Exim) can reject mail at the SMTP level for rate limits, missing PTR, or suspicious headers, before it even reaches spam. |
| Broken mail tags | A form field name doesn't match the mail tag in the Mail panel, so a placeholder like [your-email] gets sent literally, or the To field ends up malformed. |
Fix #1 — Check the Mail Tab for Mismatched Tags First
Before touching server config, rule out the simplest cause. In Contact > Edit Form > Mail, every tag in brackets like [your-name] or [your-email] must exactly match a field name from the Form tab. If you renamed a field (say, from your-email to email-address) but forgot to update the Mail tab, CF7 sends the literal text [your-email] instead of the visitor's actual address — and depending on your setup, that malformed header can cause the whole send to fail.
Also check the Sender field. If it's still set to the default pattern of the visitor's own name and address, that's a visitor-controlled email pretending to be the sender — a classic spoofing pattern that many mail servers now silently drop. Change it to something on your own domain, like WordPress <wordpress@yourdomain.com>, and put the visitor's address in Additional Headers as a Reply-To instead:
Reply-To: [your-name] <[your-email]>Fix #2 — Confirm Mail Is Actually Leaving the Server
If the Mail tab looks fine, the next step is to find out whether the message ever left your hosting account. In cPanel, go to Email > Track Delivery and search for the recipient address around the time of a test submission. You'll see one of three outcomes:
- Delivered — the message left fine; the problem is on the receiving end (spam filtering, a full mailbox, or a typo'd address)
- Deferred or failed with an SPF/DKIM reason — your domain's authentication doesn't match the sending server
- Nothing shows up at all — WordPress never handed the message to Exim, which usually points back to the plugin config or a PHP error
If nothing shows up in Track Delivery, add this temporarily to your active theme's functions.php to catch PHP mail errors CF7 usually swallows:
add_action( 'wp_mail_failed', function( $error ) {
error_log( 'CF7 mail failed: ' . $error->get_error_message() );
});Then check your site's PHP error log (in cPanel under Metrics > Errors) after a failed test.
Fix #3 — Stop Fighting PHP mail() and Route Through SMTP
The most reliable long-term fix is to stop using PHP's raw mail() function entirely and send through an authenticated SMTP connection instead — either your own cPanel mailbox or a transactional service like SendGrid or Amazon SES. Install WP Mail SMTP (or a similar plugin), point it at your mail server's SMTP credentials, and CF7 will automatically route through it since it uses the same wp_mail() pipeline underneath. This single change resolves the majority of delivery tickets, because the mail now goes out authenticated and aligned with your domain's SPF/DKIM records instead of relying on the server's default mail() behavior.
Typical cPanel SMTP settings for WP Mail SMTP:
| Setting | Value |
|---|---|
| SMTP Host | mail.yourdomain.com (or your server's hostname) |
| Port | 465 (SSL) or 587 (TLS) |
| Authentication | Yes — full mailbox address plus password |
| From Email | an address that actually exists in cPanel > Email Accounts |
Fix #4 — Install Flamingo So You Stop Losing Submissions
While you're fixing delivery, add the free Flamingo plugin (by the same author as CF7). It logs every submission inside wp-admin regardless of whether the email sends successfully. That way, even if mail breaks again in the future, you're not losing leads — you can see and export them from Flamingo > Inbound Messages while you troubleshoot.
Prevention
- Set up SPF, DKIM, and DMARC for your domain properly and keep them aligned with whatever actually sends your mail
- Never use a visitor-supplied address in the Sender/From field — always send from your own domain and put the visitor's address in Reply-To
- Keep Flamingo (or a similar logger) active permanently as a safety net
- Test the form after every CF7, theme, or SMTP plugin update — a routine WordPress update is a common trigger for this breaking again
- Periodically check cPanel > Track Delivery for silent bounces, especially if you rely on the form for sales leads
Frequently Asked Questions
Why does Contact Form 7 show a success message even when the email fails?
CF7's success message only confirms that PHP accepted the send request without throwing an immediate error — it has no way to know whether the receiving mail server actually accepted or delivered the message afterward.
Do I need a paid SMTP service, or can I use my cPanel email account?
Your existing cPanel mailbox works fine as an SMTP source for low-to-moderate volume forms. Move to a transactional service like SendGrid or SES only if you're sending high volumes or seeing rate-limit blocks from Exim.
I updated the plugin and now the form doesn't send at all. What changed?
Check the Mail tab first — plugin updates occasionally reset custom mail tag configurations or the Additional Headers field back toward defaults, breaking a custom Reply-To or Sender setup you had working before.
Can hosting-level firewalls or spam filters block CF7 emails?
Not directly, but ModSecurity or aggressive mail rate limits on shared hosting can interfere if a form gets spammed by bots. If legitimate submissions started failing during a spam wave, check cPanel's email send limits and add reCAPTCHA to the form to cut down bot traffic.
Is Flamingo a replacement for fixing email delivery?
No — it's a safety net that stores submissions in the database so you don't lose leads while delivery is broken, but you should still fix the underlying SMTP/authentication issue so you get real-time email notifications again.
