Medical Email Database: the NPI Is Public, the Inbox Is Not

There is a file waiting for you in this guide: 100 dermatology practices in Texas, exported with Derrick on 6 September 2026, free. Practice name, website, domain, city, full address, phone. The emails and the phone numbers of the people behind them are what the method below is for.

Medical email database: the short answer

A medical email database is built by resolving the organisation first and the named clinician second, because in healthcare the licence is public and the mailbox almost never is. The United States publishes every enumerated provider in the National Plan and Provider Enumeration System, and that register held 9,411,686 records as of 30 August 2026. It gives you the identity, the specialty and the practice address. It does not give you an email. That single gap is the whole job, and it is the reason every prebuilt medical file on the market is a join somebody else ran on a date you cannot see.

The second half of the job is deciding which clinician you actually mean. Nobody wants to email nine million providers. A search for a medical email database almost always means one of three narrower things: the physician or specialist who signs off on a clinical product, the practice manager or administrator who buys software and supplies, or the hospital executive layer that owns budget across dozens of sites. Those are three different lists pulled from the same register, and sending them the same message is why most healthcare campaigns underperform.

This guide walks the pipeline in order: pick the taxonomy that defines your segment, pull the organisations, resolve the named person, find and verify the address, then price the result per usable row. If you are starting from a city rather than a specialty, our guide on finding local business email addresses covers the geography-first version of the same pipeline, and the lawyers email list guide covers the same licensed-profession pattern in a different vertical.

What actually sits inside a medical email database

Two record types live side by side in healthcare data, and confusing them is the most expensive mistake in the pipeline. The national register assigns Entity Type 1 to an individual provider and Entity Type 2 to an organisation. A cardiologist has a Type 1 identifier. The cardiology group she practises in has a Type 2 identifier. A hospital has one, and so does each of its billing entities.

That distinction decides what an address even means. A Type 2 record resolves to a domain and usually to a generic inbox that a front desk reads. A Type 1 record resolves to a human being who may work at three affiliated sites under two different domains. If your campaign needs a clinical decision, you want Type 1 rows joined to a working domain. If you are selling supplies, billing services or practice software, the Type 2 organisation is often the better unit, and the person you want inside it is an administrator who has no clinical taxonomy at all.

Specialty is expressed through a healthcare taxonomy code, a ten character alphanumeric value from a set of more than 850 active codes. Every provider record carries at least one, and exactly one is flagged primary. This is the field that turns "doctors" into a segment you can actually mail: not "physicians" but the primary taxonomy for interventional cardiology, or paediatric dentistry, or clinical laboratory. A medical email database that cannot filter on primary taxonomy is a mailing list, not a segment.

Where the identity comes from, and why it is free

The enumeration register is public data, published by the federal payer system so that claims can be routed. Anyone can query it. There is a read API at the registry endpoint that needs no token and no registration, and the full file is published for download and refreshed on a schedule. You can search by name, by taxonomy, by city and by state, and you get back the identifier, the entity type, the legal and doing-business-as names, the primary practice address, a practice phone number and the taxonomy list.

What you do not get, in any version of that file, is an email address. The register was built to route claims, not campaigns. Vendors who sell a medical email database start from this same free identity layer, append addresses through pattern inference and verification, and charge for the append. That is a legitimate service. It is also something you can run yourself, on a date you choose, with a verification stamp you can point to.

France runs the same structure under different names. The Répertoire Partagé des Professionnels de Santé is published through the Annuaire Santé by the national digital health agency, released as open data, refreshed daily, and queryable through a standards based REST API. It carries identity, profession, specialty and place of practice, alongside the establishment register. Same shape, same gap: the register tells you who and where, not which mailbox answers.

Who you are actually emailing inside a practice or a hospital

A healthcare organisation is not a flat list of clinicians. It has a clinical layer, an administrative layer and, above a certain size, a procurement layer, and each one buys different things with different money. Pitching an electronic health record migration to a staff nurse, or a box of consumables to a chief medical officer, wastes the address you just paid to find.

Note what the middle column does to your sourcing. Below roughly three providers there is no administrator to email, so the clinician is the buyer and the generic practice inbox is often the only door. Above fifty, the clinician you found in the register is almost never the person who signs, and you need the executive email addresses pipeline instead. Headcount is not a nice to have filter here, it decides whether the role you want exists at all.

Build it: from taxonomy code to practice domain to verified address

The pipeline has five steps and each one is re-runnable on its own. Run them in order and stop at the first failure, because appending an address to an organisation you have not resolved is a credit spent on a question that was already answered.

Step one, define the segment. Pick the primary taxonomy and the geography before anything else. "Dermatologists in Texas" is a segment. "Healthcare" is not.

Step two, pull the organisations. Either query the public register by taxonomy and state, or start from a map search when what you want is defined by place rather than by code. A map search returns the practice as it presents itself publicly, with a website, a phone number and an address, which is exactly what you need to reach a domain.

Step three, resolve the named person. From the organisation, list the people inside it and filter by job function so you keep the administrator or the department lead rather than every clinician on staff. Find a company's people returns current and former staff at 1 credit per person, with no Sales Navigator seat needed.

Step four, find the address. With a first name, a last name and a domain, run an email lookup. Email Finder costs 5 credits per email and bills per result found, so a provider whose mailbox cannot be resolved does not cost you anything. When the practice publishes a contact address on its own site rather than using a pattern, Email & Social Extractor from Website pulls it directly at 2 credits per line.

Step five, verify and deduplicate. Never send on an unverified append. The details are in the next section, and Find Duplicates is unlimited and available on the free plan, which matters more than it sounds when the same clinician appears under three affiliated organisations.

What a medical email database costs, bought or built

Bought files are priced per record and quoted rather than listed. The claims cluster tightly: multi million record counts, accuracy figures in the mid nineties, deliverability promised in the mid eighties, and coverage across dozens of specialties. Read the second and third numbers together. An eighty five percent deliverability promise on a file you cannot re-run means roughly one in seven addresses is dead on arrival, and you find out by burning sending reputation to discover it.

Built rows price differently, because you pay per step and only for what resolves.

That is roughly 8 credits for a fully resolved and verified row. The free plan gives you 100 credits a month at no cost, which is about a dozen complete rows to test the segment before committing. Paid plans start at 9 euros a month, and at the largest plan the credit floor is 0.0016 euros, which puts a complete verified row at roughly 1.3 cents. Derrick scales the same way at a dozen rows and at a hundred thousand, so the arithmetic does not change shape when the list does.

Verify the addresses before the first send

Healthcare domains are unusually hostile to naive verification, for two structural reasons. Hospital groups consolidate dozens of acquired practices onto one mail domain, so pattern inference that works on a standalone clinic collapses. And clinical domains sit behind security gateways that accept everything at the edge, which is the definition of a catch-all.

Run four checks, in this order, and stop at the first failure.

1. Domain resolves and accepts mail. No mail exchanger, no campaign. This is free to check and eliminates a surprising share of rows pulled from map data, where the website field points at a booking platform rather than the practice.
2. Mailbox exists. Email Verification costs 1 credit per email and is the cheapest insurance in the pipeline.
3. Catch-all status. A domain that accepts every address tells you nothing about the one you hold. Our catch-all email guide covers how to detect them and what to do with the rows instead of deleting them.
4. Bounce threshold before send. Decide the rate you will not cross and hold the list to it. The bounce checker guide covers the thresholds worth holding yourself to, and what makes an address valid explains the difference between syntactically correct and actually reachable.

Why healthcare files rot faster than most lists

The identity record in a public register is durable. A clinician keeps the same identifier for a career. The mailbox is not durable at all, and the gap between those two facts is what quietly kills a purchased file while every row still looks correct.

Three decay drivers dominate in healthcare. Affiliation churn comes first: a physician moves from an independent group to a hospital system and the domain changes even though the name, the specialty and the licence do not. Consolidation comes second: when a group is acquired, an entire block of addresses migrates to the acquirer's domain in one weekend, and a file bought the week before is now wrong in bulk rather than one row at a time. Locum and part time practice comes third, where the same person is genuinely reachable at two domains and only one of them is read.

The operational answer is not to verify more often. It is to keep the definition rather than the file. If your list is stored as "primary taxonomy X in state Y, resolved to organisation, resolved to administrator, verified on this date", you re-run it. If it is stored as a CSV of addresses, you re-buy it.

Running the whole pipeline in one sheet

This pipeline is worth building rather than buying because it lives in one spreadsheet you control, and every column carries a date. One row per provider or per organisation, columns filling left to right, each one re-runnable on its own: organisation name, website, domain, named person, job function, found address, verification status, verification date.

The same steps run from three surfaces, and the right one depends on where the list needs to end up. A spreadsheet sidebar is the natural home when a human is going to read and edit the rows. The REST API is the right surface when the list belongs in a CRM and has to refresh on a schedule. And an MCP connection is the right one when you would rather ask an AI assistant for "dermatology practices in Austin with a named administrator and a verified address" and get rows back in the conversation. A web app is coming as well. Pick the surface for the workflow, not the other way round.

Six mistakes that ruin a medical email database

1. Treating individual and organisation records as one list. A Type 1 and a Type 2 identifier answer different questions. Mixing them produces a file where half the rows have no human to address.
2. Filtering on job title instead of primary taxonomy. Titles in healthcare are inconsistent across systems. The taxonomy code is the field that was designed to be filtered.
3. Buying on record count. Millions of rows is a claim about the register, which is free. The only number that matters is how many rows survive verification on the day you send.
4. Skipping the catch-all check on hospital domains. Security gateways accept everything. A verification pass that does not test catch-all status will report a clean list that bounces.
5. Mailing the clinician when the administrator signs. Above a handful of providers, the person with the licence is rarely the person with the budget.
6. Storing the file instead of the definition. A dated, re-runnable segment survives a consolidation weekend. A CSV does not.

Key takeaways

• The public register held 9,411,686 provider records as of 30 August 2026, and publishes identity, specialty and practice address, but never an email.
• Entity Type 1 is a person and Entity Type 2 is an organisation, and the two demand different pipelines.
• Primary taxonomy, a ten character code from a set of over 850, is what turns "doctors" into a segment worth mailing.
• Role exists as a function of headcount: no administrator below about three providers, no clinician signing above about fifty.
• Affiliation churn and group consolidation kill the mailbox while the identity record stays perfectly true.
• Building costs roughly 8 credits per fully resolved and verified row, and leaves you a dated definition instead of a static file.