Skip to main content

Outlook & Exchange Mailbox Configuration Troubleshooting

This guide helps you identify and fix mailbox-level settings that silently block email fetching in ServiceOps.

When emails arrive at your support mailbox but no tickets are created in ServiceOps, the cause is usually a mailbox-level setting blocking or rerouting emails before ServiceOps can fetch them. This guide walks you through the most common mailbox configuration issues in Outlook and Exchange Online so you can find and fix the problem quickly. For failures related to server configuration, see Email Server Troubleshooting.

Prerequisites​

Before you begin, ensure you have access to the following accounts and tools.

  • Outlook checks: sign in to https://outlook.office.com as the support mailbox user
  • Exchange Online checks: sign in to https://admin.exchange.microsoft.com as an Exchange Administrator
  • PowerShell checks: connect via Connect-ExchangeOnline -UserPrincipalName admin@company.com
Admin Center URLs

Exchange Online Admin Center: https://admin.exchange.microsoft.com Microsoft 365 Admin Center: https://admin.microsoft.com Microsoft Purview Compliance: https://compliance.microsoft.com

Troubleshooting Steps​

Email Forwarding Removing Emails from the Inbox​

Possible Reasons:

  • Email forwarding is enabled on the support mailbox without Keep a copy of forwarded messages checked.
  • Emails are redirected to another address and removed from the inbox before ServiceOps can fetch them.
  • Cross-forwarding between monitored mailboxes is creating a duplicate ticket loop.

Solution:

  1. Check in Outlook Web App:

    1. Sign in to the support mailbox at https://outlook.office.com.
    2. Click the Settings gear icon (top right) and select View all Outlook settings.
    3. Go to Mail > Forwarding.
    4. Check whether Enable forwarding is toggled on and note the forwarding address.
    5. Check whether Keep a copy of forwarded messages is ticked.

Disable forwarding entirely on the ServiceOps support mailbox. If forwarding is a business requirement, enable Keep a copy of forwarded messages. Without it, emails leave the inbox and ServiceOps finds nothing to fetch.

Forwarding Loop Risk

If support@company.com forwards to helpdesk@company.com and that mailbox forwards back, ServiceOps creates duplicate tickets or fails to process emails entirely. Disable cross-forwarding between monitored mailboxes.

Inbox Rules Intercepting Emails Before ServiceOps Polls​

Possible Reasons:

  • An inbox rule is deleting, moving, or auto-replying to emails before ServiceOps polls the inbox.
  • Emails are moved to a subfolder that ServiceOps does not monitor.
  • An auto-reply rule is creating an infinite loop with ServiceOps notifications.

Solution:

  1. Check in Outlook Web App:

    1. Click Settings gear > View all Outlook settings.
    2. Go to Mail > Rules.
    3. Review every rule. Check the condition (what it matches) and the action (what it does to the email).
    4. Pay particular attention to rules with actions: Delete, Move to folder, Move to Junk, or Auto-reply.

  2. Check in Outlook Desktop:

Open File > Manage Rules and Alerts and review all rules applied to the mailbox.

Remove any rule that deletes, moves, or archives incoming emails to subfolders other than Inbox. ServiceOps polls the Inbox folder by default, so emails in any other folder are invisible to it.

Subfolder Moves Are Invisible to ServiceOps

A "Move to folder" rule that moves emails to any subfolder (including named folders like "Support Tickets") breaks ticket creation silently. ServiceOps polls only the Inbox unless you configure it to poll a specific folder.

An auto-reply rule on the support mailbox creates an infinite loop: ServiceOps sends a notification, the rule auto-replies, ServiceOps receives the reply and creates another ticket, which triggers another auto-reply. Disable auto-reply rules on monitored mailboxes.

Emails Deleted by Retention Policy Before Fetching​

Possible Reasons:

  • A retention policy is deleting or archiving emails faster than the ServiceOps polling interval.
  • The Inbox folder has a short retention tag that removes emails before ServiceOps reads them.

Solution:

  1. Check in Outlook Web App:

Right-click any email in the Inbox and look for Assign policy. This shows the retention tag on that email or folder. Right-click the Inbox folder itself and select Assign Policy to see the folder-level tag.

  1. Check in Outlook Desktop:

Right-click an email and select Assign Policy to view the active retention tag.

Set the Inbox retention period to 30 days or more. If compliance requires a shorter retention period, use a "Move to Archive" policy rather than "Permanently Delete" so emails are recoverable.

Email Address or Primary SMTP Address Mismatch​

Possible Reasons:

  • The email address configured in ServiceOps is an alias that has been removed or changed by an admin.
  • ServiceOps is connecting using an address that does not match the mailbox's primary SMTP address or any active alias.

Solution:

Go to Settings > View all Outlook settings > Mail > Sync email. Under Email aliases, Outlook lists all addresses associated with the account. The primary address is marked "Primary."

Use the primary SMTP address in ServiceOps whenever possible. Aliases can be removed or changed by an admin, which would break the ServiceOps configuration without any warning. If you use an alias in ServiceOps, verify it is still active after every admin change.

Emails Landing in Junk Email Folder​

Possible Reasons:

  • Outlook's junk email filter is moving legitimate emails to the Junk Email folder.
  • The ServiceOps sending domain is not on the Safe Senders list.
  • The Junk Email Filter level is set to "High," causing false positives on legitimate customer emails.

Solution:

  1. Check in Outlook Web App:

    1. Go to Settings > View all Outlook settings > Mail > Junk email.
    2. Check the Blocked senders and domains list for any legitimate requester addresses or domains.
    3. Check the Safe senders and domains list and confirm the ServiceOps sending domain appears there.
    4. Open the Junk Email folder in OWA and check whether any emails that should have created tickets landed there.

    Add the ServiceOps sending domain to the Safe Senders list. Keep the Junk Email Filter level off "High" for the support mailbox, as high sensitivity incorrectly classifies legitimate customer emails as junk.

Exchange Admin-Level Forwarding Removing Emails from Inbox​

Possible Reasons:

  • Admin-configured forwarding is redirecting emails out of the inbox without keeping a copy.
  • DeliverToMailboxAndForward is set to False, causing emails to leave the mailbox entirely.
  • Microsoft 365 Defender's outbound anti-spam policy is silently blocking forwarding rules.

Solution:

Where to check: EAC > Recipients > Mailboxes > click the support mailbox > Mail flow tab > Email forwarding section.

PowerShell check:

Connect-ExchangeOnline -UserPrincipalName admin@company.com
Get-Mailbox -Identity "support@company.com" | Select-Object ForwardingAddress, ForwardingSmtpAddress, DeliverToMailboxAndForward

What the output means:

OutputMeaning
ForwardingSmtpAddress: emptyNo forwarding. Correct for ServiceOps.
ForwardingSmtpAddress: set AND DeliverToMailboxAndForward: TrueEmails are forwarded and a copy is kept in the mailbox. ServiceOps can still fetch them.
ForwardingSmtpAddress: set AND DeliverToMailboxAndForward: FalseEmails are forwarded and removed from the inbox. ServiceOps finds an empty mailbox. Fix this immediately.

How to fix:

Set-Mailbox -Identity "support@company.com" -DeliverToMailboxAndForward $true
Anti-Spam Outbound Policy

Microsoft 365 Defender blocks automatic forwarding to external domains by default. Go to Microsoft 365 Defender > Email and collaboration > Policies and rules > Threat policies > Anti-spam > Anti-spam outbound policy. If Automatic forwarding rules is set to "Off - Forwarding is disabled," any forwarding rules on the mailbox silently fail.

Transport Rules Blocking or Redirecting Emails​

Possible Reasons:

  • An active transport rule is deleting, redirecting, or quarantining emails before they are delivered to the mailbox.
  • A "Require TLS" rule is causing delivery failures for senders that do not support TLS.

Solution:

Where to check: EAC > Mail flow > Rules

PowerShell check:

Get-TransportRule | Select-Object Name, State, Priority, Description | Format-Table
Get-TransportRule | Where-Object {$_.State -eq "Enabled"} | Format-List Name, Conditions, Actions

Actions that break ServiceOps email fetching:

  • Delete the message without notifying anyone: ServiceOps never receives the email.
  • Redirect the message to: The email goes to a different mailbox that ServiceOps doesn't monitor.
  • Quarantine the message: The email goes to quarantine, not the mailbox.
  • Require TLS: Causes delivery failure if the sender doesn't support TLS.

Remove or modify any active transport rule that targets the support mailbox address or domain with a Delete, Redirect, or Quarantine action on emails intended for ServiceOps.

Exchange Retention Policy Removing Emails Before Fetching​

Possible Reasons:

  • An Exchange or Microsoft Purview retention policy is deleting emails faster than the ServiceOps polling interval.
  • Litigation hold is not enabled, so emails permanently deleted by retention policies cannot be recovered.

Solution:

Where to check: https://compliance.microsoft.com > Data lifecycle management > Microsoft 365 > Retention policies

PowerShell check:

Get-Mailbox -Identity "support@company.com" | Select-Object RetentionPolicy, LitigationHoldEnabled, LitigationHoldDuration, SingleItemRecoveryEnabled, RetainDeletedItemsFor

What the output means:

FieldMeaning
RetentionPolicyName of the MRM policy applied. Check the policy in EAC > Compliance management > Retention policies.
LitigationHoldEnabled: TrueLitigation hold is active. All emails are preserved regardless of deletion actions. ServiceOps can still read them.
LitigationHoldEnabled: FalseNo litigation hold. Emails deleted by retention policies are gone permanently after the deleted items retention window.

Set the Inbox retention period to 30 days or more. If compliance requires shorter retention, set LitigationHoldEnabled to True so emails are preserved in the compliance archive even after the policy moves them.

Email Alias No Longer Active​

Possible Reasons:

  • The email address used in ServiceOps is an alias that was removed by an admin.
  • A domain migration changed the primary SMTP address without updating ServiceOps.

Solution:

Where to check: EAC > Recipients > Mailboxes > click the support mailbox > Email address tab.

PowerShell check:

Get-Mailbox -Identity "support@company.com" | Select-Object -ExpandProperty EmailAddresses

In the output, the primary SMTP address has the prefix SMTP: (uppercase). Aliases use smtp: (lowercase).

Confirm the address in ServiceOps appears in the EmailAddresses list. Use the primary SMTP address (not an alias) so a future alias change doesn't break the configuration silently. After any domain migration that changes the primary SMTP address, update all ServiceOps email server configurations to match.

Service Account Missing Full Access Permission​

Possible Reasons:

  • The service account used by ServiceOps does not have Full Access permission on the target mailbox.
  • Full Access delegation was removed by an admin after initial setup.
  • ServiceOps is attempting to use a shared mailbox address directly for OAuth login, which is not supported.

Solution:

Where to check: EAC > Recipients > Mailboxes > click the support mailbox > Delegation tab

  • Full Access: The account used to authenticate ServiceOps must be listed here if it is different from the mailbox owner.
  • Send As: Required if the outgoing server sends emails as the support mailbox address using a different service account.

PowerShell check:

Get-MailboxPermission -Identity "support@company.com" | Where-Object {$_.AccessRights -eq "FullAccess"} | Select-Object User, AccessRights
Get-RecipientPermission -Identity "support@company.com" | Select-Object Trustee, AccessRights

How to grant Full Access:

Add-MailboxPermission -Identity "support@company.com" -User "serviceaccount@company.com" -AccessRights FullAccess -InheritanceType All
Shared Mailboxes Can't Log In Directly

Shared mailboxes have no credentials of their own. ServiceOps can't use a shared mailbox address for OAuth interactive login. The service account with Full Access must log in, and Microsoft Graph or IMAP accesses the shared mailbox on its behalf. If Full Access delegation gets removed by an admin, OAuth authentication succeeds but mailbox reads fail with 403 Forbidden.

Emails Quarantined by Microsoft 365 Defender Policies​

Possible Reasons:

  • Anti-spam, anti-phishing, or anti-malware policies are quarantining emails before they reach the mailbox.
  • The ServiceOps server IP or sending domain is not on the Safe Senders or Allowed IPs list.
  • Safe Attachments scanning is delaying email delivery, causing IMAP polling to miss emails on the first cycle.

Solution:

Where to check: Microsoft 365 Defender portal at https://security.microsoft.com > Email and collaboration > Policies and rules > Threat policies

1. Check quarantined emails:

Go to Email and collaboration > Review > Quarantine. Filter by recipient = the support mailbox address. If legitimate customer emails appear here, release them and adjust the anti-spam policy.

2. PowerShell check for the content filter policy:

Get-HostedContentFilterPolicy | Select-Object Name, SpamAction, HighConfidenceSpamAction, BulkThreshold

Add the ServiceOps server IP or sending domain to the "Allowed IPs" or "Safe Senders" list in the anti-spam inbound policy. Review Defender quarantine weekly during the first month of a ServiceOps deployment to catch false-positive quarantine actions before they cause ticket loss.

Safe Attachments Scanning Delays

The Safe Attachments policy scans emails before delivery and can delay arrival by several minutes. This delay can cause IMAP polling to miss emails on the first cycle. ServiceOps fetches them on the next cycle instead. If you see consistent delays between email arrival and ticket creation, check Safe Attachments policy settings in Defender.