Essentially, users rely on Microsoft 365's out-of-office (OOF) feature to notify others of their absence and ensure smooth collaboration. However, when these messages fail to function as intended, it can lead to frustration. As a Microsoft 365 admin, it's crucial to pinpoint the underlying causes of these issues.
Typically, OOF replies will not be triggered if an email is identified as junk by Exchange Online Protection. Additionally, several existing configurations in Exchange Online can lead to failed automatic replies in Outlook. To address issues with out-of-office replies, consider these common pitfalls that may interfere with the proper operation of the feature.
Out-of-office configuration issues
Incorrect date & time settings or missing messages for external users can cause out-of-office issues. Additionally, misconfigurations like enabling messages only for contacts can also lead to problems with the out-of-office functionality.
Conflict with Exchange Online transport rules
Transport rules in Exchange Online can conflict with the OOF functionality if not set up correctly. If any changes in transport rules are made to redirect, reject, or delete a message, it can prevent out-of-office rules from sending auto-replies.
Active SMTP mailbox forwarding
If a user mailbox has SMTP forwarding enabled, OOF replies won't be generated.
External OOF option turned off for the user
When a setting is configured to restrict external OOF replies for some users, their automatic replies for external organizations won't be sent. While Outlook or MS Teams enables the users to set OOF for external org, it won't get applied as this was blocked for such users.
To check if a user is blocked from sending auto-replies to external organizations, you can use the following cmdlet.
Get-Mailbox "<user’s UPN>" | Select-Object ExternalOofOptions
If you see the value of ‘ExternalOofOptions’ as ‘InternalOnly’, you can allow users to send OOF replies to external users using the following cmdlet.
Set-Mailbox "<user’s UPN>" -ExternalOofOptions External
Mailbox configured to receive journal NDRs
If a user mailbox is set to get undeliverable journal reports, OOF replies won't be sent from that mailbox, and journaling email messages may also be affected.
You can use the following cmdlet to verify whether the respective mailbox is included to receive the journal reports if the journaling mailbox is unavailable.
Get-TransportConfig | fl JournalingReportNdrTo*
If you find the affected mailbox is assigned to the ‘JournalingReportNdr’ parameter, set the param with a dedicated (non-user) mailbox address or an external address.
Set-TransportConfig –JournalingReportNdrTo "<Email Address>"
Remote domain configured to block OOF replies
If the OOF reply is disabled or misconfigured for a remote domain, auto-replies won't be sent to users in that domain as expected.
To review the OOF-enabled state and the reply type in all remote domains, use the following cmdlet.
Get-RemoteDomain -ResultSize Unlimited | ft Identity, DomainName, AutoReplyEnabled, AllowedOOFType
If you find any misconfigurations, use the cmdlet below to enable the OOF reply state and change the OOF reply type to ‘External’.
Set-RemoteDomain -Identity "<Remote Domain Identity>" -AutoReplyEnabled $true -AllowedOOFType External
Here, you can also set the reply mode as ‘InternalLegacy’, ‘ExternalLegacy’, and ‘None’ to make the OOF replies delivered as intended for the appropriate remote domain users.