What One Domain Reveals
What can MX records tell you about a company?
MX records name the servers that accept a domain's email, which exposes the email provider (Google Workspace, Microsoft 365, Proton), any security gateway sitting in front (Mimecast, Proofpoint, Barracuda), and whether the domain is set up to receive mail at all. Read alongside SPF and DMARC, they place a company's whole email stack. Bassethound resolves MX in the fast, keyless tier and correlates it with the rest of the five-layer dossier.
Best move: resolve the domain’s MX records first, then map each hostname to a known provider or gateway.
Why it works: MX records are public DNS that name the servers accepting a domain’s mail, and the major providers and security gateways use recognizable hostnames.
Key takeaways
- MX records list the mail servers that accept a domain’s email, ranked by priority (lower number wins).
- The MX hostname maps to the email provider. Google Workspace, Microsoft 365, Proton, Zoho, and Fastmail each use distinct patterns.
- A security gateway (Mimecast, Proofpoint, Barracuda) shows up as the MX and hides the mailbox provider behind it.
- A null MX (RFC 7505) declares a domain accepts no mail. A missing MX flags a parked or send-only setup.
- Read with SPF, DKIM, and DMARC, MX records place a company’s full email stack and its security posture.
What email provider does an MX record reveal?
The MX hostname is a fingerprint. You map it to a known provider.
Google Workspace resolves to smtp.google.com, or the older set aspmx.l.google.com with alt1 through alt4. Microsoft 365 uses one record shaped like yourdomain-com.mail.protection.outlook.com. Proton Mail uses mail.protonmail.ch and mailsec.protonmail.ch. Zoho uses mx.zoho.com, mx2, and mx3. Fastmail uses in1-smtp.messagingengine.com and in2. Amazon WorkMail uses inbound-smtp.
The provider tells you more than where mail lands. Microsoft 365 correlates with a Windows, Azure, and Teams shop, larger and procurement-heavy. Google Workspace correlates with a startup-leaning, Google-tooled org. Proton signals a privacy-first team. None of these is a rule, but the correlation helps when you size an account or guess the rest of the stack before firmographics come back.
Priority matters too. MX records carry a preference number, and lower wins. A domain with one low-priority provider record and a set of higher-numbered backups shows you the primary and the failover. Bassethound returns every MX with its priority and the resolved provider label in the infrastructure layer.
Can MX records expose an email security gateway?
Often, yes. Many companies route inbound mail through a filtering gateway before it reaches the mailbox, and the gateway owns the MX record.
Mimecast shows as a hostname like us-smtp-inbound-1.mimecast.com. Proofpoint shows as mxa-*.pphosted.com or a *.ppe-hosted.com pattern. Barracuda shows as a *.barracudanetworks.com host. Cisco Secure Email, Fortinet, and Sophos each carry their own names. When one of these fronts the MX, the domain filters inbound mail through a paid gateway.
That is a strong qualification signal. A gateway means the company spends on email security, which tracks with headcount, compliance obligations (SOC 2, HIPAA, finance), and a security-conscious team. If you sell security, deliverability, or anything to a security buyer, the gateway is a lead on its own.
The gateway also hides the backend. The MX names the filter, not the mailbox provider behind it, so you cannot read Microsoft 365 or Google off the record. You infer the backend from SPF, from the gateway vendor’s typical customer base, or from a follow-on lookup. Bassethound labels the gateway in the infrastructure layer and notes when the backend provider is obscured rather than guessing at it.
What does a missing or null MX record mean?
Absence carries information. A domain with no MX record and no null MX has no declared inbound path, which usually means a parked domain, a marketing-only or redirect domain, or a domain used for sending but not receiving.
A null MX is explicit. RFC 7505 defines a single record with priority 0 and a target of ”.” that declares a domain accepts no mail. Seeing it tells you the owner set this on purpose, common on domains that only send transactional mail or that back a service rather than a mailbox.
There is also the fallback rule. RFC 5321 says a sender may deliver to the domain’s A or AAAA record when no MX exists (the implicit MX). So a domain without MX is not always unreachable, but it points to an unmanaged or self-hosted setup rather than a cloud provider.
For qualification, no MX on the apex plus a live website often means the real mail lives on a subdomain or a sister domain. Bassethound reports the null-MX or missing-MX state rather than leaving the field blank, so you read the absence as a signal instead of a gap.
How do MX records combine with SPF, DKIM, and DMARC?
MX is one half of the email picture. It handles inbound, the servers that accept mail. SPF, DKIM, and DMARC live in TXT records and cover outbound: who is authorized to send as the domain, and what a receiver should do with a forgery.
Read together, they place the full stack. SPF often lists senders the MX never shows: SendGrid, Mailgun, Amazon SES, Postmark, Customer.io, Marketo, Salesforce, HubSpot. A domain on Microsoft 365 for inbound with SendGrid and Marketo in SPF runs marketing and product email through dedicated platforms, which tells you about go-to-market spend, not just the mailbox.
DMARC adds posture. A published policy of p=reject or p=quarantine signals a mature team that finished the hard part of email authentication. A policy of p=none, or no DMARC at all, points to earlier maturity or a gap.
This is the fusion angle. MX alone is a lead. MX plus the TXT vendor list plus the DMARC policy is a profile of how a company runs and secures its email. Bassethound resolves MX and TXT in the same infrastructure layer and reports the email-auth booleans (SPF, DKIM, DMARC present) next to the vendors it found.
What can MX records not tell you?
Be honest about the limits. MX records describe routing, not usage.
They tell you which server accepts mail. They do not tell you the volume, whether anyone reads the inbox, or how many mailboxes sit behind the provider. A domain can point at Google Workspace and host one forwarding alias or ten thousand seats. The record looks the same either way.
A gateway hides the backend, so an MX naming Mimecast or Proofpoint won’t reveal whether Microsoft 365 or Google sits behind it. Catch-all forwarding and split-domain routing can send mail somewhere the apex MX never mentions. Subdomains can carry their own MX that differs from the root.
And the record says nothing about internal mail flow, distribution lists, or shared mailboxes, where a lot of a company’s real email lives.
None of this makes MX weak. It makes MX a strong first read that needs corroboration. Bassethound treats it that way: it resolves MX in the fast, deterministic tier, correlates it with SPF, DMARC, the tech stack, and firmographics, and reports which fields it could not resolve instead of implying certainty it does not have.
Bassethound perspective
WhoisXML and DomainTools will sell you MX records. So will a free dig. The record is commoditized, and reading it as a standalone fact is the shallow end. One MX hostname is a lead, not a picture.
The value is correlation. An MX pointing at Mimecast, an SPF listing SendGrid and Marketo, a Microsoft 365 backend, and a homepage running Salesforce forms are four facts that mean little apart and a sales-ready profile together: an enterprise-shaped, security-conscious, Microsoft-aligned buyer already spending on outbound tooling. No single-layer lookup fuses that. Five separate MCPs make an agent pay for five round trips and then do the join itself.
Bassethound resolves MX in the fast, keyless tier, on the same call that returns the tech stack, the AI backend, and the firmographics. One request, five correlated layers. We stay honest about the limit. MX describes routing, not who reads the mail, and a gateway hides the backend provider. The dossier says so instead of guessing.
Sources
- IETF RFC 5321, Simple Mail Transfer Protocol (MX resolution and implicit MX): https://datatracker.ietf.org/doc/html/rfc5321
- IETF RFC 7505, A Null MX No Service Resource Record: https://datatracker.ietf.org/doc/html/rfc7505
- Google Workspace, set up MX records for Gmail: https://support.google.com/a/answer/140034
- Microsoft 365, create DNS records at any DNS hosting provider: https://learn.microsoft.com/en-us/microsoft-365/admin/get-help-with-domains/create-dns-records-at-any-dns-hosting-provider
Frequently asked questions
Do MX records tell you who reads a company's email?
No, not directly. MX records tell you which server accepts inbound mail. If a gateway like Mimecast fronts the domain, the MX names the gateway, not the mailbox provider behind it. You infer the backend from SPF and other signals.
Does no MX record mean a company has no email?
Not always. A null MX (RFC 7505) declares the domain accepts no mail on purpose. A missing MX can mean a parked domain, a send-only domain, or mail that falls back to the A record.
Can MX records be faked?
Not in a way that misleads. They are public DNS the domain owner controls, so they are accurate about routing but say nothing about volume or real use. They describe intent, not traffic.
Are MX records enough to identify the email security vendor?
Often yes for the inbound gateway. Proofpoint, Mimecast, and Barracuda each carry distinct hostnames. The full email picture needs the TXT records too.
How fast is an MX lookup?
About 1 to 3 seconds. It is a single DNS query, deterministic and keyless. Bassethound returns it in the fast profile, alongside the rest of the infrastructure layer.