How to Create a DMARC Record for Cold Email

Most cold email problems that look like "the platform is broken" are DNS problems. And of the three authentication records, DMARC is the one people either skip entirely or copy-paste from a blog post at `p=reject` on day one — then wonder why half their sequence disappears.

A DMARC record is a single TXT record. Creating it takes about four minutes. Getting the policy right for a cold email domain takes a bit more thought, because the record does two separate jobs: it tells mailbox providers what to do with mail that fails authentication, and it gives you a reporting feed showing every source sending as your domain. For outbound, the second job is worth more than the first.

{"h2":"What a DMARC record actually is"}

{"h2":"What a DMARC record actually is"}

DMARC sits on top of SPF and DKIM. SPF checks whether the sending IP is authorized for the envelope sender domain. DKIM checks whether the message carries a valid cryptographic signature from a domain. DMARC adds a third question: does either of those authenticated domains match the domain in the From: header the recipient sees?

That matching step is called alignment, and it's why a message can pass SPF and DKIM and still fail DMARC. If you've hit that, read Why Does DMARC Fail Even When SPF and DKIM Pass? — it walks through the alignment cases in detail. This post is about building the record itself.

{"h2":"The record you should publish first"}

For a brand-new cold email domain, publish this and nothing more complicated:

{"ul":["Type: TXT","Host / Name: `_dmarc`","Value: `v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1`","TTL: 3600 (or default/auto)"]},

One quirk trips up half of first-timers: some DNS hosts want just `_dmarc` in the host field and append the domain for you (Cloudflare, Namecheap, GoDaddy). Others — some cPanel installs, a few registrars — want the fully qualified `_dmarc.yourdomain.com`. If you enter the full name on a host that auto-appends, you'll end up with `_dmarc.yourdomain.com.yourdomain.com` and DMARC will silently not exist. Always verify after publishing.

{"h2":"Every tag, and which ones you actually need"}

{"table":{"headers":["Tag","What it does","Use it for cold email?"],"rows":[["v=DMARC1","Version identifier. Must be first.","Required"],["p=","Policy for the domain: none, quarantine, or reject","Required — start at none"],["rua=","Where aggregate XML reports are sent","Yes — this is the whole point early on"],["ruf=","Where forensic/failure reports are sent","Optional; most providers don't send them"],["fo=1","Generate failure reports when SPF or DKIM fails, not just both","Nice to have"],["sp=","Policy for subdomains, overrides p=","Yes if you send from subdomains"],["pct=","Percentage of failing mail the policy applies to","Useful when stepping up to quarantine"],["adkim=","DKIM alignment: r (relaxed) or s (strict)","Leave relaxed"],["aspf=","SPF alignment: r or s","Leave relaxed"],["ri=","Report interval in seconds (default 86400)","Leave default"]]}},

Relaxed alignment (`r`, the default) means the organizational domain has to match — so `mail.yourdomain.com` aligns with `yourdomain.com`. Strict means an exact match. For cold email you almost never want strict; it buys you nothing against spoofing that matters and breaks subdomain setups.

{"h2":"Why start at p=none"}

`p=none` means "do nothing different to failing mail, but send me reports." It feels useless. It isn't. Publishing `p=none` with a `rua` address is how you find out, within a week, every service that sends mail using your domain — your outbound tool, your CRM's notification emails, your invoicing app, an old form handler you forgot about, and anything actually spoofing you.

If you jump straight to `p=reject` before you've seen that data, you will break something. On a fresh cold email domain that only ever sends through one platform, the blast radius is small — but "small" still means a week of mail getting rejected before you notice, because rejections from DMARC often don't produce a bounce you'd recognize as an auth failure.

There's also a Gmail/Yahoo angle. Since their 2024 bulk sender rules, anyone sending 5,000+ messages a day to Gmail needs a DMARC record published — but `p=none` satisfies the requirement. Below that threshold you still need SPF or DKIM aligned. Publishing DMARC anyway is free and signals a maintained domain. More on the thresholds in Google and Yahoo Sender Requirements.

{"h2":"Reading the reports without drowning"}

Aggregate reports arrive as gzipped XML attachments, usually daily, one per reporting provider. They're genuinely unpleasant to read raw. Options:

{"ul":["Point `rua` at a dedicated mailbox and open a few manually in the first two weeks — with one sending source, the XML is short enough to skim.","Use a free parser. Dmarcian, Postmark's DMARC tool, and URIports all have free tiers that turn the XML into a table of source IPs with pass/fail counts.","Don't point `rua` at a mailbox on the sending domain that a human checks daily. Use `dmarc@` and route it somewhere quiet."]},

What you're looking for: a list of sending IPs, and for each one, whether SPF and DKIM aligned. If the only IPs are your provider's (Google, Microsoft, or your SMTP relay) and they're all passing, you're clean.

One gotcha: if you send reports to an address on a different domain — say `rua=mailto:reports@agency.com` while the record is on `client.com` — the receiving domain must publish an authorization record: `client.com._report._dmarc.agency.com` with value `v=DMARC1`. Without it, most providers won't send the reports and you'll assume nobody's reporting.

{"h2":"The step-up schedule"}

Here's a timeline that works for a cold email domain that's already through warm-up:

{"ul":["Weeks 1–3: `p=none; rua=...; fo=1`. Collect reports. Confirm SPF and DKIM align on 100% of your sending volume.","Week 4: `p=quarantine; pct=25; rua=...`. A quarter of failing mail goes to spam. Watch reply volume and reports for anything unexpected.","Week 6: `p=quarantine; pct=100; rua=...`.","Week 8+: `p=reject; rua=...` if you want maximum spoofing protection and you're confident every legitimate source is aligned."]},

Is `p=reject` necessary for cold email? Not strictly. There's no evidence that Gmail treats `reject` domains meaningfully better than `none` domains for inbox placement — the authentication pass itself is what matters. But `reject` prevents someone else spoofing your domain and torching the reputation you spent a month building, and on a domain you only use for outbound, the risk of breaking legitimate mail is low. Most outbound operators end up at `quarantine` or `reject` within two months.

{"h2":"Subdomains and the sp tag"}

If you're running outbound from `go.yourdomain.com` or `mail.yourdomain.com`, a DMARC record on the root domain covers the subdomain by default. You don't need a separate `_dmarc.go.yourdomain.com` record unless you want a different policy there.

That's the common case: keep the brand domain at `p=reject` because nothing unexpected sends from it, but publish `_dmarc.go.yourdomain.com` with `p=none` while the sending subdomain is new. Or go the other way with `sp=reject` on the root to lock down subdomains you never send from. If you're still deciding on structure, Subdomain vs. Secondary Domain covers the trade-off.

{"h2":"Five mistakes that break DMARC records"}

{"ul":["Two DMARC records on one host. Unlike SPF, having two isn't a soft failure — receivers ignore both. Check for an old record before adding a new one.","Publishing at the root instead of `_dmarc`. A DMARC string in your root TXT record does nothing.","Smart quotes. Copying from a doc that converted `\"` into curly quotes will produce a malformed record. Type it or paste from plain text.","`p=reject` with no DKIM on the sending domain. If your platform signs with its own domain and your SPF doesn't align either, reject means every message fails. Set up DKIM first.","Forgetting the record exists. A domain sitting at `p=reject` for two years with a dead `rua` mailbox is a domain where you'll find out about a problem from a prospect, not a report."]},

{"h2":"Verify it, then keep watching"}

After publishing, wait 15–30 minutes and check with `dig TXT _dmarc.yourdomain.com` (or `nslookup -type=TXT _dmarc.yourdomain.com` on Windows). You should see exactly one string starting `v=DMARC1`. Then send a test message to a Gmail address, open it, choose "Show original," and confirm the header block shows `DMARC: 'PASS'` alongside SPF and DKIM.

{"h2":"Where Sendvanta fits"}

Sendvanta checks DMARC as part of its layered deliverability health scoring — alongside SPF, DKIM, mailbox age, and domain-level signals — so a missing or misconfigured `_dmarc` record surfaces before a campaign starts rather than after a week of quiet failures. If the domain's authentication posture degrades mid-campaign, sending slows or pauses automatically instead of grinding through a list with broken alignment. You connect your own Gmail, Microsoft 365, or SMTP mailboxes; nothing routes through shared IPs, so the alignment you configure is the alignment that's evaluated. The free plan is $0 forever with 1,000 active leads and 3,000 emails a month, which is enough to publish a record, run a campaign, and confirm your DMARC passes in the wild before paying for anything.