What happens to your DMARC data? A transparency post
Before pointing your DMARC reports at any provider, you should know exactly what you are handing over. Here is the complete answer for SealedMail: what arrives, what is stored, for how long - and the email content and personal data that were never in the reports at all.
Subscribing to SealedMail means adding our reporting address to your DNS, after which the world’s mail providers send your domain’s DMARC and TLS reports to our infrastructure. For a compliance-minded buyer, that should prompt a precise question: what exactly am I handing over, and what happens to it?
This post is the complete answer. It is short, because the honest answer is reassuringly small - but “trust us, it’s fine” is not a standard SealedMail would accept from a supplier, so here is the detail, in the order a data protection review would ask for it.
What a DMARC aggregate report contains
A DMARC (Domain-based Message Authentication, Reporting and Conformance) aggregate report is a statistical summary compiled by a receiving mail provider - Google, Microsoft, Yahoo and others - describing the email it saw claiming to come from your domain. Each report contains:
- the IP addresses of servers that sent mail using your domain’s name;
- message counts per source;
- authentication results - whether each source passed SPF and DKIM checks, and the alignment outcomes;
- the policy action the receiver applied (delivered, quarantined, rejected);
- your domain’s published DMARC policy as the receiver saw it.
Equally important is what an aggregate report does not contain - by design of the standard itself, not by anyone’s discretion:
- no email content or message bodies;
- no subject lines;
- no sender or recipient mailbox addresses;
- no attachments, headers beyond the authenticating domains, or personal data from inside any email.
In other words: the reports describe traffic about your domain’s name, not correspondence. The full field-by-field anatomy is in What does a DMARC report actually show?. One technical footnote for completeness: the DMARC standard also defines a second report type - forensic/failure reports (RUF) - which can contain message detail. SealedMail’s service is built on aggregate reports and TLS reports only; we do not request forensic reports in the DNS entries you publish for us.
A TLS-RPT report is more minimal still: counts of successful and failed encrypted connections to your domain, with technical failure reasons. No content of any kind.
What SealedMail receives, stores and processes
Receives: the aggregate and TLS reports described above, sent by mail providers to the SealedMail reporting addresses in your DNS; plus the ordinary account information any supplier holds - your name, business name, the email address your weekly report goes to, and billing handled by Stripe (SealedMail does not see or store your card details).
Processes: we parse the reports, resolve source IP addresses to their operators, compare each week against your domain’s history, and run the domain health checks (your public DNS records - which are, by nature, already public). The output is your weekly plain-English report.
Stores: the report data and the derived history for your domain - necessary because interpretation depends on trend (“this source is new”; “this failure started Tuesday”). All data is held on UK-based infrastructure and handled under UK GDPR (the UK General Data Protection Regulation). The full legal detail - lawful bases, sub-processors, your rights - lives in our privacy policy, which is written in the same plain English as everything else here.
Retains: report data for the period needed to provide trend-based interpretation, and your account data for the duration of your subscription plus statutory retention for business records. If you cancel, your reporting data is deleted after the wind-down period set out in the privacy policy - and because you control your DNS, redirecting or stopping the flow of reports is always in your hands, instantly, without asking us.
The honest assessment of sensitivity
Could DMARC data harm you if mishandled? A fair due-diligence question deserves a straight answer: the realistic sensitivity is low but not zero. The reports reveal which platforms send email for your business (your mail provider, your CRM, your invoicing system) and the volume rhythm of your sending - commercially mundane, but a picture of your operations nonetheless. They contain no client correspondence, no personal data from emails, and nothing approaching special category data. SealedMail treats them with the same care regardless: UK storage, access limited to the one named person who runs the service, no sale or sharing of data, no use of your data for anything except producing your reports.
That last point bears repeating as a plain commitment: your data is used to deliver your service. Nothing else. No analytics products, no “anonymised industry insights”, no marketing lists.
Why we publish this
SealedMail sells to regulated, cautious buyers - solicitors, practice managers, charity trustees - and asks them to route security telemetry to a sole trader. The only honest response to that asymmetry is transparency specific enough to be checked: what arrives, what it contains, where it lives, who can see it, when it is deleted. If your due-diligence process needs more - a completed supplier questionnaire or our supplier information sheet - ask at [email protected] and it will be provided during service hours.
And if you would like to see exactly what we produce from such data before pointing anything anywhere, the Free Domain Health Check uses only your public DNS records - handing over nothing at all - and shows you the plain-English certificate format every subscriber receives weekly.