A form is a chain, not a single feature. The browser sends a request; WordPress validates and stores data; notification logic builds a message; a mail transport hands it to a provider; the recipient system filters it into a mailbox.
Tracing one labelled test across these handoffs reveals the owner of the failure and avoids speculative changes.
Prepare one controlled submission
Use a synthetic name, a unique reference in the subject or message and no personal information. Record the page URL, exact time with timezone, browser, expected recipient and form ID.
Keep the configuration unchanged during the trace. A new timestamp or reference for every retest prevents old messages and cached pages from confusing the evidence.
Check whether a temporary fallback contact route is needed while leads are at risk.
Stage 1: inspect the browser request
Open the browser developer tools, submit once and find the form’s POST, AJAX or REST request. Record its URL, status and response. A 403 points toward security, nonce or CAPTCHA checks; a 500 requires the matching PHP/server error; a timeout may involve PHP, SMTP or network limits.
The visual success message must correspond to an actual successful response. Console errors and blocked scripts can leave a request unsent or the interface stuck.
Remove personal field values before sharing any capture.
Stage 2: confirm WordPress processing
Look for the synthetic entry in the form plugin. Its presence proves much of the request path, but not email generation. If absent, inspect validation, plugin logs, PHP logs, security events and database errors around the timestamp.
Confirm the entry belongs to the current form and production site. Duplicate forms and staging copies often have different IDs or notification settings.
Do not enable public debug output on a live website.
Stage 3: identify the notification
Determine which notification rule should run for the submitted values. Check its enabled state, recipient tokens, conditions, From address and Reply-To.
Use an authenticated domain address as From; put the visitor address in Reply-To. Log the notification ID and intended recipient while storing as little message content as possible.
If no notification is generated, the fault is still in form/plugin logic, not at the recipient mailbox.
Stage 4: trace WordPress mail
Find the corresponding wp_mail() attempt or queue job. A false result or PHP exception needs the exact local error. A successful handoff only says WordPress passed the message to its configured transport.
For queued mail, record job creation, scheduled time, attempts and final state. Verify WP-Cron or the server scheduler rather than manually deleting pending jobs.
Keep logs access-controlled and remove diagnostic data when it is no longer required.
Stage 5: inspect SMTP provider status
Search the SMTP or transactional provider using recipient, timestamp and message reference. Record whether it accepted, deferred, bounced, blocked or suppressed the address, plus the message ID and redacted response code.
Check SMTP credentials, connection security and the provider’s sending limits only if evidence points there. Repeated tests can worsen throttling.
Provider acceptance is still not proof that the user’s inbox displayed the message.
Stage 6: follow the recipient system
Ask the authorised mail administrator to search the gateway by message ID, sender, recipient and time. Review quarantine, transport rules, aliases, distribution groups and shared-mailbox restrictions.
Inspect headers from a delivered test for SPF, DKIM and DMARC alignment. Different recipient domains may enforce authentication differently.
Check the return-path mailbox for bounces and never change MX records simply to repair outbound form mail.
Build a concise trace record
A useful trace can be reduced to a table with stage, timestamp, identifier, result and owner. Exclude passwords, API keys and real entry contents. The first missing or failed stage defines the next investigation.
After repair, repeat the entire path with a new reference. Confirm one browser success, one entry, the correct notification, one provider-accepted message and final mailbox delivery.
Request urgent repair when the chain crosses multiple suppliers, evidence conflicts or submissions are commercially critical. A good repair proves the failed handoff and the final outcome rather than merely changing the form plugin.