What we collect — and what we never touch
The DMARC report XML is discarded unread — never parsed, never stored. We characterize only the sending server's connection.
What we collect (per connection)
Source IP, ASN, network prefix, reverse-DNS/FCrDNS result, HELO/EHLO, TLS handshake details and a fingerprint, the verifying DKIM d= domain, the envelope SPF result, the per-tenant recipient address, and timestamps.
What we never collect
Message bodies, the report XML payload, or forensic (RUF) reports.
What we discard, and when
- XML payload — immediately, unread.
- Raw per-connection records (incl. the client IP) — purged on a rolling window (currently 90 days in our development phase, set to tighten), after folding into a minimal per-identity aggregate. Once a sender's transport fingerprint is confidently established, the specific client IP is no longer needed — the durable signal lives in the aggregate, not the raw record.
- Aggregate — decays and purges after 365 days with no re-observation.
- Published allowlist — only confirmed-legitimate reporter infrastructure persists, because that's the product; removed on deprecation/dispute.
- Account / OAuth — life of account; on deletion we revoke Google access and erase your personal information (the AUP-acceptance record is retained, anonymized, as required).
- Logs — audit 2 years; AUP / dispute / permission 7 years.
FAQ
No on both counts. We never parse the XML payload and never persist it. The report is a transport carrier; we extract connection metadata about the sending server and the payload is discarded unread.
A completed TCP + TLS + SMTP exchange can't spoof its source address — the connecting IP is ground truth. The XML is trivially forgeable; the connection is not.
They can send fabricated reports, but those arrive from infrastructure that fails transport authentication and never appears across many unrelated domains, so they never earn confidence in the published list. Per-tenant addressing and DNS-level authorization further limit who can reach us at all. And note what the list asserts: confidence that a sender is a legitimate reporter — not a determination that any given connection is malicious. A source merely absent from the list has simply earned no confidence yet; absence is not an accusation.
No. It's a high-confidence scoring and triage input, not a 100% failsafe — infrastructure churns and shared cloud space is ambiguous. Treat it as a strong signal, not an absolute verdict.
They can be. We minimize by design (transport metadata only, never message content) and rely on a documented legitimate-interest assessment. Raw connection data is kept only for a short rolling window and then automatically purged — data minimization by design — leaving only a minimal, low-identifiability aggregate. Published data carries a dispute/takedown process.
Yes — free to use, non-commercial.
Believe a published entry about your infrastructure is wrong, or want it removed? Every published entry has a dispute/takedown path.
Start a dispute or takedown →