An insurer is impersonated at three points at once: to the policyholder who is waiting on a claim, to the broker who sells the policy, and to the claims handler who is about to release a settlement payment. All three attacks start with a domain that resolves.
The Phishing Detection API answers one question with a hard fact: does this hostname appear in a continuously rebuilt database of DNS-verified, actively resolving phishing domains? A single lookup returns in under 50 milliseconds, so the check can sit inline in a claims mailbox pipeline, a broker portal link rewriter, or a policy administration system's outbound link validator.
# domain lifted from an FNOL acknowledgement reply { "domain": "claims-status-review.example.net", "is_phishing": true, "category": "phishing/malware", "dns_status": "resolves", "last_checked": "2026-07-27T04:30:00Z", "confidence": 0.98, "database_size": 212370 }
Most sectors defend one perimeter. An insurer defends a customer base, a distribution channel it does not administer, and a back office that moves money on the strength of documents from strangers.
Insurance carries an unusual risk profile for social engineering, and it is worth being precise about why. A retailer's customer interacts with it weekly and knows what its email looks like. An insurer's customer may go two or three years without a single meaningful contact, then suddenly needs the company urgently, at the worst moment of their year, with a damaged car or a hospital admission or a flooded ground floor. That combination of long dormancy and sudden urgency is exactly the condition attackers exploit. A policyholder who has not seen a genuine message from their insurer since the last renewal has no baseline to compare against, and a person waiting on a claim decision will click almost anything that promises movement.
The first direction of attack is aimed at the policyholder. Cloned claim-status pages, premium-refund lures promising an overpayment return, renewal-payment pages that harvest card details, and open-enrolment pages built to look like a health plan's member portal are the standard inventory. In general insurance the seasonal peaks are predictable: motor renewals, storm-season property claims, and travel policy sales before holiday periods. In life and health the lures are quieter but more damaging, because a health member portal holds claims history and clinical codes, and a life policy portal holds beneficiary details and bank instructions that an attacker can rewrite once inside.
The second direction is the distribution channel, and it is the one most carriers underestimate because they do not administer it. Independent agents, tied agents, brokers, aggregators and comparison sites, managing general agents with delegated underwriting authority: each one holds a credential to your broker portal, and none of them sit inside your endpoint estate or your mail gateway. A cloned broker login page harvests a producer credential, and that credential often carries the authority to view policyholder data across an entire book, bind cover under a delegated authority agreement, or amend payment details on an existing policy. Appointment and commission-statement lures work particularly well here because agents genuinely receive those messages from multiple carriers and cannot possibly know the correct sending domain for all of them.
The third direction is your own back office, and this is where the money actually leaves. Business email compromise aimed at a claims payment run, a repair network vendor whose invoice suddenly carries new bank details, a loss adjuster's correspondence redirected mid-thread, a treaty or facultative reinsurance settlement instruction arriving from a lookalike domain during quarter-end: these are not exotic scenarios, they are the routine texture of insurance fraud attempts. Every one of them begins with a hostname that a human being was asked to trust. Checking that hostname against a database of domains that are known to be phishing and known to be resolving right now does not solve the whole problem, but it removes a large, cheap, high-volume slice of it before a person has to make a judgement call.
Pages that mirror a claims tracking portal and ask a policyholder to re-authenticate before viewing a settlement decision that does not exist.
Overpayment or mid-term cancellation refunds that require card or bank details to process, timed to arrive shortly after a genuine renewal cycle.
Producer login pages harvesting agent credentials that carry book-wide visibility, quote authority and, under delegated arrangements, the ability to bind.
Fake appointment paperwork, licensing renewals and commission-statement notices sent to agents who legitimately receive these from a dozen carriers.
Vendor, adjuster and repair-network invoices with amended bank details, inserted into a claims thread that is already live and already trusted.
Lookalike domains used against treaty and facultative settlement correspondence, where amounts are large, counterparties are few and cycles are quarterly.
A claims department looks like customer service and behaves like a treasury. First notification of loss arrives through whatever channel the customer prefers: a web form, a mobile app, a broker's email, a call centre transcript, sometimes a letter scanned into the document management system. From that moment the file accumulates attachments and hyperlinks from parties nobody has verified, because verification is not what the intake step is for. The intake step exists to capture the loss quickly and start the clock on service metrics that the claims operations manager is measured on.
What follows is a correspondence workflow with an unusually wide surface. The adjuster exchanges messages with the policyholder, sometimes with a third-party claimant and their representative, with repair networks and hire providers on motor, with contractors and restoration firms on property, with medical providers and rehabilitation vendors on casualty and health, and with an internal fraud or SIU team when the file is referred. Each of those parties sends links: photo upload portals, estimate systems, invoice portals, scheduling tools. Handlers are trained to open them, because refusing to open them means the claim stalls.
Then the file reaches settlement. Payment instructions enter the core policy and claims platform, feed a payment file to bank rails, and clear. The window between "the adjuster receives revised bank details by email" and "the payment file is generated" is often measured in hours, and the control in that window is usually a callback procedure that a busy handler under service-level pressure may or may not complete. This is why the claims inbox is a soft target: it is a high-volume, deadline-driven, externally-facing queue whose staff are explicitly rewarded for speed and for engaging with strangers.
A domain check does not replace callback verification, and it should not be sold as if it does. What it does is remove the cases that never needed a human judgement in the first place. If a link in an inbound claims message resolves to a domain already recorded as an active phishing host, the message can be quarantined, the handler never has to assess it, and the SIU or security team receives a dated record of the attempt attached to the claim reference.
/api/v1/batch, and act on the domains that come back resolving and classified as phishing.A carrier's security programme covers the estate it owns. The distribution channel is not that estate. Independent agents run their own mail, their own endpoints and their own password habits. Tied agents may be closer, but rarely close enough to be inside your identity provider. Aggregators and comparison sites sit at arm's length behind an integration contract. Managing general agents hold delegated authority to underwrite and bind on your paper, which means an MGA credential compromise is not a data incident, it is an underwriting incident with reserves attached.
What all of them share is a login to your broker portal, and that login is what attackers want. A cloned portal page needs no zero-day and no malware; it needs a domain that looks close enough to yours and an email that arrives on a plausible pretext. Commission statements, appointment paperwork, licensing renewals, product training deadlines and rate-change notices are all genuine, recurring, unremarkable messages that a producer receives from several carriers, and none of them look suspicious. Once the credential is taken, the attacker inherits whatever the producer could see: policy data across a book, quoting authority, and in delegated arrangements the ability to issue a binder that you will be asked to honour.
The practical response is to put a domain check in two places you do control. First, inside the broker portal itself, at the point where it rewrites or renders any outbound link in a message, notification or document it serves to producers. Second, at agent onboarding and re-verification, where you collect an agency's email and web domains and can check them before they are trusted, then re-check them on a schedule as part of channel due diligence. The distribution compliance lead usually owns the second of these, and it is often the easier of the two to fund because it maps cleanly onto existing producer vetting.
Neither control asks the broker to change anything about how they work, which matters, because a distribution channel will not adopt a security measure that adds friction to placing business. The check runs on your side, against domains you already hold in your producer records or already surface in your portal, and its output is a flag rather than a block until you decide otherwise. Carriers that also sell through banks or affinity partners can point the same check at those relationships; the pattern is identical to the one described on our banking and financial services page.
The broker portal already rewrites outbound links for click tracking. Add a lookup at rewrite time and mark or interstitial any host that returns a hit.
Check the agency's stated email and web domains during appointment, then re-check the whole producer list on a schedule as part of channel due diligence.
Store the response with the producer record so the distribution compliance lead can evidence when a domain was checked and what the database said at the time.
curl "https://phishingdetectionapi.com/api/v1/check\ ?domain=agent-portal-login.example.org&apikey=YOUR_KEY" # -> is_phishing: true, dns_status: "resolves" # -> portal renders an interstitial, not the link
No supervisor requires a phishing domain database. Several require things that a phishing domain database helps you demonstrate, and the distinction matters when you write the control description.
Start with data protection, because it is the obligation that applies to every insurer holding policyholder records in Europe regardless of line of business. The GDPR requires security measures appropriate to the risk of the processing, and it requires notification of a personal data breach to the supervisory authority within 72 hours of becoming aware of it, with notification to affected individuals where the risk to them is high. Insurance data sits at the sensitive end of that spectrum: health claims data, financial circumstances, family and beneficiary relationships, sometimes criminal conviction data on motor and liability lines. A credential-harvest phishing page aimed at a member portal is a direct route to that data, which is why a domain-level control is straightforward to argue as appropriate to the risk.
Where the entity qualifies as an essential or important entity under NIS2, the obligations rise: stronger risk management measures, incident reporting duties, and explicit management accountability for the security posture. Not every insurer is in scope, and scope depends on national transposition and on the group's activities, so the honest framing for a board paper is conditional. If you are in scope, a named, versioned, daily-rebuilt control with an owner and an audit trail is exactly the kind of measure that answers the "what are you actually doing" question, and management accountability makes that answer something a board member needs to be able to give personally.
Beyond the specific instruments, insurance supervisors across most jurisdictions expect operational resilience and third-party risk management. That expectation covers the outsourcing arrangements insurers rely on heavily: third-party administrators, claims handling agents, loss adjusters, offshore processing centres, and technology providers running the core policy and claims platforms. A control that only protects the carrier's own staff mailboxes answers half the question. One that can also be applied to correspondence involving delegated parties, and to the domains those parties present, speaks to the outsourcing dimension the supervisor is asking about. Insurance distribution conduct rules add another angle: carriers are expected to treat customers fairly and to ensure communications are clear and not misleading. Suppressing domains that impersonate your own brand to your own policyholders is a conduct measure as much as a security one, which is why the distribution compliance lead often has more budget appetite for it than the security function does.
Finally, if the carrier underwrites cyber, it is already imposing control questionnaires on its insureds and pricing against the answers. That creates a reflexive obligation that no regulator has written down but every underwriting risk officer feels: it is difficult to require a control of an insured that the carrier has declined to implement itself. Describe all of this carefully in your control documentation. A domain lookup is one control among many, sitting alongside authentication, email authentication records, gateway filtering, payment callback procedures, awareness training and incident response. It is a good control precisely because it is narrow, verifiable and cheap to evidence, not because it covers the field.
Cyber and crime underwriters ask insureds what they do about phishing. The carriers that can answer the same question about themselves have a shorter, better conversation.
Insurance is the only sector that sells protection against the exact risk it is exposed to, and that produces a strange internal dynamic. A cyber underwriting team maintains a control questionnaire that asks insureds about multi-factor authentication, email filtering, phishing simulation programmes, backup regimes and payment verification procedures, then declines, prices or sub-limits accordingly. Meanwhile the carrier's own security function is fighting the identical attack pattern against its claims inbox and its broker portal. When those two conversations are held in the same building, the underwriting risk officer and the CISO end up with a shared vocabulary that neither would have developed alone.
There is a credibility argument and a financial one. The credibility argument is simple: a carrier that deploys a domain reputation check across its own claims and distribution channels can describe that control to a broker, a reinsurer or a regulator from direct experience, including its limits. The financial argument concerns loss ratios on the cyber and crime books. A material share of cyber claims and a very large share of crime and funds-transfer-fraud claims originate in a phishing email that led to a credential compromise or a redirected payment. Anything that reduces the frequency of the initiating event reduces claims volume, and the carrier that understands the control mechanically is better placed to judge whether an insured's stated control is real.
None of this justifies overclaiming. A domain lookup does not stop a well-crafted business email compromise sent from a legitimately registered, freshly compromised mailbox with no link in it at all. It does not detect a payment redirect delivered by phone. It handles the volume layer: the mass-produced, domain-driven, resolving-right-now phishing infrastructure that generates most of the attempts your staff and your policyholders will encounter this quarter. Treat it as a filter that clears the noise so your expensive controls, your callback procedures and your fraud analysts can spend their attention on the cases that actually need judgement.
The uncomfortable symmetry: the control questionnaire your cyber underwriters send to insureds asks about exactly the attack your claims department is losing money to this week, and in most carriers the two teams have never compared notes.
Either you call the API from the pipeline that already handles claims mail, or you pull the daily feed into infrastructure that never talks to the internet. Most carriers end up doing both.
The common integration is a batch lookup wired into whatever already parses inbound claims mail. Most carriers have something in that position: a mail gateway hook, a robotic process automation step that files attachments into the document management system, or an integration layer that turns an inbound message into an FNOL record in the core claims platform. Extract every hostname from the message body and from the attachment metadata, deduplicate them, and send up to 100 per call to /api/v1/batch. The response carries a per-domain verdict plus checked, phishing_found and credits_used, which is enough to decide whether to quarantine, flag for the SIU, or pass through untouched. Because a lookup returns in under 50 milliseconds, the whole check adds no meaningful latency to an intake step that is already waiting on document conversion.
Some carriers cannot make outbound calls from the relevant environment at all. Life and health insurers with hardened processing zones, groups running claims platforms inside a segmented network, and anyone whose architecture review board treats an outbound lookup from a data-bearing zone as a finding rather than a design choice all fall into this category. For them the daily feed is the right shape: a full CSV or JSON export of the database with domain,category,dns_status columns, exported at 04:30 UTC each day, retrieved once by a jump host and loaded into an on-premise DNS resolver as a response policy zone, into a firewall or proxy denylist, or into a SIEM watchlist for retrospective hunting across mail logs. The lookup then happens locally at resolution time, no query leaves the environment, and the security architect gets a control that satisfies the segmentation requirement without an exception. The feed is a subscription product; the pay-as-you-go credit packs cover the API path.
Whichever shape you choose, keep the API key server-side. The key is the username chosen at registration, and it belongs in a secrets store read by the integration service, never in a browser, a mobile app bundle, or a portal template rendered to a broker. Full endpoint reference, response schemas and rate behaviour are on the API documentation page, feed details on the daily feed page, and credit pack sizing on pricing.
"""Screen every hostname in an inbound FNOL message before an adjuster ever sees the mail. Max 100 domains per batch call.""" import os, re, requests API = "https://phishingdetectionapi.com/api/v1/batch" KEY = os.environ["PDA_API_KEY"] # server-side only HOSTS = re.compile(r"https?://([A-Za-z0-9.\-]+)") def screen_fnol(body: str, claim_ref: str): domains = sorted({h.lower().lstrip("www.") for h in HOSTS.findall(body)}) if not domains: return [] hits = [] for i in range(0, len(domains), 100): r = requests.post(API, json={ "apikey": KEY, "domains": domains[i:i + 100], }, timeout=10) r.raise_for_status() payload = r.json() # payload: results[], checked, phishing_found, credits_used for row in payload["results"]: if row["is_phishing"] and row["dns_status"] == "resolves": hits.append(row) if hits: quarantine(claim_ref, hits) # hold the message audit_log(claim_ref, hits) # timestamped evidence notify_siu(claim_ref, hits) # fraud team referral return hits # -> [{"domain": "claims-status-review.example.net", # "is_phishing": True, "category": "phishing/malware", # "dns_status": "resolves", "confidence": 0.98}]
Every candidate domain is resolved before it enters the database, using 50 concurrent threads through rotating proxies with a 10 second timeout. Only hosts with active A records are kept, and hosts that stop resolving are pruned on the next rebuild.
That matters to a claims investigation because a hit means the host was answering DNS at the last rebuild, not that it appeared on a list at some point in the past.
A single claims message routinely carries several distinct hostnames across body, signature and attachment metadata. The batch endpoint takes up to 100 domains per request and charges one credit per domain, so a whole message screens in one round trip.
See the same pattern applied to mail flow generally on email security.
The full database exports as CSV or JSON with domain,category,dns_status columns at 04:30 UTC daily. Load it into an on-premise resolver as a response policy zone, a proxy denylist, or a SIEM watchlist and no lookup ever leaves the segment.
Useful for retrospective hunting too: replay 90 days of mail logs against today's list during an incident response engagement.
This is a domain reputation lookup and a threat feed. It does not run an email gateway, render or sandbox pages, score URLs with a live classifier at request time, analyse message content, perform takedowns, deliver awareness training, or return registrar and WHOIS data. It will not catch a business email compromise sent from a legitimate compromised mailbox with no link in it, and it will not replace a payment callback procedure on a settlement instruction change.
What it does is answer, in under 50 milliseconds, whether a hostname is currently in a database of DNS-verified active phishing domains that is rebuilt every 24 hours from curated threat-intelligence and OSINT sources. Insurers place it in front of the expensive controls so that human judgement is spent on the cases that need it. Related reading: use cases for insurance, health insurance and brand protection.
Register for an API key and screen your first batch of hostnames today, or take the daily feed if lookups cannot leave your environment. Credit packs start at $59 for 10,000 lookups; the daily threat feed subscription starts at $499 per month.
