Sender Authentication Package with DMIK configuration

 Sender Authentication Package with DMIK configuration


Sender Authentication Package :
It's a branding tool which has a package of features that marketing cloud configures for you.

SAP Features

  • Account Branding - Marketing Cloud brands your account with your chosen authenticated custom domain. This feature modifies view-as-a-webpage, link and image wrapping, and removes all references to Marketing Cloud in favor of your custom authenticated domain.
  • Private Domain for Email sending - This feature assigns a domain used to send email. This domain acts as the From address for your email sends. Salesforce Marketing Cloud authenticates your email sends using the Sender Policy Framework (SPF), Sender ID, and DomainKeys/DKIM authentication.
  • Custom Domain for CloudPages - This feature includes a private domain for CloudPages.
  • Dedicated IP Address - This feature assigns a unique IP address to your account. All email messages sent from your account from Marketing Cloud use this IP address. This IP address represents most of your sending reputation.
  • Reply Mail Management - This feature controls the replies you receive from your subscribers. You can assign filters for out-of-office messages and manual unsubscribe requests.
In our previous  blog we learnt about :
1. How SPF works
2. Why SPF is required by marketing cloud  for your domain
If you haven't read SPF, here is the link.

In this blog we will learn about DMIK and why we need them for SAP configuration.

DOMAINKEYS IDENTIFED MAIL

What is DomainKeys Identified Mail (DKIM)

DKIM is a email authentication method to validate if the email was not altered during transmission between source to destination. With DKIM , emails are signed using a private key at the source, it uses public key cryptography and the public key is used to validate the email with DKIM private key as a signing certificate. The underlying algorithm for encryption is rsa-sha256. 

If we configure only SPF , email forwarding fails because the email header changes , and validation for SPF fails, therefore we configure DKIM which digital signs the email and preserves it during transmission and doesn't allow the email header changes between different email servers.

DMIK SIGNATURE
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
     c=relaxed/simple; q=dns/txt; i=foo@eng.example.net;
     t=1117574938; x=1118006938; l=200;
     h=from:to:subject:date:keywords:keywords;
     z=From:foo@eng.example.net|To:joe@example.com|
       Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
     bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
              VoG4ZHRNiYzR








References :
DomainKeys Identified Mail - DMIK 
Validity - Blog DKIM 

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.