Acceptable use policy
dotvitals sends real traffic to real servers. This policy is about the question that follows from that: are you allowed to test the thing you are testing?
Last updated
Who this applies to
Anyone using dotvitals — the website, its API, and any tool it exposes, whether or not you have an account. It is incorporated by reference into the terms of service, so breaking this policy breaks those terms.
You must be authorised to test the target
This is the rule the rest of the page elaborates. Every time you submit a target you are asserting one of two things.
- You own the target, operate it, or have permission from whoever does. Your own domain, your employer's infrastructure where that is part of your job, a client's systems you have been engaged to assess. If you would have to explain yourself to the owner afterwards, get permission first.
- Or the check is an ordinary, read-only observation of something the target publishes to everyone — the kind of lookup any visitor's browser or any mail server performs in the course of dealing with that site.
Authorisation is yours to have, not ours to verify. dotvitals cannot tell whether you had permission, which is exactly why it is stated as your obligation, and why the un-gated checks are bounded so tightly that an unauthorised one does as little as possible.
What you may point it at
Without proving anything, you may run the standard, bounded, read-only checks against a domain, host or IP address:
- DNS and DNSSEC lookups, and the DNS-published email policy records.
- One HTTP request to the homepage, and the redirect chain it produces.
- A TLS handshake and a read of the certificate and supported protocols.
- An SMTP EHLO and STARTTLS to the published mail servers, with no message ever sent.
- A connect-only check of the short published list of common ports.
- A single page load in a browser, for the performance measurement.
- Registration data (WHOIS/RDAP) and mail blocklist lookups, neither of which touches the target at all.
These are things a browser, a mail server or a DNS client already do. That is the deliberate ceiling: the un-gated checks are limited to what the target already answers for anyone.
What requires proving you own the domain
Anything beyond that ceiling is gated behind ownership verification, which means publishing a DNS record or a file we name:
- Port checks outside the published common-ports list.
- Repeated or scheduled checking of the same target.
- Results an anonymous requester is deliberately not shown.
A verification is re-checked periodically and lapses when control of the domain does. It is per-domain: verifying one domain grants nothing about any other.
What you may never do
Regardless of who owns the target, and regardless of whether you verified it:
- Use dotvitals against a target you are not authorised to test, including as reconnaissance ahead of an intrusion or to check whether an exploit would land.
- Use dotvitals as a proxy, relay or amplifier for traffic aimed at somebody else — to generate load against a target, to obscure the origin of your own probing, or to make dotvitals the party that appears in a stranger's logs instead of you.
- Run bulk or automated scans across many domains you do not own or have permission to test, or scrape dotvitals' results at scale.
- Attempt to go beyond the read-only checks — exploit a vulnerability, brute-force credentials or directories, fuzz an endpoint — even against a target you own. That testing is out of scope for this tool, and dotvitals is not the place to do it.
- Circumvent rate limits, human-verification challenges or ownership verification, including by rotating addresses, sessions or browsers to evade a limit.
- Harass or surveil a person — repeatedly checking an individual's personal domain or mail infrastructure, or gathering information about it with the intent to cause harm.
- Interfere with dotvitals itself — exhaust scanner capacity, probe our internal systems, or automate requests in a way designed to degrade the service for others. Genuine security research on dotvitals is welcome through the contact in /.well-known/security.txt; doing it without telling us is not.
- Use the email header analyzer on correspondence you have no right to read. It runs in your browser and we never see what you paste, which is a privacy protection for you rather than a licence to analyse other people's mail.
We rate-limit, and we may refuse
dotvitals limits how much scanning any one visitor, network or target can cause, and those limits apply to everyone. Two are worth stating plainly because they are often assumed away.
- A target's budget is shared across all visitors. Repeated checks of the same domain are served from a short cache instead of re-probing, so a domain cannot be hammered through dotvitals by many people at once. That limit protects the target, who has no say in who asks about them.
- A refusal is a normal outcome. dotvitals may throttle you, challenge you, block you temporarily, or decline a specific target — because it has opted out, because the service is under load, or because the pattern looks like reconnaissance. There is no entitlement to have any given check run.
Enforcement escalates rather than starting at the top: a delay, then a challenge, then a temporary block, sized to what the behaviour warrants. Automated blocks are time-bounded, and nothing is blocked permanently without a person reviewing it first. A confirmed abuse report from a target's owner, or a clear match to the prohibited uses above, can shorten that ladder to an immediate block while the case is reviewed.
If we scanned you: contact and opt-out
If dotvitals probed infrastructure you operate, you do not have to work out who to ask.
- Our probes come from 209.71.105.67 and 2a09:8280:e601:1:0:190:4889:0, in Amsterdam, Netherlands, carrying the user agent "dotvitals/1.0 (+https://www.dotvitals.com/scanner/)". You can allow-list or block those addresses, and blocking them is a legitimate choice we will not try to work around.
- The abuse contact is abuse@dotvitals.com, published here, on the contact page, on the scanner policy page and in /.well-known/security.txt. It reaches a person.
- To opt a domain out entirely, write to that address from an address at the domain, or publish a DNS TXT record we will give you. Once opted out, dotvitals refuses to run active checks against that domain and says so to whoever asked. We verify control first, because an opt-out anyone could request for anyone else's domain would be a censorship tool.
- Opt-outs are handled by a person and do not take effect instantly. If you need the traffic to stop this minute, block the two addresses above; that works immediately and needs nothing from us.
The scanner policy page explains what each probe does, which checks come from that machine and which come from Cloudflare's shared network, and how to ask what a specific scan id did.
Appeals
Every rate-limit or block response carries a request id. If you believe you were throttled or blocked in error — because you share a network with other dotvitals users, for instance — write to abuse@dotvitals.com with that id and an explanation.
Automated blocks expire on their own, so an appeal is worth making but waiting is usually faster for a short one.