Outgoing Email Server
Set up outgoing email servers so ServiceOps keeps your team and requesters informed on every ticket update, and can route emails through specific servers based on conditions you define, without manual effort.
To view the Outgoing Email Servers tab, navigate to Admin > Support Channel > Emails > Outgoing Email Servers.
After upgrading ServiceOps from version 8.0 to 8.1, re-configure all email servers as additional parameters have been added.
- Version 8.0: Client ID, Client Secret, Tenant ID, and Authorization URL.
- Version 8.1 and later: Client ID, Client Secret, Authorization URL, Token URL, Scope, and Redirect URL.
Supported Protocols
ServiceOps supports two protocols for connecting to outgoing email servers. Choose based on your email provider and authentication method.
SMTP
SMTP (Simple Mail Transfer Protocol) is the standard internet protocol for sending emails. ServiceOps uses SMTP to deliver outgoing notifications through any compatible mail server. It supports both Basic Auth and OAuth 2.0.
| Security | Port |
|---|---|
| None | 25 |
| TLS | 587 |
| SSL | 465 |
Use SMTP when your mail server is Gmail, Zoho, Yahoo, Outlook, or any standard server.
SMTP authentication must be enabled on your email account before configuring it in ServiceOps.
MAPI
MAPI connects to Microsoft Exchange and Office 365 mailboxes over HTTPS (port 443) for sending emails, using either of two connection types: Microsoft Graph API or Exchange Web Services (EWS). Both provide a secure, direct connection to the mailbox.
Use MAPI when your organization uses Microsoft Exchange Online or Office 365 and authenticates via Azure App Registration (OAuth 2.0).
MAPI requires Office 365 Exchange Online permissions in Azure. Restrict mailbox access so the Azure app can access only a single mailbox.
Email Connection Type
When Protocol is set to MAPI, an Email Connection Type field appears. Select how ServiceOps connects to your Exchange Online mailbox.
| Option | Description |
|---|---|
| Microsoft Graph API | Uses the Microsoft Graph REST API to send emails. Recommended for all new MAPI configurations. See Configuring Microsoft Azure for Microsoft Graph API for setup steps. |
| Exchange Web Services | Uses the legacy EWS SOAP-based API. Select this only if Graph API is not supported for your environment. |
Microsoft is retiring Exchange Web Services (EWS) for Exchange Online on October 1, 2026. Switch to Microsoft Graph API before this date to avoid service disruption. On-Premises Exchange installations are not affected.
You can switch the Email Connection Type on an existing server at any time. ServiceOps asks for confirmation before applying the change. No configuration or routing rules are lost when switching.
Protocol Comparison
Use the table below to select the right protocol for your environment.
| Feature | SMTP | MAPI |
|---|---|---|
| Email Provider | Any standard server | Microsoft Exchange / Office 365 only |
| Authentication | Basic Auth or OAuth 2.0 | Microsoft Sign-in (Azure AD OAuth 2.0) |
| Port | 25 / 587 / 465 | 443 (HTTPS / EWS) |
| OAuth 2.0 support | Yes (via Azure or custom) | Yes (via Azure AD) |
| Recommended for | Standard and general use | Microsoft enterprise environments |
Prerequisites
Before configuring an outgoing email server, ensure the following:
- Administrative rights are required to access and modify email server settings.
- An email account must be created with your email host or provider before configuration.
- The protocol you intend to use (SMTP or MAPI) must be supported and enabled on the email account.
- Network and firewall must allow ServiceOps to reach the mail server on the required port.
- A valid SSL certificate is required on the ServiceOps server if using HTTPS or OAuth 2.0.
- For Microsoft 365 (MAPI or OAuth), an Azure App Registration with SMTP.Send permissions is required. Refer to Configuring Microsoft Azure for OAuth.
- For MAPI with Microsoft Graph API as the Email Connection Type, an Administrator account is required to complete the setup in Azure Active Directory.
How Does Outgoing Email Routing Work?
ServiceOps routes outgoing emails through the servers you configure here. When a ticket event triggers a notification (such as a status change or SLA breach), ServiceOps evaluates the outgoing email rules for that module. If a rule's conditions match, ServiceOps sends the email through the mapped server. If no rule matches, ServiceOps uses the server marked as Primary. ServiceOps monitors each server in real time and alerts the Super Admin when a server becomes unreachable.
Adding an Outgoing Email Server
Click the Add Outgoing Email Servers button in the top-right corner of the page. A side panel appears, organized into four sections: Basic Information, Connection Method, Server Settings, and Email Filters.
The server configuration information is available with your email service provider.
Basic Information
Identify this mail server within ServiceOps.
| Parameter | Description |
|---|---|
| Name | Enter a name to identify this email server in ServiceOps. |
| Email Address | Enter the email address ServiceOps uses to send emails through this server. This is the From address for all notifications. |
| Sender Name | Enter the display name shown to recipients alongside the From address. Shown only when Protocol is set to SMTP; not shown for MAPI. |
Connection Method
Choose how ServiceOps connects to this mail server.
| Parameter | Description |
|---|---|
| Protocol | Select SMTP or MAPI. The selected protocol must be enabled on your email account. |
| Email Connection Type | Shown only when Protocol is set to MAPI. Select Microsoft Graph API or Exchange Web Services. Before using Microsoft Graph API, complete the required setup in Azure Active Directory. |
| Email Provider | Select the email provider that matches your setup: - Sign in with Microsoft: For Microsoft 365 or Exchange Online. Uses ServiceOps's pre-registered Azure app, with no manual app registration needed. - Other/Custom Server: For Gmail, Yahoo, self-hosted, or any SMTP or MAPI server using Basic Auth or a custom OAuth 2.0 app. |
Continue to the section below that matches your Email Provider selection.
Setting Up a Microsoft Email Server
This option uses ServiceOps's pre-registered Azure enterprise application for Microsoft 365 email sending. No manual Azure App Registration is required. When Sign in with Microsoft is selected, the Server, Port, Security Type, and Email Auth Type fields are not shown and are handled automatically by Microsoft.
Prerequisites:
- The URL
https://email-app.serviceops.ai/must be accessible. - Internet connectivity must be available.
- The protocol used must be enabled on your email account.
- Application consent must be enabled for the user and the group they belong to.
- Click Sign in with Microsoft.
- Select or sign in to the Microsoft account you want to use.
- Click Accept to grant the required permissions. If application consent is controlled by an administrator, refer to Configuring Admin Consent first.
- Continue to Server Settings below to finish configuring the server.
Setting Up Other Email Servers
Use this option for Gmail, Zoho, Yahoo, or any mail server that requires manual configuration of server address, port, security type, and authentication credentials.
| Parameter | Description |
|---|---|
| Server | Enter the server address for the selected protocol. Common values: SMTP (Gmail): smtp.gmail.com, SMTP (Microsoft): smtp.office365.com, SMTP (Yahoo): smtp.mail.yahoo.com, MAPI: outlook.office365.com. For custom or on-premise servers, use the address provided by your mail admin. |
When Security Type is set to SSL or TLS, enter a fully qualified domain name (FQDN) in the Server field. An IP address is only supported when Security Type is set to None.
| Parameter | Description |
|---|---|
| Port | Enter the port number. Auto-populated based on Protocol and Security Type. Common values: SMTP (TLS): 587, SMTP (SSL): 465. |
| Security Type | Select None, SSL, or TLS. Always use TLS or SSL in production. |
| Authentication Needed | Enable if the server requires login credentials. Most production mail servers require this. |
| Email Auth Type | Select Basic Auth (username and password) or OAuth 2.0 (Username, Client ID, Client Secret, Authorization URL, Token URL, and Scope). Refer to Configuring Microsoft Azure for OAuth or Configuring Gmail for OAuth for OAuth setup details. Basic Auth is not supported for Microsoft Outlook. |
Server Settings
Enable, prioritize, and link this mail server.
| Parameter | Description |
|---|---|
| Reply-To Email | Enter the email address to which recipient replies will be directed. Set this to a monitored mailbox so replies are captured and converted into tickets. |
| Proxy Server | Select the desired proxy server. Leave blank if ServiceOps has direct internet access. |
| Enabled | ServiceOps uses this server to send emails. Turn off to pause the server without removing the configuration. |
| Primary Server | Used as fallback if other outgoing servers fail. At least one server should be set as primary. |
Email Filters
Control which recipients can receive emails. All recipients are allowed if no filters are configured.
| Parameter | Description |
|---|---|
| Filter Type | Select Allow so only emails to the listed addresses or domains are sent, with all others blocked. Select Ignore so emails to the listed addresses or domains are silently blocked, with all other recipients allowed. |
| Email Addresses | Enter specific email addresses to filter, then press Enter to add each one. With Allow, only these addresses receive emails. With Ignore, emails to these addresses are silently blocked. Example: hr@company.com. Multiple entries work as OR conditions. |
| Domains | Enter domain names to filter, without the @ symbol, then press Enter to add each one. Example: company.com. With Allow, only addresses in these domains receive emails. With Ignore, all addresses in these domains are silently blocked. Multiple entries work as OR conditions. |
Click Save to add the server. Verify connectivity using the Test Connection button from the list page.
Testing Your Configuration
After saving the outgoing email server, verify end-to-end delivery before relying on it for ticket notifications.
Test Connection
Click the Test Connection button from the server list page. ServiceOps prompts you to enter a recipient email address, then sends a test email using the saved server settings. This confirms both that ServiceOps can connect to the mail server and that outgoing emails are delivered to the recipient's inbox.
| Result | What It Means |
|---|---|
| Test email received in inbox | Server is correctly configured. Outgoing email delivery is working. |
| Connection error shown | ServiceOps could not connect to the mail server. Review the server settings and try again. |
| Connected but no email received | Server connected but delivery failed. Check the spam or junk folder, verify credentials, and confirm SMTP send permissions. Review the Email Audit log at Admin > Organization > Security > Operation Audit for detailed delivery logs. |
Use the table below to diagnose connection failures:
| What Is Checked | Common Causes of Failure |
|---|---|
| Server hostname or IP reachability | Wrong server address, DNS resolution failure, or firewall blocking the connection |
| Port accessibility | Wrong port number, or the port is blocked by a firewall |
| Security type handshake | SSL/TLS certificate issue, or wrong security type selected |
| Authentication credentials | Wrong username or password, expired App Password, or OAuth token issue |
| Protocol availability | SMTP or MAPI not enabled or blocked on the email account |
Monitoring Outgoing Email Server Health
Each outgoing email server card displays a real-time connection status indicator (Reachable or Unreachable). When a server becomes unreachable, an inline error message appears on the card. Click the link in the error message to view the error details. ServiceOps sends an in-app notification to the Super Admin and all users with the Manage Support Channels permission. A recovery notification is generated when the server returns to a reachable state.
Configuring Outgoing Email Rules
Outgoing email rules control which outgoing server is used for each ticket module, based on conditions such as department, technician group, or location. Without rules, ServiceOps uses the default Primary server for all notifications.
Click the Configure Outgoing Email Rules button from the server list page to open the rules panel. For full configuration details including supported modules, condition fields, and rule evaluation order, see Outgoing Email Rules.
Best Practices
For best practices that apply across all email server configuration, see Email Best Practices.
Troubleshooting
Use the sections below to resolve common issues with outgoing email server setup and email delivery.
Test Connection fails after saving the server
Check each of the following in order:
- Server address: Confirm the hostname is correct for your provider. For Gmail use
smtp.gmail.com, for Microsoft usesmtp.office365.com, for Yahoo usesmtp.mail.yahoo.com. - Port and security type: SMTP with TLS uses port 587; SMTP with SSL uses port 465. Mismatched combinations cause handshake failures.
- SMTP authentication enabled: SMTP authentication must be explicitly enabled in the mailbox settings of your email provider.
- Authentication Needed toggle: Ensure Authentication Needed is enabled. Most production servers require it.
- Credentials: For Basic Auth, verify the username and password or App Password. For OAuth, confirm the Client ID, Client Secret, and Scope are copied correctly from Azure or Gmail.
- Firewall or proxy: Ensure the port is open between ServiceOps and the mail server. If using a proxy, confirm it is configured under Proxy Server.
- OAuth token expired: If the connection was working and suddenly fails, the OAuth token or client secret may have expired. Regenerate the secret in Azure or Gmail and update the server configuration.
Emails are not being delivered to recipients
A successful Test Connection confirms connectivity but does not guarantee all emails are delivered. Check the following:
- Spam or junk folder: Ask the recipient to check their spam folder. If emails land there, your sender domain may be missing SPF, DKIM, or DMARC DNS records.
- Filter configuration: If a Filter Type is set, confirm the recipient's address or domain is not matched by an Ignore rule, and that it matches an Allow rule if one is configured.
- Primary server configured: Confirm at least one server has Primary Server enabled so ServiceOps has a fallback when no outgoing email rule matches.
- Email Audit log: Navigate to Admin > Organization > Security > Operation Audit and review Email Audit entries for
SEND_FAILEDerrors. - SMTP Send permission: For Microsoft 365, confirm the Azure app has the
SMTP.SendDelegated permission granted by an admin.
OAuth authentication errors for Microsoft Azure
OAuth failures for Microsoft-based outgoing servers are usually caused by one of the following:
- Incorrect scope: For SMTP use
offline_access https://outlook.office365.com/SMTP.Send; for MAPI useoffline_access https://outlook.office365.com/EWS.AccessAsUser.All. - Admin consent not granted: Navigate to Azure > API Permissions and confirm Grant admin consent has been clicked and all permissions show a green checkmark. Refer to Configuring Admin Consent.
- Redirect URL mismatch: The Redirect URL in ServiceOps must exactly match the Redirect URI registered in the Azure App Registration, including trailing slashes.
- Client secret expired: Check the Certificates and secrets page in Azure and regenerate if expired.
- SMTP Authentication not enabled in Microsoft 365: Navigate to Microsoft 365 Admin Center > Users > Active Users, click the mailbox, go to the Mail tab, click Manage email apps, and enable Authenticated SMTP.
Gmail App Password errors
Gmail blocks standard passwords for SMTP when 2-Step Verification is enabled. If authentication fails with Gmail Basic Auth:
- Do not use your regular Google account password.
- Go to Google Account > Security > 2-Step Verification and confirm it is enabled.
- Go to Google Account > Security > App Passwords and generate a new App Password for ServiceOps.
- Use the generated App Password (16 characters, no spaces) as the Password field in ServiceOps.
- If App Passwords is not visible, your Google Workspace admin may have disabled it. Contact your admin to enable it.