Troubleshooting Entra External ID verification emails

A customer reaches the Microsoft Entra External ID sign-up page, enters an email address and sees the message that a verification code was sent. Nothing arrives. Resending changes nothing. The application team checks spam folders, then the user flow, then Service Health. Everything looks normal, yet registration cannot continue.

This failure sits across several systems: the application’s user flow, Entra sign-up processing, Microsoft’s delivery service, public mail transport and the recipient’s filtering. Treating it as one generic “email problem” produces random changes and weak evidence. The right approach is to identify the last stage that can be proved.

Start with the boundary of the problem

Confirm the scenario before changing anything:

• The directory is an External ID external tenant for customers, rather than a workforce tenant sending B2B invitations.
• The failure occurs during self-service sign-up, at the email ownership verification step.
• The application is connected to the expected sign-up and sign-in user flow.
• The selected identity provider is still the intended option, such as Email with password or Email one-time passcode.
• The user is not confusing a sign-up verification message with an application-generated welcome email or a B2B invitation.

Those distinctions matter because B2B email one-time passcodes, customer sign-up verification and application mail have different control planes and logs.

Build one controlled reproduction

Do not begin with repeated presses of Resend code. A useful test has one attempt, one recipient and one timestamp.

For each test, record:

Evidence	Why it matters
Exact UTC start time	Aligns Entra, application and recipient mail logs
Application and user-flow names	Proves which policy processed the request
Recipient domain category	Separates one mail system from a broader failure
Request and correlation IDs	Gives Microsoft Support a traceable transaction
Error code and failure reason	Distinguishes an expected interruption from an actual failure
Browser and network used	Identifies a client-specific pattern without exposing personal data

Use test addresses at two independently operated mail providers when permitted. For example, test one controlled corporate mailbox and one separate public provider. Do not publish the addresses, tenant identifiers, IP addresses or correlation IDs.

Space attempts apart. Aggressive retries can add throttling or anti-abuse behaviour to the original problem and make the evidence harder to interpret.

Read the sign-up logs correctly

In the external tenant, go to Entra ID > Monitoring & health > Sign-in logs and select the User sign-ups view. Filter to the narrow UTC test window, then open the matching event.

Preserve the request ID, correlation ID, error code, failure reason and the ordered sign-up steps. Microsoft documents several sign-up codes, including:

• 1002013: the user was prompted for an email one-time passcode. This is an expected interactive interruption. It does not prove that the message reached the recipient.
• 50181: the supplied OTP could not be validated.
• 50182: the OTP had expired.
• 399279: account creation failed during self-service sign-up.

A generic sign-in event or an earlier error from another attempt should not be attached to the current failure without matching time and correlation evidence.

What the logs cannot prove

The sign-up logs are valuable, but a built-in user flow does not give the tenant administrator a complete message-delivery trace. You generally cannot see every internal handoff, suppression decision, retry, SMTP response or reputation control applied by Microsoft’s sending service.

That limit changes the goal. You are not trying to prove an internal cause from incomplete logs. You are building enough evidence to show where customer-visible diagnostics end.

Verify the user flow without weakening it

Open External Identities > User flows, select the flow associated with the application and check:

1. The application is still assigned to this flow.
2. The intended email identity provider remains selected.
3. Required attributes have not changed in a way that stops the journey before verification.
4. Custom authentication extensions are either absent or have their own successful execution evidence.
5. Branding changes have not altered a link or domain used to start the flow.

Avoid disabling security controls or switching identity providers in production simply to see whether delivery changes. Clone the flow or use a non-production application for configuration comparisons.

Ask the recipient side a precise question

“Please check spam” is not a delivery investigation. Give the mail administrator the test address, UTC window and expected Microsoft-originated verification message, using a private channel.

Ask them to check:

• message trace or delivery logs;
• gateway rejection, deferral and quarantine records;
• URL rewriting, attachment inspection and impersonation policies;
• block lists or rules applied before the mailbox;
• mailbox rules and storage restrictions;
• any upstream filtering service not represented in the mailbox console.

If a receiving gateway records a rejection, use its SMTP status and enhanced response code. If multiple independent providers show no inbound transaction for controlled attempts, that is useful evidence of an upstream delivery or suppression issue. It is still not proof of a Microsoft service incident.

Test for scope, not volume

Build a small matrix:

Test	Result	Interpretation
One address fails, others succeed	Recipient-specific	Investigate that domain, address or reputation path
One domain fails, unrelated provider succeeds	Domain/path-specific	Check that domain’s gateway and DNS/mail controls
Multiple independent domains fail	Broader service or tenant path	Preserve correlations and escalate
One app fails, another app on the same flow succeeds	App/request context	Compare redirect URI and flow assignment
All apps on one user flow fail	Flow or tenant scope	Compare with a controlled flow before changing production

Stop once the scope is clear. Generating dozens of verification messages does not improve the diagnosis.

Check current service information

Review Azure Service Health for the relevant subscription and region, and check Microsoft’s published External ID known-issues page. Record what was visible at the time of the test.

The absence of an advisory is not evidence that the service is healthy for every tenant and worker. Service Health normally reflects confirmed issues with a defined impact scope. A tenant-specific suppression or a small platform fault might require support correlation before it becomes visible.

Add application telemetry around the journey

Your application cannot observe Microsoft’s internal email send, but it can record the customer journey without storing sensitive form data.

Useful fields include:

• UTC timestamp;
• application deployment version;
• generated request or operation ID;
• user-flow identifier;
• callback success or failure category;
• duration to the next step;
• a one-way, rotating diagnostic hash if you need to correlate repeated attempts without retaining an email address.

Do not log the verification code, token, raw email address or authentication response payload. If you use a hash, document its retention and make sure it cannot become a permanent user identifier.

Use retries as resilience, not diagnosis

The sign-up page owns the verification-code resend experience. Your application should not create an automated loop that repeatedly starts sign-up or asks the user to request codes.

Provide a calm recovery message instead:

1. Wait a few minutes.
2. Check junk/quarantine.
3. Request one new code.
4. If it still does not arrive, use a support path that captures the UTC time and correlation ID.

Do not tell the user that a code was delivered unless you have recipient-side evidence.

Escalate with a support-ready evidence pack

Escalate when controlled tests fail across independent recipient systems, user-flow configuration is unchanged, and the sign-up logs do not provide a customer-remediable error.

Prepare:

• tenant and application identifiers;
• user-flow name and identity-provider type;
• exact UTC timestamps;
• request and correlation IDs;
• sign-up error codes and failure reasons;
• recipient domains, supplied privately;
• receiving gateway trace results;
• Service Health and known-issues checks;
• a short statement of business impact;
• the last known successful time.

Send this material only through the private Microsoft support channel. A public Q&A thread is the right place for redacted diagnostic logic, but not for tenant identifiers, addresses, screenshots with personal data or correlation records.

Ask the case owner to determine whether the transaction was accepted by the verification-email service, suppressed or throttled, handed to downstream transport, or rejected before handoff. That is a specific investigation request rather than a generic “email did not arrive” report.

Validate recovery

When delivery resumes, do not close the incident after one successful message. Run a small, predefined validation set:

• two independently hosted recipient domains;
• one attempt per address;
• successful code receipt within the expected period;
• successful code validation;
• successful completion of account creation;
• expected sign-up log entries;
• no unexplained increase in failures for the next monitoring window.

Record whether recovery followed a configuration correction, recipient-policy change, support action or spontaneous platform recovery. If the cause remains unknown, say so. A restored service is not automatically a proven root cause.

A reusable runbook

The runbook can be reduced to eight decisions:

1. Confirm this is customer sign-up verification, not B2B or application mail.
2. Capture one controlled attempt with UTC time and correlation data.
3. Read the External ID user sign-up event and interpret its code correctly.
4. Verify application-to-user-flow assignment and identity-provider configuration.
5. Trace the same attempt at the receiving mail system.
6. Compare a minimal set of independent recipient domains.
7. Check published service information without treating silence as proof.
8. Escalate the redacted evidence pack through a private support case.

That process avoids two common mistakes: weakening the user flow in production and claiming a platform incident without evidence. It also gives Microsoft Support the data needed to inspect the part of the delivery pipeline that customers cannot see.

References

• Troubleshoot Microsoft Entra sign-up errors
• Create a sign-up and sign-in user flow for an external tenant
• Known issues with Microsoft Entra External ID
• Get support for Microsoft Entra ID