Mail Configuration

Novantra sends email for a handful of important user flows. This guide explains what those flows are, and how Novantra chooses the sender identity and outbound transport that deliver them. This is operational mail for product workflows, not newsletter or campaign tooling.

Where mail is used

The mail subsystem is the only way these things happen:

• Password resets. A user requests a reset; they get a link by email.
• Login unlock. After repeated failed logins, the account is temporarily locked. The unlock code is delivered by email.
• Membership invitations. When an admin invites someone to an organization, the invite arrives by email.
• Signup and onboarding codes. Cloud signup uses email-delivered one-time codes during account creation.
• Admin email verification. When you create or change the email on an administrator account, the verification step happens by email.
• Mail configuration tests. When you change SMTP settings, you can send yourself a test email from the settings page to confirm the transport works.

If mail breaks, these flows visibly stop working. Other parts of the product continue to function, but anything that requires an email round-trip becomes inaccessible until mail is restored.

Cloud vs Sovereign

Mail resolution differs by deployment mode, but the user-facing rule is the same: organization-level settings take precedence over deployment defaults.

For regional Cloud workspaces, email is treated as a risk-bearing surface rather than proof of residency. A custom sender domain or customer-owned mail transport can expose recipient metadata, and templates can expose content if they include sensitive details. Strict residency policies may require an aligned provider region or an approved exception.

Organization email bindings

Organization email bindings let a workspace use its own sender identity and, when needed, its own outbound relay. This is useful when different branches, facilities, subsidiaries, or regulated workspaces need separate sender domains, DLP rules, journaling, archive controls, or regional mail routing.

Supported v1 provider modes:

• Console - development/test only.
• SMTP - a generic SMTP relay.
• Microsoft 365 SMTP - your Microsoft 365 SMTP endpoint.
• AWS SES SMTP - Amazon SES through its SMTP interface.

Each binding stores the sender address, sender name, provider mode, sanitized status, and test-send evidence. Secrets such as SMTP passwords are not shown again after saving.

After saving a binding, send a test email. When the test passes, activate the binding with an audit reason. Active bindings are used for organization-scoped email such as invitations, password reset flows, login unlock links, public-session delivery, and customer-facing notices sent from the workspace context.

Cloud resolution order:

1. Active organization binding.
2. Novantra-managed cloud sender and transport.

Sovereign resolution order:

1. Active organization binding.
2. Install-level mailer configured by the install administrator.

If an organization has activated a customer-managed transport, regulated profiles should not silently fall back to the Novantra-managed Cloud sender. Treat fallback as a policy decision that needs clear internal approval.

Sovereign: configuring mail

Install-level fallback mail settings live in the system console under System -> Mailer, and require the install-admin role (SystemConfigure permission). This fallback is still required for setup and recovery, but individual organizations can configure their own sender and relay from the workspace email settings.

You can defer mail configuration during the first-run setup wizard, but several flows will stop working until you come back and finish it:

• New install-admin accounts cannot complete email verification.
• Membership invitations to new users will fail.
• Password resets will fail.

So while it’s optional during install, it’s effectively required for normal operation.

Sender identity

Every send needs a “from” address. You configure that here:

• Sender address (required) - the email address mail will appear to come from, for example novantra@acme.com.
• Sender name (optional) - the display name people see in their inbox, for example Acme Novantra or Acme HR Platform.

Sender address must be a real, valid email address. Novantra validates the binding and test-send posture, but SPF, DKIM, DMARC, journaling, and archive behavior are owned by the relay and domain you choose. Outbound mail is signed by whatever SMTP relay you point Novantra at, so terminate DKIM on that relay.

Pick a provider

There are four choices. Pick the one that matches the mail infrastructure you already have.

SMTP (generic)

Use this if you have an existing SMTP relay - a corporate Exchange, Postfix, a smarthost provided by your hosting platform, or anything that speaks plain SMTP. Providers such as SendGrid, Mailgun, and Postmark connect here through their SMTP endpoints.

Microsoft 365

Use this if your organization uses Microsoft 365 and you want Novantra mail to flow through your tenant’s SMTP service.

AWS SES

Use this if you send mail through Amazon Simple Email Service. Novantra connects to SES over its SMTP interface (not the API).

To create the credential pair, use the SES console’s SMTP settings screen, not regular IAM access keys.

Console (development only)

Use this for evaluation, local development, or staging where you do not want mail to actually be delivered. The “console” provider does not call out to any network - it logs the message metadata to the install’s log stream so you can see what would have been sent.

Send a test email

Once you’ve saved a configuration, click Send test email on the same settings page. The test sends to the email address of the admin currently signed in.

The system records the outcome on the settings page:

• When the last test was run.
• Whether it succeeded or failed.
• A sanitized error message if it failed (no raw SMTP banners, no leaked passwords).
• The timestamp of the last successful real send (not just tests).
• A running count of consecutive failures so you can spot a transport that recently broke.

You are rate-limited to 5 test sends per 15 minutes to prevent loops.

Day-to-day behavior

After setup, mail mostly takes care of itself. A few things to know:

• Send failures do not block user actions inside the product. If SMTP is briefly down, the failed-send count rises, but a user clicking “reset my password” still gets a response - they just don’t get the email until you fix the transport.
• Credentials are encrypted at rest with the install’s key provider (the one you configured in Sovereign Installation). Rotating SMTP passwords on your provider’s side requires editing the mailer config and saving the new password.
• Every config change is audited. Organization email binding changes and install mailer changes require a reason and are recorded.
• Test failures do not affect production sends. A failed test means “this admin couldn’t get a test email”; the live send path uses the same config and may succeed or fail independently. Trust the last successful send timestamp and the consecutive failures counter as your real signal.

If you skip mail at install time

It’s allowed but limited. The first-run setup wizard lets you defer mail. If you do:

• The first-admin account is created without email verification. You can verify it later, after mail is configured.
• The setup wizard records that mail is pending.
• User flows that depend on email will fail with a clear error until you finish.

Come back to System → Mailer in the admin shell when you’re ready.

Related

• Cloud Regions & Residency - how email risk fits the selected regional cell.
• Sovereign Installation - the first-run setup wizard touches mail briefly; this guide picks up where that left off.
• Access URLs - the mail subsystem builds links that point at your access URLs, so they need to be correct before mail is useful.