"No DMARC record found": causes, what receivers do, and the record to publish

"No DMARC record found" is one of the most common findings on a prospect scan, and one of the easiest to fix. It's also not always literally true. Sometimes there is a record, but it's broken in a way that leaves receivers treating the domain as if it had none. This page covers what RFC 9989 says receivers do, the causes beyond "nobody published one," and a safe first record.

What receivers do when there's no record

DMARC policy discovery (RFC 9989 §4.10.1) starts with a TXT query at _dmarc. plus the From: domain. If it doesn't find a valid record there, it walks up the DNS tree to the Organizational Domain (and, where relevant, a public suffix domain). If that walk finds nothing, RFC 9989 says:

> Mail Receivers MUST NOT apply the DMARC mechanism to the message.

So with no record:

• Receivers don't apply DMARC to the domain at all. Spoofed mail using the client's exact domain is judged only by the receiver's other filters.
• Receivers send no reports. Aggregate reports go to the rua address in the record, so without a record there's no address, and no visibility.
• Some senders get flagged. Google's sender guidelines require senders of more than 5,000 messages a day to Gmail accounts to publish DMARC for their sending domain, though "Your DMARC enforcement policy can be set to none." Mailchimp Transactional also says a DMARC policy is required to send.

Cause 1: there really isn't one

Check _dmarc.client.com for a TXT record. A common mistake is publishing it at the apex (client.com) instead of at _dmarc.client.com. A DMARC record at the apex is just an unrelated TXT record.

Cause 2: two records at _dmarc

RFC 9989 §4.10, step 2: "If multiple DMARC Policy Records are returned for a single target, they are all discarded." Two v=DMARC1 records at _dmarc.client.com, often one from the MSP and one added by a DMARC reporting vendor or a marketing tool's setup wizard, cancel each other out. The domain then behaves as if it has no DMARC record, and checkers that follow the RFC say so.

Fix: merge them into one record. If a vendor needs reports, add its address to the existing rua list. RFC 9989 allows a comma-separated list of URIs.

Cause 3: the v= tag is wrong or not first

RFC 9989 §4.7: v "MUST be the first tag in the list," its value is case-sensitive, and the only valid value is DMARC1. If v isn't first, is missing, or isn't exactly DMARC1, "the entire record MUST be ignored." Records starting v=dmarc1, p=none; v=DMARC1, or v=DMARC 1 don't count.

Cause 4: a record with no usable p= tag

This one is subtler. RFC 9989 §4.10.1 says that if a record has no valid p tag (or an invalid sp or np tag), then:

• if it has a rua tag with at least one valid reporting URI, the receiver "MUST act as if a record containing 'p=none' was retrieved"
• otherwise, "the Mail Receiver applies no DMARC processing to this message."

So v=DMARC1; rua=mailto:dmarc@client.com works as a monitoring-only record. But v=DMARC1; p=nonne with no rua is, in effect, no DMARC at all.

Cause 5: a DNS error, not a missing record

A timeout or SERVFAIL isn't the same as "no record." RFC 9989 leaves handling of DNS errors to the receiver. A receiver might deliver the message ("fail open") or temporarily reject it so the sender retries. A good checker reports a DNS error as unknown, not as missing. If a scan says "not found" but you can see the record, query it again from a different resolver, and check the zone's DNSSEC status and its name server health.

Subdomains: inherited, not missing

news.client.com usually doesn't need its own record. If _dmarc.news.client.com doesn't exist, discovery walks up to client.com's record, and the subdomain gets the sp policy if one is set, otherwise p (§4.10.1). HubSpot's documentation uses this inheritance: a subdomain counts as authenticated if the root domain has a DMARC record. A tool that checks only the exact name and reports "no record" for a subdomain may be wrong.

A safe first record

For a domain with no DMARC record, start in monitoring mode with reporting:

```

_dmarc.client.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@client.com"

```

• p=none asks receivers not to change how they handle mail. RFC 9989 says such policies "MUST NOT modify existing mail handling processes," so this is safe to publish on day one.
• rua turns on aggregate reports. Without it, receivers "MUST NOT generate aggregate feedback reports."
• If the reports go to a mailbox on another domain, such as a DMARC reporting service, that domain has to publish an authorization record at client.com._report._dmarc.<their-domain> (RFC 9990). Reputable reporting services handle this for you.
• Leave out pct. RFC 9989 removed it, and it's historic. If you later want a testing step on the way to enforcement, RFC 9989 provides t=y, which asks receivers to apply one level below the stated policy.

Then use the reports to find and fix unaligned senders before you move to p=quarantine and p=reject.

Check the domain's DMARC record now

Run the free DMARC checker →

It looks up _dmarc, follows CNAMEs, parses p= and rua, flags duplicate records, reports timeouts as Unknown rather than "no DMARC," and gives you the next record to publish.

Founding Partner: $1,999, one time. Show prospects their missing DMARC record in a branded Security Brief, then fix it as the first billable step. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.

See Founding Partner details →