You set up cold email for a client. New domain, warmed it up for a few weeks, wrote the sequences. The emails still land in spam. Someone tells you to "fix your DMARC" and you are not even sure you need it.
Here is the short answer: yes, you need DMARC for cold email in 2026. Not because it is nice to have, but because Gmail and Microsoft now expect it, and without it your sending domain looks unauthenticated to the exact systems deciding inbox vs spam.
This post explains what DMARC actually does for a cold sender, why it matters more now than it did two years ago, and how to set it up without breaking your sending.
Do you need DMARC for cold email?
Yes. If you send cold email from a domain, that domain needs a DMARC record. This is true whether you send 50 emails a day or 5,000.
Two things changed that make this non-optional:
Gmail's 2025 sender rules. Google now requires SPF, DKIM, and DMARC for anyone sending to Gmail addresses at volume. A missing or misconfigured DMARC record is one of the first things that gets a domain filtered.
Microsoft's 2025 enforcement. Outlook and Microsoft 365 tightened the same way. Sending to business inboxes without proper authentication now carries a real deliverability penalty.
For a cold-email agency this hits harder than for a normal business, because you are sending to people who did not ask to hear from you. You have no engagement history to fall back on. Authentication is one of the few signals working in your favor, so you cannot afford to get it wrong.
What DMARC actually does
DMARC ties together the two authentication checks you may already have: SPF and DKIM. On its own it does not send or block anything. What it does is tell receiving servers two things:
1. What to do when an email claiming to be from your domain fails authentication. Your policy can say "do nothing" (p=none), "send it to spam" (p=quarantine), or "reject it outright" (p=reject).
2. Where to send reports so you can see who is sending email as your domain, including anyone spoofing you.
A minimal DMARC record looks like this:
v=DMARC1; p=none; rua=mailto:[email protected]
That single TXT record, published in your DNS, is what receivers look for. If it is not there, your domain reads as one that has not bothered to set up alignment, which is not the signal you want to send when you are already cold.
Does DMARC alone fix your deliverability?
No, and this is the part most people get wrong. DMARC is necessary but not sufficient.
Getting cold email into the inbox depends on several things working together:
SPF must list the servers allowed to send for your domain.
DKIM must sign your mail with a valid key.
DMARC must be published and aligned with the two above.
Sending behavior matters too: volume, ramp speed, list quality, complaint rate, and whether the content itself trips spam filters.
You can have a perfect DMARC record and still hit spam if your SPF is broken, your domain is brand new, or you are blasting a cold list too fast. DMARC removes one common reason for filtering. It does not remove the others.
This is also why warmup alone does not solve the problem. Warming a domain builds a small amount of positive history, but if the underlying authentication is broken, warmup is building on sand. The setup has to be right first.
How to set up DMARC for cold email without breaking sending
The mistake that scares people off is jumping straight to a strict policy and watching legitimate mail get rejected. The safe path is gradual.
Step 1: Confirm SPF and DKIM are working first. DMARC depends on them. If either is broken, fix that before touching DMARC.
Step 2: Publish DMARC at p=none. This is monitor mode. It changes nothing about how your mail is delivered, but it starts collecting reports so you can see what is actually being sent under your domain.
v=DMARC1; p=none; rua=mailto:[email protected]
Step 3: Read the reports for a couple of weeks. Confirm your real sending sources (your sending platform, any tools) are passing alignment. Fix anything that is not.
Step 4: Move to p=quarantine. Once you are confident legitimate mail passes, tighten the policy so failing mail goes to spam rather than through.
Step 5: Move to p=reject. This is the end state. Mail failing authentication for your domain gets rejected, which protects your domain from being spoofed and is the strongest signal to receivers that you run a tight ship.
For a cold-sending domain, getting to p=reject is worth doing. It is the difference between a domain that looks locked down and one that looks abandoned.
Check your domain before you send
Before you run a single campaign for a client, it is worth reading the domain's actual setup rather than assuming it is fine. A domain can have a DMARC record that is present but weak, an SPF record that is broken in a way that is invisible until mail starts failing, or a missing DKIM signature.
Humerly's free audit reads any domain in about 30 seconds and shows you exactly what is set up, what is broken, and the exact DNS record to publish to fix it. It checks SPF, DKIM, DMARC, MTA-STS, and more, and it is free with no signup.
You can run it on a client domain here: audit.humerly.com
If you want the DMARC-specific view, the DMARC checker walks through your policy level and the safe path from p=none to p=reject.
The bottom line
DMARC is not optional for cold email in 2026. Gmail and Microsoft expect it, and for a cold sender with no engagement history to lean on, authentication is one of the few things you control. Set it up gradually, starting at p=none, and confirm the rest of your setup is right before you blame warmup or content.
Read the domain first. Then send.