Configure Docebo Learn email authentication in Domain management > Email sender domains. For the Built-in email service, publish the SPF and DKIM records displayed for the sender domain, then run Test DNS configuration. For Custom SMTP, authenticate the external mail provider and authorize the notification’s From address there. Finish with a real platform notification and a trusted receiver’s authentication results. Docebo email-domain configuration
This guide covers Learn platform notifications and self-registration mail. A learning-site custom URL, an Extended Enterprise secondary domain and a sender domain serve different purposes. Do not apply these instructions to another Docebo product’s mail service.
Decide which service actually sends the message
Start with a small route inventory: notification type, visible From address, configured sender domain, Built-in or Custom SMTP, and owner responsible for delivery. Include self-registration and any separately configured newsletter or notification sender. A working administrative test does not prove every event uses that same identity.
Docebo requires you to own the sender domain. Its current documentation accepts second- through fifth-level sender domains and warns against reusing a custom or secondary platform domain, where a website CNAME can conflict with email records. Choose a distinct related name, such as mail.example.com, only after checking existing DNS use. Addresses ending in @docebo.com are no longer an available fallback sender choice. Sender-domain prerequisites
You need administrative access to Domain management and a DNS administrator for the authoritative zone. Custom SMTP additionally requires the Custom SMTP app to be activated. Without it, Docebo uses the built-in service. The reviewed page does not establish a universal subscription tier for that app; confirm availability in your platform rather than assuming every contract includes it.
If recipients should reply, provision a real receiving mailbox and appropriate MX records with your mail provider. Creating a sender domain in Docebo does not create a mailbox. Docebo’s delivery-support prerequisites include SPF, DKIM and MX; preserve existing receiving service rather than inventing Docebo MX targets. Email-domain requirements
The receiving-mail owner must approve the complete MX routing plan, not merely accept an authentication screenshot. Before activation, compare each full owner and its complete numeric-priority/target set at authoritative DNS and a recursive resolver with that approved plan. Stop on missing, extra, mismatched or unapproved entries. Preserve existing inbox routing, parent nameservers, DNSSEC and forwarding; no universal Docebo MX destination is established here. MX record fields.
Add the domain in the current interface
Open Navigation menu > Configuration > Platform setup and tools > Domain management. In Email sender domains, choose New domains and certificates > New email sender domain. Enter the owned domain and select Create and edit. In General, select the delivery route. Current administration workflow
The legacy Advanced Settings > Email Preferences > Manage DKIM Keys route appears in older tutorials. Use the current Domain management workflow rather than searching indefinitely for an older control or combining instructions from both generations.
Before editing DNS, save the current records and TTLs. Identify exactly which owner will change. A TXT record on example.com does not automatically apply to mail.example.com; the DNS editor’s @ means the current zone apex, not whichever domain you intend to authenticate.
For an illustrative issued owner SELECTOR._domainkey.mail.example.com, a suffix-appending editor for example.com uses SELECTOR._domainkey.mail; one for a separately delegated mail.example.com uses SELECTOR._domainkey. If _domainkey.mail.example.com itself is delegated, use SELECTOR with that zone's administrator. A full-name field takes the complete owner. Use the actual account selector, not this placeholder. Preserve existing NS delegations and active selectors, and publish with the actual authority rather than adding an inactive parent-zone copy. Do not change nameservers, DNSSEC, mailbox MX or forwarding merely to publish a key. DNS zone boundaries.
Built-in service: publish the generated SPF and DKIM records
Selecting Built-in email service displays SPF and DKIM information for the chosen sender domain. Copy the complete owners, record types and values from that screen. Do not borrow a selector or public key from another account. Only public-key data belongs in DNS; Docebo’s managed signing private key is not something to generate externally or publish yourself.
The official DNS requirements identify include:docebosaas.com and give this new-policy example:
v=spf1 mx include:docebosaas.com ~all
This is a documented example, not a replacement for an existing policy or the account’s displayed requirements. Its mx mechanism authorizes the domain’s MX hosts and consumes SPF lookup budget. Do not add it blindly if those hosts are not intended outbound senders. Have the DNS owner reconcile the displayed policy with your real sending inventory.
Specifically, mx authorizes the applicable A/AAAA addresses of the resolved mail exchangers. Compare those addresses against approved outbound senders; receiving mail alone does not authorize that host to send training notifications. SPF mx mechanism.
If SPF already exists at the required owner, merge the necessary authorization into that single policy. Preserve other legitimate services and the intended final all qualifier. Never create separate SPF records for Docebo, Microsoft 365 and another application at the same name. Include nesting counts toward RFC 7208’s limit of ten evaluated DNS-querying terms. SPF standard
If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed redesign. SPF qualifiers describe authentication results, not guaranteed receiver delivery or rejection decisions. SPF all and redirect processing.
For DKIM, preserve the exact public-key characters. If a DNS service requires long TXT data to be split into quoted strings, keep them within one TXT record so they concatenate to the original value. Docebo specifically points Route 53 users to this issue. Do not create separate record rows for fragments, or add an extra domain suffix to the selector owner. DNS record guidance
Allow previous TTLs to expire, then return to the domain and select Test DNS configuration. A missing DKIM record can leave messages without the intended signature even when sending still appears to work. A successful application check is a prerequisite for the next stage, not proof of receiver-side DMARC alignment. Validation behavior
Custom SMTP: authenticate the external sender
With the app enabled, select Custom SMTP server and enter the provider’s hostname, port and authorized account credentials. Choose encryption to match the host: Docebo labels immediate encrypted connection TLS, typically port 465, and the upgraded connection StartTLS, typically port 587. Its Microsoft 365 guidance selects StartTLS. Do not disable transport security to get a connection test to pass. Custom SMTP instructions
Run Test connection, then Save changes. To repeat a test after saving, the documentation says you may need to re-enter the password; the domain list’s ellipsis Check validation offers another test path. Keep passwords out of DNS, screenshots and support attachments.
The connected account must be permitted to send as the address configured in each notification. Successful SMTP login does not grant permission to impersonate every address under a domain. Configure SPF, DKIM and any custom return-path at the external provider using its instructions, then test the message that Docebo actually submits. Do not add Docebo’s built-in include merely because Docebo initiated the workflow.
Confirm recipient, concurrency and daily-volume limits before enabling high-volume events. Docebo warns that SMTP-provider limits can cause notifications to miss some recipients and that Microsoft 365 SMTP is not the best fit for high-volume platform sending. DNS changes cannot fix quota exhaustion or a denied Send As permission. Provider limits and sender authorization
If the selected external route is Microsoft 365, use its authentication guide for that tenant's SPF/DKIM configuration. This does not resolve Docebo notification volume or Send As limits.
Apply DMARC without weakening the domain
SPF authenticates the SMTP MAIL FROM identity, usually reflected in Return-Path. DKIM authenticates the signing domain in the signature’s d= field. DMARC compares those authenticated identities with the visible From domain. One passing aligned mechanism is enough for DMARC, although maintaining both SPF and DKIM is valuable. RFC 9989 and DKIM, RFC 6376
Relaxed alignment permits matching organizational domains; strict alignment requires an exact match. A passing DKIM signature from the SMTP provider’s unrelated domain is not aligned authentication for your training brand.
Read the existing DMARC record and any applicable parent policy before making changes. Keep established enforcement and authorized reporting; do not replace them with a tutorial default. Only if no direct or applicable inherited policy exists, and the owner approves an appropriate monitoring plan after reviewing all senders, may a first TXT policy use this illustrative value:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
This example needs an approved reporting destination. It requests monitoring, not guaranteed delivery. Do not use the obsolete pct tag for staged enforcement under RFC 9989. Advance enforcement only after all legitimate routes have been assessed, not after one Docebo test.
For fictional From example.com, publish that TXT at full owner _dmarc.example.com, relative _dmarc in zone example.com. For From mail.example.com, use full _dmarc.mail.example.com: relative _dmarc.mail in the parent zone or _dmarc in a separately delegated mail.example.com zone. A full-name field takes the complete owner. These mappings do not authorize a child override of inherited policy.
Use aggregate reports to observe sources and failures. RFC 9991 failure reports can expose message information and need a separate deliberate privacy decision.
Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, which is 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 the policy domain is excepted; a different hostname alone does not make it external. Follow the report receiver's exact authorization instructions when needed. This protocol check is separate from the domain owner's approval to share report data with that recipient. RFC 9990 section 4.
Verify DNS and actual notification acceptance
These commands are illustrative. Replace mail.example.com and selector with your sender domain and the selector displayed in your account or a delivered signature:
dig TXT mail.example.com +short
dig TXT selector._domainkey.mail.example.com +short
dig MX mail.example.com +short
dig TXT _dmarc.mail.example.com +short
Confirm the exact record owner, one SPF policy, complete public DKIM key and the complete approved MX set. Missing _dmarc at a subdomain does not establish absence of protection; check applicable parent policy. If the actual sending provider issues a CNAME for a particular route, query that exact alias before following its target, and do not put TXT, A, AAAA, MX or a second CNAME at the same owner. This conditional branch does not turn Docebo's displayed TXT key into a CNAME or reuse the separate learning-site web CNAME.
Where literal CNAME answers are required, use DNS-only aliases returning the exact issued targets, without HTTP proxying or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone-wide settings preserve those aliases. Cloudflare documents that flatten-all cannot be overridden per record, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sending service. Do not blindly change the whole zone or remove an existing NS delegation. Cloudflare CNAME verification, flattening controls and limits.
For an empty answer, rerun without +short and inspect status and authority sections. NXDOMAIN, no data, SERVFAIL and a timeout require different repairs. Compare authoritative DNS with a public resolver before attributing a mismatch to propagation.
Next, trigger a harmless notification and a representative self-registration flow to test recipients you control. Use the trusted final receiver’s Authentication-Results and keep the following evidence, redacted where needed:
Establish which results were generated inside the receiving service's known processing boundary and how that service removes, ignores or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving-mail administrator to confirm the boundary. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain receiver-controlled diagnostic evidence when provenance is uncertain. Operational receiving-result trust.
- Expected visible From address and domain, not merely the display name.
- Actual envelope identity and
spf=pass, with its alignment assessed under effectiveaspf. dkim=pass, its signing domain and selector, with alignment assessed under effectiveadkim.dmarc=passfor the intended From domain, supported by at least one aligned passing mechanism.- Receipt of the expected notification, working reply handling when needed, and any receiving error or bounce.
For custom-domain completion, require the intended branded DKIM signature to pass and align with the visible From under the effective adkim mode, as well as receiver-confirmed dmarc=pass. DMARC success carried only by SPF does not prove that DKIM setup is complete. Investigate the actual envelope identity and sending IP if SPF returns fail, permerror or temperror, even when aligned DKIM allows DMARC to pass. Distinguish a forwarding-related SPF failure from an incorrect original-sender policy, and distinguish persistent syntax/lookup errors from temporary DNS failures. Authentication-Results trust boundary
Do not trust a header merely because it is named Authentication-Results; use the one inserted by the receiving system you control. Retest other configured sender domains and external SMTP routes independently. Authentication does not promise inbox placement, timing or recipient acceptance.
Diagnose common Docebo failures
The website works but sender validation fails. Check whether the email domain was mistakenly reused as the platform’s custom CNAME name. Preserve the functioning website and choose the supported email-domain design; do not overwrite its CNAME with TXT.
DNS checks pass but notifications are missing. Identify the exact event, sender domain and route. Confirm the event was triggered and the recipient eligible, then inspect queue or bounce evidence and SMTP-provider volume limits. A green DNS check cannot establish that a message was generated or accepted.
DKIM key exists but there is no aligned signature. Compare the signature’s selector/domain with the record you queried. Check whether the event uses another sender domain or an external SMTP service. Recheck Docebo validation and avoid treating a provider-owned signature as branded signing.
The SMTP connection test fails. Verify hostname, port, encryption and provider authentication requirements. A 465/TLS versus 587/StartTLS mismatch is a documented failure cause. SPF edits cannot repair connection authentication.
Only some From addresses fail. Verify each notification sender’s authorization at the SMTP provider. A single connected account may not be permitted to send as every configured identity.
A previously working domain was deleted. Docebo warns that affected messages can move to an untrusted gateway after deletion. Do not delete a domain as a troubleshooting reset. Restore the supported configuration with the administrator and test the affected workflows. Domain-management actions