Is forwarding emails originating from Gmail through Salesforce Marketing Cloud considered Gmail impersonation?
Matthew Whittaker
Co-founder & CTO, Suped
Published 6 Jun 2025
Updated 17 Aug 2025
8 min read
Many of us rely on robust marketing automation platforms like Salesforce Marketing Cloud (SFMC) to handle large-scale email campaigns, including crucial transactional messages like appointment reminders. A common scenario involves sending these emails from a branded subdomain, ensuring proper authentication with SPF, DKIM, and DMARC.
A significant portion of recipients reply to these emails, perhaps to reschedule or cancel. These replies are typically routed back through SFMC’s Reply Mail Management (RMM) system. The challenge arises when these replies originate from common email providers, particularly Gmail accounts.
By default, SFMC’s RMM modifies the 'From' address of incoming replies to prevent impersonation, for instance, changing 'name@gmail.com' to 'name.gmail.com@subdomain.sfmc.com'. However, some internal systems, like Salesforce Service Cloud, require the original 'From' address to correctly open cases or process information. This raises a critical question: Does deactivating this default SFMC behavior and allowing emails with a Gmail 'From' address to be forwarded through SFMC constitute Gmail impersonation under the new email guidelines?
Understanding email impersonation and Gmail's guidelines
The straightforward answer to this query is that if an email recipient sees an email where the 'From' header ends with '@gmail.com', but the email was not actually sent through Gmail's servers, it is indeed considered impersonation. Google’s guidelines explicitly state that senders should not impersonate Gmail, which means not using the 'From' domain if you are not an authorized sender for that domain.
This principle is rooted in email authentication protocols: SPF, DKIM, and DMARC. When SFMC forwards an email with the original Gmail 'From' address, the SPF and DKIM authentication checks at the receiving end will almost certainly fail. This happens because SFMC (or your configured sending domain) is not authorized in the Gmail's SPF record to send mail on its behalf, and SFMC cannot sign the email with Gmail's DKIM key. These failures lead to DMARC authentication failures. You can learn more about how to prevent brand and sender profile impersonation.
While your initial outgoing emails from your branded subdomain are correctly authenticated, the forwarding of replies where the 'From' address remains a Gmail address is the specific action that can trigger impersonation flags. Even if the recipient system (Service Cloud in this case) is lenient, this practice can lead to your emails being marked as spam or even being added to a blocklist (or blacklist) by more vigilant email providers down the line.
The role of Salesforce Marketing Cloud and reply mail management
The core of the issue lies in how Salesforce Marketing Cloud (SFMC) handles reply mail. Its default Reply Mail Management (RMM) functionality is designed with deliverability and anti-impersonation in mind. When a reply comes in, SFMC typically rewrites the 'From' address to ensure that the email appears to originate from an authorized SFMC domain or subdomain.
This default behavior is crucial for maintaining your sending reputation. If SFMC were to forward the email with the original 'From' address (e.g., 'customer@gmail.com') without modification, it would be sending email on behalf of gmail.com, which it is not authorized to do. This immediately leads to DMARC failures, making the email highly susceptible to being rejected or marked as spam by receiving mail servers. This is particularly relevant given the new bulk sender guidelines from Gmail and Yahoo.
While deactivating this feature might seem convenient for Service Cloud integration, it directly conflicts with the foundational principles of email authentication. Even if your Service Cloud instance is an internal system and doesn't reject these emails, you're setting a precedent that could negatively affect your overall email ecosystem, and could trigger DKIM failures when sending from Salesforce via Gmail.
SFMC default RMM behavior
From address: Rewrites customer@gmail.com to customer.gmail.com@yourdomain.sfmc.com.
Authentication: Maintains proper SPF, DKIM, and DMARC alignment for your sending domain.
Deliverability: High deliverability rates, low risk of spam or blocklisting.
Service Cloud: May require customization to parse the original sender from headers.
Custom RMM (retaining Gmail From)
From address: Retains original customer@gmail.com.
Authentication: SPF and DKIM will fail; DMARC will fail for Gmail domain.
Deliverability: High risk of emails going to spam or being outright rejected.
Service Cloud: Appears to work, but at the cost of external deliverability and reputation.
DMARC, forwarding, and internal systems
DMARC is designed to prevent email spoofing and phishing by ensuring that the 'From' address aligns with the authenticated domains (SPF and DKIM). When an email is forwarded and its 'From' address is not modified, but the email is sent from a different server, DMARC alignment fails. This is a critical point when considering the security and deliverability of your emails, particularly when strict DMARC policies are in place.
For internal forwarding, such as from SFMC to Service Cloud, the direct impact on deliverability might not be immediately apparent, especially if your Service Cloud instance is configured to accept all incoming mail without strict authentication checks. However, this leniency typically applies only within a closed, trusted environment. The moment these emails might potentially leave your internal system, or if your Service Cloud system itself forwards them externally, the DMARC failures become a significant problem.
Even if your Service Cloud system isn't rejecting emails, forwarding-based spoofing is a known vulnerability. The key consideration is that email authentication is designed to protect recipients from fraudulent messages. When your setup bypasses these checks, even for internal purposes, it creates a potential loophole that could be exploited or misinterpreted by external mail servers, leading to your domain being put on a blocklist (or blacklist). You should understand why emails are marked as spam when forwarded to Gmail.
The DMARC challenge with forwarding
When an email from Gmail is forwarded through SFMC without modifying the 'From' header, the DMARC check at the final recipient's server will likely fail. This is because SFMC is not the authorized sender for Gmail.com. Even if the Service Cloud does not strictly enforce DMARC, this creates a vulnerability.
The long-term impact on your sender reputation and potential blocklisting risks (even if unintentional) are significant. It is always best practice to ensure that all email traffic is properly authenticated and aligned with current email security standards.
Ensuring compliance and deliverability
To avoid Gmail impersonation and maintain optimal email deliverability, it’s essential to implement compliant solutions for handling replies from Gmail through Salesforce Marketing Cloud to Service Cloud. Instead of forcing the original 'From' address, consider using the 'Reply-To' header. This allows you to specify a different email address for replies without altering the original 'From' field. The email will still appear to come from your SFMC sending domain, maintaining proper authentication, while replies are directed to your Service Cloud email address. You may also want to check SPF verification failures for emails forwarded to Gmail.
Another approach involves integrating Salesforce Service Cloud directly with a dedicated mailbox that receives customer replies. This mailbox can then parse the original sender's information. This method avoids any 'From' header manipulation that could trigger impersonation warnings or land you on a blocklist (or blacklist). Collaborating with Salesforce support and their documentation on configuring email forwarding from Gmail to Salesforce for features like 'Email-to-Case' is highly recommended to find a solution that ensures data integrity without compromising email authentication standards. Remember, prioritizing robust email authentication is critical for long-term deliverability and sender reputation.
Scenario
From Header
Impersonation Risk
Deliverability Impact
SFMC default RMM
customer.gmail.com@yourdomain.sfmc.com
Low
High success, maintains reputation
Custom RMM (retains Gmail From)
customer@gmail.com
High
High risk of spam/rejection, DMARC failures
Using Reply-To header
customer.gmail.com@yourdomain.sfmc.com (From) with ServiceCloudEmail@yourdomain.com (Reply-To)
Low
High success, compliant authentication
Summary and recommendations
While your current setup of forwarding Gmail originating emails through Salesforce Marketing Cloud to Service Cloud might appear to work internally, retaining the original Gmail 'From' address does indeed constitute Gmail impersonation under modern email guidelines.
Relying on internal system leniency is a risky strategy that can lead to deliverability issues, including emails being marked as spam or your sending domain ending up on a blocklist (or blacklist). The best approach is to implement solutions that respect email authentication protocols, such as using the 'Reply-To' header or directly integrating with a mailbox, ensuring both data integrity for Service Cloud and robust email deliverability for your organization.
Views from the trenches
Best practices
Always ensure that the 'From' address of your emails matches the domain authorized by your SPF and DKIM records, preventing DMARC failures and maintaining deliverability.
Utilize 'Reply-To' headers to direct replies to a different address, allowing you to route customer responses to Service Cloud without altering the 'From' domain.
Configure your Service Cloud or internal systems to parse the original sender's email address from other email headers like 'Return-Path' or 'Sender' if the 'From' address is rewritten.
Common pitfalls
Deactivating default Reply Mail Management (RMM) in SFMC to retain original 'From' addresses, which leads to DMARC authentication failures.
Assuming that internal systems' leniency toward unauthenticated emails will extend to external mail receivers, risking blocklisting or spam folders.
Overlooking the long-term impact on your sender reputation by not adhering to modern email authentication standards.
Expert tips
Audit your email forwarding paths regularly to identify any potential DMARC alignment breaks or impersonation risks, especially for high-volume email streams.
Implement a DMARC policy of 'p=quarantine' or 'p=reject' to protect your domain from unauthorized use and gain better visibility into authentication failures.
Educate your team on email security best practices and the implications of email forwarding on deliverability and sender reputation.
Expert view
Expert from Email Geeks says if an email is received with a From header ending in @gmail.com but was not sent via Gmail, it constitutes impersonation and should be stopped.
2024-01-15 - Email Geeks
Expert view
Expert from Email Geeks says that forwarding emails originating from Gmail to an internal system is generally fine, provided that the internal system does not perform DMARC checks. If it does, issues will arise due to Gmail's DMARC quarantine record.
Salesforce Marketing Cloud (SFMC) to handle large-scale email campaigns, including crucial transactional messages like appointment reminders. A common scenario involves sending these emails from a branded subdomain, ensuring proper authentication with SPF, DKIM, and DMARC.
Gmail accounts.
Gmail's servers, it is indeed considered impersonation. Google’s guidelines explicitly state that senders should not impersonate Gmail, which means not using the 'From' domain if you are not an authorized sender for that domain.
Gmail is forwarded through SFMC without modifying the 'From' header, the DMARC check at the final recipient's server will likely fail. This is because SFMC is not the authorized sender for Gmail.com. Even if the Service Cloud does not strictly enforce DMARC, this creates a vulnerability.
