Not receiving DMARC reports? A checklist to find out why

You published a DMARC record with a rua= address, waited a few days, and your mailbox is empty. No reports, no errors, nothing to tell you whether the record is broken or you are just early. The causes are few and easy to check once you know the order to check them in. This guide walks through the checklist, from the cheapest test (patience) to the more technical ones such as external destination authorisation, and explains what each failure looks like.

The short answer#

Missing DMARC reports are almost always one of seven things: you have not waited 24 to 48 hours yet, the record sits at the wrong DNS name, there is more than one DMARC record, the rua= value is malformed (it must start with mailto:), the report address is in another domain without authorisation, your domain sends too little mail for receivers to report on, or the mailbox filters out the compressed attachments. Check them in that order. A live lookup of _dmarc.yourdomain.com settles the first four in under a minute. dig TXT _dmarc.yourdomain.com +short is what reveals a second record, because the free SPF, DKIM and DMARC checker shows only the first one it finds and does not check the rua= syntax. If the record is clean and a few days have passed, look at the destination mailbox.

Step 1: Give it time, and know who sends reports#

Providers batch what they saw over a day and send one report per domain, so the first reports arrive 24 to 48 hours after the record is live, and sometimes later. Nothing will arrive on day one.

Two more points set expectations:

• Not every receiver sends reports. Large mailbox providers do. Many smaller ones never will. You are collecting a sample of providers, not a complete log.
• A receiver reports only if it saw mail from you. If your domain sent nothing to a given provider yesterday, that provider has nothing to report.

If you have waited three full days, move on to the record.

Step 2: Confirm the record is where it should be#

DMARC records live at one specific name: _dmarc. in front of your domain. A record published at the bare domain, or at dmarc.example.com, is ignored. Look up what is really published:

dig TXT _dmarc.example.com +short
"v=DMARC1; p=none; rua=mailto:reports@example.com"

Things to check in the answer:

• The record exists at all. Some DNS hosts want only _dmarc in the host field, not the full name. Typing the full name makes them append your domain twice. Host-specific steps are in guides such as Cloudflare and GoDaddy.
• It begins with v=DMARC1, exactly, with nothing before it.
• It includes a p= tag. Under RFC 9989 a record with no valid p= but a valid rua= is treated as p=none and still earns reports, so this is not usually the cause of missing reports, but publish the tag explicitly anyway.
• Tags are separated by semicolons.

Remember DNS caching. If you just edited the record, receivers may use the old copy until its TTL expires.

Step 3: Make sure there is only one DMARC record#

A domain must publish a single DMARC record. If two TXT records at _dmarc both start with v=DMARC1, receivers will typically ignore both, and reporting stops. This happens when someone adds a new record without deleting the old one, or when a DNS migration copies the record in twice.

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

Delete one, keep the other, and merge any addresses into a single rua= list. Multiple report destinations are separated by commas inside one record, not by publishing more records.

Step 4: Check the rua syntax#

The rua= value is a list of URIs, and each must start with mailto:. Typical mistakes:

The last row catches many people. Aggregate reports come from rua. Setting only ruf will give you close to nothing. The full tag list is in how to set up DMARC.

Step 5: Authorise reports to another domain#

This is the cause people miss most often. If your rua= address is in a different domain from the one the record protects, receivers check that the other domain agreed to receive the reports. Otherwise anyone could point report floods at a victim's mailbox.

Take this record for example.com:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:reports@thirdparty.example.net"

Because the address is outside example.com, the receiving domain must publish an authorisation record with a name built from your domain:

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

If that TXT record does not exist, conforming receivers drop the report. You can verify it with:

dig TXT example.com._report._dmarc.thirdparty.example.net +short

Two practical notes:

• If you control both domains, simply add the authorisation record at the destination. If a vendor receives reports for you, the vendor normally publishes this for you or tells you to.
• Sending reports to a mailbox in your own domain avoids the check completely, which is why a simple dmarc@yourdomain.com forward is the least fragile setup.

Step 6: Check the destination mailbox#

If the record is valid and the authorisation is in place, the reports may be arriving and getting lost:

• Attachment filtering. Reports arrive as .gz or .zip attachments, sometimes bare XML. Mail filters that strip compressed attachments will silently drop them. Check spam, quarantine and any rule that deletes archives.
• Full mailbox. A busy domain can produce dozens of reports a day. A small shared mailbox fills quickly and starts rejecting them.
• Alias or forward that rewrites. A group alias that blocks external senders will refuse reports from providers.

Search for subjects that include "Report Domain" and the name of your domain. If you see none after checking filtering, the problem is upstream.

A dedicated mailbox, or a service that receives the reports for you, avoids most of these. Raw XML in a personal inbox also buries signal, as covered in how to read DMARC reports.

If you use a Qualisend report address#

If your rua= points at a <key>@dmarc.qualisend.com address from DMARC Reports, the destination checks are handled for you. Qualisend publishes a wildcard authorisation record, so providers will send to that address for any domain, and you do not add the authorisation record from step 5. These are the extra things that can still block data:

• The domain is not covered. Reports are stored only for domains with coverage switched on in your workspace, or a subdomain of one. A report for an uncovered domain is accepted but not saved, so the dashboard stays empty.
• The subscription is not active. Reports sent to an address whose workspace has no active DMARC subscription are refused.
• The address was rotated. After a rotation the old address stops accepting mail at once, so every rua= that still lists it will lose reports until you update DNS.
• The record does not list the address. If a DMARC record already exists, add ,mailto:<address> to its rua= list and keep the policy and other addresses.

Qualisend never edits your DNS. The record change is yours to make at your DNS host. The page tells you first reports usually arrive within 24 to 48 hours, which matches what providers do.

Subdomains and the record that wins#

If the missing reports are for a subdomain, look at what is actually published there. A subdomain with its own DMARC record uses that record, and if that record has no rua=, nothing is sent to the parent's address. A subdomain with no record falls back to the parent domain's record and its sp= policy. Reports will name the domain in the policy, so look for them under that name rather than your main domain.

It is worth running the whole domain through a domain health check after any DNS change. It flags a missing DMARC record, a record with no policy tag and a p=none policy, and shows the published record so you can read the rua= value yourself. Paid domain health monitoring also warns when a valid policy has no rua= at all. If this keeps happening after DNS edits, the domain health monitoring guide explains how to catch it before reports stop.

A final checklist#

• Wait 48 hours after the record is live.
• Run dig TXT _dmarc.yourdomain.com and read the result.
• Confirm one record, starting v=DMARC1, with an explicit p=.
• Confirm rua=mailto: with commas between addresses.
• If the address is in another domain, verify the _report._dmarc authorisation record.
• Check spam, quarantine, size limits and filters on the destination mailbox.
• Make sure the domain actually sent mail to providers that report.

When reports finally arrive, the next job is understanding them, which is covered in DMARC monitoring and who is sending as your domain.

Getting DMARC reports flowing shows you who sends as your domain, but not whether your list is clean. If you want to check the list next, the free plan on the pricing page gives you 100 credits for the full verification, and the free email checker handles single addresses. Working authentication still needs a healthy list to earn the inbox.