@Mail Domain Check

Wallet login · 2FA · transaction email

Verification email not arriving

Trace one missing message from the application event to the receiving mail system before increasing retries, changing DNS, or telling users to keep checking spam.

Start with the delivery boundary

A user saying "the email never arrived" describes the symptom, not the failing system. A wallet-login or 2FA message can fail before the application creates it, while the provider queues it, at a suppression rule, during SMTP delivery, or after the receiving server accepts it. Each layer has different evidence and a different owner.

Build a local incident response plan from the application, provider, SMTP, receiver, scope, timing, and authentication evidence already available. No address, code, token, message, or credential is entered.

Do not log or ask the user to send the verification code, reset token, session link, seed phrase, private key, or wallet signature. Correlate with a random internal message identifier and timestamps instead.

1. Prove the application generated one message

  • Locate the exact login, withdrawal, device, password-reset, or transaction event and its UTC timestamp.
  • Confirm the normalized recipient, template version, locale, sender identity, and provider request identifier without exposing the secret link or code.
  • Check idempotency, queue depth, worker errors, rate limits, regional routing, and feature flags. An HTTP request accepted by an internal queue is not yet provider acceptance.
  • Reject duplicate retry storms. A new request should invalidate or supersede earlier secrets according to the product's security model.

2. Follow the provider event, not the API response

Provider terminology varies, but a processed or accepted event usually means the provider can attempt delivery. It is not proof that the receiving mail system accepted the message. Use the provider message ID to find the next terminal or retrying event.

For Resend, use the provider-specific event map to separate queued, sent, suppressed, failed, delivery_delayed, bounced, and delivered without treating any earlier state as inbox placement.

For Supabase Auth, use the Supabase-specific boundary map to distinguish the Auth request, built-in SMTP restrictions, custom SMTP handoff, provider processing, receiver visibility, and a link that arrived but was consumed or expired.

For Auth0, use the Auth0-specific job map to separate signup or resend, an asynchronous verification-email job, a ticket that still needs delivery, tenant logs, the configured provider, receiver visibility, and link or OTP completion.

For Firebase Authentication, use the Firebase-specific request map to separate a Client SDK sending call, an Admin SDK link that still needs custom delivery, project and user state, operation-specific limits, receiver visibility, and action-code use.

For Amazon Cognito, use the Cognito-specific code-delivery map to separate the API response, user and recovery state, COGNITO_DEFAULT or DEVELOPER email mode, Amazon SES events, and receiver visibility.

Processed or queued
The provider accepted work. Check whether a later delivered, deferred, bounced, or dropped event exists.
Dropped or suppressed
Inspect the exact suppression reason, prior bounce, complaint, unsubscribe, invalid address, policy, or account restriction before removing anything.
Deferred
The receiving system temporarily rejected the attempt. Preserve the SMTP response and retry count; do not create an aggressive parallel retry loop.
Bounced
Treat a permanent denial differently from a temporary block. Correct the named condition before sending the same message again.
Delivered
The provider reports acceptance by a receiving server. This does not prove inbox placement, visibility, or that the user controls the mailbox.

3. Preserve the complete SMTP response

Keep the three-digit reply, enhanced status code, diagnostic text, recipient domain, attempted sending IP, and attempt timestamp. Under the SMTP model, a 4xx reply is transient and a 5xx reply is permanent for that attempt, but the enhanced code and receiver text identify the actual class of failure.

Decode the SMTP response locally. The pasted text stays in the browser and the result routes known Gmail codes to focused checks.

4. If the receiver accepted it, inspect receiver evidence

  1. Ask the test recipient to check spam, quarantine, category tabs, rules, aliases, forwarding, and mailbox storage through the mailbox's own interface.
  2. For a message that can be found, export the complete original header. A screenshot omits the authentication identities and delivery route.
  3. Read the final receiver's Authentication-Results, visible From domain, SPF identity, DKIM d= and s=, DMARC alignment, and newest Received fields.
  4. Compare the provider delivered timestamp with the receiver's first trusted handoff. Keep provider acceptance and inbox placement as separate measurements.

The browser-local header analyzer structures those fields without uploading the pasted header.

5. Check the public sender controls

For Gmail recipients, current sender guidelines require authentication and valid forward and reverse DNS, and they add DMARC alignment requirements for bulk senders. Authentication does not guarantee inbox placement, but missing or misaligned controls can produce rejection or spam placement.

  • Verify that the exact sending path has an SPF authorization or a valid DKIM signature, and that at least one passing identity aligns with the visible From domain for DMARC.
  • Use the real outbound sending IP from provider logs or the SMTP response to check PTR and forward confirmation. The web or MX server address may be unrelated.
  • Inspect current provider and receiver reputation, complaint, volume, consent, content, and rate-limit evidence separately. Public DNS cannot reveal those signals.
  • Inventory fallback, incident, and regional senders before tightening DMARC. A rarely used emergency route still needs authenticated receiver evidence.

Map each critical message path locally, including provider, visible From, Return-Path, DKIM identity, owner, receiver evidence, and rollback status.

Minimum incident packet

Application
UTC event time, random correlation ID, message type, template version, region, and provider request ID.
Provider
Processed, dropped, deferred, bounced, or delivered event with timestamps and the exact diagnostic reason.
SMTP
Complete reply, enhanced status code, receiving domain, sending IP, and retry attempt.
Receiver
Original header from a controlled mailbox when available, plus quarantine or rule evidence.
Public configuration
Visible From domain, SPF, DKIM selector, DMARC policy, and actual sending-IP PTR state at the incident time.

Recover without weakening the security control

Fix the failing layer, send one new controlled message through the same path, and require new provider and receiver evidence. Keep verification secrets short-lived and single-use. A fallback channel should be independently secured, rate-limited, and monitored; it should not silently bypass account-risk checks because email is delayed.

The free scanner reads public DNS and MTA-STS publication. It does not generate email, access provider logs, test SMTP delivery, inspect inbox placement, measure reputation, or prove that a user controls an address.

Primary references