dmarc external report destination not verified: rua reports silently dropped

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

Work the three things an rua change can break, in order: confirm the new DMARC record is syntactically right and actually published, confirm the new mailbox or service really accepts mail, and confirm external destination verification exists if the new address is on another domain. Reports are generated by receivers on their own schedules, so after fixing, judge the result over two reporting cycles rather than the next morning.

dmarc aggregate reports stopped arriving after changing the rua address

Use this when

• Aggregate reports stopped within a day or two of an rua address change.
• DMARC evaluation itself still passes and mail flow is unchanged.
• The new rua is a different mailbox, provider, or domain than the old one.

Not for this skill when

• Reports never arrived for a new domain. That is an onboarding verification task, not a change fault.
• Receivers stopped enforcing DMARC too. That points at the whole DMARC record, not just reporting.

Steps

1. Diff the old and new DMARC records character by character, checking the rua value, separators, and any mailto formatting fault. 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 published record matches the intended new rua exactly
2. Send a normal test email to the new rua address from outside and confirm it is accepted and stored or ingested by the report service. 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 test mail reaches the new destination with no bounce
3. If the address is on another domain, check the external destination verification record for your domain at that domain. 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: the verification record is present, or its absence is confirmed as the fault
4. Fix the identified break, then wait through two receiver reporting cycles, normally about 48 hours. 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 reports from at least one major receiver arrive at the new address
5. Record the change and the reporting gap dates in your DMARC change log so the missing days are explained later. 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 is documented with start, fix, and resume dates

Why it happens

An rua change touches three independent systems at once: your DNS record, the receiving mailbox or processor, and the permission record receivers check before sending reports to a third party. Any one of them silently stops the flow, and receivers give no bounce or error you can see. Because reporting is batched daily by each receiver, even a correct fix looks broken for the first day, which tempts admins into extra changes that start the clock again.

Variants and edge cases

dmarc aggregate reports stopped arriving after changing rua address

The change linked symptom in plain words.

rua changed no dmarc reports new address verification

The verification suspicion phrasing for third party addresses.

dmarc reporting stopped after dns change rua typo mailbox

The typo and mailbox variant covering the simple causes.

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

Edge cases to check:

• Keep the old mailbox accepting mail during a transition; some receivers report against records they cached before your change.
• A missing percent or interval tag does not stop reports, but a malformed rua value can make receivers ignore the whole reporting instruction.

Provenance

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

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

Thread query: dmarc aggregate reports stopped arriving after changing the rua address

TL;DR: Work the three things an rua change can break, in order: confirm the new DMARC record is syntactically right and actually published, confirm the new mailbox or service really accepts mail, and confirm external destination verification exists if the new address is on another domain. Reports are generated by receivers on their own schedules, so after fixing, judge the result over two reporting cycles rather than the next morning.

Not specified by the original author.

TL;DR

Your own gateway showing fail in aggregate reports usually means that stream is unsigned, misaligned, or sent from an IP not in SPF. Aggregate XML groups by source IP and authentication result, so start by matching the failing rows to a known sending system. A marketing platform, multifunction printer or CRM sending as your domain without its own DKIM and return path is the common find.

dmarc aggregate report shows fail for our own gateway

Use this when

• RUA reports list your gateway IP with dkim=fail or spf=fail rows.
• Failure volume rises after a new internal system started sending mail.

Not for this skill when

• All failing rows come from IPs you do not recognise at all. That is external spoofing, handled by enforcement policy.
• Reports are forensic RUF reports for single messages. Aggregate triage differs.

Steps

1. Parse the latest aggregate reports and group failing rows by source IP, From domain and authentication result. Verify: the failing gateway stream is isolated from general spoof noise.
2. Map each failing IP to an owner: gateway, vendor platform, printer fleet or application server. Verify: every failing IP has a named owner or is marked unknown.
3. For an owned stream, check its headers directly for a DKIM signature and an aligned return path. Verify: the missing or misaligned identifier is identified.
4. Fix the stream: enable DKIM signing with your domain, set an aligned envelope sender, and add only its real sending IPs to SPF within the lookup limit. Verify: a test message from that system shows aligned pass results.
5. Watch the next two reporting cycles. Verify: failing rows for that IP drop to zero or to explained forwarding noise.

Variant phrasings

dmarc aggregate report own ip failing

The source-IP variant for RUA triage.

rua report unknown sending source in own domain

The unowned stream variant.

Compatibility: RFC 7489 aggregate reporting, reports from Google, Microsoft and Yahoo receivers.

Why it happens

Aggregate reports record what receivers saw, not what you intended to send. Any system that can emit mail as your domain appears there, including forgotten appliances and test servers that were never given working authentication.

Edge cases / pitfalls

• Report IPs are the receiver-facing egress IPs, which may be NAT or gateway addresses shared by many internal systems.
• Low failing counts from known forwarders can be normal. Volume and trend matter more than a single row.
• Ingest reports automatically; daily XML by hand hides slow growth from a new unauthenticated stream.

Provenance

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

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

Thread query: dmarc aggregate report shows fail for our own gateway

TL;DR: Your own gateway showing fail in aggregate reports usually means that stream is unsigned, misaligned, or sent from an IP not in SPF. Aggregate XML groups by source IP and authentication result, so start by matching the failing rows to a known sending system. A marketing platform, multifunction printer or CRM sending as your domain without its own DKIM and return path is the common find.