How to test whether an email address can receive mail

"The email arrived" and "email delivery works" are not the same claim. A message can be accepted by a mail server and never appear in an inbox. It can appear in an inbox and still prove nothing about whether the domain is configured correctly. Most inbox testing goes wrong because the test answers a narrower question than the person asking it believes.

This guide covers what an inbox test can and cannot establish, how to construct one that produces usable evidence, and how to read the result.

What actually happens when mail is delivered

Before testing anything, it helps to know the sequence being tested.

The sending server looks up the recipient domain's MX records in DNS to find which server handles its mail.
It opens an SMTP connection to that server.
It states the sender address (MAIL FROM) and the recipient address (RCPT TO).
The receiving server responds — accepting the recipient, rejecting it, or deferring.
If accepted, the message body is transferred and the server returns a success code.
Afterwards, and separately, the receiving system decides where to file the message: inbox, spam, quarantine, a rule-driven folder, or nowhere.

Steps 1–5 are delivery. Step 6 is placement. They fail for entirely different reasons, and a test that only observes step 6 gives you very little when the answer is "nothing showed up."

Four ways to test, and what each one proves

Send from another account you control

The obvious approach, and the most commonly misleading one. If both accounts are on the same provider — two Gmail addresses, or two mailboxes on the same Microsoft 365 tenant — the message may never traverse the public internet. It gets delivered internally, bypassing the MX lookup and external filtering entirely.

This test can pass while external mail fails completely. If you use it, send from a genuinely different provider.

Ask the original sender to try again

The only way to reproduce a sender-specific problem. If one particular sender's mail vanishes while everything else arrives, the cause usually sits on their side — authentication failures, a poor sending reputation, or a blocklist entry — and no test from a third party will reproduce it.

Ask them to forward you any bounce message they received. That text is often the single most useful piece of evidence available.

Use an independent test service

A third-party service sends a real message from outside your infrastructure and reports what the receiving server said at the SMTP level. The advantage over self-testing is that acceptance and placement are reported separately: you learn whether the server accepted the message and whether it reached the inbox, rather than conflating the two.

SendTestMail.com works this way — the delivery status page shows the SMTP-level outcome, which is the part you cannot observe from inside your own mailbox.

Read the server logs

If you administer the mail system, this is the strongest evidence available and it should usually come first.

Microsoft 365: message trace in the Exchange admin centre
Google Workspace: Email Log Search in the Admin console
cPanel: the Track Delivery tool
Self-hosted: the mail transfer agent's log, typically under /var/log/

Logs tell you whether the message reached your server at all, which no external test can determine on its own.

Constructing a test that produces usable evidence

Send from outside your own domain and provider. Otherwise you are testing internal routing.
Test the exact address, character by character. A single transposed letter in a domain produces a bounce that looks identical to a configuration failure.
Send more than one message, from more than one source. A single result cannot distinguish a systematic fault from a one-off.
Note the time. Log searches and message traces need a time window.
Search the entire mailbox, not just the inbox — Spam, Junk, Promotions, Archive, All Mail, Trash, and any organisational quarantine.
Record the SMTP-level result, not just whether the message appeared. "It didn't show up" describes three completely different faults.

Reading the result

Accepted, and the message is visible

Delivery and placement both work for that address, from that sender, at that moment. That is a narrower statement than "my email works," but it is a solid data point.

Accepted, but nothing visible

The receiving server took the message and something downstream filed it elsewhere. Check Spam and quarantine first, then inbox rules, then forwarding — a "delete after forwarding" setting removes the local copy. Plus-addressed mail is also frequently auto-filed into a folder the recipient forgot they created.

Rejected permanently — a 5xx code

The server refused the message and will not retry.

550, user unknown / no such recipient: the address does not exist on that server, or the domain is not fully configured there
550, relay access denied: the server does not consider itself responsible for the domain, which usually means an MX problem
552 or 452, storage: the mailbox or domain is over quota
554 with a blocklist reference: the sending IP or domain is listed somewhere the recipient's server consults

Deferred — a 4xx code

Temporary. The sending server will retry, typically over a period of a day or more.

Greylisting is the most common cause: many servers reject an unfamiliar sender once on purpose, expecting a legitimate sender to retry. Rate limits and brief outages produce the same class of response. Wait and re-check before concluding anything.

No response at all

Nothing answered on the SMTP port. The MX record may not resolve, may point to a host that no longer exists, or the port may be firewalled.

Four conclusions people reach that don't follow

"I sent it from my other Gmail and it worked." Possibly internal delivery. It says nothing about external mail.
"The tool says delivered, so my email is fine." Delivered means the receiving server accepted it. Placement is a separate decision made afterwards.
"It bounced, so the address is invalid." A permanent bounce can also mean a full mailbox, a suspended account, or a blocklisted sender.
"I tested my main address and it works, so my catch-all works." Testing an address that already exists proves the mailbox receives mail. A catch-all can only be tested with an address that has never existed.

When testing is worth doing

Run a check after any change to the mail path: a new domain or mailbox, a provider migration, an MX or DNS edit, a new alias or forwarding rule, or a change to a security gateway. Also test before anything starts depending on inbound mail — a signup form, a password reset flow, a support address.

A mailbox that worked last year is not evidence that it works today. DNS records expire, providers change defaults, and forwarding destinations disappear.

Frequently asked questions

What is the difference between "sent" and "delivered"?

Sent means the sending service attempted the message. Delivered means the receiving server accepted it at SMTP. Neither means it reached the inbox.

Why did the test arrive in Spam?

Placement is decided by the receiving provider after acceptance, based on sender reputation, authentication, and content. Mail from an unfamiliar sender with no prior history is filtered more aggressively. Marking it "not spam" teaches the filter for future messages.

How long should I wait before assuming a message is lost?

For a deferred message, allow at least an hour before drawing conclusions and up to a day before treating it as failed. Permanent rejections are immediate and need no waiting.

Can I test an address I don't own?

You can send a message to it, but you cannot check where it landed. Without access to the destination mailbox you can only observe whether the receiving server accepted it — which still distinguishes a routing failure from a filtering one.

Does a successful test mean my domain is configured correctly?

It means inbound mail reached that address. Sending configuration — SPF, DKIM, DMARC — is separate and is not exercised by an inbound test.

To check an address now, send a test message and read the delivery status alongside the mailbox itself.