It's a familiar situation: a user fills out a form on a website, sees the "Sent" status after submitting it, but the request never appears in their inbox (or CRM). The error may not be displayed on the frontend, meaning the email is lost somewhere along the way between the form, the server, and the email service. 1) The form handler doesn't send the email (or sends it to the wrong location) The most common cause is that the server-side form is configured so that the user sees a successful response from the backend, but the email is never actually sent. This happens when the handler: - returns "success" before the submission is complete; - crashes with an error, but the error isn't logged and isn't displayed to the user; - sends the email to a different email address or environment (staging instead of production). Check: Open your server logs (PHP/Node/Python/NGINX) and see if the request is calling the expected endpoint and what happens after the POST request. A good indicator is whether the logs contain lines about email sending or exceptions. 2) Email not reaching the post office: spam filters, SPF/DKIM/DMARC and reputation Even if an email was actually sent from the server, it may not reach your inbox. Modern email providers often allow or block messages depending on the validity of domain authentication. Check DNS records for the sender's domain: SPF - who has the right to send mail from your domain; DKIM — message signature; DMARC — policy for handling invalid mail (what percentage to mark/reject). If these settings are not configured or configured incorrectly, emails may be marked as spam or rejected. Additionally, check whether a specific sending IP (reputation) is blocking emails or whether your hosting or email service has any restrictions. 3) The email is sent, but the user is shown “successfully” without confirmation of delivery. Some forms are designed so that the frontend displays "Sent" as soon as it receives a response from the handler (e.g., HTTP 200). However, this doesn't mean the email was successfully received by the recipient's mail server. If the sending code uses async, a timeout, or a silent error catch handler, the user will still see success. Verification: Enable tracing/logging at the sending location. Look for differences between the "send request created" and "email received/returned acceptance" events. If using an SMTP provider, it's helpful to log the server response (message-id, status). 4) Requests are lost in the CRM/recording script or recipient filters If a request should be sent to a CRM (or a table/storage of requests) rather than an email, the problem may be with the integration. Issues with webhooks, access tokens, permissions, limits, and field validation (for example, if a required field is empty, the record isn't created) are common. Verification: Try sending a test with a minimal data set and check if the message is recorded in the CRM/integration logs. Also, check your email filtering/rules: perhaps emails are arriving but are being automatically moved to the "Promotions/Spam/Archive" folders. What to do right now (quick checklist) Submit a test request and simultaneously check: backend logs, mail subsystem/SMTP logs, and the handler response status. Make sure the form settings specify the correct recipient (and the correct environment - production, not staging). Check SPF/DKIM/DMARC and, if possible, see what the sender/recipient's email provider shows for the test message. If you are using a CRM/webhook, check the integration event log and ensure the tokens/endpoint are correct. If emails still aren't arriving after these steps, the most effective way is to gather evidence: the handler's HTTP response, send attempt logs, the message ID (if any), and a sample test payload. This will help the developer or support team pinpoint the source of the "loss."