Start with the forwarding route rather than the Gmail label
A message arriving at Gmail after forwarding has a different delivery history from a message sent there directly. The forwarding service may change the SMTP envelope, preserve or alter the original message, and attach its own authentication observations. Diagnose that history before asking the original sender to change DNS. A successful direct delivery establishes a useful comparison, but it does not prove that the indirect route preserves the same authentication path.
Identify the final account type and the forwarding mechanism. Google's general sender guidelines explicitly address personal Gmail accounts, while an organization's Google Workspace routing can involve additional administrative choices. Record whether the intermediary is an alias service, mailbox rule, gateway or mailing system. Do not apply a rule for one product or route merely because both destinations display a familiar Gmail interface.
Read the provider guidance within its scope
Google's current forwarding guidance recommends using the forwarding domain in the envelope sender, authorizing the forwarding infrastructure in that domain's SPF policy, limiting spam forwarding and avoiding changes that interfere with DKIM. It also says Gmail performs its own authentication checks. Those recommendations do not promise inbox delivery or make a previous server's pass authoritative at Gmail.
Keep that guidance separate from the personal Gmail sender requirements. Requirements vary with sending volume and message purpose. This article is not a substitute for determining which requirements apply to the actual sender. Nor does it propose changing a user's account settings, enabling forwarding or adding an address to any trusted list without the appropriate owner decision.
Follow the envelope and the visible identity separately
At the final SMTP connection, SPF evaluates the relevant identity using the connecting server's address. A forwarder is a new connecting server, which is why preserving the original envelope can change the SPF result. RFC 7208 section 10.3 explains the mediator problem. The message's visible From address is a separate identity and may remain unchanged throughout.
An envelope rewritten under the forwarder's domain can obtain SPF authorization for that domain. It does not, merely by containing the original address in a local part, become aligned with the original Author Domain. Under RFC 9989 section 4.4, DMARC requires a passing authenticated identifier with the required domain relationship. Record the actual domains and alignment mode instead of treating an SPF pass as the whole answer.
For investigation, request the original envelope identity from trusted delivery records where available. A final Return-Path can be useful but does not independently describe every earlier SMTP transaction. Mark unavailable earlier values as unknown rather than reconstructing them from a display name or quoted message text.
Preserve the aligned signature when forwarding permits it
DKIM can survive forwarding when the covered content still verifies. Whether a modification invalidates a signature depends on the signed header fields, body coverage, canonicalization and the actual bytes at verification. RFC 6376 sections 3.4 and 5.4 provide those rules. Do not claim that every added header breaks DKIM or that every message with an unchanged visible body must verify.
Inspect the original signature's signing domain and selector, its listed signed headers and the receiver's verification result. A subject prefix, footer, MIME conversion or attachment transformation may affect covered material. Compare the messages before and after the suspected transformation. Adding a new signature from an unrelated forwarding domain does not repair the original signature or establish alignment for the original author.
A receiver might consider ARC evidence under its own policy. RFC 8617 describes that experimental mechanism; a valid chain is not an automatic DMARC pass or a delivery guarantee. As of this review, the proposal to reclassify ARC remains work in progress. Do not turn a draft proposal into a claim about what Gmail has enabled or disabled.
Fictional comparison of direct and forwarded receipts
Imagine the fictional sender Example Tickets sends one receipt directly to a controlled Gmail mailbox and another equivalent receipt through an alias at example.net. The intended Author Domain is example.com. In this invented scenario, the direct copy has a valid aligned signature, while the forwarded copy retains that signature but acquires a footer that changes its covered body.
Suppose the final envelope is rewritten under example.net and SPF passes for that identity. That hypothetical pass does not align with example.com. The reviewer would next inspect whether any other valid aligned signature survives and what the final receiver reports. The example does not assert a Gmail verdict, an ARC override or an observed rejection; no messages were sent or collected.
The proposed repair question is narrow: can the authorized forwarder preserve the relevant message material while meeting the service's needs? That is more useful than adding the forwarder to the original sender's policy without understanding the identity and authorization consequences.
Retain an evidence package before declaring success
Use consented test accounts and approved, non-sensitive messages. Capture direct and indirect delivery times, route identifiers, envelope observations, full signatures and trusted final authentication results. Record actual disposition separately: SMTP acceptance, mailbox delivery, spam placement and user visibility are not interchangeable outcomes. If an intermediate copy is unavailable, state which transformation cannot be localized.
Evaluate a proposed change against representative formats and routes, not just one plain-text message. Preserve the earlier configuration and define what would trigger recovery. The exact catalogue gate remains open: direct and indirect delivery samples with route, envelope, signatures and trusted results compared. This manuscript contains a fictional exercise and current documentary guidance, not those original samples or a verified Gmail rollout.