E-mail Accounts

Before the platform can send or receive emails, you need at least one E-mail Account configured. An E-mail Account bundles the credentials and connection settings for one mailbox — typically your transactional sender, plus any additional accounts for marketing, support inbound, or specific workflows.

From the Architect Panel → E-mail Accounts

Click New to start a new account. The configuration form asks for:

• Display Name — what "From" name recipients see in their inbox (e.g. "Acme Support", "Acme Notifications").
• From Address — the email address messages are sent from (e.g. support@acme.com, noreply@acme.com).
• Send Mode — SMTP (direct), Microsoft Graph (for Office 365), or Relay (through a configured Relay Client).
• Receive Mode — IMAP, POP3, Microsoft Graph, or none (for send-only accounts).

Pick send-only configuration for accounts that only need to send (most transactional accounts), or send+receive for accounts that also need inbound processing (support inboxes, reply-handling).

SMTP credentials

For Send Mode = SMTP, fill in:

• Host — your SMTP server address (e.g. smtp.sendgrid.net, smtp.mailgun.org, smtp.office365.com).
• Port — typically 587 for STARTTLS, 465 for SSL.
• Username / Password — credentials from your SMTP provider.
• Encryption — TLS (preferred), SSL, or none (only for trusted internal networks).

Test the connection before saving. The platform's Test button sends a tiny test message and reports back success or the specific SMTP error.

Sender verification — SPF, DKIM, DMARC

For deliverability, configure SPF / DKIM / DMARC records for the from-address's domain. Without those, many recipients (Gmail in particular, but most modern providers) treat your messages as spam.

• SPF — a DNS TXT record listing which servers are allowed to send mail for your domain. Your SMTP provider tells you what to add.
• DKIM — a cryptographic signature on outgoing mail. Your SMTP provider gives you a public key to publish as DNS.
• DMARC — a policy record saying what to do with mail that fails SPF/DKIM. Start with p=none for monitoring, move to p=quarantine or p=reject once you're confident your mail is well-aligned.

Three real-world accounts

Example 1: Transactional sender via SendGrid

Display Name: "Acme". From: noreply@acme.com. Send Mode: SMTP. Host: smtp.sendgrid.net:587 TLS. Receive Mode: none. SPF/DKIM/DMARC configured. Used for password resets, confirmations, all transactional sends.

Example 2: Support inbox via Microsoft Graph

Display Name: "Acme Support". From: support@acme.com. Send Mode: Microsoft Graph (for outbound replies). Receive Mode: Microsoft Graph (for inbound). Office 365 tenant + app credentials configured. Used to send and receive support emails, with the platform auto-creating tickets from inbound messages.

Example 3: Marketing via Mailgun (separate from transactional)

Display Name: "Acme Newsletter". From: newsletter@acme.com. Send Mode: SMTP via Mailgun. Receive Mode: none. Separate from the transactional account to prevent marketing complaints from damaging transactional deliverability.

SMTP is the standard outbound email protocol. ActiveManage talks SMTP to any compliant server — your SMTP provider's relay, your own mail server, or a hosted transactional-mail service like SendGrid, Mailgun, Postmark, or Amazon SES.

Required settings

On the E-mail Account configuration, when Send Mode is SMTP:

• Host — the SMTP server's hostname.
• Port — typically 587 for STARTTLS, 465 for SSL, 25 for unencrypted (don't use 25 over the public internet).
• Username / Password — authentication credentials from your provider.
• Encryption — TLS (preferred), SSL, or none.

Common providers

• SendGrid: Host smtp.sendgrid.net, port 587, TLS. Username is literally apikey, password is your SendGrid API key.
• Mailgun: Host smtp.mailgun.org, port 587, TLS. Username and password from the Mailgun control panel.
• Postmark: Host smtp.postmarkapp.com, port 587, TLS. Username and password from Postmark.
• Amazon SES: Host varies by region (email-smtp.eu-west-1.amazonaws.com etc.), port 587, TLS. SES-specific SMTP credentials generated in the SES console.
• Office 365: Host smtp.office365.com, port 587, TLS. Your Office 365 mailbox credentials. Note: Microsoft is increasingly restricting SMTP AUTH — prefer Microsoft Graph if available.
• Gmail (G Suite / Google Workspace): Host smtp.gmail.com, port 587, TLS. Requires an app-specific password or OAuth.
• Custom on-prem mail server: whatever your IT department gives you.

Picking a provider

Three criteria to weigh:

1. Deliverability

How likely are emails to actually arrive in inboxes (not spam folders)? Transactional-mail specialists (SendGrid, Mailgun, Postmark, AWS SES) have stronger deliverability than generic providers because they invest in IP reputation and sender best-practices.

2. Cost

Transactional-mail services charge per email. Typical pricing:

• First 100/day free (most providers).
• $10-20/month for 50k emails (entry tier).
• $50-100/month for 250k.
• $200+/month for 1M+.

3. Features

Beyond basic sending: open tracking, click tracking, bounce handling, webhook callbacks on delivery events, suppression lists, dedicated IPs, etc. The transactional specialists offer all of these; basic SMTP doesn't.

Testing

The platform has a Test Connection button on each E-mail Account. Always test before going live. The test sends a tiny message and reports:

• SMTP authentication success or failure (with reason).
• Delivery confirmation from the provider.
• Any error message returned by the SMTP server.

After saving, also send a real end-to-end test by triggering a real workflow that sends an email — check the recipient's inbox to verify everything looks right (subject, body, links, branding).

For pulling incoming messages, the platform supports IMAP and POP3. Configure these when an E-mail Account also needs to receive — typically support inboxes, reply-handling, automated inbound processing.

IMAP vs POP3 — which to use

IMAP

Messages stay on the server; ActiveManage reads them in place and (optionally) moves processed messages to a sub-folder. Preferred for ongoing inboxes that other clients (e.g. Outlook on a staff member's desktop) also access — they all see the same mailbox state.

Use IMAP when:

• The mailbox is also used by humans via desktop/mobile clients.
• You want messages to remain accessible after platform processing.
• You want the platform to organise processed messages into folders.

POP3

Messages are downloaded and (optionally) removed from the server. The platform takes the messages, processes them, and the server-side copy can be deleted.

Use POP3 when:

• ActiveManage is the only consumer of the mailbox.
• You don't need to retain the messages on the mail server (the platform's processing creates whatever records you need).
• The mail server doesn't support IMAP.

Required settings

For either protocol:

• Host — incoming server hostname (e.g. imap.gmail.com, outlook.office365.com).
• Port — IMAP: 993 SSL, 143 STARTTLS. POP3: 995 SSL, 110 STARTTLS.
• Username / Password — mailbox credentials.
• Encryption — TLS strongly recommended; SSL also fine.
• Polling interval — how often the platform checks for new messages.

Folder selection

For IMAP, you pick which folder(s) to monitor:

• Inbox — the default; works for most cases.
• Sent — useful when processing replies you've sent and want to track responses.
• Archive — useful for slow-pace processing or batch ingestion.
• Custom folders — for installs that use folder-based triage (e.g. a "Process by ActiveManage" folder).

Polling interval

How often the platform polls determines how quickly incoming messages get processed. Trade-offs:

• Every 1 minute — near-realtime. Higher load on the mail server. Right for support inboxes where speed matters.
• Every 5 minutes — good balance. Default for most setups.
• Every 15 minutes — relaxed. Right for low-volume mailboxes where speed doesn't matter.
• Hourly or longer — for batch-style processing where the platform just needs to catch up periodically.

Three real-world inbox configurations

Example 1: Support inbox

IMAP to Office 365 mailbox support@acme.com. Port 993 SSL. Polling: every 1 minute. Folder: Inbox. After processing, messages are flagged read and moved to a "Processed" sub-folder.

Example 2: Order acknowledgements from supplier

POP3 to mailbox orders@acme.com. Port 995 SSL. Polling: every 5 minutes. Messages are downloaded and deleted from the server (ActiveManage is the only consumer).

Example 3: Slow-pace ingestion

IMAP to a dedicated mailbox that receives batch reports from a partner. Polling: every hour. Folder: Inbox. Once a day, the platform processes everything and generates a summary report.

For Office 365 mailboxes, Microsoft Graph is the modern API and is generally preferred over SMTP/IMAP. More reliable than SMTP AUTH (which Microsoft is increasingly restricting), avoids storing passwords, and supports the full Graph feature set including richer search and folder operations.

Why prefer Graph over SMTP for Office 365

Three reasons:

1. Modern OAuth — no stored password

Graph uses OAuth 2.0 client-credentials flow. The platform stores a client ID and client secret, not a user password. Compromise of the credentials gives access to the configured mailbox only, scoped by the Graph permissions you granted — much narrower blast radius than a stored mailbox password.

2. Bypasses Microsoft's SMTP AUTH restrictions

Microsoft has been progressively disabling Basic Auth (SMTP with username+password) for Office 365 tenants. Many tenants now have it disabled by default for new mailboxes. Graph doesn't have this problem — it's the supported modern path.

3. Better operational features

Better deliverability statistics, more accurate bounce reporting, native folder operations (move processed messages to a sub-folder cleanly), full-text mailbox search.

Setup

Five steps:

1. Register an application in Azure AD. Go to portal.azure.com → Azure Active Directory → App Registrations → New Registration. Pick a name (e.g. "ActiveManage E-mail"), single tenant, no redirect URI needed for client-credentials flow.
2. Note the Tenant ID, Client ID from the app's Overview page.
3. Create a Client Secret under Certificates & Secrets. Copy the value immediately — it's only shown once.
4. Grant Mail.Send and Mail.Read permissions under API Permissions. Mail.Send for outbound, Mail.Read (or Mail.ReadWrite) for inbound. Grant admin consent.
5. In ActiveManage, create an E-mail Account with Send Mode = Microsoft Graph (and/or Receive Mode = Microsoft Graph), enter the Tenant ID, Client ID, Client Secret, and the target mailbox address.

Token refresh

Graph uses OAuth tokens that expire (typically after 1 hour). The platform refreshes them automatically using the configured app credentials — you don't need to do anything ongoing.

If the client secret expires (Azure secrets have a max lifetime, typically 1-2 years), generate a new one and update the E-mail Account. The platform notifies you when it can't refresh tokens.

Permissions granularity

The default Graph permissions (Mail.Send, Mail.Read) grant access to all mailboxes in the tenant. For tighter scoping:

• Use Application Access Policies in Exchange Online to restrict the app's access to specific mailboxes only.
• Or use delegated permissions instead of application permissions if the app should act on behalf of a specific user.

Three real-world Graph setups

Example 1: Transactional sender from a service account

App registered with Mail.Send only. Restricted via Application Access Policy to one mailbox noreply@acme.com. Used for all transactional outbound.

Example 2: Bidirectional support inbox

App registered with Mail.Send + Mail.ReadWrite. Scoped to support@acme.com. Used for both inbound ticket creation and outbound reply sending.

Example 3: Multi-mailbox setup

One app registration with broad permissions. Multiple E-mail Accounts in ActiveManage, each pointing at a different mailbox in the same tenant.