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.

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