Head office has a security team. Store 214 has a manager, a broadband line, a back-office PC that also prints labels, and eleven seasonal hires who started on Tuesday. This page is about deploying a verified list of live phishing domains across that estate — what it does for cardholder-data segmentation, what it honestly does not, and how it rolls out to sites with no local IT at all.
Every entry carries an active A record at build time, verified through rotating proxy infrastructure. Domains that stop resolving fall out instead of accumulating, so the file a store gateway loads stays a working list rather than an archive.
Payment traffic is usually the best-defended thing in the building. What sits beside it on the same broadband line rarely is.
Walk into a mid-sized store and count the things with an IP address: the registers, which by now almost certainly push card data through a point-to-point encrypted path to a terminal the merchant never sees inside; a store controller holding the price file and the day's transaction log; the back-office PC in the stockroom; a label printer, a time clock, a couple of handheld scanners, digital signage, an alarm panel with cellular backup, a camera recorder, and an access point broadcasting both a staff network and a customer one.
Most of the money and attention in retail security goes to the registers and the terminal estate, and that is the correct priority. Modern estates with point-to-point encryption and tokenisation genuinely have reduced the value of scraping a register — which is precisely why the interesting attacks migrated somewhere else.
It is simultaneously a corporate endpoint, a general-purpose browser, an occasionally-shared workstation, and the only computer in the building where somebody sits down and reads. In many chains it is logged in under a shared store account because three managers work rotating shifts, it may run a pinned operating system version because the label-printing driver only works there, and nobody is watching it in real time.
A shopper who loads a phishing page over your guest network while standing in your store has a bad experience in your building, and a price-check or order-ahead terminal left on a general browser is a small public internet café that you own and do not supervise. Neither is a cardholder-data risk, which is exactly why they never reach a compliance-driven work plan.
Every one of those devices resolves names through something, and in most store designs that something is a small number of gateways or a corporate resolver reached over the WAN. Put a verified list of live phishing hostnames in that resolution path and you have covered the back-office PC, the kiosk, the guest network, the signage player and the manager's phone on staff Wi-Fi in a single change.
None of these are generic. Each one is built around a task a store manager or area manager genuinely performs, and each is scored for how often it succeeds.
A message that appears to come from a regional director asks the manager to activate a batch of gift cards for a corporate client and send the numbers back, "because I'm in meetings all day". A companion pattern is a fake balance-check portal that harvests card and PIN pairs from customers who were handed a genuine card.
A page imitating the acquirer's or processor's merchant portal, reached from an urgent "chargeback response required within 48 hours" email. The manager signs in with the credentials that also control settlement details, and refund fraud follows in the same week rather than in the same hour.
"Your terminal firmware update is mandatory before the weekend — sign in to schedule it." The lure works because terminal estates genuinely do get pushed updates, managers genuinely are told to co-operate with the vendor, and almost nobody in a store knows what the vendor's real portal address is.
Scheduling and payslip portals are the systems every hourly worker logs into from a personal phone, often over the store's own Wi-Fi. A cloned login page harvests credentials that frequently unlock corporate single sign-on too, because in many chains the workforce portal is federated with everything else.
Aimed at the back office and at accounts payable behind it. A near-identical supplier domain sends a delivery discrepancy, a credit note or a request to confirm updated remittance details. Retail's supplier count makes verifying each one by hand impractical, which is precisely what the pattern relies on.
Merchants are told constantly that they must complete a self-assessment questionnaire or an approved scan. A page imitating a compliance portal, arriving in the right month with the right vocabulary, gets merchant identifiers, contact details and sometimes banking information from a store that assumed head office had signed them up for something.
Worth reading before anyone puts this in a compliance document, because the honest version is narrower and more useful than the marketing version.
Start with the thing that most often goes unsaid: a blocklist of phishing hostnames is not a segmentation control, it is not anti-malware, it is not a firewall ruleset, and installing one does not move a merchant between self-assessment questionnaire types — so anyone telling a store operator that a DNS filter satisfies a PCI DSS requirement outright is doing them harm, because the assessor will ask a more specific question than that.
If your cardholder data environment is properly separated from the rest of the store network — separate VLANs, restrictive rules between them, and segmentation validated by testing — nothing about adding a domain blocklist changes that boundary or the evidence you produce for it. The boundary is the control; this is not a substitute for one.
Cardholder data environments are scoped narrowly on paper and connected broadly in reality: the back-office machine that reaches a corporate application also reaches the store server, the administrator who supports the terminal estate also reads email, and the workstation used for the annual segmentation review is the same one used for supplier correspondence. Every one of the six lures above ends in a credential, and credentials are how in-scope systems get reached without touching the network boundary at all.
It sits in the malware-protection and awareness areas of the standard, and in the general expectation that a merchant applies controls against known threats to systems commonly affected by them — and usefully, it produces a log of which sites attempted to reach which blocked hostname and when, which is a far more persuasive artefact in an assessment conversation than a policy document, because it demonstrates the control operating rather than merely written down.
Retail estates are full of devices nobody can install agents on — payment terminals, signage players, time clocks, scanners, alarm panels, the recorder in the ceiling — several of them managed by third parties under contracts that forbid you from touching them. A resolver-level control is the only kind that reaches those devices at all, so if one is ever compromised and tries to resolve a listed hostname, the resolution fails without anything having been installed on it.
Modestly and precisely: outbound name resolution across store and corporate networks is filtered against a third-party database of DNS-verified active phishing domains, rebuilt every twenty-four hours, with block events logged centrally. That sentence is true, checkable, and does not claim a requirement is met by it — and overclaiming is how a helpful control turns into a finding.
Bandwidth, failure behaviour, latency and cost all point the same way once you multiply by the number of sites.
Consider what a per-query architecture asks of a store: every domain resolved by every device in the building generates an outbound request to a third party, waits for an answer, and only then proceeds — barely noticeable in a distribution centre or a flagship, but in a rural site on a contended broadband line that also carries stock replenishment, card authorisation, CCTV upload and a couple of tablets, it is another stream competing for the same pipe at the busiest hour of the day, purely to ask a question you could have answered locally.
If the lookup service is unreachable, a per-query design has two bad choices: fail open, so the control silently stops working exactly when the network is already degraded, or fail closed, so a connectivity blip takes the whole store's browsing down and a manager phones the help desk. Retail WAN links fail regularly and unremarkably, and a control whose behaviour under link failure is undefined gets disabled after the second incident.
The /feed endpoint returns the complete list as CSV with domain,category,dns_status columns, or as JSON, with unlimited downloads on a subscription. Load it into whatever already resolves names for your stores — a response policy zone on your own recursive servers, a sinkhole appliance, the blocklist facility in your existing filtering platform — and matching happens locally at memory speed with no per-query egress at all.
Because each build ships a list of domains added and removed, a store gateway or a central distribution job can apply a small diff rather than pulling and re-parsing the entire database. For an estate pushing configuration to hundreds of sites over modest links, the difference between a full file and a delta is the difference between an update window and an incident — and you can pull once centrally and distribute internally, so no store ever reaches the internet for it.
Single /check calls and /batch requests of up to a hundred domains are the right tool for what happens at head office rather than in store: screening hostnames in inbound supplier mail, checking links submitted through customer service forms, auditing outbound links on your own website and marketing sends, and answering "is this the real vendor portal?" when a store manager forwards something.
Local matching costs microseconds and adds nothing to page load or terminal traffic. The sub-50ms API response time is excellent for head-office workloads, but a store should never be waiting on a network round trip to answer a question you already own.
Fetch centrally, distribute internally. Feed downloads are unlimited on a subscription, so cost does not scale with the number of stores, franchise partners or concessions pointing at the same resolver, and a WAN outage degrades connectivity without ever degrading the control.
Most retailers end up running both. The table is about deciding which workload belongs where rather than picking a winner.
| Decision factor | Local feed at the resolver | API calls from head office |
|---|---|---|
| Covers devices with no agent | Yes — terminals, kiosks, signage, scanners, anything that resolves names | No — only systems you write code against |
| Adds traffic to store links | One scheduled download, or a diff, or nothing if you distribute internally | One request per lookup, from wherever the code runs |
| Behaviour during a WAN outage | Unchanged — matching is local | Undefined unless you build a cache and a fallback |
| Screening inbound supplier mail | Not the right shape — the mail path is not a resolution path | Ideal, especially /batch for all links in a message |
| Auditing your own site and campaigns | No | Yes — a scheduled sweep of every outbound hostname |
| Answering a one-off "is this real?" question | Only indirectly, by grepping the file | A single /check call, one credit, sub-50ms |
| Cost shape | $499/month or $499/month/year, unlimited downloads regardless of store count | Credit packages from Growth at $99/month for 25,000 lookups down to per lookup on the Enterprise plan at volume |
| Who has to operate it | Whoever already runs your resolvers or filtering platform | Whoever maintains the mail gateway, CMS or service-desk tooling |
Multiple sites, thin or no local IT, devices you cannot put software on, links you cannot afford to load, and a need for the control to behave predictably when connectivity does not. This is the deployment that covers the back-office PC, the kiosk and the guest network in one change.
Supplier mail screening, quarterly audits of your own outbound links, customer-service link checks and ad-hoc verification requests from stores. Predictable volumes, server-side calls, and no infrastructure to run. Many retailers start here and add the feed once the estate rollout is funded.
The technical work is small. The operational work is entirely about who owns the network in each site and when you are allowed to touch it.
The first question in any multi-site rollout is not technical, it is contractual: who actually owns the connectivity at each location? In a corporate estate the answer is usually clean — one WAN provider, one design, one set of gateways — but a franchisee frequently buys their own broadband, chooses their own router, sometimes runs the till on a consumer line shared with a flat upstairs, and is independent of the brand's IT department in ways that surprise people the first time they read the agreement; a concession inside a department store may be on the host retailer's network entirely, with no ability to change resolution at all.
The strongest is a corporate resolver that all sites point at over the WAN, with the list loaded once centrally. The middle option is a small resolver or filtering appliance per site pulling a distributed copy on a schedule. The weakest but still worthwhile option, for franchisees you cannot compel, is a documented configuration published with the rest of the brand standards: here is the resolver address, here is why, here is the two-line change on the router model most of you have.
Most chains freeze change from late autumn through the January sales, plus whatever regional seasons matter, so a plan requiring every store to be touched in December will not be approved. This control fits around that neatly, because after the initial rollout there is no change to a store at all — the daily build lands at 04:30 UTC and the file updates itself wherever it is held.
A 04:30 UTC build is comfortably before opening for European estates and comfortably after close for the Americas, but a global chain should pull centrally once shortly after the build lands, validate the file, then push to regional distribution points on their own schedules. Add a single alert on file age, because a silently frozen list is the only realistic way this deployment fails without anybody noticing.
The Daily Threat Feed is $499 per month; the annual option saves $1,989 and adds historical archive access, priority support, custom format options, a dedicated account manager and 100,000 API credits, which happens to cover the head-office workloads in the table above without a second purchase. Downloads are unlimited, so a chain of forty stores and a chain of four hundred pay the same.
monthly subscriptions via PayPal and billed monthly, from the Growth package at 10,000 lookups through to Enterprise at $999/month for 750,000 lookups per lookup. , which matters for a retailer whose procurement will not put a recurring charge on a card, and SFTP or S3 delivery, STIX/TAXII and on-premise arrangements are quoted rather than listed. The full table is on the pricing page.
Corporate WAN, franchisee broadband, host-retailer concession. The answer decides which of the three deployment shapes each site gets.
Log matches without blocking, in a handful of representative stores, for two to four weeks. You get a real hit rate from your own estate rather than a vendor's number.
A local allow-list applied after every import, and a named person a store can call. Decide this before enforcement, not during the first false positive on a trading Saturday.
Enforce region by region outside the trading freeze, starting with the estate on the corporate WAN. Franchise sites follow as their configuration is confirmed.
One alert if the file is older than forty-eight hours. Route block events to your existing logging so they are available as evidence, but do not create a queue nobody triages.
Including the questions that deserve a plainly inconvenient answer.
No. Scope is determined by where cardholder data is stored, processed or transmitted and by what is connected to that environment. A domain blocklist changes none of those things, and no assessor will accept it as a scope-reduction argument. If somebody has told you otherwise, ask them to name the requirement. What it is legitimately good for is evidence that you apply controls against known threats on systems commonly affected by them, and that you have logging showing the control operating. Describe it as filtering of outbound name resolution against a third-party database of DNS-verified active phishing domains, rebuilt daily, with block events logged. That claim survives scrutiny; anything larger does not.
Not if you deploy the feed rather than per-query lookups, which is exactly why the feed exists. The whole database downloads once — CSV or JSON — and after that every match is answered locally with no outbound traffic at all. In estates where even a daily download to each site is unwelcome, pull once centrally and distribute internally, so no store ever fetches anything from the internet. The daily changelog of added and removed domains makes this cheaper still, because a site can apply a diff instead of a full file. For a large estate on modest links, that is the difference between a scheduled update and a capacity conversation.
You need an exception path before you enforce, and it needs to be operable by whoever answers the phone on a Sunday. Keep a local allow-list that your update job re-applies after every import so an override survives the next refresh, and make the block page name your company with a number to call — a store manager who hits a false positive should reach a person in a minute, not conclude the network is broken and start rebooting things. Verification via an active DNS record keeps false positives low, and the confidence model is binary — 0.98 for a confirmed match and 0.0 for no match, with nothing in between — so there is no grey band to argue about. But no list is perfect, and the quality of your correction path matters more than the error rate.
It is the reason to prefer this shape of control. Nothing gets installed anywhere. The enforcement happens in the name-resolution path those devices already use, so a terminal, a signage player, a time clock or a camera recorder is covered without being touched, without a vendor support conversation, and without breaching whatever contract says you may not modify the device. The corresponding limitation is honest: a device configured to use its own hard-coded resolver, or encrypted DNS to a public provider, bypasses the control. That is worth knowing and worth checking for on your outbound firewall rules, but it does not undermine the coverage you get on the default path, which is most of the estate.
Not on its own, and this is the clearest example of the limit. If the message contains no link and simply asks the manager to reply with card numbers, there is no hostname to check and nothing in a domain blocklist can see it. That variant is addressed by process — a rule that gift-card issuance above a threshold requires a verbal confirmation to a known number, and a standing instruction that no director will ever ask for codes by email. Where it does help is the very common companion pattern: a link to a "corporate gift-card request form" or a fake balance-check page. Those are hostnames, and they are frequently reused across many retailers before anyone reports them, which is exactly the kind of infrastructure a verified list catches. Treat it as narrowing the problem rather than removing it, and keep the process rule.
Deploy before the freeze or after it, and then leave it alone — the design deliberately requires no in-store change after the initial rollout. The daily build lands at 04:30 UTC and refreshes wherever the file is held, so the list stays current through the freeze without anybody touching a site. If you miss the pre-peak window, running in monitor mode through the season is still useful: you collect a genuine hit rate from your busiest trading period, which is the best possible input to the change request you submit in January.
It helps precisely because it does not require them to do anything. A temporary hire on their fourth shift has no way to know what your real scheduling portal address is, and expecting them to learn it in a peak week is unrealistic. A network-level block means the fake one does not load, silently, with no ticket and no decision asked of anybody. It is not a substitute for the awareness work — see our security awareness page for the programme side — but it is the layer that keeps working on the days the programme has not reached yet. For estates that also want per-device coverage on managed corporate endpoints, this pairs naturally with endpoint protection and with the resolver patterns on our DNS filtering page.
No, and it is worth separating the two so neither gets neglected. The store estate is a resolution-path problem solved with the feed. The online store is an application problem: screening hostnames in customer-submitted content, in review text, in support tickets and in any redirect your checkout accepts, using server-side /check or /batch calls. 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. Look-alike domains imitating your own storefront are a third, separate problem — build a candidate list of neighbouring hostnames and re-run it on a schedule. The e-commerce and payment processors pages go further into both of those.
One central pull, distributed to every site, covering the back-office PC, the kiosk, the guest network and every device you can never install software on. Head-office workloads — supplier mail, link audits, ad-hoc verification — run on credits alongside it.
