What email testing tools can see — and how to vet one

To test whether an inbox receives mail, a tool has to be given an email address and then send something to it. That is an unavoidable amount of trust to hand over, and the addresses involved are often ones you would rather not publish — a personal account, a client's mailbox, a new domain nobody has mailed yet.

Most people never look at what happens to that address afterwards. It is worth knowing what these tools necessarily handle, what they optionally retain, and how to tell the difference before typing anything in.

What any test tool must handle

Some data handling is inherent to the function. A tool that sends mail to an address has to process:

None of that is avoidable. The meaningful question is what happens next.

What is optional, and therefore a choice

Everything past the send is a decision the operator made:

A tool retaining readable addresses is, functionally, accumulating a list of email addresses that are confirmed to work. That is a valuable asset and a serious liability at the same time, because it is exactly what a breach exposes.

The harvesting problem

This is the specific risk worth understanding, because the incentives point the wrong way.

A verified-deliverable address is worth considerably more to a spammer than an unverified one. An inbox-testing tool receives a continuous stream of addresses that users have personally confirmed they want mail at. If the operator retains them, they have built a high-quality mailing list at no cost, contributed voluntarily by the users.

Nothing about the interface tells you which kind of tool you are using. Both behave identically from the outside.

The related risk: being on the receiving end

There is a second problem these tools create, independent of data retention. Anyone can enter someone else's address. Test-sending services are periodically misused to send unwanted mail to people who never asked for it, at scale.

Responsible handling of this involves rate limiting, CAPTCHA, identifying the service clearly in the message so recipients know what happened, disclosing the requester's IP in the message body, and providing a way to block an address from receiving further tests.

If you receive an unexpected test message, it usually means someone mistyped their own address — but the presence of a block mechanism and a visible sender IP is what lets you do something about it if not.

Checking a tool before you use it

Reasonable questions, in rough order of usefulness:

Does it require an account? A tool that works without registration cannot link tests to an identity. One that requires signup has, by design, connected everything you do to a profile.

What does the privacy policy say about retention specifically? Look for a stated retention period and a stated deletion behaviour. "We take your privacy seriously" is not a retention policy. Vagueness on this point is the most reliable warning sign available.

Are addresses stored in readable form? Hashing addresses before storage means the operator can match a status lookup to a test without holding the address itself. It is a meaningful structural difference, not a presentational one.

Does the message identify itself? A test message should say what it is, which service sent it, and at whose request — so an unintended recipient is not left guessing.

Is there a way to opt out of receiving tests? Its absence suggests the abuse question was not considered.

Does the site set tracking cookies? Easy to check in your browser, and it tells you whether the operator's interests extend beyond the stated function.

Can you avoid the question entirely? For a genuinely sensitive address, sending from a mail account you already control involves no third party at all. It is a weaker test — it does not report the SMTP-level result — but it introduces no one new. Use a third-party tool when you need the independent view, not by default.

How SendTestMail.com handles it

For transparency about this site's own answers to the questions above:

Addresses and IP addresses are hashed before storage, so they are not held in readable form. Inbox content is never accessed or retained — the system observes only whether the receiving server accepted the message. Tests are not linked into a history, no account is required, and no behavioural tracking is applied.

On the abuse side: each test message states that it came from SendTestMail.com, includes the requesting IP address in the body so an unintended recipient can see where it originated, and addresses can be blocked from receiving further tests. The full detail is in the privacy policy.

These claims are worth applying the same scrutiny to as anyone else's. The questions above are the ones to ask.

Frequently asked questions

Can an email testing tool read my inbox?

Not by sending a message. Reading a mailbox requires credentials or an OAuth grant. If a tool asks to connect to your mailbox, that is a fundamentally different level of access than sending a test message, and it warrants a fundamentally different level of scrutiny.

Does hashing actually protect an address?

It prevents readable storage and makes bulk extraction from a database impractical. It is not absolute — a short, known set of candidate addresses can be checked against a hash. It is a genuine structural improvement, not a guarantee.

Is it safe to test a client's or colleague's address?

Consider whether they would expect it. The test message arrives in their inbox and, on a well-designed service, identifies where it came from and who requested it. Testing your own address on the same domain usually establishes the same thing without involving them.

I received a test email I didn't request. What happened?

Most commonly, someone mistyped their own address as yours. Check the message for the requester's IP and a block option. It is not typically an attack, but you should be able to stop it recurring.

Why do these tools use CAPTCHA?

To limit automated abuse. Without it, a send-to-any-address service is trivially turned into a mailing tool.

---

To run a check, send a test message and follow the delivery status.