Exchange 2010 shadow redundancy helps prevent a message from being lost while it is moving between transport servers. A Hub Transport server keeps its copy until the next hop confirms delivery; if that hop fails before confirming, Exchange can resubmit the message. This is protection for mail in transit—not for mail already delivered to a mailbox.
How shadow redundancy works
-
A sending server connects to an Exchange 2010 Hub Transport server, which accepts and holds the primary message.
-
Exchange uses the SMTP
XSHADOWverb to coordinate shadow redundancy with a server that supports it. If the source server does not support the feature, Exchange can use delayed acknowledgment configured on the Receive connector, allowing it to create a redundant copy before acknowledging receipt. -
The primary server keeps the message in its queue database until the next hop reports successful delivery. If that next hop fails before the acknowledgment arrives, the primary server can resubmit the message.
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.#1 Best Overall
-
The shadow server monitors delivery status through SMTP discard-status exchanges. If the primary server becomes unreachable for the configured resubmit interval, the shadow server can assume responsibility and send the message onward. A change in the primary queue database ID can trigger takeover sooner.
In a multi-hop route, the server holding a shadow copy tracks whether the next hop has completed its part of delivery. For example, an Edge Transport server may retain its copy while Hub Transport servers attempt delivery onward. Rob Sanfilippo’s technical overview illustrates this kind of failover path; Microsoft’s documentation is the authority for configuration and behavior.
What Exchange 2010 shadow redundancy protects—and what it does not
The feature protects a message during transport by preserving another copy until the next hop’s delivery is verified. It does not guarantee that mail can survive every failure: it requires an eligible peer, and failures affecting two or more servers involved in the same message’s redundancy can exceed the protection available.
Shadow redundancy is distinct from the Exchange 2010 transport dumpster. The dumpster retained messages that had been successfully delivered but had not yet replicated to passive database copies in a Database Availability Group (DAG). If an outdated copy was activated, those messages could be resubmitted. Safety Net, introduced in Exchange 2013, is the later, improved post-delivery feature. It is not another name for Exchange 2010 shadow redundancy.
Topology determines whether a shadow copy is possible
-
Non-DAG server: Microsoft describes the eligible peer as another server in the same local Active Directory site.
Rank #2
-
DAG member: Another member of the same DAG can provide redundancy, including a member in a remote site.
-
Single-server organization: There is no second eligible server, so shadow redundancy cannot create a redundant transport copy.
-
Under-provisioned DAG or multiple failures: Protection may be unavailable if there is no eligible peer or if two or more involved servers fail.
Recommended: Crashes or Glitches? A Free Driver Scan Usually Finds the Culprit →Recommended: PC Feels Slow? A Free Scan Shows What's Dragging Windows Down →Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Acceptance behavior when Exchange cannot create a shadow copy
Microsoft’s current transport documentation lists ShadowRedundancyEnabled as enabled by default and RejectMessageOnShadowFailure as $false. With the latter setting, Exchange can accept a message even when it cannot create a shadow copy; acceptance therefore does not mean redundant persistence was achieved.
If RejectMessageOnShadowFailure is set to $true, Exchange instead returns the transient SMTP response 451 4.4.0 Message failed to be made redundant when it cannot create the copy. This lets the sending server retry rather than have Exchange accept a message without the intended redundancy. It should be considered only when the topology has another eligible server.
The cited Microsoft Learn article applies to Exchange 2016, Exchange 2019, and Exchange Server Subscription Edition, although it also describes Exchange 2010’s historical behavior. Its configuration defaults are not proof of the settings in a particular Exchange 2010 installation. Check the actual organization configuration and documentation for the installed service pack before making operational changes.
Monitoring intervals and failover behavior
Microsoft’s current documentation lists a two-minute default for ShadowHeartbeatFrequency and a three-hour default for ShadowResubmitTimeSpan. These are documented defaults for the implementation covered by that page, not verified values for every Exchange 2010 environment. A shadow server can assume responsibility when it cannot contact the primary for the applicable resubmit interval; a changed queue database ID may cause earlier takeover.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Recovery can result in duplicate delivery to external recipients. For example, a shadow server may resubmit after losing contact with the primary, then the original server may return with its old queue database and send the message too. Exchange duplicate detection is intended to prevent duplicate visibility to internal mailbox users, but external systems may receive duplicates.
A separate timeout can also lead a sender to retry: the primary may have accepted the message even though the sender timed out before receiving the acknowledgment. As with failover resubmission, duplicate detection helps protect Exchange mailbox users from seeing duplicates.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Microsoft-documented defaults to treat cautiously
The values below are defaults listed in Microsoft’s current Exchange transport documentation, not a verified inventory of Exchange 2010 deployments. Confirm the installed version, service pack, and actual configuration before using them as operational guidance.
| Setting | Documented default | What it controls |
|---|---|---|
ShadowRedundancyEnabled |
$true, organization-wide |
Whether shadow redundancy is enabled. |
RejectMessageOnShadowFailure |
$false |
Whether Exchange rejects a message if it cannot create a shadow copy. When $true, the documented response is transient 451 4.4.0. |
ShadowMessagePreferenceSetting |
PreferRemote when a DAG spans sites |
Shadow-server preference in a multi-site DAG; the documentation describes local fallback after configured retries. |
MaxRetriesForRemoteSiteShadow |
4 | Retries for remote-site shadow creation. |
MaxRetriesForLocalSiteShadow |
2 | Retries for local-site shadow creation. |
ShadowHeartbeatFrequency |
2 minutes | Interval for shadow-status heartbeat activity. |
ShadowResubmitTimeSpan |
3 hours | Default interval before the shadow server can resubmit after losing contact with the primary. |
ShadowMessageAutoDiscardInterval |
2 days | How long a shadow message is retained before automatic discard under the documented implementation. |
SafetyNetHoldTime |
2 days | Retention period for Safety Net messages, a later feature rather than Exchange 2010 shadow redundancy. |
MessageExpirationTimeout |
2 days | Documented message-expiration default. |
What to verify in a legacy Exchange 2010 organization
-
Confirm whether the organization has an eligible second server in the required site or DAG.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchSpecial offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
Check the actual values of
ShadowRedundancyEnabledandRejectMessageOnShadowFailure; do not infer them from current-version defaults. -
Review the Receive connector’s delayed-acknowledgment configuration if messages can arrive from sources that do not support
XSHADOW. -
Use documentation applicable to the installed Exchange 2010 service pack before changing transport settings.
Quick Recap
Bestseller No. 4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
