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 analyzer 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 30 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 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 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. 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.

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 30 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: 30 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 30), 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 expired by their own timers; no individual enforcement decision is recorded for longer than 30 days.
• 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 or we open a case, the evidence for that case is kept while the case is open and for 90 days after it closes.

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.

TODO (owner): if the operator is established outside the EU/EEA, the international-transfer statement and the transfer mechanism relied on for Cloudflare's processing must be added here before launch, alongside the controller identity below.

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 anti-abuse challenge (Turnstile), and provides the analytics described above. It processes requests on our behalf.
• 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/WHOIS servers, reached through IANA's public bootstrap registry, answer the registration lookup. They see the domain being looked up.
• 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.

When an advertising network and a consent platform are added, this section and the cookie policy will name them specifically, before they go live.

No accounts at launch

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.

Your rights

Depending on where you live, you may have rights over personal data relating to you — access, correction, deletion, and objection to certain processing among them.

Be aware of what dotvitals can honestly do. There is no account, no address is stored, and the hashes that are stored are salted with a rotating secret, so in the general case we cannot find which records relate to you — and we will not ask you for more personal data in order to try. If you can point to a specific scan or share link you created, by URL or scan id, write to contact@dotvitals.com and we will act on it.

You can also ask questions about this policy, or raise a concern with a data protection authority in your jurisdiction, at any time.

Data controller

TODO (owner): identify the data controller here before launch — the legal entity or individual responsible for the data described on this page, its contact details, an EU representative if the controller is established outside the EU/EEA and processes EU/EEA personal data (Art. 27 GDPR), and a data protection officer if one is required or appointed. This paragraph must be filled in, with counsel review of the legal-basis statements above, before this policy can be relied on for a live launch.