Supplier fraud rarely looks like fraud. It looks like a routine remittance query from a partner you have traded with for nine years, referencing a live purchase order, in a thread that already existed. Verifying the domain in that message is a small, mechanical control that belongs in the purchase-to-pay process — and it is honest about what it cannot see, which is a genuine supplier whose mailbox is already compromised.
The successful version of supplier fraud contains no red flags, because the attacker has been reading the correspondence and knows exactly what a routine message looks like.
Start by discarding the picture most awareness material paints. The successful supplier fraud is not a badly written message from an unknown address demanding urgent action. It is a reply in an existing thread, referencing a purchase order number that genuinely exists, attached to an invoice formatted exactly like the last eleven from that supplier, arriving in the week the payment run was expected, from a person the clerk has spoken to on the phone. Everything about it is correct except one field, and that field is the account the money goes to.
In the first, the attacker registers a domain closely resembling the supplier's — a transposed pair of letters, a digit substituted for a similar-looking character, a hyphen inserted, the same second-level name under a different top-level domain — and sends from there. In the second, the attacker is inside the supplier's real mailbox, and the message comes from the genuine domain because it genuinely originated there. Conflating the two is how organisations end up with one control and two problems.
A look-alike hostname is a factual thing: either it has been observed and verified as live phishing infrastructure or it has not. Asking that question at the moment a payment instruction changes is a control costing a fraction of a credit that takes less time than opening the invoice. It is the kind of check that should have been automatic in purchase-to-pay systems for a decade, and in most organisations it still is not.
When the message comes from the supplier's real domain, no domain reputation check will flag it, because there is nothing wrong with the domain. The supplier is legitimate, the mail authentication passes, the thread history is genuine, and the attacker may have been reading that mailbox for weeks waiting for an invoice large enough to be worth the effort. What solves it is out-of-band verification of payment-detail changes, on a number held in your own records, applied without exception.
A team that believes domain checking has solved supplier fraud will relax the callback procedure, and the callback is the control catching the case the domain check cannot see. The two are complementary and the second is the more important one. Domain verification removes a large, cheap, high-volume category of attack from the queue so that the expensive human control has capacity for the residue.
In most organisations a bank-detail change travels through the same channel as everything else and is assessed by whoever happens to open it. The controls that exist are written down but discretionary, and discretion under time pressure is not a control.
Every step below is a scheduled job or a system hook rather than a judgement call. None of them replaces the callback; they narrow what the callback has to catch and give the person making it something factual to work from.
/check before the record is created/batch, 100 per requestThe annual questionnaire and the technical verification answer different questions. Most programmes have the first and assume it covers the second.
Third-party risk management as practised is largely a documentation exercise. A supplier receives a questionnaire, someone at the supplier fills it in, the answers are stored, and a risk rating is derived from them. This has real value for governance — it establishes that questions were asked, it creates a contractual hook, and it occasionally surfaces something genuinely alarming. What it does not do is verify anything. Every answer is a self-assertion, collected once a year, about a state of affairs that changes weekly.
last_checked date behind each verdict, for your own evidence fileRead the last row of the right-hand column carefully, because it is the honest boundary of this whole approach. You can verify domains you know about. A supplier's subcontractor, and that subcontractor's supplier, are invisible to you unless somebody names them, and in most industries nobody does. Tier-two and tier-three exposure is real, it is routinely cited as the reason supply chain compromise is hard, and a domain verification layer does nothing about it whatsoever.
Brand protection programmes watch for imitations of the company's own name. The domains that will be used against your accounts payable team imitate somebody else's.
There is a blind spot in how most organisations think about domain impersonation, and it follows directly from who owns the budget. Brand protection is funded by marketing or legal, its purpose is to defend the company's own name, and it monitors variants of that name. That is worth doing and it protects customers. It does nothing for the fraud that actually reaches your finance function, because that fraud does not impersonate you — it impersonates the firm that supplies your packaging, your contract manufacturer, your freight forwarder or your software reseller.
Your supplier may be too small to run a brand protection programme, may not know one exists, and in any case has little incentive to detect an imitation aimed at their customers rather than at their own revenue. The party with both the exposure and the motive is you — and the raw material required is something you already hold: a list of every domain in your vendor master data.
Take the registrable domains of your suppliers and generate the standard variant families around each: character transposition, single-character substitution including visually similar digits and letters, omission and duplication, hyphen insertion and removal, the same second-level name under other common top-level domains, and word-suffix patterns such as appending billing, invoices, portal or support. Then check them through /batch — a hundred domains per POST at one lookup each, returning checked, phishing_found and credits_used.
This tells you whether a specific hostname has been observed and verified as currently resolving credential-harvesting infrastructure. It does not tell you a variant has merely been registered, that a certificate was issued, or that somebody parked it in anticipation. It answers a smaller question with a much higher standard of proof — so a confirmed result is live infrastructure to block and to warn the supplier about today, not a possible risk to investigate. Teams running the broader watch pair this with brand protection for their own name.
The variants worth generating are those around suppliers you pay large amounts to, on predictable cycles, through processes with human discretion in them. A hundred suppliers invoicing occasionally for small sums are not where a fraudster invests effort; the three receiving seven-figure payments on quarterly terms are. Sorting the sweep by annual spend turns a large undifferentiated job into a focused one, and makes the report legible to whoever signs off the credit spend.
The distinction between "somebody reported this" and "this resolves right now" is what determines how confidently a finance system can act on a match.
A control embedded in a payment process has a higher bar than an analyst's enrichment feed, because a false positive stops money moving and an operations manager will disable the check after the second one. That bar is met by verification rather than by volume. Every domain in this database has been confirmed as having an active A record through rotating proxy infrastructure, and entries that stop resolving fall out rather than accumulating — so the list is a picture of what is live rather than an archive of everything ever reported.
A blocklist that accumulates historical reports will eventually contain a domain that was hostile two years ago, was taken down, and has since been re-registered by somebody entirely legitimate — possibly by a small supplier who bought an available name without knowing its history. A finance control that blocks payment to that supplier generates an expensive, embarrassing false positive with a very awkward explanation. A list containing only hosts confirmed as resolving now does not have that failure mode.
A confirmed match returns a confidence of 0.98 with a category of phishing/malware and dns_status of resolves; anything not in the database returns 0.0. There is no graded middle band, so no threshold for a finance systems team to configure, no drift as somebody recalibrates a model, and no ambiguous result interpreted two different ways in one department. The last_checked date tells you how current the verdict is — exactly the field an auditor asks about.
It means the hostname is not on this list. It does not mean the supplier is legitimate, the invoice genuine or the bank details correct — and a purchase-to-pay screen rendering a green tick on a 0.0 response is actively harmful, because it converts an absence of evidence into a positive assurance a clerk will reasonably rely on. Label it "no known match" and keep the callback requirement visible regardless of the result.
DNS-verified domains active at any one time, with dead entries falling out rather than accumulating
Daily rebuild time, with a changelog of additions and removals for incremental updates
Domains per batch request at one lookup each — the shape a vendor-master sweep needs
Response time, fast enough to sit inside an invoice-posting workflow without being noticed
Screening everything everywhere produces alert fatigue in a team that has no capacity for it. Screening at the decision points produces a control.
The temptation with any verification capability is to apply it everywhere, and in a finance function that is a mistake. Accounts payable teams are small, busy and measured on throughput, and a control that interrupts them frequently will be worked around within a month. The right approach is to identify the specific moments where a bad decision is irreversible and put the check exactly there.
When a supplier record is created, the domain attached to it enters your master data and will be trusted implicitly for years. Verifying it once at creation costs one credit and prevents an entire class of problem — the fraudulent vendor set up with a plausible domain already used in campaigns elsewhere. It is a straightforward hook into whichever procurement platform you run, whether SAP Ariba, Coupa, Oracle Procurement Cloud or a home-grown system, and it sits naturally alongside existing checks on company registration and tax identifiers.
This is the event the entire fraud is designed to produce and it should be the most heavily controlled transaction in the finance function. The domain check belongs here as a hard gate rather than an advisory flag: a confirmed match stops the change and escalates. But it is the smaller half of the control — the larger half is the out-of-band callback to a number held in your records, made by somebody other than the person who received the request, documented, and required without exception even for suppliers of twenty years, because length of relationship is exactly what the attacker exploits.
Domains change hands. Suppliers get acquired and migrate to a parent's domain. A registration lapses and somebody else picks it up. None of that generates an event in your finance system, so the only way to see it is to look again on a schedule. A monthly sweep of every domain in the vendor master, plus the generated variants around your highest-spend suppliers, is a small batch job whose output is usually empty — and the month it is not empty pays for every month it was.
Screening inbound message domains at the mail gateway is worth doing but belongs to mail security, covered on the email security page. Screening links in logistics portal notifications is worth doing where shipping and customs documentation drives operational decisions, and the transportation and logistics page goes into that. Neither belongs in the finance workflow, and putting them there is how you end up with a control the finance team resents and works around.
Seven stages, each owned by somebody specific. The sequence matters because the later stages only work if the earlier ones produced clean data.
Most vendor master schemas store a contact email and nothing else, which means the domain exists only as a substring nobody can query. Add an explicit registrable-domain field to the supplier record, populate it at creation, and treat it as master data with the same change controls as the bank account. Everything downstream on this timeline depends on that field existing.
Owner: procurement systemsHook /check into the vendor creation workflow so the domain is verified before the record can be approved. Store the whole response — is_phishing, category, confidence, dns_status and last_checked — against the record rather than just a pass or fail, because in eighteen months somebody will ask what was known at the time and a boolean will not answer them.
Sort by annual spend and payment predictability rather than by supplier count. The output is a working list of the suppliers whose impersonation would actually be profitable, and it is the input to variant generation. Refresh it quarterly, because spend concentration moves and last year's top ten is not this year's.
Owner: finance analyticsProduce the standard variant families around each high-exposure supplier domain and submit them through /batch at a hundred per request. Log phishing_found per run so the trend is visible. A confirmed match is not a research finding — it is live infrastructure, and it should trigger a gateway block and a same-day notification to the supplier.
A confirmed match blocks the change outright. A clean result changes nothing about the callback requirement, which stays mandatory, uses a number from your own records, and is performed by somebody other than the person who received the request. Write into the procedure that a 0.0 result means "no known match" rather than "verified genuine" — that sentence is what stops the callback quietly lapsing.
Owner: accounts payableBatch every stored supplier domain against the current database once a month. Most runs return nothing, which is the correct and boring outcome. The value is in catching the case where a supplier's domain lapsed, was re-registered, and is now being used against their other customers — an event that generates no signal at all inside your own systems.
Owner: security operationsDated verification records against each supplier, dated sweep outputs, and the archived daily changelog together demonstrate a continuous control rather than an annual assertion. That is a materially stronger position under supplier-relationship controls than a folder of returned questionnaires, and it is far easier to produce because it is generated by the process rather than collected for the audit. The accounting and tax page covers adjacent finance workflows.
Owner: internal auditA domain blocklist is a narrow control with a clear edge. Knowing exactly where that edge is determines what else you have to build.
The most important limitation has already been named and is worth repeating in its own section, because it is the one people forget once a control is deployed and running quietly. When a genuine supplier's mailbox is compromised and the fraudulent message originates from their real domain, there is nothing for a domain check to find. The domain is legitimate, the authentication passes, and the correspondence history is real. This is not a gap in the data; it is a category of attack that operates entirely outside what domain reputation can express. The control for it is the out-of-band callback, and no amount of technical verification substitutes for it.
This is a known-bad lookup, and a domain must be observed and verified as resolving before it can appear. A hostname registered this morning and used for the first time this afternoon will not be there. That window is genuinely exploited — some supplier fraud operations register a look-alike days before the invoice cycle they target — and it is inherent to every blocklist ever built. A clean result means "not on the list", never "safe".
Your direct suppliers are in your master data; their suppliers are not, and their suppliers' suppliers certainly are not. Tier-two and tier-three exposure is real and this does not address it. The only levers at that depth are contractual disclosure requirements and incident notification obligations flowing down the chain, both of which weaken with distance and neither of which gives you anything you can actually check.
It will not tell you that an invoice amount is wrong, that a purchase order does not exist, that goods were never delivered, or that a legitimate supplier is quietly overbilling you. Those are procurement and financial control problems requiring three-way matching, spend analytics and segregation of duties — which most organisations already have, and which this sits alongside rather than replacing.
Look-alike domain fraud is the highest-volume, lowest-effort supplier fraud there is, precisely because it requires no access to anybody's mailbox. Removing it mechanically at three defined points in purchase-to-pay, for a cost measured in fractions of a cent per check, frees the expensive human control for the cases that genuinely need judgement. Teams running the same verification on the payment side will find the payment processors and banking and finance pages relevant.
Including the objection that this does not stop the attack everyone is most afraid of — which is correct.
Directly, no. If the message genuinely originates from your supplier's real domain because an attacker is inside their mailbox, a domain check finds nothing wrong, because nothing about the domain is wrong. Any vendor telling you their domain intelligence stops vendor email compromise is describing a different product than the one they are selling.What it does is clear the other category out of the way. Look-alike domain fraud is far more common because it requires no access to anyone's systems, and handling it mechanically means your callback procedure, your dual-approval rule and your payment-run review are spending their attention on the harder cases. Build the out-of-band verification first if you have to choose; add this to reduce what it has to catch.
Yes, and it is cheaper than most people expect. Three thousand domains is thirty batch requests at a hundred per POST, one lookup each — three thousand credits for a complete sweep of the master data. On the $249 Professional package of 100,000 credits at $0.0025 per lookup, a monthly full sweep uses a small fraction of the year's allocation.Variant generation is what actually consumes credits, because each supplier expands to dozens of candidates. That is why the ranking step matters: generate variants for the suppliers whose impersonation would be profitable rather than for all three thousand. In most organisations that is a few dozen names, and the arithmetic stays comfortable.
Treat it as live infrastructure and act the same day, but do not assume you know which of two situations you are in. Either the supplier's domain has been compromised and is hosting a phishing page, or — more commonly — what matched was a look-alike variant rather than their genuine domain, and somebody has misread the report. Confirm which before you contact anybody.If it is the genuine domain, block it at your gateway, suspend outbound payment instructions relating to that supplier pending verification, and telephone a known contact rather than emailing. The supplier frequently does not know. Being the customer who tells them is a better conversation than being the customer who paid the wrong account and asks afterwards.
Yes, through whatever extension mechanism your platform provides — a workflow hook on vendor creation, a middleware service between the platform and your master data, or a scheduled job against an export. The API is a plain REST call returning JSON, and the integration surface is small enough that it is usually a few days of work rather than a project.Two constraints to plan for. The API key is the username chosen at registration and it is a server-side secret, so the call has to be made from middleware or a backend service rather than from anything a browser loads. And the rate limit of ten requests per second per key means a large overnight sweep needs pacing rather than a burst — one batch request of a hundred domains counts as one request, which is why batching matters.
For purchase-to-pay alone, credits are usually the right shape. The workload is bounded — onboarding checks, bank-detail change gates, monthly master sweeps and variant runs — and that is a lookup pattern rather than a bulk-matching one. the Growth plan is $99/month for 25,000 lookups, the $99 Growth package 25,000 and the $249 Professional package 100,000, all billed monthly through PayPalunder ten percent is used.The Daily Threat Feed at $499 per month becomes the better answer when the same list is also going into your mail gateway, resolver or proxy, because those need the whole database locally rather than per-domain lookups. The annual option includes 100,000 credits, which covers the procurement-side checking without a separate purchase. Both are set out on the pricing page for organisations that cannot use a card.
It is unlikely, and the verification standard is the reason. A domain only appears in the database if it has been confirmed as currently resolving through rotating proxy infrastructure, and entries that stop resolving drop out rather than accumulating — which removes the classic false-positive source of a long-dead domain that has since been legitimately re-registered.Design for it anyway. Keep a reviewed allow-list applied after each import so an override survives the next update, make the block message name the specific domain and the date of the verdict, and route escalations to a named person rather than a shared mailbox. A control that stops a payment needs a human on the other end within the hour, and that is an operational design decision rather than a technical one.
They are answering different questions. Due diligence establishes whether a company is real, solvent, appropriately insured and contractually acceptable, largely from registry data and documents. It is a point-in-time assessment of an organisation. Domain verification asks whether a specific hostname is, today, confirmed live credential-harvesting infrastructure — a continuous assessment of one technical fact.The overlap is close to zero and the cadence is completely different. Due diligence happens at onboarding and perhaps annually; the domain screening runs monthly and takes minutes. Present it to a change board as an addition to the periodic control set rather than as a replacement for anything, because that is what it is.
One tier, honestly. You can verify the domains of suppliers you have records for. You cannot verify a supplier's subcontractor unless that subcontractor has been disclosed to you and entered into your own data, and in most industries disclosure is partial at best and stale by the time you receive it.What works at depth is contractual: disclosure of material subcontractors, incident notification obligations that flow down, and a requirement that suppliers impose the same terms on theirs. Enforcement weakens with every hop and everyone in the field knows it. Anybody offering technical visibility into tier three is building a graph from public records that will systematically miss the small firms doing the actual work — and those are precisely where the exposure sits. The manufacturing page covers this from the production side.
Export the supplier domains you have on file, run them through a single batch sweep, and see whether anything in your own master data is currently confirmed as live phishing infrastructure. It is a few minutes of work and a handful of credits, and it tells you more about your third-party exposure than a year of returned questionnaires.
