If your Brightspace organization is configured to use an email domain managed by another provider, correctly configured DNS records will ensure mail delivery to external systems occurs without issue.
You must have the appropriate TXT record (for SPF) and CNAME records (for DKIM) created for your domain to allow Brightspace to send mail on your behalf. Use of a DMARC record is optional, but highly recommended.
|
Important: If your organization is using a non-D2L domain that they do not own, DMARC is unsupported with Brightspace.
|
SPF record
Although referred to as an SPF record, the underlying DNS resource record created is the TXT type. This record identifies all allowed sending mail servers, and must include the Brightspace-managed SPF record to ensure uninterrupted mail delivery should IPs or servers change.
If no current SPF (TXT) record exists, create a new record for your mail domain with the following value: "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 does not come from an SPF certified source). |
If an SPF (TXT) record exists, append the following to the existing TXT record value: "include:a._spf.brightspace.com".
Lookup Limits:
Only 10 DNS queries may occur during SPF record evaluation, each root "include:" mechanism as well as any recursive evaluations contribute to the total count. Refer to: RFC 7208, 4.6.4: DNS Lookup Limits for full details.
DKIM record
To simplify management and rotation of DKIM keys for non-Brightspace mail domains, CNAME records are used to reference Brightspace-generated private and public domain key pairs. The private key will be used to sign emails, generating a DKIM-Signature header containing digital signature information. The public key will be used by recipient mail systems in decoding the header, verifying the signature and domain identity.
If requesting DKIM enablement, via a Service Catalog request, create two new CNAME records using the following format:
d2lmail1._domainkey.{MailDomain} CNAME d2lmail1._domainkey.brightspace.com
d2lmail2._domainkey.{MailDomain} CNAME d2lmail2._domainkey.brightspace.com
Although DKIM specifications (DKIM RFC 6376, 3.6.2: DNS Binding) indicate a TXT resource record is to be used, DNS specifications (RFC 1034, 3.6.2: Aliases and canonical names) indicate CNAME records are to be followed until the desired record type is found, which successfully allows for DKIM verification.
DKIM key rotation
The active DKIM keys will be rotated 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.
DMARC record
A domain owner should publish a DMARC record to inform recipient mail systems what to do when emails from their domain fail to pass either SPF or DKIM checks. A TXT record is used to create the policy with at least two essential tags: v and p.
v: DMARC protocol version, currently v=DMARC1.p: What to do when emails fail the DMARC check, options include none, quarantine, or reject.
If new to DMARC, it is recommended to start with p=none to gather data and adjust mail configurations where appropriate. Update to use p=quarantine and eventually p=reject as familiarity with the system is increased. Refer to RFC 7489, 6.3: General Record Format for full details.