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. Where the setting supports it, test a child organizational unit or tightly restricted recipient condition before broad rollout. Some Gmail settings apply organization-wide, so confirm the supported scope before saving a change. [4]
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.
Choose the mail setting from the delivery problem
Use this as a planning aid, then check the setting's supported scope and the rules already in place. [4] [5] [8]
On a narrow screen, scroll the table horizontally to read every column.
| Business situation | Starting point | Important limit |
|---|---|---|
| Most mail must reach Gmail and a legacy server during migration | Default routing / dual delivery design | Document the migration end date and test loops and duplicate copies. |
| A specific recipient needs an additional approved destination | A narrowly scoped Routing rule | Test account status, matching conditions and other applicable rules. |
| A scanner must send company mail | SMTP relay or another supported device option | Choose authentication, allowed senders and TLS from device capabilities. |
| Mail was accepted but the user cannot find it | Email Log Search plus recipient-side investigation | Delivery status is different from inbox placement. |
Choose the next step
- Audit Gmail Routing Rules, Delegation, and Forwarding — Review inherited rules, delegation and forwarding before adding another route.
- Fix Gmail Routing, Authentication, and Delivery Failures — Use the troubleshooting guide when authentication or delivery tests fail.
Frequently Asked Questions
What should be inventoried before Gmail routing rules are created?
Inventory every receiving address and every place mail can go: users, aliases, Groups, shared inbox arrangements, secondary domains, gateways, legacy servers and catch-all destinations. Include application senders and the person responsible for each route. For example, document whether invoices@ is a user alias or a Group; those choices have different delivery and access behavior.
Supporting sources: [4]
How do we find all systems that send email as our domain?
Start with DNS and message evidence, then ask departments about their tools. Compare SPF entries and received headers with the website, CRM, invoicing platform, marketing service, scanners and password-reset systems. Record both the visible From address and the envelope sender. An SPF include alone does not identify the employee who owns the service, and a low-volume invoice sender still belongs in the register.
Supporting sources: [2]
When should we use Gmail Default routing instead of Routing?
Use Default routing for the organization's baseline delivery pattern, such as delivering most mail to two systems during a migration. Use Routing for exceptions, such as copying one executive's incoming mail to an assistant. Routing settings can override default behavior and interact with other rules. Also check account status: ordinary Routing rules do not apply to suspended users or users with Gmail turned off.
Supporting sources: [4]
How can a Gmail routing rule be tested without affecting everyone?
For a Routing setting that supports organizational-unit scope, start in a child unit containing test users and narrow the envelope sender or recipient conditions. Send a matching message and a control message, then trace both. Do not assume every Gmail setting can be isolated the same way: relay and other organization-wide settings need their own restricted test design. Allow for settings propagation before judging the result.
Supporting sources: [4]
Which Gmail SMTP option should a printer or business application use?
Use Google's recommended SMTP relay when the device and network can meet its allowed-sender, authentication and TLS requirements. A device that supports modern account authentication may use Gmail SMTP; the restricted server is for delivery to Gmail or Workspace recipients only. Do not configure ordinary account-password authentication as a fallback. Check the device's actual capabilities and Google's current setup instructions before choosing ports or credentials.
Supporting sources: [5]
What is the safest way to update SPF for Google Workspace and third-party senders?
Edit the domain's existing SPF record rather than adding a second SPF record. Assemble Google's entry and the approved third-party senders into one policy, check DNS lookup limits, then test messages from each sender. SPF checks the envelope domain, which can differ from the visible From address. Keep a known legitimate sender until traffic and its owner confirm retirement; removing an unfamiliar include can break invoices or password resets.
How do we confirm Gmail is actually signing messages with DKIM?
Send a new message from the actual Workspace domain to an external mailbox and inspect the received original headers. Look for a passing DKIM result and a signature whose d= domain is the intended company domain. Publishing the selector's DNS record is only part of setup; signing must also be active in Google Admin. Test after any gateway that modifies messages, because it can invalidate the signature.
Supporting sources: [7]
Should a business set DMARC to reject immediately?
Usually, establish legitimate sender coverage and study DMARC reports before switching to reject. Confirm that each approved platform passes aligned SPF or DKIM for the visible From domain, then move to enforcement under a planned change. A policy of none gathers evidence but does not instruct receivers to reject failing mail. Do not weaken an existing working reject policy just to repeat the initial rollout process.
Supporting sources: [6]
What information should support collect before using Email Log Search?
Collect the sender, exact recipient, approximate send time and time zone, Message-ID, bounce response and a received original header if available. Ask whether the message is missing, delayed, quarantined or unexpectedly forwarded; these lead to different investigations. Email Log Search can show Google's delivery path, but an external server accepting a message does not prove it reached the recipient's inbox. Older messages also have reduced delivery detail.
Supporting sources: [8]
What documentation is needed for a safe Gmail routing change?
Keep the previous rule values, scope, business reason, approver, change time and rollback steps in the change record. Add a small test matrix covering normal mail, the intended exception and a nonmatching control. Save message IDs and results, then name who can reverse the change. Temporary coexistence or forwarding rules need an expiry review so that a migration exception does not quietly become permanent.
Supporting sources: [4]
Related ALLMSP Resources
Sources
- 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. ↩
- Add Gmail routing settings. Routing versus Default routing, active-user scope, child organizational units, message directions and envelope filters. ↩
- Send email from a printer, scanner, or app. Supported SMTP relay, Gmail SMTP and restricted server choices; authentication requirements for devices. ↩
- Set up DMARC. Authenticate legitimate senders and review alignment before enforcing a DMARC policy. ↩
- Set up DKIM. Publish the public key, activate signing and inspect received-message authentication results. ↩
- Troubleshoot message delivery with Email Log Search. Delivery versus post-delivery investigation and limits on older message records. ↩
