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

You bought the domains, set up the inboxes, loaded your sequences, and started sending. Then your reply rates dropped off a cliff and half your emails never arrived. Nine times out of ten, the culprit is missing or misconfigured email authentication.

Setting up DKIM, SPF, and DMARC correctly is not optional for cold email. It is the baseline that determines whether your emails get delivered, filtered, or silently dropped. This guide walks through exactly how to configure all three records for every domain you use for cold outreach.

TL;DR

• SPF tells receiving servers which IPs are authorized to send from your domain
• DKIM adds a cryptographic signature to verify emails have not been tampered with
• DMARC ties SPF and DKIM together and tells servers what to do when checks fail
• All three need to be configured correctly on every cold email domain you own
• Missing any one of them increases your chances of hitting spam or being rejected outright

Why Email Authentication Matters for Cold Email

Receiving mail servers are constantly making judgment calls about whether to deliver, filter, or reject incoming email. One of the first things they check is whether the sending domain has authentication records in place.

When you send cold email from a domain with no SPF record, no DKIM signature, and no DMARC policy, you are essentially showing up with no ID. Some servers will still let you through. Most enterprise mail filters will not. And even if the email is technically delivered, the lack of authentication signals pushes your message closer to the spam folder.

For teams running cold email at scale across multiple domains, this is not a theoretical problem. A single misconfigured domain can tank deliverability for an entire campaign batch before you even notice something is wrong.

Prerequisites: What You Need Before You Start

Before configuring authentication records, make sure you have the following in place:

• A domain registered and active (purchased through Google Domains, Namecheap, GoDaddy, or another registrar)
• Access to your domain’s DNS settings (through your registrar or DNS provider)
• An email sending platform connected (Google Workspace, Microsoft 365, or a third-party SMTP service)
• Admin access to your email sending platform to retrieve DKIM keys

If you are setting up Google Workspace specifically for cold email, the Google Workspace Setup guide covers the full provisioning flow before you get to authentication.

Step 1: Set Up Your SPF Record

SPF (Sender Policy Framework) is a DNS TXT record that lists the mail servers authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from your domain, it checks your SPF record to see if the sending IP is on the approved list.

How to create your SPF record

1. Log in to your DNS provider and navigate to the DNS management section for your domain.
2. Create a new TXT record.
3. Set the hostname to @ (which represents your root domain).
4. Add the SPF value based on your sending platform:

For Google Workspace:

v=spf1 include:_spf.google.com ~all

For Microsoft 365:

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

For a third-party SMTP service like SendGrid or Mailgun, use the include value they provide in their setup documentation, and combine it with your primary sending provider if needed.

5. Save the record.

SPF rules to follow

• You can only have one SPF TXT record per domain. If you need to authorize multiple sending sources, combine them in a single record using multiple include: statements.
• The ~all at the end means “soft fail” emails that don’t match. For cold email, this is safer than -all (hard fail) while you are still verifying your setup.
• Once you are confident everything is configured correctly, switching to -all is a valid option.

Step 2: Set Up Your DKIM Record

DKIM (DomainKeys Identified Mail) works differently from SPF. Instead of checking sending IPs, it uses a public/private key pair to cryptographically sign outgoing emails. The receiving server uses the public key in your DNS to verify the signature matches the private key used when the email was sent.

This confirms two things: the email actually came from your domain, and the message was not altered in transit.

How to generate and publish your DKIM key

The process depends on your sending platform.

For Google Workspace:

1. Go to your Google Admin console.
2. Navigate to Apps > Google Workspace > Gmail > Authenticate Email.
3. Select your domain and click “Generate New Record.”
4. Google will show you a DKIM TXT record to add to your DNS. Copy the hostname (usually google._domainkey) and the TXT value.
5. Add a TXT record in your DNS with that hostname and value.
6. Return to Google Admin and click “Start Authentication.”

For Microsoft 365:

1. Go to the Microsoft 365 Defender portal (security.microsoft.com).
2. Navigate to Email & Collaboration > Policies & Rules > Threat Policies > Email Authentication Settings.
3. Select DKIM and find your domain.
4. Microsoft will show you two CNAME records to add to DNS. Add both.
5. Once DNS propagates, return to the portal and toggle DKIM signing to enabled.

For other SMTP providers:

Follow their specific DKIM setup documentation. Most will either provide CNAME records to add or a TXT record with the public key directly.

After publishing the record

DNS changes can take anywhere from a few minutes to 48 hours to propagate. You can verify your DKIM is working using a free tool like MXToolbox or by sending a test email to mail-tester.com and checking the authentication results.

Step 3: Set Up Your DMARC Record

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer that sits on top of SPF and DKIM. It tells receiving mail servers what to do when an email fails authentication checks, and it gives you a mechanism to receive reports about who is sending email using your domain.

Without DMARC, even if your SPF and DKIM are configured, there is nothing instructing receiving servers to reject or quarantine spoofed emails. DMARC closes that gap.

How to create your DMARC record

1. In your DNS settings, create a new TXT record.
2. Set the hostname to _dmarc (not the root domain).
3. Use the following value as your starting point:

v=DMARC1; p=none; rua=mailto:you@yourdomain.com

4. Replace you@yourdomain.com with an email address where you want to receive aggregate reports.

Understanding the DMARC policy values

The p= tag is the policy. There are three options:

• p=none – Monitor mode. Emails that fail DMARC are still delivered, but you receive reports. This is the right starting point.
• p=quarantine – Emails that fail DMARC are sent to the spam folder.
• p=reject – Emails that fail DMARC are rejected outright.

For cold email domains, start with p=none to gather data without accidentally blocking your own sends. Once you have confirmed your authentication is working correctly across all your sending infrastructure, you can move to p=quarantine or p=reject for stronger protection.

A more complete DMARC record example

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; pct=100; adkim=r; aspf=r

• rua = address for aggregate reports (summary of all email activity)
• ruf = address for forensic reports (individual failure reports)
• pct=100 = apply policy to 100% of emails
• adkim=r and aspf=r = relaxed alignment (recommended for most setups)

Step 4: Verify All Three Records Are Working

Once you have published your SPF, DKIM, and DMARC records, verify that all three are resolving correctly before sending any campaigns.

Tools to use

• MXToolbox (mxtoolbox.com) – Run SPF, DKIM, and DMARC lookups individually. It will flag missing records, syntax errors, and propagation issues.
• mail-tester.com – Send a test email to a unique address it provides and get a score with detailed authentication results.
• Google Admin Toolbox (toolbox.googleapps.com) – Useful for checking DNS propagation from Google’s perspective.

What a passing result looks like

• SPF: “SPF record found. No issues detected.”
• DKIM: Signature validates successfully.
• DMARC: Policy record found with valid syntax.

If any check fails, revisit the corresponding DNS record. Common issues include typos in the TXT value, publishing the record to the wrong hostname, or having duplicate SPF records.

Common Mistakes to Avoid

Having more than one SPF record. DNS only allows one SPF TXT record per domain. If you have two, both fail.

Using the wrong hostname for DMARC. The DMARC record must be published at _dmarc.yourdomain.com, not at the root domain.

Not enabling DKIM signing after adding the DNS record. Adding the DNS record is only half the step. In Google Workspace and Microsoft 365, you also need to manually turn on DKIM signing in the admin console.

Setting DMARC to p=reject immediately. If your SPF or DKIM are misconfigured and DMARC is set to reject, you will block your own legitimate sends. Start with p=none.

Skipping authentication on secondary domains. Every domain you use for cold email needs its own complete set of authentication records. You cannot inherit authentication from another domain.

Where Peeker Fits

Configuring SPF, DKIM, and DMARC correctly is a one-time setup task. The harder problem is knowing when something breaks after the fact.

DNS records get accidentally overwritten. Google Workspace DKIM keys expire or need rotation. Domains age into poor reputation and start failing spam filters even with perfect authentication. In a high-volume cold email operation with dozens of sending domains, catching these issues manually is not realistic.

Peeker’s Deliverability Analytics surfaces authentication failures, inbox placement drops, and deliverability signals across your entire domain portfolio in real time. And when a domain starts showing signs of degraded health, Peeker’s Burn Detection flags it before it contaminates your active campaigns.

For teams running cold email at scale, that kind of visibility is the difference between catching a problem early and discovering it two weeks later when reply rates have already collapsed.

FAQ

What is SPF in cold email and why does it matter?

SPF (Sender Policy Framework) is a DNS record that tells receiving mail servers which IP addresses are authorized to send email from your domain. Without it, servers have no way to verify your emails are legitimate, which increases the likelihood of them being filtered or rejected. For cold email, SPF is a non-negotiable baseline.

Do I need separate DKIM, SPF, and DMARC records for every cold email domain I use?

Yes. Authentication records are domain-specific. If you are sending cold email from 20 domains, each one needs its own SPF, DKIM, and DMARC configuration. There is no shared or inherited authentication across domains. This is one reason high-volume cold email teams benefit from tools that monitor authentication health across their entire domain portfolio, like Peeker’s Deliverability Analytics.

How long does it take for DKIM and DMARC records to propagate?

DNS propagation typically takes between a few minutes and 48 hours depending on your DNS provider and TTL settings. Most records resolve within an hour. Use MXToolbox or Google Admin Toolbox to check whether your records are visible before sending.

What happens if my DMARC policy is set to p=reject and my DKIM is misconfigured?

Legitimate emails from your domain will be rejected by receiving servers. This is why starting with p=none is strongly recommended while you confirm your authentication setup is working end to end. Move to stricter policies only after you have validated that SPF and DKIM are passing consistently.

Can a domain with proper authentication still end up in spam?

Yes. Authentication proves the email is coming from who it claims to come from – it does not vouch for the content or sending reputation of the domain. A properly authenticated domain that sends too fast, too soon, or with poor content can still land in spam. Authentication is the floor, not the ceiling, of deliverability. If a domain starts showing signs of inbox degradation, Peeker’s Burn Detection can flag it before it does damage.

Conclusion

Getting DKIM, SPF, and DMARC right is one of the most foundational steps in cold email infrastructure. It is not complicated once you know the exact records to create, but it is easy to misconfigure, and the consequences are difficult to diagnose after the fact.

The short version: publish a single SPF record authorizing your sending platform, generate and activate DKIM signing through your mail provider, and set DMARC to p=none with a reporting address while you verify everything is working. Then gradually tighten your policy as you confirm your authentication is solid.

If you are managing this across multiple cold email domains and want visibility into what is actually working, start tracking your deliverability in minutes. Try Peeker free at Pricing.