Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Separate the learning-site domain from the mail domain
Docebo email-domain configuration controls notification and self-registration sending; it is not merely a branding setting for the learning website. The provider says not to reuse a custom or secondary platform domain as an email domain because the DNS requirements can conflict. Docebo also states that sender addresses under @docebo.com can no longer be used. Choose a distinct, related name you own, and identify both the DNS administrator and the learning-platform owner before making changes.
The documentation permits email sender domains from the second through fifth DNS level and up to 500 sender domains. These limits are not reasons to create unnecessary domains. Use only the namespaces your workflows need. If people should be able to reply, create and test the appropriate mailbox through your mail provider or IT team. Configuring a sender domain alone does not create a mailbox.
Add the domain and choose its transport
Open Navigation menu, Configuration, Platform setup and tools, Domain management. In Email sender domains, choose New domains and certificates, then New email sender domain. Enter the acquired domain and choose Create and edit. The General tab offers Built-in email service or Custom SMTP server where the required custom-SMTP app is active. Without that app, Docebo uses its built-in service.
Make this transport choice explicitly. Built-in service validation and SMTP connection validation test different things. Record which option each domain uses, which notifications refer to it, and which team owns the underlying mail service. A change of transport can change the envelope domain, DKIM signer, sender authorization, rate limits and support responsibility.
Built-in service setup
References: RFC 7208 §3.2, RFC 6376 §3.6.2.
Copy the SPF and DKIM settings displayed for the domain and apply the required DNS configuration at the authoritative host. Use the complete current account values, not an example from another installation. If the envelope owner's SPF record already exists, reconcile the required permissions into one valid policy instead of adding another SPF record. Review the product's full DNS requirements, including MX, before declaring the domain ready.
After authoritative publication and appropriate cache expiry, return to Docebo and select Test DNS configuration. Missing DKIM records can fail validation even if messages are still being sent. The documentation warns that such messages may lack the DKIM header and may be treated as spam. Therefore, apparent delivery is not permission to waive a failed validation. Docebo also states that delivery troubleshooting is not supported for sender domains missing the required SPF, DKIM and MX records. Preserve the validation result and continue to the received-message test.
Custom SMTP setup
Activate the Custom SMTP app through the organization's approved process before selecting the custom transport. Supply the SMTP hostname, port, username and password using the appropriate secure configuration interface. Never put credentials in the change ticket or test evidence. Match the encryption mode to the actual server: the documented TLS option is immediate, implicit TLS, typically on port 465; StartTLS upgrades the connection in session, typically on port 587. Docebo specifically points Microsoft 365 users to StartTLS. Confirm requirements with the SMTP provider rather than using a port label as proof.
Run Test connection and then Save changes. A successful connection proves neither authorization to use every visible From address nor successful DMARC alignment. Ensure the SMTP account is authorized to send as the address selected in each notification. Apply the external mail provider's authentication settings for that route, rather than assuming built-in-service values apply to custom SMTP. Check concurrency, recipient and daily volume limits against the expected notification workload.
After saving, the sender-domain list offers Check validation from the row's ellipsis menu. This checks DNS for the built-in route or the connection for custom SMTP. The direct connection test may require re-entering the password; use the documented list action where appropriate. Do not delete a sender domain as an improvised rollback: Docebo says affected notifications can then use an untrusted SMTP gateway with no delivery guarantee. Restore a known-good supported route and verify it before removing dependencies.
Verify the sending identity, not just the dashboard
References: RFC 9989 §4.4, RFC 9989 §5.3.5.
A green setup indicator establishes only the check that the product performed. For acceptance, send a controlled message through the actual workflow to a mailbox whose received headers you can inspect. Preserve the original message rather than a screenshot of a successful DNS lookup. Record the visible From domain, the SMTP envelope domain shown by the receiving system, each DKIM signature's d= signing domain and s= selector, and the receiving system's Authentication-Results. Do not trust an Authentication-Results field simply because a sender inserted one.
SPF authenticates the envelope identity, not automatically the visible From address. DKIM verifies a signature for its signing domain. DMARC requires a passing path that aligns with the visible From domain under the applicable alignment mode. A provider-owned envelope can pass SPF without producing aligned SPF for your brand. Conversely, a valid aligned DKIM signature can provide the passing DMARC path even when SPF does not align. Inspect the actual identities before changing DNS.
Use this illustrative acceptance case, not as a claim about a provider's default: a message has From learning@example.com, envelope bounce@vendor.example.net, and a verified DKIM signature with d=example.com. SPF success for vendor.example.net alone is not aligned to example.com; the valid signature with d=example.com supplies exact DKIM alignment. If the receiver instead reports an invalid signature, the example no longer has that passing aligned path. Record both the authentication result and the domain it applies to.
Diagnose failures in a fixed order
References: RFC 6376 §6.
First confirm that the nameservers delegated for the exact domain are the servers you edited. Query the authoritative servers for the expected owner name and record type. Compare their answers with the account's supplied values, checking accidental domain suffix duplication, missing selector labels, truncated keys, and CNAME conflicts. Only after the authoritative answer is correct should you investigate recursive caching or wait for an earlier TTL to expire. There is no single guaranteed worldwide propagation deadline.
Next repeat the message test on the failing route. A web application can use a different transport from a human mailbox, and a successful preview is not proof that production notifications use the same identity. If DNS is right but the signature is missing, investigate the sending transport and product configuration rather than adding unrelated SPF permissions. If authentication passes but mail is placed in spam, retain the headers and investigate reputation, content and recipient handling separately. Authentication does not guarantee inbox placement.
Change control and completion evidence
References: RFC 7208 §4.6.4.
Keep the previous record sets, the approved new values, the domain owner, the business owner of each affected workflow, and a specific recovery decision before making changes. Never create a second SPF policy at the same owner to add a sender. Review one combined policy and its DNS-lookup dependencies; unrelated TXT records can coexist, but multiple candidate SPF policies are an error. Do not overwrite another sender's selector. Do not weaken the entire domain's DMARC policy to disguise one failing integration.
Acceptance requires authoritative DNS evidence, product validation, and a received-message identity record for every in-scope sending route. Test replies separately where the workflow expects them. These are proposed checks, not completed tests: this guide is based on retained documentation and synthetic reasoning, with no live tenant changes, DNS measurements, or delivered-message results. A human owner must review the evidence and approve any production rollout. Keep existing working routes available until the replacement is demonstrated, and remove obsolete permissions only after confirming no remaining dependency uses them.