No DMARC record found: the one line your domain is missing

In short

• The message means there is no TXT record at _dmarc.yourdomain.com. Your mail server is not broken.
• Add one TXT record with the host _dmarc and the value v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. With p=none, delivery stays exactly as it was.
• Gmail, Yahoo and Outlook.com require the record only from bulk senders. Add it anyway: Google counts a whole domain and never lifts the bulk status, and reports only start once a record exists.
• If a checker still finds nothing, look for the wrong DNS host, a doubled host name, or two DMARC records. Two records cancel each other out.
• The standard changed in May 2026 with RFC 9989: pct is gone, t and np are new. Google's help still describes pct as of October 2026.

“No DMARC record found” means that a checker asked the DNS for a TXT record at _dmarc.yourdomain.com and got nothing back. Nothing is broken on your mail server. The fix is one TXT record with the host _dmarc and the value v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. With p=none your mail is delivered exactly as before. You only tell receivers that you take part, and you start getting reports.

DMARC is the third of the three email records, next to SPF and DKIM. SPF lists the servers that may send for your domain. DKIM signs each message. DMARC tells a receiver what to do when neither of the two vouches for the domain in your From address, and where to send a daily summary. Since May 2026 it is defined in RFC 9989, which replaced the older RFC 7489. Many guides still describe the older version, and so does Google's help page as of October 2026.

The record to add

Log in where the DNS of your domain is managed. That is the company your nameservers point to, which is not always the one you bought the domain from. Add a new record with these values:

Written out as a line in a zone file, the finished record looks like this:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Replace example.com with your own domain. The three parts do this:

• v=DMARC1 marks the line as a DMARC record. It has to come first, with DMARC1 in capitals. If it does not, receivers ignore the whole record.
• p=none is the policy: treat my mail as you would anyway. Nothing is blocked or moved to spam because of this record.
• rua=mailto:… is the address for the daily reports. Create that address, or an alias that forwards to you, before you publish the record.

Google lists the same three fields in Set up DMARC. It also asks that SPF and DKIM have been working for 48 hours before you add DMARC. If your checker flags those two as well, fix them first.

How to check that it worked

Ask the DNS yourself. On macOS or Linux, open a terminal and use dig. On Windows, use nslookup.

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

If the record is live, the line comes back in quotes. This is what Google's own domain answered on 5 October 2026:

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

An empty answer means the record is not there yet, or not where receivers look for it. Once your own query shows the line, run the checker that gave you the message again. MXToolbox, for example, words the problem as “No DMARC Record found” and explains that “your domain does not have a published DMARC record”.

What each part of a DMARC record means

A record is a list of tag=value pairs separated by semicolons. Only v is mandatory in the standard, and it must be first. Put p second: Google's help states that “The v and p tags must be listed first”, and the older standard expected the same order. These are the tags of RFC 9989, section 4.7:

Older records often end in pct=100. The tag was meant to apply a policy to a share of the failing mail. RFC 9989 removed it, together with rf and ri, and gives the reason:

Operational experience showed that the "pct" tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another.

Receivers have to ignore tags they do not know, so an old pct=100 does no harm. The records of yahoo.com and microsoft.com still carried it on 5 October 2026, and Google's help page still recommends pct for a gradual rollout. In a new record, leave it out.

Do you need DMARC if you send only a few emails a day?

By the published rules of the large mailbox providers, a DMARC record is required once you send in bulk. Below that it is a recommendation.

The sources are Google's Email sender guidelines, Yahoo's Sender Best Practices and Microsoft's announcement for high-volume senders, all as of October 2026. If you send thirty emails a day from one mailbox, none of them demands the record. There are still three reasons to add it now.

• The threshold is counted per domain, and it does not reset. Google adds up all messages to personal Gmail accounts that come from the same primary domain, subdomains included. Its sender FAQ says: “Senders who meet the above criteria at least once are permanently considered bulk senders.”
• Both Google and Yahoo recommend it for everyone. Google writes that “we recommend that you always set up SPF, DKIM, and DMARC for your domains”. Yahoo “strongly urges all senders to publish a DMARC policy for each domain that sends mail”.
• Without the record you get no reports. They are how you see which servers send mail with your domain in the From line, your own tools and strangers alike.

For bulk senders the missing record has consequences. Google's sender FAQ lists the temporary error 4.7.31 for it: “the sending domain doesn’t have a DMARC record, or the DMARC record doesn’t specify a DMARC policy”. The same page says that since November 2025 mail that does not meet the requirements faces “temporary and permanent rejections”.

Added the record, and the checker still finds nothing?

Then one of these is usually the cause. Go through them with the dig query from above.

• You edited the DNS in the wrong place. If your nameservers are with a different company than your registrar, records entered at the registrar are never queried. dig +short NS example.com shows who answers for your domain.
• The host is wrong. The record sits on example.com itself, or on a doubled name, as described above. Receivers only ask for _dmarc.example.com.
• There are two DMARC records. The standard is strict here: “If multiple DMARC Policy Records are returned for a single target, they are all discarded.” Merge them into one. Two report addresses go into one rua, separated by a comma.
• The first tag is not exactly v=DMARC1. Lower case, a typo such as DMARC 1, or p= in front of it make the record invalid.
• The record type is not TXT, or the value was pasted with curly quotes from a document. Type the value as plain text, without quotes unless the help of your DNS host asks for them.
• An old answer is still cached. Resolvers remember “no such record” for a while. Ask one of your own nameservers directly by adding its name to the query, for example dig +short TXT _dmarc.example.com @ns1.example.net. If the record shows there, the checkers will follow.

Where the reports go, and what to do with them

Every receiver that got mail with your domain in the From line sends a report to the rua address. According to Google's page About DMARC reports they are “usually sent once a day by email”. The report is an XML file, usually compressed, attached to an email. RFC 9990 describes the format.

Google warns that large organisations “might get up to hundreds or even thousands of reports daily” and recommends a group or a dedicated mailbox. The number depends on how much you send and to how many domains, so one or two mailboxes produce far fewer. An alias such as dmarc@ with a filter into its own folder is enough.

The address should be on the same domain as the record. If you want the reports somewhere else, the other domain has to agree by publishing a record of its own. Without it, receivers must ignore the address (RFC 9990, section 4).

example.com._report._dmarc.otherdomain.net.  IN  TXT  "v=DMARC1;"

This is why a free Gmail address does not work as a report address: gmail.com published no such record when we checked on 5 October 2026.

In the file, each record block stands for one sending server: its IP address, the number of messages, and under policy_evaluated whether DKIM and SPF passed for your domain. You are looking for two things. Servers you know that show fail need fixing, and DMARC fails although SPF and DKIM pass explains how. Servers you do not know are either a tool you forgot or someone using your name.

After p=none: when to tighten the policy

p=none is a monitoring mode. It meets the minimum the mailbox providers ask for, and it does not stop anyone from forging your address. Only p=quarantine, which asks receivers to treat failing mail as suspicious, and p=reject, which asks them to refuse it, do that.

Before you tighten, every legitimate source of your mail has to pass. RFC 9989 says that such gaps “MUST be addressed prior to any attempt” to enforce, and that, depending on how often you send, it “may take many months” of reports to be sure. Google's rollout page finds one week of reports “usually enough”. With one mailbox and one or two tools you are closer to Google's figure, but give it a few weeks so that the monthly invoice run and the contact form show up as well.

For the step itself the two sources disagree. Google still suggests p=quarantine; pct=5 and raising the number. The standard has dropped pct and offers this instead:

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=y asks receivers to treat failures one level lower for now, that is, as none. When the reports stay clean, remove t=y. Be aware that a receiver which does not know the tag ignores it and applies quarantine in full, and that Google's pages do not mention t as of October 2026. If a stricter policy would hit mail you cannot fix yet, stay on p=none.

Where WarmupBay comes in

When you connect a mailbox, WarmupBay checks SPF, DKIM and DMARC for its domain. If the DMARC record is missing, it shows you a finished one to copy. You can start the warmup anyway. If the records are still missing after 72 hours, the warmup stops.

WarmupBay cannot add the record for you, since your DNS is yours, and it does not collect or read DMARC reports. What it does is the step after the records: your mailbox exchanges a few emails a day with other mailboxes in a shared pool, starting at three and rising by one a day, so that sending activity builds up gradually. It is free for 10 emails a day. See what the check and the warmup cover, or connect your mailbox once the record is in place.

Questions people ask

Does a DMARC record on example.com also cover subdomains such as news.example.com?

Yes. A receiver first asks for a record at _dmarc.news.example.com. If there is none, it falls back to the record of the organizational domain, example.com. The policy applied to the subdomain is the one in sp if you set it, otherwise the one in p.

Can I publish v=DMARC1; p=none without a rua address?

Yes. That is a valid record, and it counts as a published policy. You will get no reports, so you will not see whether your own mail passes or who else uses your domain. Yahoo calls a working rua address strongly recommended, and Google recommends always including one.

Do I need a DMARC record for a second domain that I only use for outreach?

Yes. Receivers look up the domain in the From address of each message, so a record on your main domain does not cover a different domain. Use the same line on the second domain. If its reports should go to an address on your main domain, the main domain has to publish the authorisation record described under Where the reports go.

What should a domain publish that never sends email?

The strict pair. M3AAWG recommends the SPF record v=spf1 -all and a DMARC record with p=reject for domains that never send mail, so that nobody can use them in a From address. For DMARC that is the line v=DMARC1; p=reject at _dmarc.

Is p=none worse for my mail than p=quarantine or p=reject?

The published sender rules of Gmail, Yahoo and Outlook.com ask for at least p=none and nothing stricter. The policy decides what happens to mail that fails DMARC, which includes forged mail in your name. One feature needs more: BIMI, the logo next to your messages, requires quarantine or reject according to Google's help.

Sources

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. Email sender guidelines – Gmail Help
4. Email sender guidelines FAQ – Gmail Help
5. Set up DMARC – Google Workspace Help
6. Recommended DMARC rollout – Google Workspace Help
7. About DMARC reports – Google Workspace Help
8. Troubleshoot DMARC issues – Google Workspace Help
9. Sender Best Practices – Yahoo Sender Hub
10. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
11. DMARC Record Published – MXToolbox
12. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)
13. M3AAWG Protecting Parked Domains Best Common Practices, December 2015 (PDF)