For Brightspace, the working setup is simple: use a custom Brightspace mail domain you own, authorize D2L with SPF, publish the two D2L DKIM CNAME records, then add a DMARC record for the visible From domain. I treat Brightspace as a normal third-party sender: DNS first, real message test second, DMARC reporting last.
D2L documents the core requirement in D2L guidance: the custom mail domain needs SPF and CNAME records so Brightspace can send on your behalf. Brightspace supports return-path domain matching, so SPF is worth configuring, not just DKIM.
Records you will publish
- SPF: Add include:a._spf.brightspace.com to the SPF record for the Brightspace sending 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 inherit a strict parent-domain policy only after Brightspace passes.
Add your domain
Use a Brightspace custom mail domain such as mail.example.edu or notifications.example.edu. I avoid using the same hostname as the Brightspace login URL because D2L notes that custom email domains should be separate from custom site URLs.
Brightspace admin screen showing 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 DMARC support does not apply cleanly.
- Open the request: Ask D2L to enable the custom mail domain and DKIM signing for that domain. D2L generates and maintains the private key while you publish the CNAME records.
- Set Brightspace mail: In Brightspace administration, set the custom mail domain for system email and notification email so course notifications use your approved domain.
- Plan replies: If learners reply to Brightspace mail, point MX records to your own mail server. If replies are not needed, coordinate the D2L gateway option with D2L before publishing MX.
|
|
|
|---|---|---|
Sender | Brightspace | Course mail source |
Domain | Subdomain | Cleaner DNS scope |
SPF | TXT | Authorizes D2L |
DKIM | CNAME | Keeps 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 Brightspace return path. If you use mail.example.edu as the Brightspace mail domain, publish SPF at that hostname. If Brightspace sends directly as example.edu, publish it at the root domain.
- Find the current SPF: Check whether the Brightspace sending domain already has an SPF TXT record. A domain must have one SPF record, not several.
- Add D2L include: Add include:a._spf.brightspace.com to the existing SPF record, before the final all mechanism.
- Create if missing: If no SPF record exists, create one with the D2L include and a soft-fail ending while you test.
- Watch the limit: Keep SPF under 10 DNS lookups. Brightspace is only one sender, so review every include on the same domain.
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 permerror results. I merge Brightspace 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 today, because D2L rotates the signing key every six months and the standby key needs to be ready before rotation.
Brightspace custom mail domain screen showing two DKIM 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 only: Do not replace the CNAME target with a copied public key unless D2L specifically instructs you to do that for your tenant.
- Wait for DNS: After publishing, wait for TTL expiry, then send a Brightspace notification and inspect DKIM authentication results.
DKIM CNAME recordsDNS
d2lmail1._domainkey.mail.example.edu CNAME d2lmail1._domainkey.brightspace.com d2lmail2._domainkey.mail.example.edu CNAME d2lmail2._domainkey.brightspace.com
Good DKIM setup
- Both selectors: The two D2L CNAME records exist and resolve publicly.
- Matching domain: The DKIM signing domain matches the Brightspace From domain or its organizational domain.
- Rotation ready: The standby selector is already in DNS before D2L rotates keys.
Common DKIM failure
- One selector: Only d2lmail1 exists, so the next key rotation causes DKIM failures.
- Wrong host: The CNAME is placed at the root domain instead of under the Brightspace mail domain.
- Flattened target: The CNAME target is replaced with stale TXT data and no longer follows D2L key updates.
Set up DMARC
DMARC belongs on the visible From domain used by Brightspace. Start with p=none so you can collect reports without blocking course notifications. If your domain already uses p=quarantine or p=reject and Brightspace already passes, stick with that stricter policy.
- Choose the host: For mail.example.edu as the visible From domain, publish DMARC at _dmarc.mail.example.edu or rely on the parent policy only after confirming subdomain handling.
- Add reporting: Send aggregate reports to a mailbox or DMARC platform that can parse XML into source-level pass and fail data.
- Use the generator: Build a clean starting record with the DMARC record generator if you do not want to hand-write tags.
- Check policy inheritance: If the parent domain has a strict subdomain policy, make sure Brightspace passes before you change the From domain.
Starter DMARC recordDNS
_dmarc.example.edu TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
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 for your custom mail domain.
- SPF pass: The return-path domain should pass SPF through a._spf.brightspace.com when Brightspace sends from your configured domain.
- DMARC pass: At least one of SPF or DKIM must pass and match the visible From domain according to DMARC rules.
Verify and troubleshoot
I verify Brightspace with a real message, not only 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 notification screen used to send a test email.
- Send a test: Trigger a real Brightspace notification, announcement, enrollment message, or system email from the configured domain.
- Inspect headers: Check Authentication-Results for SPF pass, DKIM pass, and DMARC pass. Also confirm the From domain is the domain you planned to authenticate.
- Use the tester: Send the Brightspace test message to the email tester below for a full diagnostic view of headers, DNS, and authentication results.
- Review reports: After 24-48 hours, inspect DMARC aggregate reports for D2L source traffic and confirm it is passing consistently.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
|
|
|
|---|---|---|
SPF fail | Missing include | Merge D2L include |
SPF permerror | Too many lookups | Reduce includes |
DKIM fail | Bad CNAME | Fix selector host |
DMARC fail | Domain mismatch | Fix From domain |
No reports | Bad rua | Check mailbox |
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.
Get alerted when it breaks
Brightspace authentication breaks in practical ways: someone edits SPF, a DNS provider changes a CNAME, a subdomain policy gets tightened, or a D2L selector rotation exposes a missing DKIM record. Suped's product is the best practical choice for monitoring this because it turns DMARC XML into source-level issues with exact fix steps.
- Monitor Brightspace: Use Suped's DMARC monitoring to watch Brightspace volume, DKIM pass rates, SPF pass rates, and DMARC policy results by source.
- Catch DNS drift: Enable real-time alerts for new failures so a missing Brightspace selector or SPF edit is caught before course mail delivery drops.
- Find the fix: Use automated issue detection to see whether the failure is SPF, DKIM, DMARC policy, rDNS, or DNS record syntax.
- Track reputation: Use unified DMARC, SPF, DKIM, blocklist (blacklist), and deliverability views when Brightspace mail starts landing in spam folders.
Alert rules I care about
- New source: Alert when a new source starts sending as the Brightspace domain.
- DKIM drop: Alert when Brightspace DKIM pass rates fall below the normal baseline.
- Policy impact: Alert before a move to quarantine or reject starts affecting real course notifications.
Brightspace authentication checks
Example of the pass and fail split I want to see before tightening policy.
Pass
Fail
Secure your domain with p=reject
Move Brightspace to p=reject only after reports show every legitimate Brightspace message passes DMARC. I do not move on a single test email. I want enough report data to cover course notifications, enrollment mail, announcements, password workflows, and any region-specific D2L mail path your tenant uses.
- Start at none: Use p=none until Brightspace is visible in reports and both SPF and DKIM are healthy.
- Fix all sources: Resolve unrelated senders using the same domain before blaming Brightspace. DMARC policy applies to the domain, not only one platform.
- Stage quarantine: Move to p=quarantine or a low percentage only after Brightspace has steady pass results.
- Reach reject: Move to p=reject when no legitimate Brightspace traffic fails DMARC and your helpdesk is ready for rare sender exceptions.
- Use hosted policy: Suped's Hosted DMARC lets you stage policy changes cleanly without repeated DNS edits, which is useful when education mail sources change during term setup.
Readiness for p=reject
Use these thresholds before enforcing a reject policy on a Brightspace sending domain.
Ready
98-100%
Brightspace and every known sender passes DMARC consistently.
Investigate
90-97%
Most mail passes, but failures still appear by source or subdomain.
Do not enforce
<90%
Legitimate mail still fails SPF, DKIM, or DMARC.
Final strict DMARC exampleDNS
_dmarc.example.edu TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"
Safe move to reject
- Evidence: Suped shows Brightspace passing DMARC across normal mail types.
- Coverage: SPF, DKIM, and report parsing cover the whole sending domain.
- Rollback: Hosted policy or documented DNS access is ready if a sender is 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: Marketing, student systems, and Brightspace all send from the same domain without source review.
