A contact form is a chain, not a single button: the visitor enters data, the browser validates it, the server accepts or rejects it, abuse controls evaluate it, a notification or record is created, and a person receives it. Troubleshoot with a sanitized change log that records the first failure, the exact step that failed, recent releases or routing changes, one test action, and its result. Never copy real customer messages or passwords into the log.
Reproduce the symptom safely
Use a clearly labeled synthetic submission with a test address and harmless text. Record the page URL, time, browser, device, fields completed, visible response, and a test identifier. Try one valid submission and one intentionally invalid submission. The W3C Forms Tutorial says users should receive clear success or error feedback and instructions for correcting mistakes; errors should reference the affected control (W3C user notifications).
A success message only proves that the interface displayed success. Check whether the server created the expected record or request, whether a notification job ran, and whether the destination mailbox or help desk received the same test identifier. Conversely, a missing email does not prove the form failed if the durable server-side record exists.
Map the last good submission to the first bad one
Add every relevant change between those points: page or script deployment, field-name change, endpoint or API change, spam-rule update, CAPTCHA or bot-control change, email provider or DNS change, sender or recipient change, mailbox filter, credential rotation, hosting update, and quota or billing state. Record old and new values without secrets, the owner, time, reason, and rollback.
Separate the checks by boundary. In the browser, inspect required fields, labels, network response, and visible feedback. At the application, check the request identifier, status, validation result, and whether processing reached the notification step. At delivery, check provider status, accepted or rejected status, routing, spam or quarantine, and the intended destination.
Log enough to diagnose without leaking data
OWASP recommends that application event records capture when, where, who, and what, including an interaction identifier and the response seen by the user or taken by the application (OWASP Logging Cheat Sheet). For a contact form, a useful record can include timestamp, application version, route, test identifier, validation outcome, response code, and notification result. Mask or omit message bodies, passwords, tokens, payment data, and unnecessary personal information.
Change one reversible element at a time. For example, restore a previous field mapping, correct one destination address, or roll back one spam-rule change, then repeat the same synthetic submission. Do not disable abuse protection broadly just to get a successful test; use a controlled rule or staging environment and keep the protection state in the log.
Verify the whole path
After the repair, run a valid test and confirm clear browser feedback, a successful server record, the expected notification or ticket, and receipt by the correct owner. Run an invalid test and confirm that useful, accessible instructions appear without creating a false lead. Check a second browser or device and the next production deployment. Close the log with the root cause, exact fix, evidence, owner, and follow-up date. If delivery remains inconsistent, label it unresolved and preserve the test identifiers for provider support.
Sources
- User Notification — W3C Web Accessibility Initiative
- Logging Cheat Sheet — OWASP Foundation