You must add SPF and CNAME records for your domain to allow D2L to send mail on your behalf.
Note: If your organization is using a non-D2L domain that they do not own, DMARC is unsupported with Brightspace.
SPF record
If no current SPF record exists, create the SPF record including:
{Client mailDomain} TXT -> "v=spf1 include:a._spf.brightspace.com ~all"
Note: The ~all is at your discretion (the ~ means it’s to be treated neutrally, in terms of SPAM scoring, if the record doesn’t come from an SPF certified source).
If an SPF record exists, add the following to the SPF record:
{Client mailDomain} TXT -> "include:a._spf.brightspace.com"
CNAME record
Create two new CNAME records using the following format:
d2lmail1._domainkey.{Client mailDomain} CNAME d2lmail1._domainkey.brightspace.com
d2lmail2._domainkey.{Client mailDomain} CNAME d2lmail2._domainkey.brightspace.com
Email signing
A private and public domain key pair is required to allow D2L to sign mail sent on your behalf and enable recipients to decode headers and verify the source of the email.
D2L generates the private and public domain key pair and imports it for use in signing email messages sent from the D2L Cloud on behalf of your domain. D2L provides the public DKIM TXT records to your organization for use in creating the corresponding CNAME records.
D2L will rotate the active DKIM keys every six months. When one key is rotated, the second will become active in signing emails, after which the process will repeat at six-month intervals. For organizations that have DKIM keys enabled and are using a custom mail domain, email delivery may be impacted if both required DKIM CNAME records are not in place at the time of rotation.