The agency email checklist: making client domains deliverable

· 5 min read

With every new client domain and every hosting change the same question comes up: is mail for this domain set up cleanly? This checklist gathers every area you need to verify, in the order you work through them. It is deliberately compact; the details of each topic are covered in the linked articles and tools.

1. Inventory of all sending systems

The most common mistake is not a wrong record but a forgotten sender. Before you change anything in DNS you need a list of every system that sends mail in the domain's name. Ask the client, then ask again, because accounting, sales and the shop agency often set up their own tools.

  • Mail provider for the mailboxes: Microsoft 365, Google Workspace, a hosting mailbox
  • Shop system and ERP: order confirmations, invoices, shipping notifications
  • CRM and ticket system: HubSpot, Salesforce, Zendesk and similar
  • Newsletter tool: Mailchimp, Brevo, CleverReach, rapidmail
  • Website contact forms, often sent straight from the web server via PHP mail()
  • Transactional services: SendGrid, Postmark, Amazon SES, Mailgun
  • Printers, scanners, monitoring systems and backup software that send reports

2. MX records and leftovers

The MX records must point exclusively to the hosts of the current mail provider, with the priorities the provider specifies. After a migration an old MX with lower priority often remains; the former host then accepts or rejects mail depending on whether the account still exists. Orphaned autodiscover or webmail entries need cleaning up as well.

Use the MX checker to verify that every host resolves, answers on port 25, offers STARTTLS and presents a valid certificate for its hostname.

example.com.   IN MX 10 mail.example.com.
example.com.   IN MX 20 mail2.example.com.

After the move to Microsoft 365 only this may remain:

example.com.   IN MX  0 example-com.mail.protection.outlook.com.

3. SPF: one record, under ten lookups, -all

Exactly one TXT record with v=spf1 covering every sender from the inventory. Count the DNS lookups: more than ten produce a permerror, which is worse than no SPF. Services with fixed IP addresses go in as ip4 or ip6, bulk senders such as the newsletter tool get their own subdomain with its own SPF. The record ends with -all; ~all is only meant for the transition phase.

  1. Check all existing TXT records and merge duplicate SPF records.
  2. Add the matching include or IP for every sender from the inventory.
  3. Count the lookups and verify with the SPF checker, remove orphaned includes.
  4. Publish with ~all, watch DMARC reports for two weeks, then switch to -all.

4. DKIM for every sending system

Every system from the inventory signs its mail with its own DKIM key under its own selector, because only DKIM survives forwarding and for newsletters and transactional services it is often the only check that works for DMARC. Use 2048-bit keys; 1024 bits are considered too weak and some receivers downgrade them. Add the provider's CNAME or TXT records and then activate signing in the provider panel, because many services only sign after a manual confirmation.

Make sure the DKIM domain (d=) matches the sender domain or is a subdomain of it, otherwise there is no DMARC alignment. Note every selector in the client inventory so they do not get lost at the next DNS migration.

5. DMARC: start at p=none, ramp up to reject

DMARC ties SPF and DKIM to the visible sender address and, via the rua address, gives you reports about every message sent in the domain's name. Always start with p=none and a reporting address so you see which senders are not yet authenticated. After two to four weeks of clean reports move to p=quarantine, then to p=reject, ideally starting with pct=25 and increasing step by step.

Do not forget subdomains: without sp=, the main domain's policy also applies to subdomains, which is usually intended. For unused subdomains that is exactly right. If the client uses subdomains for newsletters or shops, those need their own SPF and DKIM records, otherwise they end up in quarantine. BIMI with a logo in the inbox is an optional later step that requires p=quarantine or p=reject and, for most receivers, a Verified Mark Certificate.

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Target after the rollout:

_dmarc.example.com.  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; sp=reject"

6. Transport, servers and certificates

For domains at providers that support MTA-STS, set up TLS-RPT and then MTA-STS in testing mode, and switch to enforce after evaluating the reports. That protects inbound mail against downgrade attacks. If the client runs their own mail server, add the PTR record and forward-confirmed reverse DNS: the IP must point to the hostname and the hostname back to the IP, and the HELO name must match.

The certificates of all mail hosts belong in the same monitoring as those of the websites. An expired certificate on the MX is a cosmetic flaw with classic STARTTLS, but a delivery stop with MTA-STS in enforce mode.

7. Google and Yahoo sender requirements

Since February 2024 Google and Yahoo enforce mandatory requirements for all senders, with stricter rules for bulk senders from roughly 5,000 messages per day to the respective provider. For agency clients with a newsletter or shop they are the practical yardstick, because the points touch every area of this checklist.

  • SPF and DKIM for the sending domain, both for bulk senders
  • A DMARC record, at least p=none, with alignment of the From domain
  • Valid PTR record for all sending IPs
  • TLS for delivery
  • One-click unsubscribe via List-Unsubscribe header (RFC 8058) for marketing mail, processed within two days
  • Spam rate in Google Postmaster Tools below 0.3 percent, ideally below 0.1 percent

8. Document, re-check, monitor

Create one document per client: sender inventory, all records with dates, selectors, reporting addresses and the person at the client who knows about new tools. After every hosting change, provider change and website migration, run the checklist again, because a DNS move reliably loses exactly the records nobody expected in the zone: the CRM's DKIM selector, the TLS-RPT record, the SPF of the newsletter subdomain.

Between those events records still change: providers change their includes, clients add tools, staff delete entries they do not recognise. That is why every client domain belongs in automatic monitoring that checks SPF, DKIM, DMARC, MX and certificates regularly and reports every change, not just the outage.

Frequently asked questions

In which order do I implement this?
Inventory, MX, SPF, DKIM, DMARC at p=none, then read reports. Only when every sender passes, tighten DMARC, and after that tackle MTA-STS and BIMI. Setting DMARC to reject before the inventory loses mail.
How long does the complete setup for a client domain take?
The records are in place within one to two hours. The DMARC rollout to p=reject realistically takes four to eight weeks because of the observation phase. Plan for that in the quote.
Do I have to repeat this for every subdomain?
For every subdomain that sends mail, yes: its own SPF, its own DKIM selectors. Subdomains without mail are covered by the main domain's DMARC policy with sp=reject, and an SPF of v=spf1 -all prevents abuse.
Check now

Free DMARC record check and lookup: policy (none, quarantine, reject), pct, reporting addresses and syntax errors. With recommendations for moving to p=reject.

DomainWarn monitors SPF, DKIM, DMARC, MX, MTA-STS and certificates of all client domains and reports every change, so the checklist holds not only at onboarding but permanently.

Monitor this domain continuously14-day free trial, no credit card.

More guides