Setting Up DKIM, SPF, and DMARC for Cold Email at Scale

01 / Message signing

Set up DKIM with your actual sender.

Start in the service that sends your email, not just the outreach tool that schedules it. DomainKeys Identified Mail (DKIM) uses a private key to sign messages and a public DNS key to verify them. Keep the private key with the sending provider.

1. Inventory your senders. Include the mailbox provider, CRM and any separate delivery service. Save the existing DNS records before changing them.
2. Generate the provider's DKIM records. Use its domain-authentication settings. Follow its key-length guidance; Google Workspace recommends 2048-bit keys where supported.
3. Publish the exact records. Your provider may give you a TXT public key or CNAME targets. Use the supplied selector, record type and value; these are not interchangeable.
4. Verify, then enable signing. Some providers need a separate activation step. A DNS record alone does not prove that outgoing messages are signed.

outreach1._domainkey.example.com
│                     │
DKIM selector         Signing domain

Public lookup: selector._domainkey.signing-domain

Here, outreach1 is only an example selector. Copy yours from the provider. DNS panels often append the domain automatically: entering a full name in a relative-name field can accidentally create a doubled domain. Check the resulting hostname.

Provider example: Google Workspace DKIM setup.

02 / Sender authorisation

Keep SPF record configuration accurate.

Sender Policy Framework (SPF) checks the sending IP against the envelope sender domain, also called MAIL FROM. This can differ from the visible From address. With a provider-managed return path, ask which domain actually needs your SPF record.

1. Find the existing record. Look for a TXT value beginning v=spf1 at the relevant domain.
2. Combine authorised sources. Maintain one SPF record per hostname. Do not add a second SPF record when connecting another sender.
3. Check DNS lookup costs. SPF limits lookup-causing terms to ten during evaluation, including nested includes. Counting visible includes alone is insufficient.

example.com.  TXT  "v=spf1 ip4:192.0.2.10 -all"

This example authorises one fictional server; -allmarks other senders as failing SPF. It is not a record to copy into production. Hosted mailbox services normally provide their own values. Preserve legitimate sources and confirm the final policy with your provider.

References: Microsoft SPF configuration and SPF lookup limits.

03 / Domain alignment

Make DMARC alignment explicit.

DMARC passes when at least one authentication method passes and aligns with the visible From domain: SPF's MAIL FROM domain or DKIM's d= signing domain. An SPF or DKIM pass for an unrelated provider domain is not enough.

Relaxed alignment, the default, compares organisational domains; strict alignment requires an exact domain match. Confirm your provider supports aligned DKIM or a suitable custom return path.

Observe first, then enforce.

_dmarc.example.com.  TXT
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

For a new rollout, p=none requests no DMARC-specific enforcement while you inspect reports. It does not turn off spam filtering. Use a report mailbox or reporting service you control; external reporting destinations can require DNS authorisation. Do not downgrade an established enforcement policy just to follow this example.

Identify legitimate senders in the reports and repair failures before progressing to p=quarantine or p=reject. Those policies request stricter treatment of failing messages; receivers retain their own handling decisions. Include transactional and support mail in the review, not only outreach.

References: DMARC identifier alignment and Microsoft DMARC rollout guidance.

04 / Evidence before volume

Verify the complete sending path.

Query public DNS after the relevant cache TTLs expire, then send a test through the actual campaign mailbox to inboxes you control. These Windows PowerShell commands only read DNS. Replace the example domain and selector with your own.

Resolve-DnsName -Name example.com -Type TXT
Resolve-DnsName -Name outreach1._domainkey.example.com -Type TXT
Resolve-DnsName -Name outreach1._domainkey.example.com -Type CNAME
Resolve-DnsName -Name _dmarc.example.com -Type TXT

For DKIM, use the TXT or CNAME query that matches your provider's record type; both types need not exist. A DNS answer verifies publication, not successful authentication. Inspect the receiving mailbox's original message headers next.

Authentication-Results: receiver.example.net;
  spf=pass smtp.mailfrom=mail.example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Before scaling, check your mailbox provider's permitted use, recipient eligibility, opt-out handling and applicable requirements. Gmail's rules for senders reaching about 5,000 or more messages daily to personal Gmail accounts include SPF, DKIM and DMARC; marketing and subscribed messages also need one-click unsubscribe. That threshold is not a recommended sending volume.

Increase volume gradually only while delivery evidence supports it. Review bounces, complaints, replies and authentication reports, and pause on deterioration. Recheck after changing a provider, domain or signing key. Warmup and passing authentication do not guarantee inbox placement, replies or sales.

Receiver requirements: Gmail email sender guidelines. Technical guidance reviewed 29 September 2026.