Understanding Results
Risk score and verdict
scoreis a 0–100 risk score (higher means more risk).- The portal groups scores into practical verdicts:
- ~0–20: likely safe
- ~21–69: caution
- 70+: avoid
Flags (findings)
flags is a list of short codes describing findings. Common prefixes include:
whois:registration age/owner signalsdns:DNS configuration and typo-squatting signalsssl:TLS certificate and HTTPS posture signalscontent:page/content signals (login forms, suspicious keywords)redirect:redirect-chain behaviorsblocklist:andthreatfeed:matches against threat intelligence
Flags are meant to be actionable: treat them as “reasons” to confirm/deny a verdict.
Site hygiene is not phishing evidence
headers: findings (a missing Content-Security-Policy, no HSTS, a missing
Cache-Control, and similar) describe how well a site is hardened, not whether it
is trying to phish you. A site can be perfectly safe and still miss headers.
Because of that, hygiene findings:
- appear in their own Security Hygiene panel, never in the phishing evidence list,
- carry their own severity words (Hygiene: High / Medium / Low), which are deliberately different from the verdict words (Safe, Caution, Avoid), so a high-severity hygiene gap never reads as “this site is dangerous”,
- come with a plain description of the finding and a How to fix line,
- are labelled Not phishing evidence on every row.
Evidence shown for a result is never louder than the verdict itself: a Safe result will not display critical-looking findings.
Reading the Category Breakdown
The Category Breakdown chart shows which evidence categories contributed the risk points, not how dangerous the result is.
- Each category always keeps the same colour, so “Security hygiene” looks the same on every scan.
- Chart colours are only identities. They never reuse the verdict colours, so a wedge cannot be mistaken for a danger signal. A Safe result with only hygiene findings shows one calm wedge, not a red circle.
- Less common categories are grouped into a single neutral Other wedge. The Why this score table below the chart always lists every category with its exact points, so nothing is hidden.
- The score shown in Why this score is coloured to match the verdict chip.
EvidencePack summary (what it is)
When available, the scan output includes an EvidencePack (Dralvia's exportable evidence report) summary that:
- Records the high-level verdict and top reasons
- Captures supporting artifacts (redirect chain, content signals, screenshots/metadata when available)
- Provides persona-ready rationales (exec/security/compliance) for easier communication
Recommended next actions
The result shows a single Recommended next step at the top (the headline and a one-line explanation of the verdict), and the full list of steps once, in the Next Steps panel. A step is never repeated in both places. If a scan returns no specific steps, the top bar falls back to general guidance for that verdict, so there is always a recommendation.
That fallback was firing far more often than it should have been. Whenever a result carried a security-hygiene note — most commonly because the security-header check did not finish for the host — the scan's own analysis was being discarded on its way out of the scanner, and the report fell back to the generic advice for that verdict.
The report still looked complete, which is why it was easy to miss. What was missing on those results:
- the Recommended next step headline written for that scan, and its Next Steps,
- the Key Evidence list (each finding with its point weight and plain description),
- the evidence-panel category breakdown.
The verdict, the score, the flag list, the Security Hygiene panel and the main Category Breakdown chart were never affected — only the written explanation.
Nothing about how sites are scored changed. A result you re-scan now will show the same verdict, with the explanation that was always meant to accompany it.
A page on a hosting platform does not inherit the platform's history
An old, well-established domain is treated more leniently than a brand-new one. That leniency belongs to whoever registered the domain — and on a hosting platform, a subdomain belongs to whichever customer signed up for it, possibly minutes ago.
Dralvia therefore refuses to let a subdomain borrow its platform's registration age. A page on a site builder, an object-storage bucket, or a hosting control panel is judged on its own.
That refusal was matched against an exact list of platform addresses, so regional addresses for the same platform were missed. Two storage buckets on the same provider, with the same 21-year-old registration behind them, were treated differently purely because of how their address was written — one was correctly judged on its own, the other inherited the full 21 years.
31 platform addresses had the same gap, including major cloud storage, site builders, hosting panels, VPS hostnames and free-subdomain services. Each is now matched at the provider level, so a new region or service cannot reopen it.
This makes results on those platforms stricter, never more lenient, and it does not affect a company's own subdomains on its own domain.
The Recommended Action follows the verdict
The verdict and the Recommended Action now line up by design, at every band:
| Verdict | Score | Recommended Action |
|---|---|---|
| Safe | 0–20 | Allow |
| Caution | 21–69 | Review |
| Avoid | 70–100 | Block |
A specific, actionable finding can still raise the recommendation above the band — a page actively capturing credentials, a fake sign-in flow, a seed-phrase prompt, or a listing in a curated threat feed all recommend blocking at any score, because those name a concrete thing to act on rather than a total.
All three edges were set to numbers that had drifted from the bands, so a report could disagree with itself in either direction. Caution results scoring 21–39 were the largest group: they were told "No dominant phishing posture is controlling this result" and to allow normal access.
That happened because the recommendation was decided from a fixed list of page and redirect findings, and these results score on things that list never included — how recently the domain was registered, an invalid certificate, or infrastructure already shared with known-bad sites. Sites affected included domains registered days earlier with wallet- and account-security-styled names, and hosts sharing a fingerprint with confirmed malicious infrastructure.
The recommendation is now taken from the verdict band itself rather than from a list of findings, so it cannot drift away again as new checks are added.
A Safe result is allowed to keep its Allow recommendation when the only thing found is a single signal that is ordinary on a legitimate site, such as a sign-in prompt. Two or more such signals together still asked for review, on the reasoning that a cluster means more than one part.
Two of those signals carry no weight in the score at all. One of them is raised whenever a page stores anything in the browser, which includes setting a cookie, so it is present on essentially every site with JavaScript. Paired with a sign-in prompt, it made "a login page that sets a cookie" look like a cluster.
The effect was that clean, score-0 results were told a human had to review them. Apple's home page was one. Microsoft Azure, Microsoft Support, GitLab, Twitch and Asana were others, all scoring between 0 and 20.
Signals are now counted by the weight the score gives them. A finding the score treats as worth nothing cannot combine into a cluster either. Findings that do carry weight are unchanged, and a lure, a redirect signal, a lookalike name or a matching favicon still asks for review on its own at any score.
Checked by replaying the recommendation over every stored result: the only results that changed were the eleven of this exact shape. No result moved in the more permissive direction anywhere else, and no Avoid result has ever been recommended for Allow.
An Avoid verdict recommends blocking
The Recommended Action follows the verdict at both ends. Avoid starts at a score of 70, and every Avoid result now recommends blocking.
The block recommendation was keyed to a score of 75, not to the Avoid band, so
results scoring 70–74 were reported as Avoid while the recommended action
only asked you to review them. paypal.com.pt, at Avoid 73, is the example that
surfaced it.
795 results across 699 domains sit in that range. Most were already being blocked for a specific reason — a threat-feed listing, a credential-capture detection, a visual brand match — which is unchanged and still applies at any score. The remaining 316 results across 310 domains were being asked to review a site they had just been told to avoid.
Nothing below Avoid is affected: the change starts exactly where the band starts.
A Safe verdict does not ask you to review anything
If a scan comes back Safe, the Recommended Action says so. It no longer asks for human review of a site it just told you was safe.
Two things were causing that contradiction.
Writing a cookie counted as suspicious. Dralvia records when a page writes to
browser storage — cookies, localStorage, sessionStorage or IndexedDB. Nearly
every modern website does this, and the finding is worth almost nothing on its
own. It was nonetheless enough to demand human review, and it accounted for
95% of the affected results.
The rule only covered half the Safe band. Safe runs from 0 to 20, but the "don't escalate an otherwise clean result" rule stopped at 10, so scores 11–20 escalated regardless.
Across all 91,225 Safe results scoring 1–20, the share carrying a recommended action above "allow" falls from 12.4% to 0.3%. Nothing outside the Safe band changes at all — verified across 40,000 Caution and Avoid results, none of which moved.
What still escalates on a Safe result, deliberately: two or more findings together, and any single finding that is not ordinary on a real site — a document-share, parcel or streaming lure, a cross-domain redirect, a lookalike domain, a homograph, or another brand's actual favicon being served.
Every finding now explains itself
A finding with no explanation is just a scare word. Ten findings that appear in real scans had no description at all and showed as "No additional info." — two of them were serious enough to recommend blocking the site.
All ten now carry a plain-language explanation, including what the finding means and, where relevant, that it is normal on a legitimate site:
content:fake_auth_flowandcontent:credential_capture_active— the two that recommend blocking,content:storage_write,content:auth_flow_prompt,content:service_worker_registration,content:permission_prompt— recorded as context, explicitly described as normal on real sites,content:fingerprint_redirect_gate,brand:fake_tld_impersonation,dns:spf_presentanddns:dmarc_present— signs of ordinary email hygiene that count nothing against a site.
Every finding that can change a recommended action is now checked for an explanation automatically, so this cannot come back.
A brand's name in the text of its own site
Dralvia searches a page's visible text for the names of brands it tracks, and reports what it finds. That check is deliberately noisy — it is a plain word search, so a page containing the ordinary words "meta", "live", "apple" or "crypto" matches those brands. It carries very little weight for exactly that reason.
The Recommended Action did not treat it that way. On a domain Dralvia's registry confirms belongs to the brand itself, an ordinary word on the page still counted as evidence of imitation, and combined with one other mild signal it was enough to ask for human review of a site scoring zero.
The word match no longer counts as brand imitation on a domain the registry confirms the brand owns. Ownership comes from the registry, never from the page, so a lookalike cannot claim it.
Nothing else is relaxed. On a domain the registry does not vouch for, the same words escalate exactly as before. And on the brand's own domain a misspelling, a squat, a homograph, or that brand's actual favicon being served all still escalate — ownership excuses a word, not a lookalike or a copied asset.
Across every scan carrying a page-text brand match, 1,079 of 1,098 are unaffected. The 19 that change are three domains, all scoring zero.
Files hosted on a platform are not the platform
Threat-intelligence feeds list individual URLs. When those URLs point at content
uploaded under a large platform — a file on a code host, a document on a file
sharing service — the listing is about the file, not the site. Dralvia reports
that as its own finding, threatfeed:hosted_malicious_url, and deliberately
gives it low weight:
Threat intelligence lists specific files or pages hosted on this domain as malicious, but the entries point at content uploaded under it rather than at the site itself… Treat the site as usable and the individual link you were sent with care — scanning that exact URL will give you a verdict on it.
The score already worked this way, but the Recommended Action did not: any third-party listing, of any weight, produced "High-confidence phishing or credential-harvest behavior detected" and told you to block the host. So a report could say "treat the site as usable" and "block the URL or host" at the same time, on the same page.
The recommended action is now taken from the same weight the score uses, so the two cannot disagree. A curated feed listing (OpenPhish, PhishTank, URLhaus, Google Safe Browsing, VirusTotal, or a malicious external reputation verdict) still blocks on its own, at any score. A listing that only says files were hosted under the domain now follows the verdict: Caution results ask for review, Safe results do not.
Across every scan carrying a third-party listing, 6,691 of 6,738 are unaffected.
The 47 that change are all the hosted-files case, on 23 domains including
github.com, gitlab.com, bitbucket.org and mega.nz.
A site that could not be scanned has no verdict
If a host times out, fails DNS, or refuses the fetch, the scan does not finish and there is no risk score. That is not the same as a clean result, and the report now says so directly:
This site could not be assessed, so it has no verdict.
Treat it as unknown. An unreachable host can be offline, blocking automated visitors, or already taken down — and a phishing page that has just been removed looks exactly like a site that is merely down.
The report tells you which part failed (DNS, timeout, or fetch) in the reachability detail, and re-scanning later often resolves it.
These results previously fell through to the wording used for a clean scan ("No dominant phishing posture is controlling this result"), which read as a verdict of safe on a site nobody had managed to look at. Findings that were present still applied — a host on a threat feed is still reported as one, scanned or not.
- High risk: block/contain, and preserve the scan output (export or store JSON) for incident records.
- Medium risk: confirm with additional context (known sender, expected business process, recent domain creation).
- Low risk: allow, but consider monitoring if the domain is newly registered or the site changes often.
One brand, one finding
When a domain imitates a brand, Dralvia reports that as a single finding — "this name is one edit from binance", "this name puts coinbase next to a lure word". The finding names the brand and explains what was matched.
Dralvia's trusted-brand registry holds a few brands more than once, usually a
second row for the www. form of the same address. Eight brand names were listed
twice or three times, among them Amazon, Binance, Coinbase and Kraken.
Every one of those rows raised its own finding. A domain misspelling binance
produced three near-identical lines — a typo of binance.com, a typo of
www.binance.com, a typo of www.binance.us — and the risk score counted the
same fact once per line.
That changed the verdict, and it changed it for a reason that had nothing to do with the site being scanned. Measured on two live domains before the fix:
| Domain | Brand rows | Score | Verdict |
|---|---|---|---|
netflix-login.com | 1 | 35 | Caution |
binance-verify.com | 3 | 100 | Avoid |
The same shape of imitation, judged differently because of how many times a brand appeared in our own catalogue.
Findings are now counted once per brand name, however many rows the registry
holds for it, and the finding always names a real registration — never
www.<brand>, which is a hostname rather than a company. The other matching rows
are still recorded in the evidence, so nothing is hidden.
Two different brands remain two findings. A domain that puts paypal and amazon in the same name is doing two things, and both are reported.
What this changes for you. Some domains that scored Avoid only because a brand happened to be listed twice will now score lower, and some will fall into Caution. That is the intended behaviour: a finding about a domain's name is deliberately weighted so that a name on its own does not reach Avoid — Avoid wants corroboration from the certificate, the registration age, the hosting or the page itself. Those domains were reaching Avoid through a duplicate in our catalogue rather than through evidence.
A brand's own site was also affected. binance.com carried a finding saying it
impersonated www.binance.us — its own company. A domain that is itself in the
registry can no longer be reported as imitating another entry that shares its
name.
A certificate is judged against the site it came from
When Dralvia reports on a site's certificate, that certificate is fetched from the address you scanned, and the name on it is checked against that same address.
It was not. If the address you scanned redirected somewhere else, Dralvia followed the redirect, read the destination's certificate, and then checked that certificate's name against the original address. The names did not match, because they were never meant to.
A brand's country domain shows the shape clearly. cocacola.ro serves a
certificate that lists cocacola.ro among its names. Dralvia recorded
www.coca-cola.com's certificate instead, reported a name mismatch, and recorded
the wrong fingerprint. Because the fingerprint belonged to the destination, every
site redirecting to the same place looked like it shared infrastructure with the
others, which added a second finding on top.
Three findings came from that one mistake: the certificate name mismatch, the shared-infrastructure finding, and the certificate anomaly that is derived from them. 8,881 stored results across 582 sites carried the name mismatch.
Following the redirect was also the less safe direction. A phishing page that bounces you to a real company's site had that company's certificate read and reported as its own.
A site that serves no certificate of its own still has its canonical address checked, and the report now names which address the certificate came from. No name mismatch is raised from a certificate that was never asked to cover that name.
A finding cannot be its own evidence
Dralvia reports when several independent sites that are themselves judged dangerous all point at the same destination. That is how a campaign is spotted from where its links land.
The sites doing the pointing were counted even when the only reason they were judged dangerous was that they pointed there. Two of a company's own country domains could hold each other up with nothing underneath.
cocacola.ro and cocacola.com both redirect to www.coca-cola.com. Both were
misjudged for the certificate reason above, so both counted as dangerous sources.
Two sources is the threshold, so their own destination became a known-bad
destination, which added a large penalty back to both of them.
A site now counts as evidence only on the strength of what it shows on its own: an imitated brand name, a credential form, an invalid certificate. A real phishing page has those and still counts.
The record was also written once and never revised, so a single wrong result marked a site permanently. It is now updated on every scan, which means a corrected result repairs it automatically rather than needing manual work.
An abuse marker has to be a whole word
Some hosting providers advertise themselves in ways that are strongly associated with abuse. Dralvia names those markers in the evidence when it finds one.
The match was on any part of a word. One of the markers is nolog, for providers
advertising that they keep no logs. It matched Amazon Technologies Inc.
Across every hosting provider name on record, three matched that marker and all three were the word "Technologies" or "Technology". None was a genuine no-logs provider. A marker is now matched only where it stands as a word of its own.
The provider is still always named in the evidence. That part never depended on a marker.
When a finding is withdrawn, the report says so
A brand's own country site is a different registration from the brand's main
address. paypal.com.pt is not paypal.com, and by name alone it has the same
shape as a lookalike registration. Dralvia's first read of such a name is that it
imitates the brand.
What separates the two is where the address sends you. A brand's own country site hands you to the real brand. A lookalike never does, because handing the visitor to the genuine site captures nothing. So when a domain redirects to the very brand it appeared to imitate, Dralvia withdraws the imitation finding.
The finding is withdrawn, not deleted. It stays listed under the brand check so you can see what was considered, and it no longer counts towards the score.
The withdrawal worked correctly and was never explained. The brand check still listed "imitates paypal.com" while the verdict carried no brand finding at all, and the sentence explaining why was recorded internally and shown to nobody.
A reader comparing the two could only conclude that something had gone wrong. The explanation is now printed with the result.
Measured on the live service before the change:
| Domain | Score | Brand finding in the verdict | Listed under the brand check |
|---|---|---|---|
paypal.com.pt | 30, Caution | none | imitates paypal.com |
huawei.ro | 15, Safe | none | imitates huawei.com |
roblox.com.pt | 100, Avoid | imitates roblox.com | imitates roblox.com |
roblox.com.pt is the control. It does not redirect to roblox.com, so nothing
is withdrawn and its finding counts in full.
The withdrawal is also refused outright if the scan saw hostile behaviour on the page, such as a credential form, a threat-feed listing, or a visual match against a brand. A page cannot be both the brand's own redirector and a live phishing page, so a redirect cannot be used to shake off evidence that was actually found.
A subdomain does not inherit its parent's history
The rule above ("files hosted on a platform are not the platform") only applies to a site that is established. Dralvia works that out from its own signals: the domain is old and presents a valid certificate, or we have scanned it repeatedly and always found it clean.
Registration age belongs to the registrable domain, not to each subdomain under
it. Whoever owns example.com can create anything.example.com in seconds, and
that new name has no history of its own.
Age was being inherited. An operator registered a domain, waited, and then used throwaway subdomains under it to distribute malware. Each subdomain arrived carrying the parent's registration age, was treated as an established site, and had its threat-feed listing softened to "files hosted here". Nine such subdomains were served as Safe, every one of them carrying a live malware listing.
Against the live URLhaus feed that one registrable domain had 16 different listed subdomains carrying 16 listed URLs, which is one URL each. A genuine file-sharing platform looks nothing like that: its listings pile up on a single, stable hostname.
A subdomain now has to earn this treatment through its own scan history with Dralvia. A registrable domain still uses its own registration age, so the large platforms this rule was written for are unaffected.
Two other ways of telling these apart were tested against the live feed and rejected, because they do not work:
- Counting the listed URLs. Real platforms often have very few: 2, 5, and 7 listed URLs for three well-known services, against 6 for a malware host. No threshold separates them.
- Checking that every listed entry points at a path under the host. 17,862 of the 19,390 hosts in the feed look that way, because malware normally lives at a path. It is almost always true, so on its own it says very little.
The fix above was only half of the problem. Registration age stopped being inherited, but the scan history itself was still being read from the registrable domain. A subdomain could no longer borrow the parent's age, and could still borrow every clean scan the parent had ever received.
The effect was that a hostname nobody had ever scanned could arrive already trusted. Verified against the live service on 17 August 2026: hostnames invented on the spot under 59 different registrable domains were all treated as established before a single scan of their own existed.
There was a second effect that ran the other way. Reputation reads a bounded window of recent scans, and a frequently scanned parent filled that window. One subdomain in the live service data had eight scans of its own, the worst of them scoring 46, and every one of those scans had been pushed out of the window by the parent's 152. Its own worst result was invisible.
Scan history is now scoped to the exact hostname. Standing is earned by the host being judged, and a busy parent can no longer crowd out a subdomain's own record.
The registration side had one route left open as well. The August 14 fix stopped
subdomains on shared platforms borrowing the platform's age, but an ordinary
company domain is not a shared platform, so age was still flowing from every
domain to every subdomain under it. Checked on 17 August with names invented on
the spot: verify.wikipedia.org arrived carrying 9,347 days of registration,
login-verify-xyz.netflix.com 10,506, secure-account.stripe.com 11,297.
A hostname that does not exist has no certificate, so most of those did not
finish the test. Wildcard certificates change that: signin-update.emag.ro, a
name that has never been scanned and is not a service, was treated as
established. Dangling DNS records, compromised subdomains, delegated marketing
hostnames and customer self-service names all resolve and all present a
certificate, which is exactly the population this mattered for.
Registration now counts only for the domain that holds it. Of 52 subdomains carrying the capped score at the time, 31 held it purely on a parent's registration and none had a record of its own. Rescanning them, the cap was turning results of 41, 28 and 21 into a Safe 15, while the legitimate service subdomains in the same sample scored 17 and 20 on their own evidence and were unaffected either way.
A gap in our own coverage is not a finding about your domain
Some flags describe a check of ours that did not complete: a feed we could not reach, a WHOIS lookup that timed out, a page we could not fetch. Those carry no score, because they say nothing about the domain. They are shown so you can see what was and was not checked.
One of them could still change a verdict. blocklist:fetch_failed means our
copy of a threat feed could not be downloaded. For a well-known brand domain,
Dralvia normally sets the score to zero unless the scan found something serious,
and this flag was being counted as something serious purely because its name
begins with the same word as a real feed listing.
While that feed was unreachable, a trusted brand scanned during the outage would have been reported as Avoid, on a flag meaning only that we had not finished looking.
It had not happened: no stored scan carries the flag, so no customer saw this. It is fixed because it would have fired exactly when an upstream feed was down, which is the worst moment for verdicts to start moving.
A flag that carries no score can no longer override a trusted-brand result. Real evidence still does, at any score: a feed listing, a bad certificate, a very recently registered domain, or a malicious reputation verdict.