When email one-time codes work as an authentik second factor
Email one-time codes are a reasonable second factor when a user population cannot install an authenticator app or carry a hardware key, and the organization accepts that the mailbox becomes part of the login chain. authentik's email authenticator setup stage, available from authentik 2025.2.0, registers an email-based authenticator that sends one-time codes as an MFA method. Once the stage is bound to a flow, users who reach it receive a code by email and enter it to complete sign-in. The stage registers the authenticator for the user, so the email address on the account becomes the factor's delivery point. The stage depends on mail delivery. Every code travels through SMTP, so a failed relay, a throttled sending domain, or a mailbox that is slow to receive turns into a login failure that looks like an authentication problem. Decide whether the stage uses global SMTP settings or its own stage-specific settings, and confirm that the sending account, relay and sender domain are the ones your mail team actively monitors. Email is also one option among several second factors authentik supports, alongside TOTP, Duo, SMS, static tokens and WebAuthn. Compare it against the users' actual devices before standardizing on it.
The risk question is whether the mailbox is a meaningfully independent factor. If an attacker who has the password can also read the user's inbox, a code sent there adds little protection beyond the password, so email codes suit lower-risk applications, transitional rollouts or populations with no other option far better than administrator accounts or systems that hold sensitive data. Ask your security team whether mailbox compromise is already in your threat model, and whether email accounts themselves use phishing-resistant MFA. Confirm the token expiry you intend to set in the stage and how throttling and attempt limits are handled in your authentik version before you depend on them. Document the decision so auditors and application owners can see why email codes were accepted for a given group.
Configuration options and when each fits
This table compares the main choices for an email one-time code stage: where SMTP settings come from, how long a code stays valid, and whether email is an extra method or a required one. Read each row against your risk level and your users' ability to reach their inbox during login. The main takeaway is that email codes are only as strong as the mailbox they land in, so the settings should be chosen with that in mind.
| Option | When it fits | What changes for users and administrators |
|---|---|---|
| Global SMTP settings | One mail relay serves all of authentik's email, and you want one place to rotate credentials | Users get codes from the same sender as other authentik mail. Administrators change the relay once, but a relay change also affects password reset and other notifications |
| Stage-specific SMTP settings | The email codes need a separate sender, relay or credentials from other authentik mail | Administrators maintain a second mail configuration per stage. Codes can be routed through a different path, which adds a setting to check during troubleshooting |
| Short token expiry | Your risk is elevated, such as privileged or administrator accounts, and users can open their mail quickly | Codes stop working sooner, so users who wait on slow mail delivery must request a new code. Expect more help desk contacts if mail is delayed |
| Longer token expiry | Users sometimes read mail late or work across slow networks, and your risk for the application is moderate | Fewer failed logins from delayed mail, but a captured code remains usable for longer. Pair longer expiry with throttling and reputation policies |
| Email as an additional method | You want a fallback for users who lack an authenticator app or hardware key during rollout | Users choose email at login alongside other methods. Administrators must still define which methods a user can enroll, and the weakest enabled method sets the effective strength |
| Email as a required method | Your policy mandates MFA for everyone and email is the only method you can support for some populations | Every user must reach an inbox at login, so a mail outage blocks sign-in. Administrators need a recovery path for locked mailboxes and users who change addresses |
Setting up the email authenticator in authentik
This sequence creates an email authenticator setup stage, routes SMTP settings to it, binds it into enrollment and validation, and proves a real sign-in works, including the path for users without a mailbox.
Confirm your authentik version supports the stage
Before building anything, check that your deployment runs authentik 2025.2.0 or later, since the email authenticator setup stage is available from that release. Confirm the version under the admin interface's system information view, and note whether it is on a supported line listed in the security policy. Done means you have recorded the exact version and can open the stage types list without errors.
Configure SMTP globally or per stage
Decide whether one outgoing mail relay serves all flows or whether this stage needs its own sender. Global SMTP settings live in the system configuration, while stage-specific settings override them for this stage only. Ask your mail team for the relay host, port, TLS mode, authentication method and a sender address that your domain's SPF and DKIM records already authorize. Done means the settings are saved and the sender address is one your mail team has approved.
Create the email authenticator setup stage
In the admin interface, create a new email authenticator setup stage and give it a name that describes its purpose, such as one for enrollment. Set the token expiry to the value your risk assessment approves, and choose whether the stage uses the global or its own SMTP settings. Done means the stage appears in the stages list with the expiry and mail settings you intended.
Bind the stage into the enrollment flow
Add the setup stage to the enrollment flow your users pass through, and place it after identity and password steps so the code goes to a verified user. Pair it with a user write stage so the registered email authenticator is saved to the account. Done means a test enrollment in a non-production tenant ends with the email authenticator attached to the test user's profile.
Add the stage to the authenticator validation stage
Open the authenticator validation stage used by your login flow and enable email as an allowed device class alongside any other factors you already run. Keep the order and conditions consistent with your other MFA methods so users see one predictable prompt. Done means the validation stage lists the email device class and a login attempt for a test user shows an email code option.
Test SMTP delivery before live users
Send a test enrollment and confirm the code arrives in an inbox outside your domain, not only in a local mailbox. Check the message headers for SPF, DKIM and DMARC results and confirm the sender name and reply path look correct. Review the authentik event log for the send event and any error from the relay. Done means a code arrives within the window you expect, with passing authentication results, and the log shows no delivery failure.
Verify token expiry and single-use behavior
Request a code, wait past the configured expiry, and attempt to use it. The sign-in should be rejected, and the user should be able to request a fresh code. Then use a valid code once and try it again to confirm it no longer works. Done means both checks behave as configured, and you have noted the expiry value in your runbook for support staff.
Test the login path for a user without a mailbox
Create a test account with no working mailbox and walk through sign-in to see what it does. Users who cannot receive email need an alternative path, such as another enrolled factor or an administrator-managed recovery process, which you must design before rollout. Confirm the account can still sign in with an approved method and that the failure message does not reveal account details. Done means you have a written fallback for these users and have tested it end to end.
Security risks of email codes and how to reduce them
An emailed code is only as strong as the mailbox that receives it. The cards below cover the failure points that matter most for authentik deployments: the mailbox itself, phishing, mail provider visibility, guessing and forwarding. Each one maps to a setting or check you can make before you rely on email for sign-in.
Mailbox takeover defeats the factor
If an attacker controls the mailbox, they receive the code as easily as the user does, so email is not an independent second factor. Treat the email account as the weakest link in the chain. Ask whether your mail tenant enforces its own strong MFA and conditional access, and whether users can add mail forwarding or delegates without review. Confirm that the email authenticator stage is never the only factor protecting administrator accounts.
**Phishing of one-time codes**
A code can be relayed in real time: a fake sign-in page asks for the password and then for the code the victim just received, and the attacker submits both within the expiry window. Shorter token expiry narrows that window but does not remove it. Review which applications sit behind the email factor and consider whether phishing-resistant methods such as hardware keys are required for them. Train users to enter codes only into the sign-in page they started from.
Mail provider visibility
Codes pass through your SMTP relay and your mail provider, which may log message bodies, retain copies or expose them to administrators. Confirm with your mail provider how long messages and delivery logs are kept and who can read them. Limit the SMTP account to sending only, restrict where authentik's log output goes, and make sure code values are not written to general application logs or shared monitoring tools.
Guessing without throttling
A six-digit code can be guessed if an attacker can submit many attempts before expiry. Check how authentik throttles repeated attempts against the email stage in your version, and confirm the behavior in your own test environment before you go live. Brute-force protection for email codes is a separate topic to plan for, and the throttle should be validated rather than assumed.
Forwarding rules and shared inboxes
Automatic forwarding rules, shared team mailboxes and mobile mail apps all widen the set of people who can read a code. An assistant, a helpdesk agent or a compromised forwarding rule can complete a login that was meant for one person. Ask users to report unexpected forwarding, review mailbox rules for privileged users, and avoid using shared mailboxes as MFA destinations.
Combining email with stronger factors
Email codes are most defensible as one step in a sequence rather than a lone gate for sensitive apps. Configure the authenticator validation stage so that high-risk applications require a second method, such as a hardware key or TOTP, and use the last validation threshold to limit how often email codes are requested. Monitor failed sign-ins and alert on bursts of code requests, and review those alerts as part of routine operations.
How throttling and attempt limits apply to email codes
Does authentik limit wrong attempts on email one-time codes?
Brute-force protection for email and SMS codes was added in authentik 2026.5, and it is covered in detail on the sibling page on brute-force protection for authentik MFA codes. Before you rely on it, confirm the exact behavior for the version you run, because limits, lockout periods and where the counter is stored can change between releases. Check the release notes for your version and the authentik security policy for the supported release lines. If you run a version earlier than 2026.5, plan compensating controls such as reputation policies and alerting on failed logins until you upgrade.
How does code expiry interact with repeated resend requests?
Each emailed code carries a token expiry that you set on the email authenticator setup stage, so a code is only usable inside that window. A resend request normally issues a new code, which raises a question you must test: whether the earlier code stays valid until its own expiry, or is invalidated as soon as a new one is sent. If older codes remain valid, an attacker or a confused user holds several live codes at once, which widens the guessing surface. Confirm this behavior in your version and decide whether a short expiry plus invalidation on resend suits your risk level.
What should I test before enabling email codes for production?
Test the full login path with a real mailbox you control, not only the success case. Request a code, let it expire, and confirm the rejection message and that a fresh code works. Request several resends in a row and check whether earlier codes still validate. Enter wrong codes repeatedly and confirm the attempt limit, lockout duration and the message a user sees. Finally, check that the same throttling applies to the stage whether the user is logging in through the web flow or through a bound client. Record the results against your version so the evidence survives later upgrades.
Can a resend request be used to flood a mailbox?
Yes, unless resend requests are limited, a script or a bot can trigger many emails to one address, which causes mail volume, user confusion and possible abuse of your sending domain. Ask whether your version limits how often a code can be sent to the same user or address, and whether that limit is per stage or global. Also review who can trigger the stage, since an unauthenticated start of a recovery or enrollment flow may be reachable from the internet. Pair the answer with monitoring of your SMTP provider's sending volume and bounce rate.
Who is responsible for throttling: authentik or my mail provider?
authentik controls the attempt counting and code validation inside the flow, while your SMTP provider controls delivery volume, rate caps and abuse filtering on their side. Neither replaces the other. Attempt limits stop guessing of a single code, but they do not stop a flood of emails if resends are not capped in authentik. Mail provider limits protect your sending reputation, but they do not know which login attempt is a guess. Ask your provider which sending limits apply to your account and confirm the authentik behavior for your version, then document both owners in your runbook.
Do attempt limits for email codes affect legitimate users?
They can. A user who mistypes a code several times, or who opens an old email after a newer one arrived, may be locked out for the configured period. Lockouts also generate help desk tickets, so the support cost of a strict limit is real even though the security benefit is clear. Set expiry and attempt thresholds together, tell users that the newest email is the one to use, and define how an administrator clears a lockout. Document the trade-off so that the decision is owned by someone who accepts it.
Can DeployOpen test email code throttling for our environment?
DeployOpen can plan and run the verification described above as part of an implementation, and it can run security testing against the login flow as a separate engagement in scope. Most engagements are fixed-scope, so the test cases, the versions covered and the deliverables are agreed in writing before work starts. The quote follows from that written scope. Ask for the test matrix, the evidence format and whether retesting after an upgrade is included. DeployOpen does not issue audit reports or certifications, so any compliance mapping remains with your independent auditor.
Limits to confirm before rolling out email codes
Email codes depend on several things outside the authentik stage itself: the authentik release line you run, the mail path your SMTP settings use, the token expiry you configure, the protocols that can carry a second factor, and where your mail provider stores messages. Confirm each one in your own environment before users are asked to enroll.
Confirm your authentik release line
The email authenticator setup stage is available from authentik 2025.2.0, but the security policy lists 2026.5.x and 2026.8.x as the lines receiving security fixes. Check which line your deployment runs and whether it has been upgraded in order. The project announces security releases at least 24 hours in advance, so plan a window to apply them. Ask your team who receives that notice and how quickly a patch can be tested and rolled out.
Test SMTP deliverability end to end
A code that never arrives is a lockout, not a second factor. Send test codes from the same SMTP relay, with the same sender domain, that production will use, to mailboxes on each major provider your users have. Check spam folders, SPF, DKIM and DMARC alignment, and whether your relay rate limits sends. Decide whether the stage uses global SMTP settings or stage-specific settings, and record which one each flow depends on.
Set and review token expiry
The stage has a configurable token expiry. Do not rely on a default you have not read. Confirm the value in the stage settings, then decide whether it fits how quickly your users read mail on mobile devices and how long a code should stay valid for an attacker who has the password. Document the chosen value so that support staff answer 'my code expired' questions the same way every time.
Check whether LDAP and RADIUS clients can use it
Email codes are delivered out of band to a user's inbox, which means an LDAP or RADIUS client that only sends a password has no step where the code can be entered. Before you promise email codes to those clients, test the bind or access flow you intend to use. Compare the result with the options described for code-based authenticators appended to the password, and confirm the behavior in your own version rather than assuming it.
Review mail provider data residency
Every one-time code passes through your mail provider, which may store message content and metadata in regions you have not chosen. Ask the provider where mail is processed and stored, what logs it keeps, and who inside the provider can access them. If your data protection rules restrict where personal data goes, record that answer as part of the approval for email codes, and consider whether an in-country relay is required.
Plan the account recovery path
If a user loses access to their mailbox, they also lose their second factor. Decide who can reset enrollment, how identity is confirmed before a reset, and whether recovery relies on another authenticator. Email codes also depend on the mailbox remaining under the user's control, so check how your organization handles mailbox takeover, shared inboxes and departed staff before treating email as a substitute for a stronger method.
Deciding whether email codes match your risk level
Email one-time codes are a reasonable second factor for some populations and a weak one for others, and the decision belongs to your organization's risk assessment, not to what authentik makes easy to configure. Start by classifying the people and applications the factor will protect. Email codes tend to fit low-to-moderate risk workforce access, such as internal tools with limited data, and they work well as a fallback method for users who cannot yet use an app or key. They are a weaker match for administrators, finance approvers, staff with access to regulated data, and any population where a compromised mailbox would give an attacker the password and the second factor at once.
The core weakness is that the second factor travels over the same channel an attacker may already control. If someone takes over a user's mailbox through phishing, mailbox compromise, or forwarding rules, the code arrives where they can read it. Email codes also depend on mail delivery, which is outside authentik's control, so a slow or filtered message becomes a login problem. Before you approve the method, confirm how your mail platform handles multi-factor protection for mailboxes, whether administrators can see forwarding rules, and how your SMTP relay is monitored. The email authenticator setup stage, available from authentik 2025.2.0, is the place where token expiry and SMTP settings are configured, so those values should reflect the risk tier you chose rather than defaults.
Higher-assurance populations usually need factors that do not depend on the mailbox. App-based one-time codes, push approval, and hardware keys with user verification keep the second factor on a device the user holds, and are the normal starting point for administrators and privileged access. Where your policy requires phishing-resistant authentication, check the specific assurance requirements with your auditor or compliance adviser, and treat any mapping of authentik controls to a framework as a separate exercise. Record the decision in writing: which groups may use email codes, which may not, the review date, and who approves exceptions. That record, rather than the existence of the factor, is what your risk owner and assessors will ask to see.
Questions buyers ask before setting up email codes in authentik
How much does it cost to add email codes to authentik?
The software is free to use under the open-source edition, so cost comes from the work around it: planning the flows, configuring SMTP, testing across user groups and handing over runbooks. Your internal staff time, any mail service fees and DeployOpen's fixed-scope fee are the cost components. The authentik pricing page lists Enterprise at $5 per user per month billed annually, but that edition is only needed for features such as Google Workspace or Entra ID integrations, not for the email authenticator itself. Ask for a quote built from a written scope that names the flows, user populations and mail setup involved.
How long does an email code rollout take?
Duration depends on how many flows change, how many user populations are involved and whether your mail infrastructure is ready. A single login flow with a well-known SMTP relay is a small change, while several enrollment, recovery and application flows with testing across user groups take longer. Confirm the schedule with the vendor and your own change process, and ask for milestones in the written scope: flow design, SMTP validation, pilot group, then broader rollout.
What does your team need to provide for email codes?
Expect to provide a sending mailbox or SMTP relay account, access to the mail domain's DNS records for SPF, DKIM and DMARC, and an administrator who can approve flow changes in authentik. You also need someone to write user communication explaining what the code email looks like, how long it lasts and what to do if it does not arrive. Ask the mail team early, because sending permissions and DNS changes often take the longest to approve.
Can our internal team set up email codes without a partner?
Yes, a team with authentik administration experience can add the email authenticator setup stage, configure SMTP and test a login flow on its own, because the stage is part of the 2025.2 feature set and is configured in the admin interface. The harder part is enforcement and testing: deciding which flows and applications require the code, handling LDAP and RADIUS clients, and proving that users cannot skip the stage. If that expertise is not in-house, a scoped engagement can cover those parts while your team keeps ownership.
What makes the effort grow for email codes?
Effort grows with the number of flows that need the code, the number of directories and applications that log in differently, and any mail deliverability problems. Legacy LDAP or RADIUS clients that cannot show a second prompt need a separate design, and messages landing in spam can stall the whole rollout until SPF, DKIM and DMARC are correct. Each additional sending domain, SMTP profile or user group adds test cases. Ask for these items to be listed as separate scope lines so you can see what drives the quote.
Are email codes safe enough for our risk level?
Email codes are a reasonable second factor for many internal and low-risk applications, but they depend on the security of the mailbox they are sent to. If an attacker controls the email account, the code arrives there too, so high-risk systems usually need a stronger method such as a hardware key or app-based codes. Review your risk model with your security team and your compliance advisers before choosing. Brute-force protection for email codes is a separate control to plan for in the same design.
How is DeployOpen engagement scoped for email codes?
Most DeployOpen engagements are fixed-scope, so the written scope names the flows, applications, user groups, SMTP setup, testing approach, documentation and handover before work begins. The scope also states what is out of scope, such as mailbox provider changes or other second factors. Ask for deliverables such as a flow map, configuration record, test results and an operations runbook, and confirm acceptance criteria in writing. Ongoing support and upgrades are handled as retainers, separate from the initial build.
How DeployOpen scopes and delivers authentik MFA work
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, including authentik. For email one-time codes, we start from the risk your users and applications face, then configure the email authenticator stage, SMTP delivery and token handling to match the decision you reach.
How we scope
- Written scope lists which applications and user groups receive email codes, and which must use a stronger factor.
- We confirm the authentik version in use, since the email authenticator stage requires 2025.2.0 or later.
- Scope records the SMTP relay, sender domain and token expiry that you approve before any build starts.
How we build
- We configure the email authenticator setup stage and bind it to the authentication flows you agreed.
- We set global or stage-specific SMTP settings and test delivery from the network zones authentik runs in.
- We review how code throttling and attempt limits are configured, and document any gaps against your policy.
How we hand over
- You receive the flow and stage configuration, SMTP settings reference and a record of the test results.
- Runbooks cover enrollment, resending codes, mailbox lockouts and what to do when email delivery fails.
- Documentation maps the MFA decisions to your access control requirements so your auditors can review them.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Quotes follow from the written scope, so ask us to itemize the stages, SMTP work and testing included.
