A Lookalike Domain Has MX Records. What Does That Mean?

What does it mean when a lookalike domain has MX records?

It means the name is mail-ready. Somebody opened a DNS console, or completed a verification step at a mail provider, and made the domain capable of receiving mail. If a sender policy is published alongside the MX records, somebody also decided which servers may send as that name. These are acts with a purpose behind them, even when the purpose is entirely ordinary.

That is the difference between what is automatic and what is deliberate. A registration happens in one transaction. Nameservers are usually assigned by the registrar, and an address record often appears by default, pointing at a parking page nobody chose. None of that required a decision. Mail records did.

So a mail-ready lookalike moves up the review queue, ahead of the parked and the dormant. A reply sent to it would reach somebody, and a message from it would pass authentication as itself. What the records do not say is who that somebody is, whether any mail has been sent, or what it would contain. They move a finding up the queue. They do not decide it.

Which records make up a mail configuration?

Five kinds of published record carry the mail story, and they can be read individually or together. Every one of them is an ordinary DNS lookup, answered by a resolver rather than by the domain's own servers.

Check it yourself

You do not need a tool to answer the question. One command on any laptop, or one URL in a browser, returns the MX records for a name. Both ask a public resolver what the domain publishes; neither contacts the domain or sends any message.

The answer shapes below are for a domain on Google Workspace, a domain on Microsoft 365, and a domain that has declared it accepts no mail at all. The RFC 7505 null MX is the last of these: a single record with preference 0 and a target of a lone dot. Google's current MX value is a single host, smtp.google.com at priority 1; accounts set up before 2023 may still use older hosts beginning aspmx. Microsoft 365 uses a token derived from the domain, followed by .mail.protection.outlook.com, at the highest priority available, typically 0.

dig MX example.com +short

Returns one line per record, preference first: 10 mail.example.com. An empty answer means no MX is published, and a lone 0 . means a null MX.

https://dns.google/resolve?name=example.com&type=MX

A DNS over HTTPS query in a browser. The Answer array holds one object per record with name, type, TTL and data fields; data carries the preference and host.

curl --header "accept: application/dns-json" "https://cloudflare-dns.com/dns-query?name=example.com&type=MX"

The same query against Cloudflare's resolver, in the same JSON shape.

Google Workspace answer

example.com. 3600 IN MX 1 smtp.google.com. Older setups: five hosts, aspmx.l.google.com and alt1 to alt4, at priorities 1, 5, 5, 10 and 10.

Microsoft 365 answer

example.com. 3600 IN MX 0 example-com.mail.protection.outlook.com. The label before .mail.protection.outlook.com is the token Microsoft assigns for the domain.

Null MX answer

example.com. 3600 IN MX 0 . A domain publishing this must publish no other MX record. It is an explicit statement that the name accepts no mail.

The sender side is a TXT lookup on the same name. A Google Workspace domain typically publishes v=spf1 include:_spf.google.com ~all and signs with a DKIM key at google._domainkey.example.com. A Microsoft 365 domain typically publishes v=spf1 include:spf.protection.outlook.com -all and holds DKIM CNAME records at selector1._domainkey and selector2._domainkey. Query the selector names directly: dig TXT google._domainkey.example.com or dig CNAME selector1._domainkey.example.com.

How do you read an MX answer?

An MX record pairs a preference number with a hostname. Lower numbers are tried first, and several records sharing a number share the load between them. A domain answering with two hosts at 10 and one at 20 has a primary pair and a fallback.

The hostnames are the informative part. Mail delivered to hosts under a commodity mail platform's own domain means the name has been connected to that platform, which normally requires a sign-up and proof of control by publishing a record. A hostname under the variation itself, resolving to an address such as 203.0.113.25, means somebody is running their own mail server, which is a different kind of effort.

Two conventions are worth recognising. A single MX record pointing at a hostname that does not resolve is a misconfiguration, common on names abandoned halfway. A single record whose target is a lone dot is the null MX, an explicit statement that the domain accepts no mail, and it is what a well-run parked or defensive registration frequently publishes.

Which combinations deserve attention first?

Before anything else, compare the suspect's MX hosts and nameservers with your own domain's. A variation whose mail is delivered to the same platform as yours, under the same nameservers, is almost always your own defensive portfolio, and confirming that settles the finding in a minute. After that, a pattern of records is stronger evidence than a single one, and age belongs in the same judgement, because a recent registration with a complete mail setup has no history to explain the configuration.

What does the configuration reveal across findings?

The most useful reading of mail records is not one domain at a time. Several variations delivering mail to the same platform, sharing a DKIM selector name, or sitting under the same nameservers are probably one operator, and that turns thirty separate review decisions into one decision about a group. It works in the reassuring direction too: a cluster pointing at your own platform is your portfolio, and confirming the group settles all of it at once.

Selector names are worth noting on their own. Sending platforms choose them, so a selector characteristic of a particular platform tells you how mail from the name would be sent before any has been seen. The same is true of a sender policy that includes a well-known platform: the configuration describes the plumbing, which is a narrower claim than describing the plan.

What ordinary reasons put mail records on a variation?

Before a finding is escalated it is worth ruling out the benign explanations in order, because most of them are cheap to check and one of them is usually true.

• You own it. Defensive registrations are routinely configured so that addresses at the variation forward to the real domain.
• A regional office, subsidiary or franchise operates the name with the organisation's knowledge, often under a different ending.
• An agency or supplier registered a campaign name on your behalf and configured mail so that replies reach somebody.
• An unrelated business holds a genuinely similar name. Short words and abbreviations collide constantly.
• The name was bought for resale, with a mailbox configured to receive offers.
• A registrar or parking service publishes default records that include mail routing the registrant never noticed.

What should you do with a mail-ready finding?

The order matters more than the effort. Most of the work is cheap, and the expensive step is the last one.

A checker helps with the repetition rather than the judgement. This one generates candidates from about twenty pattern families across about 180 endings, resolves every one over DNS, and shows the MX hosts and published policy on each finding as evidence rather than as a score; on the Pro plan findings are re-checked daily and certificate transparency logs are searched every 30 minutes. The suspect site is never opened and no mail is exchanged with the domain.

1. Confirm ownership first. Check the name against your own inventory and registrar account, which resolves a large share of findings in a minute.
2. Preserve the evidence with its date. DNS answers change without notice, so capture now what you may need later.
3. Ask whether anyone has received mail from the name. Your own gateway logs are the one source that can connect a registration to an actual message.
4. Warn the people who would be targeted. Finance and accounts payable benefit from knowing a name exists before a message from it arrives.
5. Decide the response on the merits. A registrar abuse report, a dispute, and no action at all are all defensible, and each needs different evidence.
6. Keep watching it. A variation that is quiet today may be configured next month, and a monitoring routine notices the week that happens.

What mail records cannot establish

An MX record says where mail for a name would be delivered. It does not say that any mail has been sent or received, or that anything improper is intended. A domain can publish mail records for entirely ordinary reasons. The records say nothing about content either: reading them is an enquiry to a resolver about what a name publishes, not contact with the mail server named in the answer.

A non-answer is not a negative. A timeout or a server failure is unknown rather than absent, and recording it as nothing found manufactures a fact. Equally, a name with no mail records today can have them tomorrow, so an absence is a snapshot rather than a clearance.

And the central caution stands. A complete mail configuration on a name that resembles yours is a reason to review it sooner than the rest of the queue. It is not proof of phishing, and treating it as proof is how a review process loses the confidence of the people who have to act on it.

Common questions

what does it mean if a typosquatted domain has MX records

It means the name is mail-ready: somebody configured it to receive mail, which takes a deliberate step at a DNS console or a mail provider. It raises the review priority of the finding. It does not show that any mail has been sent or what it would say.

how do I check whether a lookalike domain has MX records

Run dig MX with the domain name, or open a DNS over HTTPS URL such as the dns.google resolve endpoint with type set to MX. Both ask a public resolver what the name publishes; neither contacts the domain.

what is a null MX record

A single MX record with preference 0 and a target of a lone dot, defined in RFC 7505. It is an explicit statement that the domain accepts no mail, and a domain publishing it must publish no other MX record.

can a lookalike domain with MX records send email that passes SPF and DKIM

Yes. Whoever controls the domain can publish an SPF record and a DKIM key for it, and mail from it then passes as itself. MX records show it can receive; SPF and a DKIM selector show it is set up to send.

does a lookalike domain with MX records mean phishing

No. Defensive registrations, regional offices, agencies, unrelated businesses with similar names, resale holdings and registrar defaults all put mail records on names that resemble yours. The records are a reason to look sooner, never a finding.