Email Sending - Article

Email Sending

Email Sending is the platform’s centralized communication control layer.

It governs every automated system message triggered by user activity — such as the email sent upon account creation to set a password, the issuance of a certificate, calendar invitations for scheduled sessions, reminders, consent updates, or even promotional triggers like prompting a contact manager to invite customers. Any system-driven email notification originates from the configurations managed here.

These configurations give you full administrative control over what is sent out from the system, whether it is sent at all, and how it is classified within the notification framework. Emails can be aligned with notification schemes — a structured three-level intensity hierarchy — which allows administrators to define the importance of each email type while still giving users the flexibility to choose how aggressively they want to be informed.

In other words, this area allows you to deliberately shape how the platform communicates at scale.

At its core, Email Sending exists to balance two critical dimensions:

• Clarity and Consistency—Ensuring that automated communication maintains brand tone, multilingual accuracy, and structured messaging across all workflows
• Control—Allowing administrators to regulate notification intensity, sender identity, delivery infrastructure, and overall communication volume in line with governance and operational standards

This is managed through a comprehensive configuration structure organized across the tabbed sections, supporting:

• Full customization of automated emails using a rich text editor with built-in support for images, links, buttons, files, and integrations such as questionnaires
• Multilingual governance with structured import/export workflows in multiple standard formats, enabling collaboration with translation agencies or internal language specialists
• Classification of notifications (e.g., Important vs. All) as part of the notification scheme configuration
• SMTP configuration for secure delivery through your own email services, aligned with corporate IT and security policies
• Volume limits to safeguard deliverability and protect sender reputation from accidental mass sends
• Operational visibility through usage monitoring and system logs

Well-configured email automation strengthens engagement, reduces support friction, and reinforces trust — while poorly configured automation can create unnecessary noise, fatigue, or operational risk.

Apperance — Look and Feel of Emails

System emails automatically inherit the platform’s general appearance settings, including logo, color scheme, and footer information. This ensures visual consistency with your overall brand identity without requiring manual styling in each template.

Administrators control the actual content of the email — such as subject lines, body text, images, buttons, links, and calls to action — while the surrounding layout and structural framing are applied automatically.

Emails are formatted to render appropriately across common email clients, including Microsoft Outlook across multiple operating systems, Apple Mail (macOS), and other widely used tools. This ensures that your communication maintains both brand alignment and technical compatibility across devices and platforms.

System Emails

The System Emails tab is where you manage the content and behavioral mapping of every automated email triggered by the platform.

Each system email represents a specific workflow event — such as account creation, enrollment confirmation, event updates, certificate issuance, questionnaire notifications and so on. Whenever the system reacts to user behavior via email notifications, it does so through one of these predefined email types.

This left-hand tab gives you control over how those automated responses are expressed and classified. It does not impact any logic to trigger the notifications, but it allows you to customize:

• What the message says
• Which sender identity is used
• How it is categorized within notification schemes — including if it should be sent at all

When editing a system email for a specific workflow event, you control several key elements that define how the message behaves and who it reaches:

• Type—Each workflow event often includes multiple email types, depending on who is affected by the action. For example, one version may be sent to the user, another to an administrator, instructor, or responsible role. The intended recipient is identified in the title (e.g., “Registration confirmation – user”), helping you understand the audience and purpose of the message
• Sender—You can select the sender identity for each email. This allows operational emails to originate from different roles or departments — such as Help Center, Finance, Training Center, or another defined sender — in line with practical workflows and corporate IT policies. If no specific sender is selected, the default sender will be used
• Notification Scheme—Here you define how the email is classified within the notification scheme framework. You can adjust the default mapping or remove one or more schemes entirely. If all notification schemes are removed, the email will never be sent. This makes the mapping both a communication and governance decision
• Email Subject—The subject line determines the first impression and strongly influences open rates. It should clearly communicate the purpose of the message (e.g., confirmation, reminder, approval) while remaining concise. Dynamic tokens (variables) can be used to personalize the subject line with activity details, dates, or user information
• Email Body—The body should clearly explain what happened, why the recipient is receiving the message, and what — if anything — they are expected to do next. The tone should align with your audience (internal employees, partners, customers, etc.) and remain consistent with your brand. The rich-text editor allows you to:
  • Format text and create structured lists
  • Insert links and images
  • Add buttons and attachments
  • Use dynamic tokens for contextual personalization

Available dynamic tokens depend on the specific workflow event, as they reference data tied to that action. These tokens allow the email to remain fully automated while still feeling precise and personalized, inserting contextual information at the exact moment the email is triggered — ensuring accuracy without manual intervention.

Emails can also include direct calls to action, such as:

• Navigating to an activity
• Completing a questionnaire
• Viewing a certificate
• Confirming attendance

Structured call-to-action buttons can direct users to the exact next step — for example, viewing a course, completing a questionnaire, confirming attendance, or downloading a certificate. Clear calls to action reduce friction and improve workflow completion.

A practical recommendation is to keep content concise and action-oriented. System emails are operational messages, not newsletters.

Notification language is based on the User preference

The language can be selected from the dropdown menu, allowing you to edit content in any active platform language individually. User's language preference setting in the profile determines the notification language, if it is available.

Notification Scheme Mapping

Each system email can be mapped to a notification scheme level (All, Important, or No emails). These schemes come with predefined default configurations that have evolved over several years and across numerous real-world customer deployments. They reflect practical experience.

However, they are not fixed rules. Every business context, audience, and communication culture differs — and you retain full flexibility to adjust the mapping according to your operational and governance needs.

The concept itself is straightforward: there are three intensity levels, and administrators decide how each system email type is classified.

When a new user is created, a default notification scheme is applied — either automatically or as part of the onboarding choice. After account creation, users can adjust their own notification preference from their profile. This makes your initial classification important: if too many emails are mapped as “Important,” users may reduce their notification level altogether.

By standard configuration:

• All emails includes the full set of system notifications
• Important emails represents a moderated level — typically limited to operationally significant messages such as certification issuance, completion confirmations, security alerts, or enrollment status changes. Informational, social, or promotional-style notifications generally do not belong here
• No emails still allows critical operational messages (such as password reset and security-related notifications) to be delivered, but suppresses all non-essential communication

Because users can ultimately choose their preferred notification intensity, the way you classify emails becomes a governance decision. It defines what must always reach the user and what may be filtered based on personal preference.

A thoughtful mapping strategy balances operational clarity with communication restraint — protecting engagement without creating fatigue.

Import and Export of Email Templates (PO & Excel)

In multilingual or large-scale deployments, editing system emails directly in the interface is not always efficient. The platform therefore supports structured import and export of email templates in standard formats — allowing collaboration with translation agencies, internal language teams, or structured review processes.

This functionality applies to the System Emails tab.

It allows you to:

• Export all system emails for a specific language
• Translate or revise them externally
• Re-import them in bulk
• Maintain consistency across large environments
• Avoid manual editing of each template

This becomes particularly valuable when operating in multiple languages or when preparing for go-live across regions.

The platform supports export and import in:

• .po files (Portable Object format)
• .xlsx files (Excel format)

Each serves a slightly different purpose.

PO Files are a standard localization format widely used in translation tools. They are ideal when working with professional translation agencies or software that supports structured localization workflows.

PO files preserve the relationship between original text and translated text while protecting system variables (dynamic tokens).

Excel Files (XLSX) provides a more accessible format for internal review, editing, or collaboration with non-technical stakeholders. It allows structured editing in spreadsheet form before re-importing into the platform.

How to Export System Emails

1. Navigate to Settings → Email Sending → System Emails
2. Choose Export
3. Select the language you want to export (if multiple languages are enabled)
4. Select the desired format (.po or .xlsx)
5. Download the file

The exported file will contain:

• Email subjects
• Email body content
• Structured identifiers
• Dynamic tokens (which must not be altered)

How to Import Translated or Updated Emails

1. Prepare the edited .po or .xlsx file
   • Do not modify dynamic tokens
   • Do not change system identifiers
2. Navigate to Settings → Email Sending → System Emails
3. Choose Import
4. Select the relevant language
5. Choose how imported data overrides existing data
6. Upload the file
7. Confirm the import

After import, the system updates all corresponding email templates in bulk.

It is recommended to test key workflows after large imports to validate formatting and token behavior.

Important Governance Notes

• Dynamic tokens must remain unchanged. Altering them can break data rendering
• Always keep a backup export before making large changes
• If available, test in staging environments before production rollout
• Ensure language versions remain aligned with appropriate notification scheme mapping

When to Use Import/Export

Use structured import/export when:

• Launching a new language
• Rebranding tone or messaging globally
• Working with external translation providers
• Conducting compliance reviews
• Aligning email content across multiple departments

💡 Avoid using it for small, isolated edits — the interface editor is more efficient for minor adjustments.

This import/export functionality transforms Email Sending from a simple editor into a scalable communication governance tool for comprehensive quality control.

Senders

The Senders tab defines how system emails are technically delivered and under which identity they are sent. While the System Emails tab governs what is communicated, the Senders tab governs how that communication reaches your audience. This has less to do with wording and more to do with deliverability, trust, and compliance.

Every automated email must originate from a sender identity. That identity affects:

• How recipients perceive the message
• Whether the email passes spam filters
• Whether it aligns with corporate IT policies
• How reply handling is managed
• Domain reputation and blacklisting risk

In larger organizations — particularly enterprise and extended enterprise deployments — this tab often requires coordination with IT.

What You Configure Here

Within the Senders tab, administrators can:

• Define one or more sender identities
• Configure delivery method (native or SMTP)
• Set a default sender
• Validate configuration via test emails
• Map specific senders to specific system emails

Each of these choices carries operational implications.

Delivery Method: Native vs SMTP

Native Mail Transport—The platform provides a built-in mail delivery mechanism (native transport) that allows emails to be sent without requiring immediate SMTP configuration. This option is typically used during early implementation phases, testing environments, or smaller deployments where dedicated mail infrastructure has not yet been configured.

Native delivery enables the platform to send system emails using its default transport configuration. This allows you to begin operating core workflows — such as account creation, enrollment confirmations, and certificate notifications — without waiting for corporate mail server setup.

Eurekos can assist with enabling this configuration as part of initial setup. However, because emails are sent through the platform’s managed infrastructure, alignment and coordination with the Eurekos Service Desk is required to ensure proper sender configuration and responsible usage.

It is important to understand:

• Native transport is suitable for startup and controlled rollout phases
• It may not align with strict enterprise IT policies or domain-level authentication requirements
• For production environments — especially in enterprise or high-volume scenarios — SMTP configuration is typically recommended for greater control over sender identity, SPF/DKIM alignment, and deliverability management

As part of configuration, sender identities must still be defined and tested, regardless of delivery method.

SMTP (Required for Production Environments)

SMTP configuration allows the platform to send system emails through your organization’s own mail server or a dedicated email service provider (such as Microsoft 365, Google Workspace, Amazon SES, or similar).

⚠️ We strongly recommend not using Microsoft 365 for this purpose, as it is not specifically designed for sending emails from applications. Instead, we recommend using a dedicated email delivery service such as Amazon SES, SendGrid, Postmark, or Azure Communication Services.

While native mail transport is suitable for startup and controlled environments, SMTP is typically recommended for production deployments where domain alignment, IT governance, and deliverability standards are important.

Using SMTP means emails are sent from your infrastructure, under your domain policies, rather than through platform-managed delivery.

SMTP is commonly configured when communication governance and deliverability standards are a priority. This is particularly relevant in structured enterprise environments or large-scale extended enterprise deployments.

SMTP is typically required when:

• Corporate IT policies require domain-level control—Many organizations mandate that all outgoing communication must originate from their own approved mail servers or authorized providers. This ensures internal oversight, auditability, and alignment with IT security policies
• SPF, DKIM, and DMARC alignment must be maintained—Modern email ecosystems rely on authentication standards to verify sender legitimacy and reduce spoofing. SMTP allows emails to be sent through infrastructure that is properly authenticated for your domain, helping maintain compliance with security standards and reducing the likelihood of delivery issues
• Email reputation must be managed internally—Sender reputation directly impacts inbox placement. When using SMTP through your own provider, your organization retains responsibility — and control — over reputation management, bounce handling, and blacklist monitoring
• High-volume sending requires monitoring and control—In deployments with large user bases or frequent automated notifications, email volume can be significant. SMTP allows organizations to monitor traffic, manage rate limits, and align sending patterns with provider thresholds
• You want full ownership of sender identity—SMTP ensures that system emails originate from your organization’s domain, reinforcing brand trust and making reply handling consistent with your internal communication structure

In enterprise and extended enterprise environments, SMTP is often not optional — it is a compliance and governance requirement.

How to Configure SMTP

Navigate to Settings → Email Sending → Senders → Add/Edit Sender.

You will see the fields reflected in the interface:

• Sender—The email address shown as the “From” address (e.g., your-example@organization.com). This should match a valid mailbox or authorized sending identity within your domain
• Transport—Select SMTP from the dropdown
• Host — The SMTP server address provided by your email delivery provider (for example, smtp.sendgrid.net, an Amazon SES SMTP endpoint such as email-smtp.us-east-1.amazonaws.com, or another dedicated SMTP relay service)
• Username—The authentication username provided by your mail server. This is often the same as the sender email address, but depends on provider configuration
• Password—The SMTP authentication password. Note that two-factor authentication must be disabled for this account, or an app-specific password must be generated if required by your provider
• Port—Typically:
  • 587 (TLS) – most common and recommended
  • 465 (SSL) – depending on provider
  • 25 (rarely used in secure environments)

After entering these details, always use Send test email before saving to verify that connection and authentication are successful.

Important Technical Considerations

• Two-factor authentication must not block SMTP authentication
• The sending address must be authorized within your domain
• Incorrect configuration may result in emails not being delivered
• IT involvement is strongly recommended for initial setup
• Always test before enabling high-volume workflows

General

In the General tab, you define sending limits per notification scheme — All emails, Important, and No emails.

This does not change which emails are sent. It defines how much communication is allowed to flow within a 24 hour timeframe.

Think of it as a safety layer above your notification scheme mapping. Even if many workflows are triggered at once — bulk assignments, automation sequences, event reminders, or promotions — the system will respect the thresholds you have defined.

Sending limits exist to prevent unintended consequences.

In active environments, email traffic can grow quickly — especially when launching new programs, onboarding large audiences, or running automated workflows. Without structural limits, even well-configured systems may generate sudden spikes.

By defining limits:

• You protect users from excessive bursts of notifications
• You protect your domain reputation when using SMTP
• You introduce a safeguard against configuration mistakes
• You remain aligned with provider-level sending expectations

This is particularly important in enterprise and extended enterprise contexts, where volume and complexity are higher.

How Do You Choose the Right 24-Hour Sending Quota?

Because the quota applies to a full 24-hour period, you should think in terms of daily operational volume, not momentary bursts.

Start by asking:

• What is our largest realistic daily communication event? For example: a large onboarding rollout, certification release, or promotion campaign
• How many emails could that generate across all workflows in one day? Include confirmations, reminders, calendar invites, incentive notifications, etc.
• Do automation rules trigger multiple emails per user within the same day? Overlapping workflows can multiply daily volume quickly
• What are our SMTP or provider-level daily limits? Ensure your platform quota aligns with infrastructure thresholds.

Then monitor actual sending behavior after go-live.

💡 Good practice is to:

1. Review email volume over a representative period (e.g., 2–4 weeks)
2. Identify your highest real daily peak
3. Set your quota slightly above that observed peak — with a reasonable buffer

This creates a data-informed limit rather than a theoretical guess.

Logs

The Logs tab provides operational visibility into the platform’s email activity. While the other tabs define what is sent, who sends it, and how much is allowed, Logs show you what actually happened.

This is not a configuration area. It is a monitoring and troubleshooting interface. Email automation is powerful — but when something does not behave as expected, you need traceability.

The Logs tab allows administrators to:

• Verify whether an email was triggered
• Confirm when it was sent
• See which recipient it was addressed to
• Identify delivery-related patterns

This is particularly valuable when:

• A user claims they did not receive an email
• A workflow appears not to trigger
• Sending limits were reached
• SMTP configuration is being validated
• You are monitoring high-volume activity

Practical Use Case

Imagine a learner contacts support claiming they never received their certificate email after completing a course. Instead of immediately resending certificates or questioning the configuration, the administrator can:

1. Open the Logs tab
2. Search for the specific certificate email tied to that user
3. Confirm whether the email was successfully triggered
4. Verify the recipient address stored at the time of sending
5. Review the timestamp and sending status

At this point, you can quickly determine:

• Was the email never triggered? (configuration issue)
• Was it triggered but sent to an outdated address? (data issue)
• Was it sent successfully but likely filtered or blocked? (inbox or IT issue)

This structured approach prevents unnecessary troubleshooting, avoids duplicate sending, and keeps communication with the learner precise and professional.

Best Practice Workflow for Multilingual Email Rollout

When introducing a new language — or revising communication tone across multiple languages — Email Sending should be approached as a controlled rollout, not a bulk translation task.

Below is a recommended sequence that balances efficiency, governance, and quality assurance.

Governance Perspective

Multilingual email rollout is not merely a translation exercise — it is communication governance across languages, cultures, and operating models.

A structured rollout ensures:

• Brand consistency
• Legal compliance
• Technical reliability
• Controlled communication intensity
• Reduced support burden