What is a domain restricted form?

Two checks that share one name

The first kind is about people. The form asks the respondent to sign in and compares the domain of their email address with an allowed list, so a survey meant for staff at one company only works for addresses at that company. The second kind is about pages. The form looks at the address of the website it is being shown inside and refuses to load anywhere that is not on the list. One restricts who answers, the other restricts where the form appears, and neither does the other's job. A staff survey protected only by a website check is open to anybody who finds the link, and a widget protected only by an email check forces every visitor on your site to sign in.

How each check actually works

An email domain rule is only as strong as the account behind it. It trusts that the person controls the address they signed in with, so it works well where accounts are verified and badly where anyone can type any address. It also checks the address, not your staff directory, so a contractor on a different domain needs adding by name and a leaver who still controls an account keeps access until the rule changes. A website rule depends on what the browser reports. When a page frames another page, the framed page can see the address of its parent, and it compares that with the list. That stops a form being lifted onto somebody else's site in an ordinary browser, but a request made with a script outside a browser can claim any origin it likes.

Where each one belongs

Use the email domain kind for internal requests, staff surveys, member ballots and anything where a response needs to come from inside an organisation. Use the website kind when a form sits inside your own pages, such as an enquiry form on a clinic website, and you want a copied embed code to fail on other sites. Use neither as the only protection for sensitive information. A website check is a courtesy lock, and an email domain check tells you that somebody with the right kind of address opened the form, which is not the same as knowing which person answered. Where both matter, such as a staff form placed on an intranet page, choose the check that protects the answers, which is almost always the email domain, and accept that the form can also be reached by link. A rule nobody can explain to the people it keeps out will be switched off the first time it blocks somebody senior.

Common mistakes

The most frequent is choosing the website kind for an internal form because the word domain sounded right, then discovering the form is open to anyone with the link. The second is forgetting the site that is actually serving the page: a form embedded on a staging site, a www and a bare domain, or a booking page on a separate host all need to be on the list before launch day. The third is testing only as the owner. Owners usually bypass access rules in form tools, so open the published form in a private window, from the real page, before telling anybody it works.

How it works in this form builder

The access type called domain restricted is the website kind. It is labelled for iframe embedding and takes a list of Allowed Parent Domains, one per line; leaving the list empty lets the form open anywhere, and a page that is not on the list shows an access denied message. The builder itself describes it as a light safeguard rather than strong security and points to secret key or login required for private forms. Restricting a form to company email addresses is done with login required instead, by adding an entry such as @harbourline.com.au to the allowed list, or by switching on Allow Any Signed User. A form has one access type, and access settings are stored with each published version, so a change takes effect when the form is published.

Questions people ask