What Open edX notifications and email digests change for your learners
The notification system is on by default from Verawood, so learners on a new or upgraded platform can start receiving messages without anyone switching anything on. Before launch, operators should decide which channels are active, how email digests are timed, which defaults apply across the whole instance, and how learners opt out. Treat these as launch settings to review before the first learner signs in, because a message that has already been delivered cannot be recalled.
Learners see notifications in the LMS and, where email is enabled, in their inbox. Depending on configuration, messages arrive individually or grouped into a digest. Which course events trigger a message, and how the wording reads, should be checked on your own instance with test accounts enrolled in a sample course. A learner who receives mail they did not expect is the most likely support request in the first weeks, so the difference between a web notification and an email should be clear to the people answering it.
Course teams see the effect in two places. Instructors may notice more learner traffic after course updates, and they need to know which messages come from the platform and which come from their own course content. Support staff need a short runbook covering how a learner changes preferences, how an opt-out is recorded, and what happens to digests already queued. Assign one owner for instance-level defaults so that a course team cannot change a platform-wide setting by accident, and document who approves a change.
The exact setting names, default values, digest timing options and opt-out behavior must be confirmed against the Verawood release notes and the Tutor documentation for the version you run, since Verawood was published on 30 July 2026 and configuration details can change between releases. Ask your implementation partner for a written configuration sheet that lists each setting, its value and its owner, and test every channel on a staging copy of your Tutor deployment before any learner account is created.
Which notification decisions to make before launch
This table lists the notification choices to settle before an Open edX Verawood platform opens to learners, along with the audience each choice suits. Read each row as a decision: the choices come first, then when each one fits a platform team, an academic or training organization, or a corporate learning team. Confirm exact setting names and digest options in the Verawood documentation before you write a configuration plan.
| Decision | Choices to confirm | When each choice fits |
|---|---|---|
| Web notifications | Keep the Verawood default, or limit which notification types appear to learners (confirm which types can be limited) | Platform team: test the default with a pilot group. Academic: helpful for grading and deadline updates. Corporate: helpful for compliance deadlines. |
| Email notifications | Send all types, send only selected types, or send none to learners (confirm the options available in your release) | Platform team: decide early, since this affects support volume and sender setup. Academic: keep enrollment and grading messages. Corporate: keep compliance and deadline messages and limit promotional updates. |
| Email digest timing | Digest or immediate delivery, with frequency and send time set per instance (confirm the supported schedules) | Platform team: check sending limits with your mail provider before choosing a schedule. Academic: align with term dates and assessment deadlines. Corporate: align with regional working hours and course deadlines. |
| Instance-level defaults for learners | Defaults applied to all learners, and whether learners can change them later (confirm the scope of each default) | Platform team: set defaults in configuration and document them for support staff. Academic: choose defaults the whole institution can explain to students. Corporate: match defaults to HR and compliance policy for required training. |
| Learner opt-out | Learners manage their own preferences, or staff restrict options for certain messages (confirm which messages can be locked) | Platform team: confirm whether required messages can be exempted from opt-out. Academic: state opt-out options in onboarding material. Corporate: confirm policy requirements for required training before allowing opt-out. |
How the notification system decides what to send and when
The notification system makes three decisions for each event: whether the event qualifies, which channel carries it, and when it is delivered. Instance-level defaults are the starting point, and learner preferences are applied on top of them. Before launch, confirm on a test instance whether a learner can re-enable a channel that the instance has turned off, and whether an instance default can change after learners have already saved their own settings. The Verawood release notes are the reference for which notification behavior ships in this release and where each control sits, so record the release notes version you tested against.
Events that typically generate notifications fall into two groups. Learner-facing examples include course updates, replies to a learner's discussion post, and deadline or grade messages. Course-team examples include new discussion activity and other events that staff need to act on. Confirm the exact event list in the Verawood release notes, because the set of triggering events drives mail volume more than any other setting. Create a dummy learner account and a dummy course-team account, trigger each event in a sample course, and record which channel delivers it and how quickly it arrives.
Digests collect activity over a period and send a summary instead of one message per event. The two settings to check are the digest schedule and the list of events a digest includes. Confirm whether web-only events appear in an email digest, and whether a learner who has opted out of email still receives a digest. Run a test with a known set of events, time the send, and compare the result with the mail server log. Also confirm that the scheduled job that sends digests runs in your deployment, since a digest that never sends will look like a working setup until a learner reports the gap.
The platform is a modular monolith, and Verawood adds frontend pieces such as a new Studio sidebar, a redesigned instructor dashboard and new frontend plugin slots. The admin surface and the learner surface may therefore be configured in different places, some in server-side settings and others in frontend configuration or plugin slots. Plan a checklist that covers each surface separately, and use separate test accounts for learners, instructors and course staff. Keep every configuration change in version control so that a setting tested in staging reaches production exactly as tested, and confirm that a learner's opt-out survives a digest send and a platform upgrade.
How to configure notifications on a Tutor deployment
This sequence takes a Tutor-based Verawood installation from a confirmed release baseline to notifications that behave as intended for learners and course staff. Each step closes with a check you can repeat, such as a test digest arriving or an opt-out being honored. Setting names and timings are left to the Tutor and Open edX documentation for your version, which you should confirm before you change anything.
Confirm the release and Tutor version
The platform lead records the Open edX release your instance runs and the Tutor version that deploys it. Verawood is the current named release, published on 30 July 2026, and Open edX supports only the latest named release, so confirm that your Tutor version targets Verawood and that every plugin in your build supports it. Check the Tutor documentation for your version rather than relying on memory or an older guide. The output is a written version record, stored with the deployment configuration, that the rest of the sequence refers back to.
Review the Verawood notification changes
The platform lead and a course-operations representative read the Verawood release notes and list every change that touches notifications, including defaults, channels, digest behavior and any settings that became required. Compare that list with your current configuration and with any custom plugin that handles notifications. Confirm each item against the official documentation for your version. The check is a signed-off change list in which every item is marked as no action, configure now, or test before production.
Set instance-level defaults in staging
The platform engineer applies the instance-level notification defaults in a staging environment built from the same Tutor configuration as production. Each default is written into version-controlled configuration with a short note on why it was chosen, so the decision is traceable later. Confirm the setting names and accepted values in the Tutor and Open edX documentation for your release before you apply them. The check is that a fresh redeploy of staging reproduces the intended defaults without manual changes.
Configure the email sending path and identity
The platform engineer and the messaging owner work with the mail provider to set up the sending domain, authentication records for the domain, the sender display name and the reply-to address that learners will see. Store provider credentials as secrets, never in plain configuration files. Follow the provider's current guidance for domain authentication, and confirm the mail-related settings in the Tutor documentation. The check is a test message sent from the staging LMS to an internal mailbox, where the headers show the message passed sender authentication and the displayed sender matches the approved identity.
Enable or limit the web channel
The course-operations representative and the platform lead decide which notification types should appear in the web notification area for learners and for course staff, and switch off any type that would add noise or expose information to the wrong audience. Apply the decision in staging and record it next to the defaults. Confirm the available channel controls in the documentation for your version. The check is a test action that creates a web notification for the intended audience and produces none for accounts outside that audience.
Set digest timing and confirm the schedule
The platform engineer sets the digest frequency and send time to match the time zone and working pattern of your learners and course teams. Confirm how digests are scheduled in your Tutor deployment, including the background job that produces them, and verify the timing settings in the documentation for your version. Confirm that the job runs in the environment you intend to use. The check is that the scheduled job runs in staging at the configured time and that the time zone shown in the test digest matches what you expected.
Test with learner and course-staff accounts
The QA lead creates dedicated learner and course-staff test accounts, enrolls them in a test course with a staff role, and triggers the events that generate notifications. Run the test for every channel and every digest setting in scope. Confirm three things: a test digest arrives in the expected mailbox, a web notification appears for the right account, and an opt-out is honored, meaning no further digest messages reach that account on the next scheduled run. Record each result with the date and the configuration version tested.
Promote and document the verified baseline
The platform lead promotes the verified configuration to production through the same change process used for other deployment changes, then documents the baseline for future upgrades. The document lists the release and Tutor versions, the defaults, the sender identity, the channel and digest decisions and the test results. Re-run one controlled digest and one web notification check in production with the test accounts. The check is a production test that matches the staging results and a baseline document that the next upgrade team can use.
Security and operational considerations for notification email
Notification and digest email sends on your behalf, so deliverability, personal data, credentials and logs become your responsibility once it is enabled. The cards below list what the operator must decide or verify before and after turning on email for learners.
Outbound mail authentication and reputation
Notification mail should leave from a domain you control, with SPF, DKIM and DMARC records published for that sending domain and checked against your mail provider's requirements. Confirm which From address and reply-to address learners see, and who owns the DMARC reporting mailbox. Poor authentication shows up as digests landing in spam, which learners then read as a platform fault.
Learner addresses inside notification content
Digest and notification templates can expose learner names, email addresses, course titles and progress to whoever receives them. Decide which fields templates may include, confirm that no message reveals another learner's data, and check that shared or forwarded mail does not carry more detail than the learner expects. Review the template context for each notification type before enabling it.
Mail provider credentials in your secrets handling
The SMTP or API credentials for your mail provider grant the ability to send mail as your organization, so they belong in the secrets store you already run, not in configuration files committed to version control. Confirm who can read them, how they rotate, and which environments receive separate credentials. Revoke and rotate them when staff with access change roles.
Rate limits and bounce handling
Digest timing can create sudden bursts of messages, which providers may throttle or treat as abuse. Ask your provider for its published sending limits and confirm how the platform behaves when a send is deferred or rejected. Decide who receives hard-bounce and complaint notifications, and how bounced addresses are suppressed so the platform stops sending to them.
Logging of sent messages
Operators need a record of which notifications were sent, when, and to which account, to answer learner complaints and support requests. Decide how long send logs are kept, where they are stored, and who can query them, since the logs themselves contain personal data. Confirm that logging captures delivery outcomes as well as attempts.
Change control for default settings
Notifications are on by default from Verawood, so instance-level defaults for channels, digest timing and opt-out behavior shape every learner's inbox. Record the approved defaults, route changes through your standard review, and test them in a staging instance before production. Confirm whether a change applies to existing learners or only to new accounts.
Keeping learners opted out and what that means for your obligations
Learners stay opted out only if the opt-out survives every path that can turn email back on. Two inputs usually matter: the instance-level default that applies to learners who have never set a preference, and the individual learner's own choice. Confirm in your Verawood build which one takes precedence when they conflict, and whether a policy-driven opt-out you set at the instance level overrides a learner who later re-enables email. Write the answer down before launch. Support staff will be asked this question, and the answer defines what a learner who unsubscribes can reasonably expect. Also confirm whether a change to the default applies only to new accounts or to existing ones.
Test the opt-out over time, not only at the moment it is set. Create a test learner, opt out through the interface, and confirm that no digest is queued or sent across several scheduled digest cycles. Use a test learner whose course activity would normally generate content, so that a missing send actually means something. Repeat the test after a configuration change, after the scheduled task workers restart, and after the instance moves to a new named release. Keep test accounts on a non-production site, or flag them so they cannot reach real learners' inboxes. Record the date, release, setting value and result for each run.
Upgrades are where opt-outs most often break. A new release can add notification types, change defaults, rename preference fields, or run a data migration that resets preferences it does not recognize. Before each upgrade, snapshot the preference data, run the persistence test on a staging copy built from production data, and compare the defaults the target release ships with the defaults you have configured. Read the release notes and upgrade notes for the target release, since they list changes the deployment team must review. A passing test on a fresh install does not show that an upgraded instance kept its learners' choices.
Record the policy decision as a versioned document with a named owner. It should state which notification types are on by default, which are off, who approved each choice, the instance settings and release in effect at the time, the test results, and the date of the next review. Keep the document in version control alongside the configuration so every change leaves a trail, and file the evidence from each test run with it. This record is what your team will show when someone asks how learners who declined messages were kept from receiving them, so write it for an outside reader and not only for engineers.
Whether an opt-out satisfies a specific privacy or consent requirement is a question for your legal and privacy team, not something the platform configuration can answer alone. DeployOpen can prepare the settings, tests and evidence, but it does not interpret what a requirement means for your learners and does not issue any assessment of compliance. Bring the test results and the decision record to that review, and ask counsel which jurisdictions, learner groups and message types the applicable rules cover. For how Open edX privacy tooling fits into wider regulatory obligations, see the Open edX compliance topic on this site.
Limits to confirm on your Verawood instance
Notifications and email digests are on by default from Verawood, but the defaults that matter for your learners are set per instance and per release. The cards below list what to confirm before you promise digest behavior, channel choices or upgrade timing to stakeholders, and who can answer each question.
Notification types in your deployed version
Confirm which notification types the Verawood build you deploy actually emits, since the catalog of types can differ from what release notes describe as the feature's direction. Ask the Open edX community release notes and your Tutor version pin, then check a test course in staging for each type your learners will receive. Record the list in your runbook so support staff know what learners should expect.
Digest timing per instance
Find out whether digest send times and frequency can be set per instance through configuration, or whether they are fixed in code. This decides whether you can match a regional audience's working hours without a custom build. Ask your Tutor plugin or platform engineer to confirm the setting name in your version, and test a changed schedule in staging before committing to it.
Web channel independent of email
Confirm whether learners can turn off the web notification channel while keeping email, or the reverse, and whether an instance administrator can disable one channel for all users. Some organizations need email suppressed for a cohort while in-platform alerts remain. Ask the platform engineer who owns the notification settings, then verify the behavior with a test learner account in each setting combination.
Behavior in multi-site installations
Confirm how notifications, digests and opt-out preferences behave when several branded sites share one installation. Check whether a learner enrolled on one site receives messages that carry another site's name, domain or sender address, and whether preferences are stored per user or per site. Ask your multi-site architect and the email sending owner, and test with an account enrolled on two sites.
Pending digests during upgrades
Confirm what happens to digests that are queued but not yet sent when you move to a new named release, and whether any scheduled jobs pause, resend or skip during the maintenance window. Missed or duplicated emails are a visible learner problem. Ask the release owner for the upgrade notes for your target version, and rehearse the upgrade in a copy of production with the task queue visible.
Themes and plugins
Confirm whether your custom theme overrides notification templates, whether any installed plugin adds or changes notification types, and whether frontend plugin slots used by your theme still render in the notification UI. Themes and plugins often break silently after an upgrade. Ask your frontend developer and plugin maintainers to list every template and hook touched, then review each one against the Verawood release notes and your staging results.
Questions buyers ask about notification setup and effort
What drives the cost of Open edX notification setup?
The main cost drivers are the number of channels you enable, the mail provider path, whether your custom theme changes notification templates, and how wide the testing scope is. Web notifications live inside the platform interface, so their cost is mostly configuration and review. Email adds a delivery dependency that someone must configure, authenticate and monitor. Each extra channel or digest type adds template work, test cases and sign-off. A custom theme means templates and styling must match your branding, which adds design and review time. Some costs recur after go-live, including mail reputation monitoring, bounce handling and changes to digest timing. Ask for a written quote that lists the channels in scope, the mail integration, each theme touchpoint, the test matrix and any handover or support terms.
How long does notification configuration and testing usually take?
The duration depends on the scope, so no fixed number applies to every platform. Setting instance-level defaults and digest timing is usually the shortest part of the work. Mail delivery setup, staging tests and policy decisions usually take the most time because they depend on other teams. Testing scope creates the most variation, especially if you run several languages or branded sites. External dependencies such as DNS changes for a sending domain can add waiting time you do not control. Ask the partner to break the estimate into phases: policy decisions on defaults and opt-out, mail provider access, configuration in a staging instance, test accounts for each learner and staff role, and a production change window. Confirm the dependencies and the order of phases in writing before work starts.
What does our team need to provide for notification setup?
The work needs four things from your side, and missing any one of them usually delays delivery:
- Staging instance: a non-production environment built the same way as production, so tests reflect real settings.
- Mail provider access: credentials or relay access for your chosen provider, plus a sending domain and the DNS access needed to publish its authentication records.
- Policy decisions: default digest timing, which channels are on by default, and whether learners can change their own preferences.
- Test accounts: learner, instructor and staff accounts across the course and site configurations you run, so each notification type can be checked.
Your team should also name an owner for mail reputation and bounce handling after launch. Confirm the exact settings your release needs with the vendor documentation before requesting access.
Can our platform team set up Open edX notifications without a partner?
A platform team with Tutor experience can configure notifications without a partner, provided it has a staging instance, mail provider access and time for testing. The work is mostly decisions and verification rather than unusual engineering. Teams usually struggle with delivery: SPF, DKIM and DMARC alignment, bounce handling and provider rate limits. Those problems appear after launch, so test them before learners receive messages. Confirm the exact settings against the documentation for your installed release, because defaults can change between releases. A partner is most useful when you need a fixed scope agreed in writing, independent testing, or documentation for handover. DeployOpen works on fixed scopes agreed in writing before work starts. Decide based on your team's capacity and on whether it has operated email systems before.
What changes with notifications when we upgrade Open edX?
Notifications are on by default from Verawood, so upgrading to Verawood can change learner-facing behavior even if you change no settings yourself. Before an upgrade, compare digest timing, channel defaults and any template overrides against the release notes for the target version. Open edX supports only the latest named release, so your installation will need to move forward over time, and each move needs a repeatable notification test. In Tutor deployments, upgrades usually involve rebuilding images and reapplying plugins, so custom templates and mail settings must survive that process. Ask the partner or your team how notifications will be verified on each target release. Willow is listed for December 2026, so plan your test cycle around the release dates in the Open edX release notes.
How do learners stay opted out of Open edX email digests?
Learners can opt out through notification preferences if the instance allows it, and operators can set defaults that determine what learners see first. Decide two things before launch: whether the default is opted in or opted out, and whether learners can change that setting themselves. Some institutions must honor an opt-out across all email, while others only need to control digests. Confirm the exact preference names, default values and any setting that blocks learners from changing them in the Verawood documentation for your installation. Then test the opt-out path with a learner account, including a check that digests stop after the change. Record the decision and the test result, because auditors and policy owners often ask how opt-outs were configured.
Which mail provider path affects Open edX digest delivery most?
Your mail path determines who manages deliverability, bounce handling and rate limits. The common options are your own SMTP relay inside your network, a transactional email provider, or a managed relay offered through your hosting environment. Each option has different authentication requirements, sending limits and reporting features, and not every provider exposes bounce or complaint events in the same way. Confirm with the provider which authentication records it requires, whether it supports the bounce and complaint handling you need, and what its sending limits are for your volume. Also confirm how credentials are stored and rotated in your secrets process. Choose the path before writing templates, because changing providers later can require new DNS records and new testing.
How DeployOpen scopes, delivers and supports notification setup
DeployOpen approaches Open edX notifications and email digests as a scoped configuration project inside your own installation. We start from which web and email notifications learners and staff should receive, how digests are timed, and which instance-level defaults apply before any change is made. Each setting is recorded in the written scope and tested before handover.
How we scope
- Written scope lists each notification type, channel and audience that the instance will send.
- Digest frequency, send times and recipient rules are agreed with your learning and support leads.
- We confirm which notification defaults your release enables, and which ones your policy requires you to turn off.
How we build
- Where the release allows, notification settings are kept in version-controlled Tutor configuration.
- Email delivery is tested with your mail provider, including sender domain, authentication records and bounce handling.
- Test accounts confirm digest content, opt-out links and web notifications for each learner role before go-live.
How we hand over
- A runbook records each setting, its owner, the release it was checked against and where it is changed.
- Staff receive a short guide on changing digest settings for a course or the whole site.
- Learner-facing opt-out text is reviewed with your communications team before launch.
How we support
- Ongoing support is available as a retainer for changes to digest timing, defaults and email templates.
- Notification settings are re-checked when you move to a later named release, since each release's changes are documented.
- Open edX states that only the latest named release is supported, so upgrade planning starts early.
