Prevent emails from being labeled as spam

By default, Identity Cloud transactional emails (emails automatically generated by the system, such as emails sent when a user clicks a Forgot Password link) use the return address noreply@janrain.com. And that’s fine: your Identity Cloud implementation will work perfectly well when using this address. As you might expect, however, most organizations prefer to update the email_sender_address API client setting to an address that uses their domain name instead: For example, if your domain name is akamai-documentation.com you probably want the return address to be something on the order of noreply@akamai-documentation.com.

Needless to say, in our current age of phishing and spoofing, an email allegedly sent from akamai-documentation.com that uses a totally different Sent from address (janrain.com) is going to be viewed with suspicion. As it probably should be.

Changing the transactional email return address is easy. However, if you change the return address you might discover that your transactional emails are being marked as spam and are being sent directly to users’ junk mail folders. This is invariably due to increased effort on the part of mail servers to identify and isolate suspect email messages. (Spam is not only annoying, but it’s also estimated that over 90% of all malware is delivered to users via junk email messages.) The net result? A user clicks the Forgot password link, the transactional email ends up in the user’s junk mail folder, the user never sees this message, and, as a result, the user never gets to reset their password.

That’s not the recommended customer experience.

Fortunately, there are steps you can take to increase the chances that your transactional emails aren’t marked as junk email. Note that the actual way that you implement these steps depends on your mail server; because of that, configuration steps are not included in this article. Instead, you should contact your mail server representative if you have implementation questions.

The steps you can take include the following:

• Configure an MX (Mail Exchanger) DNS record. This record indicates the mail server responsible for receiving email messages on behalf of the specified domain. Technically, you can send and receive emails without configuring an MX record. However, there’s a good chance that many of the mail servers you send transactional emails to have been configured to automatically reject emails that aren’t associated with one of these records. For that reason alone, configuring an MX record is highly recommended.

• Configure DKIM (DomainKeys Identified Mail). DKIM adds a digital signature to your transactional email header. Mail servers that receive those emails can then use your public cryptographic key to verify that signature.

• Configure SPF (Sender Policy Framework). With Sender Policy Framework, you create a DNS TXT record that lists the servers authorized to send email for your domain. In addition, you add a return-path header to your emails that point to this record. When a mail server receives one of your transactional emails, it can use the return-path header to help verify that the server used to send the email is included in the authorized mail server DNS record.

• Configure DMARC (Domain-based Message Authentication, Reporting, and Conformance). A relatively-new technology that combines both SPF and DKIM when determining the legitimacy of the emails received by a server.

We should mention that none of these methods are foolproof: after all, their effectiveness relies in large part on how your customers’ email servers are configured. Likewise, you can’t prevent individual users from blocking your emails or from marking them as spam. As a general rule, however, these methods do increase the chances that your transactional emails are delivered directly to users and that they don’t automatically end up in a junk mail folder.