Email notifications
Send an email through your own Microsoft 365 or SMTP infrastructure the moment a certificate is issued - mail apps, recipients, retries and history.
Monitoring > Email Notifications sends an email through your mail infrastructure the moment a certificate is issued. The usual reason is a handoff: another team has to install the certificate on a system aethercert does not manage itself.
This is not used for aethercert's own system email - sign-in, billing, invitations - which always comes from us.
Mail apps
A mail app is a sender you configure once and reuse. Two providers are supported.
| Provider | What it needs |
|---|---|
| Microsoft 365 | An app registration in your tenant with mail-send permission. |
| SMTP | Host, port, a security mode of STARTTLS, implicit TLS or none, and optionally a username and password. |
Credentials go to Vault and are never returned to the browser. Choosing none as the SMTP security mode means the message crosses the network unencrypted, and the form requires an explicit acknowledgement of that before it will save.
Send test delivers one message immediately so you can confirm the sender works before a real certificate depends on it. The result - success, or the error - is kept on the mail app, and both outcomes appear in the event log.
How many mail apps you can configure depends on your plan: 1 on Free, 3 on Standard, 10 on Pro, 5 on the MSP tiers.
Turning a notification on
Notifications are opt-in per certificate. On a certificate job or a certificate policy, the Notifications section takes:
| Field | Rules |
|---|---|
| Enabled | Off by default. |
| Mail app | Required when enabled. |
| Recipients | At least one and at most 10 addresses when enabled. Duplicates are collapsed. |
| Message | Optional, up to 500 characters, added to the mail body. |
Recipient addresses are format-checked whether or not notifications are enabled, so a malformed address is never stored. Carriage returns and line feeds are rejected outright
- that is part of the defence against header injection, not just tidiness.
A policy's notification settings are inherited by every certificate it creates.
When a notification is sent
One is queued when an issue or renew job succeeds. That includes the case the feature exists for: a job whose certificate was issued but failed to deploy, where somebody has to install it by hand.
A redeployment of a certificate that was already issued does not send one.
Retries and history
A send that fails is retried, up to three attempts in total, with the next attempt 30 seconds out. A notification that exhausts its attempts is marked failed and recorded in the event log as an alert-worthy event - because it usually means the "please deploy this manually" handoff never went out.
Every attempt, successful or not, is kept in the notification history on the same page.
MSP Plus
An MSP Plus portal can send its customers' mail through one of these same mail apps, so messages leave from your domain and pass your SPF, DKIM and DMARC. Pick it under MSP > Branding > Customer mail. If a send through your server fails, the message still goes out through aethercert and the fallback is recorded in your event log. See MSP customer workspaces.
Event log
The organization-wide audit trail: what is recorded, who the actor was, how long it is kept, and where to look when something failed.
Monitoring integrations
Push alert-worthy events to a webhook, a syslog/CEF collector or an SNMP trap receiver - payload shape, signing, and what is delivered.