Your cold email campaign is running. Your list is solid. Your copy converts. But then you notice something strange - your bounce rate is climbing, and your delivery is tanking. You check your spam folder out of habit, and there's barely anything there. The real problem? DMARC is rejecting your emails before they even reach the inbox.

If you've been running cold email for more than a few months, you've probably hit this wall. Gmail, Outlook, Yahoo, and every other major mailbox provider now enforce DMARC authentication as part of their spam filtering rules. Get it wrong, and your emails don't land - not in spam, but nowhere at all. Bounced. Gone.

This post walks you through exactly what's happening, why it matters, and how to fix it. If you've already set up SPF and DKIM, this is the next layer you need to understand.

What DMARC Actually Does (And Why It's Killing Your Delivery)

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. In plain terms: it's a way for mailbox providers to verify that an email actually came from who it says it came from.

Here's the problem with cold email: you're sending from someone else's domain (your client's domain, or a sending domain you control), but you're probably sending through a third-party platform like lemlist, Apollo, or Mailchimp. That creates authentication friction.

DMARC has three policy modes:

Most established businesses have DMARC set to reject or quarantine. If you're sending through an unauthenticated channel, your emails fail that check and never land.

The Core Problem: SPF Alignment

This is the specific thing that kills most cold email campaigns.

You set up SPF and DKIM (which you should have done already - if not, read this first). You think you're good. But DMARC doesn't just check whether SPF and DKIM exist - it checks whether they're aligned with the domain in the From header.

Here's what that means in practice:

If your From address is [email protected], DMARC checks whether the SPF record authorizes the IP you're sending from AND whether that IP authorization matches the domain in the From header. If you're sending through lemlist with a relaxed alignment setting, DMARC might pass for some mailboxes and fail for others.

The fix depends on your setup:

Option 1: Use a Dedicated Sending Domain (Recommended)

Instead of sending from [email protected], you create a subdomain like sends.yourdomain.com or mail.yourdomain.com specifically for cold email.

Why this works: You control the DMARC policy on that subdomain. You can set it to p=none or p=quarantine instead of reject. Your main domain stays protected, and your cold email gets proper alignment.

How to set it up:

  1. Create a new DNS record for sends.yourdomain.com.
  2. Add an SPF record: v=spf1 include:sendingplatform.com ~all (replace sendingplatform with your actual platform - lemlist, Apollo, etc.).
  3. Add a DKIM record (your email platform will give you the exact value).
  4. Add a DMARC record: v=DMARC1; p=none; rua=mailto:[email protected].
  5. Use [email protected] as your From address in your cold email platform.

Start with p=none and monitor your DMARC reports for 7-10 days. If everything passes, you can move to p=quarantine. Only move to p=reject after you're certain your infrastructure is solid (which means less than 5% SPF/DKIM failures).

Option 2: Use Your Client's Domain (High Friction)

If you're running cold email for a client and want to send from their main domain, you have to work with their DMARC policy directly. This is more complicated because you're depending on their infrastructure.

Ask your client to:

  1. Check their current DMARC record (they can use dig yourdomain.com TXT or a DMARC checker tool).
  2. If it's set to reject, ask them to lower it to quarantine temporarily while you build reputation.
  3. Make sure your sending platform is explicitly authorized in their SPF record.
  4. Verify DKIM alignment - your platform should be signing emails with their domain.

This approach works, but it's slower and depends entirely on your client's willingness to adjust their settings. Most established companies won't change DMARC for a single vendor.

How to Diagnose DMARC Failures

Before you fix anything, you need to know if DMARC is actually your problem.

Send a test email to yourself at Gmail or Outlook. Open the email, click the three dots, then "Show original" (Gmail) or "Message" > "Actions" > "View Message Source" (Outlook).

Look for the authentication headers. You want to see:

authentication-results: mx.google.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

If you see dmarc=fail, DMARC is rejecting your email. If you see dmarc=pass, you're good.

You can also set up DMARC aggregate reports (the rua= tag in your DMARC record) to get XML reports from mailbox providers showing exactly how many emails passed or failed. Google Postmaster Tools and similar services will parse these automatically.

Common Mistakes That Break DMARC

Mistake 1: Not using a subdomain, then changing your sending platform. If you've been sending from [email protected]` through Platform A, and you switch to Platform B, Platform B might not be authorized in your SPF record. Your emails start bouncing. This is why subdomains exist - you update one subdomain's SPF instead of affecting your whole domain.

Mistake 2: SPF includes that don't include your platform. If your SPF record says v=spf1 include:stripe.com ~all but you're sending through lemlist, lemlist isn't authorized. Check your actual sending platform's documentation for the exact SPF include to use.

Mistake 3: DKIM signing misconfiguration. Your email platform signs emails with a key, but if the DKIM record DNS entry doesn't match, the signature won't validate. Check the domain name in your DKIM record matches what your platform is using to sign.

Mistake 4: Testing with relaxed alignment when you need strict. Some platforms offer "relaxed" DMARC alignment - it's more forgiving. But Gmail and Outlook increasingly enforce strict alignment. Build assuming strict alignment.

The Real-World Setup That Works

Here's what actually works when you're running serious cold email campaigns:

You use a dedicated sending subdomain like sends.yourdomain.com. Your SPF explicitly includes your email platform. Your DKIM is set up with proper alignment. Your DMARC is set to p=none for the first two weeks, then p=quarantine once you see strong pass rates.

You monitor DMARC reports weekly. You track SPF/DKIM pass rates in your email platform's analytics dashboard. If either drops below 95%, you investigate immediately.

Once you're consistently hitting 98%+ authentication rates, you can confidently say DMARC isn't your deliverability problem. Any bounces after that point are usually spam filtering or content-based issues, not authentication.

When to Get Help

DMARC is straightforward if you own your domain and your sending infrastructure. If you're running campaigns across multiple domains, or if your IT team manages DNS, or if you're trying to send from a client's domain without direct access to their DNS - that's where things get messy.

The gap between understanding DMARC in theory and having it configured, tested, and monitored correctly across multiple campaigns is real. It's not hard, but it requires upfront infrastructure work and ongoing monitoring that pulls attention away from building your actual campaign and copy.

Related Guides