How to Verify Typeform, Jotform and Webflow Email Submissions

Typeform, Jotform, and Webflow can send a completed submission into a Zap, which can then pass the email answer to Mailthentic. This is post-submit verification. It does not check the address before the visitor submits the form, and it does not replace an ownership confirmation message.

General workflow

1. A completed form submission triggers the Zap.
2. The form's email answer maps into Mailthentic Verify Email.
3. Mailthentic returns the detailed status and supporting evidence.
4. A storage or CRM step records the result.
5. An optional Filter routes only the cases covered by a documented policy.

Typeform setup

Select the form and test the trigger with a submission you control. Give the email question a stable label, then map that answer into Mailthentic's required Email field. If the question was renamed after the Zap was built, retrieve a new trigger sample before remapping.

Jotform setup

Select the relevant form and use a test submission containing the email answer. Jotform may expose several email-like values if the form includes an account email and a respondent email. Inspect the sample and choose the respondent field deliberately.

Webflow setup

Choose the site and form in the trigger, submit a real test through the published form, and map the named email field. The Zap runs after Webflow records the submission. For a browser-side or server-side decision before storage, integrate the API into your own submission handler.

Use the returned form-verification fields

Map only the result fields that the destination needs. Do not invent a valid boolean or a request_id value when those fields are not part of the verified result contract.

Record the result before routing

Store status, reason, created_at, and the evidence your team actually uses. This creates an audit trail and lets a later automation change without losing the original result. Avoid copying every nested field into systems that do not need it.

Use a Filter only when appropriate

A Filter can stop later Zap steps, but it cannot undo the completed form submission. Use it to prevent a definite invalid result from entering an outreach sequence or to send risky and unknown cases to review. Do not collapse catch-all, unknown, role-based, and disposable into one rule. Read how Mailthentic statuses should be interpreted.

Handle each signal deliberately

• Invalid: preserve the reason and invite correction through an appropriate user flow.
• Disposable: decide whether temporary domains conflict with the form's purpose. A support form may accept them while an account or trial policy may not.
• Role based: a shared address can be legitimate. Route by context rather than rejecting it automatically.
• Catch all or unknown: keep the submission and seek stronger evidence. Do not represent uncertainty as a failed mailbox.

User experience and privacy

If the check influences access, explain what happened in plain language and provide a correction path. Verification does not establish ownership, so use an expected confirmation message where control of the address matters. Limit connected apps to those named in your privacy notice, avoid exposing results in public URLs, and keep API credentials out of form fields.

Testing and troubleshooting

Test one normal address, one malformed value, and one known disposable domain using records your team controls. Confirm that the right question maps in every platform and that the storage step receives the same submission identifier.

• No trigger sample: publish or enable the form as required by the platform and submit a complete test.
• Wrong email field: compare labels and raw sample values, especially when multiple email questions exist.
• Missing nested flags: retest Mailthentic and refresh fields.
• A Filter stops too much: inspect detailed status and reason rather than a derived yes or no.
• You need pre-submit checking: use an API implementation, because this Zap begins after submission.