Implementing email-verified user registration in Drupal

Allowing visitors to create accounts can support member areas, saved content, community discussions and customer workflows. Email verification adds an important control: the person registering must prove access to the address supplied before the account becomes usable. Drupal’s core User module provides this process without requiring a custom registration system.

A reliable implementation involves more than enabling a checkbox. You need to choose the correct registration policy, configure outgoing mail, adapt the account messages, test the verification link and protect the form from automated abuse. These details matter for Australian websites serving users in Sydney, Melbourne, Brisbane, regional areas and across different mobile networks.

Choose the right registration policy

Drupal’s account settings are available at /admin/config/people/accounts. The Who can register accounts? setting controls whether account creation is restricted to administrators, available to visitors, or available to visitors with administrator approval. For ordinary email verification, select Visitors rather than an approval workflow.

The relevant option is Require email verification when a visitor creates an account. When enabled, Drupal creates the user account in an inactive state and sends a verification message to the submitted address. The link in that message allows the person to verify the address and activate access according to the site’s account workflow.

Email verification should not be confused with administrator approval. Verification confirms control of an email address, while approval requires a staff member to review and enable the account. A community site may use both, but a small Australian business site will often need verification without adding a manual approval queue.

Drupal also lets administrators choose whether visitors can select a username or whether the username is generated from the email address. Avoid exposing unnecessary account details. A clear registration form should request only the information required for the service, such as an email address, password and possibly a display name.

Enable core email verification

In the administration interface, go to Configuration, People, and Account settings. Under registration settings, enable visitor registration and tick the email verification requirement. Save the configuration, then inspect the page again to ensure the setting remained enabled.

The same configuration can be managed with Drush, which is useful for development, staging and production deployments:

drush config:set user.settings register visitors -y
drush config:set user.settings verify_mail 1 -y
drush cr

Run these commands from the Drupal project directory and check the resulting configuration before applying them to a live site. Configuration import is usually preferable for a team-managed project, because the setting can be committed to version control and deployed consistently.

The verification email is generated by Drupal’s User module. A newly registered account remains blocked until the recipient follows the verification or one-time login link. The link is intended to be used once, so it should be tested from a private browser window rather than by repeatedly opening an old message.

If the account holder loses the email, the password reset process may help, depending on the account state and site configuration. Administrators can also inspect the user account and resend or manage access through the People administration screen. Avoid manually activating accounts as a routine workaround, because doing so removes the email ownership check.

Configure dependable outgoing mail

Drupal can create the registration message correctly while still failing to deliver it. The site’s default mail system may rely on the web server’s local sendmail service, which is frequently restricted by Australian hosting providers and is more likely to be filtered by Gmail, Outlook or corporate mail systems.

Set a recognisable sender address under Configuration > System > Basic site settings. Use an address on the site’s own domain, such as accounts@example.com.au, rather than a personal Gmail address. Configure the domain’s SPF, DKIM and DMARC records through the DNS provider. These records improve reputation and help receiving systems identify legitimate mail.

For production sites, use a maintained SMTP or Symfony Mailer integration that is compatible with the installed Drupal version and chosen provider. The provider may be a transactional email platform, a Microsoft 365 tenant or another authenticated service. Store credentials outside the repository, preferably in environment variables or the hosting platform’s secrets store.

Test delivery to several destinations, including Gmail, Outlook and an Australian business mailbox. A user on an NBN connection in regional New South Wales may receive messages differently from someone using a corporate network in Melbourne, but the important test is whether the message arrives, displays correctly and contains a usable link.

Edit the registration experience

Core account settings include the text used in account emails. Review the account creation and welcome messages under the user configuration page, and replace technical wording with language that matches the site. Explain what the recipient should do, where the link leads and what to do if the message was unexpected.

A useful message identifies the website, includes the account name or email address, gives a clear verification instruction and provides a support contact. Do not place marketing promotions in the verification email unless the message remains clearly transactional and complies with the applicable rules.

For more substantial changes, create a custom theme template for the registration form or use a form alter hook. For example, a custom module can alter the user registration form while preserving Drupal’s validation and submission handlers:

function example_form_user_register_form_alter(
  array &$form,
  \Drupal\Core\Form\FormStateInterface $form_state,
  string $form_id
): void {
  $form['account']['mail']['#description'] =
    t('Use an address you can access. We will send a verification link before your account is activated.');
}

The exact form structure can vary between Drupal versions and contributed modules, so inspect the rendered form and confirm the target element before deploying custom code. Keep the core email verification logic intact rather than replacing it with a second registration mechanism.

Make the form accessible and mobile-friendly. Use visible labels, meaningful error messages and adequate contrast. Many registrations occur on phones, so test keyboard navigation, smaller screens and pasted passwords. A short line explaining that verification messages may appear in Junk or Spam prevents support tickets without encouraging users to bypass the process.

Test the complete registration workflow

Test with a new address that has never been used on the site. Submit the form, confirm that Drupal creates the account in the expected state and inspect the email source as well as its rendered appearance. Check the sender, subject, site name, links, line wrapping and any unsubscribe or privacy wording that has been added by an external mail provider.

Open the verification link in a private browser session. Confirm that the account becomes active, that the user is directed to the intended page and that the link cannot be reused in a way that creates an unintended session. Also test an expired or malformed link and verify that Drupal shows a useful error rather than a PHP warning or a blank page.

Repeat the test with an existing email address. The site should not expose excessive information about whether an account exists, particularly on a public registration form. Check password reset, login before verification, logout, account cancellation and administrator-created accounts as separate paths.

Test mail failure as well. Temporarily use an invalid mail configuration in a staging environment and observe the logging behaviour. Review Reports > Recent log messages and the mail provider’s event log. Errors should be visible to administrators without displaying server credentials or internal paths to visitors.

Protect privacy and reduce registration abuse

Email verification reduces fake accounts, but it does not stop bots from submitting the form. Add a suitable CAPTCHA or challenge through a maintained Drupal module if automated registrations become a problem. Rate limiting, WAF rules and sensible hosting controls can provide additional protection without making registration difficult for genuine users.

Treat the email address as personal information. Explain why it is collected, how it is used and how long account data is retained in the privacy notice. For an Australian organisation, review the Australian Privacy Principles and the Privacy Act obligations that apply to the business. A verification email is generally part of account administration, while promotional email usually requires separate consent and unsubscribe handling under the Spam Act 2003.

Do not automatically subscribe new users to a newsletter during account creation unless the consent process is explicit and separate. A preselected marketing checkbox can create compliance and trust problems. Store only the data needed for the account, restrict access to user administration and ensure exported or backed-up data receives appropriate protection.

Use HTTPS across registration, login and verification pages. Set a suitable trusted host configuration, keep Drupal core and contributed modules updated, and avoid logging verification tokens. If a reverse proxy, CDN or security service sits in front of Drupal, check that it does not cache personalised registration responses or alter the verification URL.

Compare core and customised approaches

Drupal core is normally the best starting point because its account entity, permissions, mail API and password handling already work together. A contributed module can be appropriate when the site needs profile fields, approval queues, social login, invitation codes or a redesigned verification process, but every additional module increases maintenance and upgrade considerations.

Custom code is justified when registration is connected to an external CRM, a paid membership platform or a specialised onboarding process. In that case, keep Drupal responsible for password storage, account status and access control unless there is a strong architectural reason to replace those systems. Integrations should also handle failed API calls without leaving users in an unclear account state.

Approach	Suitable use	Main benefit	Main consideration
Drupal core settings	Standard visitor registration	Minimal maintenance and familiar administration	Limited workflow customisation
Core settings with a mail provider	Production sites requiring dependable delivery	Better authentication, logs and deliverability	Provider cost and DNS configuration
Contributed registration module	Profile, approval or invitation workflows	Adds features without building everything	Check Drupal version support and security history
Custom module	CRM or membership integration	Precise control over business rules	Requires testing, maintenance and secure coding
Manual administrator activation	Small, private membership lists	Direct human review	Slow, inconsistent and unsuitable for open registration

Before launch, verify the registration policy, email sender, DNS authentication, mobile layout, account status transitions and privacy wording. Confirm that configuration is included in deployment files and that the production mail service is separate from development mail. Drupal’s email verification feature is straightforward when these operational details are treated as part of the implementation rather than as an afterthought.