Property transactions concentrate an enormous, irreversible payment into a single instruction sent by email at a predictable moment. This page is about the part of that chain a brokerage or title office can actually control: the hostnames in transaction correspondence, in portal notifications, and in the mail that opens the office mailbox in the first place.
Closing-funds diversion is not a generic fraud that happens to hit property. It is a crime designed around the specific rhythm of a settlement.
Ask any settlement officer to describe the worst week of their career and you will hear a version of the same story. The transaction was ordinary and so was the correspondence, but somewhere in the four to six weeks between offer acceptance and completion a mailbox belonging to one of the five or six parties in the chain was opened by somebody who should not have had it — and that person then sat quietly and read, learning the property address, the matter reference, the names of the buyer's solicitor and the seller's agent, the expected completion date, the exact figure due, and even the house style of the office they were about to impersonate.
Three weeks of messages from an agent, a lender and a settlement officer have taught the buyer exactly what this transaction sounds like, so when something arrives in the same thread two days before completion — same signature block, same file reference — saying the receiving bank has changed, there is no basis for suspicion and no second attempt. Funds move as a same-day wire because that is what the closing schedule demanded, and they are layered through several accounts within hours.
Nobody at the brokerage can un-send a wire, and no product reliably tells a buyer that a payment instruction is forged. What the office can control is the step before: whether the credential-harvesting page that let the attacker into the thread was reachable from a staff machine at all. That is a narrow, testable question about a hostname, answerable from a list where every domain carries an active A record verified through rotating proxy infrastructure.
In a purchase that means the deposit or earnest money at the front of the process, and the balance of completion monies at the end. Both are moments where the buyer is primed to receive banking details and act quickly, where hesitation looks like a problem with the transaction rather than a reason for caution, and where money moves by a mechanism designed to be fast and final because legal completion depends on cleared funds arriving on a specific date.
The forged instruction usually arrives from a mailbox that genuinely belongs to a party in the transaction, so sender authentication passes. The attachment, if there is one, is a legitimate PDF. There is often no link in the message at all, because by that stage the attacker does not need one — everything that could have been intercepted happened weeks earlier, in a message that did contain a link.
A phishing blocklist does not detect a fraudulent wire instruction sent from a real, compromised account, and it is worth being blunt about that rather than overselling. It works on the credential-harvesting infrastructure that produced the compromise, and on the look-alike domains attackers register when they cannot get inside a real mailbox and settle for imitating one instead.
The American Land Title Association's Best Practices framework asks title and settlement firms to hold written information security programmes covering their email systems, the National Association of Realtors has spent years telling members not to send banking details by email, and both the Consumer Financial Protection Bureau and the FBI's Internet Crime Complaint Center take reports of this exact pattern. Screening hostnames is the part of that programme you can automate.
Everything below has been observed against property professionals repeatedly, listed in the order it tends to appear in a file rather than in order of loss.
What connects all six is that a property professional's working life is spent logging into other people's systems: in a single day an agent might authenticate to the multiple listing service, a portal back office, a transaction management platform, an e-signature service, a lockbox app, a lender's broker portal and two different lead sources — none of which belong to the firm, none of which share an identity provider, and several of which send genuine notification emails that look exactly like the fake ones.
A fake webmail or single sign-on page harvests one staff password. The attacker adds a quiet forwarding rule and reads the transaction pipeline for weeks before acting on any of it.
A hyphenated or transposed version of the brokerage or title company registers cleanly, passes its own authentication checks, and sends mail no buyer has reason to inspect character by character.
Fake multiple listing service, IDX and portal back-office logins take over the account that controls what a firm publishes, which is worth more as a distribution channel than as stolen data.
An agent's CRM holds every enquiry, phone number and buying stage in one place. A cloned login page for it is a cheap way to acquire a warm, pre-qualified target list.
Copied photographs and a below-market rent, hosted on a domain built for the purpose, collect holding deposits from applicants who will never be shown the property.
Fake tenancy and mortgage application portals ask for payslips, bank statements and photo identification — the exact bundle needed to open credit in somebody else's name.
Attackers either get inside a real mailbox or build something close enough to one. Different mechanics, same first step.
The initial message is rarely dramatic — a shared-document notification, a voicemail-transcription alert, a storage-quota warning, or a note that a secure message is waiting, which is the ordinary furniture of a modern office inbox — and it contains a link to a page reproducing the sign-in screen the staff member sees every morning, sometimes proxying the genuine site in real time so that a one-time code typed into it is relayed straight to the attacker and used within seconds.
The intruder creates an inbox rule that forwards or files anything containing words like completion, deposit, settlement, escrow or invoice, sometimes deleting the copy the staff member would have seen so the conversation continues without them. In firms where several people share a generic address — info@, accounts@, lettings@, completions@ — nobody notices a thread has gone missing, because nobody owned it individually in the first place.
They register something adjacent to your domain — a hyphen inserted, a letter doubled, a different top-level domain, the word "escrow" or "completions" bolted on the front — then configure it properly, warm it up, and start a parallel conversation with the buyer while copying the tone of the real one. Because the domain is genuinely theirs it authenticates correctly, so the only thing wrong with the message is the hostname, and the hostname is the thing nobody reads.
/batch — up to a hundred per request, one lookup each, with checked, phishing_found and credits_used in the response — and you get a verified answer on the ones already known, before anyone acts on the content of the message.is_phishing true, a category of phishing/malware, a dns_status of resolves, and a confidence of 0.98; no match returns 0.0, with nothing in between. That is a statement about presence on a verified list, not a risk score — so a clean result says "not on the list", which is a different sentence from "this is safe".Callback verification on a number taken from the engagement letter, not from an email signature, remains the single most effective control in a property transaction, and nothing here replaces it — nor the mail platform's own filtering, nor multi-factor authentication on every mailbox, nor the practice of never sending bank details electronically. What hostname screening adds is coverage of the specific step where a human being is asked to recognise a fake login page under time pressure, which is the step every one of these files has in common. Firms watching for imitations of their own brand usually pair it with our brand protection approach and route the mail-side work through email security.
Two properties decide whether a blocklist is useful in a transaction context: how current it is, and whether the entries in it are still standing up.
Phishing infrastructure aimed at property transactions has a short, deliberate life — a domain is registered, given a certificate, used against a handful of firms in one market, and abandoned before anybody has built a case file about it — which is exactly why an accumulating list of everything ever reported becomes useless: it grows without bound, most of it points at nothing, and the parts still resolving are buried among the parts that are not.
Every entry carries an active A record at the time of the build, checked through rotating proxy infrastructure so the answer does not come from a single, easily-poisoned vantage point. Domains that stop resolving fall out rather than accumulating, so the file you load into a resolver stays a working list instead of turning into a corpus you have to index.
The daily build lands at 04:30 UTC with a list of domains added and removed since the previous one. For a small office running a scheduled job that is the difference between a full reload every morning and a diff applied in seconds — and it is a genuinely interesting artefact to read once a week, because watching the additions makes the churn concrete.
The /stats endpoint reports the current database size and the last update time, and it requires no API key, no credits and no authentication at all — that is simply a property of the endpoint. A technically-minded person at your firm can verify the freshness claim independently in about ten seconds.
Six steps, each useful on its own, none of them requiring a project or a security hire.
Write down your own domains, then the obvious neighbours: hyphenated forms, doubled letters, the same name on other top-level domains, and the versions with "escrow", "completions", "title" or "settlements" prefixed. Run that list through /batch once. It is one credit per domain and it tells you which of those neighbours is already confirmed live phishing infrastructure rather than merely parked.
Extract hostnames from links in inbound mail and check them before delivery, or immediately after it if your platform only allows post-delivery action. This is the step that catches the credential-harvesting message weeks before it becomes a wire fraud, and it is the highest-value integration for a firm that will only ever do one.
Most settlement and conveyancing teams already have a moment where somebody reads the file before funds are requested. Add a hostname sweep to it: every link that has appeared in the thread, submitted in one batch call, logged against the matter reference. It takes seconds and it produces a record you can point at afterwards.
Valuation requests, tenancy applications, "list your property" enquiries and portal lead handoffs all accept text from strangers, and that text frequently contains URLs. Check the hostnames server-side before the enquiry reaches an agent's inbox. Your API key is the username you chose at registration, it is a server-side secret, and it must never appear in page source or client-side JavaScript — the API documentation covers the call shapes.
Agents work from cars, kitchen tables and open houses, on phones that are frequently personal. If the firm runs its own recursive resolver or a filtering service, load the daily feed there and point company devices at it. Where that is not possible, the mail-side and application-side checks in steps two to four still work, because they run on your infrastructure rather than on the handset.
Outbound links accumulate in property descriptions, area guides, developer microsites, partner listings and old newsletters, and domains lapse and get re-registered by somebody else. A quarterly sweep of every outbound hostname on your site costs a trivial number of credits and occasionally removes a live phishing link sitting under your own logo.
/batch POST costs the same hundred credits as a hundred single calls but consumes one request against the ten-per-second limit instead of a hundred, and returns a single summary your job can log in one line.Almost nothing written about transaction security assumes an organisation this shape. It should, because this is the shape most property businesses are.
The IT reality of an estate agency is that there frequently is no IT department: a franchised office may have a corporate mail tenancy and a security policy written at head office, but the person who actually administers anything is a branch manager with a full sales role and no time; an independent office may have a local support company on a few hours a month; and a lettings desk of two people may be running the business on a consumer mail plan, a shared password on the portal back office, and a group chat for anything urgent.
Anything requiring an agent to change how they work will not survive a busy Saturday, anything requiring endpoint software on a personal phone will not be installed, and anything requiring an analyst to triage alerts has nobody to triage them. What does survive is a control that lives on a server nobody has to think about and that produces a block rather than a notification.
A fraudulent listing carrying the national brand, or a fake portal login page using the corporate logo, is a head-office problem in theory and a branch problem in practice, because the branch is where the phone rings. Offices that run the neighbouring-domain inventory themselves can escalate with a verified answer rather than a suspicion, which is the difference between a ticket that moves and one that sits.
Agents forward transaction mail to personal addresses so they can read it on a phone that works, keep contact lists in a personal app because the CRM is slow on mobile, and sign documents on a tablet that also belongs to the household. The only controls that reach that are applied before a message leaves your infrastructure, or after a click leaves the handset via a resolver-level deployment.
The control that survives a busy Saturday is the one that runs without an agent's participation. Every security measure a property business adopts should be judged against that single test, because the ones that fail it are quietly abandoned in the first busy week and then appear in the policy document for years afterwards as though they were still in force.
monthly subscriptions via PayPal and billed monthly: the Growth plan is $99/month for 25,000 lookups at $0.0040 per lookup, the $99 Growth package is 25,000 , and the $249 Professional package is 100,000 at $0.0025 with priority support. A two-branch agency screening inbound mail links, web form submissions and quarterly site sweeps will not exhaust the smallest package quickly, a fourteen-day refund window applies if under ten percent has been used, and above $4,000 bank transfer replaces card payment — which matters when client account rules make card spending awkward.
The Daily Threat Feed is $499 per month, and it is the right answer for a title company running its own resolvers or a franchise network distributing one file to every branch. Downloads are unlimited so cost does not move with the number of offices, and all plans include priority support. SFTP or S3 delivery, STIX/TAXII and on-premise arrangements are quoted rather than listed; the full table is on the pricing page.
Including the objections that deserve an uncomfortable answer rather than a reassuring one.
No, and anyone who tells you otherwise is selling something — once an attacker is inside a genuine mailbox, the fraudulent message has no malicious hostname in it, passes every authentication check because it is authentic, and arrives in a thread the recipient has been reading for weeks, so nothing in a domain blocklist can see it. What this does is work on the stage before, because the compromise almost always begins with a link to a credential-harvesting page and that page is a hostname, so screening it reduces the number of mailboxes that get opened in the first place. Verifying payment instructions by voice, on a number obtained independently of the email, is the control that addresses the fraudulent instruction itself, and it should stay in place regardless of what else you deploy.
Partly, and it is worth being honest about which parts: if your mail is on a hosted platform administered by an outside support company, ask them to add hostname screening on inbound links, because that is a small piece of configuration against a documented endpoint rather than a project, and if your website is built by an agency, ask them to check hostnames in form submissions server-side, which is perhaps twenty lines of code in whatever framework the site already uses. The parts that genuinely need somebody technical are the resolver-level deployment and any scheduled sweep of your own site, and if nobody in your orbit can do those you are better off doing the two easy integrations well than buying something larger you cannot operate. The API documentation is written for a competent developer rather than a security specialist, which is usually the person a small firm actually has access to.
It gives you a verified answer about a specific hostname, which is narrower than what people usually mean by brand monitoring but more useful than it sounds: when a tenant calls to say they paid a holding deposit for one of your properties on a site you have never heard of, you can check that hostname immediately and know whether it is already confirmed phishing infrastructure, which turns a vague complaint into something you can send to a registrar, a portal or the police with a concrete claim attached. What it will not do is discover imitations you have not thought to ask about, so for that you need to be generating the candidate list yourself — the neighbouring-domain inventory in step one — and re-running it periodically, and firms wanting continuous coverage of that problem should look at the brand protection approach alongside this.
Not directly, and pretending otherwise would be dishonest, because a personal handset you do not manage cannot be made to enforce your policies and asking agents to install something on it rarely ends well. The realistic answer is to move the control off the device: screen hostnames in inbound mail before it is ever delivered, so the harvesting message does not arrive on the phone at all, and check links in inbound web enquiries on your server before an agent ever sees them. Where the firm does own the device, or where agents connect to office Wi-Fi, a resolver-level deployment of the daily feed covers the browsing path too — the combination is imperfect and covers most of the traffic that matters, which is the correct standard to hold this to.
Plan for it before you deploy and it stops being a crisis: keep a local allow-list that your update job applies after each daily import so an override survives the next refresh, and if you enforce at the resolver make the block page name your firm and give a phone number, because a client who hits a false positive should be able to reach a person immediately rather than concluding your systems are broken. Verification via an active DNS record keeps the false-positive rate low, and the binary confidence model means there is no ambiguous middle band to argue about — a domain is either on the list or it is not — but no list is perfect, and the correction path matters more than the error rate does.
You can describe it accurately, which is the only version worth putting in front of anybody, and the accurate description is that inbound links and transaction correspondence hostnames are screened against a third-party database of DNS-verified active phishing domains, rebuilt every twenty-four hours, with results logged against the matter — a real, checkable technical control that sits comfortably inside the kind of written information security programme ALTA's Best Practices framework expects of a settlement firm. What you should not claim is that it prevents wire fraud, because it does not; it reduces the likelihood of the credential compromise that usually precedes wire fraud, and overstating a control is how it becomes a liability in a claim.
It is a real gap shared by every blocklist that has ever existed, so the fair question is whether the residual coverage is worth the money rather than whether the coverage is total — a domain registered and first used within the same hour will not be there yet, and some transaction-specific infrastructure is exactly that fresh, particularly in targeted attacks against a single named firm. What the list does cover is the large volume of reused, mass-deployed harvesting infrastructure that most compromises actually come from: the generic webmail and document-portal clones pointed at hundreds of small firms in sequence. That is the bulk of the traffic, and removing it narrows the problem to the small number of genuinely bespoke attacks, which is where your callback verification and your staff's scepticism have a fighting chance — so treat it as one layer among several, alongside DNS filtering and identity protection measures, never as a guarantee.
Start with the neighbouring-domain inventory and the inbound mail check — two integrations a small brokerage or title office can actually operate. If you need network-wide enforcement across branches or your own resolvers, the daily feed is the deployment that fits.
