Email provider lookup

How a hostname names a company

Mail providers do not run their customers’ mail on their customers’ hostnames. They hand out a name under a domain they control, because the certificate, the routing and the abuse handling all have to belong to them — so aspmx.l.google.com, mx.zoho.com and mail.protection.outlook.com each identify their owner with no ambiguity at all.

That is the whole mechanism. We match the end of each MX hostname against a list of suffixes those companies use, on whole labels — a name that merely containsa known suffix, which is the shape a lookalike domain takes, matches nothing. It is a lookup table, not an inference, and it is deliberately narrow: guessing a provider from a hostname that resembles one would be presenting our guess as the domain’s configuration.

A gateway in front of a mailbox hides the mailbox

Some organisations point their MX at a filtering service instead of at the mailbox provider. Mail arrives at the gateway, is scanned there, and is then relayed onward to wherever the mailboxes actually are — over a path that is arranged privately between the two, and that DNS says nothing about.

When that is the shape of the answer, the honest reading is this domain files its mail through this gatewayand nothing more. The mailbox provider behind it could be any of them, and no public record will tell you which. A tool that reported the gateway as “the provider” would be stating something it cannot know, so this one names the role and stops.

The same limit applies in the other direction. A domain can accept mail at one service and send through a completely different one; the MX record covers only what arrives.

Why a provider is a clue to the rest of the records

Knowing who runs a domain’s mail tells you what its other records ought to contain. Each provider publishes the SPF include: it expects to find, and each signs with DKIM selectors it names itself — so a domain whose mail is on one service and whose SPF authorises another has usually finished a migration in one place and not the other.

That mismatch is one of the most common reasons legitimate mail lands in spam, and it is invisible from the inside: the mail sends fine, it simply fails authentication at the far end. Reading the provider first gives you the list of things the other records are supposed to say.

Nothing published is a different answer from nothing at all

A domain with no MX record has no mail provider, and senders fall back to its A or AAAA record — the address its website is on — and try to deliver there. A domain with a null MX (0 .) also has no provider, but it has said so on purpose: RFC 7505 makes a sender reject the message outright rather than fall back and retry for days.

Both are answers. So is a set of hostnames we do not recognise, which is the ordinary case rather than the odd one — a great deal of the world’s mail runs on servers belonging to no named service at all, and a domain that hosts its own is not doing anything unusual.

What this cannot tell you

It cannot tell you where mail lands when a gateway answers, whether a mailbox at the domain exists, or whether a message would survive the filtering on the other side. It cannot see a provider used only for sending, because sending leaves no MX record. And it cannot recognise a service that is not on the list, which is why an unrecognised hostname is reported as exactly that.

Answers are cached for a few minutes so that a popular link does not turn into a flood of identical DNS queries. If a domain changed provider very recently, the result will say it came from the cache.

Changing provider is a public event

This is the part worth sitting with. The MX record is not merely readable — it is the only way delivery can work, so it is readable by everyone, forever, and it updates the moment a domain moves. Anyone watching a company’s DNS learns that it switched mail providers the same day its own staff do, without asking anyone.

None of that is avoidable, and the same public record is what makes this tool possible at all. What it does mean is that the infrastructure layer of email leaks organisational facts by design, which is worth knowing before assuming the rest of it is private.

Maski appears in these results too, as a forwarder — when someone points a domain at us, their MX says so. That is the honest cost of the arrangement: a domain’s provider is public, and what stays private is the address behind each alias and the inbox it reaches.