No DMARC record published

CriticalConfirmedQuick winemail.dmarc.no-record

What this check looks for

Your domain does not publish a DMARC policy, so receiving mail servers have no instruction about what to do with mail that fails your other checks. Anyone can send email that appears to come from you.

Why it matters

DMARC is what turns SPF and DKIM into actual protection. Without it, forged mail from your domain is delivered normally and you get no reports telling you it is happening.

When the check passes, your report says: “DMARC tells receivers what to do with mail that fails your checks”.

What it costs your score

When this check fails it removes 25 points from your Email authentication score, before the status, confidence and repeat multipliers are applied. Email authentication carries a weight of 15 in the overall score.

It shares the email-auth.dmarc family ceiling of 40 points: however many findings that family produces, together they cannot remove more than that from Email authentication. One underlying problem showing up in several places is still one problem.

Severity: critical
Default confidence: confirmed
Status when triggered: fail
Deduction: 25 points
Family cap: email-auth.dmarc · 40
Category: Email authentication
Module: Email dmarc
Fix owned by: dns host
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Publish an enforcing DMARC record — p=quarantine, then p=reject — with an aggregate report address.

Without a record there is no policy and no reporting, so anyone can send mail as your domain and you cannot even see it happening.

Add rua=mailto:‹rua address› so receivers report on your mail; without reports you are changing policy blind.
If you already know every system that sends as ‹domain›, and each one passes SPF or DKIM in alignment, publish the enforcing record below straight away.
If you do not yet know your senders, publish the same record with p=none first and read the aggregate reports for two to four weeks. Be clear about what that step is: p=none asks receivers to take no action, so your domain stays spoofable and this scan will keep reporting it as unprotected until you move on. Treat it as a dated task, not a resting place.
Fix any legitimate sender failing alignment, then move to p=quarantine and, after two more clean weeks, to p=reject.

How to confirm it worked

dig +short TXT _dmarc.‹domain› — expect one record starting v=DMARC1 with p=quarantine or p=reject
Send a message from each of your sending systems to an external mailbox and confirm it still arrives in the inbox, not the spam folder.
Use "Test again" on this finding once the record is published.

The configuration to publish

v=DMARC1; p=quarantine; rua=mailto:{{ruaAddress}}

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

Generic DNS

_dmarc.‹domain›. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:‹rua address›"

Cloudflare

DNS → Records → Add record → Type: TXT, Name: _dmarc, Content: v=DMARC1; p=quarantine; rua=mailto:‹rua address›

Amazon Route 53

{ "Name": "_dmarc.‹domain›.", "Type": "TXT", "TTL": 3600, "ResourceRecords": [{ "Value": "\"v=DMARC1; p=quarantine; rua=mailto:‹rua address›\"" }] }

Enforcing from the start protects the domain immediately, but any legitimate sender that fails SPF and DKIM alignment will start being quarantined. If you are not certain of your sender list, publish this record with p=none for two to four weeks first — that is a monitoring step with no protection, and it is reported here as a failure until you raise it. Rollback is deleting or lowering this one TXT record; it takes effect within the TTL.
Cloudflare's dashboard only — if ‹domain› is not on Cloudflare DNS, use the generic zone-file form. Rollback is editing the same record back down.
Submit as an UPSERT in a Route 53 ChangeResourceRecordSets batch. Rollback is a second UPSERT with the previous value, or a DELETE.

Technical detail

No TXT record was found at _dmarc.‹domain›. Per RFC 9989 §4.10.1 a receiver walks up the DNS tree looking for a policy record; where the walk finds none, no DMARC processing is applied at all. Since February 2024, Google and Yahoo have required a DMARC record for domains sending bulk mail to their users.