A job brings together a main contractor, thirty subcontractors, a design team, a quantity surveyor and a materials supply chain that have never worked together before — and then asks them to exchange payment instructions under deadline. Screening the domain behind every link and every supplier record is the cheapest control you can add to that.
Construction does not have a corporate network problem so much as a counterparty problem. The people you email most on a live job are the people you have known the shortest time.
Most industries build their email trust slowly. A bank knows its correspondent banks, a hospital knows its group purchasing organisation, and both have years of message history to lean on. A construction project has none of that. The moment a tender is awarded, a main contractor starts corresponding with a groundworks firm, a steel fabricator, a mechanical and electrical package contractor, a scaffolding hire company, a structural engineer, an architect, a party wall surveyor and a dozen materials merchants — often for the first and only time. Every one of those relationships begins with an unfamiliar sender, an unfamiliar domain, and an immediate need to exchange documents that carry money.
That would be manageable if the pace were gentle, but it never is. Programme pressure is the defining condition of the industry. A drawing revision that arrives at four in the afternoon has to reach the site manager before the pour the next morning. A pay application has to be certified inside a contractual window or the subcontractor has statutory grounds to suspend. A materials order has to be confirmed before the merchant releases the delivery slot. Everybody involved knows that stopping to verify something costs a day, and everybody has been trained by the job itself to treat a day as expensive. Attackers do not need to defeat scepticism; they only need to arrive at the moment when scepticism is inconvenient.
Add to that a document culture built almost entirely on attachments and portal links. Bid invitations arrive as links to a plan room. Prequalification questionnaires arrive as links to a supplier portal. Drawings arrive as links to a document-control platform. Pay applications and lien waivers arrive as links to a payment-application system that half the supply chain has never used before. A member of a site team who receives an unfamiliar link to an unfamiliar portal has no baseline for what is normal, because on this project nothing is yet normal. Training people to "look for a suspicious domain" fails in exactly this environment, since every domain is new.
Finally, the money is large, lumpy and scheduled. Interim payments run to six and seven figures, they happen on predictable dates, and the instructions that direct them travel by email. An attacker who reads a single mailbox for two weeks learns the valuation cycle, the certifier's name, the exact phrasing of a remittance advice and the identity of the subcontractor whose payment is next. Business email compromise is not an exotic threat here. It is the natural consequence of the way the industry does business, and it is why the controls that work are the mechanical ones you can attach to a workflow rather than the ones that depend on somebody being suspicious at the wrong moment.
These are the recurring shapes. They differ from generic corporate phishing because each one impersonates a document type that only exists on a construction project.
A fake invitation to tender points at a lookalike plan-room login. The estimator enters the credentials that also open the real plan room, the mailbox and often the ERP single sign-on.
Supplier prequalification asks for insurance certificates, bank references and company registration data. A cloned prequal form is a complete identity kit for impersonating that supplier later.
Conditional and unconditional waivers are signed on portals nobody uses more than monthly. A lookalike waiver portal harvests a signatory's credentials at the exact point in the cycle when money is about to move.
A spoofed subcontractor domain sends a remittance update on convincing letterhead, timed to the valuation date. This is the single most expensive event in the category and the one worth engineering around.
Fake delivery confirmations for aggregate, rebar, glazing or plant reference real order numbers scraped from an earlier compromise, and carry a tracking link to a credential page.
Excavators, telehandlers and tower cranes are advertised below market on lookalike dealer sites. A deposit is wired, the site never receives the machine, and the domain is gone within days.
Drawing and RFI platform credentials are the richest prize on a project. They yield the full document set, the contact list, the revision history and a plausible identity for the next message.
A design consortium or contracting JV legitimately corresponds from three or four unrelated corporate domains plus a project-specific one. Nobody can say which is genuine, and attackers register the fifth.
Site managers, foremen and gangers read project mail on unmanaged handsets over jobsite Wi-Fi or a hotspot, where no gateway, no proxy and no endpoint agent is in the path.
What ties the list together is that none of these messages need to be clever. They need to be plausible in a context where the recipient has no memory to compare against. An estimator who receives forty tender invitations a month cannot tell you which plan rooms are legitimate, because the answer changes with every client. A commercial manager processing thirty pay applications cannot tell you which waiver portals are real, because each general contractor mandates a different one. The attacker's advantage is not technical sophistication; it is that the industry has normalised a workflow in which strangers send you links and you click them.
The second thing they share is timing. Almost every item on that list is anchored to a scheduled event — a bid deadline, a valuation date, a delivery window, a practical completion certificate. Those dates are frequently public, published in tender notices, contract awards, planning records and trade press. An attacker who wants to know when a project's next interim payment falls due does not need to compromise anything to find out roughly when to send the message. This is why controls that fire on a schedule, such as a quarterly re-screen of the vendor master, do more good than they look like they should.
The third is that the weakest party is usually the smallest. A two-person formwork subcontractor with a mailbox on a consumer email tier and no multi-factor authentication is a far softer entry point than the main contractor's own estate. Once that mailbox is read, everything the attacker sends is genuinely from the right company, with the right history, and no domain-based control anywhere in the chain will flag it. Recognising that limit honestly is the starting point for designing controls that still help, which is the subject of the rest of this page and of our note on email gateway screening.
Invoice redirection on a project rarely happens in one message. It is a sequence with a long, quiet middle, and each stage offers a different place to interrupt it.
The contract award, the planning application, the site hoarding and the trade press between them name the client, the main contractor, the architect and often the principal subcontract packages. From there, professional networking profiles supply the commercial manager, the quantity surveyor and the accounts payable clerk by name and job title.
A lookalike domain is registered for a plan room, a prequal portal or a document-control platform, and the phishing message goes to whoever is most likely to be mid-workflow — an estimator during tender, a document controller during a drawing issue. The domain resolves, holds a valid certificate and often serves a passable copy of the real login.
With working credentials the attacker reads rather than acts. Two to six weeks of observation yields the valuation cycle, the certification wording, the names on the approval chain, the format of a remittance advice and the identity of the subcontract package whose payment is largest and next.
A domain that differs from the subcontractor's by a hyphen, a doubled letter or a swapped top-level domain is registered and mail-enabled. Sometimes it is only used for the reply address; sometimes an entire fake correspondence thread is fabricated on it to make the request look like the continuation of something already agreed.
The request arrives on letterhead, referencing the correct project, the correct package and the correct application number, and it is timed to land two or three days before the certified payment date. It frequently includes a plausible reason — a factoring arrangement, a group restructure, a change of banking provider — and a phone number that reaches the attacker.
The funds move and are layered onward within hours. Nothing looks wrong until the real subcontractor chases the payment, which on a monthly cycle can be three or four weeks later. By then the receiving account is empty and the lookalike domain may already have stopped resolving.
The subcontractor has not been paid and has contractual remedies. The main contractor has paid. The argument about who bears the loss involves insurers, solicitors and often the client, and it runs alongside a live programme. The direct loss is rarely the largest number in the file.
Reading that sequence as an engineer rather than as a victim, three stages are mechanically checkable and four are not. Stage two involves a link to a domain, and a domain can be looked up. Stage four involves a sender domain, and that can be looked up too. Stage five involves a payment instruction attached to a supplier record, and that record contains domains that can be checked before the change is approved. Stages one, three, six and seven involve human judgement, contract law and money already gone. Automation belongs where the artefact is a domain; process belongs everywhere else.
The design principle for the whole page
This is also why an honest description of what a known-bad lookup does matters. Checking a domain against a database of confirmed, currently-resolving phishing infrastructure catches stage two reliably when the campaign is not brand new, and catches stage four when the lookalike has been used elsewhere and reported. It does not catch a first-use domain registered specifically for one project, and it does not catch a message sent from the genuinely compromised mailbox of a real subcontractor. Those need call-back verification and the kind of workflow discipline described further down, and they need an incident response path that assumes some of them will get through.
None of these depend on a person being alert. Each one is a check that fires on its own, attached to a workflow that already exists in your business.
Extract the host from every URL in inbound external mail, strip the scheme and path, and call the check endpoint. The API does the stripping for you, so a full URL passed as the domain parameter still resolves to the right host.
Cache verdicts locally for the day. On a project mailbox the same handful of portal domains appear hundreds of times, and a local cache turns a five-figure daily volume into a four-figure one.
Before a new subcontractor or merchant record is created, check the email domain, the website domain and the domain of any remittance portal they nominate. Three lookups against a record that will carry payments for the next two years.
Store the verdict, the date and the database size returned on the record itself. It becomes the audit artefact your insurer and your auditor will ask for.
Export the domain column from your finance system, deduplicate it, and push it through the batch endpoint in chunks of one hundred. A vendor master of a few thousand records clears in under a minute of wall clock at the published rate limit.
Run it once as a baseline, and treat every hit as an incident rather than a data-quality issue — a live phishing domain sitting in your payables master means somebody was already targeted.
Add a domain check to the approval workflow for any change of payee bank details, alongside the call-back to a number held on file. The check is not a substitute for the call-back; it is a second, mechanical opinion that never forgets to run.
Make the check block the approval on a positive verdict rather than warn. A warning in an approval queue is a warning nobody reads on the day the queue is long.
Site offices, welfare cabins and jobsite Wi-Fi run on whatever router the connectivity provider dropped in. A daily CSV loaded into that firewall or a small DNS sinkhole covers the unmanaged phones that no gateway will ever see.
The feed ships a changelog of domains added and removed, so the site device only ever applies a delta rather than reloading the whole list over a mobile backhaul.
A domain that was clean when the supplier was onboarded may be phishing infrastructure a year later. Expired domains get re-registered, small firms lose control of their hosting, and abandoned project microsites are bought by whoever notices first.
A quarterly re-run of the same batch job costs the same as the baseline and turns a one-off check into a control with a heartbeat.
The ordering above is deliberate. Gateway link screening has the widest coverage because every one of the nine attack shapes eventually involves a link, but it is also the most work to build and the most expensive to run. The bank-detail gate is the opposite: a handful of lookups a month, trivial to wire into an approval workflow, and sitting directly in front of the loss you care most about. If you can only do one thing this quarter, do number four. If you can do two, add number three, because the baseline sweep tells you whether you already have a problem.
Numbers five and six are the ones firms skip and then regret. Site connectivity is nobody's favourite asset — it is temporary, it is often a mobile router in a cabin, and it is usually procured by the project rather than by IT. That is exactly why it ends up carrying the personal handset of the site manager who approves deliveries. Loading a daily list onto it is a small piece of work that covers a population of devices your endpoint estate does not include, and it complements a broader DNS filtering posture on the corporate side.
All six assume you have somewhere to send a positive verdict. Decide that before you build any of them. A hit that raises a ticket nobody triages is worse than no check at all, because it creates the paperwork of a control without the effect of one. The simplest arrangement that works: gateway hits quarantine and notify the security mailbox; onboarding and bank-change hits block the workflow step and notify the commercial lead as well as security; batch sweep hits open one ticket per affected vendor record with the finance owner named on it.
Knowing precisely what a domain check does and does not tell you is what separates a control that works from a control that produces false confidence.
The service behind every integration on this page answers one question: is this domain a known, currently-live phishing domain? It is a lookup against a continuously maintained database of over 200,000 DNS-verified active phishing domains, rebuilt every twenty-four hours with the daily build landing at 04:30 UTC. Verification is the part that matters operationally — every domain is resolved through rotating proxy infrastructure and only kept if it still has an active A record, so parked and dead entries fall out of the list instead of accumulating into noise. A confirmed match comes back with is_phishing true, a category of phishing/malware, a DNS status of resolves, a last-checked date and a confidence of 0.98. No match returns confidence 0.0.
It is not a heuristic page classifier. It does not render the page, look at the logo, score the HTML or make a judgement about a domain it has never seen. That distinction is the single most important thing to internalise when you design around it, because it dictates where the check belongs in your architecture. A known-bad lookup is a fast, deterministic, low-false-positive gate that you can put in a blocking position with confidence — which is precisely what you cannot do with a probabilistic classifier in front of a commercial manager who needs to certify a payment today. In exchange, you accept that it will be silent on a domain registered this morning and used once.
So pair it. The verdict from this API should be one input among several in your own decision, not the whole decision. On a project mail gateway, a natural combination is: a positive verdict from the database blocks outright; a negative verdict on a domain that is also younger than thirty days, not on your vendor master, and carrying a credential-shaped link gets flagged for review; a negative verdict on a domain that has been in your vendor master for two years and appears in a hundred prior threads passes. You already hold most of those signals. The lookup supplies the one you cannot generate yourself, which is global knowledge of infrastructure that is phishing somebody else right now.
The operational envelope is worth stating plainly too, because it shapes what you can build. Single checks and batch calls are rate limited to ten requests per second per API key, and a batch call carries a maximum of one hundred domains, billed one credit per domain. A separate free, unauthenticated stats endpoint reports the current database size and last update, which is genuinely useful as a monitoring probe: if your nightly job sees a stats response whose update timestamp has not moved, you know before your users do. Full details of the request and response shapes are in the API documentation.
Two integrations carry most of the value. Both live in the finance system rather than in security tooling, which is why they are usually the last ones anybody builds.
Start with the vendor master, because it is a finite, bounded object and you can finish the job. Export the supplier table, take the domain from the primary contact email, the website field and any remittance or portal URL you hold. Normalise them — lowercase, strip the scheme, strip the path, strip a leading www — and deduplicate. A contractor with four thousand supplier records typically ends up with somewhere between two and three thousand distinct domains, because groups share a domain across trading entities and because a surprising number of small subcontractors use a free consumer mail provider that you should exclude from the check entirely and handle with a different policy.
Send that list to the batch endpoint one hundred domains at a time. At the published ten requests per second limit, three thousand domains is thirty calls and finishes in a few seconds; in practice you will want to pace it more gently and handle the 429 response as a signal to back off rather than as an error to alert on. The response gives you a results array, the number checked, the number of phishing domains found and the credits used, which makes reconciliation against your credit balance straightforward. Write the verdict back onto the vendor record with the date, so the next run is a comparison rather than a fresh discovery.
Then the approval workflow. Every finance system has a change-of-bank-details path, and in most firms it already has a control on it: a call back to a number held on the original contract, not the number on the letter. That control is correct and it fails the same way every time — under time pressure, with an unfamiliar counterparty, when the person who knows the supplier is on site and unreachable. Adding a domain check to the same step gives you a control that cannot be talked out of running. It checks the sender domain of the request, the domain in the reply-to header if it differs, and the domain of any portal the request points at.
Make the outcomes explicit in the workflow rather than advisory. A positive verdict should stop the change and route it to a named person, with the API response stored on the case. A negative verdict should not release the call-back requirement — this is the failure mode to design against, because a green tick has a way of becoming a substitute for a phone call. The wording that seems to survive contact with a busy accounts payable team is simply: the domain check did not find a known phishing domain; complete the call-back before approving.
The same lookup behaves very differently depending on where in the flow it sits. This is the comparison worth having with your finance and IT leads before writing any code.
| Placement | What it catches | Volume & cost profile | Blocks or warns |
|---|---|---|---|
| Mail gateway, inbound links | Plan-room, prequal, waiver and document-control credential pages; tracking links in fake delivery notices | Highest. Tens of thousands of lookups a month before caching, a fraction of that after | Block and quarantine |
| Supplier onboarding form | A supplier record created around infrastructure that is already known bad | Very low. Two or three lookups per new supplier | Block record creation |
| Bank-detail change approval | Redirection requests routed through a lookalike domain that has been used elsewhere | Negligible. A few dozen lookups a month in most firms | Block the approval |
| Scheduled vendor master sweep | Records that went bad after onboarding; domains re-registered by somebody else | Predictable. One credit per distinct domain, four times a year | Raises tickets, does not block |
| Site-office firewall or DNS sinkhole | Anything an unmanaged phone on jobsite Wi-Fi tries to reach | Feed subscription rather than per-lookup credits | Blocks resolution outright |
| SIEM enrichment on existing alerts | Context for domains already flagged by another control | Low, and bounded by your alert volume | Enriches, does not block |
Read the table as a sequencing plan rather than a menu. The three positions that block — onboarding, bank-detail approval and the site firewall — are cheap and fast to deliver, and between them they cover the two moments where money actually moves and the population of devices your endpoint tooling cannot reach. The gateway integration is the one that needs real engineering: link extraction, caching, a decision on what to do with shortened URLs, and a plan for the mail that arrives faster than your rate limit allows. Build it second, once the cheap blocks are in.
The two positions that only enrich are still worth having, but be honest about what they are. A quarterly sweep is a detection control with a ninety-day worst case, which is fine for the risk it addresses and useless for the one it does not. Feeding verdicts into a SIEM gives your analysts a fast answer to "have we seen this domain elsewhere", which shortens triage but does not prevent anything on its own.
One more placement is worth mentioning for engineering practices specifically. Architects, structural and civil consultants and building services engineers are frequently the party that holds the client relationship and issues the payment certificates, which makes them the highest-value impersonation target on the whole project even though they handle the least cash. If you run a practice, the check belongs on your outbound reputation work as much as your inbound mail — the same discipline discussed on our brand protection page, where the question is which domains are impersonating you rather than which are being sent to you.
Worked against the published monthly plans, for a mid-sized main contractor: roughly seven hundred staff, four live projects, and a payables master of about four thousand two hundred supplier records.
Start with the bounded jobs. Four thousand two hundred vendor records deduplicate to roughly three thousand distinct domains once you collapse group entities and exclude consumer mail providers. The baseline sweep is therefore three thousand credits, delivered in thirty batch calls of one hundred. Repeat it quarterly and the annual figure is twelve thousand credits. Supplier onboarding at, say, six hundred new or amended records a year with three domains each adds another one thousand eight hundred. Bank-detail change approvals in a firm this size run to perhaps forty a month, with two or three domains checked per request, so call it fifteen hundred a year. Those three controls together come to roughly fifteen thousand three hundred credits annually.
At the Growth package — ninety-nine dollars for twenty-five thousand credits, which works out at four tenths of a cent per lookup — that entire programme costs under a hundred dollars a year and leaves headroom. lookups reset monthly, so a single Growth purchase covers the finance-side controls for a year with room for the ad-hoc checks a commercial team will inevitably want. It is worth pausing on that number, because it is the whole point: the controls that sit directly in front of invoice redirection are the cheapest ones on the page.
Gateway link screening is where the volume lives. Seven hundred mailboxes receiving external project mail generate a large number of URLs, but the distinct-domain count after deduplication is far smaller than people expect, because project mail is repetitive by nature. A reasonable planning figure is nine to twelve thousand distinct domain lookups a month once you hold a twenty-four-hour local cache — the cache is the single biggest lever on cost, and it is also correct behaviour, since the database itself only rebuilds daily. Take eleven thousand a month and the annual figure is about a hundred and thirty-two thousand lookups.
Add that to the finance-side controls and the whole programme lands near a hundred and forty-seven thousand credits a year. The Business package — four hundred and ninety-nine dollars for two hundred and fifty thousand credits at two tenths of a cent each — covers it with substantial margin and, at twelve-month validity, effectively prices the entire control set for a mid-sized contractor at under five hundred dollars annually. A larger group running twenty projects and three thousand mailboxes would look at Enterprise at nine hundred and ninety-nine dollars for seven hundred and fifty thousand credits, or Enterprise Plus at one thousand nine hundred and ninety-seven for two million. Full package pricing is published, and there is a fourteen-day refund window if you have used under ten percent of a package.
The Daily Threat Feed is a different commercial shape and worth evaluating separately. At four hundred and ninety-nine dollars a month, or three thousand nine hundred and ninety-nine a year with the historical archive, priority support, custom format options, a dedicated account manager and a hundred thousand API credits included, it makes sense when you want the whole list resident locally rather than queried remotely: site-office firewalls, DNS sinkholes such as Pi-hole, BIND or Unbound, offline analysis, or a SIEM that wants the full set as a watchlist. For a contractor with a dozen site offices, the feed replaces a per-lookup relationship with a distribution problem, which is usually the easier one to solve on a mobile backhaul.
A last note on modelling. Do not budget from your total inbound mail volume; budget from distinct domains per day after caching, and measure it for a week before you buy. Teams consistently overestimate by a factor of three or four, buy a larger package than they need, and then feel obliged to justify it. Start with Starter at fifty-nine dollars for ten thousand credits, instrument the real number, and size the next purchase from evidence. The free API key is enough to run that measurement.
The three parts of the supply chain that no security programme owns, and what can realistically be done about each.
The average subcontractor on a commercial project is a small business. It may have eight employees, a bookkeeper who works two days a week, mail hosted on the cheapest tier available and no multi-factor authentication anywhere. It is not negligent; it is a firm whose margin does not fund a security function. It is also, from an attacker's point of view, a direct route into a main contractor's payment process, because once that mailbox is read every message sent from it is genuinely authentic. No domain check anywhere in the chain will help, because the domain is real.
What does help is admitting this in the contract and in the process. Some main contractors now require multi-factor authentication on the subcontractor's email as a condition of the subcontract, in the same clause set that already mandates insurance levels and health and safety competence. Others go further and refuse to accept bank details by email at all, taking them only through an authenticated supplier portal or in person at the pre-start meeting. Both approaches shift the problem from detection to prevention, which is the right direction of travel when the counterparty cannot be secured. Where email remains the channel, the mechanical checks described above are what is left, and they are worth having precisely because the human checks are so easily bypassed.
Joint ventures and design consortia create a different problem: legitimate domain sprawl. A JV between two contractors will correspond from both parent domains and often from a project-specific domain registered for the duration of the works. A design consortium adds the architect, the structural engineer, the services engineer and the cost consultant, each on their own domain, plus a shared document-control platform on a fifth. Every participant is being trained, message by message, that unfamiliar domains are normal on this job. The mitigation is unglamorous — publish an authoritative list of the domains in use on the project at kick-off, circulate it to every party, keep it in the project execution plan, and screen every domain on it before you publish it. A list that has been checked is worth something; a list that has not merely legitimises whatever was on it.
Then the site itself. A jobsite is a temporary network built around a mobile router, a welfare cabin and whatever the connectivity provider could deliver to a field with no fixed line. Guest Wi-Fi on that network carries the personal phones of the site manager, the foremen, the gangers and every subcontractor operative on site, and none of those devices are enrolled in anything. This is where the daily feed earns its keep: a small resolver in the cabin, loading a fresh list each morning, gives you a blocking control over a device population you will never manage. It is the same pattern used by operators of temporary and guest networks generally, and it is one of the few controls that scales down to a cabin.
Finally, the professional services around the project deserve a mention, because they are targeted through the same seam. Solicitors handling the building contract, insurers handling the professional indemnity cover and the client's own finance team all exchange payment instructions with the same parties, and they are subject to the same impersonation. If you are on that side of the table, the equivalents of this page for legal services, insurance and banking and finance describe the same controls in the language of those workflows.
The questions that come up most often when a commercial director and an IT manager sit down to scope this together.
No, and any vendor who says otherwise is selling you something. This is a known-bad domain lookup. It catches the redirection attempts routed through infrastructure that is already confirmed as phishing, and it catches the credential pages that lead to mailbox compromise in the first place, which is a genuinely large share of the sequence. It cannot catch a message sent from your subcontractor's real, compromised mailbox, because there is no bad domain to find.
Use it as the mechanical half of a two-part control. The other half is a call-back on a number held on file from the contract, and a policy that bank details are never changed on the strength of an email alone.
Deduplicated, four thousand records is usually two and a half to three thousand distinct domains. The batch endpoint takes one hundred domains per request, so that is around thirty calls. The rate limit is ten requests per second per API key, so the theoretical floor is a few seconds; in practice, pacing the job at two or three requests per second and handling a 429 with a backoff is more considerate and still finishes inside a minute.
The slow part is not the API. It is exporting a clean domain column from a finance system that has been storing email addresses in a free-text field since 2009.
A single check returns the domain you asked about, an is_phishing boolean, a category of phishing/malware, a DNS status of resolves, the date the entry was last checked, a confidence of 0.98 and the current database size. A miss returns the same shape with the boolean false, null category and status, and confidence 0.0. The batch response wraps a results array with counts of how many domains were checked, how many were phishing and how many credits the call consumed.
Store the whole response, not just the boolean. The last-checked date and database size are what make the record defensible six months later.
Not as a live API call, no — a lookup needs a working path to the internet, and a cabin on a mobile router in a cutting is not a place to put a synchronous dependency. That is the case for the feed rather than the API. Download the full database as CSV once a day, load it into the site firewall or a small local resolver, and the enforcement happens entirely on the local network with no per-request dependency at all.
The feed also ships a changelog of additions and removals, so the daily update over a constrained link can be a delta rather than the whole file.
The verdict is per domain, not per page, and the check endpoint strips schemes and path segments for you — passing a full URL as the domain parameter works and resolves to the host. What you should decide deliberately is how you treat subdomains of a domain you hold in your own vendor master, and what you do with link shorteners and tracking wrappers, which hide the real destination behind a host that will never be in any blocklist.
The usual answer for shorteners on a project mail gateway is to resolve them first and check the destination, or to treat unresolvable shortened links as untrusted by policy.
Frame it against a single interim payment. The finance-side controls — onboarding checks, the bank-detail gate and a quarterly vendor sweep — cost under a hundred dollars a year at the published credit rates for a contractor with a few thousand suppliers. That is a rounding error against one certified payment on one package on one project, and the control sits directly in front of the event where that payment could be redirected.
The gateway integration costs more to run and much more to build, so scope it separately and after. Directors approve the cheap control quickly; the expensive one benefits from the measurement data you will have by then.
The checks described here are invisible to the subcontractor. A domain lookup at onboarding happens while a record is being created; a lookup in the bank-change workflow happens inside an approval step that already exists; a batch sweep happens overnight against data you already hold. Nobody outside your finance team ever sees them.
The one thing that does add friction is the policy that bank details are never changed on the strength of an email. That is worth the friction, and it is far easier to hold to when a mechanical check backs it up rather than being the only thing in the way.
Register for a free key, screen your vendor master in an afternoon, and see whether anything in your payables data is already resolving to live phishing infrastructure. Then decide how far to take it.
