A checklist for SPF, DKIM and DMARC records

SPF lists which hosts may send mail for a domain, DKIM lets a sender sign each message with a key published in DNS, and DMARC tells receivers what to do when neither of those checks lines up with the visible From domain. All three are ordinary TXT records, so you can read them with any DNS tool.

A domain must not publish more than one SPF record. When a receiver finds more than one record that begins with v=spf1, the check returns a permanent error rather than picking one ¹. The usual cause is a second record added by a new mail vendor while the old one is still in place. Merge them into a single record.

The second limit is on DNS lookups. An SPF evaluation may trigger at most 10 terms that cause DNS queries, and exceeding that also returns a permanent error ¹. The terms that count are include, a, mx, ptr and exists, plus the redirect modifier; ip4, ip6 and all do not count ¹. Every vendor you add with an include: spends part of that budget, and a vendor's own record can spend more behind it.

• Count the include, a, mx, exists and redirect terms, including those inside included records.
• End the record with -all or ~all once you are sure every legitimate sender is listed.
• Prefer ip4 and ip6 ranges for hosts you control, since they cost no lookups.

A DKIM key is published as a TXT record under a _domainkey subdomain, named by the selector the signer chose ². The selector appears in the s= tag of the DKIM-Signature header on a real message, and the signing domain appears in d= ². You cannot guess it from the domain alone, so open a sent message and read the header.

In the key record, v= if present must be DKIM1 and come first, k= defaults to rsa, and p= holds the base64 public key. An empty p= means the key has been revoked ². If a selector query returns a record with an empty p=, mail signed with that selector will fail.

1dig +short TXT selector1._domainkey.example.com

The DMARC record is a TXT record at _dmarc under the domain, and its p= tag is required ³. The policy values are none (no requested action), quarantine (treat failing mail as suspicious) and reject (refuse failing mail) ³. If sp= is absent, the p= policy applies to subdomains too, and pct= defaults to 100 ³.

The v=DMARC1 tag must come first in the record ³. As with SPF, publish one record: if a receiver finds several, DMARC processing is not applied to the message ³. Start at p=none with an rua= address so aggregate reports show you every sender before you tighten to quarantine and then reject.

The email-domain-check product reads the MX, SPF and DMARC records for the domain behind an address and reports what it found, including multiple_spf_records and no_dmarc_record issues. Two limits to know: it follows redirect= in SPF but does not expand include: terms or count lookups, and it does not check DKIM, because the selector is not discoverable from DNS. It also never contacts a mail server.

1curl -X POST https://YOUR_API_HOST/v1/email-domain-check \
2  -H "Authorization: Bearer $LOOKVALID_API_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{"domain":"example.com"}'

1{
2  "spf": { "record": "v=spf1 -all", "record_count": 1, "policy": "-all", "valid": true, "issues": [] },
3  "dmarc": { "record": "v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s", "policy": "reject", "valid": true, "issues": [] }
4}

Read the issues arrays first: they name the problem in a form you can branch on. To run the same check across a list of domains, see the quickstart or try the free DMARC checker.

1. Count SPF records: exactly one.
2. Count SPF lookups against the limit of 10.
3. Find a DKIM selector in a sent message header and query it.
4. Publish DMARC at p=none with rua=, then tighten.

The email domain check product page has the full request and response reference.