Nothing to the mail. It asks receivers to send you aggregate reports about messages that fail authentication, while delivering them normally. It is the right place to start so you can find legitimate senders you forgot about, but it provides no protection against spoofing.

Two weeks of clean aggregate reports is a reasonable minimum for an established domain. What you are looking for is any legitimate sender failing — a CRM, a helpdesk, an invoicing tool. Once reports show only your intended senders passing, move to quarantine. For a fresh cold email sending domain with exactly one sending provider, you can start at quarantine immediately.

Yes. DMARC is published per domain and is not inherited from anywhere. Every sending domain in a cold email fleet needs its own record. Bulk-generating them is straightforward — the DMARC generator produces copy-ready records.

When the rua address is on a different domain from the one publishing the policy, that external domain must authorise it with a record at yourdomain.com._report._dmarc.theirdomain.com. Without it, receivers are required to discard the reports. Reporting vendors usually document this step, and it is the most common reason reports never arrive.

Paste the domain into the box above, or query DNS directly with dig +short TXT _dmarc.yourdomain.com on macOS and Linux, or nslookup -type=TXT _dmarc.yourdomain.com on Windows. The record lives on the _dmarc subdomain, never on the root domain — querying the root is the most common reason a lookup comes back empty on a domain that is correctly configured.

In your DNS zone, as a TXT record with the host _dmarc. Most DNS panels append the domain automatically, so entering _dmarc produces _dmarc.yourdomain.com — entering the full hostname often produces _dmarc.yourdomain.com.yourdomain.com, which resolves to nothing. If you registered elsewhere but use Cloudflare or another provider for DNS, the record must live wherever your nameservers currently point.

It tells receiving mail servers what to do with messages that claim to come from your domain but fail authentication, and it gives you reports on who is sending as you. SPF and DKIM establish whether a message is authentic; DMARC is the layer that acts on the answer and makes the result visible. Without it, a failed check is information no one uses.

SPF lists which servers may send for your domain and is checked against the envelope sender, which recipients never see. DMARC is checked against the From address they do see, requires SPF or DKIM to pass for that same domain, and specifies a consequence for failure. SPF on its own can pass while a message is still visibly spoofed — that gap is precisely what DMARC exists to close.

Alignment. DMARC does not care that SPF and DKIM passed, only whether one of them passed for the domain in the From header. Sending platforms often use their own Return-Path for SPF and their own d= domain for DKIM, so both checks pass against the platform's domain while your From domain remains unauthenticated. Publish the provider's DKIM keys under your domain, or set a custom Return-Path — either one alone satisfies DMARC.

A message fails DMARC when neither SPF nor DKIM produces an aligned pass for the From domain. That covers genuine spoofing, but far more often it is your own mail: a forwarded message that broke the SPF chain, a CRM or invoicing tool nobody added to the record, or a mailing list that rewrote headers. Aggregate reports are what separate the two, which is why the rua tag matters more than the policy on day one.

Check the record itself with this tool, then send a message to an address you control and open the raw headers. The Authentication-Results line will show dmarc=pass or dmarc=fail along with the policy applied. The header analyzer parses that for you. Aggregate reports arriving at your rua address within a day or two are the other confirmation that receivers are honouring the record.

Not legally, but effectively yes for anyone sending at volume. Google and Microsoft's bulk sender requirements put a DMARC record on the baseline list for domains sending meaningful volume to their users, and a domain without one increasingly reads as unmaintained. For cold email specifically, treat it as required — the absence of a record is a signal you do not want attached to a sending fleet.

No. If two TXT records at _dmarc both begin with v=DMARC1, receivers must ignore both and the domain is treated as having no policy at all. This usually happens when a record is added through a control panel while an older one already exists further down the zone. Delete every duplicate so exactly one remains, then re-check.

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com — monitoring only, with a reporting address so you can see what is failing before you enforce anything. Once reports show only your intended senders, move to p=quarantine. The DMARC generator builds copy-ready records for any stage of that rollout.

Indirectly, and in your favour. DMARC does not improve placement for mail that already authenticates, but its absence is now read as a maintenance signal by the large receivers, and a strict policy protects the domain reputation you are building from being burned by spoofed mail. What it will not do is fix placement problems caused by content, list quality or volume — for those, start with the blacklist checker.

Yes. SPF breaks on forwarding because the forwarding server becomes the envelope sender, and any message forwarded through a mailing list or an auto-forward rule loses its aligned SPF pass. DKIM survives forwarding as long as the message body is unmodified, so it is what keeps DMARC passing in the cases SPF cannot cover. Running both is the point of the design.

Yes — paste one domain per line into the box above and each is looked up and graded separately. Email addresses are accepted too, with the domain extracted automatically, so a list of sending inboxes can go in unedited. This is the fastest way to spot policy drift across a sending fleet where domains were set up in batches at different times.

As long as the TTL on the TXT record, usually somewhere between five minutes and an hour, plus however long resolvers hold the previous answer. Set a low TTL before making changes if you expect to iterate. Note that receivers cache DMARC policy independently of your DNS TTL in some cases, so allow a day before concluding a change did not apply.

In May 2026 the IETF published RFC 9989, 9990 and 9991, replacing RFC 7489 from 2015 and moving DMARC from Informational status onto the standards track. Existing records stay valid and still begin with v=DMARC1. Three tags were deprecated — pct, rf and ri — and three added: np, t and psd. Organizational domain discovery also moved from the Public Suffix List to a DNS tree walk, which is a receiver-side change most senders will never notice.

Yes. pct is deprecated under RFC 9989 because receivers implemented it inconsistently — in practice only 0 and 100 behaved predictably. If your record sits at pct=100, delete the tag; the behaviour is identical. If it sits below 100, you have an unfinished rollout: either commit to enforcement and drop the tag, or publish t=y to signal the policy is provisional.

np sets the policy for subdomains that do not exist in DNS at all — the gap attackers used to spoof plausible-looking addresses such as billing.yourdomain.com that were never registered. It is new in RFC 9989 and falls back to sp, then p, when unset. Adding np=reject is a low-risk change for most domains, since no legitimate mail originates from a subdomain that does not exist.