Cookie policy

There is no consent banner

dotvitals shows no cookie banner because nothing on the site needs consent. Under the EU and UK ePrivacy rules, consent is required before storing or reading anything on your device that is not strictly necessary for a service you asked for. dotvitals sets four cookies at most, two of them only after you have verified that you control a domain, all of them strictly necessary, and runs analytics that store nothing on your device at all.

You can check that rather than believe it. Open your browser's developer tools on any page of this site, look at storage and at the network requests, and compare what you find with the list below.

The cookies dotvitals sets

Two on every visit, both first-party, both strictly necessary, neither used for advertising or for tracking you across other sites:

• dv_sid — an anonymous session marker. It holds a random, signed value and nothing else: no name, no address, no history. It exists so rate limits apply to one browser rather than to everyone sharing your network address, and so you can return to a scan you just started. HttpOnly, SameSite=Lax, Secure, expires after 30 days.
• dv_clr — a short-lived proof that this browser passed the browser check, so a second scan within half an hour does not run it again. Set by the API on api.dotvitals.com the first time you start a scan. HttpOnly, SameSite=Lax, Secure, valid for 30 minutes, and shorter when the service is under load.

Blocking either is allowed and the site keeps working, but you may be challenged more often, and you will be rate limited alongside everyone else on your network rather than on your own budget.

Two more, only after you verify a domain

If you prove that you control a domain — by publishing the record, file or tag a report asks for — two further cookies are set, so that this browser can use that verification without you keeping any secret yourself. Neither is readable by page script, neither is set for anyone who has not verified a domain, and both are removed by the controls beside the verification:

• dv_own — set by the API on api.dotvitals.com, for the API alone. It carries the credential for up to eight verifications, so a scan you start from this browser can name one of them and run the checks reserved for a verified owner. HttpOnly, SameSite=Lax, Secure, sent only to the API's /v1 paths, expires with the verification.
• dv_read — set by the site on www.dotvitals.com, for the report pages alone. It carries a read-only key for the same verifications, so a report that only its owner may read can be shown to this browser. It cannot start a scan, share a report or revoke anything. HttpOnly, SameSite=Lax, Secure, sent only under /scan, expires with the verification.

Each verification works in the browser that made it and nowhere else: the credential is never shown to you, so it cannot be copied to another device or recovered after you clear your cookies. To use a domain's verification somewhere else, verify it there, which means publishing a new record. "Forget this verification on this device" clears both cookies and leaves the verification in place; "Revoke" ends it everywhere.

Three things that are not cookies

All three are your browser's local storage rather than cookies, which means they are readable only by this site's own pages and are never attached to a request: they do not reach our servers at all, and we could not read them if we wanted to. Clearing your site data removes all of them.

There is one exception and it is worth stating precisely, because the sentence above would otherwise be slightly untrue. If you ask us to delete one report — from its row in the home page list, or from the report's own page — that request carries that report's id and its one-off key, because those are what identify the report and prove it is yours to delete. Nothing else goes with it: not the rest of the list, not how many entries it has, not which other reports you hold keys for, not the fact that you keep either. Reading the list, drawing it, exporting it and clearing it still send nothing at all, and neither does deciding whether to offer you that control — the report page reads your own browser to answer that and never asks us.

• dv-theme — your light/dark choice, if you use the switch. One word.
• dv-proof-until — kept in this tab's session storage rather than with the others, so it disappears when the tab is closed. It is the time until which the page treats the browser check as already passed — 25 minutes, inside the half hour dv_clr lasts — so a second scan does not load anything from Cloudflare. A time and nothing else.
• dv-scans — the list of recent checks the home page shows you. It holds, for up to twenty checks, the report's id, the domain and when the scan started; it holds no score and no key. For a check this browser started itself it also holds the id of the previous check of the same domain, so the list can offer a before-and-after. Entries are dropped after the report's 14 days, the list can be exported or cleared from the home page, and we hold no copy of it — there is no history of your scans on our side to ask for or to delete.
• dv-scan-keys — the one-off keys for checks this browser started itself, up to two hundred of them: a report's id, when its scan started, and the key. A key is what lets this browser — and only this browser — delete that report from our servers ahead of its deletion date, which is why it is not in the list above and not in the exported file. We store only a hash of it and cannot recover it, so a report whose key you clear simply waits for its own deletion date. A key is dropped once it has been used and, like the list, after the report's 14 days. Clearing your site data removes them. It is kept separately from the list because the list holds only twenty checks: your key for a report outlasts the row that linked to it, so a check that has dropped off the list can still be deleted early — from the report's own page, which offers the same control.

Analytics without cookies

dotvitals measures page views, load performance and a fixed list of product events. None of it sets a cookie, reads a cookie, or writes anything to your browser's storage; none of it fingerprints your browser; and none of it can identify you or follow you between sites.

Because nothing is stored on your device and no personal data is collected, it needs no consent under the ePrivacy rules — which is the second reason there is no banner. The privacy policy lists exactly which events are recorded and what each may and may not carry: in particular, never a domain you scanned, never a full URL, and nothing whatsoever from the email header analyzer.

No advertising cookies

dotvitals sets no advertising cookies. No ad script, no tracking pixel, no consent-management platform and no tag manager loads on any page.

Two advertising-related things are already in place, and neither loads anything or stores anything: /ads.txt, a plain text file naming who is allowed to sell advertising on this domain, and a meta tag carrying the same publisher id. They are there so the account is in order before the first ad is served. Your browser fetches no script for either.

That describes the site as it is today, not a permanent promise. If it changes, this page and the privacy policy are updated before anything loads in your browser, and they name the network and every cookie it sets.

Cookies set by others

dotvitals embeds no third-party content — no videos, no social widgets, no fonts loaded from another origin — that could set a cookie on its own behalf.

Cloudflare, which serves the site and provides the human-verification challenge, may set its own cookie as part of that protection, for example to remember that a browser passed a challenge. That is necessary for the site's security and is not used for advertising.

Browser controls

You can block or delete cookies through your browser's own settings at any time, and you can use a tracker blocker on this site without anything breaking but one thing: starting a scan needs the browser check to load from challenges.cloudflare.com. If a blocker refuses it, the page says so, nothing is checked, and allowing that one address for dotvitals.com fixes it; reports, the record generators and the email header analyser work either way. Because the two session cookies above are used for rate limiting and scan continuity, blocking them may mean more human-verification challenges; deleting the two verification cookies means verifying the domain again, since nothing can restore them.