Back to ResourcesEmail Authentication

How to Fix "No DMARC Record Found"

By Taylor TabusaAugust 9, 2023Updated July 29, 20268 min read

In brief

Fix the 'No DMARC record found' warning: create and publish a DMARC TXT record in DNS, then verify it — a step-by-step guide with examples.

How to Fix "No DMARC Record Found"

"No DMARC record found" means your domain has no DMARC policy published in DNS. The fix is a single step: add one TXT record at _dmarc.yourdomain.com with the value v=DMARC1; p=none; rua=mailto:you@yourdomain.com. Once DNS propagates, the warning clears and receiving servers start sending you authentication reports. This guide walks through publishing the record, choosing the right policy, and verifying it.

Checkers phrase the same problem several ways. If you have seen any of these, you are missing a DMARC record:

  • No DMARC record found
  • DMARC record is missing
  • No DMARC record published
  • DMARC policy not enabled
  • Unable to find DMARC record
All of them mean the same thing: your domain has not published a DMARC policy, so mailbox providers have no instructions for what to do with mail that fails authentication. DMARC — Domain-based Message Authentication, Reporting, and Conformance — is the standard that ties SPF and DKIM together and lets you tell receivers to monitor, quarantine, or reject unauthenticated mail sent in your name.

Why "No DMARC record found" appears

A DMARC record is a TXT record published at the special host _dmarc.. A checker reports "No DMARC record found" whenever it queries that host and gets nothing back. In practice the cause is almost always one of these:

  • You have never published a record. The most common case — DMARC is not on by default at any registrar or mailbox provider, so a brand-new domain has no policy until you add one.
  • The record is at the wrong host. It must live at _dmarc.yourdomain.com, not at the root domain and not at dmarc.yourdomain.com (no underscore).
  • DNS has not propagated yet. A record you added minutes ago may not be visible everywhere until the old cache entry expires.
Leaving the warning unfixed is not cosmetic. Without a published policy, anyone can spoof your exact domain in phishing and Business Email Compromise (BEC) attacks, and you get zero visibility into who is doing it. Publishing DMARC is also now a hard requirement for bulk senders to Gmail and Yahoo, so an unauthenticated domain risks having legitimate mail throttled or blocked.

How to fix it: publish a DMARC record

To clear the warning, publish a DMARC TXT record in your domain's DNS. The record lives at _dmarc.yourdomain.com, where yourdomain.com is your actual domain.

Example DMARC DNS record: a TXT record at _dmarc.yourdomain.com containing v=DMARC1; p=none; rua=mailto:xyz@yourdomain.com. Replace yourdomain.com with your domain; choose p=none, p=quarantine, or p=reject.
  1. Sign in to your DNS host — the registrar or provider where your domain's DNS is managed (for example Cloudflare, GoDaddy, or Route 53). If you are on Cloudflare, follow our step-by-step Cloudflare walkthrough.
  2. Create a new TXT record. Set the host / name to _dmarc (most panels append your domain automatically, giving _dmarc.yourdomain.com).
  3. Set the value to v=DMARC1; p=none; rua=mailto:you@yourdomain.com. Use a mailbox you actually monitor for the rua address.
  4. Save and wait for propagation. Changes usually appear within minutes but can take up to a few hours depending on your record's TTL.
The value string is built from tags. The essentials are:
  • v=DMARC1 — the version. It is mandatory and must come first.
  • p=none — the policy: what receivers should do with mail that fails checks. Start at none to observe without affecting delivery.
  • rua=mailto:... — where aggregate reports are sent. Without it you get no data, which defeats the purpose.
For a full breakdown of every tag, including sp, pct, adkim, and aspf, see our guide to creating a DMARC record.

Choose the right policy: none, quarantine, or reject

The p tag decides what a receiving server does with mail that fails DMARC. Move through the three levels in order — do not jump straight to reject:

  • p=none (monitor). Nothing changes for delivery; receivers just send you reports. This is where every domain should start, so you can inventory every legitimate sender before you enforce.
  • p=quarantine. Failing mail is delivered to spam/junk. A safe middle step once your reports show legitimate senders passing.
  • p=reject. Failing mail is blocked outright. This is full enforcement and the only policy that actually stops exact-domain spoofing.
The difference between the two enforcement levels — and when to graduate from one to the next — is covered in DMARC reject vs quarantine. The key rule: never enforce until your aggregate reports confirm every real sender (your mail platform, marketing tools, invoicing apps) is authenticated, or you will send your own mail to spam.

Validate and monitor your DMARC record

Publishing the record is step one; confirming it is correct is step two. A record with a typo — a missing semicolon, a policy of p=nome, or an rua pointing at a dead mailbox — can read as present but do nothing useful. Run your domain through the free DMARC checker or the Email Security Score to confirm the record parses and to see your SPF and DKIM status alongside it.

Once the record is live and valid, the reports start arriving. DMARC produces two kinds:

Side-by-side comparison of DMARC aggregate (RUA) reports and forensic (RUF) reports. RUA reports summarize authentication results; RUF reports detail individual messages.
  • Aggregate reports (rua) are daily XML summaries of every source sending mail as your domain, with pass/fail counts. They are how you find unauthorized senders and confirm your own are aligned. Reading raw XML is painful, so most teams use a tool that turns it into charts — see how to understand DMARC reports.
  • Forensic reports (ruf) are per-message samples of individual failures. They are far less widely supported and can carry sensitive header data, so many domains skip them and rely on aggregate data alone.

Common issues with DMARC records

Why does my checker still say "No DMARC record found" after I added the record?

Usually DNS propagation or a placement mistake. Confirm the record is at _dmarc.yourdomain.com (with the underscore), not the root domain, and that your panel didn't double-append the domain to make _dmarc.yourdomain.com.yourdomain.com. If placement is right, wait for the TTL to expire and re-check; if it lingers, flush your DNS cache or test from a different network.

Can I have two DMARC records on one domain?

No. A domain must have exactly one DMARC record. Publishing a second one is invalid and most receivers will ignore your policy entirely, effectively leaving you unprotected. If you find duplicates — common after migrating providers — delete all but the single correct record.

My mail started going to spam after I published DMARC. What happened?

You almost certainly moved to p=quarantine or p=reject before every legitimate sender was authenticated. Drop back to p=none, read your aggregate reports to find which senders are failing SPF or DKIM alignment, fix those (add them to SPF, enable DKIM signing), and only re-enforce once the reports are clean.

Does the rua address have to be on the same domain?

Not necessarily, but if you send reports to a different domain (for example a monitoring service), that domain must publish an external-reporting authorization record. Missing that record is why some third-party addresses never receive data. Sending rua to a mailbox on your own domain avoids the extra step.

Questions readers ask

Frequently asked questions

Turn DMARC findings into a managed fix path

Start in Palisade.

Get started

Share this article

Taylor Tabusa

Written by

Taylor Tabusa

Co-Founder & Head of Business Development, Palisade

Taylor Tabusa is the co-founder and Head of Business Development at Palisade, helping managed service providers turn email security into a practical, valuable service.

More from Taylor

Related articles