An MX record identifies mail-exchange handling for a domain, but it does not prove that a specific address exists, accepts mail, belongs to the intended person, or will be delivered. A contact-list quality process should treat domain evidence, mailbox evidence, public publication, and sending outcome as separate facts.
VISUAL LESSON
What you will learn
- 01Normalize and resolve an email domain.
- 02Distinguish MX evidence from mailbox verification.
- 03Create a review and suppression record.
ILLUSTRATIVE WORKED EXAMPLE
Separate an illustrative email evidence set
PRACTICAL INTERFACE MAP
Move from raw address to an evidence-based status
Store raw value, page URL, page title, business identity, location context, access date, and source type.
Parse the domain, apply international-domain handling, check resolution and MX evidence, and timestamp the result.
Keep valid evidence, quarantine conflicts, suppress known failures, and avoid calling an untested mailbox deliverable.
STEP-BY-STEP LESSON
Public source → normalized domain → DNS evidence → cautious contact status
THE LEAD ATLAS METHOD
Lead Atlas Data can research a done-for-you business-contact list for the customer's exact campaign, locations, categories, and market, with domain and source-evidence rules defined in the brief.See how custom list research works ↗Preserve the source evidence
Store the exact email string, business name, location, public page URL, page title or section, date accessed, source type, and whether the address was directly published or inferred. Never replace a published general address with a guessed personal pattern.
Keep raw and normalized fields separate. A footer address, role inbox, named-contact page, privacy contact, and form notification address have different purposes and should not be flattened into the same campaign eligibility.
Normalize the domain safely
Trim whitespace, lowercase the domain portion, normalize Unicode and internationalized domain representation consistently, remove trailing punctuation, and flag malformed local parts, missing separators, embedded spaces, disposable services, or obvious placeholders. Preserve the original string.
Resolve aliases and redirects at the business-identity level separately from email parsing. A website's canonical domain, sending domain, and mail-receiving domain can legitimately differ; the difference needs evidence rather than automatic rejection.
Inspect DNS and MX evidence
Query DNS through an approved resolver and record response time, result, MX hosts and preferences, DNS errors, and review date. RFC 5321 describes mail routing behavior, including handling when an explicit MX record is absent, so a missing MX alone should not be translated into a universal mailbox claim.
Distinguish NXDOMAIN, temporary resolution failure, null MX, explicit MX, address-record fallback, and lookup timeout. Retest temporary failures later and keep resolver evidence so a changing domain is not judged from one transient request.
Keep mailbox status separate
A domain that accepts mail can still reject a specific local part, block a sender, defer delivery, route a catch-all, or accept then filter the message. Do not perform intrusive SMTP probing or claim a mailbox is verified without a permitted, documented method.
Use real sending outcomes, bounce categories, replies, opt-outs, and provider feedback under the organization's responsible outreach process. Suppress hard failures and preferences promptly; treat soft failures according to a limited retry policy.
Produce a reviewable contact decision
Assign statuses such as source-confirmed, domain-resolves, mail-routing-present, temporary-DNS-failure, domain-invalid, mailbox-unknown, prior-hard-bounce, suppressed, or manual review. Keep each status tied to dated evidence.
Deliverable: raw and normalized emails, public-source map, domain parser version, DNS and MX results, temporary-failure queue, mailbox-claim policy, sending-outcome fields, suppression merge, manual-review cases, refresh schedule, and data owner.
Turn this lesson into a research brief.
Apply “Review B2B Email Domains and MX Records Without Claiming Mailbox Deliverability” to one campaign before requesting or using a list.
- 01Market boundary
Name the locations and business categories this decision applies to.
- 02Fit evidence
Write the public signals that would make a business relevant enough to review.
- 03Exclusions
List the business types, markets, and records that should not enter the campaign.
- 04Outreach use
State who will review the list, personalize the message, and record outcomes.
THE TAKEAWAY
Use DNS and MX checks to understand the domain, not to certify a mailbox; preserve the public source and let actual sending systems handle delivery outcomes responsibly.OFFICIAL REFERENCES