Accepted email domains are used to verify that a user is employed at a member company before allowing the user to sign up as a company representative. Depending on the level of enforcement, company representatives and admins may not be allowed to enter non-company email addresses, even after the account is established. If your organization's site is configured to enforce accepted domains, each member company must provide a list of accepted domains for that company.

This requirement can be enforced at an escallating series of levels: on signup only, signup plus user tools, signup plus both user and admin tools. The first level, on signup only, provides the most generally useful application of the accepted domains restriction: a prescreening mechanism used to assure that new users are with a member company before granting company representative account privileges. Setting this feature at a higher level imposes certain inconveniences on users, since legitimate users may be prevented from switching to non-company email addresses when going on sabbatical, vacation or working from home.

An organization that enforces accepted domains has two options for implementing this feature on signup. The signup form may display a list of companies from which the user can select, or the form may collect the user's email address and the application will select the company for the user based on the domain of the email address provided by the user.

Domain checking is not applicable to individual memberships, staff companies or nonmembers. Organizations that offer company memberships and choose not to enforce domain checking may experience a greater incidence of unauthorized users signing up as company representatives than those that choose to enforce domain checking.

Companies add accepted domains as part of the signup process, and admins using the Add a Company or Edit a Company tool may enter or edit the list of accepted domains for a company in the Accepted Email Domains field. When accepted domains are enforced, the domain of an email address entered by a company representative will be compared to the accepted domains on the list. If the domain of the email address matches a domain on the list, the email address will be accepted.

A company's email domain is based on the domain of the company's URL, and appears in company email addresses following the @ symbol (e.g., username@example.com). Domains for companies based outside the United States use a slightly different format, some use '.co' instead of '.com' and all are appended by an extension representing the country, such as '.jp' for Japan, so an international domain would take the general form 'example.co.jp'.

An email address may also be based on a subdomain representing a particular division of the company. A subdomain includes more specific address information added to the domain string. For instance, subdomains of 'example.com' might include 'research.example.com' or 'products.example.com', and user email addresses for these divisions would take the general form 'username@research.example.com' or 'username@products.example.com'.

In domain matching, both of these subdomains contain the domain string 'example.com', so even if the subdomains weren't entered in the accepted domains list, email addresses using either of these subdomains would match the primary domain. However, if only the subdomain 'research.example.com' was on the accepted domains list, email addresses that didn't match the whole subdomain, such as 'username@example.com' or 'username@products.example.com', would not be accepted.

When accepted domains are enforced and a user tries to enter an email address with a domain that doesn't match a domain on the list, the user will be advised to provide an email address from an accepted domain and will not be able to change the email address for the account until an acceptable email address is provided. Depending on the level of enforcement, this may preclude a user from signing up, from changing their own email address via user tools or at the highest level of enforcement, prevent admins from changing the user's email address to the new address unless the domain is first added to the list by the organization admin or other authorized user.

The higher the level of enforcement, the more attention that must be paid to maintaining these lists. Limiting users to accepted domains after signup places extra demands on admins and is generally an inconvenience to users. This is discussed in more detail in the following sections.

Duplicate domain checking helps protect data integrity by eliminating the inadvertent creation of duplicate entries in the company database and enhances the enforcement of accepted domains. If the duplicate domains feature is turned on for your web site, Kavi® Members will check that domains added to the accepted domains list are unique by comparing a domain to other domains already on the list. If domains match, the application will display an error message.

This is especially useful when the company representative signup form is configured to match a user with their company based on email domain. If duplicate domain checking is not enabled and there are multiple company records in the database with the same domain—possibly as a result of entering different divisions of a company individually—the user is assigned to the first entry that matches.

The enforcement of accepted domains and duplicate domain checking features impose stricter requirements on database integrity, particularly on keeping the accepted domains lists up to date. This responsibility is shared by the company's primary contact, who is responsible for notifying the organization when company domains change or new domains are added, and the organization admin, who is responsible for updating the accepted domains lists. Additional care must be taken when performing batch updates to ensure that accepted domains are entered for every company and that duplicate companies (i.e. companies with the same accepted domain, rather than divisions with their own subdomain) do not exist in the database for optimal performance of this functionality. For instance, if the application is configured to match users with their companies on signup according to the domain of their email, signup will be disabled for companies with missing domains.

While domain checking may appear at first to be a security measure, it actually has little to contribute to system security except at the prescreening level. Beyond this level, the costs frequently begin to outweigh the benefits, placing increasing demands on admin support and increasing limitations on users with only marginal gains in security. Enforcement of accepted domains after the prescreening level is often more an issue of perceived authenticity than an actual security measure because it only limits the ability of the user to change the email address for the account. It doesn't prevent a user from logging in from wherever the user wishes and it provides no guarantee that a user still works for the company under which the user signed up.

The single greatest issue driving the escalation of admin costs and decreased user satisfaction revolves around bounced email and automated bounce handling. If a company's email domain changes and users are not allowed to change their own email addresses, messages sent from the organization to all users affected by the domain change will bounce until the company notifies the admin and the admin updates the company's accepted domains list. In the meantime, automated bounce-handling processes will go into effect. Depending on site configuration, this company's users' accounts may be inactivated—in which case these users will be unable to log in—and the users may be unsubscribed from mailing lists, committees, etc. Because admins are not automatically notified when email bounces, they will not be aware of the problem until contacted by the company. This can create a situation in which a company is unable to exercise its full membership benefits for some indefinite period of time while admins scramble to identify and undo actions performed by the bounce-handler.