How to Check MX, SPF and DMARC Records

Checking MX records

dig MX example.com +short
# 10 mx1.example.com.
# 20 mx2.example.com.

nslookup -type=MX example.com

The number before each hostname is priority — lower numbers are tried first. No MX records at all (and no fallback A/AAAA record) means the domain cannot receive mail, full stop.

Checking SPF records

dig TXT example.com +short
# "v=spf1 include:_spf.google.com ~all"

SPF lives as a TXT record directly on the domain — there can be several TXT records for other purposes, so look specifically for one starting with v=spf1. It lists which mail servers are authorized to send on the domain's behalf; its presence (not its exact content) is what most verification checks care about, as a proxy for "this domain's email is actively configured and maintained," rather than parsing the full authorization mechanism.

Checking DMARC records

dig TXT _dmarc.example.com +short
# "v=DMARC1; p=reject; rua=mailto:reports@example.com"

DMARC lives at a fixed subdomain, _dmarc.<domain>, not on the domain itself — a common source of confusion when checking manually. It builds on SPF (and DKIM) to tell receiving mail servers what to do with messages that fail authentication, and its presence indicates a domain owner who's actively managing their email security posture rather than leaving it at defaults.

Why presence matters more than full parsing, for risk purposes

Fully parsing SPF mechanisms or DMARC policy strictness is a deep rabbit hole (nested includes, redirect mechanisms, policy percentages) that mostly matters for anti-spoofing, not for evaluating whether an email address submitted to your form is trustworthy. For risk purposes, presence is the useful signal: a domain with neither SPF nor DMARC configured at all is more likely to be a neglected or throwaway domain than one with both properly set up — regardless of exactly how strict the DMARC policy is.

Checking all three in one call

curl https://api.emailriskradar.com/v1/email/check \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "user@example.com"}'

{
  "domain": {
    "domain": "example.com",
    "has_mx": true,
    "spf": true,
    "dmarc": false
  }
}

This runs all three lookups in parallel server-side, applies short-lived caching so repeat checks of the same domain don't re-query DNS unnecessarily, and folds the results directly into the reputation and risk scores — useful when you need the signal as part of a decision rather than as a standalone DNS report.