A Gmail routing review should answer three questions with evidence: who can change mail flow, which rules can redirect or copy messages, and whether legitimate senders can prove they are authorized. The review is not complete when the settings merely look familiar. It is complete when each rule has an owner, a current purpose, a tested result, and a safe removal path.
Do not delete a routing rule, gateway, DKIM selector, SPF include, or DMARC reporting destination while it may still support production mail. Capture the current state, identify affected message paths, and test replacement behavior before removing access or configuration.
ALLMSP provides Gmail mail routing and delivery support for Lawrenceville and Suwanee businesses, the wider Gwinnett County and Metro Atlanta area, and organizations across Georgia, with practical coordination across managed IT, cybersecurity, software support, backup, and employee operations.
Evidence to collect before changing Gmail routing
A useful review package contains exported or captured settings, named administrators, sender authentication evidence, representative message traces, unresolved findings, owners, and due dates. It should let management distinguish a security issue from a reliability issue and a documentation gap.
- Current Gmail Settings administrators, super administrators, and relevant custom roles.
- Default routing, Routing, SMTP relay, inbound gateway, outbound gateway, compliance, and quarantine settings.
- SPF, DKIM, and DMARC records for every active sending domain.
- A sender register covering Google Workspace, websites, marketing tools, printers, scanners, and business applications.
- Email Log Search traces and full headers for representative inbound and outbound messages.
- Open delivery incidents, user workarounds, temporary rules, and vendor dependencies.
Confirm who can change Gmail mail flow
Gmail Settings administrator authority
What to check: List every super administrator and every account with the Gmail Settings privilege. Record the person's current job, need for access, 2-Step Verification status, and last successful sign-in test.
What to do next: Remove stale accounts only after a tested replacement exists. Replace broad roles with a narrower custom or delegated role when the person only manages Gmail settings.
Default routing rules
What to check: Capture each rule's recipient condition, route, envelope change, spam behavior, delivery option, organizational scope, description, and last modification. Identify dual delivery or legacy coexistence rules that may have outlived a migration.
What to do next: Test the replacement path and narrow or retire the rule through change control. Keep a screenshot or export of the previous state until post-change delivery has been proven.
Specialized Routing and compliance rules
What to check: Record triggers, message direction, sender and recipient patterns, headers, content matches, added recipients, rejected messages, quarantines, and organizational unit scope. Note rules that can copy mail outside the intended mailbox.
What to do next: Assign a business owner and retention reason. Remove broad patterns, undocumented forwarding, or obsolete compliance actions after controlled matching and nonmatching tests.
Inspect every active routing and gateway path
SMTP relay and device senders
What to check: Capture allowed senders, IP restrictions, authentication requirements, TLS settings, envelope behavior, and device or application owners. Compare listed IPs with current public addresses and firewall rules.
What to do next: Remove unknown IPs, move devices to supported authentication, require TLS where possible, and retest every critical notification path before closing the old relay entry.
Inbound and outbound gateways
What to check: Document gateway addresses, trusted IP ranges, TLS requirements, header tags, spam treatment, routing destinations, and the contract or system that owns the gateway. Confirm whether MX records point directly to Google or through another service.
What to do next: Correct stale IPs and weak trust settings with the gateway owner. Test inbound and outbound messages through the complete path before changing MX, TLS, or rejection behavior.
SPF authorization
What to check: Record the single SPF record, all includes and IP entries, lookup count, unused services, and pass result for Google Workspace and major third-party senders. Identify services that send with the domain but are absent from SPF.
What to do next: Add legitimate missing sources, remove confirmed retired sources, consolidate duplicate SPF records, and retest external delivery after DNS propagation.
DKIM signing
What to check: Capture each sending domain, active selector, key length, DNS record, Admin console authentication status, and external message header result. Note third-party platforms that use their own DKIM selectors.
What to do next: Generate or rotate a supported key, publish it, start authentication, and prove an external message passes before removing the previous selector.
Validate authentication and delivery evidence
DMARC alignment and reporting
What to check: Record policy, percentage, reporting addresses, subdomain policy, alignment modes, known legitimate failures, and unknown sources. Compare SPF and DKIM domains with the visible From domain.
What to do next: Correct alignment for legitimate senders, investigate unknown sources, and advance enforcement only when reporting shows the business can do so without blocking required mail.
Delivery troubleshooting evidence
What to check: Trace representative inbound, outbound, internal, alias, Group, device, and application messages. Record Google transit time, delivery status, post-delivery status, route, rejection reason, and message ID.
What to do next: Open a corrective ticket for every unexplained delay, rejection, or route. Assign the issue to Google Workspace, the sending system, DNS, a gateway, or the receiving domain based on the trace.
Temporary rules and support ownership
What to check: Find rules marked temporary, migration, test, legacy, exception, journal, archive, or forward. Confirm the current owner, original approval, expiration condition, rollback steps, and whether support knows how to identify a related incident.
What to do next: Give each necessary exception an owner and review date. Retire abandoned rules through a tested change, then update the support procedure and sender inventory.
Rank findings by business and security impact
Rank a finding by what can happen if it remains, not by how easy the setting is to change. Mail loss, unauthorized forwarding, domain impersonation, and administrator lockout deserve immediate ownership. Documentation and naming issues can follow after the production risk is controlled.
Priority 1: Active security or mail-loss risk
Use this level for unknown forwarding, open relay exposure, unauthorized administrators, broken authentication on important senders, rejected business mail, or a gateway that can no longer be supported. Assign an owner immediately and preserve evidence before making changes.
Priority 2: Fragile delivery or recovery
Use this level when mail works but depends on one administrator, one undocumented DNS account, one personal mailbox, an expiring vendor, a temporary migration rule, or a device that cannot use a supported authentication method.
Priority 3: Control and documentation weakness
Use this level for unclear descriptions, missing review dates, inconsistent naming, incomplete sender records, or tests that cannot be reproduced. Correct these items so the next production issue can be resolved faster.
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 audit Gmail routing rules, delegation, and forwarding.
- 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 audit Gmail routing rules, delegation, and forwarding.
- 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 audit Gmail routing rules, delegation, and forwarding.
Frequently Asked Questions
Who should be allowed to change Gmail routing settings?
Review the following systems and records: Admin console > Account > Admin roles and assigned administrators. List every super administrator and every account with the Gmail Settings privilege. Record the person's current job, need for access, 2-Step Verification status, and last successful sign-in test. If evidence is incomplete or a control fails, remove stale accounts only after a tested replacement exists. Replace broad roles with a narrower custom or delegated role when the person only manages Gmail settings. Retest and document closure.
What should be checked in Gmail Default routing?
Review the following systems and records: Admin console > Apps > Google Workspace > Gmail > Default routing. Capture each rule's recipient condition, route, envelope change, spam behavior, delivery option, organizational scope, description, and last modification. Identify dual delivery or legacy coexistence rules that may have outlived a migration. If evidence is incomplete or a control fails, test the replacement path and narrow or retire the rule through change control. Keep a screenshot or export of the previous state until post-change delivery has been proven. Retest and document closure.
How can a routing review find hidden message copies or forwarding?
Review the following systems and records: Admin console > Apps > Google Workspace > Gmail > Routing, Compliance, and Safety settings. Record triggers, message direction, sender and recipient patterns, headers, content matches, added recipients, rejected messages, quarantines, and organizational unit scope. Note rules that can copy mail outside the intended mailbox. If evidence is incomplete or a control fails, assign a business owner and retention reason. Remove broad patterns, undocumented forwarding, or obsolete compliance actions after controlled matching and nonmatching tests. Retest and document closure.
What risks should be reviewed in the Gmail SMTP relay service?
Review the following systems and records: Admin console > Apps > Google Workspace > Gmail > Routing > SMTP relay service. Capture allowed senders, IP restrictions, authentication requirements, TLS settings, envelope behavior, and device or application owners. Compare listed IPs with current public addresses and firewall rules. If evidence is incomplete or a control fails, remove unknown IPs, move devices to supported authentication, require TLS where possible, and retest every critical notification path before closing the old relay entry. Retest and document closure.
How should inbound and outbound Gmail gateways be audited?
Review the following systems and records: Admin console > Apps > Google Workspace > Gmail > Spam, Phishing and Malware, and Routing. Document gateway addresses, trusted IP ranges, TLS requirements, header tags, spam treatment, routing destinations, and the contract or system that owns the gateway. Confirm whether MX records point directly to Google or through another service. If evidence is incomplete or a control fails, correct stale IPs and weak trust settings with the gateway owner. Test inbound and outbound messages through the complete path before changing MX, TLS, or rejection behavior. Retest and document closure.
How can an SPF review find forgotten email services?
Review the following systems and records: Authoritative DNS and full headers from each approved sending source. Record the single SPF record, all includes and IP entries, lookup count, unused services, and pass result for Google Workspace and major third-party senders. Identify services that send with the domain but are absent from SPF. If evidence is incomplete or a control fails, add legitimate missing sources, remove confirmed retired sources, consolidate duplicate SPF records, and retest external delivery after DNS propagation. Retest and document closure.
What evidence proves DKIM is working for Google Workspace?
Review the following systems and records: Admin console > Apps > Google Workspace > Gmail > Authenticate email and authoritative DNS. Capture each sending domain, active selector, key length, DNS record, Admin console authentication status, and external message header result. Note third-party platforms that use their own DKIM selectors. If evidence is incomplete or a control fails, generate or rotate a supported key, publish it, start authentication, and prove an external message passes before removing the previous selector. Retest and document closure.
What should a DMARC access review prove before enforcement increases?
Review the following systems and records: Authoritative DNS, aggregate reporting destination, and representative message headers. Record policy, percentage, reporting addresses, subdomain policy, alignment modes, known legitimate failures, and unknown sources. Compare SPF and DKIM domains with the visible From domain. If evidence is incomplete or a control fails, correct alignment for legitimate senders, investigate unknown sources, and advance enforcement only when reporting shows the business can do so without blocking required mail. Retest and document closure.
Which messages should be sampled during a Gmail routing review?
Review the following systems and records: Admin console > Reporting > Email Log Search, user mailbox, quarantine, and full message headers. Trace representative inbound, outbound, internal, alias, Group, device, and application messages. Record Google transit time, delivery status, post-delivery status, route, rejection reason, and message ID. If evidence is incomplete or a control fails, open a corrective ticket for every unexplained delay, rejection, or route. Assign the issue to Google Workspace, the sending system, DNS, a gateway, or the receiving domain based on the trace. Retest and document closure.
How often should temporary Gmail routing rules be reviewed?
Review the following systems and records: Google Admin rule descriptions, change tickets, vendor records, and support documentation. Find rules marked temporary, migration, test, legacy, exception, journal, archive, or forward. Confirm the current owner, original approval, expiration condition, rollback steps, and whether support knows how to identify a related incident. If evidence is incomplete or a control fails, give each necessary exception an owner and review date. Retire abandoned rules through a tested change, then update the support procedure and sender inventory. Retest and document closure.
