A message can leave Gmail through an administrator routing rule, a user's forwarding setting or a filter; a delegate can also read, send and delete mail without being a forwarding destination. Review these paths separately. The useful result is a record of who can change mail flow, who can access messages and which authorized test proves the intended route. [4] [5]
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.
Worked example: distinguish access from an extra message destination
This hypothetical invoice-mailbox review uses synthetic messages and approved recipients. It illustrates the evidence to collect; it does not describe an inspected customer mailbox.
| Illustrative finding | Interpretation to test | Acceptance evidence |
|---|---|---|
| No unexpected administrator routing rule appears. | A user setting or filter could still forward mail. | Review automatic forwarding, forwarding addresses and filters as well as the applied administrator rules. |
| A former assistant is still a delegate. | Delegate access is not the same as an automatic forwarding copy. | Confirm the delegate's current authority and the required read, send and delete access before changing it. |
| Only messages with invoice in the subject reach an outside address. | A filter may explain the selective copy. | Compare a matching synthetic message with a nonmatching message; record the authorized destination and actual result. |
| An approved archive destination receives a copy. | A copy can be legitimate and still need an owner. | Verify the retention purpose, accountable owner and delivery evidence before any removal. |
For each approved change, record the original setting, the affected users or organizational scope, matching and nonmatching test results, and the restoration step. Inspect message contents only when authorized; use the minimum metadata needed for the review.
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.
User forwarding, filters and delegation
Review automatic forwarding and filters in the affected mailbox as well as administrator rules. A filter can forward only a selected subset of messages; a delegate can read, send and delete mail without being an automatic forwarding destination. [4] [5] Record the approved person or destination and the purpose of each access path. Use authorized synthetic messages rather than customer mail to distinguish a matching route from a nonmatching route.
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: Investigate unexplained IPs and sender permissions before changing them. Google supports IP-based authentication for its SMTP relay; distinguish that configured path from a user-password SMTP login. Confirm the device’s supported authentication and TLS behavior, test the approved replacement and a safe rejection case, then close the retired entry through change control. [7]
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.
Use Google’s sender guidelines to review the authentication and delivery requirements that apply to the messages being sent to Gmail. [3] Confirm the sender type and applicable requirements instead of applying a bulk-sender checklist indiscriminately.
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 approved inbound, outbound, internal, alias, group, device and application samples, and capture the metadata available for each path. Email Log Search does not show message contents. For messages older than 30 days, it requires recipient and message ID and supplies post-delivery information rather than delivery status. Use current controlled samples when those limits prevent the needed historical trace. [6]
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.
Related next steps: Plan Gmail routing and delivery changes; Improve Gmail routing after the access review.
Official product documentation and ALLMSP resources
Frequently Asked Questions
Who should be allowed to change Gmail routing settings?
Limit routing changes to named administrators whose role requires the Gmail Settings privilege, and account for super administrators as well as delegated admin roles. Check the effective assignment, not just a job title or a screenshot of one user. Separate the person approving a mail-flow change from the person implementing it where practical. Keep an authorized recovery administrator available before removing access. The review should record who can change the rules today and how a material change will be approved and tested.
What should be checked in Gmail Default routing?
Record the rule's scope, recipient conditions, message types, destination, envelope-recipient changes and whether it rejects, reroutes or adds delivery. Compare the applied Default routing settings with more specialized Routing rules rather than treating either screen as the whole mail path. Use approved matching and nonmatching messages to verify the intended behavior. Do not remove a dual-delivery or migration route until its owner confirms that the destination is no longer required and a restoration plan exists.
Sources: [1]
How can a routing review find hidden message copies or forwarding?
Check administrator Routing, Compliance and delivery settings, then separately review the affected user's automatic forwarding, verified forwarding addresses and filters. Automatic forwarding can apply to new mail except spam; a filter can select only some messages. Also review delegates, who can read, send and delete messages but are not themselves proof of an automatic copy. Trace an authorized synthetic message through the suspected condition, and document the destination and business owner before disabling a route.
What risks should be reviewed in the Gmail SMTP relay service?
Identify which devices or applications use the relay, their allowed sender scope, authorized source IPs, authentication method and TLS setting. Google supports IP-based authentication for the SMTP relay; an IP-authenticated printer is not automatically an unsupported user-password login. Check the actual configured path and vendor capabilities before changing it. Avoid broadly allowing any address or an unexplained network range. Test one approved sender and a safe rejection case, then record who maintains the relay when a device or public IP changes.
Sources: [7]
How should inbound and outbound Gmail gateways be audited?
Document the gateway's purpose, addresses, trusted senders, TLS requirements and failure behavior, including any exceptions that bypass normal checks. Trace approved inbound and outbound samples across the gateway and final mailbox so that an unexpected copy, bypass or rejection has evidence. Compare Gmail's applied rules with the gateway configuration; one side alone may hide the dependency. Confirm archive, filtering and continuity obligations with the owner before removing a gateway or tightening a rule that production mail still uses.
How can an SPF review find forgotten email services?
Start with the authoritative SPF record and an inventory of real senders such as Workspace, an invoicing service or a marketing platform. Explain each include, IP range and mechanism using a current owner and representative message evidence. A DNS entry authorizes a path; it does not prove the service is still used. Check legitimate mail before removing an old include, keep the domain's SPF configuration within Google's documented requirements and verify authentication again after an approved change.
Sources: [2]
What evidence proves DKIM is working for Google Workspace?
A published DKIM key is not enough. Send an approved message from the relevant Workspace domain to an external recipient and inspect the received Authentication-Results for a DKIM pass, together with the signing domain and selector. Compare those values with the intended configuration and DNS record. Test each relevant sending path, because another service may sign with a different domain or not sign at all. Keep the previous selector until the owner has verified the planned transition.
Sources: [8]
What should a DMARC access review prove before enforcement increases?
Show which legitimate senders pass SPF or DKIM with the required alignment to the visible From domain, who receives aggregate reports and which failures remain unexplained. Strict and relaxed alignment differ, so a passing authentication result alone does not settle alignment. Use representative mail and reports before increasing enforcement, with an owner for exceptions and a reversal plan. Do not promote a policy to reject simply because one Workspace test passed while invoices, applications or forwarded mail remain unreviewed.
Sources: [9]
Which messages should be sampled during a Gmail routing review?
Sample approved external inbound, external outbound and internal mail, plus aliases, groups, relay senders and any changed route relevant to the review. Keep message IDs, timestamps, recipients and received headers. Email Log Search does not show message contents. For messages older than 30 days, Google requires recipient and message ID and provides post-delivery information rather than delivery status; do not treat that limited result as a complete historical trace. Use current controlled samples when the needed evidence is unavailable.
Sources: [6]
How often should temporary Gmail routing rules be reviewed?
Give every temporary rule a named owner, purpose, affected scope and review or expiry date when it is created. Revisit it at that date and when its migration, vendor or business dependency changes. Before removal, confirm that the replacement path works with approved matching and nonmatching messages, preserve the old configuration and define a restoration trigger. If the owner or purpose cannot be established, escalate the finding; an unexplained rule needs investigation rather than an untested deletion.
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 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. ↩
- Gmail: delegate and collaborate on email ↩
- Gmail: automatically forward messages to another account ↩
- Google Workspace: find messages with Email Log Search ↩
- Google Workspace: SMTP relay service settings ↩
- Google Workspace: set up and verify DKIM ↩
- Google Workspace: set up DMARC ↩
























































