WordPress Contact Form Says Sent but No Email Arrives

1. Distinguish successful form submission from successful mail delivery

“Says sent” and “email arrived” are two different outcomes. Treat them separately.

• Confirm the UI success state: inline message, thank-you redirect, or both — after a real submit, not a draft save.
• In DevTools → Network, confirm the form POST/AJAX returned 200/302 (not 4xx/5xx). A green UI with a failed request is a front-end lie, not a mail problem.
• Check the form plugin’s entries/submissions log. An entry that saved with no notification is the classic “sent but no email” case.
• If there is no entry and the Network request failed, stop here and use the broader contact-form diagnostic — you do not yet have delivery evidence.
• Do not assume one universal cause: missing mail after a saved entry can be recipient, spam, PHP mail, SMTP, or downstream filtering.

2. Verify notification recipient / address configuration

Wrong or outdated “To” addresses are common after migrations and staff changes.

• Open the form’s Mail / Notifications settings and read the exact To address (copy-paste into a note).
• Compare with Settings → General → Administration Email Address — they often differ.
• If To uses a mail-tag, dynamic field, or role, confirm that field is populated on the saved entry.
• Check CC/BCC and conditional notifications that may skip send for certain products, languages, or empty fields.
• Confirm the admin notification is enabled (not only a visitor auto-reply).

3. Check spam, junk, and quarantine

Many “never arrives” reports are “arrived but filtered.”

• Search the recipient inbox for a unique test phrase you put in the message body.
• Check Spam / Junk, and any provider quarantine (Google Workspace, Microsoft 365, host spam filter).
• Review filters/rules that auto-archive, label, or forward form mail to an unused mailbox.
• If mail lands in spam, note From, Reply-To, and subject — they feed the next From-domain check.
• If the message is confirmed in Spam/Junk/quarantine (not missing), continue with the focused WordPress contact form emails going to spam checklist rather than repeating broader “not sending” steps.

4. WordPress/PHP mail versus SMTP

Default PHP mail() on shared hosting is often throttled or dropped after the form “succeeds.”

• Ask: does this site send via an SMTP plugin or transactional API, or only via PHP mail?
• If only PHP mail: hosting “send test email” to the same recipient separates host mail from form-plugin mail.
• If SMTP is configured: confirm it is active for the form path (some plugins only affect wp_mail when hooked correctly).
• Do not treat every missing inbox as “need SMTP” until submission success and correct recipient are proven.

5. Sender / From-domain alignment (high level)

Misaligned From addresses often pass the form UI and still never reach the inbox.

• Note the From address on the notification. Prefer a mailbox on a domain you control.
• Avoid From addresses that impersonate the visitor’s personal Gmail/Outlook (Reply-To can carry their address instead).
• At a high level: sending service and domain SPF/DKIM should align for that From. Deep DNS debugging is out of scope here — only flag mismatch as a likely delivery filter cause.
• If spam quarantine shows “spoof” or “failed authentication,” treat From-domain alignment as a priority check before more form tweaks.

6. SMTP and plugin logging where available

Logs turn “maybe sent” into “attempted / accepted / rejected.”

• Open the SMTP plugin’s send log (or last error). Failed auth, TLS, quota, or blocked recipient appear there.
• Check form-plugin mail logs or debug add-ons if present — some record “mail attempted” vs “mail failed.”
• Hosting mail logs (if accessible) can show the message left PHP but was rejected downstream.
• If logs say accepted by the remote MTA but the inbox is empty, bias toward spam/quarantine or wrong mailbox — not form UI.

7. Test with a controlled recipient

One known mailbox you control removes “maybe the client’s filter” ambiguity.

• Temporarily set To to an address you own (same domain or a clean personal test inbox).
• Submit with a unique phrase; check inbox + spam within a few minutes.
• If controlled recipient gets mail and the original does not: original mailbox/filter/quarantine is the fault zone.
• If neither gets mail but the entry saves: stay on PHP/SMTP/From-domain and logging — not recipient typos alone.
• Restore the production To address after the test; do not leave a personal inbox as the live notification target.

8. Distinguish site/form failure from downstream delivery failure

Decide which side of the wire broke.

• Site/form side: no entry, failed Network request, disabled notification, empty To, conditional skip, plugin error on send.
• Downstream delivery: entry saved, logs show accept/attempt, mail appears in spam/quarantine, or only some recipients receive it.
• Visitor auto-reply arrives but admin notification does not (or the reverse) — that often points to notification config or per-message filtering, not “the form is broken.”
• Document which side you believe failed before changing multiple systems at once.

9. Record reproducible evidence

Vague “emails don’t work” stalls fixes; a short evidence pack does not.

• Date/time with timezone, form page URL, device, browser.
• Unique message phrase; UI success yes/no; Network status code.
• Entry saved yes/no (plugin log ID if available).
• Inboxes checked (including spam/quarantine); mail arrived yes/no.
• SMTP/plugin log snippet or error string, if any.
• One change between tests — then retest the same phrase pattern.

Tip: mark the same items in the free Enquiry Path Checklist and copy the summary for your records or a developer.

10. Isolated issue vs wider enquiry-path failure

A single wrong recipient, spam hit, or SMTP auth error is often an isolated fix. Treat it as a wider enquiry-path problem when several of these hold:

• Submission succeeds and entries save, but delivery is inconsistent across recipients or time.
• SMTP, DNS (SPF/DKIM), and plugin notifications all need coordinated changes.
• The path spans multiple steps, conditional fields, CRM/webhooks, or separate confirmation pages.
• You cannot reproduce reliably enough to verify one change.

Isolated, reproducible “success UI + missing mail” with a clear single fault → short fix territory. Multi-step / inconsistent delivery across the whole enquiry path → map and repair the path, not one random setting.

If you want help fixing it

This guide and the free checklist are complete on their own. Use a paid option only if you prefer bounded help after you’ve narrowed the failure — not as a required next step.

Also see the broader contact form not sending hub · Catalogue: QuietForgeTools hub. No private payment links on this page.