Answer first: Query the domain’s MX records. The hostnames tell you which system currently receives mail—Google Workspace (smtp.google.com or the legacy aspmx.l.google.com set), Microsoft 365 (*.mail.protection.outlook.com), Zoho, Fastmail, Cloudflare Email Routing, cPanel/hosting, or Arawa Mail. Use that map before you change MX so you know what you are cutting over from and what will break if you point elsewhere.
Why MX hostnames matter more than “who owns the domain”
Registrar and nameserver ownership do not decide who receives mail. Published MX records identify the first inbound gateway. A security filter, forwarding service, or reseller may sit in front of the actual mailbox host. Before migration or dual-provider experiments you need a reliable answer to “which company is answering for this domain right now?” This post maps common fingerprints; the companion pieces cover record mechanics and cutover: Custom-Domain Email Migration Checklist and ArawaMail DNS Records reference.
How we analyzed this
Fingerprints below are the widely documented inbound shapes for each provider as of the draft date. Provider documentation can change; treat host lists as examples and re-check the vendor’s current MX help page before a production cutover. Arawa Mail specifics are taken from current product onboarding (Cloudflare zone required; receiving activation publishes MX).
Quick lookup methods
dig MX example.com +shortnslookup -type=MX example.com- Any public DNS lookup tool that returns priority and hostname
Note priority (lower number = higher preference) and every hostname. Some providers publish one record; others publish a set.
Common provider fingerprints
Google Workspace
Current recommended shape is a single record:
smtp.google.com(priority 1)
Many existing tenants still publish the legacy five-host set:
aspmx.l.google.comalt1.aspmx.l.google.com…alt4.aspmx.l.google.com
Both patterns identify a Google inbound endpoint. They do not prove where every mailbox or downstream delivery ultimately resides. Either is a strong signal of Google Workspace (or Google-hosted inbound).
Microsoft 365 / Exchange Online
- Hosts matching
*.mail.protection.outlook.com
Example pattern: example-com.mail.protection.outlook.com. That is an Exchange Online Protection endpoint; a hybrid or filtering configuration can deliver onward to another mailbox host.
Zoho Mail
mx.zoho.com,mx2.zoho.com,mx3.zoho.com(and regional variants such asmx.zoho.eu)
Fastmail
- Typically
in1-smtp.messagingengine.comandin2-smtp.messagingengine.com
Cloudflare Email Routing
- MX pointing at Cloudflare (often
route1.mx.cloudflare.net/route2.mx.cloudflare.netor similar Cloudflare-owned hosts)
Cloudflare routing hostnames identify a Cloudflare receiving gateway, not the final mailbox product. Cloudflare-managed DNS is also not proof that Cloudflare receives the mail. Confirm the destination through the mailbox/provider dashboard and received-message headers.
cPanel / shared hosting / generic
- Hosts that look like
mail.example.com,example.com, or the hosting provider’s brand (e.g.mx1.privateemail.com,aspmx.l.google.comis Google, not “generic”)
When the MX hostname is the same domain or a well-known hoster brand, the hostname alone is inconclusive: it may be a branded gateway, self-hosted server, or reseller. Check the hosting dashboard and delivery headers.
Amazon SES inbound
SES can receive mail, but production setups often use more complex receipt rules. If you see SES-related MX or documentation pointing at SES inbound endpoints, treat it as developer-oriented receiving rather than a full business mailbox product.
Arawa Mail
Receiving activation publishes MX via an active Cloudflare zone that matches the exact domain. Confirming activation replaces conflicting MX. Receiving must be active before mailbox accounts can be created. Do not invent production hostnames—copy the exact records shown in the Arawa Mail domain dashboard or the live DNS reference. Related: How to Connect a Cloudflare Domain to ArawaMail.
Decision table (what the fingerprint implies)
| MX pattern | Likely provider | Before you change MX |
|---|---|---|
| smtp.google.com or aspmx.l.google.com set | Google Workspace | Export users/mail, plan dual-delivery or staggered cutover |
| *.mail.protection.outlook.com | Microsoft 365 | Check hybrid/Exchange Online only vs on-prem |
| mx.zoho.* | Zoho | Export and re-point carefully |
| messagingengine.com | Fastmail | Standard MX swap after backup |
| Cloudflare Email Routing hosts | Cloudflare | Confirm the forwarding destination; do not mix independent MX sets to duplicate delivery |
| Arawa Mail (dashboard-confirmed) | Arawa Mail | Already on product path; adjust only via dashboard |
| mail.example.com / hoster brand | cPanel/hosting | Often simplest cutover once DNS TTL is low |
What MX does not tell you
- Who sends mail (SPF/DKIM/MAIL FROM can point elsewhere).
- Whether the domain uses catch-all, aliases, or forwarding.
- Whether outbound reputation is healthy.
For authentication and cutover order, continue with SPF, DKIM, and DMARC explained and the migration checklist linked above.
FAQ
Can a domain have more than one provider’s MX at once?
Technically yes (multiple priorities), but most providers expect to be the primary receiver. Split MX is fragile for shared inboxes and deliverability debugging.
Does changing nameservers change who receives mail?
Only if the new nameservers publish different MX. Nameserver change alone does not move mail.
How do I confirm Arawa Mail is live after activation?
Look up MX again and compare to the records shown in the Arawa Mail domain UI. Then send a test message to a new mailbox on that domain.
Once you know the current provider, choose the matching migration or setup guide rather than guessing hostnames from memory.
Sources and review
Reviewed on 3 October 2026. Product behavior follows the linked documentation; examples are illustrative.