A renewal notice, a claim update, a payment instruction, a broker bulletin. Every one of them is an email with a link in it, sent by a business the recipient trusts and rarely hears from. This page is a reference for where to screen those links against a DNS-verified list of live phishing domains — in outbound correspondence, at the claims intake, and across a broker channel nobody in the carrier administers.
Most policyholders hear from their carrier three or four times a year, which is precisely the frequency at which a convincing forgery is indistinguishable from the real thing.
The insurance relationship has an unusual rhythm. A policyholder buys once, hears almost nothing for a year, receives a renewal notice, and possibly makes a claim after an event that has already put them under stress. That is not enough contact to build a mental model of what genuine correspondence looks like. Compare it with a bank, where a customer sees the app several times a week and would notice a login page that had drifted; or a retailer, where the sender address is familiar from a dozen order confirmations. An insurer's customer has no baseline, no habit and no reason to be suspicious of a message that arrives at exactly the moment they were half-expecting one.
Renewal season produces a wave of look-alike notices timed to the month the policy actually lapses. A named storm produces claim-related lures within days, aimed at people whose roof has just come off and whose tolerance for administrative friction is nil. A recall, a large industry event or a well-publicised catastrophe produces the same effect at a smaller scale. In each case the lure works because the recipient was genuinely expecting an insurer to contact them, and the fraudulent message arrived first.
Premiums flow inbound, claim settlements flow outbound, commissions flow to intermediaries, and every one of those flows is initiated by a document containing bank details. That is why insurance-themed phishing so often resolves into a payment diversion rather than a data theft. The credential harvest is the first act; the second act is a payment instruction sent from a mailbox the recipient has legitimately corresponded with before, which is exactly the message no filtering rule based on sender reputation will flag.
A cloned policyholder portal harvests credentials from customers on their own devices, on their own networks, using a link the carrier never sent, and no control the carrier owns sits in that path. That does not make it somebody else's problem — the complaint, the reputational damage and frequently the goodwill payment all land on the carrier — but it does mean the realistic interventions are narrower than a security team would like, and worth being precise about rather than optimistic about.
The contribution is deliberately modest and mechanically clear: it answers whether a specific hostname is currently a confirmed, resolving phishing host. That answer is useful in three concrete places on the insurance value chain — in front of the mailboxes that receive claims and broker correspondence, inside the systems that publish links outbound to policyholders, and as a self-service check the carrier can offer a customer who is holding a message and does not know what to do with it. Everything below is about those three placements, what they catch, and what they do not.
A database of hostnames that have been observed serving phishing content and confirmed to be currently resolving in DNS. Domains that stop resolving are removed rather than retained, which is why the active count sits around 390,000 rather than growing indefinitely, and why a match tells you the infrastructure is live now rather than at some point in the past.
A match is a statement of fact about a hostname. It is not a judgement about a message, a sender, an attachment or an intent. A message can be entirely fraudulent and contain no matching hostname — which is why this belongs alongside your mail gateway and your payment controls rather than in place of either.
This page covers general and property-and-casualty lines. Health and medical benefit carriers have a materially different threat surface and regulatory posture, covered on the health insurance page, and the sector-wide view sits under industries.
The two columns below have matching rows on purpose. Read across, and the boundary of what this control covers becomes obvious.
The last two rows are the ones worth dwelling on, because they define the shape of the control rather than its strengths. A hostname check screens hostnames. When the fraud is carried entirely inside a PDF, an attached invoice, or a plain-text request to change remittance details, there is no hostname to check and no verdict to return. Anyone presenting domain screening as an answer to remittance fraud is over-selling it, and a carrier that treats it that way will have quietly weakened the control that actually works there, which is out-of-band callback verification to a number held on file rather than one supplied in the message.
It earns it in volume. The renewal-clone, portal-clone and payment-capture patterns in the first four rows are reused across carriers, because the kit that produces a cloned login page does not care whose logo it wears. That means the host attacking your policyholders this week has frequently already been observed attacking somebody else's, which is exactly the circumstance in which a shared, DNS-verified list is worth more than any individual carrier's private intelligence. The verification standard matters here too: because inclusion requires a live A record, you are matching against infrastructure that is still up rather than a historical archive of everything ever reported.
The practical consequence for an insurer is that domain screening should be described as a high-volume, low-drama filter rather than as a fraud control. It removes a category of known-hostile links from your inbound mail and from the content you publish, cheaply and without judgement calls. The genuinely expensive fraud — the settlement redirection, the changed bank details, the adjuster impersonation conducted by phone — is defended by process, and no amount of link screening substitutes for it.
Appointed brokers, managing general agents and independent agencies hold your policyholder data on infrastructure your security team has never seen.
This is the feature of insurance distribution that makes it different from almost any other financial sector. A carrier of any size distributes through independent intermediaries: appointed brokers, agencies with binding authority, managing general agents writing on the carrier's paper, and wholesale brokers placing specialty risk. Each of them holds a working copy of policyholder information, each of them has credentials to a carrier portal, and each of them runs its own mail, its own endpoints and its own security programme — which in a four-person agency frequently means a mail platform's default settings and nothing else.
They understand this distribution model perfectly well. A phishing message impersonating carrier operations — a portal migration, a commission statement, a mandatory compliance module, an appointment renewal — is far more likely to succeed against a small agency than against the carrier itself, and the credential it yields opens a carrier system. From the carrier's logs the resulting session looks like an ordinary broker login from an ordinary broker, because it is: the same account, frequently the same address range, doing things brokers legitimately do. Quote and bind, endorsement, beneficiary and payee changes, bulk policyholder lookups. The compromise is invisible at the point where the carrier has visibility.
That is the uncomfortable part: the carrier carries the outcome without holding the levers. A breach at an agency becomes a notification obligation involving the carrier's policyholders, a conversation with a regulator about the carrier's oversight of its distribution chain, and a reputational event attached to the carrier's brand. Yet the carrier cannot mandate an endpoint agent on an independent agency's laptops, cannot audit their mail configuration in any meaningful way, and in practice cannot even reliably enumerate every address that corresponds with it on behalf of a placed risk.
Both are about the carrier's own mail rather than anybody else's. The first is to screen the links in the messages the carrier itself sends to its broker channel, and to publish the fact loudly: every URL in a carrier bulletin is drawn from a fixed set of carrier-owned hostnames, screened before dispatch, and the carrier will never send a broker a login link from anywhere else. That converts an unverifiable judgement — does this bulletin look right — into a rule a four-person agency can actually follow. The second is to screen inbound: broker correspondence arrives at carrier mailboxes constantly, and a compromised agency mailbox will forward the campaign into the carrier before anybody knows it has been compromised.
It is still worth stating: give the channel somewhere to report. A short, well-publicised route for an agency to say "this arrived and I do not think it is you" turns a distributed liability into a distributed sensor, and a single reported hostname checked against the live-domain list gives the carrier an answer within seconds that it can broadcast to every other appointed agency the same morning. That is the whole loop, and it is achievable without any authority over anybody else's infrastructure.
Publish a fixed, short list of carrier-owned hostnames that appear in genuine carrier correspondence, screen every outbound link against them before dispatch, and tell the channel plainly that a login link from any other host is fraudulent by definition. A rule that can be applied without judgement survives contact with an agency that has no security team, which is most of them.
Two integration patterns cover essentially every insurance deployment: per-message lookups from a mail or intake pipeline, and a whole-database pull for network enforcement.
# Every distinct host extracted from the message body and headers,
# submitted in one request. Max 100 per call, 1 credit per domain.
curl -s -X POST https://phishingdetectionapi.com/api/v1/batch \
-H "Content-Type: application/json" \
-d '{
"apikey": "YOUR_KEY",
"domains": [
"claims-portal-update.example",
"repair-network-estimates.example",
"cdn.carrier-owned.example"
]
}'
# Each result carries the same shape as a single check:
# {"domain":"claims-portal-update.example","is_phishing":true,
# "category":"phishing","dns_status":"resolves",
# "last_checked":"2026-07-27","confidence":0.98,"database_size":390000}The key belongs on a server. It is passed as a query parameter on the check endpoint or inside the POST body on the batch endpoint, which means the call must originate from your mail pipeline, your claims platform or a small internal service — never from a page running in a policyholder's or a broker's browser. Where a carrier offers a customer-facing link checker, the browser calls a carrier endpoint and the carrier endpoint holds the key.
Credits are the whole commercial model: one credit is one lookup, credits are bought outright by PayPal rather than by subscription, and they stay billed monthly. That suits insurance volumes, which are seasonal — renewal cycles and catastrophe response produce spikes that a monthly seat licence would price badly and a credit balance absorbs without any renegotiation.
The claims mailbox is the one address at a carrier that is published, monitored, and obliged to open whatever it receives.
Every other function in a carrier can be told to be careful about unsolicited attachments. Claims cannot. First notification of loss arrives from strangers by definition, frequently in distress, frequently with links to photographs, repair estimates, medical documentation, police report portals, hire-vehicle confirmations and cloud folders full of evidence. The department's entire purpose is to receive unverified material from people it has no relationship with and act on it quickly, and the service metric it is measured against rewards speed. It is a phishing target constructed to specification.
The first is straightforward credential phishing aimed at adjusters: a message dressed as supporting documentation, a link to something that looks like a document-sharing prompt, a login page, and a session in the claims system afterwards. The second is more specific to the sector — an attacker who has already harvested a policyholder's identity uses the claims channel to submit a fraudulent claim in their name, and the link in that submission serves to establish the fiction rather than to steal anything. A carrier looking only for credential theft will miss the second entirely, because nothing in it is technically hostile.
Extract every distinct host from the message body, the headers and any rewritten gateway links, normalise them, and submit them in a single batch call at one lookup each. Screening at this point helps with credential phishing and contributes to the fraudulent-claim case.
A match tells them, before they open anything, that a link in this submission points at confirmed live phishing infrastructure — which is a strong signal about the submission as a whole and not merely about the link that carried it.
For a claim submitted after an identity harvest, that same signal is a useful early indicator to route the file to special investigations rather than to standard handling, even when the fraud itself carries no malicious payload.
Claim status pages, document uploads, repair-network directories, hire-car partners, subrogation notices and renewal offers all leave the carrier as links, and the same screening belongs on that path too.
Callback verification to a number held on file, and segregation between the person who approves a claim and the person who changes a payee. Nothing here is a link problem, and nothing here is improved by screening one.
A quarterly job that pulls every outbound hostname from the correspondence templates, the CMS and the partner directory and runs it through the batch endpoint costs a trivial number of credits, and it occasionally catches the thing everybody dreads — a partner domain that lapsed and was re-registered by somebody else, now sitting inside a letter with the carrier's logo on it. This is the same hygiene pattern described on the email security page, applied to what you publish rather than to what you receive.
Nor should it be allowed to. Settlement redirection, adjuster impersonation and repair-network invoice fraud are defended by callback verification, by segregation of duties, and by a standing rule that a bank-detail change is never actioned from an inbound message regardless of how convincing it is. Link screening reduces the volume of hostile traffic reaching the people who operate those controls. It does not replace one of them.
Most carriers should do two of these and consider a third. Doing all four is possible and rarely necessary.
| Placement | What it protects | Cost shape | Effort | Blind spot |
|---|---|---|---|---|
| Inbound mail pipeline Claims, broker and finance mailboxes |
Adjusters, underwriters and finance staff opening unsolicited material all day | One credit per distinct host; batch de-duplication keeps volume low | Moderate — a hook in the gateway or post-delivery pipeline | Fraud carried entirely inside an attachment or in plain text |
| Outbound content audit Templates, CMS, partner directory |
The carrier's own brand, and policyholders following a link the carrier published | A few hundred credits per quarterly sweep | Low — a scheduled job over an exported hostname list | Nothing about the messages attackers send in the carrier's name |
| Policyholder self-check In the portal or the mobile app |
Customers who are suspicious enough to check, which is a minority | One credit per submitted host, driven by customer behaviour | Moderate — a server-side endpoint plus support wording | The customers most at risk are the least likely to use it |
| Network resolver enforcement Carrier and MGA corporate networks |
Every device and protocol on the network, not just browsers and mail | Daily feed subscription; no per-lookup billing | Higher — resolver integration and a daily reload job | Nothing outside the network: home working, broker sites, customer devices |
The claims and broker mailboxes take the most hostile inbound volume and have the least discretion about opening it. Credit consumption is predictable because de-duplicating hosts across a day's mail collapses the count dramatically, and the integration point is somewhere your mail team already operates.
If you want the block to cover every device and protocol rather than only mail, take the daily CSV feed and load it into your resolvers. It is a separate subscription with no per-lookup cost, which makes it the right shape once volume is continuous rather than event-driven. Details on the daily feed page.
Four gaps, each of which has a different owner inside the carrier. None of them is closed by a domain list.
A hostname registered this morning and used against your policyholders this afternoon will not be in any known-bad list, because nothing has observed it yet. The database is rebuilt every 24 hours and every entry is verified as resolving, which keeps it current rather than making it prescient. For a campaign timed to a renewal cycle or launched in the days after a catastrophe, some proportion of the infrastructure will be too new to have been seen.
Settlement redirection, remittance-change requests, adjuster impersonation by telephone, and the whole family of instruction fraud carry no link to check. These are process problems with process answers: callback verification on a number held on file rather than one in the message, segregation of duties between claim approval and payee amendment, and a standing rule that bank details are never changed on the strength of inbound correspondence.
When a phishing page is planted on a subdirectory of a genuine site — a small business, a community organisation, a neglected content system — the hostname is not hostile and will not appear in a list of hostile hostnames. This is a real and common pattern, and it is the reason a hostname check is a floor rather than a complete defence.
A cloned policyholder portal, a fake claim-status page circulated on social media, an advert placed against your brand name in a search result — the customer meets the fraud on their own device, on their own connection, and no control the carrier owns is in that path. The carrier can monitor for such hostnames, check reported ones quickly and support takedown; it cannot block a link it never sees.
Stated together, these four gaps describe a control that is genuinely useful and definitely partial. That is the correct way to present it to a risk committee, to an internal auditor, and to a cyber underwriter assessing the carrier's own exposure — as one measurable, cheap, daily-refreshed layer with a documented scope, sitting alongside payment verification, staff training and the mail platform. Carriers doing exactly this reasoning about their commercial customers will find the same framing useful on the banking and finance and insurance industry pages.
"Not in the list" means only that this hostname is not in this database. Build your pipelines so that a match escalates and a non-match leaves the message exactly where it was, in the queue, awaiting the same handling it would have received without any enrichment at all.
Mostly about scope, evidence, cost shape and how this reads to an underwriter or an auditor.
Nobody can promise that, and any vendor who does is guessing about somebody else's underwriting. What is true is that cyber proposal forms and underwriting calls increasingly ask specific, answerable questions about email controls, about how inbound links are handled, and about oversight of a distribution chain. Having a documented, dated answer to those questions is materially better than having a general assurance.
Count distinct hostnames, not messages. A claims mailbox receiving several thousand messages a day contains far fewer distinct hosts than that, because most links point at the same handful of document platforms, repair networks and mail-tracking services. De-duplicate across a day and cache verdicts for a short period and the daily count typically falls by an order of magnitude.
Yes, and it is a reasonable thing for a carrier to offer inside an authenticated portal or app. The customer pastes a hostname, your server calls the check endpoint with your key, and your server returns a plain-language answer. It costs one credit per submission and it gives your support function something concrete to point a worried customer at.
Partially, and mostly as an early routing signal rather than as a detection. A fraudulent claim submitted in a real policyholder's name after their identity was harvested elsewhere is not technically hostile at the point of submission — there may be no malicious link at all, in which case a hostname check contributes nothing.
Very little in terms of technology, and quite a lot in terms of rules. You cannot audit an independent agency's mail configuration or push an agent onto their laptops. You can publish a short, fixed list of carrier-owned hostnames that appear in genuine correspondence, state that a login link from any other host is fraudulent, and hold to that rule without exception in your own outbound communications.
Each lookup returns a structured response containing the domain, whether it matched, the category, the DNS status, the date it was last checked, the confidence value and the database size at that moment. Logged alongside your own timestamp and the message or case reference, that is a dated, reproducible record of what was known when a decision was taken.
Different data, different question. A mail gateway makes a composite judgement about a message using sender reputation, authentication results, content heuristics and its own intelligence, and it returns a probability dressed as a decision. This returns a factual answer about one hostname: present in a DNS-verified list of live phishing hosts, or not.
The database is rebuilt every 24 hours, and inclusion requires the hostname to be confirmed as currently resolving in DNS. Entries that go dark are removed rather than retained, which is why the active figure sits around 390,000 rather than accumulating without limit, and why a match is a statement about live infrastructure rather than about history.
Put a hostname check in front of the claims intake, across the broker channel's inbound mail, and over the templates and partner directories you publish. one lookup per API call, a hundred domains per batch request, and a twelve-month credit life that absorbs the seasonality of renewal and catastrophe periods.
