When a WordPress contact form is not sending emails, the form is not always broken. The failure can sit in the form plugin’s notification settings, WordPress wp_mail, an SMTP or transactional mail plugin, DNS authentication (SPF/DKIM/DMARC), spam or quarantine on the receiving mailbox, or a front-end submit that never reaches WordPress.
Work this checklist in order. Separate two questions early: did the form process the submission, and did the notification reach the receiving mailbox? Check saved entries only if storage is enabled for that form. Once notifications arrive again, restore any temporary cache or plugin changes made only for testing and recheck the full lead path. If one covered WordPress issue is clearly to blame and you want help, use the $99 one-time fix after you can authorize access.
Define what failed
- Note whether the visitor sees a success message, an error, or nothing after submit.
- If entry storage is enabled for this form, check for your test submission. Some forms, including Contact Form 7 without a storage add-on, do not save entries.
- Check spam, promotions, quarantine, and mailbox rules for the notification address—not only the primary inbox.
- If the whole site is offline or shows a database or HTTP error, fix that first with the site down, database connection, or 403/500/502 checklists.
Quick triage map
| What you observe | Likely layer | First useful check |
|---|
| No success message; console or network errors | Front-end / cache / scripts | Private window; bypass page cache; inspect console and the form’s AJAX request |
| Success message but no entry saved | Storage disabled, or a storage/submission problem | Confirm this form is configured to save entries before treating a missing entry as a failure |
| Entry saved; no email anywhere | Notifications or WordPress mail | Notification enabled, To/From/Reply-To; mail log for wp_mail |
| Mail log says sent; inbox empty | Delivery not yet confirmed | Check provider acceptance, bounces or rejects, and receiving spam/quarantine; a sent log alone does not prove delivery |
Safe triage order
Prefer staging when you can reproduce the form there. Take a backup before changing SMTP, DNS, or security plugins on production. Disabling spam protection or cache can increase junk submissions—restore those controls after the test.
- Check submission processing. Submit once from a private window using a test address you control. If storage is enabled, look for the entry. If storage is not enabled, use the form's response and available submission logs to investigate. A missing entry alone does not prove failure; a success message alone does not prove email delivery.
- Check notification settings. Confirm the notification is enabled, the To address is correct, and the From address uses a mailbox on your own domain. Put the visitor’s address in Reply-To. Using the visitor as From often fails sender checks.
- Test WordPress mail separately. Send a test through your host's recommended tool to a mailbox you control. A successful
wp_mail result or “sent” log shows the send request was processed, not that the email arrived. Check provider logs and the receiving mailbox, including spam and quarantine. If the test arrives but the form notification does not, compare notification settings, conditional logic, sender, and recipient. If the send request fails, use the logged error to investigate SMTP credentials or hosting mail limits.
- Align SMTP and DNS. Prefer a real SMTP or transactional provider for business-critical forms. Authenticate SPF and DKIM for the From domain. Check the provider’s bounce and reject logs for the same timestamp as your test.
- Rule out cache and script conflicts. If submit never completes, temporarily bypass cache for the contact page and disable script defer/combine for form and CAPTCHA assets on staging. See also cache plugin conflicts with forms and forms not working on mobile.
- Retest the full lead path. Confirm the submission is processed, an entry is saved if storage is enabled, and the notification reaches the intended mailbox. Check the auto-reply if used and any CRM or ad conversion tags that depend on the thank-you step.
Safer From / Reply-To pattern
From: website@your-domain.com
Reply-To: {visitor_email}
To: team@your-domain.com
Keep the From domain aligned with the domain authenticated in DNS. Do not paste SMTP passwords into tickets or public screenshots.
Common causes
- Notification disabled, wrong To address, or conditional logic that never matches.
- Visitor email used as From; domain fails SPF/DKIM checks.
- Host blocks or rate-limits PHP
mail(); no SMTP plugin configured.
- SMTP credentials rotated; plugin still has the old password.
- Page cache or deferred JavaScript breaking AJAX submit or CAPTCHA.
- Receiving mailbox rules, quarantine, or a full mailbox hiding successful sends.
When a $99 one-time fix fits
Request the $99 one-time WordPress fix if you want help with one clearly defined issue on one WordPress site. Name the form plugin, whether entries save, the notification address, when it started, and the last change you made. We confirm the scope before work begins. Send credentials only through the private access link provided after your request is accepted.
Full rebuilds, new custom features, full migrations, account-wide host outages, and multiple unrelated issues are outside this offer. If you need a deeper form-delivery package, see also fix WordPress contact form email delivery.
Related checks
If the checks do not identify the cause, send your host or mail provider the form plugin name, entry ID if available, notification timestamp, and any mail-log error (secrets redacted). Suspected compromise needs a security investigation as well as restoring notifications.