Loading errors
Is something not working as it should? Let's refresh!
Whitelisting domains for app performance and emails
Last updated:
If you are having trouble connecting to Classroomscreen, we recommend giving this article to your IT representative/department - it should provide them with the tools to get the issue resolved.
tip:
Please ensure the domains below are unblocked so Classroomscreen can work correctly.
Critical domains for the app's core functionality
- *.classroomscreen.com (Basically, our main domain and all subdomains, two levels deep. For instance, we use classroomscreen.com, auth.classroomscreen.com but also prd.files.classroomscreen.com. Please whitelist all subdomains with a wildcard.)
Recommended domains for a well-functioning app
- *.googleapis.com (This also contains subdomains for SSO and databases.)
- *.sentry.io (Needed to see issues that make it easier to provide support.)
- *.firebaseio.com (Needed for a functioning Poll widget and syncing sessions of the same user between browsers.)
Critical domains for signing in and out
- identitytoolkit.googleapis.com
important:
This applies regardless of the sign-in method.
For SSO with Google or Microsoft
The following domains are loaded by the popup for SSO using Google:
- *.youtube.com
- *.gstatic.com
- *.google.com
The following domains are loaded by the popup for SSO using Microsoft:
- *.msauth.net
- *.microsoft.com
- *.live.com
Receiving transactional emails
If you are having trouble receiving transactional emails (like pro-licenses, password reset, verification email, etc.), please follow these guidelines.
Quick checks (for everyone)
- Check Spam/Junk. If you find us there, mark the message as Not spam.
- Search your mailbox by sender or keywords (e.g., “Classroomscreen”, “verify”, “reset your password”).
- Review client-side rules/filters that might auto-archive or move messages.
- Request a new email (e.g., use “Forgot password?”).
If mail still doesn’t arrive, proceed with allowlisting below.
Steps for IT administrators (allowlist on all layers)
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: [email protected], [email protected]
1. Check for existing blocks first
- 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.
2. Allowlist in your spam filter / email gateway
- Add IP
172.246.20.106to the IP allowlist (a.k.a. Approved IPs / Permitted Senders). - Add
send.classroomscreen.comandclassroomscreen.comto Allowed/Trusted Domains. - Ensure inbound policies do not flag this IP/domains as spam/phish and do not apply rate-limiting/greylisting.
3. Mail server level (Microsoft 365/Exchange, Google Workspace, etc.)
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).
4. Third-party filtering
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.
If issues persist
5. Temporary test
- 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).
6. Validate via headers/logs
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.
Testing & support
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.
