As part of the alignment to industry standards, depending on the type of mail being used, you might be required to maintain several additional DNS records. One of the following scenarios might apply to your organization:
Scenario 1: Client uses D2L mail domain
D2L handles the creation and management of the required email records to ensure mail sent from Brightspace conforms to DMARC and related SPF and DKIM protocols.
For example: If Brightspace is configured to use mail domain clientmail.brightspace.com, D2L creates MX, DMARC, and TXT records, as well as DKIM signatures ensuring mail sent using any brightspace.com mail domain is delivered by recipients applying the DMARC policy.
Scenario 2: Client uses branded non-D2L mail domain
You must create an SPF TXT record for the mail domain that allows D2L Cloud to send mail on your behalf, as well as CNAME records pointing to the D2L DKIM TXT records publicizing a public domain key. D2L generates and maintains the private domain key to create a DKIM signature for mail sent from D2L Cloud using your branded mail domain.
For example: If Brightspace is configured to use mail domain mail.client.edu, D2L generates and publishes a private/public domain key pair as a TXT DKIM record You create CNAME records for d2lmail1._domainkey.mail.client.edu and d2lmail2._domainkey.mail.client.edu pointing to the D2L TXT DKIM records and the TXT SPF record for mail.client.edu including a._spf.brightspace.com. D2L encodes mail sent using the branded mail domain with the DKIM signature to ensure that recipients applying the DMARC policy can decode the headers and verify the sender. D2L will rotate the active DKIM key 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.
Note: If your organization is using a non-D2L domain that you do not own, DMARC is not supported with your Brightspace.