top of page

Best Practices

dots 2.png
  • Don’t pass Personally Identifiable Information (PII) in plain text. 

  • Use Encryption methods in the Cloudpage for sensitive data like ClientID, ClientSecret, Tenant endpoints, etc., 

  • Surround non-authenticated, non-application, public landing pages with a global IF/THEN clause. Check for empty required parameters. Use this clause for both front-end pages and for processing landing pages. This step prevents landing pages from processing if somebody accesses pages directly and deters parameter manipulation when accessing the base URL. 

  • Don’t substitute encoding, such as Base64 or StringtoHex, to pass fields that should not pass in plain text. Encoding isn’t encryption and it can be decoded. 

  • Hashing algorithms like MD5 and SHA1 are usually not considered secure. The most commonly used is SHA256.

  • Don’t perform any client-side validation or processing using Client-side JavaScript or AJAX. It is recommended to perform on the Server-side.

  • Use two or more QS parameters to verify it’s the same subscriber before doing any other processing on the landing page or presenting any data. 

  • When using public landing pages in Enterprise 2.0 accounts, use the AMPScript CloudPagesURL function to encrypt all QS parameters.

  • SSJS debugging and exception handling article by Mateusz Dąbrowski.

  • Utilize Code Resources instead of a Landing Page wherever you can, to avoid Supermessages consumption.

  • Implement Google reCAPTCHA that provides a seamless security layer against abusive form submissions and spam attacks. Check out this detailed article by Ivan Razine.

  • Use permissions to manage access to Cloudpages.

  • When working with API's, be aware of the volume and frequency that might hit them, and handle it effectively.

  • Do not request a new access token for every API call you make—-each access token is good for 20 minutes and is reusable. Making two API calls for every one operation is inefficient and causes throttling. But it is recommended that you refresh your token two minutes before its lifetime ends.

  • To enable security headers, insert the following code in the code view of your content page. You can also change the attributes below as needed.

<script runat=server> 

Platform.Response.SetResponseHeader("Strict-Transport-Security","max-age=200"); Platform.Response.SetResponseHeader("X-XSS-Protection","1; mode=block");


Platform.Response.SetResponseHeader("X-Content-Type-Options","nosniff"); Platform.Response.SetResponseHeader("Referrer-Policy","strict-origin-when-cross-origin"); Platform.Response.SetResponseHeader("Content-Security-Policy","default-src 'self'"); 



*Source : Salesforce Docs & Community Blogs

  • When creating the Installed Packages, allow limited access based on the use cases to be performed.

  • Limit the Setup access only to a few set of users who perform admin-related tasks.

  • For Multi-Factor Authentication, it is recommended that you register for at least two verification methods so you have a backup available - if you lose or forget your primary method.

  • Purchase SSL Certificates to secure the following URL's and understand the Impacts.

    • Cloudpages​​​ - pages.[CustomDomain].com

    • Email Tracking Links - click.[CustomDomain].com

    • Email View as a Web Page - view.[CustomDomain].com

    • Content Builder Content - image.[CustomDomain].com​​

  • Clickjack Protection - Enabled by default, this feature stops malicious pages from loading in the background of trusted Marketing Cloud pages to gain access to confidential information. But it only protects the Interface, not Cloudpages. To do so, include the security headers - X-Frame-Options, as discussed in the Cloudpages section above.

  • Create secure keys under Key Management that can be used in AMPscript Encryption functions

  • Recommended Security Settings :

  • When writing AMPscript code, use the Code Snippet Blocks in Content Builder when possible. Code snippets aren’t wrapped in HTML tables and therefore using them doesn’t add extra markup to your code.

  • When pulling URLs from data extensions or variables use RedirectTo.

  • Limit the number of Lookup functions to improve performance, especially if you have large data extensions with a lot of data.

  • Merge data into one sendable data extension before send to improve send performance.

  • Test with data identical to your live sendable data (but be careful to not accidentally send anything).

  • Surround variables in brackets even if they don't have spaces or special characters.

  • Use code comments to explain your code.

  • For more tips, check out this documentation


Apply the following best practices to implement Contact Delete. All contact deletion processes are final, and Marketing Cloud can’t restore deleted contact information.


  • Contact Delete removes contact information across the entire enterprise for Enterprise 2.0 accounts.

    • ​This deletion affects all business units that share ClientID value as the MID of the account that initiated the delete.

    • If you use multiple Enterprise 2.0 accounts, perform the Contact Delete process for each account. The deletion process requires more time to remove contact information across a large number of business units.

    • Child business units can include contact records created by triggered sends, data operations such as queries or filters, or Synchronized Data Sources. Delete those records using the child business unit MID in your request.

  • Use ContactKey or ContactID values to delete contacts.

  • If you linked multiple SubscriberKey or ContactKey values to a contact record, perform the Contact Delete process for all values.

  • To request the status for a single contact, use an API request. For large batches of deletions, the suppression status shows for contacts when the entire batch processes.

  • To improve Contact Delete performance, break your requests into at least 6 smaller requests and submit each request 5 minutes apart.

  • Data extension data-retention policies don’t ensure regulatory compliance. Use both Contact Delete and data retention policies to help ensure full removal of data.

  • We recommend setting data retention policies for a data extension when you first create it. You can apply data retention policies to new and existing data extensions. However, data extensions with more than 100 million records can’t accept retroactive data retention policies.

  • You can’t reintroduce a contact that is in suppression or in the process of being deleted after the suppression period is over. During this time you can’t perform any sends, including transactional sends, to that contact.

  • To more quickly remove contact information from your account, set the suppression period length to 0. A suppression period of 0 indicates that the contact deletion process doesn't pause after placing the contacts in the delete request in suppression. The delete request is immediately eligible to process a physical delete of the contacts that it encompasses. System availability determines when the physical deletion starts. Allow time for the deletion to process: it can take the system some time to find all data related to the Marketing Cloud contacts.

  • The deletion process yields to other account activities, such as sending, imports, automations, and query activities. These processes take precedence over deletions. As more activities run in the account, the deletions require more time.

  • The deletion process scans all sendable data extensions in an account to remove the specified contact records. To improve the speed of this process, delete any unnecessary sendable data extensions in your account.

  • When you delete a contact from a list or data extension, export any list or data extension to a file beforehand so that you can restart the contact delete process if there’s an error.

  • You can delete up to one million records.

bottom of page