---
title: "A sending-domain checklist for agency clients"
url: "https://lookvalid.com/blog/industry/cold-email-agency-deliverability-checklist.md"
canonical_url: "https://lookvalid.com/blog/industry/cold-email-agency-deliverability-checklist"
last_updated: "2026-10-22"
type: "conceptual"
summary: "Onboarding a client sending domain? Check SPF, DKIM, DMARC, MX, domain age and list quality against the published rules before the first send."
related: ["https://lookvalid.com/products/email-domain-check.md", "https://lookvalid.com/products/domain-age.md", "https://lookvalid.com/tools/email-domain-checker.md", "https://lookvalid.com/docs/quickstart.md", "https://lookvalid.com/glossary/dmarc.md"]
---

# A sending-domain checklist for agency clients

Onboarding a client sending domain? Check SPF, DKIM, DMARC, MX, domain age and list quality against the published rules before the first send.

An agency that takes over a client sending domain inherits whatever DNS state the domain is in. This checklist turns the published sender rules into checks you can run before the first message goes out, and marks which ones a lookup can answer and which need a test send. The two lookups used here are [email-domain-check](https://lookvalid.com/products/email-domain-check.md) and [domain-age](https://lookvalid.com/products/domain-age.md).

## Authentication records

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` [1].

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 [2]. 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 [3].

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 [4]. Yahoo asks bulk senders for SPF and DKIM and a DMARC policy of at least `p=none` [5]. Both publish a spam complaint ceiling of 0.3 percent [4][5].

## The checklist

Onboarding checks for a client sending domain

| Check | What good looks like | How to test it |
| --- | --- | --- |
| Exactly one SPF record | One `v=spf1` record ending in an `all` term, under 10 lookups | email-domain-check, `spf` object |
| DKIM selector published | TXT record present at the selector your sending platform gives you | Dig the selector yourself; a lookup cannot guess it |
| DMARC published | One `v=DMARC1` record at `_dmarc`, `rua` set for reports | email-domain-check, `dmarc` object |
| Mail host exists | MX records present, no null MX on a domain that sends [6] | email-domain-check, `has_mx` and `null_mx` |
| Reverse DNS and TLS | Valid forward and reverse DNS for the sending IP [4] | Your sending platform and a test send |
| Registration facts recorded | Creation date, registrar and expiry on file | domain-age |
| List screened | Disposable domains, role mailboxes and dead domains removed | email-domain-check per address |

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 [6]. Replies and bounces need somewhere to land.

## Domain age and DNS health

Registration data is published by the registry over RDAP, which records events such as registration, last change and expiration with dates [7]. 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.

## List hygiene and a first run

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.

Check the client domain, then its registration

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

Registration facts for the same domain

```bash
curl -X POST https://YOUR_API_HOST/v1/domain-age \
  -H "Authorization: Bearer $LOOKVALID_API_KEY" \
  -H "Content-Type: application/json" \
  -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](https://lookvalid.com/docs/quickstart.md), or try the [email domain checker](https://lookvalid.com/tools/email-domain-checker.md) on a single domain first.

## Sources

1. [RFC 7208: Sender Policy Framework (SPF)](https://www.rfc-editor.org/rfc/rfc7208), read 2026-10-19
2. [RFC 6376: DomainKeys Identified Mail (DKIM) Signatures](https://www.rfc-editor.org/rfc/rfc6376), read 2026-10-19
3. [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc7489), read 2026-10-19
4. [Google: Email sender guidelines](https://support.google.com/a/answer/81126), read 2026-10-19
5. [Yahoo Sender Hub: sender best practices](https://senders.yahooinc.com/best-practices/), read 2026-10-19
6. [RFC 7505: A "Null MX" No Service Resource Record for Domains That Accept No Mail](https://www.rfc-editor.org/rfc/rfc7505), read 2026-10-19
7. [RFC 9083: JSON Responses for the Registration Data Access Protocol (RDAP)](https://www.rfc-editor.org/rfc/rfc9083), read 2026-10-19

By LookValid engineering. Published 2026-10-19, updated 2026-10-19.

## Related

- [Email Domain Check API](https://lookvalid.com/products/email-domain-check.md)
- [Domain Age API](https://lookvalid.com/products/domain-age.md)
- [Free email domain checker (MX, SPF, DMARC)](https://lookvalid.com/tools/email-domain-checker.md)
- [Quickstart](https://lookvalid.com/docs/quickstart.md)
- [What is DMARC?](https://lookvalid.com/glossary/dmarc.md)