Domain-based Message Authentication, Reporting, & Conformance (DMARC) is an email authentication specification used to protect internet domains against attackers attempting to use those domains to send fraudulent email to users.
DMARC is used in conjunction with one or both of the following email authentication systems:
- Sender Policy Framework (SPF) identifies which mail servers are allowed to send email on behalf of a domain, preventing attackers from sending fraudulent emails using that domain name. The list of authorized mail servers is contained in a specifically formatted SPF TXT record, which is published in the Domain Name System (DNS) records for the sending domain.
- DomainKeys Identified Mail (DKIM) enables an organization to associate a domain name with an email message allowing the receiver to validate the sender. For added security, by employing a mechanism to sign outgoing messages with a private key, allows receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators. DKIM can be enabled for organizations using a custom mail domain by submitting a Service Catalog request.
Sent messages
In early 2016, Google and Yahoo implemented stricter DMARC policies to their email services to protect more types of email. For organizations that use Google or other third-party email services, this might impact the configuration of email in Brightspace.
Depending on your configuration, when an individual sends an email, the FROM address is listed as that individual's email address. This is helpful for the recipient in identifying the sender but may cause problems when the sender's email is an external domain.
For example: if the organizational email domain is hosted by Gmail and a learner with an email address using the Gmail domain sends an email to another learner with a Gmail account, Gmail rejects the message. This is due to Gmail's DMARC "p=reject" record D2L servers sending the email are not approved to send on behalf of the Gmail-hosted email domain. If the email message was signed with additional information, Gmail allows the email to be received.
Forwarded messages
Emails forwarded from D2L servers appear to originate from a sender’s D2L domain - in the format of {username}@{D2LMailDomain} - instead of the original (external) sender account. Email headers show the new FROM address as the user’s D2L email address, and the REPLY-TO address as the original sender’s (external) email address.
Example of how forwarded emails appear:
Reply-To: {OriginalSender}@{ExternalDomain}From: {Student}@{D2LMailDomain}To: {Student}@{ExternalMailDomain}Subject: FW: Example Email
------------------------------------
At {HH:MM AM/PM} on {Long Format Date}, "{Original Sender}" <{OriginalSender}@{ExternalDomain}> wrote
Notes:
• If your organization filters/rejects emails based on the FROM address, the DMARC specification could cause email filters to function in unexpected ways. You may need to adjust filters to account for this email forwarding standard.
• Refer to Best practices for outgoing mail to ensure you have correctly configured SPF and CNAME records for your organization. If you do not set up the SPF correctly for the D2LMailDomain, then your organization or external mail providers with very strict spam policies will reject correctly forwarded email messages.