What DNS Records Tell You About an Email Domain

An email domain is more than a name on an address. Behind every working domain is a small set of DNS records that together describe how mail is received, who is allowed to send it, how messages are signed, and how receiving servers should treat mail that fails those checks. Reading those four records — MX, SPF, DKIM, and DMARC — tells you most of what you can know about a domain's email setup without ever logging into its admin console.

MX: Where the Domain Receives Mail

The Mail Exchange record answers the most basic question: where should mail for this domain be delivered? It lists one or more hostnames authorised to accept inbound messages, each with a priority that sets the order in which senders try them. The hostnames themselves are the clearest fingerprint of the email provider — aspmx.l.google.com for Google Workspace, mail.protection.outlook.com for Microsoft 365, and so on.

What MX reveals:

• The provider or service hosting inbound mail.
• Whether redundancy is configured (multiple MX records with different priorities).
• Whether the domain receives mail at all — no MX means no direct inbound delivery.

For the format and priority mechanics, see our MX record primer, and for a business-focused view, understanding MX records for business email.

SPF: Who Is Allowed to Send

The Sender Policy Framework record lives in a TXT entry at the domain apex and lists the servers permitted to send mail on the domain's behalf. It is the outbound counterpart to MX's inbound picture. Receiving servers consult SPF to decide whether a message's sending IP is authorised; a match helps the message pass, while a failure can mark it as spam or reject it outright.

A typical SPF record looks like v=spf1 include:_spf.google.com ~all. The include: mechanism pulls in a provider's authorised IP ranges, and the all mechanism at the end sets the policy for everything else — ~all for a soft fail, -all for a hard fail.

What SPF reveals:

• The authorised sending platforms (via include: values), which corroborate the MX provider signal.
• Any third-party senders the domain has approved, such as marketing or transactional email services.
• How strictly the domain treats unauthorised senders, via the all qualifier.

DKIM: How Messages Are Signed

DomainKeys Identified Mail adds a cryptographic signature to outgoing messages. The sending server signs selected headers and the message body with a private key, and publishes the matching public key in DNS so receivers can verify the signature. The key is stored at a selector-based hostname: selector._domainkey.example.com.

Because the public key is often a CNAME pointing to a provider-managed hostname, DKIM also serves as a provider fingerprint — the target of the CNAME reveals which service rotates the keys.

What DKIM reveals:

• That the message was sent by a server holding the domain's private key — strong evidence it was not tampered with in transit.
• Which provider manages signing, via the selector hostname or CNAME target.
• Whether key rotation is delegated to the provider (common with CNAME-based setups).

One nuance: the selector name is chosen by the domain owner and is not published in a standard place, so checking DKIM usually requires either inspecting a received message's DKIM-Signature header for the selector, or querying a few common selectors like google or selector1.

DMARC: The Policy That Ties It Together

DMARC sits at _dmarc.example.com as a TXT record and tells receiving servers what to do when SPF or DKIM alignment fails. It is the policy layer that unites the other two. A DMARC record specifies a policy (p=none, p=quarantine, or p=reject), an alignment mode, and reporting addresses where receivers can send forensic and aggregate feedback.

What DMARC reveals:

• How strictly the domain enforces authentication — p=none is monitor-only, p=reject is full enforcement.
• Whether the domain is actively monitoring spoofing via aggregate (RUA) and forensic (RUF) reports.
• The domain's maturity in email authentication — a domain with p=reject and reporting configured is signalling a serious, well-maintained setup.

How They Work Together

The four records form a layered defence, each addressing a different question:

• MX answers “where do I send mail to this domain?”
• SPF answers “is the server that sent this message from this domain authorised?”
• DKIM answers “was this message signed by the domain's key and unchanged in transit?”
• DMARC answers “when SPF or DKIM fail, what should the receiver do about it?”

Read together, they describe a complete picture: where mail goes, who can send it, how it is signed, and how strictly the domain protects its identity. A domain with healthy MX, SPF, DKIM, and DMARC records is signalling a mature, deliverable, and spoof-resistant email infrastructure. For a structured way to audit all four, see how businesses can verify their email infrastructure.

How to Check Them

Each record is a public DNS entry, so you can query any of them with standard tools:

• MX: dig MX example.com or use the MX Record Checker.
• SPF: dig TXT example.com and find the entry starting with v=spf1.
• DKIM: dig TXT selector._domainkey.example.com for a known selector.
• DMARC: dig TXT _dmarc.example.com.

The Email Domain Checker bundles these lookups into a single view so you can see all four records for a domain at once, and the Provider Lookup page focuses on the provider identification that MX and SPF enable. To understand the query pipeline behind those tools, how email domain lookup works is the companion read.

What the Combination Tells You

No single record tells the whole story. MX on its own names the inbound provider; SPF adds the authorised outbound senders; DKIM proves message integrity and often reveals the signing provider; DMARC shows how seriously the domain protects its identity. Together, they let you assess deliverability risk, identify the provider with confidence, and gauge the domain's overall email maturity — all from public information. That is what DNS records tell you about an email domain, and it is why reading them is the foundation of every lookup we build.