Email and SMTP
How outbound email is transported in SGEN — system mail, notifications, form responses, and the SMTP service.
Email and SMTP in SGEN is the outbound email transport layer. It carries system mail (account notifications, operational alerts), notification email driven by automation logic, and form-response email when forms are configured to send. This page is the Reference definition of the email transport — what kinds of mail flow through, which connection options exist, and what the dependency posture looks like.
What is this for?
Read this page when you want the structural definition of the email-transport integration in SGEN — what kinds of email flow through, where SMTP is configured, and what the operator should expect when transport is healthy versus unhealthy.
Good use cases
- You are scoping email delivery for a new SGEN site and need to know how transport works.
- You are explaining to a stakeholder how SGEN handles outbound mail.
- You hit a "form-response email is not arriving" question and want the model laid out.
- You are designing internal SOPs around email-related incident response.
What NOT to use this for
- Step-by-step SMTP setup procedures — open the relevant Guide.
- Per-provider SMTP product documentation — that lives with the provider.
- Inbound email handling — out of scope.
- Per-release shipped behavior change — open What's New or Changelog.
How this connects to other features
- Integrations Overview — parent Reference area.
- Payment Gateways — sibling integration covering store transactions.
- Notification Logic — automation sub-page covering how notifications are shaped before transport.
- SG-Admin Overview — surface where email configuration lives (Configuration pillar) and where forms that produce email live.
Definition
Email and SMTP in SGEN is the outbound email transport layer. The platform exposes a configured SMTP connection so system mail, automation-driven notifications, and form-response email leave the platform through a known path with known authentication.
The defining property is transport. SGEN does not author the message content from outside; it carries the messages produced by system events, automation rules, and form configurations.
Purpose
The purpose of this page is to define the email-transport integration as a Reference layer. It explains what kinds of mail flow through, where SMTP is configured, what the operator should expect at the transport layer, and how the integration pairs with Notification Logic.
Scope
This page covers the email-transport integration at the Reference level.
The page covers:
- The kinds of outbound email the platform produces.
- The SMTP connection model.
- Where transport configuration lives.
- The dependency posture (healthy vs unhealthy).
- The boundary against per-provider product documentation and inbound email.
The page does not cover:
- Inbound email handling — out of scope.
- Per-step SMTP provider setup — Guides.
- Custom email template authoring beyond platform defaults — out of scope.
Kinds of email the platform produces
Outbound email from SGEN falls into three kinds.
System mail
Account-level operational mail — invitations, password resets, billing-related alerts, support-ticket notifications. System mail is platform-managed; operators do not configure individual messages.
Notification email
Automation-driven email triggered by configured rules — backup-completion notifications, scheduled-report delivery, integration-event notifications. The Notification Logic Reference covers how notifications are shaped before transport.
Form-response email
Per-site form configuration that sends an email when a visitor submits a form. The form definition lives in the admin → My Forms; the email leaves through the same transport layer documented here.
Site · Configuration · Email transport
SMTP connection
Where SMTP is configured
SMTP configuration lives inside the admin under the Configuration pillar. The configuration is per-site (each site can use its own SMTP credentials) but follows the same shape across sites.
Per-site SMTP
Each site holds its own SMTP host, port, authentication method, and from-address. The configuration is encrypted at rest; the operator does not see the credentials in plaintext after entry.
Health check
The configuration panel exposes a test-mail action that verifies the SMTP transport is healthy without requiring the operator to wait for a real notification event.
Dependency posture
Email transport in SGEN depends on the SMTP credentials being valid and the SMTP provider being available.
Healthy transport
Mail leaves the platform within seconds of being produced. The configuration panel reports a healthy state and the test-mail action succeeds.
Unhealthy transport
Mail queues but does not leave. The configuration panel reports the unhealthy state. System mail, notifications, and form responses all stop arriving until the connection is restored.
Constraints and boundaries
Email and SMTP is a Reference area for the outbound transport layer. It is not a substitute for per-provider documentation or for inbound-email handling.
Use this Reference for:
- Understanding what kinds of email the platform produces.
- Confirming the SMTP configuration model.
- Diagnosing transport-health questions at the structural level.
Do not use this Reference for:
- Inbound email — out of scope.
- Per-provider SMTP setup — provider documentation.
- Custom email template authoring — out of scope.
Public boundary
This page is intentionally public-safe. It does not expose SMTP credentials, transport internals, or protected operational identifiers.
Examples
Example 1 — Operator configures SMTP for a new site
The operator opens the admin → Configuration → Email and enters the SMTP host, port, authentication, and from-address. They run the test-mail action to confirm transport is healthy. System mail, notifications, and form responses can now leave the platform through the configured connection.
Example 2 — Form-response email stops arriving
A visitor submits a form but the response email does not arrive. The operator opens this page (Dependency posture section), confirms the unhealthy-transport symptom, opens the SMTP configuration panel, runs the test-mail action, and identifies whether the issue is credential-side or provider-side.
Example 3 — Stakeholder asks "what does SGEN send by default?"
The platform lead opens this page (Kinds of email the platform produces section) and walks the stakeholder through system mail vs notification email vs form-response email. The Reference grounds the conversation in the platform's email model rather than requiring per-message enumeration.
Documentation guidance
Use this page as the structural definition for the email-transport integration. Procedural detail belongs in Guides; per-release behavior change belongs in What's New or Changelog. Cross-reference Notification Logic for the automation layer that produces notification mail.
Where to find it
In SGEN Admin, navigate to the admin → Configuration → Email. The SMTP configuration panel — host, port, authentication, from-address, and the test-mail action — appears under the Configuration pillar labeled Email transport. Per-site form-response email settings live under the admin → My Forms in the individual form configuration.
Reading order
Open this page when scoping email delivery or troubleshooting email-transport questions. Pair with Notification Logic for the automation layer that produces notification mail; pair with the admin Forms Reference for the form-response surface.
Related reading
- Integrations Overview — parent Reference area.
- Payment Gateways — sibling integration.
- Notification Logic — automation layer that produces notification mail.
- SG-Admin Overview — where SMTP configuration and forms live.
Vocabulary cross-reference
- SMTP is the protocol used for outbound email transport.
- System mail is operational mail produced by the platform itself.
- Notification email is mail driven by automation rules.
- Form-response email is mail produced by per-site form configuration.
- Healthy transport means mail leaves the platform within the expected window.
Maintenance discipline
When email-transport behavior changes across releases (new authentication option, new health-check surface, new mail kind), update this Reference and log the change in Changelog. The page stays valuable because the three-kind model and the SMTP configuration shape stay small.