D2L Brightspace SPF, DKIM and DMARC setup, step by step

For Brightspace sending through an institution-owned mail domain, D2L documents include:a._spf.brightspace.com for SPF and two DKIM CNAMEs, d2lmail1 and d2lmail2, pointing to the corresponding selectors under brightspace.com. Request DKIM enablement through D2L's Service Catalog. Publish both aliases, complete activation with D2L, and verify that a new message has the intended aligned DKIM signature and dmarc=pass. D2L manages authentication for its default Brightspace mail domains. Outgoing-mail instructions, default mail configuration.

This guide describes a documented workflow; no customer account, DNS zone or delivered message was tested.

On this page: Choose the route · Prerequisites · SPF · DKIM · MX · DNS checks · DMARC · Message tests · Troubleshooting · FAQs

Choose the Brightspace mail route

The default route covers system, notification and user-generated mail. A custom website URL is a separate decision from the mail domain. D2L says the custom mail name must differ from the site-access name to avoid CNAME conflicts. A familiar school logo or Reply-To address does not tell you which domain is being authenticated. Default identities, custom mail domain.

Have the Brightspace administrator review d2l.Tools.Mail.D2LMailDomain and any d2l.Tools.Mail.D2LMailDomainOverrides. The latter permits matching external domains to be used as From addresses. Do not broaden overrides as an authentication shortcut. This guide supplies no unsourced administrator-menu path. D2L mail configuration variables.

Prepare the domain and change plan

Before DNS changes, identify:

• The Brightspace environment, approved mail domain, D2L support contact and administrator able to request Service Catalog changes.
• Every intended From domain, including departmental overrides, system notifications and forwarding paths.
• The domain's DNS administrator and authoritative zone, including any delegated child zone.
• Existing SPF, DKIM, DMARC and MX answers, their complete owner names, TTLs and affected services.
• Whether replies must be received, and whether the environment uses Full Mail or an outgoing-only arrangement.
• A controlled test mailbox, synthetic message content, the change window and an agreed rollback owner.

Do not authorize sending as consumer domains you do not control. D2L states that DMARC is unsupported for a non-D2L domain the organization does not own. Keep student records, real class lists and production notification audiences out of the test. Domain ownership requirement.

Configure SPF at the correct owner

SPF evaluates the SMTP MAIL FROM identity, normally reflected in the delivered Return-Path. The receiver's smtp.mailfrom result is more useful than guessing from the visible From address. SPF at a parent does not automatically apply to a child domain. RFC 7208.

D2L's published authorization is include:a._spf.brightspace.com. If the approved mail-domain owner has no SPF record and the sender inventory justifies a D2L-only policy, the documented standalone example is:

Type: TXT
Full owner: mail.example.com
Value: v=spf1 include:a._spf.brightspace.com ~all

mail.example.com is fictional. Replace it with the confirmed custom mail domain. ~all means SPF softfail, not neutral and not a promise to accept mail. The custom-domain page lists a 60-minute SPF TTL; use a TTL approved for your deployment. D2L SPF instructions, record table.

If a policy exists, insert the include into that one policy before its terminal all, preserving other legitimate senders and its approved ending. A policy using redirect= needs evaluation rather than blind appending. Never replace the institution's Microsoft 365 or Google Workspace authorizations just to add Brightspace. See merging SPF records safely.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Evaluate the complete policy, not just the new include. SPF permits at most 10 evaluated DNS-lookup-causing terms, including nested evaluations: include, a, mx, ptr, exists and redirect. ip4, ip6 and all do not consume that term budget. This is not a count of DNS packets or just top-level includes. Additional address-query limits apply to mx and ptr; implementations should limit void lookups to two. Exceeding the term limit produces permerror. Do not copy today's resolved D2L addresses into a static flattened policy to conceal an error. RFC 7208 lookup limits.

Publish both DKIM aliases and request activation

Request DKIM enablement through D2L's Service Catalog, naming the exact custom mail domain and affected routes. Publish both documented aliases for that domain:

The selector targets are D2L-published values; the institution-specific mail-domain suffix must match the request. Do not invent a tenant selector, upload a private key or replace these aliases with a copied public key. Confirm that D2L has enabled signing after DNS is available. Merely creating the records does not establish activation. Service Catalog and DKIM records.

D2L documents a six-month active-key rotation. Keep both CNAMEs even when current messages use only one selector. Both are needed for rotation continuity. Rotation behavior.

Place records in the actual authoritative zone

For d2lmail1._domainkey.mail.example.com, enter d2lmail1._domainkey.mail when editing an example.com zone that serves the name. If mail.example.com is separately delegated, its child-zone editor normally needs d2lmail1._domainkey. Repeat for selector 2. Inspect the completed name to prevent a doubled suffix.

A CNAME cannot coexist with ordinary TXT, A or other record data at the same owner. Stop on a collision and identify the dependent service instead of deleting its record. Preserve legitimate child-zone and _domainkey NS delegation; publish through that namespace's actual DNS administrator. Keep the aliases DNS-only, with each record's Flatten off, and verify that zone-wide settings do not flatten these names. Coordinate any shared or zone-wide setting change with the DNS owner after reviewing its effects on other services. Do not remove delegation or change a shared setting merely to make one record visible. Cloudflare's CNAME verification guidance.

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

Keep MX and reply routing separate

D2L requires an MX record for the outgoing mail domain, but it need not replace the institution's mailbox routing. An approved institutional endpoint can receive replies. The default D2L endpoint does not retain or process messages as a normal mailbox.

For an outgoing-only custom domain using D2L's default endpoint, contact D2L before adding MX so its gateway is configured. D2L warns that skipping this can create routing loops. Only after confirmation, the documented value is gourmand.brightspace.com, priority 10, at the approved custom mail-domain owner. The documented TTL is 24 hours. Do not apply this to the institutional root or Full Mail indiscriminately. Current MX requirements and values.

Full Mail uses a separate region-specific endpoint. Have D2L confirm the environment's region and current hostname from that same table. Geographic location alone does not identify the tenant's routing. Save the approved owner, target and priority, and include reply delivery in acceptance where required.

Check public DNS before acceptance

These are reader-run commands, not test results. Replace the variables with confirmed values. ZONE is the authoritative parent or delegated child zone, not automatically the From domain.

ZONE='example.com'
AUTH_NS='ns1.dns-host.example'
MAIL_DOMAIN='mail.example.com'
MAIL_FROM_DOMAIN='mail.example.com'

dig +short NS "$ZONE"
dig @"$AUTH_NS" "$MAIL_FROM_DOMAIN" TXT +norecurse
dig @"$AUTH_NS" "d2lmail1._domainkey.$MAIL_DOMAIN" CNAME +norecurse
dig @"$AUTH_NS" "d2lmail2._domainkey.$MAIL_DOMAIN" CNAME +norecurse
dig @"$AUTH_NS" "$MAIL_DOMAIN" MX +norecurse
dig "d2lmail1._domainkey.$MAIL_DOMAIN" TXT
dig "d2lmail2._domainkey.$MAIL_DOMAIN" TXT
dig "$MAIL_DOMAIN" MX
dig "$MAIL_FROM_DOMAIN" TXT
dig "_dmarc.$MAIL_DOMAIN" TXT

Use NS delegation and SOA evidence to identify authority. An empty NS answer for mail.example.com alone does not mean the subdomain is broken: the parent may serve it. Confirm authoritative answers from the correct zone and compare public recursive results after positive and negative caches expire.

Expected results are one SPF policy at the actual envelope owner, both exact D2L CNAME targets and a usable DKIM public key when the alias is followed. For MX, compare the complete approved set of full owner, numeric priority and target hostname against both authoritative and recursive answers. A nonempty MX response is insufficient: preserve the approved inbound/reply design and investigate missing or unexpected entries without replacing unrelated mailbox routing. Check the actual From domain's DMARC policy separately if it differs from MAIL_DOMAIN. A full response distinguishes NXDOMAIN, NOERROR without the queried type, and SERVFAIL. Resolve wrong delegation, DNSSEC failures and suffix errors rather than waiting indefinitely for propagation.

Preserve DMARC policy and authorize reporting

DMARC passes when SPF or DKIM both passes and aligns with the visible From domain. Relaxed alignment uses the applicable organizational-domain match; strict alignment requires the exact domain. aspf and adkim set these modes and default to relaxed. A provider-domain signature can pass cryptographically without aligning. Reply-To is not the comparison target. RFC 9989 alignment.

Keep existing policy intact. Check _dmarc at each From domain and its applicable inherited policy before creating anything. RFC 9989 uses DNS-tree-walk discovery, supersedes RFC 7489 and removes the old pct tag. An empty direct lookup does not justify a child p=none that overrides an inherited enforcing policy. See DMARC policy inheritance.

Only if no direct or inherited policy applies, and the domain owner approves a monitored initial deployment, this fictional first-policy shape may be used:

For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

Type: TXT
Full owner: _dmarc.mail.example.com
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Provision and approve the real reporting address before publishing. p=none requests no DMARC-based disposition change; other filters may still reject mail. For an external reporting service, follow its authorization instructions: the report consumer normally publishes authorization at POLICY_DOMAIN._report._dmarc.REPORT_DESTINATION_DOMAIN, under its own DNS authority, not at a guessed school-side name. Reports can disclose sending infrastructure and traffic; approve the recipient, access and retention. Do not add failure reporting casually. RFC 9990 reporting authorization.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Do not raise enforcement based on one test. Inventory other senders and indirect routes. RFC 9989 section 7.4 says domains publishing p=reject must not rely solely on SPF and must apply valid DKIM signatures. For this branded deployment, require the intended DKIM pass and alignment, together with a receiver-observed DMARC pass. Current interoperability requirements.

Accept each Brightspace message path

After D2L confirms activation, have the authorized administrator generate controlled messages with synthetic content. Test system mail, notifications and user-generated mail separately, plus any external-domain override or forwarding route actually used. Do not email a live class to test authentication.

D2L documents forwarded mail using the user's D2L-domain From address and the original sender in Reply-To. Compare the resulting From identity, not the original author's address. Brightspace forwarding behavior.

For each route, save the actual From domain, envelope domain, DKIM d= and s=, time and workflow. Use receiver-controlled authentication diagnostics, or have the receiving administrator establish which Authentication-Results fields genuinely originated inside its trust boundary. Confirm how the boundary removes or clearly distinguishes external, sender-inserted results, including forged fields claiming its own authserv-id. A familiar authserv-id or a header's position alone is not proof of origin. Do not trust results pasted inside forwarded content. If provenance cannot be established, obtain receiver-side diagnostic evidence before accepting the result. RFC 8601 forged-header safeguards.

Accept the route when:

1. The message uses the approved From identity and the intended D2L selector.
2. The intended custom-domain signature has dkim=pass and aligns under the actual adkim mode.
3. The trusted receiver reports dmarc=pass; identify which aligned mechanism supplied it.
4. SPF is evaluated at the observed MAIL FROM domain without unexplained errors, and its alignment status is recorded separately.
5. Reply handling works as agreed, and no alternate message class remains assumed rather than tested.

A DMARC pass supplied only by SPF does not complete a custom-DKIM commissioning exercise. An unrelated passing signature also does not prove D2L used the configured domain. Conversely, investigate actual SPF fail, softfail, permerror or temperror separately even when aligned DKIM supplies a DMARC pass; that pass does not resolve an SPF fault. Recheck after rotation, domain changes, overrides or gateway changes; review aggregate reports for wider coverage. None of these results guarantees inbox placement.

Troubleshooting and recovery

Restore only the approved changed values if rollback is necessary. Keep unrelated mail services, old valid selectors and established DMARC policy intact; coordinate D2L-side rollback so DNS and signing do not diverge. Do not replace this diagnosis with IP allowlisting or bypassing authentication. D2L explicitly discourages those bypasses because cloud sending addresses can change. D2L default-mail guidance.