“My verification email hasn’t arrived” isn’t one single failure. It may still be waiting in the sender’s queue, the address may contain a one-character typo, the sender may have rejected the temporary domain, or an older code may have been invalidated by a newer request. Once you hold the variables steady, waiting becomes a diagnosable process.
The first step isn’t refreshing—it’s freezing the variables
After submitting, don’t change the address or click “Resend” repeatedly. Compare the complete email address you entered with the address on the current page, character by character, paying special attention to random prefixes, hyphens, and the domain. Browser autofill can sometimes replace the temporary address with your primary email, and refreshing the inbox won’t fix that.
Also note roughly when you clicked submit and what the page reported. If the sender clearly says “Email sent,” the request passed at least the front-end validation. If the button keeps spinning, the page reports too many attempts, or it directly says the domain isn’t supported, the problem is still in the sender’s process—don’t keep waiting.
Keep one address, one request, and one timestamp fixed. During troubleshooting, manually refresh the inbox only; change nothing else.
Watch the 0–2, 2–7, and 7–12 minute windows
0–2 minutes: Confirm that the action succeeded
Check whether the sender shows a success message, verify the email address, then return to the temporary email inbox and refresh it manually once. Most automated verification emails arrive quickly, but not seeing one immediately isn’t enough to conclude that it was lost.
2–7 minutes: Keep the address unchanged and refresh sparingly
Refreshing once every minute or two is enough. Don’t resend every ten seconds: the sender may throttle requests for the same account, queue the new request behind the first, or invalidate a code that arrives later. You can also check the sender’s status page for authentication-email delays.
7–12 minutes: Resend once, deliberately
After confirming the address is correct and the page allows it, resend once and note the new time. If the first and second emails arrive together, use the newest one and check the stated expiration to determine whether the older code is invalid.
| What you see | Most likely location | Next step |
|---|---|---|
| Domain rejected immediately on the sending page | Sender policy | Use a long-term email address or forwarding alias |
| Page succeeded, but no email after 12 minutes | Sending queue or delivery chain | Resend once and check the status page |
| Two emails arrive together | Sender delay or throttling | Use only the latest verification code |
| Other emails arrive, but messages from one site never do | Rules specific to that sender | Stop switching temporary addresses |
Narrow the problem with comparison signals
If the same recipient address receives emails from other sources, the inbox itself is at least working. If one particular site never delivers, its sending rules or queue are the more likely cause. If nothing arrives from any source, check whether the address has expired or whether the sender’s form still contains the old address after you switched.
“It still hasn’t arrived after switching addresses” isn’t conclusive evidence either. Many sites evaluate the domain rather than the full address, so changing prefixes under the same domain won’t bypass their policy. Instead, it makes you lose the observation window for the original address.
When to resend—and when to stop
If the sender shows a clear cooldown timer, wait for it to finish. Without a timer, it’s still best to allow a few minutes. Don’t click a third resend; multiple active codes increase the chance of receiving one that is immediately reported as invalid. When the email arrives, check the time, recipient address, and expiration before copying the code.
- Use only the newest verification email as the basis for your action.
- If entering the code fails, first check whether you used an older email instead of immediately switching addresses.
- For login-link emails, open only the newest link so you don’t use a revoked token.
- For important accounts, don’t tie the recovery link to an address that expires within 24 hours.
Still not delivered after 12 minutes
If the sender’s public status page reports an outage, keep the current address and continue waiting. If the page explicitly rejects temporary domains, stop retrying. For accounts that may later need invoices, alerts, or recovery links, switch to a pausable forwarding alias instead. An alias hides your primary email while preserving long-term receiving capability.
When contacting site support, provide the submission time, the recipient domain, the page’s success or error message, and whether you tried one resend. Don’t share the verification code. This is enough for them to search their sending logs and is more useful than saying only that the email never arrived.
A clear time window prevents troubleshooting steps from interfering with one another: verify first, wait, resend once, then choose an alternative identity based on the sender’s policy. Even if the email never arrives, you’ll know whether to address the sender, the address choice, or the account recovery path.
Keep one address and start a clean observation
Use the temporary inbox for short-term verification. If the sender rejects temporary domains or the account needs long-term recovery, switch to a forwarding alias.