MX record

How an MX record works

An MX record lives in DNS next to A, AAAA, and CNAME records. Wikipedia describes it as the record that specifies the mail server responsible for accepting email messages on behalf of a domain name 1. A domain can publish one MX record or several. When several exist, each one carries a preference value, also called priority, and a host name that must resolve to an address 1.

Senders sort the MX hosts by preference and try the lowest number first 1. Equal preference values are a common way to split load across two hosts 1. Cloudflare documents MX among the standard DNS record types that operators create when they want a domain to receive mail 2. The host name in the MX record must point at a real mail exchanger. Pointing it at a CNAME is a common misconfiguration that breaks delivery.

If DNS has no MX record, some senders fall back to the domain's address record. That fallback is fragile and many modern systems treat a missing MX as a hard stop. RichAPI Email verifier surfaces this as mxFound, a boolean on every successful verdict 3. When mxFound is false, the domain cannot receive mail from anyone, so the row can leave the list before anyone debates status labels 3.

MX checks are cheap relative to a full SMTP probe. They answer a binary question about the domain, not about one mailbox. A domain can have a healthy MX and still reject a specific local part. That is why email verification combines mxFound with other signals rather than stopping at DNS alone 3.

DNS operators publish MX records through their DNS host. Cloudflare lists MX as one of the record types you create when a domain should receive mail 2. The workflow is the same on most hosts. Create the MX, point it at a mail host, wait for TTL to expire, then confirm with a public DNS lookup. Until that lookup returns the new host, some senders still use the old path.

Preference values deserve a short note. Lower numbers are tried first 1. A common pattern sets the primary host to 10 and a backup to 20 1. Another pattern sets two hosts to the same preference so traffic splits 1. Neither pattern is magic. What breaks delivery is an MX whose host no longer resolves, or an MX that points at a CNAME instead of an address record.

MX is also the first place catch-all policy shows up. The receiving host named in the MX decides whether unknown local parts get a mailbox, a rejection, or a silent drop. The MX record itself does not encode that policy. It only names the host. That is why mxFound true is necessary but not sufficient for a send decision 3.

Why MX records matter for list hygiene

List hygiene starts with domains that cannot receive mail at all. An address on a domain with no MX will bounce on the first send. Catching that with mxFound before the campaign saves bounce rate and sender reputation.

Outbound tools sometimes skip the DNS step and jump to SMTP. That wastes time on domains that were never set up for mail. Checking MX first is the filter that makes later steps worth running. RichAPI Email verifier returns mxFound on every successful call so a pipeline can drop those rows in one branch 3.

MX also explains some false confidence. A domain can show a valid MX while the company uses a catch-all. Every local part looks deliverable at the handshake. The MX says the domain accepts mail. It does not say a person named Jane has a mailbox. Pair the MX signal with catch-all email handling and a hard bounce watch after the first wave.

Agencies inheriting a CRM often find thousands of contacts on parked domains, expired domains, or domains that never published mail. Running the verifier and deleting on mxFound false is the cheapest cleanup pass 3. The call bills 2 credits per verdict, and a waterfall miss with no verdict bills zero 3. New accounts start with 100 free credits 3.

Operators who manage DNS should also watch preference values. Setting every MX to the same preference spreads load. Setting one much lower creates a primary and a backup. Both patterns are valid. The failure mode is an MX that points at a host that no longer resolves, which looks fine in a stale spreadsheet and fails in live DNS.

Product builders who expose email fields in a signup form can call the verifier server-side and reject mxFound false before the account is created 3. That single branch stops fake domains and typos of major mail hosts from landing in the database. It does not replace CAPTCHA or fraud checks. It removes a class of rows that would have hard bounced on the first message.

RevOps teams should log the mxFound value with a timestamp. Domains change registrars. Mail moves from one ESP to another. A contact that verified clean in January can sit on a domain that dropped MX in June. Re-verification close to send time is the habit that keeps the gate honest 3. Storing one forever-green mxFound flag without a date recreates the stale-list problem the check was meant to solve.

When mxFound is true and status still looks weak, dig into SMTP verification and catch-all handling next. When mxFound is false, stop. There is no mailbox-level nuance left to debate on a domain that cannot receive mail 3.

Example of an MX record check

Suppose a cleanup job has ten thousand contact rows with unknown domains. The job calls email_verifier on each address 3. For every response it reads mxFound first 3. Rows with mxFound false leave the sendable list immediately, because those domains cannot receive mail 3.

A domain that returns mxFound true moves to the next branch. The job then reads disposable and status 3. Disposable domains leave the B2B list. Catch-all statuses go to a separate track. Only addresses that pass those gates stay in the cold-send pool.

Billing follows the verifier rules. A successful verdict costs 2 credits 3. A call where providers run and reach no verdict returns billed false at zero cost 3. New accounts get 100 free credits to test the flow 3.

After the pass, the job stores mxFound next to the contact. When a domain later drops its MX, a re-verify catches it. That is cheaper than learning from a wave of hard bounces. The MX check does not replace SMTP verification or inbox placement tests. It is the first gate that removes domains that were never going to accept mail.

A second example is a signup webhook. A trial form posts an address to the backend. The backend calls email_verifier before it creates the user 3. If mxFound is false, the API returns a validation error and never writes the row 3. If mxFound is true, the flow continues and may still reject disposable domains for a B2B product 3.

That pattern costs 2 credits per verdict 3. On a quiet day it is cheap. On a launch day it still beats storing thousands of dead addresses and learning from bounce webhooks later. The free 100 credits on a new RichAPI account cover an early test of the same webhook 3.

Finally, when a deliverability review finds a cluster of hard bounces on one corporate domain, check public DNS before blaming content. If the MX disappeared during a migration, the fix is to pause that domain and wait for DNS to settle. Verification will show mxFound false until it does 3.

MX record vs SMTP verification

An MX check asks whether the domain can receive mail at all. SMTP verification asks whether a specific mailbox answers at the mail server. Both matter before a cold send, and they answer different questions.