Short version: yes, and it is no longer a question of best practice. Since Google and Yahoo published their bulk sender requirements in 2024, a DMARC record on your sending domain is table stakes, and the cost of not having one is paid quietly in filtered mail rather than loudly in error messages.

The longer version is worth reading, because the way people usually implement it is where the actual damage happens.

What DMARC does, in one paragraph

You already have SPF, which lists the servers allowed to send mail for your domain. You already have DKIM, which cryptographically signs each message so a receiving server can tell it was not altered.

Neither of them tells the receiving server what to do when a message fails. That decision is left to each provider, and they all guess differently. DMARC is you publishing the answer: quarantine it, reject it, or let it through and tell me about it.

It also adds one thing SPF and DKIM lack on their own: alignment. A message can pass SPF perfectly for a domain the recipient never sees, while the From line says something else entirely. That gap is precisely how convincing phishing works, and closing it is DMARC's real contribution.

Why it became effectively mandatory

Google and Yahoo's 2024 requirements for bulk senders include, in plain terms:

  • Authenticate with SPF and DKIM
  • Publish a DMARC record on the sending domain (p=none satisfies the letter of it)
  • Keep spam complaint rates below 0.3%
  • Support one-click unsubscribe on marketing mail
  • Ensure the From domain aligns with SPF or DKIM

The thresholds are aimed at high-volume senders, but the signals are applied broadly. A domain with no DMARC record reads as unmanaged infrastructure, and unmanaged infrastructure is what most spam comes from. You do not need to be a bulk sender to be judged by the same heuristics.

Get the order right

This is where most of the self-inflicted damage happens. The order is not optional:

  1. SPF first. Every service that sends mail as you must be listed. Your mailbox provider, your outreach tool if it relays, your invoicing system, your helpdesk, your marketing platform.
  2. DKIM second. Signing enabled and verified for each of those services.
  3. DMARC last, and starting at p=none.

Publishing DMARC first tells the world to enforce rules you have not finished configuring. People do this, see mail start disappearing, and conclude DMARC is dangerous. DMARC is not dangerous. Enforcing before you have looked is dangerous.

The three policies

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

p=none changes nothing about delivery. It asks receiving servers to keep doing whatever they were doing and send you aggregate reports about what they saw. This is where you start, always. Run it for two to four weeks.

Those reports are the point. Almost everyone who reads their first DMARC report discovers at least one legitimate service sending as their domain that they had forgotten about. Finding that before enforcement is the entire reason p=none exists.

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100

p=quarantine sends failing mail to spam. Move here once your reports show every legitimate source passing. If you are nervous, pct=25 applies the policy to a quarter of failing messages first.

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

p=reject tells servers to refuse failing mail outright. It is the strongest anti-spoofing position and where you want to end up, after quarantine has run clean for a month.

Alignment is the part people miss

A message passes DMARC if either SPF or DKIM passes and aligns with the domain in the visible From header.

Consider a tool that sends on your behalf using its own envelope domain. SPF checks that envelope domain and passes. Your From header says you@yourdomain.com. SPF passed, but it passed for the wrong domain, so it does not align, so it does not help you.

DKIM alignment is usually the more robust route for third-party senders, because a properly configured DKIM signature carries your domain regardless of which server relayed the message. It is also the reason a forwarded email can break SPF but survive DKIM.

If you use any service to send as your domain, the question to ask them is not "do you support SPF." It is "does your DKIM signature use my domain, and what do I need to publish for that."

The two mistakes that break things

Too many SPF lookups. SPF permits ten DNS lookups. Each include: counts, and each include can pull in more. Add enough services and you silently exceed the limit, at which point SPF returns a permanent error and every message fails it. Check your record with an SPF validator rather than counting by eye, and flatten or consolidate if you are near the ceiling.

Forgetting a sending source before enforcing. Your accounting software sends invoices as your domain. Your booking system sends confirmations. Nobody remembers these at DMARC time, and both stop being delivered the day you publish p=reject. This is exactly what p=none reporting is for, and skipping that phase is how it happens.

Cold email specifically

Three additions on top of the general advice.

Send cold outreach from a separate domain. Not a subdomain of your primary domain: a separate domain, redirected to your main site. If a cold campaign damages sender reputation, you want that damage contained somewhere that is not the domain your invoices and contracts go out on. This is the single highest-leverage decision in the whole setup, and it is one you can only make cheaply at the beginning.

Do not inherit a subdomain policy by accident. A DMARC record on example.com applies to subdomains unless you say otherwise with the sp tag or a dedicated record. If you deliberately send from mail.example.com, decide what its policy is rather than discovering it.

DMARC does not make you deliverable. It gets you past a gate. Everything that decides whether you land in the inbox afterwards, reputation, engagement, list quality, complaint rate, is still ahead of you. Authentication is necessary and nowhere near sufficient.

Checking your setup

Send a message to an address at Gmail, open it, and use "Show original." You want to see three lines saying PASS: SPF, DKIM and DMARC. If DMARC says FAIL while SPF says PASS, you have an alignment problem, not an SPF problem, and the fix is on the From domain rather than the record.

For anything more than a spot check, read your aggregate reports. They are XML and unpleasant by hand, and any of the free DMARC report parsers will turn them into something legible.

Leads Ranger audits SPF, DKIM, DMARC and MX for every mailbox you connect and reports what is wrong in plain English rather than raw DNS, because the failure mode that matters here is not knowing something is broken.

The five-minute version

If you do nothing else today, publish this:

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

It cannot break anything, it satisfies the stated requirement, and it starts the reports you need before you can safely do anything stronger. Then read those reports in a fortnight and move to quarantine.