System Messages

SmarterMail generates a large number of automated, system-driven emails as part of its normal operation — password expiration warnings, delivery failure notices, two-factor authentication codes, mailbox size alerts and more. System Messages is the central library of every one of those templates. From here, a system administrator can rewrite the subject and body of any message to match company voice and branding, add a reply-to address so responses land in a monitored mailbox instead of disappearing, and create alternate-language versions of a message so non-English speaking users receive notifications they can actually read. These templates are server-wide: they apply to every domain hosted on the server, and there is no per-domain page that overrides them.

If a system message is left without a From Address, SmarterMail sends the message using "noreply@" plus the domain that generated the notification — not the domain of whoever happens to receive it. For example, if a password reset is requested for a user on example.com, and the system's Password Reset Request message has no From Address configured, the user receives that email from "noreply@example.com". The same rule applies to delivery status notifications (bounces): the sending domain used for the "noreply@" address is always the domain associated with the message that triggered the notification, not an arbitrary or recipient-side domain.

Note: This "noreply@" behavior is only a fallback used when no From Address is set — SmarterMail does not check for, reserve, or manage an address with that name. If a domain already has a real "noreply@" mailbox, alias, or mailing list configured, it is completely unaffected by this fallback. The practical difference is simply that any reply sent to that fallback address will actually be delivered to that existing mailbox, alias, or list instead of bouncing back as undeliverable.

Built-In System Message Types

Every notification SmarterMail can generate has a corresponding built-in message, always available in English by default. The most commonly customized types include:

Password Expiring Soon / Password Policy Violation — Warns a user that their password will soon expire, or that it currently fails one or more of the domain's password policy requirements (e.g., minimum length, complexity).
Password Exceeded / Password Policy Violation - Final Notice — The final enforcement notices sent when the grace period from the messages above has elapsed and the account is about to be (or has been) locked for password expiration or a policy violation.
Password Reset Request / Password Reset Request - Active Directory — Delivers the password reset link when a user uses the "Forgot Password" link on the login screen. The Active Directory variant is used automatically for domains where users authenticate against Active Directory.
Two-Factor Code Request — Delivers the one-time verification code when a user has two-factor authentication enabled and chooses email as the delivery method.
Mailbox Size Limit Exceeded - User / Mailbox Size Limit Exceeded - Administrator — Notifies the mailbox owner (and separately, the domain administrator) when a user's mailbox has grown past its assigned size limit.
Domain Size Limit Exceeded — Notifies the appropriate administrator when an entire domain has exceeded its allotted disk space limit.
Virus Detection User Notification — Informs a user that a message sent to them contained a virus and, as a result, was placed in quarantine or not delivered.
Delivery Status Success, Delivery Status - No Notification, Delivery Status Delayed, and Delivery Status Failure — The delivery status notification (DSN) messages sent back to a sender confirming successful delivery, confirming the message was relayed onward without further confirmation, warning of a delivery delay, or reporting an outright bounce, respectively. These only generate when delivery status notifications are enabled in Protocol settings.
Read Receipt — The confirmation email generated when a recipient acknowledges a read-receipt request. Unlike other message types, this one is always sent from the original recipient's own address, which is why the From Address and Display Name fields aren't shown when editing it.
Migration Summary - Success / Migration Summary - Failure — Sent after a mailbox migration job completes, summarizing the results or reporting that the migration was interrupted.
Meeting Forwarded Notification — Sent when a calendar meeting invitation is forwarded to additional recipients, informing the original organizer or attendees of who it was forwarded to and when.

Note: A small number of internal notifications (for example, the message logged when a user accepts an Acceptable Use Policy) are generated using this same system but are not exposed in the System Messages list, since they are not intended to be customized.

The System Messages List

When accessing System Messages, every configured message — the English default for each type, plus any additional languages that have been created — is listed together with the following columns:

Message — The message's title/type, e.g., "Delivery Status Failure" or "Password Reset Request".
Language — The language this particular version of the message was written in.
Subject — The message's subject line, exactly as it will appear in the sent email.

Editing a System Message

Click on a message's row to open the editor. The following fields are available:

Message Title — Not editable; this simply displays the message's type and language for reference (e.g., "Delivery Status Failure - English").
Subject — The subject line of the email. Most subjects contain one or more template variables (see below); it's best to leave these variables in place, since removing them means the resulting email will be missing that piece of information entirely.
Message Body — The body of the email, edited using SmarterMail's full HTML/rich-text editor. Formatting, links, tables and inline images can all be added directly in the body — for example, an administrator could insert the company logo or a "Contact Support" button into the password expiration email. Inline images inserted this way are stored as attached files tied to that specific message, not as external links.
From Address — An optional sender address. This does not have to correspond to a real mailbox on the server — SmarterMail only validates that it's a syntactically correct email address, so it can point to a mailbox hosted elsewhere. Setting a real, monitored address here is useful both to let users reply with questions and to reduce the odds of the message being caught by recipient-side spam filters (since "noreply@" addresses are treated with more suspicion by some filters than a real, deliverable address). For example, setting the From Address on Password Policy Violation to support@example.com means a confused user can simply reply to ask why their password was rejected, instead of the message dead-ending at an unmonitored noreply@ address.
Display Name — The friendly name shown alongside the From Address in the recipient's inbox (e.g., "Example.com IT Support"). This field is required for every message type except Read Receipt, which always uses the original recipient's own display name instead.

Template Variables

Most message types support a specific set of variables, shown in the editor's Variables panel below the body field, and each is replaced with real data at send time. Common examples include:

%DisplayName% and %RcptAddress% — The recipient's display name and email address. Available on nearly every message type.
%ExpireDate% and %DaysLeft% — Used on the password expiration and violation messages to show the date the password will expire (or was locked) and the number of days remaining.
%Link% — Used only on the password reset messages; inserts the one-time password reset URL. This is the single most important variable to preserve — removing it means the user has no way to actually reset their password from the email.
%MailboxSizeLimit% — Used on the mailbox size messages to show the configured size limit.
%Domain%, %DomainSizeLimit_MB%, and %DomainCurrentSize_MB% — Used on the domain size limit message to identify the domain and show its limit versus current usage.
%Subject% and %Error% — Used on the delivery status (DSN) messages to echo the original message's subject line and, for delayed/failed deliveries, the specific SMTP error that was returned by the remote server.
%VirusName%, %From%, and %To% — Used on the virus detection notification to identify the detected threat and the original sender/recipient of the infected message.
%Code% — Used on the Two-Factor Code Request message to insert the verification code itself.

Note: The variables available depend entirely on the message type being edited — the editor only lists the variables that are actually recognized for that particular message, so always check the Variables panel for the message currently being edited rather than assuming a variable from one message type will work in another.

Creating a System Message in a New Language

By default, every message type only has an English version. System administrators can create additional versions in other languages so that users who have a different language configured receive notifications they can read, rather than always falling back to English. Which version SmarterMail actually uses at send time depends on the message type:

For the four Delivery Status messages (Success, No Notification, Delayed, and Failure), SmarterMail resolves the language as follows:

Use the language configured in the default account settings of the domain associated with the original sender of the message that triggered the notification — since that sender is who actually receives the delivery status notification. For example, if user1@domain1.com sends a message to user2@domain2.com and it bounces, the resulting Delivery Status Failure notice is delivered back to user1@domain1.com, so SmarterMail looks for a Delivery Status Failure message matching domain1.com's configured default language — not domain2.com's, since domain2.com never receives this notification.
If no matching message is found in that language (or the sending domain isn't local to this server), fall back to the English default.

For every other message type (password messages, mailbox/domain size limits, two-factor codes, migration summaries, etc.), the language is instead resolved against the individual recipient, in this order:

Use the language configured on the recipient's own user account.
If no matching message exists in that language, fall back to the language configured in the domain's default account settings (i.e., the language new users on that domain are assigned by default).
If still no match, fall back to the English default.

Note: A practical example of this second chain: a Spanish-speaking user whose personal account language is set to Spanish will receive a password policy violation notice in Spanish only if a Spanish version of that specific message has been created. If no Spanish version exists, but the domain's default language is French, SmarterMail tries French next; if no French version exists either, the user receives the English original. A message coming back in the wrong language is almost always explained by one thing: nobody has ever created a version of that particular message type in the expected language.

To create a new version of a default system message in another language:

Click the New button in the content pane. A modal opens.
Select the Message Type — that is, the built-in message this new version is based on.
Select the Language for the new version.
Click Save. The new message opens in the content pane, where the Subject, Message Body, From Address, and Display Name can be filled in.
Once everything has been entered, click Save again to store the new message.

Resetting a Built-In Message to Its Default

English messages can be edited just like any other message — there is no restriction preventing an administrator from rewriting the subject, body, From Address, or Display Name of a built-in English message. Because of this, the editor for an English message shows a Reset button in place of a Delete button, letting an administrator undo any customization and restore that message's original factory subject, body, sender name, and blank From Address in one step. This is useful, for example, after experimenting with a heavily customized password expiration notice: rather than trying to manually undo every change, clicking Reset returns the message to exactly what shipped with the product.

Deleting System Messages

Any additional-language messages that have been created can be deleted as needed. Select the checkbox next to the message, then click Delete. Multiple messages across different languages can be selected and deleted at the same time.

Note: English messages cannot be deleted, since every message type must always have at least one guaranteed-available version. The checkbox next to an English message is disabled in the list so it can't be selected for deletion, and the server independently rejects any attempt to delete an English message even if it's attempted directly — so there is no way to remove the English default for a message type, only to edit or reset it.