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. However, most organizations prefer to update the email_sender_address API client setting to an address that matches their domain name. For example, if your domain name is mydomain.com, you probably want the return address to be something on the order of noreply@mydomain.com instead of noreply@janrain.com.

Starting in February of 2024, email providers such as Gmail and Yahoo Mail have new requirements for bulk email senders to follow. In order to send emails with specific return addresses that match the customer domain, customers will need to comply with the following. If customers do not comply with the following requirements, the emails to their end users will bounce back and the individual will not receive the email.

• 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 required.
• 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). This technology used to be optional but is becoming required for many email providers as of Q1 2024. DMARC combines domain authentication with DKIM and SPF to add linkage to the from domain name in an effort to monitor and protect the domain from fraudulent email.

Additionally, email providers are starting to require bulk email senders to adopt:

• Easy Unsubscription - End users shall be able to unsubscribe from marketing bulk senders with one click. Starting in Feb of 2024, both GMail and Yahoo will require all non-transactional emails from bulk senders to have a single click unsubscribe link embedded in the email in order for it to be delivered successfully. Then in June of 2024, these marketing emails will also be required to include a one-click unsubscribe header along with the unsubscribe link.

  However, Identity Cloud emails will not be subject to the Easy Unsubscribe requirement because all emails sent via the Identity Cloud are transactional emails pertaining to authentication.

  With these new rules in place, it will become important for each customer to adopt these new requirements across their brands to ensure their domains remain in good standing with spam rate thresholds. Failing to adopt these requirements for marketing emails could impact a customer’s transactional emails sent for the same domain.

• Spam Rate Threshold - In addition to the above mitigation steps that email providers have taken, many are introducing spam rate thresholds that senders must stay under in order to continue sending emails to their recipients. The Identity Cloud platform has you covered in that metrics are collected on bounce rates and evaluated in realtime to ensure emails continue to arrive at their intended recipient. This bounce rate is monitored and has automated alerting in case the bounce rate increases past an acceptable threshold.

Please note that none of the above spam mitigation steps are foolproof and some emails may get flagged as spam or be put into the junk folder. Likewise, you cannot prevent individual users from blocking your emails or from marking them as spam. As a general rule, however, the above methods greatly increase the chances that your transactional emails are delivered directly to users without ending up in their junk folder.

To set up your email-sending capabilities for the Identity Cloud in compliance with the requirements listed above:

1. Contact Akamai Support to request a custom email sender address. In your request, you’ll need to provide your email domain and a subdomain for transactional emails.

   1. Example: Let’s say you want your emails to come from noreply@example.com, using mail.example.com as the MAIL FROM subdomain. Then you should provide:
      1. Sender email: noreply@example.com
      2. Domain: example.com
      3. MAIL FROM domain: mail.example.com

         📘

         Note that a MAIL FROM domain is required, and it must be a subdomain of the parent domain of a verified identity (email address or domain) that you want to use to send email from. For more information, see Using a custom MAIL FROM domain (Amazon SES).

2. Akamai will initiate the email sender configuration and verification process, and will provide a list of records which you must copy and publish to your domain’s DNS provider.

   📘

   This addresses the MX, DKIM, and SPF requirements described above.

3. Once you’ve completed the DNS changes, please let Akamai know.

4. Akamai will confirm when the email sender address is successfully verified. The verification itself can take up to 72 hours, but typically happens in less than 24 hours.

5. Once your email sender address is verified, then you can update the email_sender_address setting with your custom address.

6. Test your transactional emails.

   1. For example, submit the registration form or request a password reset to trigger a transactional email from Akamai.
   2. Confirm the email is sent from your custom sender address, and that it is not flagged as spam.

📘

To configure the content and subject line of the emails, which can be customized per locale (i.e. per language you wish to support), see: Modify transactional emails