Gmail routing determines where a message goes after it reaches Google Workspace and what happens before delivery. A safe design begins with a complete list of domains, aliases, applications, scanners, marketing systems, gateways, journals, and legal or compliance requirements. The objective is not to create the most rules. It is to create the fewest rules that produce a documented business outcome.
Treat mail flow as production infrastructure. Before changing Default routing, Routing, SMTP relay, inbound gateways, outbound gateways, content compliance, or attachment compliance, capture the existing settings and identify a rollback owner. Test a narrow organizational unit or controlled recipient group before applying a rule to the entire domain.
ALLMSP coordinates Gmail deployment and configuration from Lawrenceville for clients in Suwanee, across Gwinnett County and Metro Atlanta, and throughout Georgia, through one accountable in-house workflow from discovery and correction through testing, training, and ongoing support.
What a dependable Gmail routing setup should accomplish
A dependable Gmail routing setup lets the business explain how normal mail, application mail, printer mail, aliases, forwarded messages, quarantined content, and undeliverable recipients are handled. It also gives support staff enough evidence to trace a message without guessing.
- Primary domains, secondary domains, domain aliases, user aliases, and Google Groups are documented.
- Every system that sends as the company domain is recorded with its owner and authentication method.
- Default routing handles the broad delivery pattern while specialized Routing rules have narrow conditions.
- SPF, DKIM, and DMARC cover Google Workspace and all approved third-party senders.
- Printers and applications use a supported SMTP option with known sending limits and ownership.
- Real inbound, outbound, internal, alias, application, and failure tests have been traced in Email Log Search.
Map the mail system before creating rules
1. Inventory domains and recipient types
Record the primary domain, secondary domains, domain aliases, user aliases, Groups addresses, catch-all behavior, suspended recipients, and any legacy server that still receives mail. Add the business owner and technical owner for each recipient type so a delivery decision can be approved by the right person.
Where to work: Admin console > Account > Domains, then Directory > Users and Directory > Groups
Verification: Send one message to a normal user, an alias, a Group, and a deliberately invalid recipient. Document the expected and actual result for each address.
2. List every approved sender
Create a sender register with the service name, envelope sender, visible From domain, sending IP or vendor include, authentication method, volume, message purpose, and support owner. Include systems that send only a few messages because password resets and invoice notifications can be business critical.
Where to work: Company application inventory, DNS records, website forms, marketing platforms, scanners, printers, and finance systems
Verification: Compare the register with SPF includes, recent message headers, Email Log Search, vendor invoices, and website form settings. Resolve every sender that appears in evidence but has no owner.
3. Choose Default routing or a specialized rule
Use Default routing for the organization-wide delivery pattern, such as dual delivery during a migration. Use Routing for narrower cases based on sender, recipient, organizational unit, group membership, message direction, envelope, headers, or content. Write the business reason and expiration condition into the rule description.
Where to work: Admin console > Apps > Google Workspace > Gmail > Default routing and Routing
Verification: A reviewer who did not build the rule should be able to explain its trigger, action, affected users, and rollback step from the saved documentation.
Configure routing and authenticated sending
1. Design rule order and scope
Identify rules that can apply to the same message and document the expected combined behavior. Scope early tests to a controlled organizational unit or group. Avoid broad regular expressions when an exact address, domain, group, or message direction can express the requirement more safely.
Where to work: The specific Gmail setting page where each routing or compliance rule is configured
Verification: Run matching and nonmatching test messages. The intended message should change while the control message should remain untouched.
2. Configure supported application and device mail
Choose SMTP relay, authenticated Gmail SMTP, or restricted SMTP according to the device capability, recipient scope, volume, and security requirement. Prefer OAuth where supported. Restrict relay by authenticated account or known public IP and require TLS when the sending system supports it.
Where to work: Admin console > Apps > Google Workspace > Gmail > Routing > SMTP relay service, plus the sending device or application
Verification: Send a device or application message to internal and approved external recipients. Confirm the sender identity, TLS result, authentication result, and delivery status in the received header and Email Log Search.
3. Publish SPF for all approved sources
Maintain one SPF TXT record per domain and include every approved service that sends with that domain. Remove retired sources only after mail evidence confirms they are no longer active. Keep the SPF evaluation within the supported lookup limit and do not create several competing SPF records.
Where to work: The authoritative DNS provider for each sending domain
Verification: Send from Google Workspace and each major third-party sender to an external mailbox. In the full header, confirm SPF passes for the correct envelope domain.
4. Enable and verify DKIM signing
Generate a 2048-bit DKIM key when the DNS provider supports it, publish the selector record, wait for DNS availability, and start authentication in the Admin console. Repeat the process for every Google Workspace sending domain that needs its own signature.
Where to work: Admin console > Apps > Google Workspace > Gmail > Authenticate email, then the domain DNS provider
Verification: Send to an external Gmail or Google Workspace account, open Show original, and confirm DKIM passes for the expected domain and selector.
Prepare support and recovery procedures
1. Introduce DMARC with reporting
Publish a DMARC record with a monitored reporting address and begin with a policy that lets the team study alignment before enforcement. Identify every legitimate source that fails alignment, correct it, then move toward quarantine or reject based on evidence and business approval.
Where to work: The authoritative DNS provider and the mailbox or service that receives aggregate reports
Verification: Review aggregate data for Google Workspace, marketing platforms, applications, and unknown senders. Confirm the visible From domain aligns with SPF or DKIM for legitimate traffic.
2. Prepare Email Log Search procedures
Document how support will search by sender, recipient, message ID, date range, and direction. Record what delivered, rejected, quarantined, rerouted, forwarded, or delayed statuses mean for the company and when a vendor or receiving domain must be contacted.
Where to work: Admin console > Reporting > Email Log Search
Verification: Give support a test message ID and ask them to trace the message without verbal coaching. Correct the procedure wherever they have to guess.
3. Record rollback and change ownership
Save the previous rule configuration, test recipients, expected results, change window, approver, implementer, and rollback decision point. Add a review date for temporary migration, forwarding, compliance, or coexistence rules so they do not become permanent by accident.
Where to work: The company change ticket, documentation platform, and Google Admin audit records
Verification: A second administrator can identify the last known good state and restore it without relying on the original implementer’s memory.
Run delivery tests before the change is complete
Use controlled messages that represent the actual ways the business sends and receives mail. A single successful message does not prove a routing design. Save the message ID and full header for every test so later troubleshooting has a known baseline.
- Normal inbound delivery: Send from an unrelated external domain to a licensed user and trace the message. Pass: The message reaches the expected mailbox with the intended spam and routing treatment.
- Normal outbound delivery: Send from a Workspace user to two unrelated external providers. Pass: SPF or DKIM passes, DMARC aligns, and the message is not unexpectedly rerouted.
- Alias and Group delivery: Send to each supported alias and representative Group configuration. Pass: Recipients match the documented membership and posting policy.
- Application or device delivery: Trigger a real scanner, website form, accounting alert, or line-of-business notification. Pass: The message uses the approved sender, authenticates as designed, and arrives with readable content.
- Rule exception: Send one message that matches a routing rule and one that is intentionally outside its scope. Pass: Only the matching message receives the configured action.
- Failure and rollback: Use a controlled invalid recipient or disabled test rule, then follow the rollback procedure. Pass: Support finds the failure evidence and restores the expected state within the approved window.
Official product documentation and ALLMSP resources
- Gmail routing and delivery options for Google Workspace. Official guidance for default routing, specialized routing, dual delivery, recipient changes, compliance, and secure delivery, with the planning steps on this page applying it to the work needed to configure Gmail routing without breaking business mail.
- Set up SPF for Google Workspace. Official steps for authorizing mail sources and coordinating SPF with DKIM and DMARC authentication, with the configuration checks here applied to the controls needed to configure Gmail routing without breaking business mail.
- Gmail email sender guidelines. Current Google requirements and recommendations for authentication, delivery, subscription messages, and sending practices, with the review process on this page using that guidance to help the organization configure Gmail routing without breaking business mail.
Frequently Asked Questions
What should be inventoried before Gmail routing rules are created?
Relevant systems and records include Admin console > Account > Domains, then Directory > Users and Directory > Groups. Record the primary domain, secondary domains, domain aliases, user aliases, Groups addresses, catch-all behavior, suspended recipients, and any legacy server that still receives mail. Add the business owner and technical owner for each recipient type so a delivery decision can be approved by the right person. Verify completion by confirming that send one message to a normal user, an alias, a Group, and a deliberately invalid recipient. Document the expected and actual result for each address.
How do we find all systems that send email as our domain?
Relevant systems and records include Company application inventory, DNS records, website forms, marketing platforms, scanners, printers, and finance systems. Create a sender register with the service name, envelope sender, visible From domain, sending IP or vendor include, authentication method, volume, message purpose, and support owner. Include systems that send only a few messages because password resets and invoice notifications can be business critical. Verify completion by confirming that compare the register with SPF includes, recent message headers, Email Log Search, vendor invoices, and website form settings. Resolve every sender that appears in evidence but has no owner.
When should we use Gmail Default routing instead of Routing?
Relevant systems and records include Admin console > Apps > Google Workspace > Gmail > Default routing and Routing. Use Default routing for the organization-wide delivery pattern, such as dual delivery during a migration. Use Routing for narrower cases based on sender, recipient, organizational unit, group membership, message direction, envelope, headers, or content. Write the business reason and expiration condition into the rule description. Verify completion by confirming that a reviewer who did not build the rule should be able to explain its trigger, action, affected users, and rollback step from the saved documentation.
How can a Gmail routing rule be tested without affecting everyone?
Relevant systems and records include The specific Gmail setting page where each routing or compliance rule is configured. Identify rules that can apply to the same message and document the expected combined behavior. Scope early tests to a controlled organizational unit or group. Avoid broad regular expressions when an exact address, domain, group, or message direction can express the requirement more safely. Verify completion by confirming that run matching and nonmatching test messages. The intended message should change while the control message should remain untouched.
Which Gmail SMTP option should a printer or business application use?
Relevant systems and records include Admin console > Apps > Google Workspace > Gmail > Routing > SMTP relay service, plus the sending device or application. Choose SMTP relay, authenticated Gmail SMTP, or restricted SMTP according to the device capability, recipient scope, volume, and security requirement. Prefer OAuth where supported. Restrict relay by authenticated account or known public IP and require TLS when the sending system supports it. Verify completion by confirming that send a device or application message to internal and approved external recipients. Confirm the sender identity, TLS result, authentication result, and delivery status in the received header and Email Log Search.
What is the safest way to update SPF for Google Workspace and third-party senders?
Relevant systems and records include The authoritative DNS provider for each sending domain. Maintain one SPF TXT record per domain and include every approved service that sends with that domain. Remove retired sources only after mail evidence confirms they are no longer active. Keep the SPF evaluation within the supported lookup limit and do not create several competing SPF records. Verify completion by confirming that send from Google Workspace and each major third-party sender to an external mailbox. In the full header, confirm SPF passes for the correct envelope domain.
How do we confirm Gmail is actually signing messages with DKIM?
Relevant systems and records include Admin console > Apps > Google Workspace > Gmail > Authenticate email, then the domain DNS provider. Generate a 2048-bit DKIM key when the DNS provider supports it, publish the selector record, wait for DNS availability, and start authentication in the Admin console. Repeat the process for every Google Workspace sending domain that needs its own signature. Verify completion by confirming that send to an external Gmail or Google Workspace account, open Show original, and confirm DKIM passes for the expected domain and selector.
Should a business set DMARC to reject immediately?
Relevant systems and records include The authoritative DNS provider and the mailbox or service that receives aggregate reports. Publish a DMARC record with a monitored reporting address and begin with a policy that lets the team study alignment before enforcement. Identify every legitimate source that fails alignment, correct it, then move toward quarantine or reject based on evidence and business approval. Verify completion by confirming that review aggregate data for Google Workspace, marketing platforms, applications, and unknown senders. Confirm the visible From domain aligns with SPF or DKIM for legitimate traffic.
What information should support collect before using Email Log Search?
Relevant systems and records include Admin console > Reporting > Email Log Search. Document how support will search by sender, recipient, message ID, date range, and direction. Record what delivered, rejected, quarantined, rerouted, forwarded, or delayed statuses mean for the company and when a vendor or receiving domain must be contacted. Verify completion by confirming that give support a test message ID and ask them to trace the message without verbal coaching. Correct the procedure wherever they have to guess.
What documentation is needed for a safe Gmail routing change?
Relevant systems and records include The company change ticket, documentation platform, and Google Admin audit records. Save the previous rule configuration, test recipients, expected results, change window, approver, implementer, and rollback decision point. Add a review date for temporary migration, forwarding, compliance, or coexistence rules so they do not become permanent by accident. Verify completion by confirming that a second administrator can identify the last known good state and restore it without relying on the original implementer's memory.
