Most security teams can name their primary production domain without hesitation. Ask the same team how many domains the organization actually owns, and the answer is usually a guess, followed by a call to whoever handles the registrar invoice. A domain portfolio audit is the process of turning that guess into a verified list, and then deciding what to do with everything on it that nobody is actively using. For teams with dozens or hundreds of domains accumulated over a decade of marketing campaigns, acquisitions, and country launches, this is not a one-time cleanup. It is a recurring control that belongs next to certificate inventory and third-party risk review.
How a domain portfolio sprawls
Nobody sets out to own 200 domains. It happens through a series of individually reasonable decisions that never get revisited.
Marketing campaigns are the most common source. A product launch gets a short, memorable domain for a print ad or a conference booth: brandname2021.com, brandname-summit.io. The campaign ends, the landing page is torn down, and the domain sits in a registrar account with an auto-renew toggle that nobody remembers turning on.
Country-code top-level domains add a second layer. Expanding into a new market typically means registering the local ccTLD (.de.jp.com.br) before there is even a localized site to put on it, partly to keep a competitor or squatter from taking it first. Multiply that by every country the sales team has ever discussed entering, including the ones that never happened.
Defensive registrations are the third driver: common misspellings of the brand, the brand plus “login” or “support” or “billing”, and every gTLD variant a reseller can upsell at checkout (.net.org.co.biz.app.xyz). Legal and brand teams often request these independently of IT, on a personal or departmental card, which is exactly how a domain ends up outside the central inventory in the first place.
Finally, mergers and acquisitions import someone else’s sprawl wholesale. An acquired company’s registrar account, often under a different reseller and a different point of contact, gets folded in during due diligence and then left alone because migrating DNS during an integration is rarely anyone’s top priority. Regardless of the origin, each of these registrations becomes part of the attack surface the moment it resolves to anything at all, whether or not the security team remembers registering it.
Building the inventory: where the data actually lives
A domain portfolio audit fails when it relies on a single source, because no single source is complete. Cross-referencing at least three of the following is the minimum bar for a result you can trust.
- Registrar and reseller accounts. Pull the full domain list from every registrar the organization has ever used: GoDaddy, Namecheap, MarkMonitor, CSC, Google Domains successors, and any reseller a regional office signed up with independently. Export to CSV rather than relying on the dashboard view, since dashboards often paginate or hide expired entries.
- Finance and accounts payable records. Search expense reports and vendor payment history for registrar names and generic terms like “domain renewal” or “hosting.” This is how you find the domains that were never entered into the IT-managed registrar account at all.
- DNS zone files. If the organization runs authoritative DNS internally or through a managed provider, the zone list itself is a ground-truth inventory of what currently resolves, independent of who owns the registration.
- Certificate Transparency logs. Querying crt.sh or a CT log aggregator for the base brand name and known variants surfaces domains and subdomains that have ever had a public TLS certificate issued, including ones set up outside any sanctioned process.
- Passive DNS and subdomain enumeration. Tools such as
amass enumorsubfinder -d brand.comcombined with a passive DNS history service reveal domains that have pointed at company-owned IP ranges at some point, even if they no longer do.
Reconcile these lists into a single spreadsheet or, better, a structured asset record with columns for registrar, expiry date, owning team, last known use, and DNS status (active, parked, unresolved). This record is the artifact the rest of the audit works from, and it needs an owner who is accountable for keeping it current, not just for producing it once.
What an expired domain actually costs you
The risk of losing a forgotten domain is not abstract. Once a registration lapses and clears the registrar’s redemption grace period, it re-enters the public pool and can be bought by anyone, usually within minutes if it has any residual search ranking or backlink value.
The most direct consequence is brand impersonation. An attacker who registers a lapsed campaign or ccTLD domain can stand up a page that mimics the original branding, still indexed under old backlinks, and use it for phishing or malware distribution. Because the domain previously belonged to the real company, it inherits a degree of trust and SEO authority that a freshly registered lookalike domain would not have.
The subtler and often more damaging failure mode is mail-based takeover through stale DNS records that reference the expired domain, rather than the domain itself. A common pattern: your production domain’s SPF record includes a third-party marketing or fulfillment vendor’s domain (v=spf1 include:oldvendor-mail.com ~all). If that vendor relationship ends and the vendor’s domain is allowed to expire, whoever re-registers it can add their own SPF and DKIM records and successfully send mail that passes authentication checks as if it originated from your approved sender list. This is the dangling SPF include problem, and it is invisible until someone audits every include: mechanism against current vendor status, not just the top-level domain’s own registration.
A second variant hits old company sub-brands directly: if a decommissioned domain still has MX records pointing at a live mail exchanger, or if employees historically used addresses on that domain for account recovery, an attacker who reclaims the domain can receive password reset emails for any service where that address is still on file. Domains rarely get fully “logged out” of every third-party account that once used them.
Parking rules for domains you keep but do not use
Not every low-value domain should be released. Defensive and lookalike registrations often need to stay under your control precisely so nobody else can weaponize them. The requirement is to park them safely rather than leaving them in an ambiguous, unmonitored state.
| Record type | Recommended parked configuration | Why |
|---|---|---|
| A / AAAA | None, or point to a controlled placeholder page returning HTTP 410 | Prevents the domain from resolving to an abandoned hosting IP that could be reassigned to another tenant |
| MX | Null MX per RFC 7505: 0 . |
Explicitly declares the domain accepts no mail, closing the account-recovery and mail-spoofing paths |
| SPF | v=spf1 -all |
Hard-fails any mail claiming to originate from the domain, since none should |
| DMARC | v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourmaindomain.com |
Enforces the SPF/DKIM failure and routes any spoofing attempts to a monitored inbox |
| Registrar lock | Client transfer lock enabled, auto-renew on, WHOIS privacy on | Blocks unauthorized transfer and hides the registrant contact from harvesting |
Set a renewal reminder well ahead of the registrar’s own notice, since those notices reliably land in an inbox nobody checks. Ninety, sixty, and thirty days out is a reasonable cadence, tied to the owner field in the inventory record rather than to whichever employee happened to register the domain originally.
Deciding what to cut
Every domain on the list should be run through the same short set of questions before a renewal decision is made:
- Does it map to a live or planned product or market? If there is no roadmap item tied to it within the next renewal cycle, that is a point against keeping it.
- Does it receive any traffic or hold meaningful backlinks? Check analytics and a backlink tool; a domain with zero visits and no inbound links has little defensive value beyond blocking squatters.
- Is it referenced anywhere still in circulation? Old print materials, partner integration docs, or a still-live SPF include are reasons to keep a domain parked rather than release it, even if it serves no active purpose.
- Does it correspond to a registered trademark? Legal defensibility can outweigh cost for a small number of domains regardless of traffic.
- What is the renewal cost relative to its risk if lost? A $12/year defensive .com is cheap insurance. A ccTLD that requires a local presence agent, or one priced well above standard gTLD rates, deserves a harder look, since it is often carrying ongoing cost and third-party dependency for very little return.
Domains that fail all five should be allowed to lapse deliberately, not accidentally, which means documenting the decision and removing every DNS record that references them before the registration itself expires.
A centralized governance model
The recurring pattern behind portfolio sprawl is that domain registration has no single point of accountability. Fixing that structurally prevents the next audit from starting at zero.
Route every new domain purchase through one approved registrar relationship, or at most two for redundancy, and through procurement rather than a personal card, so it lands in the same financial trail as every other vendor purchase. Require a naming and tagging convention at registration time: owning team, business justification, planned decommission date for campaign domains, and a named individual accountable for renewal, not just a shared team alias that turns over every eighteen months.
DNS management should sit with a small central team even when domains are requested by marketing or regional units. Delegating a subdomain via NS records is safer than handing out edit access to a shared parent zone, since it limits the blast radius if that team’s credentials are compromised or a well-meaning contractor makes an unreviewed change.
Treat the domain inventory as an asset record, not a spreadsheet that gets refreshed once a year under audit pressure. Platforms built for continuous discovery, such as SITEY’s asset inventory module, pick up newly observed domains and subdomains from certificate transparency and DNS monitoring on an ongoing basis, so a shadow registration surfaces within a discovery cycle instead of at the next annual review.
Once the inventory is centralized, tie it into the same scanning and closure workflow used for every other asset class. A domain that resolves to a live host should enter the same rotation as any other target; a domain that is intentionally parked should be flagged as such so it does not generate false findings every cycle. Platforms that run scheduled discovery, such as SITEY’s scan management workflow, can be configured to re-check parked domains on a lighter cadence, confirming the null MX and SPF hard-fail records are still in place rather than treating them as fully out of scope. That distinction, active asset versus deliberately parked asset versus abandoned asset, is the entire point of the audit, and it only holds up if someone revisits it on a schedule.
Finally, put the review on a calendar. A quarterly pass against the registrar export, cross-checked against the CT log query and the finance record, catches new sprawl before it accumulates for another five years. The goal is not a portfolio of zero unused domains; some defensive and reserved registrations are legitimate. The goal is that every domain the organization holds has a known owner, a known reason to exist, and DNS records that reflect its actual state instead of whatever was configured the day it was registered and never touched again. Details on how discovery and asset tracking fit together across a broader environment are covered on the platform features page.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.