From Form Submission to Email
Maintained by the SplitForms team · Updated
SplitForms checks the request and form settings, applies spam controls, and saves accepted submissions before attempting owner notification email. Email, attachments and integrations each have their own delivery conditions. Use the dashboard record as the first checkpoint when tracing a missing notification.
The checkpoints in a submission
Separating the stages makes troubleshooting more precise. A browser sending a request, a backend storing it and a mailbox displaying it are different events. Test each part with a clearly labelled entry that your team expects.
| Stage | What to verify |
|---|---|
| Browser request | The production page posts to the intended endpoint with named fields. |
| Form and account checks | The key is current, the form is active and the account has allowance. |
| Spam and origin checks | Allowed Domains, honeypot and configured verification match your form. |
| Saved submission | The expected answers appear in the dashboard or Spam view. |
| File storage | Expected files were stored and can be opened. |
| Notification | Email notifications are enabled and the configured recipient can receive mail. |
| Integration delivery | The receiving application accepted and processed the webhook or connector request. |
References: SplitForms API reference · Email notification documentation
The lead is saved but no email arrived
Start with the receiving form’s settings. Check whether owner notifications are enabled, which address receives them, and whether a rule routed this submission elsewhere. Review spam and quarantine folders in the receiving mailbox. Custom SMTP users should also inspect their provider’s delivery result.
SMTP acceptance does not guarantee inbox placement. A receiving provider can delay or filter a message after it has been sent. Resend a stored submission only when you intend to send another notification; changing the form and asking the visitor to submit again is usually unnecessary.
References: Email missing after a successful form submission
The lead is absent or marked as spam
Check the actual request before changing spam protection. A copied sample access key, a hidden honeypot accidentally filled by your script, a missing verification token or a production hostname absent from Allowed Domains can explain the result. Some anti-bot gates deliberately return a generic success without creating a record.
Distinguish early rejections from submissions saved with a spam classification. A Spam folder entry can be reviewed; an early dropped request has no stored lead to recover. Correct the integration and repeat a controlled test, keeping genuine visitor information out of test fixtures.
References: Spam protection setup
Email and webhooks have separate outcomes
On paid plans, SplitForms can deliver a signed webhook to your receiver. It uses HMAC-SHA256, an eight-second timeout and one retry after roughly two seconds for network errors, timeouts and 5xx responses. A 4xx response is not retried. Verify the signature against the raw request body before acting on the data.
Return promptly after durably accepting the event, and do slow CRM work in a queue. Keep a stable submission identifier in your downstream record so a repeated delivery does not create another lead. The browser’s success screen is not a receipt from your CRM.
References: Webhook delivery and signature reference · Webhook retry strategy
What to include in a support request
Record the affected form name, approximate time and time zone, page URL, response status and error code, and which checkpoint failed. Say whether the entry exists in the dashboard. A redacted screenshot of the request structure is more useful than a statement that the form does not work.
Do not paste account tokens, MCP tokens, SMTP passwords or full visitor submissions into public issue trackers. Keep a small synthetic example that reproduces the failure, and share sensitive records only through an appropriate support channel.
References: SplitForms security information
Frequently asked questions
Does success mean the email was delivered?
No. It is the form endpoint’s response, not proof that a recipient’s mailbox displayed a message. Verify the dashboard record, then diagnose notifications separately.
Do I need to rebuild my form to use this workflow?
Usually not for an existing HTML form. Keep its visible fields and styles, connect a SplitForms endpoint, and verify the production request and downstream delivery.