Why aren't my DMARC reports arriving?

You added rua= to your DMARC record days ago, and the reporting mailbox is still empty. That silence is a symptom, not a verdict: DMARC reporting fails quietly, with no bounce or error to tell you what went wrong. This guide walks through every common cause in the order worth checking, with the exact DNS lookups and fixes for each.

If you are setting up reporting for the first time, read DMARC rua and ruf reporting addresses first. This page is for when that setup doesn't produce reports.

Why am I not receiving DMARC reports?

You are not receiving DMARC reports because something between your DNS record and your inbox is silently dropping them. In practice the cause is one of five things: the record itself is invalid or missing a usable rua address, there are two DMARC records, an outside report address hasn't authorized your domain, the mailbox or spam filter is discarding the reports, or the receivers you mail simply don't send reports.

Here is the quick map from symptom to cause:

How long do DMARC reports take to arrive?

Expect the first DMARC aggregate reports one to two days after you publish a valid rua address. That estimate follows from how reporting periods work: RFC 9990, section 3.1.1.4 says that "typically, the reporting period will encompass a single UTC day, beginning at 0000UTC". A receiver collects results for that whole day and sends the report after the day closes.

Microsoft Learn describes its own reports the same way: they "are typically sent once per day (the report contains the DMARC results from the previous day)". Google's About DMARC reports page says "DMARC reports are usually sent once a day by email."

So if you publish rua at 3 p.m. on Monday, the first full reporting day may be Tuesday (UTC), and the report may not reach you until Wednesday. DNS caching adds to this. A receiver that cached your old record keeps using it until the record's TTL expires. Wait at least two full days of normal sending before you troubleshoot.

Is my DMARC record actually valid?

Your DMARC record is valid only if it is one TXT record, at exactly _dmarc.yourdomain, that starts with v=DMARC1 and contains at least one mailto: address in rua. Any one of those failing can stop reports completely, and nothing warns you. Check each part below.

Look the record up the way receivers do

Run one of these, replacing example.com with your domain:

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com
Resolve-DnsName -Name _dmarc.example.com -Type TXT

The last line is the PowerShell command Microsoft uses in its own troubleshooting steps. You should see exactly one answer, for example:

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

If you get nothing, the record isn't where receivers look. The most common reason is a doubled name. Many DNS hosts add your domain to whatever you type in the host field, so entering _dmarc.example.com creates _dmarc.example.com.example.com. Enter just _dmarc in that field. Google's Set up DMARC page gives the full name as _dmarc.example.com; your host's form may want only the first part.

Check for two DMARC records

If the lookup returns two strings that both begin with v=DMARC1, receivers ignore both. RFC 9989, section 4.10 is blunt: "If multiple DMARC Policy Records are returned for a single target, they are all discarded." With no usable record, receivers "MUST NOT apply the DMARC mechanism", which means no policy and no reports. (For a subdomain, the receiver then falls back to the parent domain's record.)

This often happens when a reporting service and an admin each add a record, or when an old record is left behind after a provider change. Merge the tags you want into one record and delete the other.

Check the tag syntax

These mistakes each break reporting:

• v=DMARC1 isn't first. RFC 9989 section 4.7 says the v tag "MUST be the first tag in the list", and if it isn't, "the entire record MUST be ignored."
• No mailto:. rua=dmarc@example.com is not a URI. Receivers must support mailto: and ignore schemes they don't support, so a bare address gets nothing.
• A semicolon between addresses. rua=mailto:a@example.com; mailto:b@example.com makes the second address look like a broken tag. Separate addresses with a comma.
• A typo in the tag name. rau= or rus= is an unknown tag, and RFC 9989 section 4.8 says "Unknown tags MUST be ignored."
• Curly quotes or stray spaces pasted from a document. Type the record into your DNS host's form as plain text.

Here is an example of a broken record and its fix:

Broken:  "p=none; v=DMARC1; rua=dmarc@example.com; mailto:ops@example.com"
Fixed:   "v=DMARC1; p=none; rua=mailto:dmarc@example.com,mailto:ops@example.com"

The DMARC Checker parses the record the way receivers do and flags each of these problems. The DMARC Record Generator writes a clean record if you'd rather start again.

What about an invalid policy value?

A bad p= value doesn't always stop reports. RFC 9989 section 4.10.1 says that if the policy is invalid but rua contains at least one valid URI, the receiver "MUST act as if a record containing "p=none" was retrieved." So p=rejet still gets you reports, but no enforcement. Fix it anyway, because you are getting less protection than you think.

Are reports being sent to an address on another domain?

If your rua address is on a different organizational domain from the one you are monitoring, the destination domain must publish an authorization record, or receivers silently skip it. This is the most common cause when reports go to a reporting service or to a mailbox on a sister company's domain.

The check is defined in RFC 9990, section 4. For example.com sending reports to dmarc@example.net, the receiver looks up:

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

It expects an answer that starts with v=DMARC1. If verification fails, RFC 9990 says "the URI MUST be ignored by the Mail Receiver generating the report." Microsoft's troubleshooting table lists this exact case under "Aggregate reports not being received".

Three things to know:

1. The destination publishes the record, not you. If you use a reporting service, it must add the record for your domain, often automatically when you add the domain to your account.
2. Each monitored domain needs coverage. The name includes your domain, so example.com and example.org need separate records, unless the destination publishes a wildcard such as *._report._dmarc.example.net.
3. Subdomains of your own domain don't need it. dmarc@reports.example.com shares the organizational domain example.com, so no authorization record is required.

iBlockSpam's DMARC monitoring handles this for you: you switch monitoring on for the domain in the portal first, which publishes the authorization, and then add rua=mailto:dmarc@iblockspam.com to your record.

Is the reporting mailbox rejecting or filtering the reports?

Reports that leave the receiver can still die at your end: the mailbox may not exist, may be full, or your spam filter may quarantine the reports or strip their attachments. Check the mailbox side before you assume receivers aren't sending.

The address must be able to receive mail

Send a normal test email to the rua address from an outside account. If it bounces, fix that first. Check that the address exists, that a shared mailbox or group accepts mail from external senders, and that the domain of the address has working MX records. RFC 9990 section 3.5 allows a receiver whose delivery fails to retry later or simply discard the data, so a mailbox that was broken for a week can mean a week of reports that are gone for good.

Size can matter too. A large organization's reports are compressed XML, and RFC 9990 notes that delivery "potentially encounters a problem when feedback data size exceeds maximum allowable attachment sizes." Very small mailbox quotas fill quickly: Google warns that "large organizations might get up to hundreds or even thousands of reports daily."

Your own spam filter may be holding them

Aggregate reports are automated messages with an XML attachment that is usually gzip compressed. RFC 9990 section 3.5.2 requires the extension to be xml or xml.gz, though in practice you may also see .zip files. An attachment-type filter that blocks compressed files, or a bulk-mail rule that quarantines automated messages, will catch them.

Look in the quarantine for messages whose subject starts with "Report Domain:", the format RFC 9990 requires. If you find them, release them and add an exception for the reporting address. RFC 9990 says report mail "MUST conform to the DMARC mechanism", meaning it must get an aligned DMARC pass itself, so you can safely allow authenticated report senders rather than turning off the attachment rule. With iBlockSpam, held messages appear in the quarantine and digest emails, and you can add the report senders to an allow list.

Rules and forwarding

Check mailbox rules that move automated mail, and auto-forwarding that sends reports to an address nobody reads. Both Google and Microsoft recommend a dedicated mailbox or group for reports rather than a person's inbox. Microsoft's advice is to "use a specific mailbox or Microsoft 365 Group to receive the DMARC reports (don't deliver the reports to a user's mailbox)."

Do the receivers I email actually send reports?

Not every receiver sends DMARC reports, so a quiet mailbox can be correct. You only get a report from a receiver that received mail claiming to be from your domain and that chooses to report. If you send a few messages a week to small companies running their own servers, you may get very few.

A few patterns are worth knowing, at the time of writing (November 2026):

• Microsoft 365 reports only for direct MX. Microsoft Learn says Microsoft 365 sends aggregate reports "as long as the MX record for the Microsoft 365 domain points directly to Microsoft 365." Microsoft adds that if a tenant routes internet mail through a non-Microsoft service or device first, or delivers to an on-premises server before Microsoft 365 in a hybrid setup, "DMARC Aggregate reports aren't sent." This is about mail that Microsoft 365 receives from you.
• Microsoft doesn't send failure reports. "Microsoft 365 doesn't send DMARC Forensic reports (also known as DMARC Failure reports), even if a valid ruf=mailto: address exists." It isn't alone: RFC 9991, section 7 says "many large-scale providers limit or entirely disable the generation of failure reports, preferring to rely on aggregate reports."
• Coverage is partial. Microsoft sets expectations plainly: "Not all receivers send reports. Coverage is typically 70-90% of total mail volume."
• Volume follows your sending. Microsoft notes that report volume varies with the volume of mail you send, so holidays and quiet weeks produce fewer reports.

To confirm reporting works at all, send a few messages from your domain to a Gmail address you control, then wait two days. Google says its DMARC reports are usually sent once a day, so if no Google report arrives after normal sending, the problem is most likely on your side.

Why do reports arrive for my main domain but not a subdomain?

Reports for a subdomain go to the rua in the first DMARC record found for that subdomain. Under RFC 9989, section 4.10.1, receivers query _dmarc at the exact From domain first, and only walk up the DNS tree to a parent if nothing is found there.

That creates a trap. If news.example.com publishes its own record, perhaps added by a marketing platform as v=DMARC1; p=none, receivers use it instead of the parent's. With no rua in it, mail from that subdomain generates no aggregate reports. RFC 9990 also requires a separate report for each policy domain, so even when a subdomain's record has its own rua, those reports arrive separately from the parent domain's.

Check every subdomain you send from:

dig +short TXT _dmarc.news.example.com

Either add rua to the subdomain's record or delete the subdomain's record so it inherits the parent's. Microsoft notes that subdomains inherit the parent's DMARC record until you create one in the subdomain.

How do I troubleshoot missing DMARC reports step by step?

Work through this checklist in order. Each step rules out one cause.

1. Wait two full days after publishing or changing rua, with normal mail flowing.
2. Look up _dmarc.yourdomain with dig, nslookup or Resolve-DnsName. Confirm exactly one record, starting with v=DMARC1.
3. Check the rua value: every address starts with mailto:, and multiple addresses are separated by commas.
4. Check for a doubled name such as _dmarc.example.com.example.com in your DNS host, and delete it.
5. If the address is on another domain, look up yourdomain._report._dmarc.otherdomain and confirm it returns v=DMARC1.
6. Send a test email to the report address from an outside account and confirm it arrives.
7. Search quarantine and junk for subjects beginning "Report Domain:" and release any you find.
8. Allow the report senders and .xml.gz/.zip attachments for that one mailbox.
9. Check each sending subdomain for its own DMARC record without rua.
10. Send test mail to a Gmail address, wait two days, and look for Google's report.
11. Once reports arrive, open them in the DMARC Report Analyzer and follow how to read DMARC reports.

Next steps

• Run the DMARC Checker on your domain, or an Email Health Check to see DMARC alongside SPF, DKIM and MX.
• When reports start flowing, use them to find every legitimate sender. Unfamiliar sources are explained in unknown sources in DMARC reports.
• Then plan the move to enforcement with DMARC from p=none to p=reject.
• If you'd rather not run a report mailbox at all, iBlockSpam's DMARC monitoring collects the aggregate reports for you and shows who sends as your domain. Its counts come only from receivers that report.

Browse our other SPF, DKIM and DMARC guides.