What this analysis does
Select the Gmail web workflows you actually use. Mailybox maps each selected dependency to the published January 2027 change and produces a prioritized transition plan without requesting access to a Google account. It is designed for individuals and teams that need to inventory impact before the removal date.
The planner inventories workflows that depend on Gmail’s changing third-party account support. It does not connect to Google or guess from an address; the result is based only on the dependencies selected by the user.
Inventory workflows before choosing a replacement
Separate reading mail from another provider, presenting another From identity and sending through an external SMTP service. These workflows can look like one account in the Gmail interface while relying on different protocols, credentials and DNS identities.
Record the mailbox owner, provider, domains, forwarding rules, client applications and business processes attached to each workflow. A replacement is safe only when it preserves the required receiving, sending and reply behavior.
- Identify every account and alias used in Gmail web.
- List devices and applications that already use IMAP or provider apps.
- Capture SPF, DKIM and DMARC evidence for each sending route.
Choose the migration path by function
Provider forwarding, a provider-native application, a standards-based mail client or a controlled mailbox migration solve different problems. Do not treat forwarding as a complete replacement when users must send with the original identity, retain server-side folders or preserve provider-specific controls.
For outbound mail, verify who operates the SMTP path and which domains authenticate. Moving a user interface without updating sender authentication can preserve the same delivery failure under a new workflow.
Discover application and SMTP dependencies before migrationRead the detailed Gmail 2027 field guide
Retest the complete path before the deadline
Pilot with a low-risk account, then test inbound delivery, replies, sent-item behavior, aliases, authentication results and recovery procedures. Keep the old path available until the replacement has produced real message evidence and the owner has accepted the workflow.
Google can clarify or revise product-transition details. Recheck the linked primary notice before final cutover and record the date used for the migration decision.
Example: one Gmail view hides two dependencies
Evidence supplied
A user reads a provider mailbox in Gmail web and also sends as that address through the provider SMTP service.
How to read the result
The plan records receiving and sending as separate dependencies, then requires authentication and reply testing for the replacement path instead of treating one forwarding rule as complete migration.
Known limits
- The planner does not inspect a Google account or confirm which settings are enabled.
- It does not migrate messages, credentials or DNS records.
- Product-transition scope should be rechecked against Google’s current notice before cutover.
Common questions
Does the planner connect to Gmail?
No. It builds a plan from the workflow selections supplied by the user.
Is forwarding always a complete replacement?
No. It may cover inbound delivery while leaving sending identity, folders, replies or compliance requirements unresolved.
When should testing begin?
Begin with enough time for a pilot, DNS changes and user acceptance before January 2027 rather than waiting for the final weeks.