Client data in a tax practice is aggregated behind a handful of logins — e-Services, the e-file identifiers, the portal, the practice-management suite. Screening every hostname your staff and your clients hand you against a DNS-verified list of live phishing domains removes the destinations that already exist, before anyone types a password into one.
Most industries lose one account at a time. A compromised tax practice loses the entire client roster in a single event, and the clients find out months later.
Consider what actually sits inside a mid-sized practice at the end of an engagement. No individual client holds that combination in one place; their preparer does.
The identifiers that let a practice do its job are the same ones that make a stolen session valuable. Take over all three together and you have not stolen data, you have inherited the practice's authority to act.
That aggregation is the whole reason the profession is attacked the way it is. An attacker who successfully phishes an individual taxpayer gets one identity and has to repeat the effort for the next one. An attacker who phishes the person who prepared four hundred of those returns gets four hundred identities in one motion, pre-validated, formatted and cross-referenced.
The economics of the two attacks are not remotely comparable, and every attacker knows it. The firm is not being targeted because its own money is unusually accessible; it is being targeted because it is the concentration point for other people's.
The consequence is distributed in an unpleasant way. The clients bear the identity theft: a legitimately filed return bounces as a duplicate, a refund they were counting on has already been paid to somebody else, and the recovery process runs for a year or more.
The notification obligation, the difficult phone calls during the exact weeks it has no time for them, the professional-liability exposure, and the quiet erosion of the one asset a practice actually sells — the client's willingness to hand over everything. Neither party can undo the other's damage.
That is why the useful place to intervene is well before the credential is entered, not after. A known-bad domain lookup is a narrow tool aimed at exactly that moment. It does not judge whether an email is suspicious, whether a request is out of character, or whether a client is who they say they are. It answers one factual question about a hostname: is this specific host currently observed and verified as live phishing infrastructure? When the answer is yes, the destination stops being reachable and the sequence ends before there is a password to steal.
Impersonation of the IRS and of state revenue departments works on preparers for a reason that has nothing to do with carelessness. Correspondence from tax authorities genuinely does arrive unannounced, genuinely does cite a notice number the recipient has never seen before, and genuinely does impose a response window measured in days. A message saying a client's account is under examination, that a submission was rejected, or that an identity-verification step is outstanding is not implausible — it is Tuesday. The lure works by being indistinguishable from the ordinary texture of the job.
A cited notice reference and a stated response window, resolving to a replica of a federal or state sign-in page.
An "annual identity confirmation" flow that collects the EFIN, the PTIN and the account password in sequence.
A claimed transmission failure on one specific return, with a link to "review and resubmit" behind a login.
A deadline framed as a compliance obligation, pointing at a cloned society or education-provider portal.
An urgent update or forced re-authentication for the tax preparation or practice-management suite the firm runs.
The message cites a form the recipient handles constantly — a W-2 discrepancy, a 1099 mismatch, an amended 1040 — and pins it to a plausible notice identifier so it reads as a specific case rather than a broadcast. It sets a bounded deadline. Then it offers a link that carries the reader to something resembling e-Services, a state department of revenue portal, or an e-filing platform's sign-in. The page collects the identifiers listed above, sometimes in a sequence dressed up as multi-factor enrolment, and the harvesting is finished before the preparer has read to the end of the fake case summary.
Practices filing across multiple states interact with a dozen different revenue departments, each with its own portal design, its own domain conventions and its own notice formats. Nobody holds a mental catalogue of what all of them are supposed to look like, which means the visual-recognition defence that partly works for federal correspondence is simply unavailable. A hostname check does not care how unfamiliar the real portal is; it only cares whether this particular host has already been confirmed hostile.
Continuing-education deadlines, licence renewals, society membership notices and software security bulletins all carry a compliance flavour that produces prompt clicking, and they arrive from organisations whose real sending domains most staff could not name. The same screening applies without any change in configuration, which is the practical advantage of working at the hostname layer rather than trying to enumerate every sender a practice legitimately hears from.
Document exchange is where the modern practice lives, and it is structurally hostile territory. Clients send source documents through a portal, through whatever general-purpose file-sharing service they happen to use, through email attachments, and occasionally through whatever their bank or broker generates on their behalf. Every one of those routes produces a notification containing a link, and every one of them trains staff to click links in messages that were not expected, from senders who are not in the address book, at a time of year when the volume makes individual scrutiny arithmetically impossible.
A notification saying a client has uploaded documents, styled after a mainstream sharing service or after the firm's own portal, is one of the highest-yield lures aimed at accounting staff, because opening exactly those messages is the recipient's entire job that week. The credential harvested is often not the portal's — it is whatever single sign-on identity the portal federates to, which usually means the mailbox, which is the account that unlocks password resets for everything else.
Extract hostnames at the gateway or from the message store and check them before the message reaches a preparer.
Clients paste links into portal threads. Screen them on submission, server-side, before the thread renders.
PDFs and spreadsheets from clients carry embedded URLs. Pull them during intake and batch them, 100 per request.
Check the hostname in any signature-request notification before it is forwarded to a partner for approval.
Resource pages and client instruction templates accumulate outbound hostnames. Re-verify them on a schedule.
Engagement letters and fee arrangements are legitimate reasons to send a document for signature, so a forged engagement letter or a spoofed e-signature request is a natural fit. Wire instructions are worse: a practice that handles estimated payments, escrow, trust disbursements or client refund routing sends and receives banking detail as a matter of routine, and an amended-instructions message arriving mid-thread is the single most expensive email in the profession. Firms working through this alongside their own client-money controls will recognise the pattern from our banking and finance and legal services pages.
What makes it tractable is that it is machine-readable. Portal messages, notification emails and submitted documents all contain hostnames that can be extracted and checked without a human deciding anything. The check is server-side, it costs one credit per hostname, and it happens between receipt and display — which is the only window where prevention is still possible.
Almost no other industry has an exposure curve this predictable. Planning around it is the cheapest advantage available to a firm of any size.
The seasonality is not a curiosity for an awareness slide. It is an operational fact with direct consequences for how a practice buys and deploys. Credit consumption is not flat: a firm screening inbound hostnames burns a large share of its annual volume inside a fourteen-week block, which is precisely why credits that stay billed monthly from purchase suit this profession better than a monthly subscription charging the same in July as it does in March. Buy against the peak, spend the remainder through the quiet months on audit work, and let the arithmetic sit still.
Every deployment decision — where the check sits, what the block message says, who fields the resulting question — should be made and tested in the off-season, because the one thing a practice cannot absorb in March is a new tool behaving unexpectedly. The rollout further down this page is deliberately shaped to finish before intake begins, with the peak treated as the period when nothing changes rather than the period when something is finally installed.
Gateway filtering covers the firm's own email. It does not cover a link a client pasted into a portal thread, or one embedded in the PDF they uploaded at midnight.
Most firms that have thought about phishing at all have thought about it as an email problem and addressed it at the mail gateway. That is the right first move, and it leaves a specific gap. A tax practice does not receive its most sensitive traffic through email; it receives it through an intake channel it built or bought — a portal, an upload form, a document-request workflow — and content arriving that way typically bypasses every mail control the firm owns. A client who pastes a link into a portal message has delivered a clickable hostname straight to a preparer's screen with nothing in between.
A PDF from a client's brokerage, a spreadsheet exported from their bookkeeping system, an invoice forwarded from one of their vendors — these routinely carry embedded URLs, and the reason they matter is that the client's own environment may already be compromised. A business client whose bookkeeper was phished last month will forward documents in complete good faith containing links somebody else placed there. The firm is not defending against its clients; it is defending against whatever has already happened to them, which is a materially different and much more common situation.
During intake, pull hostnames from the message body and from the text layer of uploaded documents, deduplicate them, and submit them to the batch endpoint — up to a hundred domains in one request, one lookup each.
Attach the result to the document record rather than acting on it invisibly, so a preparer who opens the file a week later sees a flag rather than having to remember a warning from a different screen.
Where the verdict is positive, the useful default is to remove the link and surface a short note, not to quarantine the whole upload: a client whose submission silently disappears will telephone the firm during the worst possible week.
The API key is passed as a query parameter or in the POST body, and it must be used server-side only. Never put it in client-side JavaScript, never call the endpoint from a browser inside a portal page, and never expose it in anything a client could view the source of. Put a small endpoint of your own in front of it and let your server hold the key — a key embedded in portal page source is a key published to every client and to everyone they forward the page to.
Firms are sold overlapping products with overlapping promises. The honest version is that each of these catches a different failure and none of them catches all of it.
| Failure a practice actually experiences | Staff training | Mail gateway filtering | DNS-verified phishing lookup |
|---|---|---|---|
| Cloned e-Services page, domain already reported | Works while attention holds | Depends on sender reputation | Verified host, blocked outright |
| Domain registered this morning, first used this afternoon | Only if the copy is poor | Sometimes, on heuristics | Not yet observed |
| Malicious link inside a client-uploaded PDF | Nobody inspects PDF link targets | Never entered the mail path | Extract and batch at intake |
| Link pasted into a portal message by a client | Arrives inside a trusted surface | Outside the mail gateway | Screened server-side on submit |
| Amended wire instructions, no link at all | Callback procedure catches it | Nothing to inspect | No hostname to check |
| Partner impersonation asking for a client data export | Verification habit is the control | Only where the sender is spoofed | Out of scope |
| Stale link on the firm's own resource page | Nobody re-reads old pages | Not an email at all | Scheduled batch re-verification |
| Still works when the mail platform is bypassed | Human-dependent | No | Yes, at DNS or at intake |
The shape of the tool becomes clear. It is decisive precisely where the destination is a hostname that has already been caught, and it is silent everywhere else. Two rows carry a cross in that column for the same honest reason — there is no domain involved at all — and pretending otherwise would be the kind of overclaim that makes a partner distrust everything else on the page. Wire-instruction fraud is defeated by a callback to a number you already held, and no lookup service substitutes for that.
The argument for layering appears without anyone having to make it rhetorically. Every row training handles well is a row where automation has nothing to inspect, and every row where training fails is a row where a machine check does not depend on a person's attention at eight in the evening in the second week of April. The two controls are complements with almost no overlap, which is an unusually clean result and the reason this page does not suggest replacing anything you already run.
Six steps, all of them small, deliberately scheduled into the months when a practice has attention to spare.
List every route by which an external hostname reaches a preparer's screen: mail, the portal, the upload form, the signature service, the practice-management inbox. Most firms find two channels they had forgotten, and the list is what determines whether you need the API, the feed, or both.
Pull the suspicious messages staff have already reported this year, extract the hostnames, and run them through the check endpoint by hand. That produces a hit rate from your own mail rather than from a brochure, and it is the number that settles the internal conversation.
Start with intake, because that is the gap the mail gateway leaves. Log verdicts without blocking for two or three weeks, confirm nothing legitimate is being flagged, and only then let the result change what a preparer sees.
A generic denial creates a phone call. A line saying the address was verified as a fake sign-in page, that nothing the client sent was lost, and that a named person can help, turns an alarming moment into a short conversation — and it is the wording that keeps clients calm during the weeks you cannot afford noise.
Practices with an office resolver or firewall can load the daily feed as CSV and enforce for every device, including the machines nobody remembers are on the network. Matching then happens locally, so no per-lookup credit is consumed and nothing about staff browsing leaves the office.
One recurring job in the quiet months: re-verify outbound hostnames on your website and client instruction templates, sweep saved bookmarks on shared workstations, and confirm the feed file is no older than forty-eight hours. A silently stale list is the only realistic way this deployment fails.
The interface is small enough that most firms integrate it in an afternoon, and the sizing question answers itself once you count messages.
/api/v1/checkA GET carrying the hostname and your key. The response is a small JSON object with domain, is_phishing, category, dns_status, last_checked, confidence and database_size. Typical latency is under fifty milliseconds, which is what makes it usable inline rather than as a background job — the check finishes before a mail-flow rule or an intake handler would have moved on anyway.
/api/v1/batchFor anything batch-shaped, and intake screening is always batch-shaped, post a JSON body containing your key and an array of domains. The cap is a hundred domains per request and the cost is one credit per domain, so a nightly job sweeping the day's uploads is a handful of requests rather than thousands. The third option is the daily feed: the complete database delivered as CSV on a separate subscription, together with the added and removed changelog, which is what you want when the enforcement point is a DNS resolver, a firewall or an offline analysis pipeline rather than an application.
Sizing is a counting exercise, not a guess. Take the number of external messages and uploads your firm handles in a peak week, multiply by the average distinct hostnames each contains — one or two is typical after deduplication — and multiply by fourteen weeks.
# One hostname, server-side, one credit
curl "https://phishingdetectionapi.com/api/v1/check?domain=eservices-verify-irs.example&apikey=YOUR_KEY"
{
"domain": "eservices-verify-irs.example",
"is_phishing": true,
"category": "phishing",
"dns_status": "resolves",
"last_checked": "2026-07-27",
"confidence": 0.98,
"database_size": 390000
}
# Up to 100 hostnames pulled from today's client uploads, one lookup each
curl -X POST https://phishingdetectionapi.com/api/v1/batch \
-H "Content-Type: application/json" \
-d '{"apikey":"YOUR_KEY","domains":["client-portal-1040.example","secure-docs-cpa.example"]}'This is a floor, not a perimeter. A practice that understands the boundary deploys it well; a practice that overestimates it deploys it once and stops thinking.
The central limitation is definitional. This is a list of hostnames observed and verified as live phishing infrastructure. A domain registered this morning, resolved for the first time this afternoon, and used in a single campaign aimed at forty preparers before being abandoned will not appear until it has been seen. That gap is real, it is shared by every blocklist ever maintained, and the only honest position is to treat this as one layer among several rather than as a verdict on the trustworthiness of a link.
Inclusion requires the domain to be currently resolving in DNS; entries that go dark are dropped rather than retained, which is why the active count sits around 390,000 instead of ballooning into an archive of everything ever reported. That matters practically, not just aesthetically: a resolver parsing a file full of long-dead domains every morning is slower, noisier and no safer. The rebuild runs every twenty-four hours and the changelog records exactly what entered and what left, so a firm can watch the churn rather than take it on faith.
This page has already named the most expensive one. Amended wire instructions arriving in a live thread, a partner impersonation asking a junior to export a client list, a telephone call claiming to be the software vendor's support desk — none of these contain anything to look up. They are defeated by callback procedures against numbers held independently, by a rule that data exports always require a second approver, and by explicit cultural permission for a junior to make a partner wait. No API sold by anyone replaces those.
If a preparer's credentials have already been entered somewhere, the response is credential rotation, review of e-file activity for submissions the firm did not make, notification obligations under whichever rules apply to you, and the reporting steps your professional body and the relevant tax authority require. Practices building the response side should read the incident response and DNS filtering pages, and should write the procedure down before the season starts rather than during it.
These are the objections that come up in every conversation about this, and most of them deserve a straight answer rather than reassurance.
Mail filtering inspects mail. A tax practice receives a large share of its highest-risk content outside the mail path entirely, and none of it traverses your gateway:
A gateway makes a probabilistic judgement about a message. This makes a factual statement about a hostname: verified as currently resolving and confirmed as phishing infrastructure, or not on the list. Those are different kinds of answer and they compose well together.
Not directly, and it would be dishonest to imply otherwise. It reduces the likelihood of the credential theft that precedes that outcome, by removing the destinations where credentials get typed, but it has no visibility into e-file submissions themselves. Detecting misuse afterwards is a separate control:
Count rather than estimate. Distinct hostnames per external message after deduplication is usually one or two; multiply by your peak-week message and upload volume, then by fourteen weeks. Most solo and small practices land well inside 10,000 credits, which is the Growth package at $0.0040 per lookup.
A check request contains one hostname and your API key, and nothing else:
Use the daily feed instead. You download the full database as CSV and every comparison happens on your own equipment, so no per-lookup traffic leaves the office at all.
Plan the correction path and it stops being a crisis. Four things make the difference:
Yes, if you scope it to one channel. A single scripted check inside whatever automation your mail platform already offers, calling one endpoint with one parameter, is an afternoon of work and covers the largest share of the risk. You do not need the portal integration, the feed or a resolver to get value.
The practical route is asking whoever supports your practice-management software whether they can add the call, since it is a single HTTP request and the documentation is short.
It is a documented technical control with a log, which is useful evidence when describing the safeguards your practice operates. What it is not is a compliance product, and this site makes no certification claim of any kind — do not enter it on a form as though it were one.
Keep it factual: the firm screens inbound hostnames against a third-party database of verified live phishing domains, updated daily, with results logged. That sentence is true and defensible; anything stronger is not.
Train them — the comparison table above shows several rows where a trained person is the only control that works at all. But training asks for sustained attention, and the season is defined by the absence of it. A preparer on the fourteenth consecutive twelve-hour day is not a worse professional; they are a person operating at the edge of what attention can deliver.
Running the two together means human judgement is spent on the attacks that genuinely require it rather than on the ones a machine could have removed silently.
Start with one channel, measure the hit rate against hostnames your own staff have already reported, and decide from your own numbers. lookups reset each month, so the package that covers April also covers the October extension spike and the off-season link audit.
