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).
• if you choose Continue with Google: your Google account identifier, the name and email address Google returns with it, Google's confirmation that it has verified that address, and the list of permissions Google granted for the sign-in. An address Google has not verified is refused and no account is created. We do not keep your Google profile photo, and we do not keep the access, refresh or ID tokens Google issues: we contact Google only to complete a sign-in you started and never use your Google account for anything else, so we have no use for them. An account created with Google has no password with us unless you set one through "Forgot password?" on the sign-in page. An account created with email and password is never connected to Google; you sign in to it with your password.
• 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 the IP address your sign-up request came from. We resolve it once, when you create the account, 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. The sign-up address itself is not added to your account. Apart from a short-lived rate-limit entry, usually cleared within minutes, we keep it only in the raw web-server access log described in section 05, like the address of every request. If that address cannot be resolved to a country, we use the address of your earliest sign-in that we still hold instead, normally your first. For accounts whose sign-up was still in that access log on 18 October 2026 we corrected the country once from it — or set it, for accounts that had none — where the log matched the account unambiguously. Until then it came from the first sign-in, and older accounts keep that value; an email security scanner that opens the verification link can be that first sign-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 those addresses are deleted the country is all that remains.
• if you turn on two-factor authentication: with an authenticator app, the app's secret key and your ten backup codes, both stored encrypted (if you start setting up an app and do not finish, they stay until you set it up again, turn two-factor off or delete your account); with email codes, each code is stored only as a hash, never the code itself, and expires after five minutes. Turning two-factor off deletes the secret and backup codes. The cookies it uses and the note we keep about a remembered browser are described under Cookies.

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, 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 below.

Workspace sharing

On a paid plan, the owner of an account can give other people access to one or more of its workspaces (the folders its domains are grouped in) by inviting their email address, and an admin of a workspace can invite members to it. Each invitation is for one workspace and one role, admin or member. Sharing keeps these records:

• Invitations. For each invitation we store the address it was sent to, the account and the workspace, the role offered, who created it, when it was created and when it expires (7 days after it was created), and whether it was accepted (when, and by whom) or canceled (when). Resending an invitation replaces its link, so the earlier link stops working, and sets it to expire 7 days after the resend. The link carries a secret. In our database we store only a SHA-256 hash of that secret, never the secret itself, so a stored invitation record cannot be turned back into a working link. The full link is in the email itself, and Postmark keeps a copy of that email (see the next point). The secret sits after the # in the link, the part of a web address that browsers do not send when they request a page, so it does not reach our web server's access log. The invitation page then sends it to us in the body of a request, so that we can find the invitation by its hash, and so does the sign-up page in that tab (to fill in the invited address); we do not log or store it. In your browser, the invitation page takes the secret out of the address bar as soon as it opens (if your browser does not allow that, the link stays in the address bar), keeping it with that page in the tab so that reloading the page still works; your browser's own history list may still record the link as you opened it. If you are not signed in, the page keeps the secret in that tab's session storage instead, so that it can finish after you sign up or sign in (if your browser refuses that storage, the copy kept with the page stays). These copies are removed when you join on the invitation page, when it finds that the invitation is no longer open, or when you choose to set up your own workspace instead; if you leave it without finishing there (for example to finish in the tab your confirmation email opens), a copy can stay in that tab until you close it. Your browser removes them when you close the tab, unless it later restores or duplicates that tab, which can bring them back with it.
• The invitation email. It is sent only to the invited address, from our own sending address rather than the inviter's, through Postmark (section 04). It shows the name on the inviter's account, or "A teammate" if that name contains an email address (we do not add their email address), the workspace's name, the role offered, when the invitation expires and the link. Postmark keeps a copy of each email it sends, link included, for about 45 days, as it does for every email we send.
• A record of each invitation email sent. Each time we send an invitation email, the first time or as a resend, we first record the address it is sent to, the account sending it, the invitation and the time; the record stays even if the email then fails to go out. We use these records only to enforce the limits that stop sharing being used to send unwanted mail: no more than 20 invitation emails per account, and 3 per address from all accounts together, in any 24 hours. (The per-address count ignores letter case and surrounding spaces, but a differently written form of the same mailbox, for example with a +tag, counts as a separate address. Deleting an account deletes its send records, so its emails stop counting toward the per-address limit.)
• If an invitation email cannot be delivered. If it bounces, or its recipient reports it as spam and their mail provider passes that report on to Postmark, Postmark tells us, and we record the address, what happened, when, and whether Postmark has stopped delivering to it, as we do for every email we send.
• Access to a workspace. An invitation can be accepted only by someone signed in with the invited address, once that address is verified. We then record who has access to which workspace of which account, with which role, who invited them and when access was given. Accepting also switches your current sign-in session to that account.
• Each person's own email settings. Everyone given access has their own email settings for that account, which only they can change: their report frequency and level of detail, and which alerts and notices they want. An alert reaches them only if the account's owner also has that alert type switched on. Until they first open their account page (where their email settings are) or use an unsubscribe link, or until we first send them a report (or find that their address cannot receive one), the defaults apply and nothing is stored for them. From then on we store these settings, when they were created or last changed, and when their last report was sent to them (or, if their address cannot receive mail, when it was last due).
• A "joined by invitation" note. If you accept an invitation at a time when you do not own a DMARCmetric account yourself (for example because you signed up to accept it), we note the time on your user record. It is written once and never changed. Its only uses are our own: our admin console marks people with the note as invited in its list of users and leaves them out of its sign-up counts and country chart, and we leave them out of our activation-funnel figures. It is not shown outside our team.
• Our server's log. It records, by internal identifier: who created, resent or canceled each invitation; who accepted an invitation, and to which workspace; most attempts to invite or accept that we turned down, with the reason and who made them; when someone reached a sending limit; who removed someone's access through the account's list of people, changed a role or left an account (access that ends because a workspace, an account or a user account is deleted is not logged this way); and, for each person given access, the reports, alerts and record-health notices we sent them or could not send them, the reports we skipped, and when they used an unsubscribe link. The lines about sending an invitation hold no part of the invited address and none of the names in the email. The lines about other emails — a report, alert or notice to a person given access, or a bounce or spam report — show the recipient address's first character and its domain, as for every other email we send.

Inside the account, the list of people and invitations is shown only to the account's owner and to admins. The owner sees everyone with access, with their name, email address, workspaces and roles, and every invitation not yet accepted or canceled, with its address, workspace, role and expiry (and an internal reference to the person who created it); an admin sees the same for the workspaces they administer, and the owner's name and email address. Everyone given access is shown the account owner's email address, as the person to ask about the account's plan and about settings only the owner can change (such as keeping original report files). Everyone given access also sees the account's name, which titles the reports, alerts and notices we email them; the names of the workspaces shared with them and their role in each; the first name of the person who shared each one with them (or the owner's); whether their access is paused; and which alert types the owner has switched off. Anyone who has an invitation link can open it without signing in and see the invited address, the workspace's name, the inviter's name, the role and whether the invitation is open, expired, canceled, accepted or paused. Once you are signed in with a verified address, you also see the open invitations sent to that address, in any account, with the workspace's name, the inviter's name, the role, the expiry and whether it is paused. If the name on the inviter's account contains an email address, we do not hand it out: the invitation page and the invitation email say "A teammate" instead.

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?

TLS reports (TLS-RPT)

If you publish a TLS-RPT record that points to us, mail operators that SEND mail to your domain and support TLS-RPT (for example Google) email us a report for each day they sent you mail, saying whether they could deliver it to you over a secure connection. We generate none of it. From each report we keep in your account: the reporter and the period it covers; the kind of policy it describes; how many connections succeeded and how many failed; and for failures, the reason, the name and IP address of your receiving mail server and the IP address of the sending mail server. Reports name no messages and no subject lines; the only email address in them is the reporter's own contact address, which we do not keep in your account. We keep in your account only the parts of a report that are about your own domain; anything about another domain is left out. The email a report arrives in is deleted from our mail server after about 30 days (about 90 days if we could not process it). Reports are stored on every plan, so after upgrading you see the last 30 days straight away (a paused domain's reports are not stored); reading them is included with Starter. They follow your plan's retention (section 05).

Brand logo (BIMI)

On paid plans you can upload a logo for a domain so that mailbox providers can show it next to your mail (BIMI). We store each file exactly as you upload it, together with which domain it is for, when it was uploaded, which person uploaded it, a fingerprint (hash) of the file and the random address it is published at. Our server logs also record which person uploaded or deleted a logo, or uploaded a file that failed our logo checks. The logo is public: anyone with its address can download it without signing in, because that is how mailbox providers fetch it — upload only what you would put on your public website. Requests for it that reach our server, from a mailbox provider or anyone else, are recorded in our web server's access log with the requester's IP address, like every request to our server (section 05); requests answered from Cloudflare's cache (section 04) do not reach us. Because your BIMI record points to that address, it also shows publicly that the domain uses DMARCmetric. Serving the logo sets no cookie.

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. (Separate from this measurement: the sign-in, sign-up and password-reset pages send one diagnostic line about the bot check, described in section 04, and inside the signed-in product a click on an Upgrade link is recorded — see Upgrade clicks below.)
• 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.

Upgrade clicks

When you are signed in and click one of the links inside DMARCmetric that lead to upgrading — today, the links on the locked Mail transport security checks and on the locked Encrypted delivery (TLS-RPT) card on a domain's page, and the Host your logo link under a domain's BIMI check on Free — your browser tells our server, and we record that click on your account: which link it was, the domain page it was on, your plan at that moment and the time. We use it to learn whether those links help people decide to upgrade, by comparing it with whether the account later did.

• No IP address and nothing about your browser is stored with it, and no cookie is set for it. Like every request, the click also appears in our web server's access log, which does hold your IP address and is rotated away after 90 days (section 05).
• The page-view measurement described above is unchanged: it still carries no account identifier.

Feedback surveys

From time to time we email a short survey about DMARCmetric. We record on your account that it was sent (and when, and any reminder), the stage your account was at — whether you had added a domain and received reports, Free or paid, and whether you came from one of our ads — together with your workspace, the date you signed up and the name of your first domain, and your answers, if you give any: the rating, the options you tick, anything you write, and when you answered.

Mail scanners open every link in a message, so to tell a person reading the survey from a scanner we also record each opening of the survey page: when it was opened, how long it stayed open, whether it was visible, whether a person (rather than a script) interacted with it, the score you clicked in the email if any, your browser's User-Agent string, your country, and the network your address belongs to — the first three parts of an IPv4 address or the first 48 bits of an IPv6 one, never the full address.

Verify DNS presses

When you press Verify DNS on the domain setup or domain settings page, your browser looks the record up itself through a public DNS-over-HTTPS resolver run by Google or Cloudflare (see section 04) and tells our server what it showed you. We store on that domain the time of the press, the result shown, and the time of the last press that showed the record as set up — so that, if a record later stops working, we can tell when it last looked right. A press that shows the record as set up also restarts the setup emails we send while a domain is waiting for its first report.

Check record, on a domain's Encrypted delivery (TLS-RPT) card, works the other way round: our server, not your browser, looks up which DNS servers host your domain and asks them directly for its TLS-RPT record. These lookups name your domain and its DNS servers, nothing else. When those servers give a clear answer, we store on that domain what they said — set up and sending reports to us, sending them somewhere else, not there, or there but unusable (and why) — and when, so the card can still show it after you reload the page. We also store the time of the last press, which limits how often the check can run. The result is stored without who pressed it: no user, no IP address and no copy of the record is kept with it.

Check again, in the BIMI section of a domain's settings page, has our server ask your domain's own DNS servers for the domain's BIMI record directly. When the page opens while you host a logo for the domain with us, and public DNS answers that the domain has no BIMI record or a single one pointing to none of those logos, the page also makes this check once by itself. These lookups by our server name your domain and its DNS servers, nothing else. What the servers say is sent back to the page and is not stored: our server holds it in memory for 10 seconds, so another press for that domain within that time gets the same answer. Our server log records which domain was checked, what kind of answer came back and how long it took — not who pressed it and not the record. Each press also has your browser read the domain's DMARC record again — and, for a subdomain with no BIMI record of its own, its parent domain's BIMI record — through public DNS, as described in section 04; when our server can't answer, your browser reads the BIMI record there too.

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. The one short-lived exception, pressing Continue with Google, is described below.

Where you found us. When you create an account we also store, on your user record, the domain name of the site that sent you to us — for example google.com or bing.com, never the address of the page — or that you came to us directly, and, if you came through one of our ads, the campaign number Google added to the link. These travel the same way as the click identifier, in the address bar only, and are deleted on the same schedule (section 05). We use them to learn which searches, sites and campaigns bring people who sign up; they are not sent to Google or anyone else.

If you press Continue with Google. The click identifier, the site that sent you and the campaign number are not put in the link to Google. While you are on Google's page they wait on our server, in a temporary sign-in record that expires after ten minutes, so that they can be stored with a new account, or put back in the address of the page you return to if the sign-in does not complete. That record is deleted when your browser comes back from Google within five minutes, whether you approved or cancelled there; otherwise it expires after ten minutes and is deleted the next time our sign-in system clears out expired records. The values reach your user record only if a new account is created, which only the sign-up page does. The only thing we write to your device for this, until you are signed in, is the five-minute cookie described in section 08, which holds a random value, not these.

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 to provide the service, for the purposes below, and for the further purposes set out with their legal bases after them:

• 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 to send your DMARC report digests. Digests go out weekly by default, also to people given access to a workspace, until you change how often they come or turn them off in your email settings, or use the unsubscribe link in a digest.
• Aggregate-report data — to parse, store and visualise your DMARC reports so you can monitor authentication and improve your email security posture.
• TLS reports — to store and show you whether senders could deliver mail to your domain securely.
• Brand logo — to store the logo you upload and publish it so that mailbox providers can show it with your mail.

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, for the TLS reports you ask senders to send us, and for hosting the brand logo you upload.
• 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, a reference to your browser's User-Agent line, any campaign labels on the link 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.
• Surveys and Verify DNS presses — legitimate interest (Art. 6(1)(f) GDPR): the survey records described in section 02 let us learn what people need and tell real readers from mail scanners, the Verify DNS record lets us support you when a domain's setup breaks and restart the setup emails once your record looks right, and the stored Check record result lets the Encrypted delivery (TLS-RPT) card show what your DNS servers said after you reload the page, and the time of the last press limits how often the check can run. The survey and Verify DNS records are not shown outside our team; the Check record result is shown only to people in your account, on that card. If you would rather we did not hold your survey records, email [email protected] and we will delete them; a later survey, if you receive one, is recorded again.
• Knowing whether our Upgrade links help — legitimate interest (Art. 6(1)(f) GDPR): the click record described in section 02 lets us see whether people who click an Upgrade link inside the product go on to upgrade, so we can tell which of those links are worth keeping. It holds no IP address, is never shown outside our team and builds no profile beyond those clicks. If you would rather we did not hold it, email [email protected] and we will delete the click records we hold for you; a click you make after that is recorded again.
• 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 (the exceptions, each a single step done once, are the country correction and the ad-campaign recovery described in the next two points), and it is rotated away on the schedule in section 05.
• Knowing where our customers are — legitimate interest (Art. 6(1)(f) GDPR): the raw access log holds the address of every request, and the sign-in record described in section 02 the address of every sign-in, so we can run and secure the service. We also resolve the address your sign-up came from (or, if that cannot be resolved, your earliest sign-in's) once to a country so we can see which markets our customers come from and decide where to spend our effort. For accounts whose sign-up was still in the access log on 18 October 2026 we also corrected that country once from the log, as described in section 02. 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 addresses it comes from are 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.
• Knowing which of our ads brought you — legitimate interest (Art. 6(1)(f) GDPR): for accounts created before we started recording where you found us at sign-up (2026-10-13, 21:00 UTC), we recovered the ad campaign number once from our web server's access log, by matching the click identifier already on your account (section 02) with the link you arrived on. Only the campaign number was copied to your account — nothing else from the log — and it is deleted on the same schedule as the click identifier. This too is a second use of data we collected for running our servers, and it applies only to accounts that arrived through one of our ads. If you would rather we did not hold it, email [email protected] and we will clear it.
• Addresses we stop emailing — legitimate interest (Art. 6(1)(f) GDPR): for every email we send, we keep a record of what Postmark tells us when that email bounces or is reported as spam, or when Postmark stops or resumes delivering to an address, so that we do not keep emailing an address Postmark has stopped delivering to. This record is not deleted with the account or a user account, because without it we would start emailing those addresses again.
• Workspace sharing — performance of a contract (Art. 6(1)(b) GDPR) for access and each person's own email settings, and for the account owner's or an admin's use of sharing; legitimate interest (Art. 6(1)(f) GDPR) for holding and emailing an invited address before it is accepted (the account's interest in giving its team access, and ours in providing it), for the send records, which stop sharing being used to send unwanted mail, for our server's log lines about invitations and access (running and securing the service), for our copy of what Postmark tells us when an invitation email bounces or is reported as spam (so that our records match the addresses Postmark will no longer deliver to), and for the "joined by invitation" note, which keeps our sign-up figures honest.

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.

DNS lookups go to Google or Cloudflare. When one of our pages checks a domain's DNS records — the domain setup page once you add a domain and the domain settings page as it opens (the record you publish now and, on setup, which company hosts your DNS), Verify DNS, the BIMI section's Check again, the dashboard's DNS checks, the domain health card and the free tools — your browser sends the lookup itself to a public DNS-over-HTTPS resolver run by Google (dns.google, 8.8.8.8) or Cloudflare (cloudflare-dns.com, 1.1.1.1). That resolver receives your IP address, the name being looked up and what your browser sends with any web request, such as the site the request comes from; its servers may be outside the EEA. These lookups do not pass through our servers. Our server also looks up the DNS records of the domains in your account and the domain of the email address you sign up with — through the same two resolvers, except Check record and the BIMI section's Check again, which ask your domain's own DNS servers directly; those lookups carry the domain name and come from our server's address, not yours.

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 account'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, TLS reports, the plain-English summaries derived from them, and alerts; forensic failure samples have their own fixed 30-day window.

Existing accounts 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 described in section 02 is kept on your account for as long as the account exists and is deleted with it, so after those 90 days the country on your account is all we still hold about where you signed up and signed in from, along with the country noted for each remembered browser if you use two-factor authentication (see Cookies).

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. The record of where you found us (the referring site's name and the ad campaign number) is deleted at the same time, and so are the payment records kept for that measurement. All three automated deletions — the website-usage records, the sign-in addresses and these click identifiers — are monitored: a deletion that fails raises an alarm to us, and for the website-usage records and the sign-in addresses so does one that stops running.

Surveys and Verify DNS presses. Survey records — what was sent, your answers and the page openings — are kept for as long as your user account exists and are deleted with it. Because the survey record holds the name of your first domain as it was when we sent the survey, that name stays with the survey record if you later remove the domain, its workspace or the account, until your user account is deleted or you ask us to delete it. The Verify DNS record, the Check record result and the time of the last press live on the domain and are deleted when the domain is removed.

Brand logos. A logo is deleted when you delete it, or when its domain or the account is deleted. If the account moves to Free, logos already uploaded stay published until you delete them. If the user account of the person who uploaded a logo is deleted, the logo stays and no longer records who uploaded it; removing that person from the account does not change this. After a deletion, Cloudflare may serve a cached copy for up to five minutes, and mailbox providers keep their own copies. The server log lines about uploads and deletions stay in its system log until the oldest entries are removed to keep that log within its size limit.

Upgrade clicks. The click records described in section 02 are kept for as long as your account exists and are deleted with it — or earlier, with your user account, if that is deleted. Deleting a workspace or a domain does not delete them; deleting a domain only removes which domain page a click was on.

Support email. Emails you send to our support or sales address, and our replies, are kept in our support mailbox at Zoho, in the United States (section 04), for as long as they are useful to answer you, and deleted on request.

Workspace sharing. The records described in section 02 are deleted as follows. The daily job described below is monitored: if it fails or does not run, it raises an alarm to us.

• Invitations are deleted by a daily job 30 days after they were accepted, canceled or expired, and at once if their workspace or account is deleted. Each resend sets an invitation's expiry to 7 days after that resend, so one that keeps being resent stays until it is canceled or allowed to expire.
• The record of each invitation email sent is deleted by the same job 30 days after that send, and at once if the account is deleted. It is kept for those 30 days even when its invitation or workspace is deleted sooner, so that deleting an invitation cannot reset the sending limits.
• The invitation email itself, link included, is kept by Postmark for about 45 days after it was sent, like every email we send (section 04).
• The record of an invitation email that bounced or was reported as spam is not deleted automatically, like the same record for any other email we send — not even when the account or a user account is deleted.
• Access to a workspace lasts until it is removed (by the account's owner, or by an admin for a member of a workspace they administer), until the person leaves the account, or until the workspace, the account or the person's user account is deleted. While the account is not on a paid plan, access is paused, not deleted.
• A person's own email settings for an account are deleted in the same step that removes their last access to that account, and also when the person or the account is deleted.
• The "joined by invitation" note is part of the user record and is deleted with it.
• Our server's log lines about invitations and access, and the other lines described in section 02, stay in its system log until the oldest entries are removed to keep that log within its size limit. Lines that raise an internal alarm are also copied, with any email address removed, into an alarm email we send to ourselves.

Deleting a user account removes that person's own access and email settings at once. If they own an account, that account is deleted with them, and with it its invitations and send records. Invitations and send records in other accounts, including any that hold the deleted person's address, are not deleted early: they follow the schedule above. In those accounts, an invitation the deleted person created or accepted, and access they gave to others, stay, without the link to that person's user record; an invitation they accepted still holds their address until the schedule above deletes it.

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. A paid subscription has to end first (see the Terms of Service).

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. Apart from the tokens in links we email you, described below, 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 — one that lets that browser skip the code. It lasts thirty days from your most recent sign-in on that browser and is renewed each time you sign in there, so a browser you keep using is not asked again. Both are Secure, signed and backed by a server-side record. The ten-minute one is cleared as soon as you finish signing in. A remembered browser stops skipping the code the moment you remove it under Trusted devices on your account page, forget all devices, or disable two-factor (a browser may keep the dead cookie until it expires); signing out alone does not remove it. Neither cookie identifies you to anyone but us.

So that you can recognise a remembered browser in that list, we note, when it is remembered and each time it signs in, its browser and operating system (from the User-Agent it sends) and the country that sign-in came from. We do not keep the IP address for this — only the country worked out from it — and the note is deleted together with the remembered device.

Pressing Continue with Google sets one more short-lived cookie, __Secure-better-auth.state, for five minutes. It holds only a random value, signed by our server, that ties Google's answer to the browser that started the sign-in. It is Secure and cannot be read by scripts on the page. It is cleared when Google sends you back to us, and in any case expires after five minutes.

Apart from these cookies, our pages keep a secret in your browser only when you open a link we emailed you that carries one. The pages opened from an email-verification, password-reset or survey link take the token out of the address bar as soon as they open (if your browser does not allow that, it stays in the address bar) and keep it with that page in the tab, so that reloading the page still works, until you close the tab (the password-reset page lets go of it once your new password is saved and it moves you on to sign in); your browser's own history list may still record the link as you opened it. The invitation page does the same with an invitation link's secret and, if you are not signed in, keeps it in that tab's session storage instead (if your browser refuses that storage, the copy kept with the page stays), so that it can finish after you sign up or sign in; these copies are removed when you join on the invitation page, when it finds that the invitation is no longer open, or when you choose to set up your own workspace instead, and if you leave it without finishing there, a copy can stay in that tab until you close it (section 02). None of these is a cookie. Your browser removes them when you close the tab, unless it later restores or duplicates that tab, which can bring them back with it.

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. An email sign-up confirms its address through the link we send; a sign-up with Google is accepted only when Google has verified the address.
• Passwords are hashed and never stored or logged in plain text.
• Optional two-factor authentication. You can add a second step to sign-in: a code from an authenticator app (with ten backup codes) or a code sent to your account's email address, valid for five minutes and void after five wrong attempts. The app's secret and the backup codes are stored encrypted, and an email code only as a hash. It is not available for an account that signs in with Google: a Google sign-in is protected by your Google account, so turn on 2-Step Verification there. If you also set a password for such an account, signing in with that password has no second step.
• 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, using your server-side session, to an account you own or to the workspaces shared with you, 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].