Email domain intelligence brings together evidence about a domain’s mail configuration, network infrastructure and, when available, registration. It can help you investigate a customer domain or add technical context to a CRM record. Each observation answers a different question: where mail goes, what sending policy is published, which network announces an address or when the domain was registered.
Read those observations separately before making a decision. A working mail route does not establish that a named mailbox exists, and an old registration does not establish that you can trust its current user. Emvero’s Domain Intelligence collects infrastructure evidence without opening an SMTP session or sending email.
Start with the mail route
Check whether the domain has a route for incoming mail. In an Emvero profile, mail_routing.status can report routable. That establishes a route in the observed DNS configuration; it does not test a recipient.
MX records identify the receiving hosts. A provider match describes the visible inbound operator, which may be a filtering gateway in front of the mailbox service. If mx.provider_match is unknown, keep the provider unknown. An unfamiliar hostname is not evidence that the organisation hosts its own mail. The separate guide shows how to identify an email provider from MX records.
An empty MX answer needs care: SMTP permits an implicit route to the domain’s own address when no MX exists. RFC 5321 describes this fallback. For the diagnostic cases, see a domain without an MX record.
Keep sending configuration and classifications in context
SPF and DMARC fields describe what the domain publishes about sending mail. In Domain Intelligence, not_performed means no message authentication was evaluated. The lookup checks supported publication syntax and policy fields; it does not follow SPF includes to evaluate a sender or discover DKIM keys. The SPF and DMARC comparison explains how those mechanisms relate to a message.
The classifications under email.classification come from reference data. A domain absent from a disposable list has not thereby been proved safe, and a negative public-provider flag does not prove a corporate address.
The field email.catch_all.state reports evidence already held for the domain. This lookup does not make a new recipient probe. An unknown state gives you no basis for recording either “accepts every recipient” or “checks individual mailboxes”.
Read network and registration data at the right level
Both standard and extended profiles include network information. network.mail describes addresses for the mail hosts; network.web describes addresses resolved for the requested domain and the CNAME chain followed to reach them. An autonomous system number, or ASN, identifies the network announcing an address.
Use this to compare infrastructure. Mail and website addresses can share a network while serving different purposes. The network’s country field describes where the autonomous system is registered, so it cannot locate a server. If a CDN or proxy is visible, its edge addresses may conceal the origin. Resolving an address also does not establish that a website responds there.
The extended variant adds registration data retrieved through RDAP, the Registration Data Access Protocol. RDAP distinguishes events such as registration and later changes, each with its own date. RFC 9083 defines these event fields.
Check registration.registered_domain before using the age. A lookup for a subdomain reports registration for its registrable parent. registration.age_days counts whole days from the reported registration date to generated_at; it says nothing about when a company started, when its website launched or when the current owner acquired it. Some registries do not provide the date. Keep that absence visible rather than recording an age of zero.
A worked reading of one profile
Suppose you are reviewing example.com before adding technical details to a customer record. The values below come from a synthetic example, not a live lookup. They are selected observations, not a complete API response.
| Observation | What you can record |
|---|---|
mail_routing.status: routable |
The observed configuration supplies an incoming mail route. |
mx.provider_match: unknown |
No single incoming provider has been identified. |
email.catch_all.state: unknown |
Catch-all behaviour has not been established. |
| Mail host IP addresses include AS64500 and AS64511; website IP addresses include AS64500 | Some mail and website addresses share a network. This does not identify a common service operator. |
registration.age_days: 2191 |
The reported registration is 2,191 whole days old at the example’s generation time. |
SPF -all; DMARC reject |
These are published sending settings, not authentication results for a message. |
The profile gives you useful infrastructure details, but no conclusion about alex@example.com. If onboarding requires evidence about that address, check it separately. The comparison of a full check and a domain check explains what each depth can establish. Confirmation by the user is a further step when control of the mailbox matters; a technical check cannot establish consent to receive your messages or guarantee inbox placement.
For this customer review, you could save the route and registration age while leaving provider and catch-all fields unknown. A recently registered domain could prompt a follow-up question under your own policy. Registration age alone does not justify approving or rejecting a customer.
Check the field you depend on, even when the profile is complete
complete describes completion of the required observations for the selected variant. A complete profile can still contain an unknown provider or catch-all state, or establish that a domain does not accept mail. Network enrichment does not determine that overall status, so read its own metadata.
An extended profile is partial when the registration date is unavailable. That does not erase usable mail-routing evidence. Conversely, if the routing source itself fails, the service can return an error; a DNS failure is not a no-mail finding.
Before using a field, inspect meta.status and reason, then its source, source_version, observed_at, expires_at and stale values where available. A profile assembled now may contain observations made earlier. The Domain Intelligence documentation describes these fields.
Two expiry dates have different meanings: registration.expires_at is the registry’s domain expiry date, while registration.meta.expires_at describes how long the cached registration observation can be reused. Neither tells you when the customer’s mailbox stops working.
Save evidence separately from your decision
In a CRM integration, retain the checked domain, the fields your workflow uses and their source dates. Keep the domain profile separate from a contact’s email verification result. If several contacts share a domain, the profile can supply common domain context without implying that all their mailboxes work.
Store your decision and its reason separately too. That lets you review a record when evidence changes without turning an old provider label or missing registration date into a permanent judgement about a customer. Your integration writes these records; the lookup does not update the CRM automatically.
When retrieving through the API, replaying a completed lookup with the same Idempotency-Key, domain and variant returns its saved answer within the replay window. It does not refresh the observations. Follow the Domain Intelligence API guide for retries and new lookups.
To read a profile without building an integration, inspect a domain with Emvero. Start with the mail route, then use the supporting fields that answer your actual review question.