Agreement and troubleshooting Out of Part (OOF) replies

  • Article
  • 10 minutes to read
  • Applies to:
    Exchange Online

OOF replies can exist a fleck of a mystery. How do they work? Why exercise they sometimes not get delivered to other users, and what exercise you do if they don't? This commodity 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," encounter this blog mail).

What are Out of Part replies?

OOF, or automatic replies are Inbox rules that are prepare in the user'south mailbox by the client. OOF rules are server-side rules. Therefore, they are triggered regardless of whether the client is running.

Automated replies can be configured as follows:

  • By using the automatic reply characteristic from inside Outlook as explained here
  • By using other clients, such equally Outlook on the web (OWA)
  • By running a PowerShell command (Set-MailboxAutoReplyConfiguration)

Admins can gear up OOF replies from the Microsoft 365 Admin Portal on behalf of users.

If automatic replies are enabled, merely one reply is sent to each sender even if a recipient receives multiple messages from a sender.

In addition to using the congenital-in OOF functionality in their client, people sometimes utilize rules to create an Out of Part message while they are away.

By design, Exchange Online Protection uses the loftier gamble delivery pool (HRDP) to send OOF replies, because OOF replies are lower-priority messages.

Types of OOF rules

There are 3 types of OOF rules:

  • Internal
  • External
  • Known Senders (contact list)

These rules are set individually in the user'southward mailbox. Each rule has an associated message class and name. The dominion name is stored in the PR_RULE_MSG_NAME holding. The following table lists the message grade and proper name that are associated with each OOF rule.

Type Message grade PR_RULE_MSG_NAME
Internal IPM.Rule.Version2.Message Microsoft.Exchange.OOF.KnownExternalSenders.Global
External IPM.Rule.Version2.Bulletin Microsoft.Substitution.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 Electronic mail rule) also take the IPM.ExtendedRule.Message message form. The MSG_NAME variable determines how the dominion is used.

OOF rule details

All Inbox rules can be viewed by using the MFCMapi tool:

  1. Log on to the tool.
  2. Select the profile that's associated with the mailbox that has the OOF rules.
  3. At the top of the data shop, select Inbox, and and then right-click Open up associated contents table.

OOF rules in MFCMapi:

Screenshot of OOF rules in MFCMapi.

OOF rules templates in MFCMapi:

Screenshot of OOF rules templates in MFCMapi.

OOF response history

An OOF response is sent ane 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 land changes (enabled or disabled) or when the OOF rule is modified. OOF history is stored in the user'south mailbox, and tin be viewed by using the MFCMapi tool at: Freebusy Information > PR_DELEGATED_BY_RULE.

Screenshot of the OOF response history that's stored in the Freebusy Data.

Note

If y'all desire to send a response to the sender every time instead of simply one fourth dimension, you tin can apply the "have server reply using a specific bulletin" mailbox server-side rule instead of using the OOF rule. This alternative dominion sends a response every time that a message is received.

Troubleshoot OOF issues

The post-obit sections discuss some of the scenarios in which OOF replies aren't sent to the sender. They include possible fixes and some more often seen OOF configuration bug that you may accept experienced.

If an OOF reply appears not to have been sent for all users in the tenant, a transport rule is usually to arraign. Check all the ship rules that may utilize to the afflicted mailbox by using stride two of this article.

If you suspect a delivery problem, run a bulletin trace from the Role 365 tenant. For OOF messages, the sender of the original bulletin becomes the recipient during tracking. You should be able to decide whether the OOF respond has been triggered and sent to an external or internal recipient. The message trace will clearly indicate whether a transport dominion is blocking the OOF response.

There's one scenario that'south worth highlighting when it comes to send rules blocking OOF replies. Let's assume that you lot moved the MX record to a third-party anti-spam program. You lot have created a ship dominion to reject any email message that'southward sent from any IP address other than the third-party anti-spam program.

The ship rule will expect like this example:

Description:
If the message: Is received from 'Exterior the organisation' Take the following actions: reject the bulletin and include the explanation 'You are non permitted to featherbed the MX record!' with the status code: '5.7.ane' Except if the message: sender ip addresses belong to ane of these ranges: '1xx.1xx.7x.3x'
ManuallyModified: False
SenderAddressLocation: Envelope

Because OOF rules take a blank (<>) return path, the OOF dominion unexpectedly matches the transport rule, and OOF responses get blocked.

To fix this effect, change the "Match sender address in bulletin" transport rule holding to "Header or envelope", so that the checks volition also be done against the From(also known equally "Header From"), Sender, or Reply-To fields. For more than information almost mail flow rule conditions, come across the "Senders" section of this commodity.

Screenshot to select Header on the Match sender address in message page.

JournalingReportNdrTo mailbox setting

If the afflicted mailbox is configured nether the JournalingReportNdrTo setting, OOF replies won't exist 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, yous tin can set the dedicated mailbox to an external address.

For more than information most how to resolve this issue, meet Ship and mailbox rules in Exchange Online or in on-bounds Exchange Server don't piece of work equally expected.

Forwarding SMTP accost is enabled on the mailbox

If the affected user mailbox has SMTP forwarding enabled, OOF replies won't be generated. It tin exist checked in whatever of the following locations:

  • In the user mailbox settings in the client (such every bit Outlook on the web):

    Screenshot of checking forwarding SMTP address using the client.

  • In PowerShell:

                      Get-Mailbox -Identity Daniel | fl DeliverToMailboxAndForward, ForwardingSmtpAddress, ForwardingAddress

    Screenshot of checking forwarding SMTP address using PowerShell.

  • In User Properties in the Microsoft 365 Portal:

    Screenshot of checking forwarding SMTP address using the Microsoft 365 Portal.

For information about how to resolve this issue, run into this article.

OOF reply type that is assail remote domains

Pay attention to which OOF reply blazon is fix 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 exist generated at all.

There are 4 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 tin check the OOF respond type from Exchange Admin Center > Mail flow > Remote domains.

Screenshot of Out of Office automatic reply types.

Alternatively, you tin can run the post-obit PowerShell cmdlet:

              Get-RemoteDomain | ft -AutoSize Proper name, DomainName, AllowedOOFType

Screenshot of checking OOF reply using PowerShell.

As an example, assume that you have a hybrid arrangement that includes mailboxes that are hosted both in Substitution on-premises and Exchange Online. By blueprint, only external messages in this scenario volition be sent to Substitution on-premises if AllowedOOFType is set to External. To send internal OOF messages to Exchange on-premises in a hybrid surroundings, gear up AllowedOOFType to InternalLegacy.

You also have the option at the mailbox configuration level (ExternalAudience: Known) to send external OOF replies but to people who are listed as your Contacts. Run the post-obit control to bank check the configuration:

              Get-MailboxAutoReplyConfiguration daniel | fl ExternalAudience

Screenshot of checking OOF reply configuration using PowerShell.

Remote domain blocks OOF replies

Another setting on remote domains is i that you lot utilize to let or prevent messages that are automated replies from client email programs in your arrangement.

This setting can be found in Exchange Admin Middle > Mail flow > Remote domains.

Screenshot of Automatic replies setting.

Alternatively, yous tin can run the following PowerShell cmdlet:

              Get-RemoteDomain | ft -AutoSize Name, DomainName, AutoReplyEnabled

Screenshot of checking OOF reply blocking using PowerShell.

Note

If the value of the setting is false, no automated replies volition be sent to users in that domain. This setting takes precedence over the automatic replies that are set upward at the mailbox level or over the OOF type (as discussed earlier). Keep in mind that truthful is the default value for new remote domains that you create and the born remote domain named Default in Commutation Online. And false is the default value for the built-in remote domain named Default in on-premises Exchange.

If the email bulletin is marked as spam and sent to Junk, an automatic reply isn't generated at all

This is cocky-explanatory.

Message trace shows commitment failure

When you investigate an OOF reply consequence, you might discover the following error entry in the message trace:

"550 5.7.750 Service unavailable. Customer blocked from sending from unregistered domains."

If you discover this entry, contact Microsoft Back up to learn why the unregistered domain cake was enforced.

Message trace shows a Driblet effect

In the message trace, you may see a Drop result with a description that resembles the post-obit case:

250 2.1.v 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 case, if the type of OOF replies that can be sent to recipients in the remote domain is set up to External or ExternalLegacy, the internal answer volition be dropped, and the Drop event will be logged. For replies that are sent to internal recipients, a similar ExtToInt issue volition occur.

Additional OOF issues

When yous create, configure, or manage OOF replies, you might too experience the post-obit issues.

An old or duplicate OOF bulletin is sent

If either an old or indistinguishable OOF reply is sent, bank check for a duplicate Inbox dominion, and delete it if you notice one.

If there isn't an additional Inbox dominion, this issue may too 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 listing. In this situation, OOF replies volition keep to be sent to recipients who are non already in the listing – one reply for every message sent by the recipients. All users who are already in the list volition not receive duplicate OOF replies.

To resolve this upshot, apply one of the following methods.

Method ane

  1. Remove the OOF rules and the OOF rules templates from the mailbox. To locate the rules, see the OOF rule details section.
  2. Disable so re-enable the OOF feature for the mailbox.
  3. Check again whether the OOF feature works every bit expected and the symptoms do not occur.

Method 2

If Method 1 doesn't resolve the issue, remove the OOF response history.

  1. Disable automatic replies in Outlook if currently enabled and get out Outlook.

  2. Log on to the MFCMapi tool and select Tools > Options.

  3. Select the following check boxes:

    • Use the MDB_ONLINE flag when calling OpenMsgStore
    • Use the MAPI_NO_CACH flag when calling OpenEntry

  4. Select Session > Logon.

  5. Select the Outlook profile for the mailbox and double-click to open it.

  6. Expand Root Container and and so select Freebusy Information.

  7. In the Other Names column, right-click the PR_DELEGATED_BY_RULE belongings that has the 0x3FE30102 tag, point to Edit as stream, and then select Binary.

  8. Select all the text in the Stream (Binary) box and delete it.

Ii different OOF letters are sent

If ii different OOF letters are sent, and you don't find an boosted Inbox rule, the culprit is likely an OOF rule in the Outlook customer. To check for and delete such a dominion, follow these steps:

  1. In the Outlook client, select File > Automatic Replies > Rules.

  2. Select the OOF rule and and so select Delete Rule.

    Screenshot shows steps to delete the automatic reply rule.

Automatic replies cannot be enabled and an error message is received

When you lot try to access automatic replies from the Outlook customer, you receive the following error message:

"Your automated respond settings cannot exist displayed because the server is currently unavailable. Try once more afterwards."

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. (Find that it might take several hours for the protocol to exist re-enabled.)

  • Enable the OOF feature past running the following cmdlet:

                      Set-MailboxAutoReplyConfiguration <identity> -AutoReplyState Enabled

  • Check whether the OOF feature works equally expected.

  • If the upshot withal exists, review the rules quota on the mailbox:

                      Get-mailbox -identity <mailbox> | fl RulesQuota

    Screenshot of checking mailbox identity.

    By default, the RulesQuota parameter has a maximum value of 256 KB (262,144 bytes). This is determined past the size of the rules, non 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 department. After you remove the rules, you can re-enable the OOF feature so exam once again.

An automatic respond 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 dominion is created manually by using the out-of-role template.