> ## Documentation Index
> Fetch the complete documentation index at: https://filla.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Email verification

> Require respondents to verify their email address with a one-time code before submitting.

## What email verification does

Email verification (OTP) requires respondents to confirm they own the email address they entered by receiving and entering a 6-digit code. The form cannot be submitted until the code is verified.

This is configured on the **Email field**, not at the form level.

## When to use it

* Event registrations where you need to confirm the attendee can receive emails
* Account creation forms where a valid, owned email is required
* Gated content access where you need to confirm identity
* Any form where you want to prevent fake or borrowed email addresses

## How to enable it

<Steps>
  <Step title="Click the email field in the canvas">
    Open the email field's settings panel.
  </Step>

  <Step title="Find the Verification section">
    Expand the **Verification** section in the settings panel.
  </Step>

  <Step title="Toggle 'Verify email with a one-time code' on">
    Enable the toggle.
  </Step>

  <Step title="Set the code expiry (optional)">
    The **Code expires after (minutes)** setting controls how long the code remains valid. Default is 10 minutes.
  </Step>
</Steps>

## The verification flow for respondents

<Steps>
  <Step title="Respondent enters their email">
    They type an email address in the email field.
  </Step>

  <Step title="Respondent requests the code">
    A **Send verification code** button appears. They click it to trigger the code email.
  </Step>

  <Step title="Code is sent">
    Filla sends a 6-digit code to the email address. The send button has a 30-second cooldown to prevent abuse.
  </Step>

  <Step title="Respondent enters the code">
    A code input appears on the form. The respondent checks their inbox and enters the code.
  </Step>

  <Step title="Verification confirmed">
    On success, a green checkmark appears on the email field. The respondent can now submit the form.
  </Step>
</Steps>

## Settings on the email field

| Setting                               | Description                                                                                 |
| ------------------------------------- | ------------------------------------------------------------------------------------------- |
| **Verify email with a one-time code** | Enable OTP verification for this field.                                                     |
| **Code expires after (minutes)**      | How long the code remains valid. Default: 10 minutes. Only visible when verification is on. |

## What verification confirms

OTP verification confirms that the respondent has access to the inbox. It does not verify that:

* The email address exists at the domain level
* The domain has valid MX records
* The address can receive all types of email

For deliverability validation, use the [Email Validator](/docs/tools/email-validator) processor tool on your Airtable data.

## Common questions

<AccordionGroup>
  <Accordion title="What if the respondent doesn't receive the code?">
    They can click "Resend code" after the 30-second cooldown. Ask them to check their spam folder. The code comes from Filla's sending domain.
  </Accordion>

  <Accordion title="Can I use email verification alongside 'block free email providers'?">
    Yes. The provider block runs first. If the email is from a blocked domain, the respondent sees an error before they can even request a verification code.
  </Accordion>

  <Accordion title="Is the verification stored in Airtable?">
    The verification status is not stored as a separate field. The verified email address is stored in the email field as normal. The form will not submit without the verification being completed.
  </Accordion>

  <Accordion title="Does OTP verification add friction to the form?">
    Yes, it adds an extra step. Use it only when confirming email ownership is worth the added friction for your use case.
  </Accordion>
</AccordionGroup>