If a scanner, deliverability tool, or DNS checker told you "no DMARC record found," here is the plain answer: there is no DMARC TXT record published at _dmarc.<yourdomain>. The tool queried that exact hostname, the DNS lookup came back empty, so it reported the gap. This is common, it is not an active compromise, and you can fix it in a few minutes by publishing a single DNS record.
What the message means
No DMARC policy is published at _dmarc.yourdomain, so receivers have no rule for forged mail.
Why "no DMARC record" matters
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is a DNS-published policy that tells receiving mail servers one thing: what to do when a message claiming to be from your domain fails authentication.
Here is the part that surprises people. You can already have SPF and DKIM set up and still have zero spoofing protection. SPF and DKIM authenticate mail, but on their own they do not tell a receiver to act on a failure. A mailbox provider that sees a forged message failing SPF is free to deliver it anyway, because nothing instructed it otherwise. DMARC is that instruction.
Without a DMARC record, an attacker can put your exact domain in the visible From: address of a phishing or business-email-compromise message, and receiving servers have no policy telling them to reject or quarantine it. The address is your real domain, not a lookalike, which is what makes these messages convincing to staff, customers, and suppliers. Publishing DMARC is how you take that capability away.
DMARC also adds a feedback loop. Once you publish a reporting address, mailbox providers send you aggregate reports listing every source sending mail that claims to be your domain. That visibility is valuable on its own, even before you start blocking anything.
The fix: publish one DMARC record
A DMARC policy is a single DNS TXT record. The host (also called name or label, depending on your DNS provider) is _dmarc, which makes the full record live at _dmarc.example.com for the domain example.com. The value is a short string of semicolon-separated tags.
Start with this monitor-only record. Replace you@example.com with a mailbox you actually read:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:you@example.com
That is a complete, valid DMARC record. It turns on reporting without affecting delivery of any mail. Here is what every tag does, including the ones you will add as you tighten the policy:
| Tag | What it does |
|---|---|
v | Version. Must be exactly v=DMARC1 and must be the first tag. Required. |
p | Policy for the domain. One of none (monitor), quarantine (treat failing mail as suspicious, usually spam folder), or reject (refuse failing mail outright). Required. |
rua | Address for aggregate reports, written as a mailto: URI. This is where the daily summaries of who sends as your domain are delivered. Strongly recommended. |
ruf | Address for per-message failure reports. More detailed and more sensitive; many providers no longer send these. Optional. |
pct | Percentage of failing mail the policy applies to, from 0 to 100. Defaults to 100. Used to roll out enforcement gradually, for example pct=25. Optional. |
sp | Policy for subdomains. If omitted, subdomains inherit the p value. Set it explicitly when you want subdomains treated differently. Optional. |
adkim | DKIM alignment mode: r for relaxed (default) or s for strict. Controls how closely the DKIM signing domain must match your From: domain. Optional. |
aspf | SPF alignment mode: r for relaxed (default) or s for strict. Same idea, for the SPF domain. Optional. |
One alignment rule worth knowing. A message passes DMARC only if SPF or DKIM passes and the passing domain is aligned with the domain in the visible From: address. A message can pass SPF for some unrelated bounce domain and still fail DMARC because that domain is not aligned. This is why DMARC catches exact-domain spoofing that SPF alone misses.
The safe rollout path: from monitor to enforce
Do not jump straight to p=reject. If any of your legitimate mail does not yet pass and align under SPF or DKIM — a newsletter platform, an invoicing tool, a help-desk system, a CRM — then an enforcing policy will quarantine or reject your own mail. The whole point of starting at p=none is to see every sender first, fix the gaps, and only then turn on enforcement. Move through these stages:
Stage 1 — Monitor only
Collect data, change nothing about delivery. Run this for about two weeks while you read the aggregate reports.
v=DMARC1; p=none; rua=mailto:you@example.com
Stage 2 — Quarantine a slice
Once reports confirm your legitimate senders pass and align, start enforcing on a fraction of failing mail. pct=25 applies quarantine to a quarter of failures so you can watch for surprises.
v=DMARC1; p=quarantine; pct=25; rua=mailto:you@example.com
Stage 3 — Full quarantine
If nothing legitimate is being caught, remove pct (it defaults to 100) so all failing mail is quarantined.
v=DMARC1; p=quarantine; rua=mailto:you@example.com
Stage 4 — Reject
The end state. Failing mail is refused at the receiving server and never reaches the inbox or spam folder. This is the policy that gives full exact-domain spoofing protection.
v=DMARC1; p=reject; rua=mailto:you@example.com
Step by step
- Log in to your DNS host. This is wherever your domain's DNS is managed — your registrar, or a provider like Cloudflare, Route 53, or Google Domains. DMARC lives in DNS, not in your email provider's settings.
- Add a new TXT record. Set the host/name to
_dmarcand the value to your starter record:v=DMARC1; p=none; rua=mailto:you@example.com. Some control panels auto-append your domain to the host, so you enter_dmarc; others want the full_dmarc.example.com. Do not type the full name twice. - Make sure SPF and DKIM already pass for legitimate mail. DMARC builds on them. If your real senders do not pass and align, tightening the policy later will quarantine your own mail. Verify SPF and DKIM first, then enforce.
- Wait for propagation. The record is usually live within minutes to a couple of hours, depending on your TTL. Re-check before assuming it failed.
- Read the aggregate (
rua) reports for about two weeks. Confirm every legitimate sending source shows as passing and aligned, then move up the stages above towardp=reject.
Re-check it live
After you publish, confirm it resolved. The email spoofing test checks SPF, DKIM, and DMARC together and gives a plain yes/no on whether your domain is spoofable. For the DMARC record alone — version, policy grade, and report addresses — use the DMARC checker. Both run instantly with no signup.
Common mistakes
| Mistake | Why it hurts |
|---|---|
Staying on p=none forever | Monitor-only never blocks anything. Spoofed mail still lands. p=none is a starting line, not a finish line — plan to reach quarantine or reject. |
No rua address | Without a reporting address you are blind. You cannot see which senders pass, so you can never safely tighten the policy. |
Record on the root instead of _dmarc | DMARC is only read at _dmarc.yourdomain. A TXT record on the bare domain is ignored, and checkers still report no DMARC record found. |
| Two DMARC records on one domain | If a domain publishes more than one DMARC TXT record, receivers apply none of them. One record per domain — edit the existing one rather than adding a second. |
| Enforcing before SPF/DKIM align | If legitimate senders do not pass and align, quarantine or reject sends your own mail to spam or refuses it. Fix authentication first, watch reports, then enforce. |
FAQ
What does "no DMARC record found" mean?
A checker looked up the DNS TXT record at _dmarc.yourdomain and got nothing back. Your domain has not published a DMARC policy, so receiving mail servers have no instruction on what to do with messages that fail SPF and DKIM. It is common, and you fix it by publishing one TXT record.
Is p=none enough to stop spoofing?
No. p=none is monitor-only. It tells receivers to take no action on failing mail and just send you reports, so spoofed messages still get delivered. It is the safe first stage to gather data, but only p=quarantine or p=reject actually instructs receivers to hold or refuse forged mail.
How long does DMARC take to work?
The record itself takes effect once DNS propagates, usually minutes to a few hours depending on your TTL. But reaching an enforcing p=reject safely takes longer: plan on roughly two to four weeks at p=none reading aggregate reports so you can confirm all of your legitimate senders pass before you tighten.
Do I need SPF and DKIM too?
Yes. DMARC does not authenticate mail on its own. It builds on SPF and DKIM and checks that at least one of them passes and is aligned with the domain in your visible From: address. If your legitimate mail does not pass and align, a strict DMARC policy will quarantine or reject your own messages, so fix SPF and DKIM before you enforce.
Sources. Tag definitions, the _dmarc location, the alignment requirement, and the single-record rule are from RFC 7489 (DMARC), the IETF specification. General deployment guidance and the staged none → quarantine → reject rollout follow the practices documented at dmarc.org. This guide explains a standard DNS configuration and is not affiliated with any mailbox provider.