Privacy policy

The short version

• There are no accounts, and dotvitals never asks for your name, email address or payment details.
• Your IP address is never written down. A salted hash of your network prefix is, and the salt rotates.
• Email headers you paste — into the header analyzer or into the DKIM checker's header page — are processed in your own browser and never reach us at all.
• Reports are private by default. Sharing one is something you have to do deliberately, and every share link expires.
• A scan record is deleted 14 days after it is created, by a job that runs every hour.
• No advertising, no ad cookies, no consent banner, and analytics that set no cookie and collect nothing about you personally.

What we store, per data class

The target you submit — the domain, URL or IP address you asked dotvitals to check. This is the input to the tool rather than information about you, though it can still be personal data when a domain identifies a person.

The scan result — the DNS records, headers, certificate details and other technical facts dotvitals observed about that target, plus a scan id, a timestamp, a score and the evidence behind each finding. This is information about the target's infrastructure, and all of it was already visible to anyone who asked the target the same questions.

The registry's answer about a domain — the RDAP or WHOIS response, in full, so that a lookup can show you what the registry actually said rather than only our reading of it. We store it exactly as the registry sent it and remove nothing from it. Where a registry withholds the registrant, what you see is the registry's own redaction, marked as theirs.

That has a consequence worth stating plainly rather than leaving you to discover it. A minority of registries still publish the registrant's name, e-mail address, telephone number and street address — .uk is one — and for those domains a scan stores those details, in the registry's response, for the scan's 14 days. They belong to a third party who did not ask to be scanned, and no check of ours reads them: they are held because the response is held whole, not because anything needs them. This was a deliberate choice — data a registry publishes to anyone who asks is public record, and a lookup that shows you an edited document while calling it the registry's answer is not telling you the truth. Since the ICANN Registration Data Policy took effect most registries withhold these fields, so for most domains there is nothing here to store. If it is your detail and you would rather it were not in a report, the registry is where to have it redacted at source, and abuse@dotvitals.com is where to have the report deleted.

The report itself shows two of those fields as fields: the registrant organisation and, where the registry publishes one, the registrant name. They are shown as the two separate fields the registry keeps them in — a record that publishes a name and no organisation is shown as having no organisation, not as an organisation called that name.

The parameters you chose for a check — the DKIM selector you asked us to look for, the DNS record type you asked us to trace. They are stored with the scan so that pressing "check this again" re-runs the check you actually asked for rather than the default one. They are parameters for checks we run, never free text: anything that is not a parameter of a known check is discarded before the scan is saved, and they are deleted with the scan.

A salted hash of the requesting network — not your address. The next section is about exactly that, and it is worth reading rather than taking on trust.

An anonymous session marker, kept in your browser rather than by us. The dv_sid cookie holds a random value and a signature over it and nothing else — no name, no address, no record of what you checked. What our side holds is a hash of that value in a counter, so that rate limits apply to one browser rather than to everyone sharing a network address. The cookie policy lists it, and the second cookie, in full.

An ownership verification, if you make one — the domain, the challenge value, the method that succeeded, and the evidence of the check.

A share link, if you create one — a hash of the link's token, the scan it points at, when it was created and when it expires.

We do not store your name, your email address unless you write to us, your precise location, a device fingerprint, or a profile of the domains you have checked.

Your IP address, and the two salts

There is no column anywhere in dotvitals that an IP address could be written into. The address that arrives with your request is used in memory — to apply rate limits and to decide whether to challenge or refuse the request — and then discarded. It leaves us in one place only: verifying the browser check that runs before every scan sends it to Cloudflare, which is named below with everyone else who receives anything. What can be stored is a hash, and the way that hash is built is what makes it safe:

• The address is truncated before it is hashed, to the /24 of an IPv4 address or the /48 of an IPv6 one. Hashing the full address and then throwing away part of the digest would still identify your exact address to anyone holding the salt; truncating first means the individual address is gone before the hash exists.
• The truncated prefix is hashed together with a secret salt that rotates. Without a salt, the space of /24 networks is small enough to enumerate in seconds, which would make the hash no protection at all. With one, and with rotation, hashes from one window cannot be linked to hashes from the next.

There are two salts, on two different clocks, and the difference is deliberate.

• The daily salt is used for anything that describes a scan — the hash stored alongside a scan record. Each day's value is randomly generated rather than worked out from the date, and it is deleted when the day ends, so there is nothing left to recompute it from: scan records from different days cannot be linked to one another, including by us.
• The abuse salt changes every 14 days and is used only for the rate-limit and abuse ledgers, never for anything stored with a scan. It is longer because a ledger that forgot every midnight could not notice a network that misbehaves every day; 14 days is the shortest window that outlives the longest block we will apply. The two are derived so their keyspaces are separate: an abuse key cannot be matched against a stored scan's hash.

A request whose address cannot be parsed is not exempt from limits. It is metered in one shared bucket with everything else we cannot key, which is a smaller budget than being identifiable earns.

Pasted email headers are never stored

The email header analyzer is the one surface on dotvitals that takes a piece of somebody's private correspondence, so it is built differently from everything else here.

The analysis runs in your browser. The code that parses headers is shipped to your tab and executed there. It makes no network request, touches no storage, and there is no endpoint on our side that could receive a header block. The headers are not stored, not logged, not cached, not indexed and not shared — because they never arrive.

Two things can leave your browser from that page, and only if you ask for them:

• IP addresses taken from the Received chain, sent one at a time for a reverse-DNS lookup. An address is not a message: it carries no subject, no correspondents and no content. It is used for the lookup and dropped — nothing writes it to storage and nothing logs it.
• The From domain, to read its published DMARC policy. That is a public DNS record about a domain, not about a person.

Both are optional and the analysis works without them; it reports those fields as not looked up rather than pretending it knows.

The DKIM checker can also read your DKIM selector out of a pasted header. That happens on a separate page built like the analyzer: it loads only its own code, runs no third-party script, shows no cookie banner and sends no analytics. The header is read in your browser and never sent. To check the signature, the page asks our API for one public key, sending only the domain and the selector; nothing is stored or logged. A link back to the DKIM checker carries the same two values and nothing else, and the check you run there is stored like any other. Everything else that page shows about the header is worked out in your tab and gone when you leave it.

A header analysis can never be saved or shared, and that is enforced in the storage layer rather than left to the page: the write path refuses any result belonging to the analyzer by name, and a report holding one is refused a share link.

Reports are private by default

Running a scan publishes nothing. A report is reachable by its scan id, which is random and unguessable, and by nothing else: every report page is served with no-store and noindex, is excluded in robots.txt, appears in no sitemap, and is linked from no public page. Search engines do not have your report, and dotvitals publishes no directory of scanned domains.

Sharing is a separate, deliberate act. A share link exists only if you asked for one. It is a different token from the scan id, and only a hash of it is stored, so the plaintext link exists on our side for exactly as long as it takes to hand it back to you.

Every share link expires. The default is 7 days. You can ask for as little as 5 minutes or as much as 14 days, and whatever you ask for is capped again by the report's own retention window: a link cannot outlive the report it points at. There is no such thing as a permanent share link, and you can revoke one at any time.

Anyone holding a share link can read that report, so treat it as you would any unguessable URL.

A scan run under a verified ownership is stricter still: it holds results an anonymous visitor is deliberately not given, so the scan id alone does not open it and the ownership grant is required.

How long we keep things

A deletion job runs every hour. Before it existed these periods were written down and nothing was actually deleted; saying so here is part of the point of this page.

• Scan record — the row, the module results, the parameters the scan ran with, the finding index and the stored evidence: 14 days from creation, then deleted. The stored objects are deleted before the row that names them, so nothing is left in a bucket with no record of it.
• Share link: what you asked for (default 7 days, at most 14), never beyond the scan's own window. A revoked link is removed at the next sweep, and deleting a scan deletes its links.
• Ownership verification, not yet completed: 7 days to finish it, then it expires.
• Ownership verification, completed: re-checked every 30 days; three consecutive failures mark it failed, and 7 days after that it expires. Expired and revoked records are deleted 7 days later.
• Live scan progress events: held by the coordinator for 1 hour after the scan finishes, then deleted.
• Cached check results: each check's own cache lifetime, at most 24 hours, expired by the store itself rather than by a job.
• Rate-limit counters and abuse ledgers: keyed on the 14-day abuse salt, and each one deletes itself two days after the last request it saw — eight days instead, while a block is actually in force, because a block that forgot itself before it expired would not be a block.
• Short-term traffic counters used to watch the service's own health: 60 one-minute buckets, so one hour, and they hold counts rather than requests.
• Pasted email headers: never stored, so there is no period.
• Analytics: aggregate counts with no identifier in them, retained by Cloudflare under its own retention for the products named below.

If you report abuse to us, or we open a case from a report, the evidence for it is the correspondence and what was noted from it. There is no abuse-case database on this site: it is held by a person, in a mailbox, and kept while the case is open and for 90 days after it closes — a commitment a person keeps, rather than a job that enforces it as everything else on this list is.

Analytics

dotvitals measures how the site is used with two things that are both cookieless and both incapable of identifying you.

Cloudflare Web Analytics counts page views and measures load performance. Cloudflare states that it uses no client-side state — no cookies, no local storage — and does not fingerprint visitors by IP address or user agent. Nothing it records is tied to a person across visits.

Our own product counters record that something happened, from a fixed list of events: a scan was started, a scan finished, a tool was used, a suggested fix was copied, a re-test was clicked, an error was shown. Each carries the page template it happened on (for example /tools/[tool]) and, for some, the name of the tool or module involved.

What those counters deliberately never carry:

• No domain, URL or IP address you scanned. The event says a scan completed, not what it was about.
• No full URLs and no query strings, which is where a target would otherwise leak. Only the route template is recorded.
• No cookie, no session id, no visitor id and no address. The request is sent without credentials, so it cannot be joined to anything else about you.
• Nothing at all from the email header analyzer. That page sends no product event of any kind, and that is enforced in the code rather than left to whoever adds the next event.

Because these counters carry no identifier, they cannot be used to build a profile, and there is nothing in them to hand to an advertiser.

Where the processing happens

The site, the API and the storage run on Cloudflare's global network, which serves each request from a location near you.

The active probes — DNS, SMTP, port checks, TLS enumeration, blocklist lookups and the browser page load — all run on one machine in Amsterdam, Netherlands, in the EU, at 209.71.105.67 and 2a09:8280:e601:1:0:190:4889:0. If you are asking the data-transfer question: that machine is in the Netherlands, whatever the IP-geolocation databases claim about its address.

Cloudflare's network is global, so the edge that handles your request is the one nearest you — which is the point of it, and which means the handling can happen outside the EEA if that is where you are. Cloudflare and Fly.io process on our instructions, under their own published data-processing terms; neither decides anything about you on its own account.

dotvitals is built and operated from Romania. The probe machine is in the Netherlands, and both are in the EU.

Who else receives anything

The list is short, and it is exhaustive.

• The target you asked us to check. Obviously: a diagnostic tool that did not contact the target would be reading tea leaves. The target sees our probes, from the addresses on the scanner policy page. It sees nothing about you.
• Cloudflare hosts the site, the API and the storage, provides the browser check (Turnstile), and provides the analytics described above. It processes requests on our behalf.
• The browser check runs on every scan, not only when something looks wrong. Until 1 October 2026 it ran only when a visitor's traffic looked suspicious; since then, starting a scan, re-testing a check or verifying a domain first runs Cloudflare Turnstile in your browser, so that the request is known to come from a person's browser rather than from a script. It runs invisibly in almost every case: your browser loads it from challenges.cloudflare.com and sends Cloudflare the signals it uses to tell a browser from a bot, and Cloudflare answers with a one-time token that we check with Cloudflare before anything is scanned. It is loaded on the scan page and the checker pages when they start a check, and on a report only when you reach for a re-test or verification control; it is never loaded on the email header analyser, and once you have passed it this tab does not load it again for 25 minutes. One detail belongs here rather than in a footnote: when the token is verified, your full IP address is sent to Cloudflare as part of verifying it. That is the one place a complete address leaves the request — to the company whose network delivered the request to us in the first place, and which therefore already had it.
• Fly.io hosts the probe machine in the Netherlands. It provides the server; it receives nothing about you.
• Public DNS resolvers — Cloudflare, Google and Quad9, over DNS-over-HTTPS — answer the name lookups a scan needs. They see the names being looked up, which are the target's, not yours.
• Registry and registrar RDAP servers, reached through IANA's public bootstrap registry, answer the registration lookup. They see the domain being looked up. No WHOIS server is contacted: a registry that publishes no RDAP service is simply not asked, and the report says so.
• DNS blocklist operators — Barracuda, DroneBL, PSBL, blocklist.de and UCEPROTECT — answer whether a mail server's address is listed. They see that address, which belongs to the target's mail infrastructure.
• Google's Chrome UX Report API, where it is configured, answers what real Chrome users experienced on a URL. It receives the URL being checked.

That is the whole list. There is no advertising network, no consent platform, no tag manager, no session-recording tool, no A/B testing service, no customer-data platform and no IP-geolocation provider on dotvitals today. Nothing about you is sold, and nothing about you is shared with anyone not named above.

If an advertising network is ever added, this section and the cookie policy name it specifically, and the consent question that governs it, before it goes live rather than after.

No accounts

dotvitals does not require, or currently offer, an account. Everything above describes anonymous use. If accounts are introduced later (for saved history, higher limits or an API key) this policy will be updated first, and account data will follow its own, separately documented retention rule.

The list of recent checks on the home page is not an account and is not a record we keep. It is written by your own browser into its local storage (dv-scans, described on the cookies page), it is never sent to us, and we have no way to see it, link it to you or restore it. It is a convenience on one device, not a backup: the durable handle for a report is its own link, which you can bookmark.

One action does reach us, and only when you take it. A check your browser started can be deleted from our servers ahead of the retention window — from its row in that list, or from the report's own page — which sends that report's id and the one-off key your browser was given when the scan started, and nothing about the rest of the list. The key is why this is safe to offer without an account: a report's id is readable by anyone holding it, so if the id were enough, every link you shared would be a delete button for whoever received it. We store only a hash of the key, so nobody but the browser that ran the scan can use it, and we cannot delete a report on your behalf on the strength of an id.

Your browser keeps those keys separately from the list, so a check that has dropped off the end of the list can still be deleted early. Nothing about either store is sent to us, and the report page never asks us whether your browser holds a key: it looks in your own browser and nowhere else.

Your rights, and the one thing we cannot do

Depending on where you live you have rights over personal data about you: to see it, to have it corrected, to have it deleted, to object to what is done with it. Those rights apply here. What follows is what each of them comes to against a system built the way this one is.

Start with the salt, because everything else follows from it. The day's salt is 32 random bytes, held in one cache entry that expires just after midnight UTC. It is generated, not derived — not from the date, not from anything else we keep — so when the entry expires the salt stops existing and the hashes written under it can never be recomputed by anyone, including us. Hand us your address today and we could work out today's hash. Hand us the same address tomorrow and there is nothing left to compare it against.

An erasure request about that hash therefore has a specific answer. The GDPR provides for this case: where a controller can show it is not in a position to identify the person behind the data, the rights in Articles 15 to 20 do not apply to that data unless you can supply something that identifies the record (Article 11). We are in that position by construction rather than by luck, and we will not ask you for your address or a copy of anything in order to go looking. Collecting more about you to honour a request about less is the wrong trade, and it is the trade this design exists to avoid.

That still leaves a good deal we can do, and this is the list:

• A report, if you hold its scan id or its link. That identifies the record and nothing about you has to. Write to contact@dotvitals.com and it is deleted, by hand: there is no self-serve delete button on this site. Otherwise a report goes on its own 14 days after it was created, whether or not anyone asks.
• A share link, which you can revoke yourself at any time without asking anybody, and which expires regardless.
• The session cookie, which you end by clearing this site's cookies in your browser. Nothing on our side outlives it but a hash of it in a counter that deletes itself within two days of your last request.
• A question about this policy, an objection, or anything you think is wrong here: contact@dotvitals.com, and it is read by the person who wrote it.

You can raise a concern with a data protection authority in your country at any time.

Who is responsible for this

The controller for everything described on this page is the person who operates dotvitals, from Romania. There is no company. Write to contact@dotvitals.com about anything on this page, and it reaches that person and nobody else.

The operator's full identity is provided to a data protection or other supervisory authority that asks for it, and on a legitimate legal request.

No data protection officer has been appointed.