A saved entry is valuable evidence: the visitor’s request reached WordPress and the plugin wrote it to storage. The remaining failure sits between notification logic and the final mailbox.
Protect the entries as live leads, then trace one controlled submission without altering several layers at once.
Secure and triage existing entries
Restrict entry access to authorised staff because forms commonly contain personal data. Identify unanswered enquiries since the last known good notification and route them through an approved process.
Do not export a full database into email or a public support ticket. If an export is necessary, minimise fields, store it securely and follow the site’s retention policy.
Record the entry ID and submission time for a synthetic test; avoid using a customer’s message for diagnostics.
Confirm the correct notification is enabled
Many form plugins can save an entry even when every email notification is disabled. Open the active form and inspect each notification’s enabled state, recipient, subject and conditional rules.
Check whether staging, migration or a plugin update changed a setting. Review To tokens that depend on a field value: a blank or malformed recipient field can prevent mail creation.
Keep the visitor in Reply-To and use an authenticated domain address as From.
Test notification conditions
Reproduce the exact department, product or consent choices that should trigger the email. Compare the displayed label with the stored value used by the condition.
Create a controlled test that should match one rule and another that should not. Confirm which notification IDs execute. Do not simply remove all conditions, because that can send personal data to the wrong team.
If a default route is needed, use an authorised internal mailbox and document why it exists.
Inspect WordPress mail generation
Enable an appropriate mail log long enough to capture recipient, time, subject/reference and result. Minimise stored body content and protect log access.
If the test entry has no corresponding mail attempt, inspect the plugin and PHP error logs at that timestamp. A hook conflict, invalid header, fatal error or queue failure may stop notification generation after the entry is saved.
If WordPress logged success, continue outward; success does not prove final delivery.
Check queues and scheduled tasks
Some plugins and add-ons queue notifications rather than sending them inside the browser request. Review pending or failed jobs and verify WP-Cron or the server cron runner is working.
Look for a growing backlog, repeated retries and hosting resource limits. Do not delete a queue before recording its state; it may contain recoverable business enquiries.
Repair the runner or the specific failed job, then process messages at a controlled rate to avoid provider throttling.
Follow SMTP and mailbox evidence
Search the external SMTP provider by recipient and test timestamp. Note acceptance, deferral, bounce or suppression and retain the message ID. Check the authenticated return-path mailbox for non-delivery reports.
If accepted, ask the recipient administrator to search gateway quarantine, transport rules, aliases and shared mailbox restrictions. A message absent from the user’s spam folder may still exist at the organisation gateway.
Verify SPF, DKIM and DMARC using a delivered copy.
Prove recovery end to end
After the narrow repair, make a new labelled submission. Confirm one entry, the intended notification ID, one mail attempt, provider acceptance and final delivery. Test Reply-To, conditional routes and attachments where used.
Monitor several low-risk events and ensure analytics records success only after the server confirms the entry.
Request urgent help when entries are accumulating, queued mail is uncertain or logs stop between layers. Share entry IDs, timestamps and redacted errors—not customer content, credentials or database exports.