As a Gmail admin, you can create rules to manage spam, email content, and email attachments for your organization. You might need new rules when you add a Google Workspace service or when you’re setting up Gmail security. Follow these best practices to minimize the time it takes to test new and changed rules.
Before you begin
- When creating rules, you usually have to change and test them several times to make sure they work correctly for your organization.
- We recommend trying out new rules in a test environment (see recommendations for your test environment below on this page).
- More rules increase the test time.
- Changes can take up to 24 hours but typically happen more quickly. Learn more
How organization size & structure affects rules
- Rules for lots of users or large organizational units take longer to update.
- Rules for an organizational unit also apply to its child organizational units. Therefore, organizational units with a lot of children can take longer to update.
Best practices for your test environment
| Recommendation | Description |
|---|---|
| Create a test environment with a few users. | A small test environment lets you quickly update rules and verify how they affect email flow and delivery. The size of the environment where the rule is used directly affects how long it takes for the rule to update. |
| Use a recommended test environment. |
Use one of these types of test environments:
|
| Set up the test domain just like your primary domain. | If you use a secondary test domain, set it up like your primary domain so that rules behave as they would in your primary domain. |
| Remove any unused rules from the test environment. | Add only the rules you’re testing to the test environment. If you tested rules in this environment in the past, remove old rules before adding and testing new ones. |
Best practices for creating & testing rules
| Recommendation | Description |
|---|---|
| Test rules with real data. | Test the same type of email attachments and content (including secure content) that you normally use in your organization. |
| Avoid long strings or long lists. | To save time and possible troubleshooting, avoid using expressions with more than 1,000 characters and lists with more than 1,000 elements. |
| Check the rule syntax before testing. | To get test results similar to what you'll get in your organization, check the rule syntax with real data. You can test your rule first in the Google Admin console. You can also test your data with predefined classifiers that trigger rules. Learn more about testing data using the Cloud Data Loss Prevention API. |
| Test on a parent organizational unit. |
It’s better to test on a parent organizational unit rather than a child. As with nested groups, it’s difficult to isolate and identify the rule causing an issue with a child organizational unit. However, if you need to test how a new rule interacts with existing rules, copy the new rule into a test organizational unit that is a child of the organizational unit that uses the existing rules. Learn how multiple rules affect message behavior. |
| Avoid testing rules with groups. |
The rule update time corresponds to group size (number of members) and it can be difficult to determine a group’s size. Also, it’s more complex to test rules with nested groups. When you add a new rule, for Account types to affect, uncheck the Groups box. |
| Use a unique subject line for each message used to test a rule. | Unique subject lines help you identify which rules have been applied to test messages. Email Log Search lists messages by subject line. Each message entry indicates which rule was applied to the message. |
| Change the rule name every time you update a rule. | Email Log Search shows rules by name. When updating and testing a rule several times, a unique rule name helps you know which version of the rule you’re testing. |
Best practices for verifying rules
Use Email Log Search to check which rules have been applied to test messages. For details, go to Find messages with Email Log Search.