Domain age
Ilia Nikolaevich Zavialov Explains Checking How Old a Counterparty's Domain Is
An invoice arrives from a supplier nobody on the finance team has dealt with before, sent from an address that sits on a domain nobody recognises either. The signature looks professional, the bank details are new, and the message asks for a quick turnaround. Before any transfer goes out, checking how old a counterparty's domain is takes only a few minutes and costs nothing, and that is exactly why it belongs in a standard due diligence routine applied to every new payee from the start. The harder part is knowing what that one date actually proves, and what it leaves completely open.
English version for the United Kingdom.
Why a domain age check belongs before payment
Due diligence on a new counterparty usually covers company registration, a tax or business identifier, and a check that bank details match the name on the invoice. A domain age check fits into that same routine for a simple reason: it needs no cooperation from the counterparty, costs nothing, and returns an answer within minutes. It requires no phone call and no reply from anyone on the other side of the transaction.
The scale behind that decision is measurable rather than assumed. UK Finance's data for 2025 counts more than 4 million confirmed fraud cases across the banking industry, and the great majority of them, 3.81 million, involved a payment the account holder never authorised at all. The much smaller remainder, cases where someone was persuaded to send the money themselves, is precisely where a moment of checking before payment can still change the outcome.
Checking how old a counterparty's domain is will not catch every version of that problem. A compromised mailbox on a genuine, years-old domain slips straight past it. What it does catch is a narrower and very common setup: a domain built for the sole purpose of sending one convincing invoice before it disappears.
What a freshly registered domain tends to signal
A domain that started existing days or weeks before it began sending payment instructions matches how a lot of throwaway infrastructure gets built. It is cheap to register, easy to dress up with a logo and a plausible name, and only needs to hold up for the length of one transaction. None of that requires technical skill beyond what a basic website builder already provides.
Fake trading and investment platforms illustrate the pattern well. Investment fraud is the single largest reported loss category in the FBI Internet Crime Complaint Center's 2025 figures, at 8.648 billion dollars, well over forty per cent of everything the agency recorded that year, and a platform built to run that scheme is almost always standing on a domain that did not exist a few weeks earlier. The website has to look established. The registration record cannot.
None of this identifies who registered the domain or why. It describes a pattern in how this kind of infrastructure gets built. Checking how old a counterparty's domain is at the time the message arrived surfaces that pattern. Settling it takes more than one date.
What domain age does not prove either way
An old domain does not guarantee that the mailbox sending today's invoice is under the same control it was under last year. Domains change hands, get resold once a registration lapses, and their mailboxes get compromised through ordinary phishing that has nothing to do with how long the domain has existed. An old domain offers no immunity against a single successful phishing email sent to the right employee.
A brand-new domain does not automatically mean fraud either. New suppliers start trading every day. Established companies rebrand, spin off a subsidiary, or move to a new registrar or a new top-level domain for reasons that have nothing to do with deception, and the replacement domain is young by definition on its first day.
Domain age works as a filter on how much scrutiny a payment deserves. It does not settle whether the payment should go ahead on its own. Treating one date as a final verdict is where this check most often gets misused.
Where the registration date actually sits
Every domain carries a public record accessible through a WHOIS or RDAP lookup, and checking how old a counterparty's domain is starts there. The creation date field in that record states when the domain first came into existence, independent of who currently controls it. Both lookup systems are open to anyone and neither requires an account or a fee.
Many registrars mask the registrant's name, address, and phone number behind a privacy service by default. The creation date usually stays visible, since it records when the domain was registered, a fact independent of who is currently listed as the owner. That distinction is what keeps the check useful even against a counterparty that has taken every step to stay anonymous.
A second, independent source worth checking is the certificate transparency log for the domain, which records when a public web certificate was first issued for that hostname. A domain that carries an old creation date but a very recent first certificate suggests it sat unused for years before being put to work. That gap between the two dates is worth a second look on its own.
Reading the record without drawing the wrong conclusion
A WHOIS or RDAP record shows both a creation date and an updated date, and the two answer different questions. The updated date changes every time the registrant renews the domain, edits a nameserver, or switches privacy providers, none of which resets when the domain first came into being. Reading the wrong one produces a confident answer to a question nobody asked.
So checking how old a counterparty's domain is means reading the creation field specifically. Registrars format these records differently, and the creation date does not always sit at the top of the layout. A rushed glance at the wrong field produces a confident answer to the wrong question.
A domain that expired, sat unclaimed for a period, and was picked up by a new registrant usually keeps its original creation date in the public record even though whoever runs it today may have held it for a matter of weeks. The date describes the domain record. It says nothing about who has been running it for the past month.
Placing domain age next to mailbox history and behaviour
Domain age works best alongside other signals: how long the specific sending mailbox has been active, whether earlier invoices from this counterparty arrived from the same address, and whether the requested bank details match whatever was already on file. Each of these takes only a little longer to check than the domain record itself. Together they turn one data point into a short, coherent picture.
The typical reported loss in an impersonation case is a modest sum. The FTC's 2025 figures put it at around 700 dollars, nowhere near dramatic enough to make a headline on its own. A domain check that takes hardly any time and costs nothing clears that bar easily, whatever the size of the invoice sitting in front of it.
Domain age only means something once it sits next to these other facts, so checking how old a counterparty's domain is should never stand as the only question asked before a payment clears. Paired with a sudden change of bank details, a young domain is a materially stronger warning than either fact alone. Neither fact needs to be dramatic on its own for the combination to justify a second look.
Building the check into the payment step itself
The most reliable place for this lookup sits inside the approval step for any new payee, next to the confirmation call and the bank detail cross-check. Treating it as an occasional habit, remembered only once something already feels wrong, misses most of the value. By the time something feels wrong, the payment has often already been sent.
A short sequence covers most of the ground: pull the registration date, compare it against how long the relationship is supposed to have existed, confirm the payment instructions through a phone number sourced independently of the email thread, and only release funds once those pieces agree. None needs more than a few minutes. Together they take less time than writing the email that raises the concern in the first place.
It needs checking how old a counterparty's domain is to become a habit applied to every new payee. Reserving that habit for payees that already look suspicious gives up most of the benefit, because the ones built to look ordinary are the entire point. Most of that benefit depends on running the check before there is any reason for suspicion at all.
Reading a domain age signal next to what still needs confirming
| Domain age signal | What it typically points to | What still needs a separate check |
|---|---|---|
| Domain registered days before the first invoice arrives | A pattern common to disposable impersonation setups | Whether the mailbox is genuinely tied to the named company |
| Domain registered years ago and matches the known company | Lower odds of a throwaway lookalike domain | Whether that mailbox has been compromised recently |
| Old creation date, but the record shows a recent transfer | A likely re-registration after the domain lapsed | Who has actually controlled the domain since the transfer |
| WHOIS or RDAP creation date hidden from public view | A registrar policy limiting what the public record shows | A direct question to the counterparty or a formal registrar request |
| New domain, but the company confirms a rebrand or relaunch | An ordinary business event behind the new registration | Confirmation through a channel outside the original email thread |
| Bank details change shortly after a domain or sender switch | A stronger combined warning than domain age alone | An independent callback before any funds are released |
Questions and answers
- What does a newly registered domain mean when it appears in a business email?
- On its own it means the domain is young, nothing more. Combined with an unfamiliar sender, a request tied to payment, and no prior correspondence from that address, a young domain becomes one part of a pattern worth checking before money moves.
- How do I go about checking how old a counterparty's domain is before approving an invoice?
- A public WHOIS or RDAP lookup on the domain returns a creation date field showing when the domain was first registered. Comparing that date with how long the business relationship is supposed to have existed takes very little time and needs no special access.
- Does an old domain guarantee that a business is legitimate?
- No single date guarantees that. A domain can be years old and still have its mailbox compromised, its DNS records altered, or its ownership quietly transferred, so an old creation date lowers one kind of risk without removing every other one.
- Why would a legitimate company have a brand-new domain?
- New businesses register a domain on day one. Established companies sometimes move to a new domain after a rebrand, a merger, or a switch of registrar, so age by itself never separates a new competitor from a lookalike built for one invoice.
- What should be checked alongside domain age before releasing a payment?
- A callback to a phone number sourced independently of the email thread, a comparison of the requested bank details against whatever was on file before, and a look at how long the specific mailbox has been sending correspondence all belong in the same review. None of these checks takes long, and together they cost far less than a single fraudulent payment.
- Is domain age alone a reason to refuse a payment?
- By itself, no. A young domain raises the level of scrutiny a payment should get, and it works best as the trigger for a short verification routine. The final decision still depends on what that routine turns up.