dmarc external report destination not verified: rua reports silently dropped

TL;DR

Publish the verification record that authorises the other domain to receive your reports: at the domain that owns the rua mailbox, add the DMARC external destination verification TXT record for your domain, then wait a reporting cycle. Reporting receivers check for that permission before sending aggregate reports to a third party address, and without it they silently drop the reports, which looks exactly like a reporting outage.

dmarc external report destination not verified: rua reports silently dropped

Use this when

• Your DMARC rua points at a mailbox or service on a different domain.
• Reports from major receivers stopped, or never started, while DMARC itself passes.
• The report provider says it sees no volume for your domain.

Not for this skill when

• The rua mailbox is on your own domain and mail to it bounces. That is a mailbox problem, not external verification.
• You use a report service subdomain delegated from your domain. Check their specific setup instead.

Steps

1. Confirm the exact rua value in your DMARC record and identify the domain that receives the reports. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the receiving domain for aggregate reports is confirmed from the live record
2. Check for the external destination verification record: query TXT for your domain name under the _dmarc subdomain of the receiving domain. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the query either returns the expected v=DMARC1 record or confirms it is missing
3. Add the missing verification record at the receiving domain DNS, with help from whoever controls that zone, usually the report service. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: an external lookup returns the verification record with the right name and value
4. Wait at least one full reporting interval, normally 24 hours, and check the provider inbox for new reports. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: fresh aggregate reports from major receivers start arriving
5. Send nothing else changing DMARC in the same window, and note the fix date so the reporting gap is explained in your records. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the gap period and the fix date are recorded with the DMARC change log

Why it happens

Aggregate reports contain sending data for your domain, so receivers will not send them to an unrelated domain on the strength of your rua tag alone. The specification requires the receiving domain to publish a record saying it accepts reports for your domain. Report services normally create this during onboarding, but a DNS migration, a zone rebuild, or a manual setup can lose it, and receivers drop the reports without any bounce or warning.

Variants and edge cases

dmarc external report destination not verified rua reports dropped

The specification wording admins find in receiver documentation.

dmarc aggregate reports not arriving third party rua verification record

The symptom plus record phrasing for report service setups.

rua reports silently stopped dmarc external destination verification txt

The silent failure variant stressing there is no bounce to find.

Compatibility: RFC 7489 DMARC external destination verification, major DMARC report processors and receiver reporting.

Edge cases to check:

• Every domain you publish DMARC for needs its own verification entry at the receiver, including subdomains with separate records.
• Receivers report on their own schedules; judge the fix over two cycles, not one morning.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__qcXTocCEpqdRDTqSqle5g