Security and privacy at DMARCmetric
Everything in this article describes the system as it ships today — each claim maps to how the product is actually built, not to a roadmap. This article covers current practice in plain language; for the full statement, see our Privacy Policy.
Your account and sign-in
- Sessions live on the server, in a cookie — no sign-in token is kept in browser storage. When you sign in, DMARCmetric sets a session cookie backed by a server-side session record. That makes sessions genuinely revocable: signing out invalidates the session on the server, immediately. There is no JWT sitting in localStorage for a rogue script to steal. One thing a tab can keep: if you open a workspace invitation link without being signed in, the invitation page keeps the link's secret in that tab's session storage so that it can finish after you sign up or sign in. It is removed when you join, when the page finds the invitation is no longer open, or when you choose to set up your own workspace instead; otherwise it stays until you close the tab.
- Cookies are flagged Secure — they are only ever sent over HTTPS.
- Email verification is required. You cannot sign in until the address on your account is verified, so an account cannot be operated from an email its owner never confirmed. With Continue with Google, Google's confirmation that it has verified the address takes the place of our link, and an address Google has not verified is refused.
- Authentication endpoints are rate-limited. Sign-in, sign-up and password-reset requests have hard per-window limits, and the counters are stored in the database so limits survive restarts.
- Passwords are hashed by the authentication library (better-auth) and are never stored or logged in plain text.
- Two-factor authentication is available, optional and per user. A second sign-in step from an authenticator app (with backup codes) or an emailed code; a stolen password alone no longer opens the account. How to turn it on and what it does is in Two-factor authentication (2FA). It is not available for an account that signs in with Google (see below).
Signing in with Google
Continue with Google is optional. On the sign-up page it creates your account, or signs you in if your Google account already has one; on the sign-in page it only signs in to an account that already uses Google, and never creates one. When you use it, Google tells us your Google account identifier, your name and email address, and whether Google has verified that address; we keep those. We do not keep your Google profile photo or any token Google issues, and we use Google for nothing but signing you in. An account created with email and password is never connected to Google — not automatically and not by any setting — so sign in to it with your password. The details, including the short-lived cookie this uses, are in our Privacy Policy.
What your data is — and is not
- Aggregate DMARC reports carry no message content. This is a property of the format itself: an RUA report is counts, IP addresses and authentication results. No bodies, no subject lines, no recipient addresses ever reach us, because reporters never send them. Exactly what we do store from each report is detailed in How long is my data kept?
- We hold no card 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, never card details: your account's plan (and Scale package), its Stripe customer and subscription identifiers, and the subscription's status, billing interval, price and currency, renewal, cancellation and trial dates, and when these last changed. If you came to us from one of our ads, the amount, currency and time of each payment made in your account's first 100 days are also kept, until 100 days after you signed up, for the advertising measurement described in our Privacy Policy.
- Your data is scoped to your account. Every API query that reads report data is tenant-scoped: it filters by the account you are working in — and, in an account that shares workspaces with you, by those workspaces only — taken from your server-side session, never from anything the browser merely claims. The one exception is a BIMI logo you choose to host with us: it is public by design, because mailbox providers fetch it without signing in.
Where your data lives
- Hosting is in Germany. The service runs on Hetzner infrastructure in Germany (an EU member state), behind Cloudflare.
- Web traffic goes through Cloudflare and is TLS-encrypted between your browser and the service.
- DNS lookups use public resolvers. When our pages check a domain's DNS records, your browser asks Google's or Cloudflare's public DNS-over-HTTPS service directly, and our server uses the same two for most of its own checks (the TLS-RPT Check record asks your domain's own DNS servers directly) — see our Privacy Policy.
- IP geolocation happens inside our own database. The country view is powered by a GeoLite2 dataset loaded into our PostgreSQL instance, so resolving a sender's IP to a country is a local SQL lookup. Your senders' IP addresses are not sent to any third-party geolocation service.
Small design choices that add up
- Unsubscribe links fail closed. Digest unsubscribe tokens are HMAC-SHA256-signed and strictly validated, including a constant-time comparison. If the signing secret were ever missing or too weak, the endpoint disables itself entirely rather than accept anything questionable.
- Opening an unsubscribe link never changes anything by itself. The link shows a confirmation page; the change happens only when you explicitly confirm. Email scanners that prefetch links cannot unsubscribe you by accident.
- Unsubscribing touches one database field — your own report cadence for the account the email came from (or, from a product-update email, your product-update switch for that account). No external suppression list is involved, which is also why re-enabling digests from your settings works instantly.
What we do not claim
We would rather publish a short list of true statements than a long list of impressive ones. So, plainly: DMARCmetric does not currently hold SOC 2 or ISO 27001 certification, and we make no certification claims around GDPR — this article simply describes how the system handles your data today. Our Privacy Policy sets out the same practices in a formal statement, including our sub-processors and your GDPR rights.
If anything here does not answer your question, the support box below reaches a human. For the wider picture of what the product does with your reports, see What is DMARCmetric?