Automated Cold Email Deliverability Setup Checklist

An automated cold email program requires four verified DNS records (MX, SPF, DKIM, and DMARC), a dedicated sending domain, a two-to-four-week mailbox warmup, and active reputation monitoring before message one sends. Skip any one and messages either fail authentication at the receiving server, burn through reputation before building any, or keep running until a bounce spike takes the sending domain offline. This checklist separates what you can verify directly in DNS and your monitoring dashboards from what you can only infer from proxy signals. Every threshold here comes from protocol specifications and primary vendor documentation.

What Must Be Configured Before the First Automated Cold Email

A dedicated sending domain, separate from your primary company domain, is the first configuration requirement. This is operational guidance from vendor documentation broadly, not a protocol requirement from any RFC. The isolation logic is straightforward: if the sending domain’s reputation degrades from complaints or bounces, it does not pull down the root domain that runs your corporate email and website. A subdomain such as mail.yourcompany.com works technically, but a fully separate second-level domain creates a cleaner fault boundary and makes recovery simpler if the domain needs to be retired.

Four DNS records must resolve correctly before any outreach starts. First, an MX record routes replies to a real mailbox. Second, an SPF TXT record authorizes your email service provider’s sending infrastructure. Third, a DKIM public key is published at the selector subdomain your ESP specifies. Fourth, a DMARC TXT record at _dmarc.yourdomain.com with at minimum p=none and a reporting address. Confirm all four are resolving with the dig command before logging in to your sending platform.

dig TXT yourdomain.com                         # SPF record
dig TXT selector._domainkey.yourdomain.com     # DKIM public key
dig TXT _dmarc.yourdomain.com                  # DMARC policy

Each sending mailbox also needs a profile photo, a realistic display name, and a working email signature before warmup begins. Receiving filters start building a reputation model from a new account’s first few days of activity. A mailbox with no avatar and an empty signature on day one signals bulk automation to those filters before you’ve sent a single automated message. Set these up first.

Authentication Checklist: SPF, DKIM, and DMARC for Automated Cold Email

SPF (Sender Policy Framework), defined in RFC 7208, authorizes which IP addresses may send mail on behalf of a domain. Its hard evaluation limit of ten DNS lookups per SPF check is the most common silent failure point. Every include mechanism in your SPF record that points to another domain costs one or more of those lookups. Chains of nested includes across multiple ESPs can silently push the evaluation past the limit, causing the check to return a permanent error (permerror) rather than a pass or fail. The receiving server treats permerror as an authentication failure.

DKIM (DomainKeys Identified Mail), defined in RFC 6376, adds a cryptographic signature to outgoing messages that the receiving server verifies against your published public key. A valid DKIM signature confirms the message was not modified in transit. Use a 2048-bit key. The 1024-bit key size is widely considered too weak and is rejected by some receiving configurations.

DMARC, defined in RFC 7489, requires alignment between the From domain in the message header and either the SPF-authenticated domain or the DKIM-signed domain. Passing SPF alone does not satisfy DMARC when the envelope sender domain does not match the From header domain. For automated cold email, configure DKIM signing on the sending domain and ensure the From address matches the DKIM d= tag. That combination satisfies DMARC alignment without depending on envelope domain matching.

Note: Google’s SPF, DKIM, and DMARC setup guide for Workspace-hosted domains covers the implementation steps in detail and is kept current by their team.

Mailbox, Domain, and Tracking Setup

Three to five mailboxes per sending domain is common operational practice. That range distributes daily volume across accounts, keeps each mailbox’s daily send count below the levels that flag bulk automation, and means a single mailbox suspension does not halt all outreach from the domain. Each mailbox should ideally have its own DKIM selector if your ESP supports per-mailbox key generation, though per-domain signing is acceptable when per-mailbox is not available.

Custom tracking domains for open and click tracking should live on a subdomain separate from both your primary domain and your sending domain. Shared ESP tracking subdomains (tracker.yourESP.com) aggregate reputation across every sender on the platform. One bad actor on the same ESP can drag that subdomain’s reputation down, affecting your deliverability even when your own sending practices are clean. A custom subdomain isolates your tracking reputation completely.

Open tracking measures an HTTP request to load a single tracking pixel and infers a read without confirming one. Images are disabled by default in most B2B email clients, so open rate undercounts are structural rather than random. An automated cold email sequence that uses an open event to trigger step two will miss every recipient who reads the message but never loads images. Plan your sequence logic around replies and clicks, not opens, when the data source permits.

Warmup and Ramp Plan for Automated Cold Email Sends

A new mailbox needs at least two to four weeks of warmup at low volume before it can carry cold email volume. Receiving servers and spam filters use behavioral signals from the first days and weeks of activity to build a reputation model. Sending high volume from day one bypasses that history-building period entirely, and most filtering systems treat that pattern as a spam signal. Warmup isn’t a protocol requirement from any RFC. It’s an operational response to how commercial reputation systems actually work.

A practical ramp starts at 10 to 20 messages on day one, increases by 10 to 20 messages per day, and targets a steady-state ceiling of 30 to 50 messages per mailbox per day for most automated cold email programs. Those numbers are vendor and community guidance, not values derived from any email protocol specification. Lower volume with strong positive engagement signals (replies, no complaints, no unsubscribes) builds domain reputation faster than high volume with weak engagement.

During warmup, send to contacts most likely to reply or at minimum unlikely to mark the message as spam. Seeding the warmup window with contacts who will not engage at all introduces negative signals during the highest-risk period. Warmup tools that simulate engagement by sending to seed mailboxes and marking messages as not-spam are measuring their own seed network, not your actual recipient list behavior. The signal they generate can influence reputation scoring tools. It doesn’t tell you how your real prospects will respond. Treat seed-test results as an inferred warmup proxy, not a measured deliverability outcome.

Monitoring, Stop Rules, and Reputation Signals

Set operational stop rules before your first send, not after something breaks. For automated cold email, pause the campaign when the hard bounce rate on a single day’s sends exceeds 5%, when the spam complaint rate exceeds 0.1% (one complaint per 1,000 messages), or when Google Postmaster Tools shows domain reputation dropping to Low. The 0.1% complaint threshold aligns with publicly documented Google guidance on the point at which reputation impact becomes significant for sending domains.

Google Postmaster Tools is a free dashboard showing measured domain reputation, spam rate, authentication results, and delivery errors for Gmail traffic. It reports what Google actually observes at the inbox level for your domain, making it one of the few sources where you see a measured signal rather than an inferred one. The limitation is coverage: Postmaster Tools covers Gmail and Google Workspace only and tells you nothing about your standing with Microsoft 365, Yahoo, or any other mailbox provider.

Microsoft doesn’t publish a postmaster-style reputation dashboard equivalent to Google’s. Reputation for Outlook and Microsoft 365 destinations is inferred from bounce codes, complaint signals routed through the Junk Mail Reporting Program, and third-party reputation monitors, none of which give you the same direct window that Postmaster Tools provides for Gmail. Microsoft’s equivalent guidance lives in its email authentication documentation for Defender for Office 365.

Common Failure Modes and How to Diagnose Them

The most common cause of DMARC failures on a new automated cold email setup is a mismatch between the From header domain and the domain the ESP uses for envelope sending. Some ESPs default to sending with their own platform domain in the envelope unless you explicitly configure your domain there. Confirm your ESP sends the envelope from your sending domain and that DKIM is configured for that same domain. Check the DMARC aggregate reports delivered to your rua address to see exact alignment failure counts before scaling any volume.

SPF failures after an ESP migration almost always trace back to the 10-lookup limit in RFC 7208. Adding a new ESP’s include mechanism to an SPF record that already chains several others can silently push the lookup count over the limit. The receiving server returns permerror and the message fails SPF authentication with no obvious warning in your sending platform’s dashboard. Run an SPF lookup count audit after every ESP change, every record edit, and every new include addition.

High hard bounce rates on a new sending domain usually come from list quality, not from authentication or configuration. A list that hasn’t been validated recently will surface invalid addresses the moment volume starts. Hard bounces above 5% in the first days of a campaign strongly indicate the list source is the primary problem. Send a small initial batch of 200 to 500 messages against a freshly validated list segment. If bounce rates stay below 2% on that batch, the domain configuration is sound and the broader list needs cleaning before expansion.

Inbox placement claims from warming tools and some ESPs are almost never directly measured. Seed-list testing drops a message to a known set of mailboxes and checks where it lands, measuring inbox placement for that specific seed network under those specific conditions, not for your actual recipient list. A sender can produce a 95% seed-test inbox placement figure while accumulating spam complaints from real recipients whose mailbox providers are absent from the seed network. Treat seed-test results as an inferred proxy, not a verified deliverability measurement.

Every automated cold email program that succeeds at scale shares the same foundation: correct DNS records, a warmed mailbox, and monitoring in place before volume starts. None of that is proprietary insight or a vendor differentiator. It’s documented behavior from the protocols that govern how email moves between servers. The checklist above is a starting point for your DNS audit, not a substitute for reading the DMARC aggregate reports your rua address collects every day after launch.

When a campaign stalls at the deliverability layer, the diagnosis almost always comes back to one of three things: an authentication misconfiguration visible in DMARC aggregate reports, a list quality problem visible in hard bounce rates, or a reputation problem visible in Google Postmaster Tools. Each of those signals is measurable from sources you can access today without a paid tool. The outcome your specific domain and list will produce from those inputs is not something any dashboard can tell you in advance.

Prices, limits and product capabilities were checked on 2026-08-13 and change without notice. Nothing here is a prediction of results for your list, domain or market.