Model a chain of rules rather than a pair of providers
A mixed-provider forwarding problem is often described as “mail works in one system but not the other.” That description hides the route. The same address can receive mail through an alias, a mailbox rule, a security gateway and another forwarding rule before the final mailbox sees it. Each stage can introduce a different envelope identity, message transformation or local decision.
Build a versioned route inventory before comparing authentication results. Name the original sender, each intermediary and the final receiver; distinguish automatic redirection from a person composing a new forward. Record who owns each rule and which evidence can be obtained. Provider names are useful labels, but the actual rule type, account configuration and processing sequence determine the behavior that needs verification.
Establish a comparison contract for each hop
For every handoff, propose the same evidence fields: observation time, connecting source, envelope sender where known, Author Domain, signatures present, covered content changes and receiving-system results. Include a route identifier so that a direct sample is not confused with a different branch of the indirect path. Preserve both intended configuration and observed behavior because they can disagree.
A provider export or control-panel screenshot describes configuration, not necessarily the transaction that produced a received message. If a service cannot expose the intermediate envelope, mark that field unknown and retain the final receiver's observation. Do not fill gaps by assuming that all rules called forwarding use the same SMTP method.
Use a small, authorized comparison set with representative formats and known recipients. Change only one planned variable at a time when practical. Plain text, multipart mail and messages with attachments can exercise different processing paths. The purpose is to isolate a dependency, not to manufacture a global deliverability percentage from a handful of examples.
Evaluate identities again after every forwarding boundary
The final connecting server can differ from the original sender's server. RFC 7208 section 10.3 explains why that matters for SPF. An intermediary may retain the envelope or replace it; that behavior needs evidence. A later rewrite can replace an earlier rewriting domain, so the final Return-Path alone is not a complete history of all prior identities.
Under RFC 9989 section 4.4, the passing identifier must also align with the Author Domain for ordinary DMARC success. Putting the original address inside a rewritten local part does not create that domain relationship. Nor does a signature from every intermediary necessarily help alignment: each signing domain must be evaluated for its relationship to the author.
Treat surviving original DKIM as a separate path. According to RFC 6376 sections 3.4 and 5.4, verification depends on signed fields and canonicalized covered content. A provider can add an unsigned trace header without necessarily invalidating a signature, while a changed signed subject or covered body can matter. Compare the actual material instead of assigning blame to the last provider in the chain.
Keep provider guidance local to the documented product
Google's forwarding recommendations and Microsoft's SRS description address related problems from different product perspectives. Microsoft's documentation includes route-dependent exceptions. Read each against the exact product and direction of flow, then verify the resulting envelope rather than predicting it from the provider logo.
The same caution applies to receiver assessments. Microsoft's composite authentication explanation describes an additional result distinct from ordinary protocol results. Do not create a universal pass column that treats that value, an ARC chain result and DMARC as equivalent. Keep the original labels and document their meaning where they were produced.
ARC can carry earlier assessments, but RFC 8617 leaves trust and handling to receiver policy. At this review date it remains Experimental; the October 2026 reclassification proposal is an active draft, not an adopted replacement. Cross-provider planning should not depend on an unverified promise that each receiver trusts each intermediary.
Fictional example with two independent failures
Consider a fictional route from example.com through an organizational mailbox at example.net, then an archive service, then a personal mailbox. The intended comparison includes a direct control and one sample from each observable stage. In the invented scenario, the first forward preserves the signed message while the archive service adds a ticket label to a signed Subject field.
Suppose the final envelope belongs to the archive service and its SPF evaluation passes. That result does not by itself align with example.com. The subject change may explain loss of the original aligned DKIM path, but the reviewer would need real before-and-after material to establish it. The proposed change belongs to the archive transformation, not automatically to the first mailbox's DNS.
Separately, the inventory reveals an old rule that could send replies back toward an earlier address. That is a routing risk to review on its own; an authentication pass would not prove loop prevention. No message loop, header change or provider verdict was actually observed for this example.
Preserve operational ownership when rules change
Record the exact rule difference, the service owner, intended destination and evidence needed to accept the change. Review duplicate copies, stale destinations, privacy expectations and failure notifications alongside authentication. A route that authenticates but exposes messages to an unintended mailbox is not a successful migration.
After approved execution, repeat the comparisons and preserve residual unknowns. The catalogue requires direct and indirect delivery samples with route, envelope, signatures and trusted results compared. That gate remains open. This article supplies an original diagnostic framework and fictional route exercise, not live provider tests, approved rule changes or proof of equivalent behavior across services.