DMARC is a DNS TXT record that tells email receivers what to do with mail claiming to come from your domain that failed authentication. It sits on top of two other records, SPF (which IPs may send for you) and DKIM (a cryptographic signature on each message). DMARC itself sends no mail and signs nothing. It is a policy: "check this mail against my SPF and DKIM, and if it fails, do X."
At a host named _dmarc.yourdomain.com. A minimal record:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
p=none means "monitor only": receivers still deliver the mail, but they send you aggregate reports to the rua address so you can see who is sending as your domain and whether that mail authenticates. p=quarantine asks receivers to route failures to spam; p=reject asks them to refuse delivery outright.
A lot of guides imply that publishing p=none "protects" your domain. It does not block anything by itself. What it does is three things: (1) it starts the flow of aggregate reports, which is the only reliable way to find out who is sending as your domain; (2) it is a published policy that large providers treat as a signal your domain is managed; and (3) it is a prerequisite before you can safely move to quarantine or reject. Google and Yahoo's bulk-sender requirements ask for a published DMARC record at p=none as the minimum, and for aligned SPF or DKIM on top of that.
DMARC passes when the domain in the From header "aligns" with the domain that passed SPF or DKIM. The default is relaxed alignment: mail@sub.yourdomain.com aligns with yourdomain.com. If you send from a completely different domain (a third-party ESP's own domain, for example), alignment fails and DMARC fails too, even if SPF and DKIM are both configured correctly. This is the most common reason a "configured" DMARC still shows failures in the reports.
1. Check what exists. Look up your SPF, DKIM and DMARC records. If you have no idea who sends mail for your domain (marketing tools, transactional mail, legacy systems), that's the first thing to sort out, because you can't safely enforce a policy you don't understand.
2. Fix SPF and DKIM first. DMARC is only as good as the two records underneath it. A broken SPF with a strict DMARC just rejects your own legitimate mail.
3. Publish p=none and read the reports. Aggregate reports arrive as XML files; you don't need to parse them by hand, but you do need to see whether the senders you expect are authenticating.
4. Move to p=quarantine, then p=reject, once the reports show only your legitimate senders passing. Most domains that have been sitting at p=none for years can make this jump in a week.
If you find a domain you don't recognize in the reports, that's a real signal, not a false alarm: someone is sending mail as you. The fix is the same order of operations, faster. And if your domain has no DMARC at all, you have no way of knowing whether that's happening today, which is the whole point of the record.
Related: p=none vs quarantine vs reject · SPF vs DKIM vs DMARC · Why email misses Gmail's inbox
The free audit checks SPF, DKIM, DMARC, MX, TLS and more in about 30 seconds, and shows the exact record to add if one is missing.
Run the free auditWant this checked automatically every day? Inboxproof Pro monitors your domain around the clock and alerts you the moment a record breaks or an IP gets listed. See pricing →