Is forwarding emails originating from Gmail through Salesforce Marketing Cloud considered Gmail impersonation?

Key findings

• External impersonation: Sending emails to external recipients with a from an unauthorized server is considered impersonation and will likely lead to delivery issues. Gmail’s updated guidelines specifically aim to prevent this.
• Internal forwarding: Forwarding replies from Gmail users through a system like Salesforce Marketing Cloud (SFMC) to an internal Service Cloud system is generally acceptable, provided the internal system is not performing stringent DMARC checks on inbound mail.
• DMARC implications: If the `From:` header retains the original address during forwarding, SPF will likely break. If the receiving internal system performs DMARC checks, it could lead to DMARC failures, especially with Gmail's DMARC policy. This might not be impersonation but a technical authentication failure.
• SFMC’s default behavior: By default, SFMC’s Reply Mail Management often rewrites the `From:` address to avoid perceived impersonation, appending to the original sender's address.

Key considerations

• Service cloud handling: The crucial factor is how Salesforce Service Cloud's inbound email system processes and interprets the `From:` header of these forwarded emails. Its internal DMARC verification settings are key.
• DMARC policy impact: A stricter DMARC policy from Gmail could impact internal email deliverability when using email forwarding, leading to messages being quarantined or rejected by the receiving system if authentication fails.
• Authentication testing: Testing the full email flow by sending a reply from a Gmail address and inspecting the email headers for DMARC pass or fail results is highly recommended to assess compliance.
• System requirements: If Service Cloud requires the exact original `From:` address, it suggests a configuration that prioritizes internal process integrity over external DMARC compliance for forwarded internal messages.
• Email deliverability: Understanding email deliverability issues and how authentication protocols like DMARC work is crucial for preventing even internal delivery problems, as detailed in this Salesforce email deliverability guide.

Key opinions

• Operational priority: Many marketers prioritize the smooth functioning of internal systems, such as Service Cloud requiring the original Gmail address to open cases, even if it means deactivating default SFMC `From:` address rewriting.
• Current system efficacy: If the current forwarding process has been working without issue for an extended period, marketers tend to believe it is compliant or at least not causing immediate problems.
• Focus on outbound: The main concern for impersonation is often placed on initial outbound sends, with less emphasis on the `From:` header integrity for internally forwarded replies, especially if the receiving system is permissive.
• Uncertainty on guidelines: There can be uncertainty among marketers regarding how specific new guidelines (like Google’s “Don’t impersonate Gmail”) apply to complex internal email flows versus external sends.

Key considerations

• Risk assessment: Even if current processes work, new guidelines from major mailbox providers necessitate a reassessment of potential risks related to deliverability and blocklistings.
• Internal DMARC impact: Marketers should consider whether their internal systems perform DMARC checks, as this could lead to issues if Gmail's DMARC policy is set to quarantine or reject. For more on this, see how stricter DMARC policies affect internal deliverability.
• Proactive testing: It is prudent to proactively test the email flow, including examining email headers, to ensure continued compliance and avoid unexpected disruptions, as discussed in the Salesforce Marketing Cloud Trailhead community.
• Salesforce-to-Salesforce communication: Marketers should leverage Salesforce's support for guidance on how their platforms are intended to handle such internal email routing to prevent authentication issues.

Key opinions

• Clear impersonation: Any external email received with a `From:` address that was not sent directly by Gmail servers is considered impersonation and is a serious violation.
• Internal DMARC checks: Internal forwarding of Gmail-originated emails is generally acceptable only if the receiving internal system does not perform DMARC validation, as SPF is likely to break.
• Gmail’s DMARC policy: Gmail's DMARC policy, which often moves towards quarantine or reject, will lead to problems if authentication fails on forwarded emails that retain the Gmail `From:`.
• Inbound system handling: The critical determinant for success in such forwarding scenarios is how the internal receiving system (e.g., Service Cloud) processes inbound email authentication.

Key considerations

• Testing email headers: It is crucial to perform thorough testing by sending a sample email through the entire flow and inspecting its headers to verify DMARC validation status and identify any authentication failures. Our guide on email forwarding and DMARC offers more insight.
• Relying on internal acceptance: While an internal system might currently accept all emails, relying solely on this could pose future risks if its DMARC checking policies change, or if a global blocklist (or blacklist) picks up on the behavior.
• DMARC for internal mail: Even for internal communications, a misconfigured DMARC can cause issues, as discussed in our article about internal automated emails going to spam. For more on general DMARC concepts, see this article on unverified senders.
• Long-term compliance: Maintaining a healthy sender reputation requires ongoing vigilance against evolving industry standards and mailbox provider requirements.

Key findings

• From header importance: RFC 5322 defines the `From:` header as crucial for identifying the author of the message, and any manipulation or misrepresentation is subject to scrutiny.
• Anti-impersonation: Google’s sender guidelines explicitly prohibit impersonating Gmail or other domains, requiring authenticated sending from the legitimate infrastructure.
• DMARC’s role: DMARC is designed to protect domain reputation by ensuring that the `From:` address aligns with authenticated SPF and DKIM domains. Forwarding can break this alignment.
• Forwarding complexities: Technical documentation on email standards acknowledges that forwarding can inadvertently cause DMARC failures due to changes in message path or content, often requiring specific handling or protocol extensions like ARC (Authenticated Received Chain).

Key considerations

• Sender address rewriting: To comply with best practices and prevent authentication failures, forwarding systems should ideally rewrite the `From:` address to their own authenticated domain, while preserving original sender information in `Reply-To` or `Sender` headers.
• Salesforce documentation: Salesforce's own documentation on email deliverability outlines how their platforms handle authentication and manage replies, which can guide proper configuration to avoid issues. Find out more about preventing brand and sender impersonation.
• DMARC policy enforcement: The increase in stricter DMARC enforcement by major mailbox providers means that systems that handle forwarded mail must adapt to prevent legitimate emails from being blocklisted or quarantined. A deeper dive into DMARC, SPF, and DKIM is available.
• RFC compliance: While RFCs provide a framework, practical implementation for deliverability often requires understanding how mailbox providers interpret and enforce these standards in real-world scenarios.