Whitelisting domains for app performance and emails

Last updated:

If Classroomscreen is not loading correctly, certain features are not working (such as polls or syncing), or you see an error indicating that data cannot be loaded, this can be caused by network restrictions. This most commonly occurs when connected to a school network.

Want to check if your connection is causing the issue?

Run our diagnostics test to see if anything is being blocked on your network: Run diagnostics

If any issues are detected, we recommend giving this article to your IT representative/department - it should provide them with the tools to get the issue resolved.

These URLs must be allowed at both the network level (school firewall) and within any web filtering services (such as GoGuardian, Lightspeed, or Securly).

Main domain
We recommend whitelisting the main domain and all subdomains with a wildcard if the security software supports it.

Subdomains Used for
User for loading data provided by Classroomscreen such as background images.
Used for user authentication
Used for a well functioning back-end
User for loading date such as images, and backgrounds uploaded bij the user
The join app is user for participans for the remote voting functionality for Poll widget.

External domains Used for
For SSO and to reach databases.
Needed for a functioning Poll widget and syncing sessions of the same user between browsers.
Critical for signing in and out (regardless of the sign-in method)
Critical for signing in and out (regardless of the sign-in method)
For SSO with Google
For SSO with Microsoft

If you are having trouble receiving transactional emails (like pro-licenses, password reset, verification email, etc.), please follow these guidelines.

  1. Check Spam/Junk. If you find us there, mark the message as Not spam.
  2. Search your mailbox by sender or keywords (e.g., “Classroomscreen”, “verify”, “reset your password”).
  3. Review client-side rules/filters that might auto-archive or move messages.
  4. Request a new email (e.g., use “Forgot password?”).

If mail still doesn’t arrive, proceed with allowlisting below.

Allowlist these senders and identifiers:

Sending IP: 172.246.20.106

Domains: send.classroomscreen.com, classroomscreen.com

DKIM signature: send.classroomscreen.com

From addresses to trust: info@classroomscreen.com, support@classroomscreen.com

  • Look for the IP/domain/senders on any deny/block lists or in quarantine.
  • Remove any block rules and train the system that these senders are legitimate.
  • Add IP 172.246.20.106 to the IP allowlist (a.k.a. Approved IPs / Permitted Senders).
  • Add send.classroomscreen.com and classroomscreen.com to Allowed/Trusted Domains.
  • Ensure inbound policies do not flag this IP/domains as spam/phish and do not apply rate-limiting/greylisting.

Create a mail flow/transport rule (or equivalent) so messages from IP 172.246.20.106 or domains send.classroomscreen.com / classroomscreen.com are:

  • Bypassed from anti-spam/anti-phish scoring, or
  • Stamped as trusted so they reach the inbox.
  • Keep the scope narrow (only this IP and these domains).

If you use Barracuda, Proofpoint, Mimecast, or similar:

  • Add the IP and domains to that provider’s allowlist.
  • Contact the provider’s support to confirm there is no upstream block.
  • Temporarily relax strict filtering for our IP/domain and request a test email (see “Testing & support” below) to confirm delivery.
  • After testing, re-enable your policies (keeping the exception for our IP/domain).

In message trace/quarantine or raw headers, confirm that incoming test messages:

  • Originate from IP 172.246.20.106;
  • Contain DKIM send.classroomscreen.com;
  • Are not rejected by your SPF/DMARC checks.

We’re happy to send a test email to confirm delivery. Request a test email through the contact us page. Please include the address to send to and mention it’s an allowlist test.

Related articles for you to read