Reply Mail Management and MX Records

 Reply Mail Management and MX Records


Reply Mail Management manages replies , actions on the rules defined and route the email to the routing address. If you want to learn why RMM needs to be implemented for your marketing cloud account, click hereTo configure RMM , you need to have Sender Authenticated Package configured. If you have not yet enabled SAP,  raise the request for SAP or raise a request for RMM services.

The most important connection with RMM is the delegation of custom domain and sub domain to salesforce marketing mail servers. And to delegate you need to have the four NS entries in your DNS :

  • ns1.exacttarget.com
  • ns2.exacttarget.com
  • ns3.exacttarget.com
  • ns4.exacttarget.com
For RMM, you can self configure the MX records for self-hosted DNS. 

Why you need to have Sender Authenticated Package enabled for RMM?

When you enable SAP , it configures SPF, DMIK and DMARC for delegating emails with OMM like any other Mail Transfer Agent and it has to lookup the DNS records for delegation to OMM.



 MAIL EXCHANAGE RECORDS

What is Mail Exchange Records (MX Records)

MX records are the entries to the DNS which defines the priority of accepting email messages by the OMM (mail servers) on your behalf of your custom domain name. 

For example, you bought a new domain from ISP and added users for sending emails on your behalf. Your verified users would be able to send emails if you have SPF defined in the DNS, but if you have not defined MX records in your DNS, external mail servers will not be able to deliver emails to your domains. But, you can still receive emails from internal servers. Your verified users can exchange emails without MX records in the DNS.

  • MX record is used to receive emails from external domains
  • Control email flow
  • Load balancing

Example of your DNS entries MX records :

Domain			TTL   Class    Type  Priority      Host
example.com.		1936	IN	MX	10         onemail.example.com.
example.com.		1936	IN	MX	10         twomail.example.com.
Domain defines where emails has to be directed to , Type should be MX , priority defines which mail server to prefer for load balancing, host defines mail servers for the domain. The host should directly map to the address records and should not point to any CNAME records.


For your tenant in marketing cloud , your custom domain MX records in DNS will look like :
$TTL1H
$ORIGIN example.com
@       IN SOA       ns1.example.com           hostmaster.example.com
(
                    2013010100                     ;Serial
                          2H                       ;Refresh
                          1H                       ;Retry                                      
                          2W                       ;Expire
                          1H)                      ;TTL
         IN NS         ns1.example.com
         IN NS         ns2.example.com
localhost            IN A         127.0.0.1
                         IN MX 10       mailserver.example.com
;
;Delegate email.example.com to Salesforce Marketing Cloud
email                         IN NS               ns1.exacttarget.com
email                         IN NS               ns2.exacttarget.com
email                         IN NS               ns3.exacttarget.com
email                         IN NS               ns4.exacttarget.com
ns1/ns2/ns3/ns4.exacttarget.com are the mail server (OMM) for marketing cloud.

Note :
Delegation to external mail servers rather than marketing cloud mail server is possible if we self host the MX records in DNS.
Marketing Cloud has 4 mail servers for delegation of incoming emails and office 365 allows only one MX records.





References :
RMM 

Delegation 




Comments


Knowledge Article

Most Viewed

CLOUD PAGE ENABLEMENT - PART 1

EMAIL NOT SENT IN JOURNEY BUILDER

CONSIDERATIONS FOR JOURNEY BUILDER

Journey Builder REST API Documentation

Preference Center Demystified

Popular Posts

CLOUD PAGE ENABLEMENT - PART 1

EMAIL NOT SENT IN JOURNEY BUILDER

CONSIDERATIONS FOR JOURNEY BUILDER

Journey Builder REST API Documentation

Preference Center Demystified

SEND LOG EANBLEMENT

Share with Friends

Disclaimer:

The information provided on this technical blog is for general informational purposes only. As a SFMC (Salesforce Marketing Cloud) Technical Architect, I strive to offer accurate and up-to-date content related to SFMC and its associated technologies. However, please note that technology is constantly evolving, and the information provided may become outdated or inaccurate over time.

The content published on this blog represents my personal views and experiences as a SFMC Technical Architect and does not necessarily reflect the official views or opinions of any organization or employer I may be affiliated with.

While I make every effort to ensure the accuracy and reliability of the information presented, I cannot guarantee its completeness, suitability, or applicability to your specific circumstances. Therefore, it is essential to verify any information provided and make your own independent assessments or seek professional advice if needed.

Furthermore, any actions taken based on the information provided on this blog are at your own risk. I shall not be held liable for any damages, losses, or inconveniences arising from the use of the information presented here.

Please keep in mind that SFMC and its associated technologies are complex and require technical expertise for proper implementation and management. It is recommended to consult with qualified professionals or official SFMC documentation for comprehensive guidance.

Finally, please note that any product or company names mentioned on this blog are trademarks or registered trademarks of their respective owners. The mention of these trademarks or registered trademarks does not imply any endorsement or affiliation with the blog.

By accessing and using this blog, you agree to the terms of this disclaimer. If you do not agree with any part of this disclaimer, please refrain from using this blog.