A newsroom's exposure is not one login page. It is two decades of outbound links in a back catalogue nobody re-reads, a comment queue that never closes, a newsletter that reaches more inboxes than most mail campaigns, and a subscriber login worth cloning. This page is about checking hostnames at publish time and sweeping the archive on a schedule, using a list of DNS-verified live phishing domains.
Most security advice assumes the thing being protected is live and staffed. A publication's largest attack surface is neither.
Published pieces carrying outbound links to sources, documents and organisations that may no longer own the domain in question.
Comment threads, forums, reader tips and submitted listings, where an external party writes a URL onto your domain under your masthead.
Newsletters, RSS, syndication partners and push alerts, where one bad destination reaches every subscriber at once and cannot be edited afterwards.
Subscriber logins, paywall flows and the newsroom's own credentials — the parts an attacker imitates rather than attacks.
These four are worth separating because they fail differently and are owned by different people. The archive belongs to nobody in particular; it is the residue of everyone who has ever filed. The community queue belongs to moderation, which is usually understaffed and measured on throughput rather than accuracy. Distribution belongs to a growth or audience team optimising open rates. The account belongs to product and to whoever runs the subscription platform, and in many organisations that is a vendor rather than a colleague. There is rarely one person who can see all four at once, which is precisely why the same weakness recurs in each of them independently.
None of these require the publication to be breached. In every case the publisher's own systems work exactly as designed.
A 2016 investigation cites a campaign group's site. The group folded, the registration lapsed, somebody bought the domain for its residual traffic, and today it serves a fake sign-in page. Your article is still the top result and still links to it.
Automated accounts post links under high-traffic pieces during the hours no moderator is on shift. By the time it is removed, the thread has been read by tens of thousands of people who trust the page it appeared on.
A daily digest aggregates links from several desks and an affiliate feed. One destination has changed hands since it was scheduled. The send completes in four minutes and there is no edit button afterwards.
Programmatic inventory and content-recommendation widgets route readers to hosts chosen by an exchange, not by your editors. The reader cannot tell the difference and neither, in the moment, can your ad ops team.
A cloned subscription page, promoted through search or social during a big story, harvests the email and password of readers who assume any page carrying the masthead is the masthead. The credential is then tried at their bank.
A message to a named reporter offers documents behind a "secure viewer" that asks them to authenticate with their work account. The target is not the newsroom's money. It is the contact list and the unpublished draft.
Read those six together and a pattern emerges that is uncomfortable for anyone whose job is trust. In five of the six, the reader's decision to click is entirely rational — they clicked because a publication they read decided the destination was worth pointing at, or because the page carried a masthead they recognise, or because the newsletter arrives every morning and always has. The credibility being spent is yours, and it accumulated slowly. That is what makes the failure asymmetric: the attacker borrows a reputation built over twenty years for the cost of one domain registration.
Publishers measure the archive by traffic and by prestige. Nobody measures it by the number of live outbound hostnames it currently points at.
Every serious publication has a long tail that keeps earning. Explainers, obituaries, court reports, recipe pages, historic match reports, the definitive piece on a subject nobody else covered properly — these keep drawing search traffic for a decade or more, and they are frequently the pages a reader lands on with no idea when they were written. Inside those pages sit outbound links, and outbound links point at domains held by other people, who are under no obligation to keep holding them.
A company is acquired, a campaign ends, an academic moves institution, a small business closes, an agency reorganises and retires a microsite. Expired domains carrying inbound links from reputable publications are commercially valuable precisely because of those links, and there is an established market for acquiring them. Most re-registrations end in something merely tacky; a meaningful minority end in something hostile, because a domain a national title links to is a domain that readers and search engines already trust.
An article that was accurate and responsible on the day it was filed becomes, without anybody touching it, a referral path to a credential-harvesting page. The CMS records the link exactly as it was entered. Analytics reports a healthy page. The only signal is a reader complaint, and readers rarely complain about the publication that sent them — they blame the destination, or themselves.
Pull every outbound hostname out of the CMS and collapse the duplicates; a decade of publishing usually reduces to a few tens of thousands of distinct hosts, a small fraction of the link count. Push that set through the batch endpoint, a hundred at a time, one credit apiece, and what returns is a list of articles currently linking to verified live phishing infrastructure — almost always short, which is exactly why the exercise is worth running.
A monthly or quarterly sweep costs a trivial number of credits and catches the domains that changed hands since the last run. Publications that already operate a link-rot job — checking for dead links, archiving to a web archive, flagging broken references — usually find this is one extra call inside a pipeline they run at night anyway. The brand protection page covers the complementary problem of hostnames impersonating you rather than being linked by you.
The uncomfortable arithmetic: the more durable your journalism, the longer your outbound links keep working on somebody else's behalf. An archive is not a museum — it is a live referral network you stopped maintaining the day each piece was filed.
checked, phishing_found and credits_used so the run logs itself.The verification standard is the whole difference between a list you can act on automatically and a list that generates work.
Newsrooms have institutional reasons to be sceptical of automated flags, and they are the right reasons: a tool that returns a probability score invites an argument every time it fires, and an argument at eleven at night on a deadline is an argument the tool loses. There is no score to interpret here. The verdict arrives as a true or false on is_phishing, with phishing/malware in category, resolves in dns_status, and a plain date in last_checked — which happens to be exactly the value you want when writing a correction note.
Because inclusion requires an active A record, verified through rotating proxy infrastructure, a domain that stops resolving drops out of the next daily build instead of sitting in the file forever. A piece flagged three months ago and fixed does not keep re-flagging, and the file your systems load stays a picture of what is currently live. For a publisher running a nightly sweep, that is the difference between a job that finishes and a job that grows.
A daily record of domains added and removed ships with the feed, which lets you stop re-checking the entire archive every night. Instead you check what changed: any host newly added to the list, joined against your own outbound-link index. That is a small operation, it runs in seconds, and it means a domain that turned hostile on Tuesday surfaces on Wednesday morning rather than at the next quarterly run.
One check when a link enters the system, one job that revisits what is already out there, and a correction path agreed in advance.
Before checking anything, build the inventory: every outbound hostname in the CMS, with the article IDs that reference it. Most publishers discover the count of unique hosts is an order of magnitude smaller than the count of links, and that this index is useful for half a dozen other jobs too.
A pre-publish hook in the CMS extracts hostnames from the body and calls the check endpoint server-side. A confirmed match blocks publication and shows the editor which link and why; anything else passes silently. At sub-50ms the desk never feels it, and the editor is never asked to make a judgement call.
Comments, forum posts, reader tips, event listings, obituary notices, classified entries — anywhere an external party writes a URL that will render on your domain. The check runs before the content is stored, so nothing hostile is ever live even briefly, and moderators see a queue that has already been filtered.
Newsletter and syndication payloads get a final batched check immediately before dispatch, because a link approved on Monday can turn on Thursday. Overnight, the archive sweep joins the daily changelog against your link index and files anything newly flagged for the morning.
Decide in advance what happens when a live piece points at a hostile host: link removed or disabled, a dated footnote explaining that the destination changed hands, escalation to the standards desk above a threshold, and a record kept. This is an editorial policy question, not a technical one, and it is far easier to settle before the first hit than during it.
Six places the call belongs, with the specific behaviour each one needs. None is more than an afternoon of work for the team that owns the system.
Whether the platform is WordPress, Arc, a Drupal build or something written in-house, there is a hook that fires between "editor presses publish" and "content becomes live". Extract hostnames from the rendered body, deduplicate within the piece, and batch them in one call rather than looping — a long feature with forty references is still a single request.
The interface matters as much as the check. Name the specific link, quote the last_checked date, and offer a one-click "remove link and continue". An editor told only that "a security check failed" will republish straight through the warning — and on a deadline they will be right to, because the warning gave them nothing they could act on.
User-generated content is where volume defeats people. A check at submission, before storage, removes the entire category of "hostile link was live for eleven minutes" — and because it happens server-side, no automated poster can see or evade it from the client. The social media page covers the same shape at platform scale.
A host submitted last week may have been clean then and be verified as phishing now, so a nightly job over recent submissions — joined against the day's changelog — catches the delayed activations that a submission-time check by definition cannot. Keep the window bounded to a few weeks and the job stays small enough to run without anybody noticing it.
Distribution is the surface with no undo: once a digest is in half a million inboxes it cannot be edited, and a correction reaches a fraction of the people the original did. That asymmetry justifies a hard gate — extract every hostname from the assembled payload, batch it, and hold the send on a confirmed match rather than warning someone who may not be awake. Content taken from partners deserves the same treatment, since their editorial checks are not yours to inspect.
A cloned paywall or "your subscription is expiring" page harvests an email and password that will then be tried at a bank, a retailer and a mail provider — the damage lands on the reader and the blame lands on the masthead. Two practical uses: feed known hostile hosts into the resolver serving your own staff, and verify the hostname before warning subscribers about a reported message, so the notice is factual rather than precautionary. See identity protection for the credential-reuse chain.
Journalists are targeted for what they know rather than what they own, which changes both the attacker's economics and the honest limits of a blocklist.
A reporter's mailbox is not valuable in the way a finance director's is. Nobody is trying to redirect a payment. What is valuable is the contact list, the thread with a source who is not ready to be named, the draft that has not cleared legal, and the calendar showing who was met and when. That changes the profile of the attack: it is patient, it is aimed at named individuals whose contact details are published deliberately, and it uses pretexts drawn from the job itself — a document drop, an interview request, an embargoed release, a whistleblower who needs the reporter to authenticate to a secure portal before the files can be released.
Newsrooms have the unhappy property that their staff are professionally obliged to do the exact things security training tells everyone else not to. A reporter who ignores unsolicited attachments from strangers is a reporter not doing investigations. The advice cannot be "be more careful" — it has to be structural, which means putting controls somewhere other than one person's judgement at the moment they are being manipulated.
Blocking verified hostile hostnames at the resolver used by the building, and checking hostnames extracted from inbound mail server-side, removes the large volume of reused kits and rotating infrastructure that hit hundreds of other organisations the same week. That is most of what arrives, and clearing it means the security-minded people in the building spend attention on the small remainder instead of triaging noise.
This is a known-bad lookup. Coming back clean tells you the hostname has not been observed and verified; it does not tell you the page at the other end is harmless. Infrastructure stood up at breakfast and fired once at a single named reporter by mid-afternoon will not be in there, and that is exactly the profile of the targeted operation a media organisation fears most.
Hardware security keys for staff accounts defeat credential phishing regardless of whether the domain is known. Separate, well-understood channels for source contact reduce what a compromised mailbox exposes. A blocklist handles volume, not sophistication. Used together they complement each other; used as substitutes they leave a gap. The email security and security awareness pages cover the adjacent layers.
Including the question nobody enjoys answering, which is what happens when the check is wrong about a site a reporter needs.
It should be imperceptible, and if it is not, the integration is wrong rather than the tool: responses come back in under 50 milliseconds and a whole article's worth of hostnames goes in one batched call rather than one call per link, so the added time is a fraction of what the CMS already spends rendering a preview. Two design rules make this safe on a live desk — deduplicate hostnames before calling, and fail open on a timeout so the piece publishes and the overnight sweep catches it. A newsroom that gets blocked once by a security tool will route around that tool permanently, and no amount of policy will stop them.
This is the awkward one and it deserves a real answer rather than reassurance, because journalists write about phishing operations and an article about a scam may quite properly need to name the hostname involved. Two things resolve it: the check should flag at publish rather than block outright, with an override that records who overrode it and why — that is an editorial decision and it belongs to a person — and house style for these cases should already be to render hostile hostnames as unlinked plain text, often with the scheme broken, which is good practice regardless of any tool. Keep a documented allow-list applied after each import so an intentional reference does not re-flag every night.
Yes, and it is cheaper than it sounds because the unit is the hostname rather than the link: twenty years of publishing might contain millions of outbound links but typically only tens of thousands of distinct hosts, and at a hundred domains per batch request with one lookup each, a full first pass usually costs a small fraction of a starter package. After that you never repeat it in full — join the daily changelog of newly added domains against your link index every night and you are checking a few hundred entries rather than the whole archive. The expensive part is building the outbound-link index, and most publishers find they want that index for other reasons anyway.
It answers a narrower question than brand monitoring, and it is worth being precise about the difference: this will tell you whether a specific hostname is verified live phishing infrastructure right now, but it does not go looking for typo variants of your masthead, watch certificate transparency logs or discover impersonation you have not thought of. What it does very well is verify candidates — feed it the obvious permutations of your own domains plus anything readers have reported, and you get a confirmed answer before deciding whether to warn subscribers or start a takedown. Publications running an active monitoring programme usually pair the two; see the brand protection page.
It depends on the platform's extensibility and it is worth checking before assuming, because many hosted community products expose a pre-moderation webhook or an API you can poll, either of which is enough to run the check server-side and act on the result. Where the platform genuinely offers no hook you have two fallbacks: run the check on the rendered page's outbound hosts as part of your nightly job, which catches things late rather than never, and block hostile hosts at the resolver used by staff so that at minimum nobody in the building follows one. Neither is as good as a submission-time gate, and both are considerably better than nothing.
Two shapes, and most publishers use both: plans are monthly subscription via PayPal and billed monthly — Growth at $99/month for 25,000 lookups, $99/month for 25,000 lookups, $249/month for 100,000 lookups, $499/month for 250,000 lookups, and upward from there — with a mid-sized title running publish-time checks and a nightly incremental sweep typically living comfortably in the middle of that table. At $499 a month, or $499/month for the year, the Daily Threat Feed buys unlimited downloads and becomes the right call once you want the whole list held locally, whether for a resolver serving the building, an in-house matching service, or high-volume community checking where per-lookup billing stops making sense. The annual feed includes 100,000 API credits, which covers the archive work without a second purchase.
Partially, and the honest constraint is architectural rather than technical: programmatic creatives are served client-side by an exchange and often use redirect chains that resolve only at click time, so a server-side check cannot see the final destination in advance. What you can do is check the landing domains your ad ops team accepts for direct-sold and sponsored content, check the destinations declared in any allow-list you hold with a network, and check hostnames reported by readers who complain. That is a partial answer and should be presented as one internally — the ad tech page covers where the boundary sits and who is able to act beyond it.
Rebuilds run on a 24-hour cycle and the finished build appears at 04:30 UTC; nothing gets in without an active A record confirmed through rotating proxy infrastructure. The moment a domain goes dark — seized, suspended or just abandoned — the next build leaves it out, which is deliberate and matters for an archive sweep, because a piece you fixed last month will not keep reappearing in tomorrow's report and the file your systems load stays a working set rather than a historical record. Each response carries last_checked as a date, which is the value to quote in a correction note if you publish one.
Start with the outbound-link index you probably half-have already, run one batched pass over the distinct hostnames, and see what twenty years of publishing is currently pointing at. If the community queue and the resolver both need covering, the daily feed is the shape that scales without per-lookup billing.
