Data retention and privacy

21 June 2026 · 14 min read

DMARC Engine processes one specific kind of data: the email-authentication metadata that mailbox providers send back about your domain. That means sending IP addresses, the volume of messages seen from each source, and whether those messages passed or failed SPF, DKIM and DMARC alignment. It does not mean the bodies of your emails, your customers' messages, or anything a recipient typed. This page sets out exactly what we keep, how long we keep it, where it is processed, our position under the UK GDPR and EU GDPR, and how you can export or delete your data at any time. If you only want the short version: aggregate DMARC data is statistical, it is tied to your domain rather than to named people, you control it, and you can wipe it on request.

We have tried to write this in plain language rather than legalese. It describes how the product actually behaves, grounded in how the system is built, not a generic template. Where a topic has its own dedicated page, we link to it so you can go deeper.

What kind of data DMARC Engine handles

It helps to separate three different things, because they have very different retention and privacy properties.

1. Aggregate DMARC report data (RUA). This is the core of the product. When you publish a DMARC record with a rua= tag pointing at DMARC Engine, mailbox providers such as Google, Microsoft and Yahoo send your domain a daily XML summary. Each report says, in effect: "over this 24-hour window, we saw this many messages claiming to be from your domain, sent from these IP addresses, and here is how many passed or failed SPF and DKIM, and how they aligned." There is no message content in an aggregate report. There is no subject line, no recipient, no body. It is a count of envelopes grouped by sending source. You can see the same shape of data in our free DMARC report analyzer, which parses a report in your browser without an account.

2. Forensic or failure report data (RUF). Some providers can send per-message failure samples, which historically could include header fragments and limited content. In practice almost no major provider sends these any more, because of exactly the privacy concerns they raise. DMARC Engine is built around aggregate reporting. We do not require you to publish a ruf= tag, and our guidance is not to. If you want the detail on the difference, see /blog/dmarc-rua-ruf-reports.

3. Account and configuration data. This is the information you give us to run the service: your name, your work email, your organisation name, your domains, the DNS records and policies you configure, your notification channels, and (if you are on a paid plan) billing records. It also includes operational metadata we generate, such as session records and an audit log of changes made in your account.

The rest of this page treats these three categories separately, because lumping them together is how privacy pages become misleading.

What we store, field by field

We would rather be concrete than wave at "certain data". Here is what actually lands in our database.

From aggregate DMARC reports

Sending source IP addresses. The IP that submitted mail claiming to be your domain. This is the single most sensitive field, and we discuss it directly below.
Daily pass and fail counts per domain: how many messages passed DMARC, how many failed, how many were quarantined, how many were rejected.
Per-source daily rollups: for each sending IP, the volume seen that day, plus SPF-pass, DKIM-pass and DMARC-pass counts, and the reverse-DNS or organisation name where the provider supplied it, and an approximate country derived from the IP.
Reporter identity: which provider sent the report, and the report ID, used to deduplicate and to validate that a report genuinely belongs to your domain.

We do not store message subjects, bodies, attachments, recipient addresses, or any per-recipient detail, because aggregate reports do not contain them. To understand how to read these fields, see /docs/aggregate-report-analysis and /docs/analytics-explained.

From your account and configuration

Identity: your name and email, your organisation name and timezone, and team members' names, emails and roles.
Authentication: a hashed password (never the plaintext), session tokens, and, if you enable it, your two-factor settings. See /docs/security-and-2fa.
Domains and policies: each domain you add, its verification state, and the DMARC, SPF, DKIM, MTA-STS and BIMI configuration you build in the dashboard.
Secrets: where we manage records on your behalf, sensitive values such as DKIM private keys and notification-channel credentials are stored encrypted at rest, not in plaintext.
Operational records: an audit log of who changed what and when (which records the acting user and the source IP of the change), notification history, and API key hashes (we store a hash and a short prefix, never the full key after creation).
Billing: on paid plans, invoice records. Card details are handled by our payment processor and are not stored on our systems.

The one field in aggregate reports that can be personal data is the sending IP address. Under the GDPR an IP address can be personal data when it can be linked to an identifiable individual. For the IPs in DMARC reports this is almost always a mail server belonging to an organisation, a marketing platform, a forwarder or a botnet host, rather than a named person's home connection. But because it sometimes can be personal data, we treat the whole aggregate dataset as if it falls within scope. That is the cautious and correct position, and it is why everything below (lawful basis, retention limits, deletion rights) applies to report data and not only to your account details.

We use these IPs for exactly one purpose: to show you which sources are sending mail as your domain so you can authorise the legitimate ones and spot the spoofers. We do not enrich them with third-party identity data, we do not build advertising profiles, and we do not sell them. If you want to see how this drives the product, the threat monitoring and analytics explained pages show the IP-level view in context.

How long we keep it

Retention is set by data type. The defaults below apply unless your plan or a written agreement says otherwise.

Aggregate report data

Raw inbound reports and the rollups we derive from them are retained on a rolling window so you have enough history to make safe policy decisions and to satisfy compliance reviews, while not hoarding data indefinitely. The practical effect is that you keep a meaningful trend (months of daily statistics, not days) so you can see the impact of moving from p=none to p=quarantine to p=reject, but very old detail ages out. Higher-tier plans extend the window where longer history is genuinely useful, for example annual audits. If you need a specific retention period documented for a regulator or a customer, ask support and we will confirm it in writing for your account.

The principle is GDPR storage limitation: we keep report data only as long as it serves the purpose you signed up for, which is getting and staying at enforcement and watching for abuse.

Account, configuration and operational data

While your account is active, we keep your account, domain and configuration data so the service works.
Audit logs are retained for a longer window than report data, because their whole point is a durable record of security-relevant changes. See /docs/the-audit-log.
Sessions expire automatically and expired sessions are cleared.
After you close your account, we delete or anonymise your data within a reasonable wind-down period, except where we must keep a minimal record for a legal reason (for example, retaining invoices for the period tax law requires). See "Deleting your data" below.

Backups

Operational backups exist for disaster recovery and roll off on their own schedule. When you delete data, it is removed from the live system immediately and ages out of backups as those backups expire. We do not restore individual deleted records back into the live system from backup.

Where your data is processed and stored

DMARC Engine runs entirely on Cloudflare's platform. There is no separate cloud provider behind the scenes.

Compute runs on Cloudflare Workers, Cloudflare's edge runtime. Request handling happens close to the user.
The primary database is Cloudflare D1. Account, domain, configuration and the aggregated report statistics live here.
Object storage is Cloudflare R2, used for assets such as BIMI logos and VMC certificates, and for archiving raw report payloads that need to be retained or inspected.
Inbound report email is received through Cloudflare Email Routing into a dedicated worker that parses the report, validates it belongs to your domain, and writes the aggregated result. Reports arrive at a per-domain address you publish in your DMARC record; that address is a routing key, not a secret, because it is visible in your public DNS.
Outbound email (password resets, alert notifications) is sent through Cloudflare's email service, or through a transactional email provider as a fallback.

Because this is built on Cloudflare's global network, processing can occur in data centres in multiple regions. Cloudflare is the sole infrastructure sub-processor for hosting, storage and email delivery. We deliberately keep the sub-processor list short. If your organisation needs data processing pinned to a specific region (for example, EU-only), raise it with support before you onboard so we can confirm what is achievable on your plan; the database supports regional placement, and we would rather set that up at the start than migrate later.

Sub-processors

A sub-processor is a third party that processes data on our behalf so we can run the service. We keep this list intentionally small:

Cloudflare for compute, database, object storage and email delivery, as described above.
A payment processor for paid plans, which handles card data directly so that we never store it.
A transactional email provider as a fallback path for system emails, when not using Cloudflare's email service.

We do not use third-party advertising trackers or data brokers, and we do not feed your report data into them. If we add or change a sub-processor in a way that materially affects how your data is handled, we will update this page and, for customers with a data processing agreement, follow the notice process in that agreement.

Roles matter under the GDPR, so let us be precise.

For your account data (your name, your login, your billing), DMARC Engine is the data controller. We decide why and how it is processed: to give you an account, authenticate you, bill you and support you.
For the report data about your domain, you, our customer, are the controller of your domain's email programme, and DMARC Engine acts as a data processor on your instructions, processing that data to provide the monitoring and authentication service you configured.

Our lawful bases are:

Contract: most processing is necessary to deliver the service you signed up for.
Legitimate interests: security, abuse prevention, audit logging and keeping the service reliable. We have balanced these against your rights, and they are narrow operational interests, not marketing profiling.
Legal obligation: keeping the minimum records that law requires, such as financial records.
Consent: where we ever rely on consent (for example, optional marketing email), it is opt-in and you can withdraw it at any time.

For business customers who need it, we offer a Data Processing Agreement that documents these roles, the sub-processor list, security measures and the handling of international transfers using the appropriate safeguards (such as Standard Contractual Clauses where data leaves the UK or EEA). Contact support to put a DPA in place.

Your rights, and how to exercise them

If you are in the UK or EU, the GDPR gives you a set of rights. We extend the practical effect of these to all customers regardless of location, because it is simpler and fairer.

Access: ask what we hold about you, and get a copy.
Rectification: correct anything inaccurate. Most account fields you can edit yourself in account settings.
Erasure: have your data deleted, subject to the narrow legal-retention exceptions noted above.
Portability: receive your data in a structured, machine-readable format. Our export features below cover the report data directly.
Restriction and objection: ask us to pause certain processing, or object to processing based on legitimate interests.
Withdraw consent: where processing relies on consent.

To exercise any right that you cannot complete yourself in the dashboard, email our support team from the address on your account. We will verify your identity and respond within the statutory timeframe (one month under the GDPR, extendable for genuinely complex requests, in which case we tell you). You also have the right to complain to a supervisory authority; in the UK that is the Information Commissioner's Office.

Exporting your data

You do not have to file a formal request to get your data out. The product is built so you can self-serve.

Report exports: from the dashboard you can export your aggregate analytics and source data. See /docs/reports-and-exports for the available formats and scheduling. Scheduled reports can be emailed to recipients you choose on a daily, weekly or monthly cadence.
API access: programmatic export is available through the API, so you can pull your domains, statistics and source data into your own systems. See /docs/api-reference. API keys are scoped by permission, and we store only a hash of each key.
Configuration: your DNS records and policies are visible and copyable in the dashboard at any time, so you are never locked in. The published records live in your own DNS, under your control.

Because aggregate report data is statistical, an export is genuinely your data in a usable form: dates, source IPs, volumes and pass/fail counts that you can load into a spreadsheet or a SIEM without any proprietary wrapper.

Deleting your data

Deletion is designed to be real and complete, not a soft hide.

Delete a single domain: removing a domain from your account cascades to its configuration, its DMARC, SPF, DKIM, MTA-STS and BIMI records, and its associated statistics and source data. Once a domain is gone, new reports arriving for it that cannot be matched to an active domain are not added to your account.
Remove a team member: revokes their access and sessions.
Stop new report collection: change or remove the rua= tag in your DNS so providers no longer send reports to us, then delete the domain. We only ingest reports for domains that are active in an account and that pass our ownership validation, so an unmatched report is not silently retained against you.
Close your account: contact support to close the whole organisation. We delete or anonymise your account, domain, configuration and report data within a reasonable wind-down period, keeping only the minimum we are legally required to retain (such as financial records for the statutory period). Deleted data is removed from the live system at once and ages out of backups as those backups expire.

If you want a deletion confirmed in writing, say so when you request it and we will send confirmation once it is complete.

Security measures that protect this data

Retention and privacy are only meaningful if the data is actually protected. In brief:

Encryption in transit for all traffic, and encryption at rest for sensitive secrets such as DKIM private keys and notification credentials.
Hashed passwords and hashed API keys: we cannot read either back.
Two-factor authentication and optional IP allowlisting for accounts that want them, covered in /docs/security-and-2fa.
Role-based access so team members only see what their role permits, covered in /docs/team-and-roles.
An audit log recording security-relevant changes, including the acting user and source IP, in /docs/the-audit-log.
Report-origin validation: every inbound report must match a domain you own and pass a fail-closed check before it is stored, which keeps forged reports from poisoning your data.

Cookies and the public site

The dashboard at app.dmarcengine.com uses only the cookies it needs to keep you logged in and secure: a session cookie and security tokens. The free tools on the public site, such as the DMARC checker, SPF checker, DKIM checker and BIMI checker, run DNS lookups for the domain you type in and do not require an account. We do not run third-party advertising trackers across the product. For the formal cookie notice and the full privacy policy, see the privacy and cookie links in the site footer.

A note on the free tools

When you use a public tool, you are querying public DNS for a domain. That is the same information anyone can look up with dig. We may keep light, anonymised usage counts to understand which tools are useful and to prevent abuse, but the tools are not an account and they are not how the product collects your ongoing report data. The monitoring and retention described on this page begin only when you create an account, add a domain, verify ownership and publish a rua= tag pointing at us.

Frequently asked questions

Do you read my emails? No. Aggregate DMARC reports contain counts and IP addresses, not message content. We never see your customers' messages.

Do you sell my data? No. We do not sell, rent or share your report data or account data with advertisers or data brokers.

Where is my data stored? On Cloudflare's platform (Workers, D1 and R2). Processing can occur across Cloudflare's regions; ask about regional placement before onboarding if you need it pinned.

Can I get a DPA? Yes, for business customers. Contact support.

How do I delete everything? Delete your domains, or ask support to close your organisation, and we delete or anonymise your data within the wind-down period.

What is the difference between aggregate and forensic reports again? Aggregate (RUA) is statistical and what we use; forensic (RUF) can include content and is largely deprecated. We do not push you to enable it. See /blog/dmarc-rua-ruf-reports.

Where to go next

See the data the product collects in action: /docs/analytics-explained and /docs/aggregate-report-analysis.
Export and reporting options: /docs/reports-and-exports.
Account and team controls: /docs/account-and-organisation-settings and /docs/team-and-roles.
Security features: /docs/security-and-2fa and /docs/the-audit-log.
The product itself: /products/dmarc and the wider analytics view.
What providers actually require, including the compliance angle: /requirements.

If anything here is unclear, or you need a specific commitment in writing for a procurement or compliance review, contact support and we will give you a straight answer for your account rather than a generic one.