WordPress Contact Form Not Sending Email — Troubleshooting Guide

Short decision path

Pick the branch that matches what you observe. Do not skip the distinction — the form/plugin path and the mail-delivery path need different checks.

This page does not claim automatic diagnosis. Use one unique test phrase per attempt and change only one thing between tests.

1. Distinguish “form failed” vs “form submitted but email not delivered”

Treat these as separate problems until evidence says otherwise.

• Form failed: no success message, error on submit, Network request fails (4xx/5xx), or no entry appears in the form plugin log.
• Form submitted but email not delivered: success UI or thank-you appears, and/or an entry is saved, but the admin notification never arrives in the expected inbox (including spam).
• Submit a real test with a unique phrase in the message body (e.g. TEST-2026-10-04-A).
• Open browser DevTools → Network: note whether the form POST or AJAX call fires and its status code.
• If the request fails or never fires, stay on the form/plugin/browser path — do not jump to SMTP yet.

If the form already reports success (or saves an entry) but the notification never arrives, also see: WordPress contact form says sent but no email arrives.

2. Backup before modifying production

Before disabling plugins, changing SMTP, or editing form mail templates on a live site:

• Take a fresh backup (files + database) or confirm a recent host backup you can restore.
• Note current form notification settings, SMTP credentials location, and active plugins before you change them.
• Prefer staging when available; if you must work on production, change one setting at a time and re-test with the same unique phrase.
• Do not delete “old” notification rules until you have a working replacement and a recorded successful test.

3. Validation and submission errors

Many “email not sending” reports are actually blocked submits.

• Watch for required-field, CAPTCHA, consent, or file-upload errors — including ones that only appear on mobile.
• Confirm JavaScript loads (theme/plugin conflicts can break the submit handler while the button still looks clickable).
• Check the form plugin’s entries / submissions log. No entry usually means the submit never completed; a saved entry with no mail points to notifications/SMTP.
• If conditional logic or multi-step forms are used, confirm the final step is the one that triggers send — earlier steps may only save drafts.
• Retest in a private window with extensions disabled to rule out browser blockers.

4. Recipient / admin email configuration

Wrong destination is common after migrations or staff changes.

• In the form plugin, confirm the notification “To” address is current and typed correctly.
• Compare against Settings → General → Administration Email Address (they are not always the same).
• If notifications go to a role or dynamic field, confirm that field is populated on submit.
• Send a plain WordPress or host-panel mail test to the same address to separate “form config” from “mailbox rejects mail.”

5. Spam and junk folders

Many “not sending” reports are “sent but filtered.”

• Search the recipient inbox (and any shared/team inbox) for your unique test phrase.
• Check Spam / Junk / Quarantine — including Google Workspace / Microsoft 365 quarantine if you use them.
• Check filters/rules that auto-archive or forward form mail.
• If mail arrives in spam, note From, Reply-To, and subject — weak SPF/DKIM or a mismatched From domain often causes this.

6. SMTP and mail delivery

Default PHP mail() on shared hosting is unreliable. Many hosts throttle or drop it.

• Ask: does this site use an SMTP plugin or transactional provider (authenticated SMTP or API mailer)?
• If SMTP is configured, open its send log / last error. Failed auth, TLS, or daily limits show up there.
• Confirm the From address uses a domain you control and that SPF/DKIM align for that sending service.
• Test sending from a different path (hosting “send test email,” or a simple SMTP test) to the same recipient.
• Do not assume every missing email is an SMTP problem — only treat it as one after submission success and correct recipient are confirmed.

7. WordPress / plugin notification settings

Contact Form 7, WPForms, Gravity Forms, Fluent Forms, and others each store mail settings differently.

• Confirm the admin notification is enabled (not only a user auto-reply).
• Check Mail / Notification tabs for empty To, broken mail-tags, or conditional logic that skips send.
• If there is an auto-reply to the visitor, test whether that arrives while admin mail does not (or the reverse) — it narrows the fault.
• After plugin or site updates, re-open the form and save once; some setups need a re-save after migrations.
• Disable one recent add-on (spam service, CRM hook, webhook) temporarily if sends stopped after it was installed — then re-test once.

8. Caching, security, and plugin conflicts

Caches, firewalls, and overlapping plugins can break POST, nonces, or AJAX without an obvious UI error.

• Purge page cache / CDN cache for the contact page; retest in a private window.
• Exclude the contact page (and admin-ajax.php / form endpoints) from full-page cache if your cache plugin allows it.
• Check security / WAF / bot protection logs for blocked form POSTs (especially after adding CAPTCHA or rate limits).
• Temporarily disable one layer (cache plugin or one security rule — not everything at once) and retest with the same unique phrase.
• If the site is behind Cloudflare or similar, review Bot Fight / Managed Challenges on the form URL.
• Suspect a plugin conflict when two form-related, optimization, or security plugins were recently combined — deactivate the newest one first, then re-test.

9. Recent plugin, theme, or update changes

Failures that started “after an update” usually belong on the conflict/update path.

• List what changed in the last successful-to-failed window: WordPress core, form plugin, SMTP plugin, theme, security, cache, or host PHP version.
• Read the form and SMTP plugin changelogs for mail-tag, REST, or nonce changes.
• If a theme update restyled the contact page, confirm the form shortcode/block is still present and not duplicated inside a cached template.
• Roll forward carefully: restore from backup or revert the single newest change, re-test, then update again with a plan — do not stack untested updates.

To update again with a plan, the £59 Update & Safety Check is one pass: backup check, sequenced core/theme/plugin updates, smoke tests of key pages and forms, and a short report. It does not repair a break that already exists; the £49 Quick Fix below covers one agreed problem.

10. Test from desktop and mobile

Some failures only appear on phone layouts or specific browsers.

• Repeat the same unique-phrase test on a phone (real device) and on desktop.
• Try a second browser, and one private/incognito window (extensions can block scripts).
• On mobile, confirm required fields, consent checkboxes, and sticky headers are not covering the submit control.
• If desktop works and mobile fails (or vice versa), note viewport, browser, and whether the Network request differs.

If the visitor already sees success or thank-you but your business still cannot find the enquiry (entries, mail, spam, or CRM), see: WordPress contact form says submitted but no enquiry received.

11. When server/mail logs or hosting support may be required

DIY checks above cover most configuration mistakes. Escalate to server/mail logs or hosting support when:

• Submission succeeds and entries save, but no provider (SMTP plugin, transactional mailer, or host mail) shows an accepted send.
• SMTP auth succeeds in the plugin UI, yet remote logs show rejects, greylisting, or daily send limits.
• You need access to mail queue, exim/postfix logs, or blocked outbound port 25/465/587 — typically host-only.
• PHP fatals, 500s on admin-ajax.php, or WAF blocks appear only in server logs, not in the browser.
• SPF/DKIM/DMARC must be fixed at DNS for the sending domain and you lack DNS control.

Bring your unique test phrase, timestamps (with timezone), form URL, and any SMTP error string — support can search logs faster with that evidence.

12. Test evidence to record

Clear notes turn a vague “emails don’t work” into something fixable.

• Date/time (with timezone), page URL, device, browser.
• Which decision-path branch you followed (will not submit / submits but email missing / intermittent after update).
• Unique message phrase used in the test.
• Whether the UI showed success; Network status for the submit request.
• Whether an entry appeared in the form plugin log.
• Inboxes checked (including spam/quarantine) and whether mail arrived.
• SMTP/plugin log snippet or error string, if any.
• What you changed between tests (one change at a time).

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

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.

More paths: WordPress troubleshooting resources. No private payment links on this page.