Phishing and spoofing was the single most-reported cybercrime in the FBI’s 2024 Internet Crime Report, with 193,407 complaints logged by the FBI’s Internet Crime Complaint Center. That’s the world your cold emails land in: a hostile inbox environment where receiving servers shoot first and ask questions later.

Here’s the thing. If your domain can be spoofed, inbox providers don’t know whether to trust mail from you. And when they don’t trust you, your legitimate outreach ends up in spam (or rejected outright).

In this guide, I’ll show you exactly how DMARC works, how to set it up step by step, and how to keep your cold emails landing in the inbox.

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It’s a DNS record that lets receiving servers verify an email really comes from your domain, working on top of SPF and DKIM.

Think of it as the final checkpoint. SPF tells a server which IP addresses can send on your behalf. DKIM adds a cryptographic signature that proves the message wasn’t altered in transit. DMARC ties both together and tells the receiving server what to do when mail fails those checks.

The protocol was first defined by the IETF in RFC 7489 (2015) and has since been updated. But the core logic remains: authenticate every message, report what happens, and give domain owners control over how failures are handled.

Without DMARC, a bad actor can send email pretending to be you. With DMARC, you tell inbox providers exactly how to handle those forgeries.

Let’s be direct: DMARC is now a hard requirement for sending cold outreach at scale.

Since February 2024, Google requires a DMARC policy for senders of 5,000 or more messages a day to personal Gmail accounts. This applies to personal Gmail, not Google Workspace domains, but personal Gmail accounts make up a significant portion of any cold email list. Yahoo requires bulk senders to publish a DMARC policy of at least p=none. Starting May 5, 2025, Microsoft routes mail from senders of 5,000 or more messages a day to Outlook.com that fails SPF, DKIM, or DMARC into the junk folder. Outright rejection is planned as a later phase. This applies to consumer Outlook.com, not Exchange Online.

The 5,000-message threshold sounds high. It’s not. If you’re running multichannel campaigns across multiple domains and mailboxes, you can hit that number faster than you think. And even if you’re below the threshold, missing DMARC signals to inbox providers that you don’t take authentication seriously. That hurts your sender reputation over time.

Sure, you can run outbound without DMARC. But you’re gambling with deliverability every time you hit send.

The stakes go beyond inbox placement. Business email compromise drove $2.77 billion in reported US losses in 2024, according to the same FBI report. When attackers spoof your domain to phish your prospects or partners, that’s your brand taking the hit.

DMARC protects your domain reputation. It tells inbox providers you’ve locked down your email authentication. And it gives you visibility into who’s sending mail on your behalf, legitimate or not.

When a message arrives at a receiving server, the server checks two things: does the sending IP match the SPF record for this domain? Does the DKIM signature validate?

DMARC adds a third layer. It looks at both results and checks whether the domain in the From header aligns with the domains used in SPF and DKIM. If both pass and align, the message is authenticated. If either fails, the DMARC policy decides what happens next.

Here’s what a basic DMARC record looks like:

Let me break down those tags:

v is the version. Always DMARC1.

p is the policy. It tells receiving servers what to do with messages that fail authentication. You have three options: none (monitor only, deliver anyway), quarantine (send to spam), or reject (block entirely).

rua is the reporting address. Receiving servers send aggregate reports here so you can see who’s sending mail from your domain.

You can add more tags to fine-tune behavior:

Most senders start with just v, p, and rua. Add the others as you get more sophisticated about monitoring.

DMARC depends on SPF and DKIM. If you haven’t configured those yet, start there. You’ll need to set up an SPF record for your domain and configure your DKIM record before DMARC can do its job. Without them, DMARC has nothing to enforce.

Once SPF and DKIM are in place, here’s how to add DMARC.

Before you create a new record, check whether your domain already has DMARC configured. You can run your domain through lemlist’s free deliverability setup checker to see your SPF, DKIM, and DMARC records in one place. If a record already exists, update it rather than create a duplicate.

Start with a monitoring-only policy so you can see what’s happening before you enforce anything:

Replace the email address with one you control. This is where aggregate reports will land. Use a dedicated mailbox or alias, because these reports can pile up fast.

Step 1: Open your domain provider’s DNS management panel. This is wherever you manage DNS for the domain you send from (GoDaddy, Cloudflare, Namecheap, or whoever hosts your domain).

Step 2: Add a new DNS record with these settings:

Save the record.

Step 3: Validate the record. Query _dmarc.yourdomain.com again and confirm your record appears. Note that DNS changes can take up to 48 hours to propagate, though it’s often faster.

Don’t jump straight to reject. The safe path is:

This gradual rollout lets you catch configuration problems before they bounce real outreach.

Setting up a DMARC record is the foundation. But if you’re sending thousands of cold emails across multiple mailboxes and domains, you need more than a DNS record. You need ongoing visibility into what’s actually happening.

When you connect an existing domain or buy a new sending domain in lemlist, the platform can set up authentication automatically. SPF, DKIM, and DMARC, configured correctly from the start. That removes one of the most common failure points: manual DNS setup errors that silently tank deliverability.

Before any campaign goes out, pre-send deliverability checks catch risky content, technical misconfigurations, and inbox-placement signals. You’ll know about authentication issues before they affect a real send.

And inbox placement testing takes it further. lemlist sends to real test addresses across Google and Microsoft to show whether you land in the primary inbox, promotions, or spam. You also get alerts when bounce rates or spam complaint trends start climbing. That kind of early warning is the difference between a fixable problem and a burned domain.

This isn’t about replacing DMARC setup. It builds on it with the monitoring that cold outreach at scale actually requires.

Once your DMARC record is live with a rua address, aggregate reports will start arriving. These are XML files sent by receiving servers, usually daily, summarizing what happened to mail from your domain.

These show the big picture across all messages:

Aggregate reports help you answer questions like: who is sending mail from my domain? Are my legitimate sources passing authentication? Is anyone spoofing me?

These contain details on individual messages that failed DMARC. They’re more granular but also more sensitive:

Not all inbox providers send forensic reports, and some organizations disable them for privacy reasons. Treat them as a nice-to-have, not a guarantee.

Here’s the catch. DMARC reports arrive as raw XML. They’re technically readable, but practically painful. A single day of sending can generate dozens of reports with thousands of lines.

You can parse them by hand if you enjoy that sort of thing. Most teams use a DMARC monitoring tool that aggregates and visualizes the data. That’s not strictly necessary, but it saves real time as volume grows.

Yes. Since February 2024, Google requires DMARC for senders of 5,000 or more messages a day to personal Gmail. Microsoft enforces similar rules for Outlook.com as of May 2025. Even below those thresholds, DMARC improves your sender reputation and protects your domain from spoofing.

A basic record looks like this: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. It’s a TXT record added to your DNS with _dmarc as the host.

SPF specifies which IP addresses can send mail for your domain. DKIM adds a cryptographic signature that proves the message wasn’t altered. DMARC ties both together and tells receiving servers what to do when messages fail authentication. You need all three for proper email authentication.

Start with p=none. It monitors without affecting delivery, so you can review reports and confirm legitimate mail passes before moving to quarantine or reject.

Query _dmarc.yourdomain.com and confirm your TXT record appears. Then send a test email and check the headers for DMARC=pass. A deliverability checker that shows full authentication results makes this easier.

DMARC isn’t optional for cold email in 2026. Google and Microsoft now enforce authentication requirements, Yahoo asks for the same, and sending without DMARC puts your deliverability at risk.

The setup itself is straightforward: confirm SPF and DKIM are in place, add a DMARC record starting with p=none, monitor your reports, then tighten the policy over time. The harder part is keeping visibility as you scale across multiple sending domains and mailboxes.

If you want to run cold outreach with authentication handled from day one, start a 14-day free trial.