A sending-domain checklist for agency clients

Start with the three records receivers read. SPF is a single TXT record that begins with v=spf1; a domain may not publish more than one, and a receiver that finds two returns a permanent error. SPF evaluation also stops with a permanent error once a record needs more than 10 DNS-querying terms such as include and mx ¹.

DKIM public keys live in a TXT record at selector._domainkey.domain, where the selector and domain come from the s= and d= tags of the signature header ². DMARC is a TXT record at _dmarc.domain whose p tag asks receivers to do nothing, quarantine or reject mail that fails, and a message passes when SPF or DKIM passes with an aligned domain ³.

Google says senders of 5,000 or more messages a day to personal Gmail accounts need SPF, DKIM and DMARC, and that all senders need valid forward and reverse DNS for the sending IP and should use TLS ⁴. Yahoo asks bulk senders for SPF and DKIM and a DMARC policy of at least p=none ⁵. Both publish a spam complaint ceiling of 0.3 percent ⁴⁵.

A domain that sends mail should not publish a null MX, which RFC 7505 defines as a single MX record with preference 0 and the root label, meaning the domain accepts no mail ⁶. Replies and bounces need somewhere to land.

Registration data is published by the registry over RDAP, which records events such as registration, last change and expiration with dates ⁷. The domain-age product reads those events and returns created_at, age_days, expires_at and the registrar. Record the age, then decide with your own policy how much warm-up volume a young domain gets.

The email-domain-check product reports what public DNS says: MX hosts, the SPF record and its all policy, the DMARC policy and report addresses, and issues such as multiple_spf_records. It never opens a connection to the mail server, and it does not look up DKIM, because the selector is not discoverable from the domain alone.

Run each address on the client list through email-domain-check. It flags disposable domains, free providers, role mailboxes such as info@, and domains with no mail host, and returns a deliverability_signal of good, risky or undeliverable with reasons. It cannot say that a mailbox exists, so expect some bounces from addresses that pass.

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"}'

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

For example.com, a captured response shows null_mx: true, one SPF record of v=spf1 -all and a DMARC policy of reject, so the signal is undeliverable: exactly the profile of a domain that must never be used to send. Read the fields the same way for your client, then work down the table.

1. Run both lookups on the client domain and fix every issue listed.
2. Publish DKIM from your sending platform and send a test message to confirm it signs.
3. Screen the list, then start at low volume and watch complaint rate against the 0.3 percent ceiling.

To run these checks from the command line or an agent, start with the quickstart, or try the email domain checker on a single domain first.