Authorized Domains

Control which websites can submit to your forms using domain restrictions.

Security Feature: Submissions from non-authorized domains or referrers will be flagged as spam and routed to your Spam folder.

Overview

Authorized Domains let you whitelist specific domains that are allowed to submit to your forms. This prevents unauthorized websites from using your form endpoint and helps protect against spam and abuse.

When you add authorized domains to your form:

Submissions from listed domains are processed normally
Submissions from unlisted domains are flagged as spam
Subdomains can be whitelisted individually or with wildcards

When to Use Domain Restrictions

Use Case	Recommendation
Production website with known domain	✅ Enable with your domain(s)
Multiple environments (staging, production)	✅ Add all environment domains
Public API integration	❌ Consider API key authentication instead
Development/testing	Add `localhost` or disable temporarily
Embedded forms on third-party sites	✅ Add each authorized site

Adding Authorized Domains

Go to your form’s Settings
Find the Authorized Domains section
Add your domain(s) to the whitelist
Save changes

Valid Domain Format

A valid domain requires a host and must not include:

Path (/page)
Port (:3000)
Query string (?param=value)
Fragment (#section)
Protocol (https://)

Examples:

Input	Valid	Notes
`example.com`	✅	Root domain
`www.example.com`	✅	Subdomain
`app.example.com`	✅	Subdomain
`staging.app.example.com`	✅	Nested subdomain
`localhost`	✅	Local development
`https://example.com`	❌	Remove protocol
`example.com/contact`	❌	Remove path
`example.com:3000`	❌	Remove port
`example.com?ref=nav`	❌	Remove query string

Subdomain Handling

Each subdomain must be added individually. The root domain does not automatically authorize subdomains.

Example Configuration:

If your form is embedded on multiple subdomains:

example.com
www.example.com
app.example.com
blog.example.com

All four entries are required to accept submissions from each subdomain.

Development and Staging

Local Development

Add localhost to your authorized domains during development:

localhost

Note: Port numbers are not validated. localhost covers localhost:3000, localhost:5173, etc.

Multiple Environments

For projects with staging and production environments, add all domains:

localhost
staging.example.com
example.com
www.example.com

How Spam Flagging Works

When a submission arrives from a non-authorized domain:

The submission is not rejected — it’s still received
The submission is flagged as spam
It’s routed to your Spam folder in the dashboard
You can review and recover legitimate submissions if needed

This approach ensures you don’t lose submissions due to misconfiguration while still protecting against abuse.

Checking Spam Submissions

Go to your form’s Submissions page
Click the Spam tab
Review flagged submissions
Mark legitimate submissions as “Not Spam” to move them to your inbox

Common Configurations

Single Website

example.com
www.example.com

Website with App Subdomain

example.com
www.example.com
app.example.com

Multi-tenant SaaS

example.com
*.example.com

Note: Check if wildcard subdomains are supported in your plan.

Development + Production

localhost
127.0.0.1
dev.example.com
staging.example.com
example.com
www.example.com

Embedded Forms on Third-Party Sites

If you allow partners or customers to embed your form on their websites, add their domains:

example.com
www.example.com
partner-site.com
www.partner-site.com
customer-website.org

Consider creating separate forms for each partner to track submissions by source.

Troubleshooting

Submissions Going to Spam

Problem: Legitimate submissions are being flagged as spam.

Solutions:

Check the submission’s referrer in the Spam folder
Verify the domain is in your authorized list
Ensure you’ve added both www and non-www versions
Check for typos in your domain configuration

Form Not Working in Development

Problem: Local form submissions are flagged as spam.

Solution: Add localhost to your authorized domains:

localhost

Form Not Working After Domain Change

Problem: Submissions stopped working after changing your website’s domain.

Solution: Update your authorized domains list:

Add the new domain(s)
Keep old domains temporarily if redirects are in place
Remove old domains once migration is complete

Submissions from Mobile Apps

Problem: Mobile app submissions are flagged as spam.

Solution: Mobile apps don’t have a referrer domain. Consider:

Using API key authentication instead of domain restrictions
Setting authentication mode to Protected for server-side submissions
Removing domain restrictions if all submissions come from your app

Best Practices

Always include both www and non-www versions — Users may access your site either way
Add all subdomains explicitly — Root domains don’t automatically cover subdomains
Include development domains — Add localhost for local testing
Review your Spam folder regularly — Catch any misconfigured legitimate submissions
Use separate forms for different sources — Makes it easier to track and manage submissions
Combine with other security measures — Domain restrictions work well alongside:
- API key authentication
- reCAPTCHA or hCaptcha
- Honeypot fields
Document your domains — Keep a record of why each domain is authorized

Domain Restrictions vs. API Authentication

Feature	Domain Restrictions	API Key Authentication
Best for	Client-side forms	Server-side integrations
Security level	Medium	High
Setup complexity	Simple	Requires backend
Mobile app support	Limited	Full
Spam handling	Flagged, not blocked	Rejected if invalid
Rate limits	Standard	Higher limits

For maximum security, use both domain restrictions and API authentication with a server-side proxy.

Form Blocks Reference — Complete reference for all block types
reCAPTCHA Integration — Add CAPTCHA protection
hCaptcha Integration — Alternative CAPTCHA solution
Honeypot — Invisible spam protection
API Reference — Full REST API documentation