How to set up DMARC/DKIM/SPF for Brightspace
Published 21 Jun 2026
Updated 25 Oct 2026
13 min read
Summarize with
Updated on 25 Oct 2026: We clarified Brightspace's DNS setup and the message checks required before enforcing DMARC.
For a custom Brightspace mail domain, the setup is direct: authorize D2L with SPF, publish the two D2L DKIM CNAME records, make sure the domain has an MX record, then publish DMARC for the visible From domain. Treat Brightspace as a third-party sender: publish DNS first, test a real message second, then use DMARC reports to confirm every mail path.
D2L documents the core requirements in D2L guidance: a custom mail domain needs SPF and DKIM records so Brightspace can send on your behalf. Confirm the actual Return-Path domain in a received message before relying on SPF for DMARC alignment.
Records you will publish
- SPF: Add include:a._spf.brightspace.com to the SPF record for the Brightspace return-path domain.
- DKIM: Create both D2L CNAME records, d2lmail1 and d2lmail2, because D2L rotates keys every six months.
- DMARC: Publish a DMARC TXT record on the visible From domain, or confirm how the custom domain inherits the parent policy.
- MX: Give every custom mail domain at least one valid MX record, even when replies are not required.
Choose the Brightspace mail model
Check the From domain on a recent Brightspace message before editing DNS. A default D2L-managed mail domain and a custom branded mail domain have different owners and setup tasks.
D2L-managed domain
- A domain such as mail.orgname.brightspace.com is controlled by D2L.
- D2L manages its MX, SPF, DKIM, and DMARC policy, so you do not publish those records in your DNS zone.
Custom branded domain
- A domain such as mail.example.edu is controlled by your organization.
- You publish the required DNS records and submit a D2L Service Catalog request to enable DKIM signing.
- Use only a domain your organization owns. D2L does not support DMARC for a non-D2L domain owned by someone else.
Configure the custom mail domain
Use a dedicated Brightspace mail domain such as mail.example.edu or notifications.example.edu. Keep it separate from the Brightspace login hostname because D2L does not allow a custom site URL to be the same as a mail domain or to be used for mail.
Brightspace administrator settings for a custom outgoing mail domain.
- Pick the domain: Choose a subdomain dedicated to Brightspace mail, for example mail.example.edu. This keeps Brightspace DNS separate from your main website and primary mailbox routing.
- Confirm ownership: Use a domain your organization owns. If the From domain belongs to a third party or a personal mailbox provider, Brightspace does not support DMARC for that setup.
- Open the request: Submit a D2L Service Catalog request to enable DKIM for each custom domain used in outgoing mail. D2L generates and maintains the private keys while you publish the CNAME records.
- Set Brightspace mail: Save the default mail domain in d2l.Tools.Mail.D2LMailDomain, following D2L's email setup instructions. Check the From addresses for system email and notification email, and authenticate each custom domain they use.
- Plan MX routing: Publish at least one MX record for every custom mail domain. Point it to your mail server when replies are needed. Contact D2L before using its send-only gateway to prevent routing loops. That endpoint does not store replies; Full Mail uses regional MX endpoints. Follow D2L's MX instructions to choose the correct destination.
|
|
|
|---|---|---|
Sender | Brightspace | Course mail source |
Domain | Owned subdomain | Defines DNS scope |
MX | MX | Handles replies and responses |
SPF | TXT | Authorizes D2L |
DKIM | CNAME | Supports key rotation |
DMARC | TXT | Controls policy |
Use the table to keep the Brightspace DNS scope tight before publishing records.
Set up SPF
Brightspace SPF belongs on the domain used in the Return-Path, also called the envelope From domain. If a received message uses mail.example.edu in its Return-Path, publish SPF at that hostname. Use the root domain only when the Return-Path actually uses example.edu. SPF records are not inherited by subdomains. The examples below are alternatives; preserve all approved senders when editing an existing record.
- Find the current SPF record: Check whether the Brightspace return-path domain already has an SPF TXT record. A hostname must have one SPF record, not several.
- Add the D2L include: Add include:a._spf.brightspace.com to the existing SPF record before its final all mechanism. Keep the include instead of copying D2L IP addresses, which change over time.
- Create the record if missing: D2L documents ~all as an optional soft-fail ending. Choose the final all qualifier according to your domain's mail policy.
- Watch the lookup limit: SPF evaluation permits no more than 10 DNS-querying mechanisms and modifiers. Count the D2L include and its recursive lookups with every other sender on that hostname.
Alternative SPF examplesDNS
mail.example.edu TXT "v=spf1 include:a._spf.brightspace.com ~all" example.edu TXT "v=spf1 include:a._spf.brightspace.com ~all" # If you already have SPF, merge the include into that record. v=spf1 include:_spf.example.net include:a._spf.brightspace.com ~all
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Do not publish duplicate SPF records
Multiple SPF TXT records on one hostname produce a permerror. Merge the Brightspace include into the existing record and verify the final DNS response before sending a test notification.
Set up DKIM
Brightspace DKIM uses two CNAME records under the sending domain. Publish both records even if only one appears active, because D2L rotates the signing key every six months and the standby key must resolve before rotation.
Brightspace DKIM setup showing the d2lmail1 and d2lmail2 selectors.
- Create selector one: Publish d2lmail1 as a CNAME under _domainkey for the Brightspace mail domain.
- Create selector two: Publish d2lmail2 the same way. Delivery can break after a D2L key rotation if one selector is missing.
- Use CNAME records: Do not replace a CNAME target with a copied public key unless D2L gives tenant-specific instructions to do so.
- Confirm signing: After both records resolve publicly, ask D2L to confirm DKIM enablement for the custom domain. Then send a Brightspace notification and inspect its DKIM result. Publishing CNAME records alone does not enable signing.
DKIM CNAME recordsDNS
d2lmail1._domainkey.mail.example.edu. CNAME d2lmail1._domainkey.brightspace.com. d2lmail2._domainkey.mail.example.edu. CNAME d2lmail2._domainkey.brightspace.com.
These examples use fully qualified DNS names. If your DNS editor automatically appends example.edu, enter d2lmail1._domainkey.mail and d2lmail2._domainkey.mail as the record names. Do not append your own domain to the Brightspace CNAME targets. Check cached results again after the previous TTL expires.
Good DKIM setup
- Both selectors: The two D2L CNAME records exist and resolve publicly.
- Matching domain: The DKIM signing domain has DMARC alignment with the Brightspace From domain.
- Rotation ready: The standby selector is already in DNS before D2L rotates keys.
Common DKIM failure
- One selector: Only d2lmail1 exists, so signing with the missing selector produces DKIM failures.
- Wrong host: The CNAME is placed at the root domain instead of under the Brightspace mail domain.
- Copied target: The CNAME target is replaced with stale TXT data and no longer follows D2L key updates.
Set up DMARC
DMARC policy applies to the visible From domain used by Brightspace. Start with p=none so you can collect reports without asking receivers to quarantine or reject course notifications. If the applicable DMARC record already uses p=quarantine or p=reject, confirm Brightspace passes before changing its From domain or DNS records.
- Choose the host: For mail.example.edu as the visible From domain, publish one DMARC TXT record at _dmarc.mail.example.edu. If absent, check the inherited policy; in this example, inspect _dmarc.example.edu and its sp tag, or p when sp is absent. Deeper domain hierarchies require checking policy discovery rather than assuming the immediate parent controls it.
- Add aggregate reporting: Replace the example RUA mailbox with a monitored address. If reports go to a different organizational domain, confirm that the destination authorizes external reporting, as specified in RFC 9990. A DMARC platform should provide its required report address and authorization instructions.
- Use the generator: Build a starting record with the DMARC record generator if you do not want to hand-write tags.
- Check domain alignment: DMARC passes when SPF or DKIM passes and that authenticated domain has the required relationship with the visible From domain.
Starter DMARC recordDNS
_dmarc.mail.example.edu. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.edu"
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
What should pass
- DKIM pass: A Brightspace message should pass DKIM with a D2L-managed signature whose signing domain has DMARC alignment with the From domain.
- SPF pass: The return-path domain should pass SPF through a._spf.brightspace.com when Brightspace sends from the configured custom domain.
- DMARC pass: At least one of SPF or DKIM must pass with domain alignment to the visible From domain.
Check SPF and DKIM domain alignment
Compare the visible From domain with smtp.mailfrom for SPF and header.d for DKIM in the receiving server's Authentication-Results header. RFC 9989 defines the domain comparison rules.
Illustrative received headers with matching domainstext
From: notifications@mail.example.edu Return-Path: <bounce@mail.example.edu> Authentication-Results: receiver.example; spf=pass smtp.mailfrom=mail.example.edu; dkim=pass header.d=mail.example.edu; dmarc=pass header.from=mail.example.edu
- Relaxed alignment is the default: aspf=r and adkim=r accept domains with the same organizational domain.
- Strict alignment: aspf=s or adkim=s requires an exact domain match for the corresponding authentication method.
A CNAME target under brightspace.com locates the public key; the signature's d= value identifies the signing domain. If that value is brightspace.com instead of your custom domain, ask D2L to check custom-domain signing.
Verify Brightspace email authentication
Verify Brightspace with a real message as well as DNS lookups. DNS proves the records exist. A live notification proves Brightspace is using the expected From domain, return path, DKIM selector, and signing domain.
Brightspace email notification settings for testing email authentication.
- Send a test: Trigger a real Brightspace notification, announcement, enrollment message, or system email from the configured domain.
- Inspect headers: Check the receiving server's Authentication-Results for SPF, DKIM, and DMARC. Confirm the header From domain, envelope From domain, DKIM selector, and signing domain match the planned configuration.
- Use the tester: Send the Brightspace message to the email tester below for a diagnostic view of headers, DNS, and authentication results.
- Review reports: Allow 24-48 hours for initial aggregate reports after sending test traffic, then review normal Brightspace sending patterns. Reports come from receiving providers, and timing and coverage vary.
- Test indirect delivery: Check forwarding and mailing-list routes used by your institution. Forwarding often breaks SPF; an unchanged DKIM signature can still support a DMARC pass.
DNS verification commands for the example domainBASH
dig +short MX mail.example.edu dig +short TXT mail.example.edu dig +short CNAME d2lmail1._domainkey.mail.example.edu dig +short CNAME d2lmail2._domainkey.mail.example.edu dig +short TXT d2lmail1._domainkey.mail.example.edu dig +short TXT d2lmail2._domainkey.mail.example.edu dig +short TXT _dmarc.mail.example.edu
Replace the example domain in these commands. Confirm that both CNAME targets match D2L's values and that TXT lookups through each selector return a public key. If the exact From domain has no DMARC record, inspect its inherited policy too. These checks verify DNS publication; the received test message verifies signing.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
|
|
|
|---|---|---|
SPF fail | D2L include missing at the actual Return-Path domain | Merge the include into that domain's existing SPF record |
SPF permerror | Duplicate SPF records or more than 10 lookup-causing terms | Keep one SPF record and reduce the evaluated lookup count |
DKIM fail or no signature | Wrong selector, unresolved CNAME target, or signing not enabled | Check both selector records and confirm D2L signing enablement |
DMARC fail | Neither authentication method passes with the required domain relationship | Compare the From domain with smtp.mailfrom and header.d, then correct the failing path |
No reports | Wrong RUA address, missing external authorization, or no reporting traffic | Verify the destination and authorization, send test traffic, and allow reporting time |
Keep troubleshooting tied to the authentication result that failed.
For a deeper checklist, use the related verification workflow for DMARC, DKIM, and SPF after the Brightspace DNS records resolve.
Monitor Brightspace authentication
Brightspace authentication can break when someone edits SPF, a DNS change removes a CNAME, a subdomain policy gets tightened, or a D2L key rotation exposes a missing selector. Suped is our DMARC reporting and email authentication platform. It parses aggregate reports into source-level results. Its notification settings let you set a DMARC failure percentage threshold and alert recipients.
- Monitor Brightspace: Use Suped's DMARC monitoring to review Brightspace volume, authentication results, and policy disposition by source.
- Set failure alerts: Configure a failure threshold and notification recipients. Alerts depend on aggregate report arrival, so investigate DNS changes directly when course mail is disrupted.
- Find the cause: Use issue detection to distinguish SPF, DKIM, DMARC policy, and DNS syntax failures.
- Investigate delivery: If DMARC passes but Brightspace mail lands in spam, inspect recipient filtering and any delivery error details. Authentication does not guarantee inbox placement.
Checks after a failure alert
- New source: Review unfamiliar sending IPs and confirm whether they belong to an approved Brightspace mail path.
- DKIM drop: Compare Brightspace DKIM results with the established baseline and check both selectors.
- Policy impact: Review failures before a move to quarantine or reject affects real course notifications.
Brightspace authentication checks
Illustrative percentages, not measured Brightspace results. SPF and DKIM show authentication results; DMARC also requires domain alignment.
Pass
Fail
Move a dedicated Brightspace domain to p=reject
For a dedicated Brightspace mail domain, move to p=reject only after reports show every legitimate Brightspace message passes DMARC. One test email is not enough. Collect report data that covers course notifications, enrollment mail, password workflows, and every D2L mail path used by the tenant.
For domains used by people who post to Internet mailing lists, RFC 9989 advises against p=reject. Assess those workflows separately; p=quarantine is a valid final policy when rejection would disrupt legitimate mail.
- Start at none: Use p=none until Brightspace is visible in reports and its legitimate mail passes DMARC.
- Fix all sources: Resolve other legitimate senders using the same domain before changing policy. DMARC policy applies to the domain, not only Brightspace.
- Stage quarantine: Move to p=quarantine after reports cover normal Brightspace sending patterns and unexplained failures have been resolved.
- Reach reject for a dedicated domain: Move to p=reject after direct and indirect delivery tests confirm legitimate mail passes and the team has a documented rollback path.
- Use hosted policy: Suped's Hosted DMARC supports staged policy changes after a one-time DNS delegation. Receivers see a policy change when they next refresh cached DNS data.
Readiness for p=reject
Use these checks for a dedicated Brightspace sending domain, including forwarding and mailing-list routes that carry its mail.
Ready
All known mail passes
Every known legitimate source passes DMARC across normal sending patterns and the indirect delivery routes in use.
Investigate
Unexplained traffic remains
An unknown source or unexplained authentication failure still appears in reports.
Do not enforce
Legitimate mail fails
A legitimate Brightspace message or another approved sender still fails DMARC.
Reject policy example for a verified dedicated domainDNS
_dmarc.mail.example.edu. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.edu"
Safe move to reject
- Evidence: Suped reports show Brightspace passing DMARC across normal mail types.
- Coverage: Every approved source and the indirect delivery routes using this dedicated domain have been reviewed.
- Rollback: Hosted policy or documented DNS access is ready if a sender was missed.
Risky move to reject
- Single test: One message passed, but aggregate reports still show unknown traffic.
- Missing DKIM: Only one D2L selector exists, so key rotation can break signing later.
- Shared domain: The domain is also used for people's email or mailing-list participation without assessing rejection impact.
FAQ
For a custom Brightspace mail domain, publish SPF even when DKIM passes. Verify the actual Return-Path before relying on SPF for DMARC alignment. D2L manages SPF for a default D2L-owned mail domain, so no SPF change is needed in your DNS for that path.
The SPF include a._spf.brightspace.com is for D2L Brightspace outgoing mail. Add it to the existing SPF record for the custom Return-Path domain Brightspace uses.
A brightspace.com reverse DNS (rDNS) suffix is a clue, not proof that a message is authorized. Confirm the From domain, Return-Path, DKIM signing domain, and source ownership before approving traffic in DMARC reports.
When Brightspace uses a default D2L-managed mail domain, D2L manages its MX, SPF, DKIM, and DMARC policy. Monitor your own domain only when a Brightspace workflow uses that domain in the visible From address.
Yes, but a dedicated subdomain such as mail.example.edu limits SPF complexity and separates Brightspace DNS from other institutional senders. The mail subdomain must not be the same hostname as the custom Brightspace site URL.
For a dedicated Brightspace domain, switch after reports cover normal sending patterns and legitimate sources pass DMARC, including the indirect routes in use. Keep shared user-mail and mailing-list workflows under a separately assessed policy. Suped's product groups reports by source and supports staged policy changes.
