> ## Documentation Index > Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt > Use this file to discover all available pages before exploring further. # Allowlisting Quickstart > Network and email allowlisting for onboarding: application URLs, US and EU APIs, authentication, content CDNs, customer uploads, and email delivery. Send this page to your IT team before onboarding. It puts the web destinations, email senders, source IPs, and optional upload and integration requirements in one place. Some security products call allowlisting **whitelisting** or **safelisting**. ## Start with the short list **Web access: HTTPS / TCP 443.** In many environments, the two Living Security wildcards plus the external content and sign-in asset hosts below cover employee access. | Allowlist entry | Purpose | | - | - | | `*.livingsecurity.ai` | Applications, US and EU APIs, sign-in, shared assets, and onboarding tours | | `*.livingsecurity.com` | Documentation and content, including `platform-cdn.livingsecurity.com` and `assets.livingsecurity.com` | | `assets.livingsecurity-content-cdn.ai` | Customer-uploaded images, documents, and training/SCORM content | | `videos.livingsecurity-content-cdn.ai` | Customer-uploaded and catalog videos, thumbnails, and captions | | `cdn.contentful.com` | Contentful content delivery | | `images.ctfassets.net` | Contentful images | | `assets.ctfassets.net`; `downloads.ctfassets.net` | Contentful files and downloads | The customer content CDNs and Contentful hosts are **outside** the Living Security wildcards. The customer CDNs use `livingsecurity-content-cdn.ai`, a separate domain from `livingsecurity.ai`. Also allow `static.descope.com` and `descopecdn.com` for **embedded sign-in assets only**; sign-in requests use `auth.livingsecurity.ai`. If you use only `*.livingsecurity.ai`, add `platform-cdn.livingsecurity.com` and the other `.com` content hosts listed below. The detailed hostname tables are for IT teams that cannot use wildcards; they do not require duplicate rules. Check whether your gateway's wildcard matches nested names such as `api.eu-west-1.livingsecurity.ai`. A wildcard may exclude the bare domain. Use hostnames for web destinations because their IPs can change. **Complete the email rules below as well.** Content authors also need the [upload destinations](#upload-destinations). Integrations with source-IP restrictions need the [connected-system rules](#ip-rules-in-your-connected-systems). The standard entries are on this page; linked guides provide setup instructions. ## Email delivery ### Authentication emails | From address | Sending IPs | | - | - | | `app@livingsecurity.ai` | `159.183.37.179/32`, `159.183.38.165/32` | Apply these entries to **sign-in emails** in your mail protection service. Verify that messages arrive before their links expire. Notifications use these same IPs; simulations use the separate ranges below. See [Enterprise Identity](/features/settings/sso). ### Transactional platform emails The **same two sending IPs listed above** also send platform notifications in **both US and EU**. Allow these From addresses and the authenticated return-path domain: | Configuration | From addresses | Return-Path / mail authentication | | - | - | - | | Living Security platform email | `app@livingsecurity.ai`; `noreply@livingsecurity.ai` | `em9309.livingsecurity.ai` | | Custom sending domain | The activated address shown in **Settings → Communications → Sending Domain** | Use that domain's displayed DNS records; platform-managed delivery uses the same source IPs above | | Your SMTP transport | The **From email** saved in **Settings → Communications → SMTP Transport** | Your own relay's sending IPs and mail authentication | These cover welcome messages, training assignments, reminders, and other notifications. Keep SPF, DKIM, and DMARC validation enabled. Simulation SMTP uses its own ranges below. **If your own SMTP relay restricts connections by source IP**, obtain Living Security's SMTP connection source IPs for your region from Support before configuring the relay. These identify the connection **to your relay**, separately from your relay's own sending IPs. Do not substitute the platform-managed mail IPs above or the integration API IPs below. ### Phishing simulations For **platform-managed SMTP**, use your organization's region: | Region | Sending CIDR | Complete address range | Mail authentication domain | | - | - | - | - | | United States (`us-east-1`) | `3.41.193.72/29` | `3.41.193.72` – `3.41.193.79` | `us.mail.trident-sim.com` | | European Union (`eu-west-1`) | `3.40.138.240/29` | `3.40.138.240` – `3.40.138.247` | `eu.mail.trident-sim.com` | Allow the **complete IP range** for your region. Use the mail authentication domain for gateway rules that require it. The visible From address varies by simulation; use the current allowlist package for your selected simulations. Before launch, obtain the organization-specific package from **Settings → Simulations → Allowlisting → Export allowlist package**, or request it from your Customer Success Manager before you have access. It includes enabled sending domains, landing/URL hosts, and the distinct **Reply-To domain**. Review the actual From addresses for your selected simulations if your gateway requires full addresses. Download an updated package when your simulation settings change. **Direct mailbox injection (DMI)** uses your connected Microsoft 365 or Google Workspace integration; the SMTP source ranges do not apply to that delivery path. URL access, provider consent, and inbox testing still matter. Follow the provider-specific steps in [Simulation Settings](/features/settings/phishing-simulation#allowlisting-and-allowlist-export), including Microsoft Defender's simulation controls when applicable. ## Application and API access | Purpose | Hostnames to allow | Who needs access | | - | - | - | | Dashboard | `app.livingsecurity.ai` | Administrators and managers | | Engage | `engage.livingsecurity.ai` | Employees taking training or opening assignments and scorecards | | US API | `api.us-east-1.livingsecurity.ai` | Browsers and API clients using the US region | | EU API | `api.eu-west-1.livingsecurity.ai` | Browsers and API clients using the EU region | | Sign-in | `auth.livingsecurity.ai` | Administrators and employees signing in | | Documentation | `docs.livingsecurity.com` | Administrators and users reading help | For EU organizations, allow **both API hostnames** for browser sign-in and application access. For a direct API integration, use your organization's assigned regional URL. See [API quickstart](/developers/v1/quickstart). If your organization uses a custom application or sign-in hostname, include the exact hostname provided during setup. ### Sign-in requirements | Purpose | Hostnames | When needed | | - | - | - | | Embedded sign-in assets | `static.descope.com`; `descopecdn.com` | Scripts, styles, and other assets that display the embedded sign-in form; these are asset hosts, not sign-in API endpoints | | Sign-in fonts and scripts | `fonts.googleapis.com`; `fonts.gstatic.com`; `cdn.jsdelivr.net` | When requested by your embedded sign-in form | | Your identity provider | Your organization's SSO and MFA hostnames | SSO redirects and authentication challenges | Sign-in requests use **`auth.livingsecurity.ai`**, listed above. The embedded form also loads assets from the hosts in this table. If the form does not display correctly, ask your IT team to check whether those asset requests are blocked. ## Content, CDNs, and customer uploads Allow these hosts for administrators previewing content and employees consuming it. Email image protection may also need access to image hosts. | Purpose | Hostnames | Scope | | - | - | - | | **Customer-uploaded assets** | `assets.livingsecurity-content-cdn.ai` | Organization images, documents, email assets, and uploaded training/SCORM content | | Customer-uploaded and catalog videos | `videos.livingsecurity-content-cdn.ai` | Streaming video, thumbnails, and captions | | Application images and assets | `cdn.livingsecurity.ai` | Images and other assets displayed in the application | | Living Security content delivery | `platform-cdn.livingsecurity.com` | Platform content; covered by `*.livingsecurity.com` | | Contentful content delivery | `cdn.contentful.com` | Contentful-hosted content | | Contentful images | `images.ctfassets.net` | Catalog artwork and training images | | Contentful files | `assets.ctfassets.net`; `downloads.ctfassets.net` | Catalog files and large downloadable assets | | Training media | `assets.livingsecurity.com` | Training media served through the Living Security content hostname; covered by `*.livingsecurity.com` | The customer asset and video hosts are on **`livingsecurity-content-cdn.ai`**, a different domain from `livingsecurity.ai`. Allowing `*.livingsecurity.ai` alone does **not** cover them. Enter the explicit hosts above when your gateway does not support wildcards. A wildcard also may not include the bare domain or nested subdomains in your security product. If you add externally hosted content, also allow the destinations that content uses. Review those addresses before assigning the content to employees. ### Upload destinations **Content authors only.** These destinations receive new uploads; employees viewing existing content need the CDN hosts above. | Upload type | Destination to allow over HTTPS / TCP 443 | | - | - | | Images, documents, and training packages — US | `phoenix-prod-us-east-1-tenant-assets.s3.us-east-1.amazonaws.com` | | Images, documents, and training packages — EU | `phoenix-prod-eu-west-1-tenant-assets.s3.eu-west-1.amazonaws.com` | | Resumable video uploads — both regions | `video.bunnycdn.com` | Use the file-upload row for your organization's region. Preserve signed URL query strings and required headers, and permit upload methods such as `PUT`, `POST`, `PATCH`, `HEAD`, and preflight requests. Video **playback** uses the custom Living Security CDN; the video upload host is a separate authoring requirement. ## Additional features and integrations * **SSO/MFA and integration consent:** allow your identity provider and the sign-in/consent pages for each system you connect. * **Onboarding tours:** `onboard.livingsecurity.ai`, covered by the `.ai` wildcard; permit HTTPS and secure WebSockets on TCP 443. * **Livvy and live updates:** permit streaming HTTPS responses and secure WebSockets on TCP 443. * **External content, custom domains, and your LMS:** include the exact hosts your organization uses. Test hosted SCORM from the learner network. ## IP rules in your connected systems If a system you connect restricts API access by source IP, add these addresses to **that system's API allowlist**. They are the source addresses it will see when Living Security requests data. They are not outbound destinations for employee devices. Allow all four **sync** addresses (the same in US and EU): | IP address | CIDR | | - | - | | `52.34.139.153` | `52.34.139.153/32` | | `54.69.127.183` | `54.69.127.183/32` | | `44.247.133.183` | `44.247.133.183/32` | | `52.26.211.56` | `52.26.211.56/32` | Also allow the **platform** pair for your region when you use any of these integrations: * [Auth0](/integrations/auth0) * [Cofense Triage](/integrations/cofense-triage) * Code42 * Cornerstone * [CrowdStrike Falcon](/integrations/crowdstrike) * [Microsoft Entra ID](/integrations/microsoft-entra-id) — including Microsoft Graph * [OneLogin](/integrations/onelogin) * Sophos Central * Zscaler Client Connector The platform pair also applies to connections configured for **direct egress** and providers that require direct actions. Keep both address sets allowed for continued authentication, syncs, and actions: | Region | IP addresses | CIDR | | - | - | - | | **United States** | `98.91.60.249`, `13.216.91.102` | `98.91.60.249/32`, `13.216.91.102/32` | | **European Union** | `34.246.236.210`, `52.31.102.238` | `34.246.236.210/32`, `52.31.102.238/32` | Keep all required addresses allowed after setup so authentication and data syncs continue to work. Use these entries only for integration API access. The [integration egress guide](/integrations/managing/egress-ip-addresses#integrations-that-need-both-sets) lists provider-specific requirements. ## Verify before launch Test through the same corporate network, proxy, VPN, endpoint protection, and mailbox controls your employees use: * Sign in to Dashboard and Engage; complete SSO/MFA or receive a working email sign-in link. * Open a Dashboard page and ask Livvy a question. * Open catalog images, play a video with captions, and open a downloadable document. * Upload a customer asset, then preview it as a learner; launch an uploaded SCORM package if you use one. * Deliver a welcome or training-assignment email; check its sender, authentication, links, and images. * Run a simulation on the chosen delivery path; verify inbox arrival, landing-page access, and replies for reply-based scenarios. * Connect each enabled integration and verify an actual data sync, not just successful authorization. If one check fails, capture the blocked hostname, time, region, affected feature, and gateway error or mail trace, then contact Support. Remove credentials, session tokens, and signed URL query strings before sharing diagnostics. Recheck this guide and your exported simulation package when configuration changes. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.