Q: Can a Database Availability Group have a mix of Exchange Server 2013 and Exchange Server 2016 members?

A: No.

When information about Windows Server 10 began to emerge one of the interesting items was mixed-mode clusters, which will allow a rolling upgrade of the operating systems on cluster members without having to take the entire cluster offline or build an entirely new cluster. Naturally this lead to speculation that Exchange might support mixed-mode DAGs as well.

While I agree that would be a terrific feature, Microsoft has clearly stated that it is not supported to run different versions of Exchange Server within the same DAG.

Update 16/12/2015 – Microsoft has added the block to prevent this in Cumulative Update 11 for Exchange Server 2013

The problem right now is that Exchange Server 2016 RTM has shipped without the necessary blocks to prevent a customer from adding 2013 and 2016 servers to the same DAG. Microsoft has included information in the release notes for Exchange Server 2016 to clarify this.

Mailbox servers running different versions of Exchange can be added to the same database availability group The Add-DatabaseAvailabilityGroupServer cmdlet and the Exchange Admin Center incorrectly allow an Exchange 2013 server to be added to an Exchange 2016-based database availability group (DAG), and vice versa. Exchange supports adding only Mailbox servers running the same version (Exchange 2013 versus Exchange 2016, for example) to a DAG. Additionally, the Exchange Admin Center displays both Exchange 2013 and Exchange 2016 servers in the list of servers available to add to a DAG. This could allow an administrator to inadvertently add a server running an incompatible version of Exchange to a DAG (for example, adding an Exchange 2013 server to an Exchange 2016-based DAG). There is currently no workaround for this issue. Administrators must be diligent when adding a Mailbox server to a DAG.

So yes, it is technically possible today to do it, but it is completely unsupported to do so.

This definitely wins the award for Bug That Should Never Have Shipped in RTM.