Every domain that publishes a DMARC record with a rua tag receives aggregate reports — compressed XML, daily, from Microsoft, Google, Yahoo and every other large receiver. They pile up in a mailbox nobody opens. TATER reads them for you, and tells you what they say.
DMARC has two halves. The policy in DNS tells the world what to do with mail that fails authentication. The aggregate reports tell you what actually happened. Most organizations publish the first and never read the second — which means they have turned on a rule and switched off the only instrument that shows its effect.
It is easy to see why. The reports are gzipped XML, addressed to a mailbox created for the purpose, arriving a few dozen times a day from senders nobody recognises. Opening one by hand tells you almost nothing; you need every report over a window, aggregated by domain and by sending source, before a picture appears. So the mailbox fills up, and the folder becomes a place mail goes to be ignored.
An unread report set is tolerable at p=none, where nothing is being rejected. At p=quarantine or p=reject it is not: legitimate mail from a service you authorised years ago can be failing alignment and getting refused, and the reports are the only place that shows up. The sender rarely tells you. The recipient never does.
Moving from none to quarantine to reject is supposed to be evidence-led: you tighten when the failing volume is understood and every legitimate sender is aligned. Without the reports, that decision is a guess, and the way you discover you guessed wrong is a phone call about a missing invoice.
Aggregate reports name every IP sending as your domain, aligned or not. That is where an impersonation campaign against your brand becomes visible — usually well before anyone reports a phishing mail that claims to be from you.
TATER reads the reports where they already land, parses them on the server, and keeps the aggregate. There is no connector to buy, no DNS change, and no agent in the loop.
Name the mailbox your rua tag points at. TATER subscribes to it and parses each report as it arrives.
Reports arrive as .gz, .zip or raw XML, sometimes forwarded inside another email. All of it is handled server-side.
Per domain: message volume, DMARC pass rate, failing count, the reporting window, and the sources responsible for the failures.
A readiness read for stepping the policy to reject — and a plain statement when the data is too thin to say.
A pass rate on its own is not actionable. What you need is the list of sending sources that failed alignment, ranked by volume, so you can sort them into two piles: services of yours that were never set up properly, and everyone else.
The first pile is a fix — an SPF include, a DKIM key, a sending domain change at the vendor. The second is either harmless background noise or somebody spoofing you. Both matter, and neither is visible from the DNS record alone.
Reports that predate the connection are not lost. TATER can read what is already sitting in the mailbox, so the first useful window is however far back the mailbox goes — not the day you turned it on. A history you already own is the difference between deciding now and waiting a month to collect what you had all along.
Your DMARC, SPF and DKIM records stay yours to set, in your own DNS. TATER tells you what the receivers are reporting back and whether a change is safe to make; it does not make the change. Aggregate reports are also exactly that — aggregate. They carry sending IPs, volumes and authentication results, never message content, so nothing here reads anyone's mail.
The guide covers pointing TATER at your rua mailbox, importing the reports already in it, and reading the alignment results.
If your domains publish a rua tag, the evidence already exists. It is a question of reading it.