How can I determine the ISP or mailbox provider of an email address?
Published 18 May 2025
Updated 19 Jun 2026
14 min read
Summarize with
Updated on 25 Jun 2026: We tightened this guide around MX-based provider detection, DNS edge cases, and warmup segmentation.
The direct way to determine the ISP or mailbox provider behind an email address is to look up the recipient domain's MX records, then classify the MX hostnames. For person@example.com, ignore the person part and query example.com. If the MX points at Google, Microsoft, Yahoo, Apple iCloud, or another recognizable mailbox network, that is the receiving platform to use for segmentation and warmup limits.
The caveat is important: MX lookup tells you where the domain routes inbound mail, not always the final mailbox a human reads. Custom domains can use Google Workspace, Microsoft 365, forwarding, or a gateway in front of the real mailbox. Do not confuse this with the DNS provider or registrar. Nameservers show who hosts DNS; MX records show where inbound mail is routed.
For obvious consumer domains, the address suffix is enough for a first pass: @gmail.com points to Google, @outlook.com and @hotmail.com point to Microsoft, @yahoo.com points to Yahoo, and @icloud.com points to Apple iCloud. For custom domains and migrated ISP domains, the MX record is still the better source of truth.
- Start with the domain: Strip the local part, lowercase the exact domain after @, and query MX records.
- Classify the MX: Group common host patterns such as Google, Microsoft, Yahoo, Apple iCloud, AOL, and legacy ISP mail.
- Read priority correctly: Lower MX preference numbers are tried first, while matching numbers act like the same priority pool.
- Add confidence levels: Treat direct mailbox MX matches as high confidence and gateway matches as partial confidence.
- Use it for warmup: Cap volume by receiving platform because Gmail and Outlook see traffic across hosted domains.
The direct answer
To identify the mailbox provider of an address, use the recipient domain's MX record. That record says which mail exchangers accept mail for the domain. If a custom domain has MX records under Google, it is using Google-hosted inbound mail even when the address is not @gmail.com. If it has MX records under Microsoft protection hosts, it is usually on Microsoft-hosted inbound mail.
When several MX records exist, the preference number matters. Mail senders try the lowest-numbered MX records first. If several records have the same preference, they belong to the same priority group, so classify the whole group before you assign a provider bucket.
Treat the result as a provider bucket, not as absolute proof of the user account type. A domain can route mail through a security gateway, a forwarding service, or a legacy host before delivery. A mailbox can also forward to a second mailbox after SMTP delivery. Public DNS will not expose that final handoff.
Flowchart showing domain extraction, MX lookup, IP resolution, PTR lookup, and provider assignment.
What the answer proves
DNS proves the receiving route for a domain. It does not prove the recipient's personal mailbox brand, subscription plan, inbox interface, or forwarding destination.
- High confidence: The MX hostname directly matches a known mailbox provider pattern.
- Medium confidence: The MX hostname belongs to a gateway that commonly fronts business mail.
- Low confidence: The MX is private, generic, parked, missing, or only traceable through PTR clues.
Run the lookup
For a small list, run DNS lookups manually and record the MX hostnames. For a larger list, batch domains, cache answers, and classify results with a rule table. The important part is to deduplicate domains first. A list of 200,000 addresses often has far fewer unique recipient domains.
Run the lookup against the exact domain after the @ sign. For you@example.com, query example.com, not www.example.com. For you@mail.example.com, query mail.example.com first because subdomains can have separate mail routing. If the domain returns no MX, retry before labeling it missing; a resolver timeout and an absent record are different outcomes.
Handle null MX explicitly. An MX answer of 0 . means the domain says it accepts no mail, so put it into a no-mail bucket instead of provider unknown. A domain with no MX can still trigger SMTP A or AAAA fallback, but that is a weak signal for provider classification and a poor basis for planned sending.
The lookup order is MX first, A or AAAA second, PTR third, and Whois or ASN data only when the volume is small or the host pattern is unclear. If the MX hostname is self-branded, resolve the host to an IP address before you classify the email hosting provider. PTR is useful because it can reveal the network naming convention behind an IP. A separate reverse DNS check helps when a mailbox host uses a generic name.
Basic lookup sequencebash
dig +short MX example.com nslookup -type=MX example.com dig +short A aspmx.l.google.com dig +short AAAA aspmx.l.google.com dig +short -x 142.250.0.27 whois 142.250.0.27
Do not classify broken MX answers
A provider label only works when the MX answer is reachable and expected. Put the domain into a review bucket when the MX target is malformed, lacks A or AAAA records, times out from multiple resolvers, uses a lookalike hostname, publishes null MX, or places an unknown host at the highest priority.
- Check target records: Resolve every MX hostname before assigning a provider.
- Check priority: An unfamiliar low-number MX target can receive mail before the expected provider.
- Check null MX: A single MX target of dot means the domain does not accept mail.
- Check ownership: Compare the hostname, PTR, Whois, and ASN with the expected provider.
- Check twice: Repeat timeouts through another resolver before treating records as absent.
If you are checking your own sending domain at the same time, use the domain health checker to validate the authentication side before ramping volume. Recipient provider grouping solves one part of warmup; your own DNS and authentication must also pass cleanly.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
At scale, keep recipient provider classification separate from sender authentication checks. One tells you where mail is going. The other tells you whether your own domain has the DNS foundation to earn delivery.
One-off checks
- Best fit: A single domain, a support ticket, or a quick sales ops check.
- Process: Query MX, inspect the hostname, then save the provider label.
- Risk: Manual labels drift when providers change routing patterns.
List-scale checks
- Best fit: Warmup planning, segmentation, routing analysis, and list hygiene.
- Process: Deduplicate domains, cache DNS answers, then classify with rules.
- Risk: Uncached lookups can overload resolvers and slow the job.
Classify common providers
After the lookup, the useful work is classification. Maintain a simple mapping of MX host patterns to provider buckets, then keep the raw DNS answer beside the label. That raw value matters when a rule needs review later.
For obvious consumer addresses, the domain suffix can be enough to choose a provider family: @gmail.com maps to Google, @icloud.com, @me.com, and @mac.com map to Apple iCloud, and @outlook.com, @hotmail.com, @live.com, and @msn.com map to Microsoft. For ISP-branded or migrated addresses, confirm with MX because the visible brand and mailbox operator can differ.
Add a few common setup-list clues to the rule table too. @aim.com and @aol.com belong in the AOL family, @verizon.net often routes through AOL-family infrastructure, @onmicrosoft.com is Microsoft, and many old ISP domains route through Yahoo-family hosts. Confirm these with MX before using them for warmup limits.
For Google, older hosted domains often show aspmx.l.google.com and related alt hosts, while some current hosted setups use smtp.google.com. Gmail consumer addresses use Google receiving hosts too, but keep Gmail consumer and Google-hosted custom domains as separate audience buckets when the MX pattern supports it.
|
|
|
|---|---|---|
 Google | Google MX hosts | Split Gmail and hosted domains when the pattern is specific. |
 Microsoft | Outlook protection hosts or onmicrosoft.com | Separate consumer Outlook clues from Microsoft 365 clues. |
 Yahoo | Yahoo DNS hostnames or migrated ISP hosts | Treat as Yahoo family unless custom routing says otherwise. |
 Apple iCloud | iCloud mail hosts | Usually clear for personal domains using iCloud mail. |
AOL or legacy ISP | AOL, AIM, Verizon, or migrated ISP routing | Classify by MX, not only by the address suffix. |
Gateway | Security MX host | Shows the front door, not the final inbox. |
Null MX | 0 . | Domain says it accepts no mail. |
No MX | Missing record | Review for SMTP A fallback, but do not rely on it for planned mail. |
Common MX clues and how to classify them.
Provider rule exampleyaml
google: match_mx: - smtp.google.com - aspmx.l.google.com - gmail-smtp-in.l.google.com classify_as: Google mailbox platform microsoft: match_mx: - mail.protection.outlook.com - olc.protection.outlook.com classify_as: Microsoft mailbox platform no_mail: match_mx: - "0 ." classify_as: Does not accept mail
Store confidence beside the label. A direct Google or Microsoft MX match gets high confidence. A generic gateway gets medium confidence because the provider behind it remains hidden. A PTR-only clue gets low confidence because IP naming can lag behind real routing changes.
Provider confidence bands
Use confidence to decide whether a provider label should drive warmup limits.
Direct MX match
90-100%
The MX hostname belongs to a known mailbox provider family.
Gateway match
70-89%
The MX shows an inbound gateway with a likely provider behind it.
PTR-only clue
40-69%
The provider guess comes mainly from reverse DNS naming.
No stable clue
0-39%
DNS does not expose a provider with enough reliability.
Caveats that change the answer
The hardest cases are not the obvious @gmail.com or @outlook.com addresses. The hard cases are custom domains, domains with inbound filtering, domains with multiple MX records for priority or failover, domains with null MX, and domains that forward mail after receipt. DNS reveals the first receiving hop, and sometimes that is enough for warmup planning. It is not enough for a perfect consumer mailbox census.
The DNS provider is a separate finding. Nameservers and SOA records can identify where DNS is managed, but they do not identify the mailbox provider unless the MX target points to that same provider.
If you are investigating a message sample instead of a recipient list, original headers answer a different question. Received lines, Return-Path, DKIM d=, SPF mailfrom, and an SMTP banner can help identify the sending platform or MTA. They do not prove the mailbox provider behind the recipient address. For that, still query the domain after @ and its MX records.
Microsoft is a good example. Some hostnames point toward consumer Outlook-style mail, while others point toward Microsoft 365 business mail. Both still land in the Microsoft family for throttling, but split them when there is enough confidence because business mail and freemail can behave differently.
What MX lookup can tell you
- Receiving route: Which hosts accept inbound mail for the domain.
- Provider family: Whether the route appears to use Google, Microsoft, Yahoo, Apple, AOL, or another provider.
- Routing confidence: Whether the evidence is direct, indirect, or too weak to use.
What MX lookup cannot tell you
- Final inbox: Forwarding after delivery is usually invisible in public DNS.
- User plan: DNS rarely proves the subscription type or mailbox interface.
- Filtering result: MX lookup does not show whether your next message will hit spam.
Provider confidence levels for direct MX matches, gateway MX records, PTR clues, and unknown results.
Do not overfit the labels
A provider label should guide rate limits, monitoring, and investigation. It should not permanently suppress a recipient or override live engagement data. If the DNS clue is weak, send in a conservative mixed bucket and watch delivery responses.
Use the result for warmup
There are real warmup concerns when a hidden share of a list uses the same mailbox provider. If you ramp based only on visible domains, you can send too much volume into Gmail or Outlook without noticing it. The receiving provider still sees the aggregate traffic across its hosted domains.
Warmup buckets usually start with Google family, Microsoft family, Yahoo family, Apple family, AOL or legacy ISP, business gateway, and unknown. Then apply daily caps by bucket and raise caps only when deferrals, bounces, complaints, and engagement stay stable. Before ramping a new stream, send a real message through an email tester and inspect authentication, headers, and message content.
Keep this separate from sender-side IP reputation DNS checks. Recipient-provider lookup starts with the address domain and MX records. IP reputation checks start with the sending IP, sometimes by reversing IP octets into a DNS query, and they help explain reputation trends, not which provider receives a recipient's mail.
- Normalize first: Lowercase domains, remove invalid addresses, and deduplicate recipient domains.
- Query DNS: Fetch MX answers and cache them with a timestamp.
- Assign buckets: Use provider rules and confidence levels rather than one flat label.
- Throttle by bucket: Keep Gmail, Outlook, Yahoo, Apple, AOL, gateway, and unknown traffic within planned limits.
- Refresh regularly: Recheck active domains because MX routing changes after migrations.
A practical warmup rule
When the provider label is high confidence, use the provider bucket for throttling. When confidence is low, use a conservative unknown bucket and let live delivery signals decide when to increase volume.
Also watch your sending reputation. If bounces or deferrals cluster around one provider bucket, slow that bucket rather than slowing every recipient. If an IP or domain appears on a blocklist (blacklist), fix that reputation issue before increasing volume. Suped includes blocklist monitoring so teams can see IP and domain listing problems beside authentication data.
Where Suped fits
Suped's product assumes mailbox provider detection has limits. Public DNS has limits too. Where Suped helps is the other half of the same deliverability workflow: proving that your own domain is authenticated, monitored, and clean before you push more volume into Gmail, Outlook, Yahoo, Apple, AOL, and business domains.
Suped combines DMARC monitoring, SPF and DKIM checks, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, real-time alerts, issue detection, and steps to fix. The practical workflow is simple: classify recipient domains by MX, then use Suped to keep your sending domain trustworthy while you ramp.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
If you manage many domains or client accounts, Suped's MSP and multi-tenancy dashboard also helps keep warmup, authentication, and reporting work organized across domains. That matters when one sender has clean Google delivery while another sender fails SPF, has missing DKIM, or starts to hit blocklist or blacklist listings.
Views from the trenches
Best practices
Normalize recipient domains first, then group MX answers before assigning provider labels.
Store raw MX, A, and PTR answers so provider rules can be reviewed when routing changes.
Keep freemail and business-hosted variants separate for warmup and reputation analysis.
Common pitfalls
Treating every custom-domain Google MX as consumer Gmail creates poor warmup buckets.
Using only the right side of the email address misses hosted Gmail and Microsoft tenants.
Running huge DNS jobs without caching creates slow results and avoidable resolver pressure.
Expert tips
Check MX hostnames first, then use PTR or Whois only when the host pattern is unclear.
Maintain a rule table with examples, owner notes, confidence, and last-checked dates.
Separate provider detection from throttling logic so bad labels do not block good mail.
Marketer from Email Geeks says MX, A, PTR, and occasional Whois lookups are enough to group most recipient domains into useful provider buckets.
2021-03-04 - Email Geeks
Marketer from Email Geeks says basic scripts plus a spreadsheet work well for raw DNS collection, but cached automation is better for large files.
2021-03-05 - Email Geeks
Use provider buckets, not guesses
The answer is yes: you can usually determine the ISP or mailbox provider behind an email address by checking the recipient domain's MX records and classifying the hostnames. That is the method to trust for warmup planning because it catches custom domains using Google Workspace, Microsoft 365, and other hosted mailbox systems.
Do not treat the label as perfect identity data. Keep the raw DNS result, add confidence, refresh the data, and let live delivery signals override weak labels. Then pair provider buckets with strong authentication, DMARC reporting, sender-side reputation checks, and blocklist or blacklist checks so the sending side is as clear as the recipient segmentation.
