{"id":1017,"date":"2026-08-01T11:28:18","date_gmt":"2026-08-01T08:28:18","guid":{"rendered":"https:\/\/fluidcrm.io\/blog\/?p=1017"},"modified":"2026-08-01T11:35:32","modified_gmt":"2026-08-01T08:35:32","slug":"how-to-check-mx-records","status":"publish","type":"post","link":"https:\/\/fluidcrm.io\/blog\/how-to-check-mx-records\/","title":{"rendered":"How To Check MX Records (and What They Actually Tell You)"},"content":{"rendered":"\n

Learning how to check MX records takes about a minute, and you do not need permission to do it. Every domain that receives email has an MX record and that record is public. Which means you can find out whether a company runs Gmail, Outlook, Zoho or an enterprise filter that kills most of it on arrival.<\/p>\n\n\n\n

Most posts about MX records teach you how to set one up. This one teaches you how to read one. You get the 3 ways to check any domain using the free bulk MX lookup tool<\/a>, a table that turns a hostname into a provider name and my honest take on which providers are brutal to cold email after 3 years of doing it at Fenixtal.<\/p>\n\n\n\n

To check a domain’s MX records, run the domain through an MX lookup tool, or use nslookup -q=mx domain.com<\/code> on Windows and dig domain.com MX +short<\/code> on Mac or Linux. The hostname in the result tells you which provider hosts that domain’s email.<\/strong><\/p>\n\n\n\n

<\/span>What Is an MX Record?<\/span><\/h2>\n\n\n\n

An MX record is a DNS setting that tells the rest of the internet which server should receive email for a domain.<\/strong><\/p>\n\n\n\n

MX stands for Mail Exchanger. When someone sends a message to hello@yourcompany.com<\/a>, their mail server asks DNS one question first. Where do I drop this? The MX record is the answer.<\/p>\n\n\n\n

Think of a big office building. The street address gets the courier to the front door, but the courier still needs the mailroom to sort the delivery. Your domain is the street address. Your MX record is the sign on the mailroom door telling the courier which desk to hand the mail to.<\/p>\n\n\n\n

Two rules matter when you read one. An MX record points to a hostname like mail.example.com<\/code>, never to an IP address. And that hostname cannot be a CNAME, which is a rule written into the DNS spec itself<\/a>. Plenty of broken mail setups trace back to somebody ignoring that second rule.<\/p>\n\n\n\n

A domain can have several MX records at once. That is normal and it is how failover works, which I cover further down.<\/p>\n\n\n\n

<\/span>How To Check MX Records for Any Domain (3 Methods)<\/span><\/h2>\n\n\n\n

Checking MX records takes under a minute, and you do not need access to the domain to do it. MX records are public DNS data, so you can look up any domain you like, including a prospect’s. Here are the 3 ways, fastest first.<\/p>\n\n\n\n

<\/span>Method 1: Use an online MX lookup tool (fastest)<\/span><\/h3>\n\n\n\n
    \n
  1. Open the free bulk MX lookup tool<\/a> (it can lookup individual domains and emails too)<\/li>\n\n\n\n
  2. Type the domain on its own, with no www<\/code> and no https:\/\/<\/code><\/li>\n\n\n\n
  3. Press check and read the host column<\/li>\n<\/ol>\n\n\n\n

    The host column is the part that matters. Everything else on the screen is supporting detail.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    <\/span>Method 2: Run it from the command line<\/span><\/h3>\n\n\n\n

    If you live in a terminal, this is quicker than opening a browser.<\/p>\n\n\n\n

    On Windows:<\/p>\n\n\n\n

    nslookup -q=mx example.com<\/code><\/pre>\n\n\n\n
    On Mac and Linux:<\/p>\n\n\n\n
    dig example.com MX +short<\/code><\/pre>\n\n\n\n
    The dig<\/code> version gives you the cleanest output, usually two columns. The number on the left is the priority and the text on the right is the mail host. The nslookup<\/code> version prints the same information with more words around it.<\/p>\n\n\n\n
    <\/span>Method 3: Check your DNS provider dashboard<\/span><\/h3>\n\n\n\n
    This one only works for domains you own. Log into Cloudflare, Namecheap, GoDaddy or wherever your DNS lives, open the DNS records section and filter for MX.<\/p>\n\n\n\n
    One catch that trips people up. The dashboard shows what you saved, not always what the world can see. If you changed a record 10 minutes ago, the dashboard says done while half the internet is still serving the old answer from cache. When you want the truth, check from outside with method 1 or 2.<\/p>\n\n\n\n
    <\/span>What Your MX Record Actually Tells You<\/span><\/h2>\n\n\n\n
    The hostname inside an MX record is a fingerprint. Every major email provider uses its own hostname pattern, so once you know the patterns you can name the provider on sight without asking anyone.<\/p>\n\n\n\n
    If the MX record contains<\/th>Email is hosted on<\/th><\/tr><\/thead>
    aspmx.l.google.com or googlemail.com<\/td>Google Workspace (Gmail)<\/td><\/tr>
    mail.protection.outlook.com<\/td>Microsoft 365 \/ Outlook<\/td><\/tr>
    mx.zoho.com or mx.zoho.eu<\/td>Zoho Mail<\/td><\/tr>
    *.pphosted.com or *.ppe-hosted.com<\/td>Proofpoint security gateway<\/td><\/tr>
    *.barracudanetworks.com<\/td>Barracuda security gateway<\/td><\/tr>
    *.mimecast.com<\/td>Mimecast security gateway<\/td><\/tr>
    mx1.privateemail.com<\/td>Namecheap Private Email<\/td><\/tr>
    in1-smtp.messagingengine.com<\/td>Fastmail<\/td><\/tr>
    mx.yandex.net<\/td>Yandex<\/td><\/tr>
    A local or country-specific host<\/td>Regional provider or self-hosted<\/td><\/tr>
    No MX record at all<\/td>No dedicated email host, red flag<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    That last row needs a closer look. When a domain has no MX record, sending servers fall back to its A record and try to deliver there instead. That almost never works, because a parked domain or a plain website server is not running a mail service. Sometimes the missing record is on purpose, because the domain redirects somewhere else or exists only to stop somebody else registering it. Sometimes it is a mistake nobody has noticed yet. Either way, treat that address as undeliverable and pull it before you send.<\/p>\n\n\n\n
    <\/span>Why the Email Provider Matters for Cold Email<\/span><\/h2>\n\n\n\n
    The provider behind a domain changes how hard it is to land a cold email in the inbox. Same message, same sending domain, same warmup, different provider, different result.<\/p>\n\n\n\n
    In 3 years running cold email at Fenixtal I sent for 50+ B2B clients across marketing agencies, dev firms, construction companies and compliance companies. 1,000+ meetings booked, 12M\u20ac+ in pipeline. The thing that surprised me most had nothing to do with copy. Two lists with the same offer and the same sender would perform completely differently, and the split kept coming down to where those mailboxes lived.<\/p>\n\n\n\n
    Provider<\/th>Difficulty<\/th>Why<\/th><\/tr><\/thead>
    Gmail \/ Google Workspace<\/td>Easiest<\/td>Most forgiving of the majors<\/td><\/tr>
    Zoho, Fastmail, regional hosts, custom SMTP<\/td>Moderate<\/td>Smaller, less aggressive filters. Often easier than Outlook<\/td><\/tr>
    Microsoft 365 \/ Outlook<\/td>Hard<\/td>Strict, many signals, more sensitive than Gmail<\/td><\/tr>
    Proofpoint, Barracuda, Mimecast<\/td>Hardest<\/td>Enterprise gateways sitting in front of the mailbox, very aggressive<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Most people assume the giant providers are the strict ones and the small regional hosts will let anything through. That is half right. Gmail is the biggest and the most forgiving of the lot. Outlook is the wall. Microsoft tenants are where I saw the most silent filtering, the kind where nothing bounces and nothing lands anywhere the prospect will ever look.<\/p>\n\n\n\n
    The gateway rows tell you something extra. If a domain sits behind Proofpoint, Barracuda or Mimecast, that company was big enough to buy a separate security layer for its email. You are not just looking at a hard filter, you are looking at a company with a procurement process and an IT department.<\/p>\n\n\n\n
    So the practical use is simple. Before you send to a list, check what the MX records say about it. A list full of pphosted.com<\/code> and barracudanetworks.com<\/code> means expect a fight, warm up harder and lower your daily volume. A list that is mostly Gmail means you can move faster. If you are running this kind of outreach as a service, the same logic applies to how you track replies in a CRM built for cold email agencies<\/a> and how you set up a pipeline for outbound work<\/a>.<\/p>\n\n\n\n
    Take the last list you sent to. How many of those domains were sitting behind Outlook or a gateway? If you have no idea, that is the whole problem in one sentence.<\/p>\n\n\n\n
    One honest caveat. The provider is not the only thing that decides whether you land. Domain reputation, warmup, sending volume and the content of the message all move the needle too. The MX record just tells you what you are walking into before you start.<\/p>\n\n\n\n
    One more DNS check worth doing at the same time. Since February 2024 Google and Yahoo have required every sender to have SPF or DKIM, and bulk senders above 5,000 messages a day to Gmail need SPF, DKIM and DMARC together. Those are separate records from the MX and they sit on your sending domain rather than the prospect’s, but if you are already in DNS before a campaign it costs nothing to confirm all 3 are set.<\/p>\n\n\n\n
    <\/span>How To Check MX Records for a Whole Prospect List<\/span><\/h2>\n\n\n\n
    Checking one domain is easy. Checking 8,000 of them is a different job, and copy-pasting into a lookup tool one row at a time is not a plan.<\/p>\n\n\n\n
    For single domains, the free MX lookup tool<\/a> is the fastest route. Paste the domain, read the host, move on.<\/p>\n\n\n\n
    For a full list, you need something built for lead lists. csvgo.io<\/a> checks 50k+ MX records inside a list while it verifies emails, verifies catch-all addresses, cleans company names and organizes prospect-list CSVs, all in one flow. It is the bulk companion to a single-domain lookup, so instead of a hostname for one prospect you get a provider column across the whole file.<\/p>\n\n\n\n
    \"CSVgo.io<\/figure>\n\n\n\n
    Once the file is clean you can sort by provider and split your sending. Gmail-heavy segments on one schedule, Outlook and gateway segments on a slower one. If you are still putting your outbound stack together, this fits alongside the other sales tools worth using early<\/a>. Before you send, the rest of the setup matters too, and I covered that in the cold email outreach guide<\/a>.<\/p>\n\n\n\n
    <\/span>How To Read an MX Record: Priority, Host and TTL<\/span><\/h2>\n\n\n\n
    An MX record has 3 parts you actually read: priority, host and TTL. Once you know what each one does, a lookup result stops looking like noise.<\/p>\n\n\n\n
    Priority<\/th>Host<\/th>TTL<\/th><\/tr><\/thead>
    10<\/td>mail1.example.com<\/td>3600<\/td><\/tr>
    20<\/td>mail2.example.com<\/td>3600<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Priority<\/strong> is the number on the left, and lower wins. Mail goes to mail1.example.com<\/code> first because 10 beats 20. If that server is down or refusing connections, the sending server falls back to mail2.example.com<\/code>. The numbers themselves mean nothing on their own, only their order matters, which is why you see 1 and 5 on some domains and 10 and 20 on others.<\/p>\n\n\n\n
    When two records share the same priority number, mail gets spread across them roughly evenly. That is how bigger providers share incoming load across several servers.<\/p>\n\n\n\n
    Host<\/strong> is the mail server hostname. This is the field you read to identify the provider, and it is the only part of the record that tells you anything about the company you are looking at.<\/p>\n\n\n\n
    TTL<\/strong> is time to live, in seconds. It says how long other servers are allowed to remember this answer before asking again. A TTL of 3600 means one hour of cache. Drop it to 300 before you plan a migration so changes spread fast, then put it back up once everything is stable.<\/p>\n\n\n\n
    <\/span>MX Record Example (Annotated)<\/span><\/h2>\n\n\n\n
    Here is what a domain on Google Workspace looks like when you run a lookup on it, with every field labeled.<\/p>\n\n\n\n
    Type<\/th>Name<\/th>Priority<\/th>Value<\/th>TTL<\/th><\/tr><\/thead>
    MX<\/td>@<\/td>1<\/td>aspmx.l.google.com<\/td>3600<\/td><\/tr>
    MX<\/td>@<\/td>5<\/td>alt1.aspmx.l.google.com<\/td>3600<\/td><\/tr>
    MX<\/td>@<\/td>5<\/td>alt2.aspmx.l.google.com<\/td>3600<\/td><\/tr>
    MX<\/td>@<\/td>10<\/td>alt3.aspmx.l.google.com<\/td>3600<\/td><\/tr>
    MX<\/td>@<\/td>10<\/td>alt4.aspmx.l.google.com<\/td>3600<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Reading it line by line:<\/p>\n\n\n\n