Outgoing Email Server
Set up outgoing email servers so ServiceOps keeps your team and requesters informed on every ticket update without manual effort.
Configure outgoing email servers to enable ServiceOps to send email notifications, ticket updates, and announcements. You can set up multiple outgoing email servers and define rules to route emails through specific servers based on conditions.
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 via Microsoft Exchange Web Services (EWS), an HTTPS-based API provided by Microsoft Exchange and Office 365. It communicates over HTTPS (port 443) and provides a secure, direct connection to the mailbox for sending emails.
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.
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.
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 pop-up window will appear.
The server configuration information is available with your email service provider.
Select your Email Provider to see the relevant configuration fields and steps.
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.
Enter the following details:
| Parameter | Description |
|---|---|
| Name | Enter a name to identify this email server in ServiceOps. |
| Enter the Microsoft mailbox email address used as the From address for all notifications. | |
| Protocol | Select SMTP or MAPI. The selected protocol must be enabled on your email account. |
| Sender Name | Enter the display name shown to recipients alongside the From address. Visible only when SMTP is selected. |
| Email Provider | Select Sign in with Microsoft. |
| 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 | Toggle to enable or disable the server. |
| Primary | Enable to use this server as the fallback when other configured outgoing servers are unavailable. |
- 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.
- Click Save. The server will appear in the list. Verify connectivity using the Test Connection button.
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 |
|---|---|
| Name | Enter the name of the email server. |
| Enter the email address used as the From address for all notifications. | |
| Protocol | Select SMTP or MAPI. |
| Sender Name | Enter the display name shown to recipients alongside the From address. |
| Email Provider | Select Other. |
| 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. |
| 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 (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. |
| Reply-To Email | Enter the reply-to email address. Set this to a monitored mailbox so that recipient replies are captured and converted into tickets. |
| Proxy Server | Select the required proxy server. Leave blank if ServiceOps has direct internet access. |
| Enabled | Toggle to enable or disable the server. |
| Primary | Enable to use this server as the fallback when other configured outgoing servers are unavailable. |
| Filter Type | Select Allow to send emails only to the specified addresses or domains (all others are blocked), or Ignore to silently block emails to the specified values (all others are allowed). If no filter is configured, ServiceOps sends emails to all recipients by default. |
| Emails | Enter specific email addresses to filter. 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. 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. |
If the test email lands in the spam or junk folder, review your sender domain's SPF, DKIM, and DMARC DNS records with your mail admin.
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 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.