Understanding and troubleshooting Out of Office (OOF) replies
OOF replies can be a bit of a mystery. How do they work? Why do they sometimes not get delivered to other users, and what do you do if they don't? This article discusses the bits and pieces of OOF replies from the perspective of an Exchange Online configuration. However, much of this discussion also applies to an on-premises configuration.
(If you've ever wondered why "Out of Office" is abbreviated as "OOF" instead of as "OOO," see this blog post).
What are Out of Office replies?
OOF, or automatic replies are Inbox rules that are set in the user's mailbox by the client. OOF rules are server-side rules. Therefore, they are triggered regardless of whether the client is running.
Automatic replies can be configured as follows:
- By using the automatic reply feature from within Outlook as explained here
- By using other clients, such as Outlook on the web (OWA)
- By running a PowerShell command (Set-MailboxAutoReplyConfiguration)
Admins can set up OOF replies from the Microsoft 365 Admin Portal on behalf of users.
If automatic replies are enabled, only one reply is sent to each sender even if a recipient receives multiple messages from a sender.
In addition to using the built-in OOF functionality in their client, people sometimes use rules to create an Out of Office message while they are away.
By design, Exchange Online Protection uses the high risk delivery pool (HRDP) to send OOF replies, because OOF replies are lower-priority messages.
Types of OOF rules
There are three types of OOF rules:
- Internal
- External
- Known Senders (contact list)
These rules are set individually in the user's mailbox. Each rule has an associated message class and name. The rule name is stored in the PR_RULE_MSG_NAME property. The following table lists the message class and name that are associated with each OOF rule.
| Type | Message class | PR_RULE_MSG_NAME |
|---|---|---|
| Internal | IPM.Rule.Version2.Message | Microsoft.Exchange.OOF.KnownExternalSenders.Global |
| External | IPM.Rule.Version2.Message | Microsoft.Exchange.OOF.AllExternalSenders.Global |
| Known Senders | IPM.ExtendedRule.Message | Microsoft.Exchange.OOF.KnownExternalSenders.Global |
Note
In addition to the OOF rules, other rules (such as the Junk Email rule) also have the IPM.ExtendedRule.Message message class. The MSG_NAME variable determines how the rule is used.
OOF rule details
All Inbox rules can be viewed by using the MFCMapi tool:
- Log on to the tool.
- Select the profile that's associated with the mailbox that has the OOF rules.
- At the top of the information store, select Inbox, and then right-click Open associated contents table.
OOF rules in MFCMapi:
OOF rules templates in MFCMapi:
OOF response history
An OOF response is sent one time per recipient. The list of recipients to whom the OOF response is sent are stored in the OOF history, which is cleared out either when the OOF state changes (enabled or disabled) or when the OOF rule is modified. OOF history is stored in the user's mailbox, and can be viewed by using the MFCMapi tool at: Freebusy Data > PR_DELEGATED_BY_RULE.
Note
If you want to send a response to the sender every time instead of only one time, you can apply the "have server reply using a specific message" mailbox server-side rule instead of using the OOF rule. This alternative rule sends a response every time that a message is received.
Troubleshoot OOF issues
The following sections discuss some of the scenarios in which OOF replies aren't sent to the sender. They include possible fixes and some more frequently seen OOF configuration issues that you may have experienced.
OOF issues related to transport rules
If an OOF reply appears not to have been sent for all users in the tenant, a transport rule is usually to blame. Check all the transport rules that may apply to the affected mailbox by using step 2 of this article.
If you suspect a delivery problem, run a message trace from the Microsoft 365 tenant. For OOF messages, the sender of the original message becomes the recipient during tracking. You should be able to determine whether the OOF reply has been triggered and sent to an external or internal recipient. The message trace will clearly indicate whether a transport rule is blocking the OOF response.
There's one scenario that's worth highlighting when it comes to transport rules blocking OOF replies. Let's assume that you moved the MX record to a third-party anti-spam program. You have created a transport rule to reject any email message that's sent from any IP address other than the third-party anti-spam program.
The transport rule will look like this example:
Description:
If the message: Is received from 'Outside the organization' Take the following actions: reject the message and include the explanation 'You are not permitted to bypass the MX record!' with the status code: '5.7.1' Except if the message: sender ip addresses belong to one of these ranges: '1xx.1xx.7x.3x'
ManuallyModified: False
SenderAddressLocation: Envelope
Because OOF rules have a blank (<>) return path, the OOF rule unexpectedly matches the transport rule, and OOF responses get blocked.
To fix this issue, change the "Match sender address in message" transport rule property to "Header or envelope", so that the checks will also be done against the From(also known as "Header From"), Sender, or Reply-To fields. For more information about mail flow rule conditions, see the "Senders" section of this article.
JournalingReportNdrTo mailbox setting
If the affected mailbox is configured under the JournalingReportNdrTo setting, OOF replies won't be sent for that mailbox. Additionally, journaling email messages may also be affected. A recommended practice is to create a dedicated mailbox for the JournalingReportNdrTo setting. Alternatively, you can set the dedicated mailbox to an external address.
For more information about how to resolve this issue, see Transport and mailbox rules in Exchange Online or in on-premises Exchange Server don't work as expected.
Forwarding SMTP address is enabled on the mailbox
If the affected user mailbox has SMTP forwarding enabled, OOF replies won't be generated. It can be checked in any of the following locations:
In the user mailbox settings in the client (such as Outlook on the web):
In PowerShell:
Get-Mailbox -Identity Daniel | fl DeliverToMailboxAndForward, ForwardingSmtpAddress, ForwardingAddress
In User Properties in the Microsoft 365 Portal:
For information about how to resolve this issue, see this article.
OOF reply type that is set on remote domains
Pay attention to which OOF reply type is set up on remote domains, because it will affect the OOF reply. If the configuration of the OOF reply type is incorrect, an OOF reply may not be generated at all.
There are four OOF reply types:
- External
- ExternalLegacy
- InternalLegacy
- None
For more information about these OOF types, see the AllowedOOFType entry in the "Parameters" section of Set-RemoteDomain.
You can check the OOF reply type from Exchange Admin Center > Mail flow > Remote domains.
Alternatively, you can run the following PowerShell cmdlet:
Get-RemoteDomain | ft -AutoSize Name, DomainName, AllowedOOFType
As an example, assume that you have a hybrid organization that includes mailboxes that are hosted both in Exchange on-premises and Exchange Online. By design, only external messages in this scenario will be sent to Exchange on-premises if AllowedOOFType is set to External. To send internal OOF messages to Exchange on-premises in a hybrid environment, set AllowedOOFType to InternalLegacy.
You also have the option at the mailbox configuration level (ExternalAudience: Known) to send external OOF replies only to people who are listed as your Contacts. Run the following command to check the configuration:
Get-MailboxAutoReplyConfiguration daniel | fl ExternalAudience
Remote domain blocks OOF replies
Another setting on remote domains is one that you use to allow or prevent messages that are automatic replies from client email programs in your organization.
This setting can be found in Exchange Admin Center > Mail flow > Remote domains.
Alternatively, you can run the following PowerShell cmdlet:
Get-RemoteDomain | ft -AutoSize Name, DomainName, AutoReplyEnabled
Note
If the value of the setting is false, no automatic replies will be sent to users in that domain. This setting takes precedence over the automatic replies that are set up at the mailbox level or over the OOF type (as discussed earlier). Keep in mind that true is the default value for new remote domains that you create and the built-in remote domain named Default in Exchange Online. And false is the default value for the built-in remote domain named Default in on-premises Exchange.
If the email message is marked as spam and sent to Junk, an automatic reply isn't generated at all
This is self-explanatory.
Message trace shows delivery failure
When you investigate an OOF reply issue, you might find the following error entry in the message trace:
"550 5.7.750 Service unavailable. Client blocked from sending from unregistered domains."
If you find this entry, contact Microsoft Support to learn why the unregistered domain block was enforced.
Message trace shows a Drop event
In the message trace, you may see a Drop event with a description that resembles the following example:
250 2.1.5 RESOLVER.OOF.IntToExt; handled internal OOF addressed to external recipient
This is a normal log entry.
When Exchange Online generates OOF replies, it generates and sends both internal and external replies. When the replies are delivered, messages that don't apply will be dropped. For example, if the type of OOF replies that can be sent to recipients in the remote domain is set to External or ExternalLegacy, the internal reply will be dropped, and the Drop event will be logged. For replies that are sent to internal recipients, a similar ExtToInt event will occur.
Additional OOF issues
When you create, configure, or manage OOF replies, you might also experience the following issues.
An old or duplicate OOF message is sent
If either an old or duplicate OOF reply is sent, check for a duplicate Inbox rule, and delete it if you find one.
If there isn't an additional Inbox rule, this issue may also occur if the OOF history reaches its limit. The OOF history has a limit of 10,000 entries. If this threshold is reached, new users can't be added to the history list. In this situation, OOF replies will continue to be sent to recipients who are not already in the list – one reply for every message sent by the recipients. All users who are already in the list will not receive duplicate OOF replies.
To resolve this issue, use one of the following methods.
Method 1
- Remove the OOF rules and the OOF rules templates from the mailbox. To locate the rules, see the OOF rule details section.
- Disable and then re-enable the OOF feature for the mailbox.
- Check again whether the OOF feature works as expected and the symptoms do not occur.
Method 2
If Method 1 doesn't resolve the issue, remove the OOF response history.
Disable automatic replies in Outlook if currently enabled and exit Outlook.
Log on to the MFCMapi tool and select Tools > Options.
Select the following check boxes:
- Use the MDB_ONLINE flag when calling OpenMsgStore
- Use the MAPI_NO_CACH flag when calling OpenEntry
Select Session > Logon.
Select the Outlook profile for the mailbox and double-click to open it.
Expand Root Container and then select Freebusy Data.
In the Other Names column, right-click the PR_DELEGATED_BY_RULE property that has the 0x3FE30102 tag, point to Edit as stream, and then select Binary.
Select all the text in the Stream (Binary) box and delete it.
Two different OOF messages are sent
If two different OOF messages are sent, and you don't find an additional Inbox rule, the culprit is likely an OOF rule in the Outlook client. To check for and delete such a rule, follow these steps:
In the Outlook client, select File > Automatic Replies > Rules.
Select the OOF rule and then select Delete Rule.
Automatic replies cannot be enabled and an error message is received
When you try to access automatic replies from the Outlook client, you receive the following error message:
"Your automatic reply settings cannot be displayed because the server is currently unavailable. Try again later."
To help narrow down this issue, follow these steps:
Verify that the EWS protocol is enabled on the mailbox. OOF replies rely on this protocol. (Notice that it might take several hours for the protocol to be re-enabled.)
Enable the OOF feature by running the following cmdlet:
Set-MailboxAutoReplyConfiguration <identity> -AutoReplyState EnabledCheck whether the OOF feature works as expected.
If the issue still exists, review the rules quota on the mailbox:
Get-mailbox -identity <mailbox> | fl RulesQuota
By default, the RulesQuota parameter has a maximum value of 256 KB (262,144 bytes). This is determined by the size of the rules, not the number of rules.
Remove the OOF rules and the OOF rules templates from the mailbox. To locate the rules, see the OOF rule details section. After you remove the rules, you can re-enable the OOF feature and then test again.
An automatic reply is sent even if OOF is disabled
In some scenarios, OOF messages are still sent even though the feature is disabled. This might occur if the rule is created manually by using the out-of-office template.