"Phishing" refers to the fraudulent use of email messages that are disguised to look like messages from reputable companies, but are actually intended to induce the consumer to reveal sensitive information, such as passwords or credit card numbers. This topic describes the features available in Cheetah Messaging to prevent phishing attacks from links sent as part of Messaging Campaigns.
Cheetah Messaging uses the concept of "redirects" for tracking link clicks within message content. When a recipient clicks a tracked link, the platform first directs the recipient to a Cheetah Digital server (where the click behavior is captured and tracked for reporting purposes), then redirects the recipient to the intended destination, such as the client's website or online store. Without the anti-phishing features described below, unscrupulous individuals could exploit tracked links to redirect unsuspecting consumers to nefarious destinations as part of a phishing attack.
When the Link Authenticity feature is enabled for a client, Cheetah Digital's redirect servers will authenticate a clicked link to ensure it has not been tampered with, before redirecting the recipient to the intended destination URL.
Link Authenticity is an optional feature that must be enabled in a client's account. Once the feature is enabled, all new Email Campaigns launched from that point forward will take advantage of the feature; Email Campaigns launched prior to the feature being enabled will not use Link Authenticity. Please speak to your Client Services Representative for more details on enabling this feature.
Note: Link Authenticity is available only in the Email Channel. The feature applies to links in all format versions (HTML, Plain Text, etc.) defined in the Email Campaign.
When the Campaign deploys messages, the platform "hashes" each tracked link URL, meaning that the human-readable text is converted into unreadable text by means of an encryption key. The platform appends the value to the link as a new reserved Campaign parameter -- "hp."
When a recipient clicks on a tracked link from this Campaign, the platform validates all click events originated from the URL, and rejects the link click if the value of the "hp" parameter does not match or is not present. If the "hp" parameter is present, the redirect is allowed to continue, and the platform logs the link click event.
Optionally, a client can provide a list of valid, or “allowed”, domains for their tracked link destinations. Only links that are redirected to a domain on this allowed list will be allowed to proceed. This concept of "allow-listing" domains prevents users from getting redirected to unknown, potentially fraudulent destinations.
The registered domain list is an optional feature that must be enabled in a client's account. Once the feature is enabled, all Campaigns that were previously created, as well as all Campaigns created in the future, are impacted. Unlike Link Authenticity above, the registered domain feature will affect link clicks within in-flight Campaigns (Link Authenticity affects only Campaigns launched after the feature is enabled).
When providing the allow-list of valid domains, you must provide ALL valid domains. As soon as you provide one valid domain in your registered domains list, the platform is instructed to begin this process of checking link clicks against the list. If you don't provide all valid domains, then you may end up inadvertently blocking link clicks that you want to proceed. For example, let's say you have two valid domains for link destinations: "home.companyabc.com" and "store.companyabc.com." If you send us only the first domain, then the platform will begin checking all link clicks from your Campaign messages. All link clicks to "home.companyabc.com" will be deemed valid and allowed to proceed, but all links clicks to "store.companyabc.com" will be blocked, which is likely undesirable. For this reason, it's important that you provide us with ALL valid domains when setting up the registered domain feature.
The platform supports the use of an asterisk as a wildcard character. Continuing the above example, the client could provide "*.companyabc.com" to encompass both of their valid domains.