D2L has recently invested in hardware and technology to implement DMARC policies in the D2L Cloud. This is not a product change, although that is being planned (see PIE # D2689!), it is foundational work to improve how the application generates, sends, and receives mail in the future. Many other well-known email providers have already implemented DMARC and are actively rejecting emails received that do not meet the DMARC standard.
What Is DMARC?
DMARC (Domain-based Message Authentication, Reporting & Conformance) is the new standard for email services to easily determine legitimate mail vs SPAM or Phishing. DMARC policies build upon already existing email formalities like Sender Policies and Domain Key Identification to allow senders and receivers to protect and monitor their domain from fraudulent email. For more background, check out DMARC and email authentication.
- Sender Policy Framework (SPF) prevents sender address forgery by allowing the owner of a domain to specify which mail servers can send on their behalf. The list of authorized mail servers is published in a specifically formatted Domain Name System (DNS) SPF TXT record.
- DomainKeys Identified Mail (DKIM) adds a digital signature associated to a domain name to email messages allowing the receiver to validate the sender. The public key of a pair is published in a specifically formatted Domain Name System (DNS) DKIM TXT record.
Figure: DMARC flowchart.
Image Source: DMARC.org
What Is D2L Doing About This?
To start, we’ve added DMARC info to Community (download attachment and see section DMARC and email authentication) through our non-release updates process. It describes different mail configuration scenarios and includes DMARC details which are also summarized below.
D2L has put DMARC servers and processes in place to ensure mail sent through the D2L Cloud with Client-owned domains are successfully validated by receiving organizations. These servers encrypt and generate DKIM/DMARC headers, validate DKIM and DMARC fields, store DMARC results for further processing, and are programmed to generate policy reports.
One of the key components of using DKIM is that sent emails must be signed. With new infrastructure in place, the D2L Cloud is now ready to begin verifying incoming emails and securely signing outgoing emails. This will reduce SPAM to the Learning Environment.
What Should You Do Next?
Short answer? If you are using a branded mail domain to send email through Brightspace, you should have your DNS provider publish SPF and DKIM records with the values specified below. This will need to be done for any domains that are used to send mail from the Learning Environment – the default MailDomain, and any other domains used for sending system notifications.
- Create or edit a TXT record to include the D2L SPF record:
- {Client mailDomain} TXT "v=spf1 include:a._spf.brightspace.com"
- For example:
- mail.example.com TXT "v=spf1 include:a._spf.brightspace.com"
- Create 2 CNAME records pointing to the D2L public DKIM keys:
- Reach out to your TAM, CSM, or to Support to let them know you are ready for D2L to begin signing your emails with DKIM headers
**Replace {Client mailDomain} with the branded mail domain in use within your environment
Long Answer? There is no shortage of technical detail to discuss when it comes to the topic of email! Feel free to check out some of the other Mail Best Practices or MX records articles for more details and hopefully you found this introduction useful. Please add any questions in the comments below!
