Verification email not arriving? How to find out why

Start with the sixty-second check

Do these four before anything else. Between them they account for most missing verification mail, and none of them takes longer than reading this sentence.

1. Read the address back, character by character. Not the one in your head — the one actually open in front of you, against the one actually in the form. rn and m, l and 1, a dot you added, a dot you dropped: an address that is one character out is a different mailbox that works perfectly and is not yours.
2. Check which domain you used. Three public domains are offered, and the same name in front of each is three separate mailboxes. k7fq2m@grabmail.io and k7fq2m@mixozia.com have nothing to do with one another.
3. Make sure you are not watching the alias. The alias is the address you hand out; the mailbox opens under the address you keep. Reading an alias back gives you an empty mailbox every time — not because the mail is late, but because nothing is ever stored under it.
4. Ask the site to send it again. Most sign-up forms have a resend link and it costs nothing. If the second one lands instantly, the first was lost at the sender's end and there is nothing here to investigate.

How long a verification email should take

A verification mail normally appears two or three seconds after you press the button. What a longer wait means:

One delay is ours, and it is worth knowing about. If our storage layer is unavailable the mail servers accept and hold what arrives rather than rejecting it, and deliver once the layer is back — for up to 5 days. A sending server is never given a permanent rejection for a problem at our end, because senders do not retry those. So a message that is genuinely late is still coming.

You are watching the wrong mailbox

This is the most common cause and the hardest to see: an address that is one character wrong is a perfectly good mailbox that simply nobody sent anything to. There is no error to notice, because nothing here is created in advance. Six ways it happens:

A typo, on either side

Typed one way into the form and another way into the inbox. Copy and paste in both directions rather than reading it off a screen.

name+tag@ is not name@

Plus-addressing opens a separate mailbox here rather than tagging an existing one. That is deliberate — tags are how people keep sign-ups apart — but it means shop+aug@grabmail.io never shows up in shop@grabmail.io. Open it exactly as you typed it, tag and all.

A different public domain

The same name on grabmail.io, mixozia.com and linqmail.com is three unrelated mailboxes. Nothing is shared between them.

The alias, not the address

The alias delivers into the mailbox and can never read it back. Paste an alias into the inbox and it will stay empty forever, however much mail arrives.

A phone that helped

Autocorrect and autocapitalise rewrite an address while you type it. Capitals are harmless — everything is lower-cased here — but an autocorrected word is a different address.

Somebody else's mailbox, briefly

Short, obvious names on a public domain are shared by everyone who thinks of them. If you used test@ or hello@, another person may have opened your message, or deleted it, before you looked.

The site never sent it

Worth ruling out early, because nothing you do on this side will fix it. Sign-up forms fail quietly far more often than they admit:

• The account already exists. Many sites answer “we have sent you a link” whether or not the address is new, and send nothing at all when it is not. It is a deliberate measure against address harvesting, and it is good practice — it is also indistinguishable from a lost message.
• The address was refused after the form said thank you. Some blocklists run when the message is sent, not when the field is filled in.
• The send is on a schedule. A batch that runs every five or ten minutes is common on smaller sites, and nothing on the page says so.
• Their provider bounced it. The bounce goes back to them, not to you, and it does not always reach a human.
• You are past a resend limit. Three requests in a minute, and the fourth is dropped without a word.

One test separates all of this from a delivery problem, and it takes a minute: get something else sent to the same address. Any other site's “forgot password” form will do. If that arrives and the verification does not, the fault is at the sender and no amount of waiting will change it.

The site refuses disposable addresses

Plenty of services keep lists of disposable-mail domains, and the public domains here are on them. This is the one cause that does not go away by itself, so it is worth recognising quickly. It shows up in two shapes, and only one of them is honest about what it is doing.

There is no trick that makes a blocked domain unblocked, and any service advertising “temp mail that works everywhere” is a list that has not been updated yet. What does work is an address nobody has listed — which is the next section.

There is a fuller version of this, including what those lists actually check, in the guide on signing up without giving your real address.

The fix that removes the whole class of problem

One MX record on a domain you already own turns every address on it into a mailbox here. It is free, it takes a few minutes, and it settles three of the causes above at once:

• No blocklist has heard of it. Your domain is never printed anywhere on this site, so there is nothing for a filter to match against.
• Nobody else is guessing at it. The public domains are on every page here; yours is not, so even a short address on it is not shared with strangers.
• One address per service, with no collisions. forum@ today and shop@ tomorrow, both on a domain only you use — and when one of them starts getting spam you know exactly who sold it.

The record itself is one line, and publishing it is the whole of the proof of ownership — there is no account to create and nothing to verify:

MX record for your domain10 smtp.grabmail.ioCopy

The full walk-through is here: the record, what publishing it proves, and the honest limits of a mailbox with no password on it.

When it is a test suite waiting, not a person

Everything above still applies, plus three failures that only bite scripts:

An empty mailbox is not an error

Nothing is created here, so an address that has never received anything answers 200 with count: 0 and an empty list. Only a domain we do not host answers 404. Code that treats “empty” as a failure gives up a second before the mail lands.

You are sleeping instead of polling

A fixed sleep(5) is too long on a good day and too short on a bad one. Poll once a second against a wall-clock deadline, and fail the test when the deadline passes rather than after a fixed number of tries.

You are over the rate limit

One request per second, per address. Over it you get 429 with a Retry-After header in whole seconds. A client that ignores the header and hammers is a client that waits longer.

deadline=$(( $(date +%s) + 60 ))
while [ "$(date +%s)" -lt "$deadline" ]; do
  n=$(curl -sG https://grabmail.io/api/v1/mailbox \
        --data-urlencode "address=$ADDR" | jq '.count')
  [ "$n" -gt 0 ] && break
  sleep 1
done

There is a whole guide to doing this properly — testing an email verification flow end to end — with Playwright and pytest helpers that do not flake, and the failure modes that make this awkward in CI.

It arrived, and it is not there any more

Three ways a message that really did arrive is not in front of you now:

It expired

Everything is deleted 5 days after it arrives, read or not. The clock starts at delivery, and every message carries expires_at so a client never has to work that date out for itself.

Somebody deleted it

On a public domain, anyone who knows the address can open the mailbox and delete from it. If you used a short, guessable name, that somebody was not necessarily you.

You deleted it

The inbox has a delete button and the API has a DELETE call. Both take effect immediately, and neither has an undo.

If it is still not there

There is no support mailbox to write to, and that is deliberate rather than rude: a service built on unauthenticated, disposable mail is not a place to send something that needs to be read. So every remaining step is one you can take yourself.

1. Check the service is up. The status page reports the mail servers, the API and the website separately, so “nothing arrives” and “the site is slow” are never confused.
2. Try another public domain. If one is on the sender's blocklist, the other two may not be.
3. Try an address on a domain of your own. It rules out every blocklist in a single move, and it is the only test that does.
4. Take a different route in. Sign in with an account you already have, or a phone number, if the site offers one at all.
5. Accept that it is the sender. If mail from anywhere else lands in the same mailbox seconds later, the mailbox is working and the message was never handed over.

And if that verification mail was the only thing standing between you and an account you genuinely care about, take the hint and use a real mailbox for it. A disposable address is the right tool for the sign-ups that stop mattering an hour later — which is most of them, but not that one.

Questions