The success message proves that the browser received a positive application response. It does not prove that WordPress created the notification, that SMTP accepted it or that the recipient mailbox delivered it.
Preserve a test submission and follow it through each handoff instead of changing form and DNS settings simultaneously.
Create a controlled test
Use a clearly labelled test name, a unique subject/reference and a non-sensitive message. Record the exact submission time with timezone, page URL, recipient and browser.
Do not enter a real customer enquiry repeatedly. That can create duplicate entries and confuse sales.
Test as a logged-out visitor in a private browser, then check whether the form stores an entry.
Confirm WordPress received the submission
Inspect the form plugin’s Entries/Submissions area where available. If no entry exists, the success message may be generated before persistence or a cache/JavaScript layer may be misleading.
If the entry exists with all fields, the browser-to-WordPress path worked. Move to notification generation.
Check server/PHP logs for the exact timestamp, but do not log full personal form content.
Review notification rules
Confirm the notification is enabled, its recipient matches the expected mailbox and conditional logic actually fires for the chosen answers.
Check dynamic tags used in To, From, Reply-To and subject fields. A misspelled field token can produce an empty/invalid header while the entry still saves.
Do not place the visitor’s arbitrary email address in From. Use an address on the sending domain and put the visitor address in Reply-To.
Capture the WordPress mail event
Use a reputable mail logging method temporarily to record timestamp, recipient, subject, headers and error outcome. Redact message body and attachments from shared logs.
WordPress wp_mail() can return success when the local handoff accepted the message; it does not guarantee mailbox delivery.
If no mail event appears, inspect the form plugin/hook. If an event appears, continue to SMTP/provider evidence.
Check SMTP acceptance
Review the SMTP plugin/provider log for authentication, connection, message ID and response code. Distinguish:
- WordPress never called mail;
- SMTP connection/authentication failed;
- provider accepted the message;
- provider rejected sender/recipient/limit;
- provider later bounced it.
Do not publish SMTP usernames, tokens or complete headers.
Trace the recipient side
If the provider accepted the message, search spam, quarantine, mail-flow rules and aliases at the destination. Ask the company-mail administrator to search by message ID, sender and timestamp.
Testing only a personal Gmail inbox does not prove delivery to the business domain. Corporate gateways can reject or quarantine differently.
Check bounce messages at the authenticated return-path mailbox.
Verify sender authentication
Inspect the final message headers from a mailbox that received the test. Confirm SPF/DKIM/DMARC alignment for the actual provider and From domain.
Do not add a second SPF TXT record. Merge authorised senders into one valid policy with DNS/mail-provider guidance.
MX controls inbound mail; it does not automatically authorise the website to send.
Repair one failing handoff
Fix the exact notification, SMTP credential, sender alignment, rate limit or mailbox rule identified. Keep a rollback of plugin/DNS configuration.
Then repeat one labelled test and verify entry, mail log, provider acceptance and final mailbox. Test Reply-To and any sales automation.
Keep leads safe while diagnosing
If the form stores entries, export or review them securely so unanswered enquiries are not forgotten. Restrict access because entries may contain names, email addresses or other personal data. Do not paste live submissions into public support tickets.
If the form does not store entries, temporarily provide a visible alternative contact route such as a monitored email address or telephone number. State the limitation honestly instead of leaving visitors with a success message that cannot be trusted.
Avoid repeatedly submitting the same production form. Use labelled test data, record the exact time and remove the test entries afterwards under the site’s retention policy.
When to request urgent repair
Request help when leads are being lost, logs disagree or delivery varies by recipient. Send the page URL, timestamp, form plugin and non-sensitive error text—never mailbox/WordPress passwords.
A reliable repair proves the message reached the intended mailbox, not merely that the green success notice appeared.