An email arrives and something about it sits wrong. The domain is almost right but not quite. The name in the signature doesn’t match the address it came from. The message concerns an invoice, a payment detail, or an account that needs attention today rather than tomorrow.
The question people ask themselves at that moment is “is this a real email?” It sounds like one question. It is almost always two, and they have very different answers.
The first is whether the address exists at all: is there a mailbox behind it, or was it invented? The second is whether the person using it is who they claim to be and intends what they say.
The first question is the easy one. An email verifier settles it in a few seconds without sending anything to the address. The second question is where this gets complicated, and it is the one most people are actually asking.
The two questions, and why the distinction matters
Keeping them separate is worth the effort, because conflating them produces exactly the wrong kind of confidence.
An existence check is a technical question with a technical answer. The address either resolves to a real, reachable mailbox or it does not. That answer is reliable, fast, and narrow.
Intent is a judgment question, and no technical check answers it. Here is the part that most advice on this topic skips over: the overwhelming majority of fraudulent email comes from addresses that are entirely real. Someone registers a domain, creates a mailbox, and sends from it. That address will pass every existence check available to you, because it exists. It was created specifically so that it would.
This is why a clean result should not be read as reassurance. It answers a question you were partly asking, using a method that has no visibility into the question you were mostly asking. People get caught in the gap between those two things.
The distinction is still worth drawing rather than abandoning, because existence checks do catch a real and common category of problem. Just not the one most people assume.
What an automated check actually establishes
The mechanics are simple enough to describe in a sentence. The check confirms the address is correctly formed, that the domain exists and has working mail records configured, and that the receiving server responds when asked whether it accepts mail for that specific mailbox. None of that requires sending a message.
What that result usefully catches falls into three categories.
- Addresses that were never real. Contact details invented to look plausible. A made-up mailbox on a genuine company domain. Details typed into a form by someone who needed the field filled rather than the mail delivered. These fail immediately and unambiguously.
- Lookalike and typo-squatted domains. A domain registered one character away from a real company is the backbone of payment redirection fraud, and the eye is bad at catching it in a signature block. What a check often surfaces is that the lookalike domain has no functioning mail infrastructure behind it, or has one configured within the last few weeks, which is a discrepancy that reads clearly even when the domain string does not.
- Disposable and throwaway addresses. Worth its own section, below, because on inbound messages this one behaves differently from the others.
Each of these is a fact about the address. None of them is a fact about the person.
A disposable address on an inbound message is a signal in itself
Temporary and disposable mail services exist for good reasons. Keeping a personal address off a marketing list. Testing a signup flow. Handling a one-time transaction with a company you have no intention of hearing from again. Apple’s Hide My Email and similar masked-address features have made the practice thoroughly mainstream, and plenty of careful, privacy-minded people use them daily.
Notice, though, that almost every one of those reasons applies to someone receiving mail. They rarely apply to someone initiating a business conversation.
That asymmetry is what makes the signal useful. Somebody contacting you unprompted about an invoice, a payment, a partnership, or an account problem, from a mailbox designed to stop existing shortly after the exchange, has made a strange choice for a legitimate counterparty. Real counterparties need the thread to still be reachable next month. Disposability is a feature to the sender only when the sender does not plan to be found.
This is the one check in the whole category that carries an intent signal rather than just a factual one. An existence result that comes back clean tells you very little. A disposable result on unsolicited inbound tells you quite a lot. It does not prove anything, and there will be false alarms, but it inverts the default position from neutral to cautious, which is the right place to start.
Disposable-domain detection runs automatically as part of a standard check, which matters because the domain names themselves are endless and nobody recognises them by sight.
Where the check returns “can’t tell,” and why that isn’t a failure
One result confuses people, so it is worth explaining.
Many corporate domains are configured to accept mail addressed to anything at that domain, whether or not the specific mailbox exists. The server answers positively either way, which means the standard existence check cannot distinguish a real employee’s address from an invented one. You get an inconclusive result rather than a yes or a no.
This is common at larger organisations, often as a side effect of how inbound mail gets filtered rather than as a decision anyone made deliberately. The practical point for someone assessing a suspicious message: an inconclusive result on a large company’s domain is ordinary and is not itself a warning sign. The question went unanswered. That is different from the answer being bad. Verification services vary in how far they push on these domains, and some resolve considerably more of them than others.
The questions worth asking instead
Since the technical check covers less ground than people hope, the useful work is elsewhere.
- Does the domain predate the request? A domain registered three weeks ago, arriving alongside a change to payment instructions, is a far stronger signal than anything about the mailbox. Public registration records take a minute to look up.
- Does the request match the relationship? Payment detail changes, time pressure, and requests routed outside the normal channel are the actual pattern. They remain the pattern regardless of how legitimate the sending address turns out to be.
- Can you confirm through a channel the sender did not supply? The contact details inside a suspicious message are the least trustworthy thing in it. Use a number or address you already held, or one from the organisation’s own site.
- Does the address match how that organisation writes addresses? Most companies use a consistent house format. An address that breaks the pattern deserves a question even when it exists.
- What is the exposure if you are wrong? Scale the scrutiny to the stakes. A newsletter signup and a wire instruction do not warrant the same treatment.
Where this fits in a financial services context
Invoice and payment redirection fraud is worth singling out, because it works precisely by satisfying the check. A registered lookalike domain, a functioning mailbox, a plausible signature, a message written by someone who has read the real correspondence. The address is real. Everything about it passes.
So the honest value of address verification in this setting is narrower than it is often sold as, and it is worth being exact about what it is. It removes a category of obviously fabricated contact detail. It flags disposable addresses at the point they enter your systems, whether through a form or an inbound message. It catches the lookalike domain that was registered in a hurry and never properly configured. Those are real contributions and they are cheap to obtain.
What it is not is a control. It is one layer, sitting underneath the process controls that actually govern how payment details get changed and who is permitted to authorise it. Teams that treat verification as the control are the ones who end up surprised, because the fraud that gets through was never going to fail an existence check in the first place.
A final thought
“Is this a real email” is nearly always two questions wearing one coat. The technical half is answerable in seconds and the answer is dependable within its limits. The human half needs the same judgment it has always needed, and no amount of tooling has changed that.
Tools that answer a narrow question well are genuinely useful, right up until somebody mistakes them for answering a broader one.
