How to configure SFMC to send on behalf of sales reps with DKIM/DMARC authentication?
Michael Ko
Co-founder & CEO, Suped
Published 15 Jul 2025
Updated 17 Aug 2025
8 min read
Setting up Salesforce Marketing Cloud (SFMC) to send emails on behalf of sales representatives, while ensuring full DKIM and DMARC authentication, presents a unique challenge for many organizations. The goal is to leverage the personal touch of a sales rep's email address while maintaining brand trust and avoiding deliverability issues.
The core of this challenge lies in managing email authentication protocols, SPF, DKIM, and DMARC, across multiple sending platforms. When emails appear to come from an individual sales rep (e.g., salesrep@mycompany.com) but are technically sent via SFMC, proper configuration is crucial to prevent them from landing in spam folders or being rejected outright.
This setup typically involves a combination of Salesforce Marketing Cloud's Sender Authentication Package (SAP) and Private Domains, which work together to ensure your emails are properly signed and aligned, satisfying the strict requirements of major mailbox providers.
The Sender Authentication Package in SFMC is more than just branding. It's a suite of tools that gives you dedicated IP addresses and sets up private domains for tracking links, images, and bounces. This ensures all the technical domains (return-path, links, images) are aligned to a specific subdomain (e.g., e.mycompany.com), providing a consistent sender identity.
While SAP handles the technical infrastructure, a private domain (which is your actual "From" domain, like mycompany.com) is essential for DMARC alignment. You can add your top-level domain as a private domain within SFMC. This step is critical because it allows SFMC to apply DKIM signatures to emails sent from your primary domain, even if the underlying sending infrastructure (SAP) uses a subdomain.
To send emails that appear from salesrep@mycompany.com and pass DMARC, you need both the SAP configured on a subdomain (e.g., email.mycompany.com or sfmc.mycompany.com) and your primary domain (mycompany.com) added as a private domain. This way, the email's visible "From" address (mycompany.com) aligns with the DKIM signing domain, ensuring DMARC compliance.
SAP subdomain configuration
Purpose: Handles technical aspects like bounce handling, image wrapping, and click tracking.
Domain: Uses a dedicated subdomain (e.g., e.yourbrand.com).
Authentication impact: SPF alignment often happens at this subdomain level for the Return-Path.
Private domain for from address
Purpose: Allows SFMC to send emails with your primary domain in the "From" address field.
Domain: Your main domain (e.g., yourbrand.com).
Authentication impact: Enables DKIM signing of your primary domain, crucial for DMARC alignment.
Configuring authentication protocols
DKIM (DomainKeys Identified Mail) is a digital signature attached to your email, allowing the recipient's server to verify that the email was indeed sent by an authorized sender and hasn't been tampered with. In SFMC, when you add a domain as a private domain, it generates the necessary DKIM records for you. You'll then publish these as CNAME records in your domain's DNS. For emails to pass DMARC, the domain used in the DKIM signature must align with the "From" domain displayed to the recipient. You can learn more about how to add your DKIM record for your owned domain in SFMC, and for general best practices on setting up email authentication, consult our comprehensive guide to SPF, DKIM, and DMARC.
DMARC (Domain-based Message Authentication, Reporting, & Conformance) leverages both SPF and DKIM. For an email to pass DMARC, at least one of these (SPF or DKIM) must align with the "From" domain. In the 'send on behalf of' scenario with SFMC, SPF often doesn't align with the primary "From" domain because the return-path (bounce) address typically uses the SAP subdomain (e.g., bounce.e.mycompany.com). However, this is usually acceptable, as long as DKIM alignment is achieved. If you encounter DMARC failures when using 'on behalf of' sending, understanding this distinction is key. For more on SPF failure and return paths, review our related article.
If you also send corporate email from the top-level domain (mycompany.com) via other services like Google Workspace or Microsoft 365, DKIM can indeed exist in more than one place. Each platform will have its own DKIM keys. Adding your primary domain as a private domain in SFMC solely for DKIM signing purposes, without impacting your existing email infrastructure, is common. Salesforce's documentation also provides guidance on setting up email authentication.
Multiple DKIM signatures
A common misconception is that a domain can only have one DKIM signature. In reality, multiple email sending services (like SFMC, Google Workspace, or Microsoft 365) can each generate their own DKIM records for the same domain, using different selectors. When an email is sent, the receiving server will check for valid DKIM signatures associated with the sending domain. As long as at least one valid signature aligns with the "From" domain, DMARC will pass.
Practical implementation steps and potential pitfalls
The most robust way to achieve DMARC compliance when sending on behalf of sales reps from SFMC is to implement a SAP on a dedicated subdomain (like email.yourcompany.com) and concurrently add your primary domain (yourcompany.com) as a private domain. This configuration allows the SAP to handle all the background technical aspects of sending while the private domain ensures your visible "From" address is properly DKIM-signed and aligned for DMARC.
A critical pitfall to avoid is using a Reply-To address that points back to the sales rep's original email address if the From address is an SFMC subdomain (e.domain.com). While technically possible, it can confuse recipients and lead to deliverability issues. Some mailbox providers may auto-populate the From address (the subdomain) into address books, causing recipients to send replies to the wrong address later. The goal is seamless sender experience and proper replies back to the sales rep.
Reply-to address warning
Do not set your Reply-To address to your main domain if your visible From address is a Salesforce Marketing Cloud subdomain (e.g., e.yourcompany.com). This can confuse recipients, leading to replies being sent to the technical subdomain rather than the intended sales rep. Always aim for consistent domain usage.
SFMC offers a "multi-bounce domain" setting that can help achieve SPF alignment across multiple domains, but it adds significant complexity. Discussing this with Salesforce support is advisable, but proceed with caution. Furthermore, a common recommendation for this sending model is to deactivate Reply Mail Management (RMM) in SFMC, as it can sometimes interfere with personalized 'on behalf of' sending. You can also consult resources like Spam Resource for tips on sending as the top level domain.
Maintaining strong deliverability
Once your configuration is in place, consistent monitoring of your DMARC reports is paramount. These reports provide invaluable insights into how your emails are being authenticated by various mailbox providers and identify any DMARC failures. Understanding these reports helps you quickly identify and resolve any issues, ensuring your 'on behalf of' sending remains compliant and lands in the inbox. Tools that provide DMARC monitoring can greatly simplify this process.
Beyond DMARC reports, regularly verifying your SPF, DKIM, and DMARC records is crucial. DNS changes, platform updates, or human error can inadvertently break authentication. Use an email deliverability tester to send test emails and verify that all authentication checks are passing for the 'on behalf of' emails. This proactive approach helps maintain high deliverability rates and prevents your emails from being flagged as suspicious or ending up on a blocklist (or blacklist).
Even with perfect authentication, sender reputation remains vital. Factors like bounce rates, spam complaints, and engagement metrics directly impact inbox placement. When sending on behalf of sales reps, ensure they are adhering to best practices, such as sending to engaged lists and avoiding spammy content. A healthy sender reputation, combined with robust authentication, is the foundation of successful email programs.
Authentication check
SFMC domain
Alignment for DMARC
SPF
Return-Path (typically SAP subdomain)
Often fails (softfail) with From domain, but is acceptable if DKIM passes.
DKIM
Signing domain (main domain added as private domain)
Should pass and align with From domain.
DMARC
Based on From domain
Passes if either SPF or DKIM aligns and passes.
Views from the trenches
Best practices
Ensure both a Sender Authentication Package (SAP) subdomain and a Private Domain are configured in SFMC to manage both technical sending and "From" address branding.
Always align your DKIM signature with the primary "From" domain to ensure DMARC compliance, even if SPF does not explicitly align.
Regularly monitor DMARC reports to identify and address any authentication failures, ensuring consistent deliverability.
Deactivate Reply Mail Management (RMM) in SFMC if you are sending personalized emails on behalf of sales reps to prevent deliverability issues.
Common pitfalls
Relying solely on SPF alignment for DMARC when sending on behalf of sales reps from SFMC, as it often won't align with the primary domain.
Configuring a Reply-To address on your main domain if your "From" address is an SFMC subdomain, which can confuse recipients and lead to misdirected replies.
Not adding the primary sending domain as a Private Domain in SFMC, preventing proper DKIM signing and DMARC alignment.
Ignoring the potential for multiple DKIM records on the same domain, which is a common and necessary setup for different sending platforms.
Expert tips
Leverage the multi-bounce domain setting in SFMC carefully, as it can add complexity but potentially help with SPF alignment across multiple domains.
If sending from multiple domains, consider discussing complex configurations with Salesforce support, especially regarding multi-bounce domain settings.
Proactively test your email authentication using an email deliverability checker after any configuration changes to ensure continued compliance.
Understand that DMARC primarily relies on either SPF or DKIM alignment, so a passing DKIM is often sufficient even if SPF doesn't align for the primary domain.
Expert view
Expert from Email Geeks says that sending on behalf of sales reps with DKIM/DMARC authentication is doable in SFMC, and it doesn't create a conflict with existing G-Suite or Salesforce CRM domains.
2024-05-15 - Email Geeks
Expert view
Expert from Email Geeks says that DKIM can exist in more than one place, so a domain can be configured in G Suite, Salesforce CRM, and Salesforce Marketing Cloud simultaneously.
2024-05-15 - Email Geeks
Achieving authenticated email sending
Configuring Salesforce Marketing Cloud to send on behalf of sales representatives while maintaining strong DKIM and DMARC authentication is a nuanced but achievable goal. By strategically combining a Sender Authentication Package (SAP) on a subdomain with your primary domain added as a Private Domain, you can ensure that your emails are properly signed and aligned, enhancing both deliverability and brand credibility. Remember that proper authentication is a critical element of strong email security, and it signals to mailbox providers that your emails are legitimate.
Google Workspace or 
Microsoft 365, DKIM can indeed exist in more than one place. Each platform will have its own DKIM keys. Adding your primary domain as a private domain in SFMC solely for DKIM signing purposes, without impacting your existing email infrastructure, is common. Salesforce's documentation also provides guidance on setting up email authentication.
