Email sign-in: magic link or one-time code
M7 consumer accounts can sign in using a link or a six-digit code delivered together in one email. Both prove access to the same verified email address; using either successfully makes both unusable for another sign-in.
Start from the application's normal M7 sign-in and choose Sign in with an email link or code. The address must already be verified and active on a single active M7 consumer account. Email sign-in does not create an account or link accounts by matching email addresses. The account need not have a password.
Complete a sign-in
- Enter the account's verified email address and select Send link and code.
- Complete either option below before the email expires.
- If the account's Email sign-in two-factor setting is enabled, enter a current authenticator code or select Use a recovery code.
- Continue through any required authorization review and return to the application.
| Option | What to do |
|---|---|
| One-time code | Enter the six-digit code from the email on the original M7 sign-in page. Keep any leading zeroes. |
| Magic link | Open the email link in the browser where sign-in began. Check the displayed email address, then select Confirm email sign-in. |
The magic-link confirmation page displays Signing in with the requested email address before enabling confirmation. Loading those details does not use the link or sign the user in. Simply opening or previewing the link does not consume it; explicit confirmation is required.
The page shows progress during submission, green success feedback while the next page loads, and red errors when a step fails. Return to site provides an exit, including when the sign-in request is unavailable. If details cannot load, retry the details lookup or start again from the application.
Use the original browser
The email request is bound to the browser that started it. Keep that browser's cookies and site storage available until sign-in completes. A new tab in the same browser profile can open the link. A different browser, another profile, or a normal window outside the originating private session cannot complete it.
Private browsing works while that private session remains open. If the email opens in another browser, return to the original sign-in page and enter its code there. An unsuccessful visit from another browser does not consume the request. After closing the original private session or clearing its site storage, start a new sign-in from the application.
Expiry, resend, and retries
- The email link and code expire after ten minutes. The authorization request must also remain valid; an expired authorization can require restarting even before the email's expiry.
- Wait at least one minute between email requests. A successfully issued replacement for the same sign-in invalidates the previous link and code; use the newest message.
- Five incorrect email-proof attempts exhaust a request. The account also has limits of five issued requests and ten incorrect proof attempts in a 15-minute window. Requesting another email does not reset that shared budget. Additional request limits apply by IP address.
- When email proof succeeds and two-factor verification is required, complete that next step within five minutes and while the authorization remains valid.
- Email proof is single-use even if a later step or network request fails. A terminal error requires a new sign-in; do not repeatedly reuse the old message.
The send confirmation is deliberately generic. It does not reveal whether an
address is registered, verified, active, uniquely associated with an account,
or currently eligible for another email. Check the address and spam folder,
wait before resending, or use another available sign-in method. If the page
reports an operational error, an opaque trace_id can help support locate
the failure; do not send support the email link, code, or other credentials.
Two-factor settings and recovery
The independent Email sign-in setting in M7 two-factor settings applies to both magic links and email codes. When enabled, successful email proof is followed by authenticator or recovery-code verification. When disabled, email proof completes this authentication step without an email-specific second factor. The setting defaults to off and requires a linked authenticator and a current authenticator code to change.
Turning this setting off does not turn email sign-in itself off. Password, Device Code, and account/session checks have their own settings. Later reuse of an account signed in by email follows the account/session policy.
The hosted recovery-code option defaults to Disable two-factor authentication. Successful recovery with that option unlinks the authenticator and turns all its checks off. Keeping it linked requires another unused code for a later recovery operation; the final recovery code always unlinks it. See two-factor authentication and recovery for the full behavior. Email sign-in by itself does not reset an authenticator or bypass an enabled email two-factor check.
Application integration
Applications continue to use authorization code with PKCE.
Send the user through /authorize; M7 presents email sign-in within the hosted
consumer login. Keep the original state, nonce, and PKCE verifier until
completion. Do not collect the user's emailed link, email code, authenticator
code, or recovery code in the application.
On success, process the normal authorization callback
and exchange its authorization code at the token endpoint. The email code is
not the OAuth authorization code. Email sign-in adds no grant type, discovery
endpoint, or amr/acr assurance guarantee. Validate the resulting tokens
using the existing token contract.
This hosted option supports consumer browser authorization. Device Code
approval retains its own sign-in flow, fresh federated authentication follows
the provider's policy, and refresh-token and machine requests remain
noninteractive. Email sign-in cannot satisfy prompt=none; start an
interactive authorization when user action is required.
Account-management integrations can read and change the email two-factor choice through the API User settings contract.