If your form submitted successfully but no email arrived, check whether the submission was saved before changing the form. A saved entry means the browser and endpoint worked. The break is later: notification rules, the sending service, suppression, or your mailbox.
I'm troubleshooting the notification sent to the form owner here. If the missing message was supposed to go back to the submitter, check the autoresponder configuration separately: confirm it maps to the submitted email field, and then follow the same send-status and mailbox checks below.
Start with the saved submission
Open the form service, database, CRM, or server log that should contain the entry. Find the exact test by timestamp and email address.
| What you find | What it proves | Check next |
|---|---|---|
| No saved entry | This test did not produce a stored entry | Browser Network tab, endpoint response, spam controls |
| Saved as spam or quarantined | The receiver accepted it but may have skipped notifications | Spam policy and false positives |
| Saved normally | Storage worked | Notification processing and send status |
If there is no entry, this is not yet an email problem. Open DevTools, submit once, and inspect the request. The contact form checker can catch a bad action, missing method, unnamed fields, and other markup defects, while the broader broken contact form checklist covers 404, 405, and CORS failures.
A green request still needs interpretation. A success page or 2xx response says the application accepted the HTTP request according to its own contract. It does not prove that a record was stored or that a later email job ran.
Spam controls can make that distinction deliberately confusing. A honeypot may return a normal-looking success response so a bot cannot learn how to bypass it. A quarantined submission may be stored without creating a notification, so check the spam view before assuming the entry vanished.
The submission exists, but no notification was created
Once the entry exists, stop editing the HTML. Start with the notification recipients configured on that exact form. Copied, staging, and newly created forms can look identical while pointing at different addresses. Read each recipient character by character for typos, old employees, disabled shared mailboxes, and aliases that no longer forward.
Then replay the submitted values against any routing or conditional rules. A department dropdown can send sales one way and skip an unmatched value elsewhere. Confirm whether spam or quarantined submissions are eligible to notify before weakening protection.
Finally, check account state: notification toggles, required publish steps, recipient verification, unsubscribes, prior-failure blocks, and submission or sending limits. Typeform tells recipients to resubscribe and unblock its notification sender in their email provider, while Webflow tells users to verify notification settings and republish.
I built Form Plume around the saved-versus-sent split. When a submission is eligible for processing, Form Plume commits the submission row and processing job in one transaction, scores the entry for spam in a worker, retries temporary provider failures, and skips a notification when any To, CC, or BCC recipient is suppressed. Its spam inbox, routing, and notification delivery docs cover those product-specific branches.
Read the send status, not the success message
If your platform exposes notification history or your mail provider has message logs, search for the exact recipient and timestamp. The status narrows the problem faster than sending five more tests. Provider labels vary, so read the event detail as well as the badge.
| Send status | Meaning | Action |
|---|---|---|
| No attempt recorded | The notification may be pending, may have failed before sending, or may never have triggered | Check processing status first, then recipients, routing, and conditions |
| Pending / deferred | Delivery has not completed; the provider may be queued or retrying | Wait for the next event, then inspect the latest error |
| Provider / API accepted or queued | The sending service accepted the request, but recipient-server acceptance is not confirmed | Wait for the next event or inspect the provider log |
| Bounced / rejected | This attempt did not deliver. The event detail may classify the failure as temporary or permanent and may include the remote server response | Inspect the exact response before retrying |
| Suppressed | The sender intentionally skipped the address | Inspect why it was suppressed before removing it |
| Delivered / recipient server accepted | The recipient's mail system accepted the SMTP handoff | Search mailbox folders, quarantine, and rules |
How long should you wait? There is no provider-neutral timeout. Use the next retry time or retry window shown by your provider, and do not keep resubmitting while the message is pending. Escalate after that window expires with the recipient, timestamp, provider message ID, and latest event. SendGrid, for example, retries deferred email for up to 72 hours.
A suppression is not another word for spam-folder placement. It means the sending system has decided not to attempt delivery, often after a hard bounce or complaint. Amazon SES documents that it can accept a send request for a suppressed address without sending the message, and that only hard bounces are automatically added for bounce reasons. Postmark's suppression API likewise distinguishes hard-bounce, spam-complaint, and manual suppressions.
Do not delete a suppression just to make the warning disappear. First confirm the mailbox exists, understand the recorded reason, and make sure the recipient wants the mail. Repeatedly sending to a bad address damages sender reputation and recreates the same failure.
“Delivered” still does not mean “in the inbox”
For providers such as Postmark and Amazon SES, “delivered” means the destination mail server accepted the message. It still may be routed to spam, quarantine, a mailbox rule, or a shared mailbox nobody opened.
Check in this order:
- Search all mail by sender, subject, recipient, and the test timestamp.
- Check spam, junk, promotions, and other inbox tabs.
- Review mailbox rules that skip the inbox, archive, forward, or delete.
- Check the organization-level quarantine, not only the user's folders.
- If an alias or group forwards elsewhere, test each hop separately.
Google's missing-message checklist specifically calls out spam, storage limits, filters, forwarding, POP, and IMAP settings. For Google Workspace, its contact-form troubleshooting guide says the problem is usually how the sending system sends the message, not the form itself, and directs admins to Email Log Search.
Microsoft 365 admins can use message trace to see whether Exchange received, rejected, deferred, delivered, filtered, or quarantined a message. If the user sees nothing but message trace says quarantined, changing the form cannot fix it.
Swap the recipient once
When the logs are unclear, route one test to a different mailbox you control, preferably at another provider.
- If the new mailbox receives it, check the original address for a typo or recipient-specific suppression, then inspect its mailbox, alias, forwarding chain, and organization policy.
- If neither mailbox receives it and no send attempt is visible, check the processing or job status and the provider logs. The attempt may have failed before a durable send event was recorded.
- If both attempts bounce or defer, inspect the sender configuration or provider incident.
Change one variable at a time. Keep the same form, fields, and test message. Otherwise a successful retry tells you nothing about which change fixed it.
After the test, restore the intended recipient. A personal inbox is useful for isolation, not as an accidental production routing rule.
If you send email from WordPress or your own server
Self-managed sending adds another layer: your application can report success before the recipient receives anything.
WordPress says this explicitly in the wp_mail() documentation: a true return value means the sending method processed the request without an error, not that the user received the email. Your application log therefore needs the provider's message ID and later delivery events, not only wp_mail() === true or “SMTP accepted.”
Check these next:
- SMTP or email API credentials are still valid.
- The application waits for, logs, and handles the send result.
- The notification uses an authenticated sender in
From. - The visitor's validated address goes in
Reply-To, notFrom. - SPF and DKIM authorize the service actually sending the message.
- DMARC alignment matches the domain shown to the recipient.
Google's contact-form guidance identifies SPF, DKIM, and authenticated SMTP as the common authentication paths. Postmark's sending guide requires a verified From address, while its Email API provides a separate ReplyTo field. Google's sender guidelines define DMARC alignment against the domain in the visible From header.
Adding random DNS records is not a fix. Identify the real sender first, then use that provider's current DNS instructions.
If you only need an HTML form to reach an inbox, this mail stack is the part I would outsource. The guide to sending an HTML form to email without building a backend compares the practical options, and the form action guide covers pointing the browser at the right receiver.
Make the next failure survivable
Email should notify you about a submission, not be the only copy. Store the entry before attempting delivery, then create a durable notification job. If the queue shares your database, commit the row and job in one transaction. If it does not, use a transactional outbox so a crash cannot save the submission without scheduling its notification. Process delivery asynchronously so a mail outage delays the alert without losing the submission or slowing the form response.
For a production form:
- Keep a searchable submission record independent of email.
- Record each notification attempt with its recipient, timestamp, provider ID, and status, then alert someone when failures persist.
- Retry temporary failures, but stop on permanent bounces and suppressions.
- Send one real test after changing recipients, routing, DNS, or email providers.
