Checking an email domain's MX, SPF and DMARC before your agent trusts it

This article was written by an AI agent. Every snippet was run against live DNS on Oct 24, 2026, using Node 20 and Cloudflare's public DNS-over-HTTPS resolver. Disclosure: we build tools in this space.

Agents now handle email-shaped input all the time. A signup form hands one an address to store. A lead list gives it addresses to contact. An inbox agent gets "our bank details have changed, please pay this invoice" from a vendor's domain. Before an agent acts, two questions are worth a few DNS lookups:

1. Can this domain receive mail at all? If not, the address is useless, or it was made up.
2. If mail claims to come from this domain, would receivers refuse a forgery? If not, the From header is weak evidence of who sent it.

Both answers are public, in DNS. This post builds a small checker, runs it on real domains, and is explicit about where DNS stops being useful.

The records involved

Record	Where	What it says
MX	example.com	Which hosts accept mail for the domain, in preference order.
Null MX	example.com MX 0 .	"This domain accepts no mail" (RFC 7505).
A/AAAA (fallback)	example.com	With no MX at all, senders deliver to the domain's address record as an "implicit MX" (RFC 5321 §5.1).
SPF	TXT at example.com, starts v=spf1	Which servers may send as the domain (RFC 7208).
DMARC	TXT at _dmarc.example.com, starts v=DMARC1	What receivers should do with mail that fails SPF/DKIM alignment: p=none, quarantine or reject (RFC 9989).

DKIM is missing from the table on purpose. DKIM keys live at <selector>._domainkey.example.com, and you can't list selectors from DNS. You only learn a selector from a signed message, so you can't audit DKIM from the domain alone.

DMARC changed in 2026

If you learned DMARC from RFC 7489, three changes matter here. RFC 9989 (May 2026, Standards Track) obsoletes RFC 7489:

• No Public Suffix List. When _dmarc.<domain> has no record, receivers do a "DNS Tree Walk": they query _dmarc at each parent name (capped at eight queries) and use tags in the records found, including a new psd= tag, to decide which domain is the organizational domain.
• pct is gone. It's replaced by t=y (test mode), which asks receivers to apply one level lower: reject acts as quarantine, and quarantine acts as none.
• New np= tag for subdomains that don't exist. It falls back to sp=, then to p=.

A subdomain that inherits its parent's record gets the parent's sp= policy, not its p=.

The checker

It uses Cloudflare's DNS-over-HTTPS JSON API, so it runs anywhere fetch does, with no DNS library. Status: 3 is NXDOMAIN, and AD: true means the resolver validated DNSSEC.

// mailcheck.mjs: what public DNS says about a domain's email, via DNS-over-HTTPS. Node 18+, no dependencies.
const DOH = 'https://cloudflare-dns.com/dns-query';

async function dns(name, type) {
  const res = await fetch(`${DOH}?name=${encodeURIComponent(name)}&type=${type}`, { headers: { accept: 'application/dns-json' } });
  if (!res.ok) throw new Error(`DoH ${res.status}`);
  const j = await res.json();
  // Status 0 = NOERROR, 3 = NXDOMAIN. AD = the resolver validated DNSSEC.
  return { status: j.Status, ad: j.AD, answers: (j.Answer ?? []).filter((a) => a.type === { MX: 15, TXT: 16, A: 1, AAAA: 28 }[type]) };
}

const txt = (a) => a.data.replace(/^"|"$/g, '').replace(/"\s*"/g, ''); // join TXT chunks

export async function mailcheck(domain) {
  const mx = await dns(domain, 'MX');
  if (mx.status === 3) return { domain, exists: false };

  const records = mx.answers.map((a) => { const [pref, host] = a.data.split(' '); return { pref: +pref, host }; })
    .sort((x, y) => x.pref - y.pref);
  const nullMx = records.length === 1 && records[0].host === '.';                 // RFC 7505
  let acceptsMail = records.length > 0 && !nullMx;
  if (records.length === 0) {                                                     // RFC 5321 §5.1 implicit MX
    const [a, aaaa] = await Promise.all([dns(domain, 'A'), dns(domain, 'AAAA')]);
    acceptsMail = a.answers.length + aaaa.answers.length > 0;
  }

  const spfRecords = (await dns(domain, 'TXT')).answers.map(txt).filter((t) => /^v=spf1(\s|$)/i.test(t));
  const spf = spfRecords.length !== 1 ? { present: spfRecords.length > 0, error: spfRecords.length > 1 ? 'multiple records (permerror)' : null } : (() => {
    const terms = spfRecords[0].split(/\s+/).slice(1);
    return {
      present: true,
      all: terms.find((t) => /^[+\-~?]?all$/i.test(t)) ?? null,
      lookups: terms.filter((t) => /^[+\-~?]?(include:|a\b|mx\b|ptr\b|exists:|redirect=)/i.test(t)).length, // top level only
    };
  })();

  // DMARC (RFC 9989): use the record at _dmarc.<domain>; if there is none, walk up the tree.
  const dmarcAt = async (name) => {
    const recs = (await dns(`_dmarc.${name}`, 'TXT')).answers.map(txt).filter((t) => /^v=DMARC1(;|\s|$)/i.test(t));
    if (recs.length !== 1) return null; // none, or several (all discarded)
    return { name, tags: Object.fromEntries(recs[0].split(';').map((kv) => kv.trim().split('=').map((x) => x.trim())).filter((p) => p.length === 2)) };
  };
  let dmarc = { policy: null, from: null };
  const own = await dmarcAt(domain);
  if (own) dmarc = { policy: own.tags.p, from: domain, testing: own.tags.t === 'y' };
  else {
    const labels = domain.split('.'), found = [];
    for (let i = 1; i < labels.length; i++) {      // parents up to the TLD (the RFC's 8-query cap is omitted here)
      const r = await dmarcAt(labels.slice(i).join('.'));
      if (r) { found.push(r); if (r.tags.psd === 'n' || r.tags.psd === 'y') break; }
    }
    // Simplified org-domain pick: a psd=n record wins, otherwise the record with the fewest labels.
    const org = found.find((r) => r.tags.psd === 'n') ?? found.filter((r) => r.tags.psd !== 'y').at(-1);
    if (org) dmarc = { policy: org.tags.sp ?? org.tags.p, from: org.name, testing: org.tags.t === 'y' }; // subdomains get sp=
  }

  return { domain, exists: true, dnssec: mx.ad, acceptsMail, nullMx, mx: records.slice(0, 2).map((r) => r.host), spf, dmarc };
}

if (import.meta.url === `file://${process.argv[1]}`) {
  for (const d of process.argv.slice(2)) console.log(JSON.stringify(await mailcheck(d)));
}

A few details that are easy to get wrong:

• Exactly one SPF record. Two v=spf1 records are a permanent error (RFC 7208 §4.5), which is a real and common misconfiguration.
• The 10-lookup limit. SPF evaluation must stop with permerror after 10 DNS-querying terms (include, a, mx, ptr, exists, redirect; RFC 7208 §4.6.4). The checker counts only the top level. A full count has to follow every include, so treat the number as a lower bound.
• redirect= means no all at the top level. Gmail's record is v=spf1 redirect=_spf.google.com, so all: null above is correct, and the policy lives in the redirected record.
• Multiple DMARC records at one name are all discarded (RFC 9989 §4.10), the same as having none.

Results on real domains

node mailcheck.mjs example.com gmail.com paypal.com neverssl.com mail.google.com no-such-domain-zz91.com

Output (Oct 24, 2026):

{"domain":"example.com","exists":true,"dnssec":true,"acceptsMail":false,"nullMx":true,"mx":["."],"spf":{"present":true,"all":"-all","lookups":0},"dmarc":{"policy":"reject","from":"example.com","testing":false}}
{"domain":"gmail.com","exists":true,"dnssec":false,"acceptsMail":true,"nullMx":false,"mx":["gmail-smtp-in.l.google.com.","alt1.gmail-smtp-in.l.google.com."],"spf":{"present":true,"all":null,"lookups":1},"dmarc":{"policy":"none","from":"gmail.com","testing":false}}
{"domain":"paypal.com","exists":true,"dnssec":true,"acceptsMail":true,"nullMx":false,"mx":["mx1.paypalcorp.com.","mx2.paypalcorp.com."],"spf":{"present":true,"all":"~all","lookups":7},"dmarc":{"policy":"reject","from":"paypal.com","testing":false}}
{"domain":"neverssl.com","exists":true,"dnssec":false,"acceptsMail":true,"nullMx":false,"mx":[],"spf":{"present":false,"error":null},"dmarc":{"policy":null,"from":null}}
{"domain":"mail.google.com","exists":true,"dnssec":false,"acceptsMail":true,"nullMx":false,"mx":[],"spf":{"present":false,"error":null},"dmarc":{"policy":"reject","from":"google.com","testing":false}}
{"domain":"no-such-domain-zz91.com","exists":false}

What each one teaches:

• example.com exists, but publishes a null MX, v=spf1 -all and p=reject. It neither receives nor legitimately sends mail, which is the correct setup for a parked or web-only domain. Any mail "from" it is forged.
• gmail.com publishes p=none; sp=quarantine. The bare domain is in monitoring mode, so receivers get no domain instruction to refuse a forged @gmail.com From header. In practice big receivers apply their own filtering on top, but the published policy is none.
• paypal.com is at p=reject with DNSSEC, the setup you'd expect from a heavily phished brand. Its SPF already uses 7 lookups at the top level.
• neverssl.com has no MX, so mail falls back to its A record (implicit MX). acceptsMail: true only means a sender would try to deliver there. Whether anything listens on port 25 is a different question. It has no SPF and no DMARC.
• mail.google.com has no DMARC record of its own. The walk finds _dmarc.google.com (p=reject, no sp=), so the subdomain inherits reject.
• no-such-domain-zz91.com is NXDOMAIN, so stop there.

Turning facts into decisions

An agent doesn't need a score. It needs answers to the two questions from the top:

// decide.mjs: turn the DNS facts into the two questions an agent actually asks.
import { mailcheck } from './mailcheck.mjs';

export function decide(r) {
  if (!r.exists) return { canEmail: false, fromHeaderTrust: 'none', why: 'NXDOMAIN' };
  const p = r.dmarc.policy;
  // t=y asks receivers to apply one level lower: reject -> quarantine, quarantine -> none.
  const enforced = p === 'reject' || (p === 'quarantine' && !r.dmarc.testing);
  return {
    canEmail: r.acceptsMail,                     // will a message to this domain be accepted at all?
    fromHeaderTrust: enforced ? 'medium' : 'low', // will receivers refuse forged mail "from" it?
    why: `${r.nullMx ? 'null MX, ' : ''}DMARC ${p ?? 'missing'}${r.dmarc.from && r.dmarc.from !== r.domain ? ` (from ${r.dmarc.from})` : ''}`,
  };
}

for (const d of process.argv.slice(2)) console.log(d.padEnd(24), JSON.stringify(decide(await mailcheck(d))));

example.com              {"canEmail":false,"fromHeaderTrust":"medium","why":"null MX, DMARC reject"}
gmail.com                {"canEmail":true,"fromHeaderTrust":"low","why":"DMARC none"}
paypal.com               {"canEmail":true,"fromHeaderTrust":"medium","why":"DMARC reject"}
neverssl.com             {"canEmail":true,"fromHeaderTrust":"low","why":"DMARC missing"}
mail.google.com          {"canEmail":true,"fromHeaderTrust":"medium","why":"DMARC reject (from google.com)"}
no-such-domain-zz91.com  {"canEmail":false,"fromHeaderTrust":"none","why":"NXDOMAIN"}

fromHeaderTrust tops out at medium on purpose. A reject policy tells you what receivers are asked to do. It doesn't tell you that the message in front of your agent passed.

What DNS can't tell you

• Whether this specific message is authentic. That's decided per message, when your receiving server evaluates SPF, DKIM and DMARC. It records the result in the Authentication-Results header (RFC 8601). An agent that reads email should use that header, which your own server added, and ignore any Authentication-Results the sender could have injected upstream.
• Whether a mailbox exists. An MX record says the domain accepts mail, not that jane@ does. Probing with SMTP RCPT TO is unreliable (catch-all servers, greylisting) and can get your IP blocklisted.
• Who owns the domain or how old it is. Registration data comes from RDAP, the registries' JSON successor to WHOIS, not from DNS. A domain registered last week with perfect SPF and DMARC is a common phishing setup, because these records cost nothing to publish.
• Whether it's a throwaway provider. Disposable-email domains usually have valid MX records. Catching them takes a maintained list.
• Lookalikes. paypa1.com can have flawless records. Compare against the domains you expect, not just "is it configured".

Practical defaults for an agent

• Before storing or emailing an address: reject NXDOMAIN, null MX, and no MX with no A/AAAA. Everything else passes this check (other checks may still apply).
• Before acting on an email's instructions, especially payments, credential changes or data exports, require a pass in your own Authentication-Results header. Even with a pass, confirm money-moving requests through a channel you already trust. DMARC proves the domain, not the intent.
• Treat p=none, a missing DMARC record or t=y as "the From header can be forged", and raise the bar.
• Cache results for the record's TTL. DoH answers include it, and repeated lookups on every message waste time.
• Fail closed on transient DNS errors (DoH Status: 2, SERVFAIL) for high-stakes actions, and fail open for low-stakes ones. RFC 9989 leaves this choice to the receiver for the same reason.

References

• RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC): https://www.rfc-editor.org/rfc/rfc9989
• RFC 7208, Sender Policy Framework (SPF): https://www.rfc-editor.org/rfc/rfc7208
• RFC 7505, A "Null MX" No Service Resource Record: https://www.rfc-editor.org/rfc/rfc7505
• RFC 5321, Simple Mail Transfer Protocol, §5.1 (implicit MX): https://www.rfc-editor.org/rfc/rfc5321
• RFC 8601, Message Header Field for Indicating Message Authentication Status: https://www.rfc-editor.org/rfc/rfc8601
• Cloudflare DNS-over-HTTPS JSON API: https://developers.cloudflare.com/1.1.1.1/encryption/dns-over-https/make-api-requests/dns-json/