Block or Trust IP Ranges in Google Workspace

Credentials get stolen. VPNs get misconfigured. Remote workers connect from unexpected locations. The reality of managing Google Workspace for an Australian SMB is that "valid login" and "safe login" are not the same thing. Someone with a stolen username and password logging in from a residential IP address in Eastern Europe looks identical to your legitimate staff member doing the same thing from their home office in Brisbane — unless you have told Google Workspace to treat those two scenarios differently.

IP-based controls are one of the most direct tools available to Google Workspace admins. They let you say: access from these addresses is trusted, access from those addresses is blocked, and everything else gets additional scrutiny. Used correctly, they significantly reduce your attack surface without adding friction for your team.

This guide covers the two primary mechanisms for IP-based controls in Google Workspace: Context-Aware Access, which handles access policies across Google services, and Gmail IP allowlists and blocklists, which control inbound email routing and relay permissions. It also covers how to apply CIDR network masks correctly, practical use cases for Australian SMBs, and the licence requirements you need to know before you start.

What this guide covers:
- Why IP-based controls matter and when to use them
- How Context-Aware Access uses IP signals to allow or block service access
- How to configure Gmail IP allowlists and blocklists for inbound email
- How to read and apply CIDR network notation correctly
- Common use cases with worked examples
- Licence requirements for each feature

Why IP-Based Controls Matter

IP-based access controls are not a replacement for multi-factor authentication or device management. They are an additional layer in a defence-in-depth strategy. Their primary value is in narrowing the blast radius when credentials are compromised.

Consider these scenarios that are common for Australian businesses:

• Credential stuffing attacks: An attacker cycles through a list of stolen username and password combinations. Your staff are likely on that list from one of the many data breaches affecting Australian consumers. Without IP restrictions, a valid credential from an overseas IP gets straight through.
• Compromised remote access: A staff member's home network is compromised. Without network segmentation, the attacker piggybacks on their VPN session. With IP restrictions tied to your VPN exit node, sessions from unexpected subnets trigger additional challenges or are blocked outright.
• Inbound email spoofing and relay abuse: Spammers attempt to route mail through your domain or deliver malicious payloads from known bad IP ranges. Gmail's IP blocklist gives you a lever to reject email from specific sources before it ever reaches a user's inbox.
• Admin Console access from uncontrolled locations: Your Super Admin account should not be accessible from an internet cafe in any city, let alone one overseas. Locking Admin Console access to your office IP range is one of the fastest wins available to any Workspace admin.

The Australian Cyber Security Centre's Essential Eight framework emphasises restricting access based on need and context. IP-based controls are a concrete implementation of that principle inside your existing Google Workspace environment — no additional infrastructure or third-party tooling required.

Understanding CIDR Network Notation

Before diving into the Admin Console steps, it is worth taking a moment to understand CIDR notation, because you will encounter it everywhere when configuring IP restrictions.

CIDR (Classless Inter-Domain Routing) notation represents an IP address range as a base address followed by a slash and a prefix length. The prefix length tells you how many bits of the address are fixed, and therefore how many addresses the range contains.

Common examples:

Finding your office IP range: Your ISP assigns your office either a static IP address or a dynamic one that changes periodically. For IP-based controls to be reliable, you need a static IP. Contact your ISP if you are unsure. Once you have your static IP, use /32 to represent that single address, or /24 if your ISP has assigned you a full subnet.

For VPN exit nodes: Your VPN provider will give you the exit IP addresses or ranges your traffic appears to come from. Add these alongside your office IPs to ensure remote workers connecting through approved VPNs are not blocked.

If you have a dynamic IP or are not sure of your current public IP, visit whatismyip.com.au from your office network. That will show you the IP address that Google sees when you connect.

Method 1: Context-Aware Access for IP-Based Service Restrictions

Context-Aware Access is Google Workspace's policy engine for controlling access to Google services based on who is connecting, where they are connecting from, and what device they are using. IP address or subnet is one of the core signals it evaluates.

Licence Requirements

Context-Aware Access with IP-based conditions is available on:

• Business Standard and Business Plus: Basic IP-based access levels. Sufficient for most Australian SMBs.
• Enterprise Standard and Enterprise Plus: Full context-aware access, including device posture signals combined with IP conditions.
• Education Standard and Education Plus: Full capabilities for education institutions.

Business Starter does not include Context-Aware Access. If you are on Starter and this feature is important to your security posture, upgrading to Business Standard is the minimum step required.

Step 1: Navigate to Context-Aware Access

1. Sign in to the Google Admin console at admin.google.com with a Super Admin account.
2. Navigate to Security > Access and data control > Context-Aware Access.
3. If this is your first time here, you will be prompted to enable Context-Aware Access for your organisation. Click Enable.

Step 2: Create an Access Level Based on IP

Access levels are the building blocks of Context-Aware Access. Each level defines a set of conditions. When a user meets those conditions, they are granted the access associated with that level.

1. Click Access Levels in the left navigation panel.
2. Click Create Access Level.
3. Name it clearly. Use a convention your team can read at a glance. Examples:
4. AU-Office-IPs-Trusted
5. Corporate-VPN-Exit-Nodes
6. Admin-Console-Restricted-IPs
7. Under Conditions, find the IP subnet section.
8. Click Add IP subnet.
9. Enter your office IP in CIDR notation. For example: 203.0.113.10/32 for a single static IP, or 203.0.113.0/24 for a full subnet.
10. Add additional subnets as needed. For example, add your VPN exit node IP alongside your office IP.
11. Click Save.

You can also create an access level that uses IP as a blocking signal rather than a trust signal. To do this, use the Negate option to create an access level that is satisfied when the user is not connecting from specified IPs. This allows you to block access from any IP outside your approved list.

Step 3: Assign the Access Level to Google Services

1. In the Context-Aware Access section, click App assignments or select Assign access levels.
2. You will see a list of Google services. Click the service you want to protect — for example, Admin Console.
3. Select the organisational unit (OU) or group to apply the policy to. For Admin Console access, apply it to your IT Admins group.
4. Under Access level, select the access level you just created.
5. Click Assign.

Repeat this process for other services. A practical starting configuration for an Australian SMB might look like this:

Step 4: Test Before Enforcing

Context-Aware Access includes a monitoring mode that logs what would happen without actually blocking users. Use it.

1. When assigning an access level, look for the Monitor option before selecting Enforce.
2. Leave the policy in monitor mode for at least one to two weeks.
3. Review access events under Reports > Audit and investigation > Access transparency or check the Security Investigation Tool if you are on Enterprise.
4. Look for legitimate users who would be blocked by your policies. Common causes: a staff member working from a client site, someone connecting through a mobile data connection instead of the office VPN, or a recently changed office IP that has not been updated in your access level.
5. Once you are satisfied that no legitimate access patterns will be disrupted, switch from monitor to Enforce.

Critical note for Super Admin accounts: If you are applying IP restrictions to Admin Console access, make sure you are testing from inside the approved IP range before you enforce the policy. Locking yourself out of the Admin Console from the wrong network is a recoverable situation, but it is a frustrating one that requires Google Support intervention.

Method 2: Gmail IP Allowlists and Blocklists

Gmail's IP-based controls operate on inbound email rather than user access. They give you two capabilities: trusting specific IP ranges so that email from those sources bypasses spam filtering, and blocking specific IP ranges so that email from those sources is rejected at the gateway.

These settings are configured under Gmail's routing and compliance settings, not under Context-Aware Access.

When to Use Gmail IP Allowlisting

Allowlisting an IP range tells Gmail to bypass spam filters for email arriving from that source. This is appropriate when:

• You have an internal application (a CRM, ERP, or monitoring system) that sends email through your domain and is being incorrectly flagged as spam.
• You use a third-party email service (such as a bulk marketing platform or invoice system) that sends legitimate email on your behalf and you want to ensure reliable delivery.
• You are migrating email from another mail server and need the old server's IPs to be trusted temporarily during the transition.

Important caveat: Allowlisting bypasses spam filtering. Only allowlist IP ranges you control entirely or trust completely. Allowlisting a shared IP from a cloud provider (a broad AWS or Azure range, for example) is not appropriate, as it would allow spam from any sender using those shared infrastructure IPs to bypass your filters.

Step-by-Step: Configuring Gmail IP Allowlisting

1. In the Google Admin console, navigate to Apps > Google Workspace > Gmail > Spam, Phishing and Malware.
2. Find the Email allowlist section.
3. Click to open and add the IP addresses or CIDR ranges you want to trust.
4. Enter one IP or CIDR range per line. For example:
   203.0.113.50 198.51.100.0/28
5. Click Save.

For more granular control — for example, to allowlist email from a specific server and also bypass specific spam filters selectively — use the Inbound gateway settings instead:

1. Navigate to Apps > Google Workspace > Gmail > Advanced settings.
2. Scroll to the Inbound gateway section and click Configure.
3. Add the IP ranges of your inbound gateway or mail relay.
4. Choose whether to Require TLS for connections from these IPs and whether to Reject unencrypted connections.
5. Check Message is considered spam if the following IP is on a blocked list if you want additional spam protection even from trusted gateways.

Step-by-Step: Configuring Gmail IP Blocklisting

Gmail's blocklist allows you to reject email from specific IP addresses or ranges at the gateway level, before it is delivered to any user's inbox.

1. Navigate to Apps > Google Workspace > Gmail > Advanced settings.
2. Scroll to the Blocked senders section. Note: this is distinct from the spam filter and operates at the IP or sender level.
3. For IP-based blocking, use Email allowlist in reverse or configure Routing rules with IP-based conditions:
4. Navigate to Apps > Google Workspace > Gmail > Routing.
5. Click Configure next to Inbound routing or Routing.
6. Add a new routing rule.
7. Under Email messages to affect, select Inbound.
8. Under Add expressions that describe the content you want to search for, add a condition that matches the source IP range.
9. Set the action to Reject message with a custom rejection message if desired.
10. Click Save.

For straightforward IP blocking of known spam sources, many Australian admins find it effective to use the Blocked senders list under Spam, Phishing and Malware settings combined with envelope sender domains, and reserve the routing rules approach for specific IP-range rejections.

Combining Gmail IP Controls With SPF and DMARC

IP-based Gmail controls work best when combined with proper email authentication. If you have SPF, DKIM, and DMARC configured correctly for your domain, Gmail can reject spoofed emails at the authentication layer before IP-based controls even come into play. The IP controls then handle cases that authentication cannot: bulk spam from legitimate-looking but unwanted senders, or specific sources you want to explicitly trust despite not having perfect authentication records.

Practical Use Cases for Australian SMBs

Use Case 1: Restricting Admin Console Access to the Office

Scenario: You manage a 60-person business in Melbourne with a single static office IP (203.0.113.42). You want to ensure your two Super Admin accounts can only access the Admin Console from the office or through the company VPN (exit IP 198.51.100.8).

Solution:
- Create an access level Admin-Approved-IPs with two subnets: 203.0.113.42/32 and 198.51.100.8/32.
- Assign this access level to the Admin Console service, applied to the IT Admins Google Group.
- Run in monitor mode for one week to confirm no legitimate admin access is coming from other IPs.
- Enforce.

Result: A compromised Super Admin credential used from any other network is blocked before it can make any changes to your environment.

Use Case 2: Protecting Google Drive for Finance

Scenario: Your finance team of five people handles payroll and client billing from the office. You want their Google Drive access restricted to the office network, with an exception for the CFO who travels interstate and uses the company VPN.

Solution:
- Create an access level Finance-Approved-Networks that includes the office subnet and the VPN exit IP.
- Assign this access level to Google Drive, scoped to the Finance OU.
- Ensure the CFO's laptop is enrolled in endpoint verification so device posture can be validated alongside the IP condition (requires Business Plus or above).
- Enforce after a one-week monitoring period.

Result: Finance data in Drive is inaccessible from any network except your office and approved VPN, even if a team member's credentials are stolen.

Use Case 3: Blocking a Known Spam Source From Emailing Your Domain

Scenario: You are receiving a sustained volume of spam from a specific IP range (192.0.2.0/24) that is not being caught by Gmail's default spam filters.

Solution:
- Navigate to Apps > Google Workspace > Gmail > Routing.
- Create an inbound routing rule that matches the source IP range and rejects the message.
- Use a rejection message such as: 550 5.7.1 Message rejected: sender IP range is blocked by recipient policy.

Result: Email from that range is rejected at the gateway and never reaches user inboxes or spam folders.

Use Case 4: Allowlisting Your Invoice System

Scenario: Your accounting software (hosted at a static IP 198.51.100.100) sends automated invoices to clients that occasionally land in the Gmail spam folder for your staff who receive copies.

Solution:
- Navigate to Apps > Google Workspace > Gmail > Spam, Phishing and Malware.
- Add 198.51.100.100/32 to the Email allowlist.
- Confirm the source IP is static and dedicated to your software — not a shared cloud provider IP.

Result: Invoice emails from your accounting system arrive in the inbox reliably.

Affiliate & Partner Programs

If you are evaluating a Google Workspace plan upgrade to access Context-Aware Access features (available from Business Standard and above), the following referral link may be useful:

• Google Workspace Referral Program: https://referworkspace.app.goo.gl/ — refer businesses to Google Workspace and earn rewards through the official partner program.

Wrapping Up

IP-based controls in Google Workspace are not glamorous, but they are effective. Restricting Admin Console access to your office network and VPN closes off one of the most commonly exploited attack vectors — compromised admin credentials — with a configuration change that takes under 30 minutes. Gmail IP allowlisting ensures your internal systems communicate reliably without being caught by spam filters. Blocking known bad IP ranges at the gateway keeps your users' inboxes cleaner.

The key decisions to get right are:

1. Use static IPs. Dynamic IPs make access levels and allowlists unreliable. If your office does not have a static IP, contact your ISP — it is typically a small additional monthly cost and well worth it for the security and operational reliability it enables.
2. Use CIDR notation precisely. A /32 for a single IP, /24 for a class-C subnet. Overly broad ranges (like /8 or /16) defeat the purpose of IP-based restriction by including too many addresses you do not control.
3. Always test in monitor mode before enforcing. Context-Aware Access blocks real users in real time. An unanticipated lockout during business hours costs more in lost productivity and support effort than the time saved by skipping the testing phase.
4. Layer these controls, do not rely on them alone. IP restrictions are one layer. They work best alongside enforced 2-Step Verification, device management policies, and DLP rules. No single control is sufficient on its own.

If you take one action from this guide today, make it this: create a Context-Aware Access level that restricts Admin Console access to your office IP and VPN exit node, run it in monitor mode for a week, and then enforce it. That one change significantly reduces your exposure if a Super Admin credential is ever compromised.

Your Google Workspace environment is only as secure as its weakest access point. With the right IP controls in place, you make that access point a great deal harder to reach.

Need help with your cloud migration? Contact our team for a free consultation.