Contact Form 7 not sending email — the green checkmark that means nothing

The form submits. The green message appears. The email never arrives. Before you start disabling plugins, understand what that green message actually certifies — because the answer explains the entire problem, and it comes from CF7's own documentation.

What the green border actually means

Contact Form 7 sends mail through WordPress's wp_mail() function. The green success message means exactly one thing: that function returned true. WordPress core is unusually candid about what that is worth:

"A true return value does not automatically mean that the user received the email successfully. It just only means that the method used was able to process the request without any errors."WordPress developer reference, wp_mail()

And CF7's own FAQ, answering "I see a green border response but I never receive a mail", is even more direct:

"Showing the green border message means that the PHP function for sending the mail has certainly completed successfully. So if you can't receive the mail, it's highly possible that the mail has been kidnapped or killed after that… Spam filter often causes this kind of problem."contactform7.com FAQ

Kidnapped or killed. That is the plugin author telling you, in writing, that the success message covers only the first link of a chain with at least four links in it. Everything after the handoff is invisible to CF7 — and therefore to you.

Where the chain actually breaks

1. No SMTP — the mail is unauthenticated

By default wp_mail() ends up calling PHP's mail(), which hands the message to the mail transport on your web host. That message carries no SPF alignment, no DKIM signature, and comes from a shared hosting IP with an unknown reputation. Gmail and Outlook increasingly treat that as spam — or drop it outright, without a bounce. From the site's perspective, everything succeeded.

2. The From address doesn't belong to your domain

An old and very persistent tutorial habit: putting [your-email] in the From field on the Mail tab, so replies "come from the visitor". To a receiving mail server that is a domain you do not own, sending from an IP you do not own — textbook spoofing. Modern CF7 flags this itself as a configuration error ("Sender email address does not belong to the site domain"), and its documentation is explicit that the From address should belong to the same domain as the web site. The visitor's address belongs in Reply-To, not From.

3. The host disabled or throttled mail()

Many hosts disable the PHP mail function entirely, or cap outbound mail, specifically to stop compromised sites from spamming. CF7 will show a red border if wp_mail() returns false — but a throttled or silently discarded message can still return true.

4. Anti-spam ate the submission — and you can't tell

This one is genuinely tricky. If Akismet, reCAPTCHA or the disallowed-words list rejects a submission, CF7 shows an orange border. But here is the design decision, stated openly in their FAQ: CF7 deliberately uses the same message for a mail failure and for a spam rejection, on the reasoning that you should not tell a spammer they have been detected.

Sensible for spam. Terrible for you: from the front end, "your mail configuration is broken" and "our anti-spam is silently eating real client leads" look identical. reCAPTCHA v3, in particular, scores submissions invisibly — a badly tuned threshold will quietly reject real humans forever.

5. It arrived — in the spam folder

The most common ending, and the hardest to prove. The email was delivered to the recipient's server, accepted, filtered, and dropped into Junk, where nobody looks. Every log in your stack says "sent". The client says "we get no enquiries".

The fix, in order

1. Install an SMTP plugin and authenticate properly. Send through a real mail service with SPF, DKIM and DMARC aligned to your domain. This single change fixes the majority of cases.
2. Put your own domain in the From field. [e-mail], not the visitor's address. Visitor goes in Reply-To.
3. Install Flamingo. CF7 states plainly that it "doesn't store submitted messages anywhere. Therefore, you may lose important messages forever". Flamingo (same author) saves submissions to the database. It does not fix delivery — but it converts a permanently lost lead into a lead you can still find.
4. Turn on spam logging to find out whether anti-spam is the one rejecting your submissions, since the front-end message won't tell you.
5. Check the recipient's spam folder — and, if the recipient is on a corporate mail system, ask their admin to check the quarantine.

And now the real problem

Suppose you did all five. The form works today. You tested it, the email arrived, you closed the ticket.

Six weeks from now, one of these will happen: the SMTP plugin gets an update that breaks authentication; the mail service rotates a key; the host tightens outbound limits; the client's IT department turns on a stricter spam policy; a plugin update changes the From header. The form will keep showing the green message. Nobody will notice for weeks — until the client asks why enquiries have dried up, and you get to explain that you weren't watching.

This is not hypothetical, it is the default outcome, because none of the standard tools verify delivery:

What actually verifies delivery

Only one thing: submitting a real test lead and then finding it in a real mailbox. Not a function return value, not an SMTP acknowledgement, not a provider's report — the message, in the inbox, with your own eyes (or a machine's).

That is what our form check does. On a schedule, it submits a synthetic lead through the form with a unique marker in the body, and then looks for that marker in a monitored mailbox over IMAP. If the message arrives, the whole chain works — plugin, wp_mail(), SMTP, authentication, the recipient's spam filter. If it doesn't arrive within the window, you get an alert while the client is still happily unaware.

It is deliberately the least clever check we have: it does exactly what a careful human would do, except it does it every hour and never forgets. And it is the only check that can catch the failure mode CF7's own author describes — mail that was kidnapped and killed somewhere after the green checkmark.

FAQ

Why does CF7 show a green message but no email arrives?

The green border only means wp_mail() returned true — the request processed without an error. WordPress core states that a true return does not mean the email was received. CF7's FAQ says the mail may have been "kidnapped or killed" after that, most often by a spam filter.

Does Contact Form 7 store submissions?

No. Its own docs warn you may "lose important messages forever" if mail breaks. Flamingo saves submissions to the database — turning a lost lead into a delayed one.

What does the orange border mean?

A spam module (Akismet, reCAPTCHA, disallowed list) blocked the submission. CF7 deliberately shows the same message for a mail failure and a spam rejection, so from the front end you cannot tell which one is eating your leads.

How do I know the form still works without testing by hand?

Monitor delivery end to end: submit a test lead with a unique marker on a schedule, then verify it arrives in the mailbox. That is the only check covering the whole chain, including the receiving spam filter.

Originally published at pingvera.com.

---

Originally published at pingvera.com.