--- title: "Authorized Domains" description: "Restrict form submissions to specific domains. Unauthorized submissions are automatically flagged as spam by Forminit." url: https://forminit.com/docs/authorized-domains/ --- # 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 1. Go to your form's **Settings** 2. Find the **Authorized Domains** section 3. Add your domain(s) to the whitelist 4. 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: 1. The submission is **not rejected** — it's still received 2. The submission is **flagged as spam** 3. It's routed to your **Spam folder** in the dashboard 4. 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 1. Go to your form's **Submissions** page 2. Click the **Spam** tab 3. Review flagged submissions 4. 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:** 1. Check the submission's referrer in the Spam folder 2. Verify the domain is in your authorized list 3. Ensure you've added both `www` and non-`www` versions 4. 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: 1. Add the new domain(s) 2. Keep old domains temporarily if redirects are in place 3. 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: 1. Using **API key authentication** instead of domain restrictions 2. Setting authentication mode to **Protected** for server-side submissions 3. Removing domain restrictions if all submissions come from your app --- ## Best Practices 1. **Always include both www and non-www versions** — Users may access your site either way 2. **Add all subdomains explicitly** — Root domains don't automatically cover subdomains 3. **Include development domains** — Add `localhost` for local testing 4. **Review your Spam folder regularly** — Catch any misconfigured legitimate submissions 5. **Use separate forms for different sources** — Makes it easier to track and manage submissions 6. **Combine with other security measures** — Domain restrictions work well alongside: - API key authentication - Cloudflare Turnstile, reCAPTCHA, or hCaptcha - Honeypot fields 7. **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. --- ## Related Documentation - [Form Blocks Reference](https://forminit.com/docs/form-blocks/) — Complete reference for all block types - [Cloudflare Turnstile Integration](https://forminit.com/docs/cloudflare-turnstile/) — Free, privacy-first CAPTCHA - [reCAPTCHA Integration](https://forminit.com/docs/recaptcha/) — Add CAPTCHA protection - [hCaptcha Integration](https://forminit.com/docs/hcaptcha/) — Alternative CAPTCHA solution - [Honeypot](https://forminit.com/docs/honeypot/) — Invisible spam protection - [API Reference](https://forminit.com/docs/submit-form-api/) — Full REST API documentation