How to Set Up DMARC for Cold Email (Step-by-Step Guide)

Your cold emails can have perfect copy and a solid offer and still land in spam because your DMARC record is wrong. DMARC is the one DNS record that tells receiving mail servers what to do when someone tries to send email pretending to be your domain. For cold email senders, getting it right is not optional. This guide walks through what a DMARC record does, how to set one up correctly for your sending domains, which policy to use for cold outreach, and what to watch for once it's live.

What is a DMARC record for email?

A DMARC record is a DNS TXT record that tells receiving mail servers how to handle messages that fail SPF or DKIM authentication on your domain. Without it, there's no instruction. Servers can accept, reject, or quietly file failed auth messages however they want. With it, you control that behavior and get visibility into who's sending on behalf of your domain.

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It builds on top of SPF (which authorizes sending IP addresses) and DKIM (which signs the message with a cryptographic key). Where SPF and DKIM authenticate, DMARC enforces and reports back to you what it found.

For cold email specifically, DMARC matters in two ways. First, Google and Microsoft now require DMARC on any domain sending at volume. Without a record at all, you'll hit inbox placement issues before your first send. Second, your policy setting determines how aggressively receiving servers treat unauthenticated messages. Getting that wrong either kills your deliverability or leaves your domain exposed to spoofing.

What does a DMARC record look like?

A DMARC record is a TXT record published at the subdomain _dmarc.yourdomain.com, and it looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The key fields:

• v=DMARC1 - version tag. Required. Always first.
• p=none|quarantine|reject - the policy. This determines what happens to messages that fail authentication.
• rua=mailto:... - where aggregate reports go. These are daily rollup reports from receiving servers telling you how many messages passed and failed authentication.
• ruf=mailto:... - where forensic (per-message failure) reports go. Optional, and many senders skip this.
• pct=100 - what percentage of failing messages the policy applies to. Defaults to 100. You can start at a lower number while rolling out stricter policies.
• sp=none|quarantine|reject - subdomain policy. If you want a different rule for subdomains, set this separately. Otherwise the main policy applies.

Which DMARC policy should cold email senders use?

For sending domains used in cold outreach, start with p=none and move to p=quarantine once you confirm your authentication is working cleanly. For most cold email senders, stopping at quarantine is fine. Reject is stricter than you need and can cause issues if any legitimate send path isn't fully authenticated.

Here's the policy progression and what each actually means:

• p=none (monitoring) - the DMARC record exists, reports go to your inbox, but nothing is blocked or filtered. Use this first to observe. Google and Microsoft's sender requirements consider p=none acceptable, having the record at all is what's required.
• p=quarantine - messages that fail authentication go to spam. This is the right end-state for most cold email sending domains. You're protected from spoofing, legitimate mail still flows, and the policy signals that you care about authentication.
• p=reject - messages that fail authentication are rejected outright, not delivered. Use this for your main business domain (the one you use for internal email and client communication), not your sending subdomains. The risk of a misconfigured send path rejecting legitimate mail is too high for active outbound operations.

A note on the DMARC policy choice for cold outreach: your sending domains are separate from your main domain. Your main domain (company.com) should run p=reject over time. Your sending domains (co-company.com, usecompany.com) should run p=quarantine once you've confirmed SPF and DKIM are both passing.

How do you set up a DMARC record for a cold email sending domain?

Setting up DMARC takes about five minutes once SPF and DKIM are already configured. Here's the sequence:

Step 1: Confirm SPF and DKIM are working first. DMARC requires at least one of them to pass and align. If your SPF record isn't set or your DKIM key isn't published and signing, adding DMARC won't help. It has nothing to validate against. Use MxToolbox or Google Admin Toolbox to verify both records are resolving correctly before you add DMARC.

Step 2: Build your DMARC record. For a sending domain starting out, use this:

v=DMARC1; p=none; rua=mailto:dmarc@yoursendingdomain.com

Replace the RUA address with a real inbox you check. You'll get aggregate reports from Gmail, Outlook, and others. These are plain XML files that show you how your messages are authenticating and from which IP addresses.

Step 3: Add it to DNS. Go to your domain registrar or DNS host (Cloudflare, Namecheap, Route53, etc.). Add a TXT record:

• Name/Host: _dmarc (this creates the record at _dmarc.yourdomain.com)
• Type: TXT
• Value: your DMARC record string
• TTL: 300 or default (lower TTL is fine for initial setup)

Step 4: Verify propagation. DNS changes take 5 to 30 minutes for most registrars. Check it with dig _dmarc.yourdomain.com TXT or the MxToolbox DMARC lookup. You should see your record returned.

Step 5: Monitor for two weeks, then tighten. Once reports start coming in and you see SPF and DKIM passing consistently, move from p=none to p=quarantine. That's usually the final state for a sending domain.

What does DMARC alignment mean, and why does it trip senders up?

DMARC doesn't just check whether SPF and DKIM pass. It checks whether they align with the From address your recipient sees. This is the piece most guides skip, and it's where cold email senders run into issues.

SPF alignment means the Return-Path domain (the bounce address in the email headers) matches the From domain. When you send through a third-party tool like Smartlead or Instantly, the Return-Path might be their domain by default. If your SPF record is on your domain but the Return-Path is on theirs, SPF passes but doesn't align to your From address. DMARC won't count it.

DKIM alignment means the d= domain in the DKIM signature matches the From domain. If you've set up DKIM on your sending domain and your sequencer is signing with that key, alignment passes cleanly. This is why properly configured DKIM on your sending domain is the more reliable authentication path for cold email.

The practical fix: configure DKIM on your actual sending domain, not just on your sequencer's default settings. Most platforms support custom DKIM. If your platform doesn't, your authentication is weaker than it looks, because you're relying on SPF alignment that can break with any forwarding or routing change. The DKIM setup guide covers the exact steps for Google Workspace and Microsoft 365.

What are the most common DMARC mistakes cold email senders make?

The most common issue is adding DMARC before SPF and DKIM are correctly configured. DMARC in monitoring mode (p=none) won't break anything, but the reports will show you authentication failures that you then have to chase down. Fix the underlying records first, add DMARC in monitoring mode, confirm everything passes, then keep the record in place.

Second most common: publishing DMARC on the sending domain but not the main domain (or the reverse). Your main company domain should have DMARC too, and it should be stricter than your sending domains over time. A spoofed email from your main domain is a brand and legal problem. A spoofed email from a sending domain is annoying but contained.

Third: setting p=reject too early. If you move to reject before every send path is authenticated, you'll block legitimate mail. The quarantine policy gives you the sender reputation signal without the hard rejection risk. Most cold email senders never need to go beyond quarantine on sending domains. The DMARC issues troubleshooting guide walks through the failure modes with specific fixes.

Fourth: ignoring the RUA reports. Set a real inbox for aggregate reporting and actually look at the reports once a week for the first month. You'll see exactly which IP addresses are passing and failing authentication for your domain. If an unfamiliar IP shows up sending on your behalf, that's either a misconfigured send path or someone spoofing you. You want to know.

How does DMARC fit into the full cold email authentication stack?

DMARC is the capstone, not the foundation. The order matters:

1. SPF - lists the IP addresses and services authorized to send email on behalf of your domain. One TXT record at your root domain.
2. DKIM - cryptographically signs your outgoing messages so receiving servers can verify the message content wasn't tampered with in transit.
3. DMARC - checks whether SPF or DKIM passed and aligned, then enforces a policy and reports back on what it found.

All three need to be configured correctly on every sending domain you use. "Sending domain" means any domain in your From address, not just your main company domain. If you're running 20 sending domains, each one needs its own SPF record, DKIM key, and DMARC record. That's a real setup and maintenance burden if you're managing it manually, which is part of why managed infrastructure services exist.

The cold email infrastructure guide goes deeper on how the full DNS stack works across a fleet of sending domains. The advanced DNS for email deliverability guide covers edge cases like SPF flattening, DKIM key rotation, and DMARC subdomain policies for complex sending setups.

Frequently Asked Questions

Do I need DMARC for cold email?

Yes. Google and Microsoft require a DMARC record on any domain sending at volume, specifically for domains sending to Gmail and Outlook at scale. Beyond compliance, DMARC in monitoring mode costs you nothing and gives you visibility into how your authentication is performing. There's no reason to skip it.

What DMARC policy should I set for cold email sending domains?

Start with p=none to monitor authentication, then move to p=quarantine once you confirm SPF and DKIM are both passing and aligned. Most cold email sending domains stay at quarantine. Use p=reject for your main business domain, not your sending domains.

Can I add DMARC without DKIM?

Yes, but DMARC will rely entirely on SPF alignment to pass. SPF alignment can break under forwarding and with certain sequencer configurations. DKIM alignment is more reliable for cold email. Set up DKIM on each sending domain before treating your DMARC configuration as production-ready.

How long does it take for a DMARC record to propagate?

Most DNS changes propagate within 5 to 30 minutes. You can verify with dig _dmarc.yourdomain.com TXT or MxToolbox's DMARC lookup. If you're not seeing the record after an hour, check for typos in the record name. The underscore in _dmarc is required.

Will DMARC affect my cold email deliverability?

Adding a DMARC record in p=none mode doesn't change how your messages are delivered. It's purely observational. Moving to quarantine or reject affects how receiving servers handle authentication failures, not properly authenticated mail. Correct DMARC configuration improves deliverability by signaling to inbox providers that your domain is managed. Incorrect configuration (like p=reject before authentication is solid) can cause delivery failures for legitimate mail.

At ScaledMail, we provision and manage the infrastructure layer end to end: secondary sending domains separate from your main business domain, real Google Workspace and Microsoft 365 inboxes, authentication configured correctly (SPF/DKIM/DMARC on every domain), IP rotation, and continuous reputation monitoring. Warmup runs inside your sequencer (Smartlead, Instantly, EmailBison, PlusVibe), where the engagement signals live. DNS setup including DMARC is part of what we configure when we bring a domain online. You don't have to manage it record by record. See the setup or get started if you want the foundation built right.