emailverifier.dev
Posts

Which DNS Records Does a Domain Need to Receive Email?

| 6 min read | Usama Ejaz
An inbound mail route reaches an MX server while SPF, DKIM, DMARC, PTR, and website signals remain in separate outbound and context lanes.

To receive email, a domain needs a usable SMTP route. That normally means one or more MX records whose targets resolve to A or AAAA addresses. SMTP also permits an older fallback: when no MX record exists, the domain itself can act as an implicit mail exchanger if it resolves to an address.

SPF, DKIM, and DMARC do not make a recipient domain reachable. A website does not either. Those signals answer different questions, and mixing them into one “domain health” score can reject perfectly usable signup addresses.

Here is the kind of hypothetical result I would not use:

{
  "domain": "customer.example",
  "website": false,
  "mx": true,
  "spf": false,
  "dkim": false,
  "dmarc": false,
  "valid": false
}

The problem is not the data. The problem is the last line. Four unrelated absences have overridden the one signal that actually answers whether the domain publishes a mail route.

What does SMTP actually look up?

RFC 5321, section 5.1 tells an SMTP sender to look for MX records first. When ordinary MX records exist, each exchanger name must resolve to at least one A or AAAA address. That gives the sender a destination to try.

customer.example.       3600  IN  MX   10  inbound.mailhost.example.
inbound.mailhost.example. 3600 IN A    192.0.2.40

This example uses reserved names and an address from the documentation range. It is a protocol illustration, not a live mail setup.

If the MX answer is empty, SMTP creates an implicit MX pointing back to the recipient domain. That fallback only helps when the domain has a usable A or AAAA address. If the domain publishes MX 0 ., the meaning is the opposite: RFC 7505 defines that null MX as an explicit statement that the domain accepts no mail.

The complete routing branch is in my guide to null MX versus no MX record. The important boundary here is smaller: ordinary MX or implicit MX can establish a possible route. Neither one proves that a particular mailbox exists.

Why don’t SPF, DKIM, and DMARC prove receiving capability?

Because they authenticate mail sent from a domain. They do not advertise where mail addressed to that domain should go.

DNS evidence Question it answers Use for a signup address
MX plus target A/AAAA Where can an SMTP sender try delivery? Continue to mailbox checks
SPF TXT record Which client hosts may use a domain in SMTP MAIL FROM or HELO? Do not use its absence as a recipient failure
DKIM key Can a receiver validate a signature claiming responsibility by the signing domain? Do not use its absence as a recipient failure
DMARC policy How should a receiver evaluate aligned SPF or DKIM for the visible author domain? Do not use its absence as a recipient failure

SPF checks authorization for the SMTP client against the MAIL FROM or HELO identity. DKIM associates a signing domain with a message. DMARC evaluates the visible author domain against authenticated SPF and DKIM identifiers.

None of those standards turns a missing policy into “this domain cannot receive mail.” A domain might receive support messages while sending no mail at all. It may outsource inbound and outbound mail to different providers. It may have incomplete authentication that deserves an administrator’s attention without making every recipient at that domain invalid.

The reverse mistake is just as risky. A domain with perfect SPF, DKIM, and DMARC can still publish a null MX, have no usable inbound route, or reject a specific recipient. Authentication is not mailbox verification. My SPF, DKIM, and DMARC guide owns the message-authentication side of that distinction.

What about a website or reverse DNS?

An HTTPS response is useful for learning about an organization, but it is outside SMTP’s recipient-routing lookup. A domain can delegate its website and mail to different systems, run only mail, or intentionally have no public website. I would not block an address because https://domain.example times out, redirects, or returns no page.

PTR records are also easy to misplace. Reverse DNS starts from a sending IP and asks which hostname represents it. Clean forward and reverse DNS is useful sending infrastructure, but it does not tell you whether person@domain.example has an inbound route. The reverse-DNS guide covers that separate round trip.

A provider classification belongs in its own field too. A known disposable provider can be a policy signal, while a free or personal provider is not automatically disposable. Neither classification replaces mail routing or mailbox evidence.

Run a five-query audit without collapsing the answers

These commands inspect the records, but the interpretation matters more than the command count:

domain="customer.example"

dig "$domain" MX
dig "$domain" A
dig "$domain" AAAA
dig "$domain" TXT
dig "_dmarc.$domain" TXT

Read the results in separate lanes:

  1. Routing: ordinary MX, null MX, empty MX with an address fallback, confirmed DNS failure, or temporary DNS error.
  2. Sender authentication: SPF and DMARC policy at the queried names. A DKIM key cannot be discovered generically without knowing the selector.
  3. Provider risk: disposable, personal/free, privacy relay, or unclassified.

dig +short is convenient, but it hides the DNS response code. Use the full output when you need to distinguish an empty answer from NXDOMAIN, SERVFAIL, or a timeout. Temporary DNS trouble should remain unknown instead of becoming a permanent rejection.

The free MX, SPF, and DMARC tools expose these DNS views separately. Current emailverifier.dev domain results also keep classification, risk, and mail_routing as separate fields. That separation is deliberate: a domain-level result does not confirm one mailbox or guarantee delivery.

Use one decision for routing and different decisions for risk

For a signup flow, I would map domain evidence like this:

  • Confirmed unavailable routing: block and ask the user to correct the domain.
  • Available routing: continue to complete-address verification. Do not call the mailbox confirmed yet.
  • Unknown routing: retry with a bounded delay or keep the account pending. Do not translate a resolver failure into “invalid email.”
  • Disposable or role-address signal: apply the product’s risk policy without rewriting the routing result.
  • Missing SPF, DKIM, DMARC, PTR, or website: do not use that absence to reject a recipient address.

The strongest fair objection is that missing sender authentication can still indicate weak domain hygiene. It can. If you are evaluating a vendor’s security posture, keep that evidence and review it in that context. A signup verifier has a narrower job: decide whether the address is structured, routed, risky, accepted, rejected, or inconclusive. Turning an outbound-security observation into a recipient verdict makes the result look more certain while making it less accurate.

The corrected model is not one valid boolean. Keep mail routing, sender authentication, provider classification, mailbox evidence, and inbox confirmation separate. Then let each signal change only the decision it can actually support.

Continue reading

← Back to blog