Health plans are phished through the one channel members have been trained to trust: routine benefit correspondence. This is a working reference on the lures that target member and provider portals, why the enrolment calendar makes the timing predictable, and how a lookup against 390,000+ DNS-verified live phishing domains fits into the communications a payer already sends.
Understanding why payers are targeted so persistently starts with being precise about what sits behind a member account.
A retailer that loses a customer account has lost an email address, a shipping address and possibly a payment token that the issuer can rotate by Friday. A health plan that loses a member account has lost something structurally different. Behind that login sits:
It is not a credential. It is a dossier, and every field in it is permanent in a way a card number never is.
Stolen card data has a short useful life because the fraud detection and reissue machinery around it is fast and well practised. A stolen benefits identity has no equivalent machinery. Nobody reissues a date of birth. Nobody rotates a diagnosis history. The data stays usable for years, and the harm it enables — care obtained under someone else's coverage, claims filed against a policy the real member never used, a benefit maximum quietly consumed — surfaces late, often only when a legitimate claim is denied for a reason the member cannot explain.
You cannot mandate multi-factor authentication for all of them without excluding the segment least able to comply, you cannot run mandatory training, and you cannot control the device, the mail client or the network they use. What you can control is what leaves your systems, what your systems accept, and what your service representatives are equipped to answer when a member phones to ask whether a message is real. Those three levers are where a domain screening control actually earns its place.
A payer sends an enormous quantity of legitimate correspondence: enrolment confirmations, identification card notices, claim status updates, benefit statements, formulary changes, prior authorisation decisions, wellness programme prompts, premium billing. Members are conditioned to receive unsolicited messages from their plan and to act on them. An attacker imitating that traffic is not fighting the member's expectations; they are riding them.
The use of another person's benefit identity — subscriber ID, group number and demographics — to obtain care, prescriptions or equipment, or to submit claims against their coverage. It differs from ordinary financial identity theft in three ways that matter operationally: it corrupts a clinical record as well as a financial one, the victim usually discovers it through a denial or a bill rather than a statement, and the remediation involves the plan, the provider and sometimes a regulator rather than a single issuer.
The specific field set a portal clone is built to harvest: member or subscriber ID, group number, date of birth, last name, ZIP code and, on enrolment-themed pages, a Social Security number and household income. That combination is chosen deliberately. It is enough to pass identity verification at a second organisation — a pharmacy benefit manager, a provider's registration desk, a marketplace application — which is what converts a stolen login into a usable identity.
Every one of these works by borrowing the credibility of a routine plan communication rather than inventing a new reason to click.
The base case and the most common. A registered lookalike hostname — a hyphenated variant of the plan name, the plan name with -member, -login or -secure appended, a character substitution, or the same string under a different top-level domain — serves a pixel-accurate copy of the real login page. Some clones proxy the genuine portal in real time, so the member sees their actual account after authenticating and never suspects anything, while the operator harvests the session. The lure that delivers it is usually a security alert about unusual activity, which is the one message class members have been taught to treat as urgent.
An EOB notification is ideal for an attacker because it is common, it is boring, and it carries just enough anxiety to guarantee a click. The claim-denial variant is stronger still: a member told a claim has been rejected wants to know why immediately, and the message that tells them so can direct them anywhere. These campaigns rarely need to be convincing in their detail, because the emotional response arrives before the scrutiny does.
A category rather than a single lure. These are standalone sites presenting themselves as neutral comparison tools or as an official exchange, collecting a full enrolment application — household size, income, Social Security numbers for every member of the household — and either selling the lead, applying for coverage fraudulently, or simply keeping the identity bundle. They are frequently advertised rather than emailed, which puts them entirely outside your mail infrastructure and makes them the hardest of the six for a payer to observe.
Aimed at practice staff rather than members. A message purporting to come from the plan asks a billing coordinator to re-verify credentials, review a reimbursement policy change or update remittance details. A compromised provider account is worth more per unit of effort than a member account: it can submit claims, it can see many patients' data at once, and it sits inside a trust relationship your systems are built to honour.
Prior authorisation is slow, opaque and consequential, which makes it excellent bait for members and prescriber offices alike. A message announcing that an authorisation has been approved, denied or requires additional documentation reliably produces action. The pharmacy benefit variant works on formulary changes and copay assistance, where the member is already anxious about cost and already expects to be asked for identifiers.
Brokers occupy a trusted position on both sides and are administered by neither. An attacker impersonating a broker to a member can request policy changes or redirect premium payments; impersonating a plan to a broker can harvest the book of business. The channel's defining characteristic — that legitimate communication routinely arrives from domains you do not own — removes the member's best available heuristic entirely.
Most organisations cannot predict when they will be targeted. A health plan can put it in a project plan a year ahead.
The dates are published. Annual enrolment for a given market opens on a known day and closes on a known day; employer group renewals cluster at the turn of the year; special enrolment periods follow qualifying events on defined timelines. Every one of those dates is public, and each one produces the same predictable conditions:
An attacker does not need to invent any of that. They need to arrive during it.
Enrolment season is not the time to introduce a new control — it is the time to have one already running and already tuned. Establish what your normal outbound and inbound link profile looks like, because a spike in hostnames resembling your brand is only visible as a spike if somebody recorded the flat period before it.
Every hostname that will appear in an enrolment communication should be enumerated, checked and approved in advance, so that anything else appearing in your own mail stream is an anomaly by definition rather than a judgement call somebody has to make under load.
Not a warning. Give representatives a screening tool they can paste a member's reported URL into and get an answer in under a second, instead of a script that tells them to advise caution and leaves the member exactly where they started.
Run the permutation sweep across your own plan and portal names on a daily schedule for the duration, so a clone of your enrolment portal is discovered by your tooling rather than by a member who has already filled it in.
Deductibles start over and members log in to check what changed. Lower intensity than enrolment, and the same underlying condition: an unexpected message about coverage arrives at a moment when the member has a reason to believe it.
The spring wave of claim disputes when the first post-reset explanations of benefits arrive, and the autumn formulary update cycle. Neither produces enrolment-scale exposure, but each is a period when a member receiving an unexpected message about their coverage has an entirely plausible reason to believe it.
A domain lookup is one row in this table, not the table. Reading it honestly is the fastest way to see where the gaps sit.
| Scenario | Mail authentication (SPF / DKIM / DMARC) | DNS-verified known-bad domain lookup | Member-side MFA |
|---|---|---|---|
| Spoofed sender using your exact domain | Rejected at the receiving side | Not what it inspects | Never reached |
| Lookalike hostname already catalogued as live phishing | Passes — the attacker owns that domain | Verdict before the link is followed | Helps only if the member completes it |
| Lookalike registered this morning, not yet observed | Passes | Unknown until it enters the pipeline | The control that still applies |
| Real-time proxy clone forwarding to your portal | Passes | Blocked at the hostname if catalogued | Session is relayed through |
| Compromised legitimate site hosting the fake form | Passes | Hostname is genuine and clean | Depends on the factor type |
| Advertised fake marketplace, never emailed | Out of scope | Only via proactive brand sweeps | No account involved |
| Plain-text instruction to redirect a premium payment | Depends on the sending domain | No link to evaluate | No login involved |
Half-filled markers mean partial coverage under stated conditions, not a qualified yes. The rows where every column is weak are the ones that belong in your process controls rather than your technical ones.
Two conclusions follow from reading down the columns, and both of them change what you buy next.
What is actually in the database, how it is maintained, and why that maintenance is the part that matters in production.
Every entry is confirmed to be currently resolving at build time. Domains that go dark are dropped from the next build rather than kept, so the file describes live infrastructure instead of accumulated history.
A complete daily rebuild, accompanied by a changelog of domains added and removed. That changelog is what makes an update a reconcilable diff rather than an opaque replacement.
Query it live for per-message decisions, or take the whole database as a CSV subscription and match locally in a resolver, gateway or claims platform. The second shape costs no credits per lookup.
The distinction between a verified list and an accumulated one is not academic once the data is inside something that has to make a decision on every message. An accumulated list grows without bound, because removing entries requires verification work that most publishers are not funded to do, and after a couple of years the majority of such a file is dead: parked domains, lapsed registrations, hosts taken down long ago.
The response body is deliberately small and stable, so it can be consumed by a gateway rule and by an analyst reading the same event three weeks later: domain, is_phishing, category, dns_status, last_checked, confidence and database_size. The last_checked field is the one to persist alongside your own event record — it is what lets you state, later and precisely, when a hostname was known hostile, which is the question that governs a notification timeline far more often than anyone expects going in.
The highest-value insertion point for a payer is not inbound mail. It is the outbound stream your own members already trust.
The part you fully control and the part with the worst failure mode. A payer's outbound mail is assembled from templates, campaign tools, vendor-supplied footers, click-tracking wrappers and content that marketing, benefits and clinical teams all contribute to, so hostnames enter that pipeline from more directions than anyone maintains a list of. Screening every distinct host in a template before release costs a handful of credits and removes the scenario in which your own trusted channel carries a member to a hostile destination.
When a member phones to ask whether a message is genuine, the representative currently has no way to answer and is trained to be non-committal, which helps nobody. A single field that takes a pasted URL, extracts the host and returns a verdict in well under a second converts that call from a deflection into a resolution — and produces an accumulating record of what members are actually being sent, which is the earliest signal most payers can realistically get that a campaign against their brand has started.
Inbound mail to staff and to the claims and appeals intake queues, where the exposure is not credential theft in the abstract but a payment or an authorisation decision at the end of it. This is the insertion point whose failures show up in a finance reconciliation rather than in a security console.
Generate the plausible permutations of your plan names and portal hostnames, push them through the batch endpoint on a schedule, and act on hits with your registrar and your communications team. It is the only insertion point that can see infrastructure which never passes through any system you operate.
If you operate recursive DNS, load the daily feed so that corporate devices cannot reach catalogued phishing hosts regardless of how the link arrived — email, text message, chat, or a QR code on a printed benefits flyer. This one costs no credits per lookup, because the matching happens on your equipment.
The integration is a single HTTP call in each case. The key is passed as a query parameter or in the POST body and must remain server-side; it must never be embedded in a member-facing web application, a mobile bundle or anything a vendor can read out of a repository. Detail on gateway-side handling is on the email security page.
# One hostname — screening a URL a member reported to the contact centre
curl -s "https://phishingdetectionapi.com/api/v1/check?domain=myplan-member-login.example&apikey=$PDA_KEY"
# Batch — pre-flight every distinct host in an enrolment template
curl -s -X POST "https://phishingdetectionapi.com/api/v1/batch" \
-H "Content-Type: application/json" \
-d '{
"apikey": "YOUR_SERVER_SIDE_KEY",
"domains": [
"enrollment.yourplan.example",
"click.yourmailvendor.example",
"yourplan-openenrollment.example"
]
}'
# Returned per domain:
# domain · is_phishing · category · dns_status
# last_checked · confidence · database_sizeUp to 100 hostnames per batch request, one credit per hostname. Endpoint reference on the API documentation page.
A contracted practice is an organisation you depend on, cannot patch, and cannot compel — which makes it the most awkward surface a payer owns.
The provider network is where a payer's security model runs out of authority. A contracted practice may be a hospital system with a security operations centre, or it may be three clinicians and an office manager sharing one workstation and a mailbox that handles referrals, remittance advice and appointment requests in the same inbox. Both are in the same network, both submit claims through the same portal, and both hold protected health information belonging to your members. You set contractual expectations, but you do not run their mail, choose their browser or see their alerts.
What an attacker gets from a compromised provider account is qualitatively different from a member account, which is why the effort spent is higher. A provider login can typically look up eligibility for many members, view claim history, submit new claims and change remittance destinations. One credential yields a query interface over a slice of your book rather than a single dossier, and the activity it generates looks like ordinary business because it is arriving through the channel that business is supposed to arrive through.
The remittance redirect deserves particular attention because it is the variant that moves money and the variant that most often succeeds. An attacker with provider portal access, or simply with a plausible impersonation of the practice, submits a change of banking detail for electronic funds transfer. The claim is legitimate, the adjudication is correct, the payment is correct, and it arrives in the wrong account. No security control detects it, because nothing anomalous happened at a technical level. That is a process problem, and it needs a process answer: out-of-band verification against contact details you already held, a mandatory hold period on remittance changes, and a second approver. A hostname check contributes to it — the link in the request message can be screened, and the requesting domain can be checked — but treating a clean verdict as authorisation to change a payment destination is exactly the misuse to guard against.
The realistic extensions to the network are modest and worth doing anyway. Screen the links in every communication you send to providers with the same discipline you apply to member mail. Give the provider relations team the same URL-checking tool the member contact centre has, since practice staff phone to ask the same question. Batch-check the domains of contracted practices you already hold in your credentialing records, on a schedule, so a compromised or impersonated practice domain surfaces before it is used against you. And where a practice is small enough to accept the advice, point them at the delivery-side view of the same problem on the healthcare page. Pharmacy benefit and specialty distribution channels carry a related exposure, covered on the pharmaceutical page.
Both halves are load-bearing. A control described accurately survives an audit; a control described generously creates one.
Payers operate inside a dense regulatory frame, and it is worth being precise about how a domain screening control relates to it rather than gesturing at acronyms. The HIPAA Security Rule requires administrative, physical and technical safeguards for electronic protected health information, and requires a risk analysis that identifies threats to that information — social engineering plainly among them. Screening the hostnames in inbound and outbound communications is a technical safeguard that contributes to preventing unauthorised access; it is not, on its own, an access control, an audit control or an integrity control, and describing it as satisfying those requirements would be wrong. State insurance data security regimes based on the NAIC model law require a documented information security programme with safeguards proportionate to identified risk; a screening control with a query log is a documented, evidenced component of such a programme. That is the accurate claim, and it is a useful one.
The evidence artefact is genuinely valuable and frequently overlooked. Every lookup produces a timestamped record of a hostname and a verdict. Over a policy year that becomes a clean, machine-generated demonstration that a stated control was operating continuously — what was checked, when, what the answer was, and what the system did in response. Assessors are rarely interested in how clever a control is; they want to know whether it ran on a given date and whether anyone can show it. The same logs shorten an incident timeline, because last_checked gives you a defensible answer to when a hostname was first known hostile.
Now the limits. This is a known-bad lookup, and the honest description of it is narrow. It answers whether a hostname has already been observed and DNS-verified as a live phishing site. It does not evaluate hostnames it has never seen, so a domain registered during your enrolment window and used the same afternoon is invisible to it until it enters the pipeline. It does not inspect page content, so a compromised legitimate site — a small practice's own website serving a fake portal form — returns clean, because the hostname genuinely is that practice's. It does not read messages, so a plain-text premium redirection or a fraudulent remittance change with no link at all sits entirely outside its scope.
It is also silent on the channels that never touch a URL: telephone pretexting against your contact centre, a fraudulent claim submitted with a correctly stolen identity, an insider, or an attacker already holding valid credentials. And it will occasionally be wrong in the other direction. Shared hosting infrastructure that has carried phishing content can be flagged in a way that inconveniences a legitimate site on the same platform, which is why any enforcement path needs a documented exception route a provider or a member can actually reach, staffed by a person with the authority to act on it.
Set against that, the case for deploying it is straightforward and does not require overstatement. The great majority of what reaches your members and your provider network is catalogued infrastructure reused across campaigns, and removing it costs fractions of a cent per decision. Treated as a floor beneath multi-factor authentication, mail authentication, out-of-band payment verification and a contact centre equipped to give members a real answer, it does substantial work. Presented to a board or a regulator as comprehensive protection against phishing, it will not survive the first incident it did not prevent — and that outcome is avoidable by describing it correctly now. Carriers outside the health line will find the corresponding treatment on the insurance industry page.
Seven questions that come up in almost every evaluation, answered without hedging.
A lookup transmits one hostname and your API key. It carries no member identifier, no claim data, no message body and no protected health information — unless your own integration adds something, which is the only way it could happen and is straightforward to avoid.
If your privacy assessment prefers that no query leave your environment at all, take the daily feed instead. You download the complete database once a day and every comparison runs inside your own infrastructure.
Yes, and it should not be done per message in any case. Campaign mail is assembled from a small number of templates containing a small number of distinct hostnames, so the correct point of screening is template release, not send time.
That turns a campaign to two million members into a handful of lookups. For genuinely per-recipient dynamic links, batch the distinct hosts at build time and cache the verdicts for the life of the campaign.
Count three streams separately: distinct hostnames in inbound mail after deduplication, contact centre URL checks, and the daily brand permutation sweep. The first dominates; the other two are usually a few thousand a month combined.
lookups reset monthly and one credit is one lookup, so a package bought before the window covers the peak and the quiet months after it. The bands are set out on the pricing page.
A confirmed hit is definitive and actionable: the hostname is verified live phishing infrastructure, the member should not enter anything, and if they already did, you have an immediate account containment task rather than a maybe.
A clean result is weaker and should be scripted as such. It means the hostname is not currently catalogued, not that the message is genuine. The representative should still verify through the plan's own channels rather than treating the check as clearance.
Only if the site has been observed and catalogued, and only if you go looking. Nothing about an advertised site passes through your infrastructure, so there is no inbound event for a check to attach to.
The workable approach is the proactive sweep: batch-check permutations of your plan and product names on a schedule, and pair it with the brand monitoring described on the brand protection page. Treat that as partial coverage, not a solved problem.
Build the exception path before you enforce anything. Keep a local allow list applied after the feed, give provider relations a documented route into it, and record who approved each entry and why.
It is worth re-checking exceptions periodically. Because the database drops domains that stop resolving and publishes daily additions and removals, an entry that was flagged during a hosting compromise will often have left the build on its own.
Yes. The interface is the same call regardless of which system makes it, so most payers wrap it once as an internal service and let the member portal, provider portal, contact centre console and mail gateway all consume that wrapper.
That also centralises the query log, which is what you want for evidence, and lets you apply one allow list and one caching policy rather than maintaining several that drift apart over a year.
Screen the links you send, equip the contact centre to give members a real answer, and sweep your own brand permutations on a schedule — against a database rebuilt every twenty-four hours.
