> For the complete documentation index, see [llms.txt](https://help.nightfall.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.nightfall.ai/data-exfiltration-prevention/exfiltration_endpoint/policies/starter-domain-collections.md). # Starter Domain Collections Starter domain collections are curated lists of domains that Nightfall maintains so you don't have to build them by hand. Each one covers a category of destination — personal email, cloud storage, code repositories, VPN services. The **Backs policies** column refers to the numbered set in [Recommended Human Exfil Policies](/data-exfiltration-prevention/exfiltration_endpoint/policies/recommended-human-exfil-policies.md). Load a collection once, then reference it from as many policies as you like. When Nightfall updates the list, every policy pointing at it picks up the change. ### Why they matter If you want to alert when sensitive data goes to personal webmail, the policy needs a list of what counts as personal webmail. That list is 95 domains covering every major free provider and disposable-address service. Building it yourself means researching and maintaining it; loading the starter collection takes a few seconds. The same applies in reverse. Policies that watch for uploads to *unsanctioned* destinations work by exception — a destination is unsanctioned because it is not in a sanctioned collection. Until your own systems are collected, every upload to them looks like something worth flagging. ### The collections #### Destination categories | Collection | Domains | Backs policies | What it covers | | --------------------------------- | ------- | ------------------- | ------------------------------------------------------------------------------------------------------------------- | | **Personal email** | 95 | 3, 6 | Free webmail and disposable-address services — Gmail, Yahoo, Outlook.com, Proton, Mailinator and regional providers | | **File sharing services** | 51 | 3, 6 | WeTransfer, Dropbox, Box, MEGA, SendSpace and similar | | **Forums and online communities** | 49 | 3, 6 | Reddit, Quora, Stack Exchange, 4chan, Discourse-hosted boards | | **Social media** | 48 | 3, 6 | Facebook, Instagram, X, TikTok, LinkedIn, Snapchat | | **Cloud storage** | 42 | browser only | Dropbox, Box, OneDrive, iCloud, pCloud, Sync.com, Tresorit | | **Messaging apps** | 41 | 3, 6 | WhatsApp Web, Telegram Web, Signal, Discord, WeChat | | **VPN and proxy services** | 41 | 3, 6 | NordVPN, ExpressVPN, Surfshark, Tor, open proxy services | | **Personal blogs and sites** | 32 | 3, 6 | WordPress.com, Blogspot, Tumblr, Medium, Substack, Wix | | **Peer-to-peer file sharing** | 31 | 3, 6 | BitTorrent, uTorrent, Transmission, public tracker sites | | **Code repositories** | 30 | Source code uploads | GitHub, GitLab, Bitbucket, SourceForge, Gitee, Codeberg, self-hosted Gitea | | **Anonymous file upload** | 26 | 3, 6 | AnonFiles, file.io, transfer.sh, GoFile, catbox.moe, 0x0.st | #### AI and automation | Collection | Domains | Backs policies | What it covers | | ------------------- | ------- | -------------- | ------------------------------------------------------------------------------------ | | **GenAI** | 23 | 1, 4 | ChatGPT, Claude, Gemini, Perplexity, Copilot, DeepSeek, Grok, NotebookLM, ElevenLabs | | **Agent builders** | 22 | 1, 4 | n8n, Make, Zapier, Pipedream, LangChain, Flowise, Dust, CrewAI, Manus, Relevance | | **Data connectors** | 16 | 1, 4 | Glean, Retriever, Read.ai, Pinecone, Weaviate, Qdrant, Milvus, Elastic, Algolia | **Agent builders and data connectors are worth loading even if you have no AI policy yet.** They cover tools that connect to internal systems and move data on a schedule, which is a different risk shape from someone pasting into a chat window. #### Session check domains | Collection | Domains | Backs policies | What it covers | | --------------------------------------------- | ------- | -------------- | ---------------------------------------------------------------------------- | | **Nightfall supported session check domains** | 36 | 2, 5 | Google Workspace, Microsoft 365, Dropbox, Box, iCloud, and major AI services | This one is different from the rest. It is not a list of destinations to watch — it is the list of destinations where Nightfall **can tell a personal account from a corporate one**. Copy the full list of 36 domains from [Session Detection](/data-exfiltration-prevention/exfiltration_endpoint/policies/trigger/session-detection-corporate-and-personal-account-filtering.md). The session check file in the download above is an older, shorter list. Session detection reads the signed-in identity from the page, using DOM inspection, a browser storage key, or cookies depending on the site. That only works where Nightfall has implemented it. On any other domain the check falls back to a best-effort lookup and is not guaranteed. **Load this collection before building any policy that depends on account type.** A policy that checks the session on an unsupported domain will be created, will look correct in the console, and will never fire. Also create your **Corporate Domains** collection with your company email domains. Session detection uses it to decide which accounts are corporate. ### Working with wildcards Most entries are wildcards: `*.dropbox.com` matches `www.dropbox.com`, `app.dropbox.com` and any other subdomain. Two consequences worth knowing: **Coverage figures that match literally will understate you.** If you compare a list of observed destinations against your collections using exact string matching, `chat.deepseek.com` will not match `*.deepseek.com` and will appear uncollected. Expand wildcards before comparing, or treat the figure as a floor. **A wildcard covers subdomains you have not seen yet.** That is usually what you want for a service you have decided about, and occasionally not — `*.google.com` covers Drive, Gmail, Docs and also `sdk.cloud.google.com`, which behaves differently from the rest. ### Loading a collection 1. Go to **Collections** in the Nightfall console. 2. Choose **New collection** and give it a name you will recognize in a policy. 3. Paste the domain list, one entry per line. 4. Save, then reference the collection from a policy's destination scope. Collections are referenced by policies, not copied into them, so a single collection can back several policies and updating it updates all of them at once. ### Which to load first If you are starting from nothing, these three cover the most ground: **Personal email, cloud storage and file sharing.** Together these back the policies that catch the case most organizations care about first — someone moving company data to an account they own. **Then the high-risk set**: anonymous file upload, VPN and proxy, peer-to-peer, and personal blogs. These are small lists covering destinations that rarely have a business justification, which makes them good candidates for enforcement sooner than the broader categories. **Code repositories** if you have engineers, since it backs source code upload policies. Git push policies use your own Approved Git Destinations collection instead. **Session check domains** before any policy that distinguishes personal from corporate accounts. ### Keeping your own collections alongside these Starter collections cover categories of external destination. They do not cover your own systems, and those matter just as much. Most unsanctioned-destination policies work by exception, so a sanctioned collection holding your own domains, your SaaS tools and your partners' systems is what stops routine work from generating alerts. Build that one yourself — nobody else knows what your business sanctions. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.nightfall.ai/data-exfiltration-prevention/exfiltration_endpoint/policies/starter-domain-collections.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.