How to Set Up SPF, DKIM, and DMARC for Cold Email Outreach (Step-by-Step)

Getting your DNS records wrong is the fastest way to kill your cold email deliverability before you send a single message. SPF, DKIM, and DMARC are not optional extras — they are the foundational authentication layer that tells Gmail, Outlook, and every other major email provider that your emails are legitimate. Without these records configured correctly, your carefully written cold emails will land in spam folders, bounce entirely, or never reach a human inbox at all.

The stakes are real. Google and Yahoo both enforce strict sender authentication requirements. Any domain sending more than 5,000 emails per day must have all three records in place and passing. But even at lower volumes — the 30 to 50 emails per day typical of most cold outreach campaigns — missing or misconfigured authentication records will tank your inbox placement rate from day one. You will burn through domains, waste weeks of warm-up time, and wonder why your reply rates hover near zero.

This guide walks through exactly how to configure each record, step by step, using Google Workspace as the primary example. The same principles apply to Microsoft 365 and other providers — the specific record values differ, but the logic is identical. By the end, you will have a fully authenticated sending domain ready for cold outreach. For the next step after DNS setup, see our guide to building a lead list for free and our cold email copywriting templates.

What Each Record Does and Why It Matters

Before setting up the records, it helps to understand what each one actually does. These aren't interchangeable — each solves a different part of the email authentication problem. Think of them as three layers of verification that work together. SPF validates the sending server, DKIM validates the message integrity, and DMARC ties them both to your domain with enforcement rules.

Receiving mail servers check all three in sequence. If any layer fails or is missing, the receiving server assigns a lower trust score to your message. With enough negative signals, the message goes to spam — or gets rejected outright. Understanding what each layer does will help you debug issues faster when something breaks.

SPF (Sender Policy Framework)

SPF is a DNS TXT record that lists which mail servers are authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from you@yourdomain.com, it looks up your domain's SPF record to verify the sending server's IP address is on the approved list.

Without SPF, anyone can send email "from" your domain. With SPF, unauthorized senders fail the check and their emails are marked suspicious or rejected. This matters for cold email because your domain is new and has no established reputation. SPF is the first trust signal that tells receiving servers you are who you claim to be.

Here is how SPF evaluation works in practice. The receiving server extracts the Return-Path domain from the email envelope (not the visible From header — that is DMARC's job). It then performs a DNS lookup on that domain for TXT records containing an SPF policy. The policy lists authorized senders using include: mechanisms, IP addresses, or IP ranges. The server checks whether the connecting IP matches any of these. If it does, SPF passes. If not, the result depends on your qualifier — ~all gives a softfail (suspicious but not rejected), while -all gives a hardfail (rejected).

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to every email you send. The sending server signs each message with a private key, and publishes the corresponding public key in a DNS TXT record. Receiving servers use the public key to verify the signature — confirming the email wasn't modified in transit and genuinely came from your domain.

DKIM protects against email tampering and strengthens your domain's identity. It's a direct signal that boosts inbox placement rates. Unlike SPF, which only validates the sending server, DKIM validates the message itself. This means that even if your email passes through forwarding servers or mailing lists that change the envelope sender (which would break SPF), DKIM can still pass because the signature is embedded in the message headers.

The technical flow: your mail server generates a hash of certain email headers and the body content, encrypts that hash with your private key, and attaches the encrypted hash as a DKIM-Signature header. The receiving server reads the selector and domain from this header, looks up the public key via DNS, decrypts the hash, and compares it to its own hash of the message. If they match, DKIM passes. If the message was altered in any way — even a single character — the hashes will not match and DKIM fails.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC builds on SPF and DKIM by telling receiving servers what to do when authentication fails. It also adds an alignment requirement — the "From" domain must match the domain in the SPF or DKIM record. This prevents attackers from passing SPF with their own domain while spoofing yours in the visible From header.

DMARC has three policy levels: p=none (monitor only), p=quarantine (send to spam), andp=reject (block entirely). For cold email, start with p=none. The critical point is that having a DMARC record present at all — even at the monitoring level — is a positive signal. Many receiving servers treat domains without DMARC records as inherently less trustworthy.

DMARC also provides a reporting mechanism. When you include rua and ruf tags in your DMARC record, receiving servers send you aggregate and forensic reports about authentication results. These reports tell you how many messages passed or failed SPF and DKIM, which IP addresses are sending on your behalf, and whether any unauthorized sources are spoofing your domain. For cold email operators, these reports are valuable for diagnosing deliverability problems — if you see a spike in DKIM failures, you know something changed in your sending configuration.

Step 1: Set Up SPF for Google Workspace

Log into your domain registrar (GoDaddy, Namecheap, Cloudflare, etc.) and navigate to DNS settings. Before adding anything, check whether an SPF record already exists. Look for a TXT record that starts with v=spf1. If one exists, you will need to modify it rather than creating a new one — having two SPF records is invalid and will cause both to fail.

Add a new TXT record with these values:

• Type: TXT
• Name/Host: @ (or leave blank — this means the root domain)
• Value: v=spf1 include:_spf.google.com ~all
• TTL: 3600 (1 hour) or your registrar's default

If you're using Microsoft 365 instead of Google Workspace, the value is:

• v=spf1 include:spf.protection.outlook.com ~all

Important SPF rules:

• You can only have one SPF record per domain. If you have multiple sending services (e.g., Google + Mailgun), combine them in one record: v=spf1 include:_spf.google.com include:mailgun.org ~all
• SPF has a 10 DNS lookup limit. Each include: statement counts as one lookup. Exceeding 10 breaks SPF.
• Use ~all (softfail) rather than -all (hardfail) for cold email. Hardfail can cause legitimate mail to be rejected if your setup has any gaps.

A practical note on the 10-lookup limit: each include: can itself trigger additional lookups. For example, _spf.google.com internally includes multiple sub-records, which collectively use about 4 of your 10 lookups. If you are also including Mailgun, SendGrid, and your ESP, you can hit the limit quickly. Use a tool like EasySPF or MXToolbox's SPF lookup to count your total lookups after configuring. If you exceed 10, consider using an SPF flattening service that resolves includes into static IP addresses.

For cold email specifically, your SPF record will typically include your email provider (Google Workspace or Microsoft 365) and possibly your cold email tool if it sends via its own SMTP servers. Most modern cold email tools like Instantly and Smartlead connect to your email account directly via SMTP and send as your account, so they do not require a separate SPF include — the email originates from Google's servers, which are already covered. Check your ESP's documentation to confirm whether an additional SPF include is needed.

Step 2: Set Up DKIM for Google Workspace

DKIM setup in Google Workspace requires generating a key in the Admin Console and then publishing the public key in DNS. This is a two-part process, and the most common mistake is completing only the first part.

In Google Admin Console:

• Go to Apps > Google Workspace > Gmail
• Click "Authenticate email"
• Select your domain from the dropdown
• Click "Generate new record"
• Choose DKIM key length: select 2048-bit (more secure than 1024-bit)
• The selector prefix defaults to google — leave this as-is
• Copy the generated TXT record value

In your DNS settings:

• Type: TXT
• Name/Host: google._domainkey
• Value: The long string Google generated (starts with v=DKIM1; k=rsa; p=...)
• TTL: 3600

A common registrar quirk: some registrars (like Namecheap) automatically append your domain to the hostname. If your domain is yourdomain.com and you enter google._domainkey.yourdomain.com in the Name field, it may create the record at google._domainkey.yourdomain.com.yourdomain.com, which is wrong. In these cases, enter only google._domainkey without the domain suffix. If unsure, check your registrar's documentation or use MXToolbox to verify the record resolves at the correct location after saving.

Another potential issue: some registrars have a character limit on TXT record values. A 2048-bit DKIM key produces a long string, and if your registrar truncates it, the key will be invalid. If you run into this, try wrapping the value in quotes or splitting it into two strings within the same record (some registrars support this). Cloudflare and most modern registrars handle long values without issue.

After publishing the DNS record (allow 15–60 minutes for propagation), return to Google Admin Console and click "Start authentication." Google will verify the record and activate DKIM signing. This step is critical — until you click this button, Google will not sign your outgoing emails with DKIM even if the DNS record is perfectly configured. This is the single most common DKIM setup failure.

For Microsoft 365: Navigate to Security > Email & collaboration > Policies & rules > Threat policies > DKIM. Select your domain and enable signing. Microsoft generates the CNAME records for you to publish in DNS. Microsoft uses two CNAME records (selector1 and selector2) rather than a single TXT record. Publish both, then toggle DKIM signing to "Enabled" in the Microsoft 365 admin portal.

Step 3: Set Up DMARC

DMARC requires both SPF and DKIM to be working correctly first — DMARC alignment checks depend on both passing. Don't set up DMARC until you've verified SPF and DKIM are functioning. If you publish a DMARC record while SPF or DKIM is misconfigured, the DMARC reports will show failures, and if you later tighten the policy to quarantine or reject, your own legitimate emails could be affected.

To verify SPF and DKIM are working before proceeding: send a test email from your domain to a Gmail account. Open the received email, click the three dots menu, and select "Show original." Look for the authentication results header. You should see spf=pass and dkim=pass. If either shows fail or neutral, go back and fix it before continuing with DMARC.

Starter DMARC record (monitoring only):

• Type: TXT
• Name/Host: _dmarc
• Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1
• TTL: 3600

Replace dmarc@yourdomain.com with an actual email address you monitor — you'll receive aggregate reports (rua) and failure reports (ruf) to this address. The fo=1 tag tells receiving servers to generate a forensic report whenever any authentication check fails, giving you maximum visibility into problems.

A practical tip: DMARC aggregate reports arrive as XML files attached to emails. They are not human-readable out of the box. For a single cold email domain, you can use a free DMARC report analyzer like DMARCian, Postmark's DMARC tool, or MXToolbox's DMARC report parser to visualize the data. These tools parse the XML and show you pass/fail rates, sending source IPs, and alignment results in a readable dashboard. If you manage 10 or more domains, consider using a dedicated email address per domain (like dmarc-reports@yourdomain.com) and a centralized DMARC monitoring tool to keep things organized.

DMARC policy progression:

• Start: p=none — monitor and collect reports, no action on failures
• After 30 days with clean reports: p=quarantine — failed auth goes to spam
• After 60 days with clean reports: p=reject — failed auth is blocked entirely

For cold email, staying at p=none is fine. The primary benefit for deliverability is having a DMARC record present at all — even a monitoring-only policy signals to receiving servers that you care about authentication. Moving to p=quarantine or p=reject provides stronger anti-spoofing protection but adds risk if you later add new sending services without updating SPF and DKIM first. For most cold email operators, the deliverability benefit of p=none versus p=quarantine is negligible. Focus your energy on sending quality and warm-up instead.

Step 4: Set Up Custom Tracking Domain (Critical)

Every cold email tool uses a tracking domain to log opens (tracking pixel) and clicks (link redirection). By default, most tools use their own shared tracking domain — and those shared domains are often on blacklists due to abuse by other users. This single misconfiguration accounts for a large percentage of deliverability failures in otherwise well-configured cold email setups.

Here is why this matters so much. When you include a link in your cold email and the recipient clicks it, their email client first navigates to the tracking domain (e.g., tracking.instantly.ai) before redirecting to the actual URL. Gmail and other providers scan these link domains against known spam and phishing databases. If the shared tracking domain has been flagged — because another user on the same platform sent spam through it — your email inherits that negative signal. You could have perfect SPF, DKIM, and DMARC, pristine email copy, and a fully warmed domain, and still land in spam because of a shared tracking domain.

Set up a custom tracking domain for each sending domain. This is a CNAME record pointing to your ESP's tracking infrastructure:

• Type: CNAME
• Name/Host: track (this creates track.yourdomain.com)
• Value: Your ESP's tracking endpoint (e.g., tracking.instantly.ai for Instantly)

After adding the CNAME, go to your ESP settings and set track.yourdomain.com as your custom tracking domain. All open and click tracking will now route through your domain rather than a shared one.

Some additional considerations for tracking domains. First, use a subdomain that looks natural —track, go, or link are common choices. Avoid anything that looks suspicious like redirect or click123. Second, if you manage multiple sending domains, each one needs its own custom tracking domain. Do not share a tracking domain across sending domains — the whole point is reputation isolation. Third, make sure your tracking subdomain also has an SSL certificate. Most ESPs handle this automatically when you configure the custom domain, but verify by visiting https://track.yourdomain.com in a browser and confirming it loads without certificate errors. Gmail penalizes emails containing links to non-HTTPS destinations.

Step 5: Verify Everything Is Working

After publishing all records and waiting for DNS propagation (typically 15 minutes to a few hours), verify each record is resolving correctly. Do not skip this step. A record that looks correct in your registrar's dashboard may not be resolving properly due to syntax errors, propagation delays, or registrar-specific formatting issues.

Use these tools:

• MXToolbox.com — SPF Lookup, DKIM Lookup (enter your selector: google), DMARC Lookup
• Mail-tester.com — send a test email to the address they provide. Score of 9–10/10 means your authentication is clean.
• Google Postmaster Tools — sign up at postmaster.google.com and verify your domain. Monitor domain reputation and authentication pass rates.

A fully configured domain should show:

• SPF: PASS
• DKIM: PASS (using the google selector)
• DMARC: Record found, policy configured
• Mail-tester score: 9–10/10

Here is a more thorough verification process. Send a test email from your cold email tool (not just from Gmail directly) to a test address. This ensures the email travels through the exact same path your campaign emails will use. Some cold email tools route through their own SMTP servers, which can affect authentication results. If your tool connects directly to your Google Workspace account via OAuth or app passwords, the results should match a direct Gmail send. But if the tool uses its own sending infrastructure, you need to verify that path specifically.

After sending the test email, open it in Gmail, click the three dots, and select "Show original." You will see a full breakdown of authentication results at the top of the raw message. Check three things: the SPF result line (should show pass), the DKIM result line (should show pass with your domain), and the DMARC result line (should show pass). If any of these show fail,neutral, or temperror, the corresponding record needs attention.

Set a calendar reminder to recheck your records 7 days after initial setup. DNS records can be accidentally overwritten if your registrar has auto-configuration features, or if a team member modifies DNS for another purpose. A quick weekly check during the first month of sending catches problems before they damage your domain reputation.

Managing DNS for Multiple Cold Email Domains

Most serious cold email operations use multiple sending domains to distribute volume and protect their primary brand domain. If you are running 3 to 10 sending domains (a common setup for agencies and B2B outreach teams), each domain needs its own complete set of authentication records. There are no shortcuts here — SPF, DKIM, DMARC, and custom tracking domains must be configured individually for every domain.

To keep this manageable, create a spreadsheet or checklist that tracks the setup status of each domain. Include columns for domain name, registrar, SPF status, DKIM status, DMARC status, custom tracking domain, warm-up start date, and current sending volume. When you purchase a new domain, work through the checklist top to bottom before connecting it to your cold email tool. This prevents the common mistake of starting warm-up on a domain that has incomplete authentication — which wastes warm-up time and can actually harm the domain's initial reputation.

If you buy domains from multiple registrars, consider consolidating DNS management under a single provider like Cloudflare. You can keep the domain registered at the original registrar but point the nameservers to Cloudflare. This gives you a single interface for managing all DNS records, faster propagation times (Cloudflare propagates in under 5 minutes in most cases), and a consistent UI that reduces configuration errors.

Common Mistakes to Avoid

These are the most frequent errors when setting up DNS for cold email:

• Multiple SPF records — You can only have one. Merge all include: statements into a single TXT record.
• Forgetting to activate DKIM in Google Admin — Publishing the DNS record alone is not enough. You must click "Start authentication" in the Admin Console.
• Using the wrong host for DKIM — The Name/Host field must be google._domainkey, not just _domainkey.
• Setting DMARC before SPF/DKIM are confirmed working — DMARC can cause legitimate email to fail if SPF or DKIM has errors.
• Skipping the custom tracking domain — Using your ESP's default tracking domain is a significant deliverability risk.

Beyond these five, there are several less obvious mistakes that catch people. Copying DNS record values with trailing spaces or line breaks is a frequent issue — some registrar UIs are not forgiving about whitespace. Always trim the value before pasting. Another mistake is assuming DNS changes take effect immediately. Even though modern providers are fast, always wait at least 15 minutes before testing, and up to 24 hours if using a registrar with longer TTL defaults.

One more subtle issue: if your domain was previously owned by someone else and they left old SPF, DKIM, or MX records in place, those stale records can interfere with your new configuration. When setting up a newly purchased domain, audit all existing DNS records first and remove anything that is not part of your intended configuration. Old MX records pointing to abandoned mail servers, leftover SPF records from previous owners, and orphaned CNAME entries can all cause unexpected authentication failures.

For a complete walkthrough of the full cold email infrastructure — including domain purchasing strategy and warm-up schedules — see our cold email deliverability checklist and our email domain warm-up guide.

Want to learn how to build and sell AI automations? Join our free community. Join the free AI Agency Sprint community.