Privacy Policy

01Who we are

DMARCmetric ("we", "us") operates the DMARC monitoring service at dmarcmetric.com. We are the data controller for the personal data described in this policy.

The data controller is Digiport OÜ, registered at Viru väljak 2, Tallinn 10111, Estonia. Estonia is a member state of the European Union, so the GDPR applies directly. The accountable contact for any privacy question is [email protected].

02What data we process

Account data

When you create an account we process the information you give us:

• your name and email address;
• your workspace / organisation details and the domains you add to it;
• a hashed password (we never store or log your password in plain text — it is hashed by our authentication library).
• a sign-in record for each session. When you sign in we create a server-side session so we can recognise you on your next request, and that record keeps the IP address the sign-in came from and your browser's User-Agent string, alongside the session's own identifier and expiry. We keep them to run and secure your account. For IPv6 addresses only the first half of the address is stored. How long we keep the address is in section 05.
• a two-letter country derived from that address. We resolve it once, against the offline dataset inside our own database described in section 04, and store the country code on your account so our own team can see which countries our customers are in. It is used for internal reporting only: it is not shown to anyone outside our team, not published, and not shared with anyone. Once the address is deleted the country is all that remains.

Billing data. Payments for paid plans are processed by Stripe; card details are entered on Stripe's hosted checkout and billing pages and never touch our servers — we never see, transmit or store a card number. We hold only billing metadata: your workspace's plan, its Stripe customer and subscription identifiers, and subscription status.

DMARC aggregate-report data

The core of the service is parsing the aggregate (RUA) DMARC reports that mail providers send about messages claiming to be from your domains. These reports are third-party-generated telemetry — we do not create them; receiving mail operators (Google, Microsoft, Yahoo and so on) generate and send them. For each sending source in a report we store the structured rows:

• the sender IP address and the message count it sent;
• the authentication results — SPF and DKIM outcomes and the DMARC disposition applied;
• the domains involved — the header-from and envelope-from;
• the reporter and reporting period — which operator sent the report and the date range it covers;
• derived fields we compute ourselves: the sending country resolved from the IP inside our own database, and the provider grouping shown under sending sources.

Aggregate reports carry no message content — no bodies, no subject lines, no recipient addresses. This is a property of the RUA format itself: reporters never send that data, so it never reaches us. See also Security and privacy at DMARCmetric and How long is my data kept?

Website usage data

Our web server keeps a standard access log of the requests it serves — every website does — and that log records your IP address. We keep it to run and secure the service and it is rotated away automatically; section 05 states after how long.

Every 15 minutes we read that same log on our own server to count how many people visited our website, which pages they opened, roughly which country they came from, and which site linked to them. No third-party analytics service is involved and no analytics script runs in your browser. What that measurement keeps is listed below, and your address is not part of it.

• No cookie is set and nothing is stored in your browser for this — see Cookies below. There is no analytics script, pixel or beacon on our pages: we are reading our own server's log after the fact.
• This covers the signed-in product as well as our public pages. If you are logged in, the pages you open inside DMARCmetric are recorded in the same way and under the same rules. Those records carry no account identifier — only the same one-day value described below — and are counted separately from public-site visits.
• The usage records contain no IP address. Your address is read from the log line, combined with your browser's User-Agent string and a secret we generate fresh every day to produce a one-way value, and is not copied into the store. That value tells one visitor apart from another within a single day and nothing more. We delete each day's secret two days later, after which it can no longer be connected to any address and cannot be matched against any other day's values — so the usage records cannot follow a visitor from one day to the next, and we report no "unique visitors this month" figure: because the value changes every day, the only honest number that design can give is a daily average, never a monthly total.
• We store one record per page view, not a running total. Each record holds the time, the page, your country, the referring site, a reference to the User-Agent line below, any campaign labels described below, and the one-day value above. The records are aggregated when we report on them; they are not stored aggregated.
• When another site links to us we record only that site's domain name — for example news.ycombinator.com — and never the address of the page itself.
• If you arrive through one of our own campaign links, that link carries campaign labels in its address (utm_source, utm_medium, utm_campaign). We keep those three values so we can tell which campaign brought you; they describe the link, not you. Nothing else from the address bar is kept.
• We keep the User-Agent header your browser sends, exactly as sent — a technical line of up to a few hundred characters naming the browser, its version and the operating system. We keep it because it is what separates the crawlers and scanners from actual readers: on a typical day most of the requests this site receives are automated. Each distinct line is stored once in a lookup table with no address beside it, together with a running count of how many stylesheet and image requests that same line has made — the signal that tells an automated scanner from a real browser. It is also one of the inputs to the one-day value above.
• Your country is resolved on our own servers from the local database described in section 04; no IP address — a sender's or a visitor's — is sent to a geolocation service.

Advertising measurement

We run search ads. If you reached this site by clicking one of them, Google added a click identifier (gclid) to the link you followed. It is an advertising identifier: it identifies that click, and Google can relate it back to the search session that produced it.

It travels in the address bar only — we write nothing to your device to carry it, no cookie and no browser storage, which is why section 08 says what it says. If you go on to create an account, that identifier is stored on your user record so we can tell Google Ads which clicks led to a sign-up, to a verified domain, or to a payment. A visitor who never signs up leaves no trace of it: there is no record to store it on.

What Google receives is the identifier, the conversion type (sign-up, activation — your first verified domain — or paid), its timestamp and, for a paid conversion, the amount. It is served from a file on our own server that Google fetches on a schedule. Your name, your email address and your IP address are not in that file. We do not embed any Google advertising or analytics script on this site. Retention is in section 05.

03Why we process it & legal basis

We process the data above only to provide the service you signed up for:

• Account data — to create and secure your account, authenticate you, and send you essential transactional email (email verification, password reset, notices about your domains' DNS setup — such as the record to publish when you add a domain, and when we see it go live — and any digests you opt into).
• Aggregate-report data — to parse, store and visualise your DMARC reports so you can monitor authentication and improve your email security posture.

We frame this policy around the GDPR and rely on the following legal bases:

• Performance of a contract (Art. 6(1)(b) GDPR) — for your account data and for providing the DMARC monitoring service you signed up for, including authenticating you and delivering essential transactional email.
• Legitimate interests (Art. 6(1)(f) GDPR) — for processing the aggregate-report telemetry to detect spoofing and abuse and to secure the service. This telemetry is third-party-generated and carries no message content, so this processing does not override your interests or fundamental rights.
• Understanding how our website is used — legitimate interest (Art. 6(1)(f) GDPR): we need to know which pages are read in order to improve them. The measurement sets no cookie, stores no IP address and builds no profile; each record holds the page, the time, your country, the referring site and a value that stops being meaningful the day after your visit, as described in section 02, and we report on it only in aggregate.
• Running and securing our servers — legitimate interest (Art. 6(1)(f) GDPR): our web server's access log records the address of every request, including yours. We need it to investigate abuse, attacks and faults. It is not used to build a picture of you, and it is rotated away on the schedule in section 05.
• Knowing where our customers are — legitimate interest (Art. 6(1)(f) GDPR): the sign-in record described in section 02 holds an address so we can run and secure your account, and we also resolve it once to a country so we can see which markets our customers come from and decide where to spend our effort. We are stating this plainly because it is a second use of data we collected for security: the country is coarse, it is never shown outside our team and it builds no profile of you, and the address it came from is deleted on the schedule in section 05 while the country stays with your account. If you would rather we did not hold it, email [email protected] and we will clear it.

04Sub-processors

We use a small set of infrastructure providers to run the service. We do not sell your data or share it with advertisers.

Web fonts are served from our own origin. Until 2026-08-30 the pages of this site loaded their typefaces from fonts.googleapis.com and api.fontshare.com, which meant your IP address and browser string reached Google and Indian Type Foundry on every page load. Those files are now hosted by us, so that transfer no longer happens and neither provider appears in the table above.

Cloudflare Turnstile (a bot-challenge widget) is active on our sign-in, sign-up and password-reset-request forms. When one of those pages loads, the widget is fetched from Cloudflare and performs its check in your browser; it operates under the Cloudflare entry above. It is not used on the public tools or on any other page. Those three pages also record one diagnostic line per load — whether the widget rendered — as an ordinary request to our own server. It carries no form values, email address or token.

05Data retention

Report data is retained according to your workspace's plan. Since the launch of paid plans on 2026-07-16, dashboards and exports read at most your plan's retention window — currently 30 days of history on the Free plan and one year on Starter — and a scheduled job physically deletes stored report data only once it is older than your plan's window plus a 60-day grace period (roughly 90 days of storage on Free, about 14 months on Starter). The grace period means upgrading immediately reveals still-stored history. The purge covers report rows, the plain-English summaries derived from them, and alerts; forensic failure samples have their own fixed 30-day window.

Existing workspaces are notified before the first scheduled deletion runs — nothing quietly vanishes from accounts that predate these windows.

Website usage data. The page-view records described in section 02 are kept for 400 days, so a twelve-month chart always has a full year behind it, and are then deleted automatically. The daily secret that distinguishes visitors within a day is deleted after 2 days. The raw web-server access log those records are derived from — the one that does hold your IP address — is rotated away after 90 days.

Sign-in records. The IP address held in the sign-in record described in section 02 is deleted 90 days after that sign-in — the same window as the raw access log above, because it is the same kind of data kept for the same reason. The sign-in record itself stays, without the address. The two-letter country resolved from it is kept on your account for as long as the account exists and is deleted with it, so after those 90 days the country is all we still hold about where you signed in from.

Advertising click identifiers. The gclid described in section 02 is deleted 100 days after the account was created. Google refuses a conversion reported more than 90 days after the click, so past that point the identifier can serve no purpose — and an advertising identifier kept for no purpose is exactly what this deletion is for. All three automated deletions — the website-usage records, the sign-in addresses and these click identifiers — are monitored: if a purge does not run, it raises an alarm to us rather than passing unnoticed.

Deletion on request is always available:

• Removing a domain removes its data. Deleting a domain from your workspace hard-deletes its stored reports and rows from the application database immediately.
• Everything else: just ask. Self-service account deletion is not in the product yet, so it is handled by hand — email [email protected] from your account's address and we will delete your account and its data.

For the full detail on report-data retention, see How long is my data kept?

06International transfers

Your account and report data are hosted in Germany (EU) on Hetzner infrastructure. Web requests are served through Cloudflare's global edge network, which may route or terminate TLS at edge locations outside your country; report processing and storage remain on our EU hosting.

Our primary hosting is in the EU (Hetzner, Germany). Where a sub-processor (for example Cloudflare or Postmark) may process personal data outside the EEA, such transfers are governed by the European Commission's Standard Contractual Clauses (SCCs) and equivalent safeguards. As noted under Sub-processors, no IP address — a sender's or a visitor's — is ever sent to MaxMind — IP-to-country resolution is a local lookup inside our own database, so no IP data is transferred to a geolocation service.

07Your rights

Under the GDPR you have the right to:

• access the personal data we hold about you;
• rectification — correct inaccurate data;
• erasure — have your data deleted (see Data retention above);
• portability — receive your data in a portable form (you can also export report data yourself via CSV export);
• objection — object to certain processing.

To exercise any of these, email [email protected] from your account's address and a human will handle it.

One limit, stated plainly. The website-usage records in section 02 carry no identifier we can match to you — the value that distinguishes visitors is regenerated every day and its secret is deleted two days later. We therefore cannot find your past page views in order to show or delete them (Art. 11 and 12(2) GDPR). If you object to that measurement, email us and we will stop counting your visits from then on. Every other right above is unaffected, and this limit does not apply to your account or report data.

08Cookies

We use first-party cookies only, and only to sign you in. The essential one is the session cookie set when you sign in. It is flagged Secure (only ever sent over HTTPS) and is backed by a server-side session record, so signing out revokes it immediately. There is no token stored in your browser for a rogue script to steal.

If you turn on two-factor authentication, two more appear, both part of the same sign-in: a short-lived cookie (ten minutes) that ties the code you enter to the password you just typed, and — only if you tick Remember this device — a thirty-day cookie so that browser is not asked for a code every time. Both are Secure, signed and backed by a server-side record. The ten-minute one is cleared as soon as you finish signing in; the thirty-day one stops working on every device the moment you disable two-factor (a browser may keep the dead cookie until it expires). Neither identifies you to anyone but us.

We use no analytics, advertising or tracking cookies.

That sentence is narrower than it may sound, and we would rather say so than hide behind the word "cookies": we do measure which ads bring sign-ups (section 02). That measurement carries an identifier in the link rather than in your browser, so there is nothing stored on your device to consent to — but it is advertising measurement, and naming it is the honest thing to do. Because every cookie we set is strictly necessary to run the service, no cookie-consent banner is required — there is nothing non-essential to consent to.

This still holds now that we measure website usage (section 02): that measurement reads our own server's log and neither stores nor reads anything on your device, which is what consent under the ePrivacy rules is about. The Cloudflare Turnstile widget on our sign-in, sign-up and password-reset-request pages is a security measure rather than a tracking one, and is described in section 04.

09Security

• Server-side, revocable sessions. Sessions live in a server-side record referenced by a Secure cookie, not as a token in your browser; signing out invalidates the session immediately.
• Email verification is required before you can sign in, and authentication endpoints (sign-in, sign-up, password reset) are rate-limited.
• Passwords are hashed and never stored or logged in plain text.
• Encrypted transport. Web traffic is TLS-encrypted between your browser and the service via Cloudflare.
• EU hosting in Germany, with tenant-scoped data access — every query that reads report data is scoped to your workspace using your server-side session, never anything the browser merely claims.

We describe only what is true today. DMARCmetric does not currently hold SOC 2 or ISO 27001 certification, and we make no such certification claims. See Security and privacy at DMARCmetric for the fuller picture.

10Changes & contact

We may update this policy as the product evolves; the "last updated" date at the top reflects the current version. For any privacy question, to exercise your rights, or to request deletion, contact [email protected].