Skip to main content
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. 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. Integrations with source-IP restrictions need the connected-system rules. The standard entries are on this page; linked guides provide setup instructions.

​
Email delivery

​
Authentication emails

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.

​
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: 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: 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, including Microsoft Defender’s simulation controls when applicable.

​
Application and API access

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. If your organization uses a custom application or sign-in hostname, include the exact hostname provided during setup.

​
Sign-in requirements

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. 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. 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): Also allow the platform pair for your region when you use any of these integrations: 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: 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 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.