---
title: How to use Get-EmailAddressPolicy in Powershell
slug: get-emailaddresspolicy-powershell
published: 2025-10-23T16:48:12.000Z
updated: 2025-10-23T16:48:12.000Z
feature_image: /blog/images/get-emailaddresspolicy-powershell/get-emailaddresspolicy-syntax-microsoft-learn.1600.webp
feature_image_alt: Microsoft Learn documentation for the Get-EmailAddressPolicy cmdlet showing its PowerShell syntax
author: James Futhey
author_slug: james
meta_description: Learn how to use Get-EmailAddressPolicy in PowerShell to view and verify email address policies in Exchange Server and Exchange Online.
status: published
---

In Microsoft Exchange, **email address policies** define how addresses are automatically assigned to recipients such as **mailboxes, distribution groups**, and **contacts**.

The **Get-EmailAddressPolicy** cmdlet allows administrators to **view** those policies, inspect their filters and templates, and verify how addresses are structured before applying updates with other cmdlets like **Set-EmailAddressPolicy** or **Update-EmailAddressPolicy**.

This cmdlet is available in both **Exchange Server (on-premises)** and **Exchange Online**.

## What is the Get-EmailAddressPolicy Cmdlet?

The **Get-EmailAddressPolicy** cmdlet is used in **Exchange Management Shell** (on-premises) or **Exchange Online PowerShell** to display existing **email address policies**. Each policy defines how primary and secondary SMTP addresses are generated for users and other recipients in your Exchange organization.

It provides detailed information about each policy, including the **policy name, recipient filter, priority, enabled templates**, and **applied domains**. Administrators typically use this command before modifying a policy with **Set-EmailAddressPolicy** or creating a new one with **New-EmailAddressPolicy**.

### Syntax

Get-EmailAddressPolicy [[-Identity] _EmailAddressPolicyIdParameter_]

```powershell
[-DomainController _Fqdn_]
[-IncludeMailboxSettingOnlyPolicy]
[<CommonParameters>]
```

### Parameters

-   **Identity** – Specifies the email address policy to view by name, distinguished name (DN), or GUID.
-   **DomainController** – (On-premises only) Specifies the FQDN of the domain controller that retrieves data.
-   **IncludeMailboxSettingOnlyPolicy** – Displays policies that apply only to mailbox settings (legacy usage).
-   **CommonParameters** – Supports standard PowerShell common parameters such as Verbose, Debug, ErrorAction, and WarningAction.

## Practical Uses of Get-EmailAddressPolicy

### 1\. Auditing existing address policies before migrations

Before performing an **Exchange Server upgrade** (for example, from **Exchange 2013** to **Exchange 2019**) or moving to **Exchange Online**, administrators use **Get-EmailAddressPolicy** to list all active and legacy email address policies.

This ensures that each **mailbox, distribution group**, and **linked mailbox** follows the correct **SMTP address format** and that all policies reference valid **accepted domains**. It’s also crucial for detecting old or duplicate address templates left over from earlier environments such as **Exchange 2003** or **Exchange 2007**.

### 2\. Verifying address policies after domain or branding changes

Organizations that undergo **rebranding**, mergers, or **domain renaming** often modify their email address formats. Running **Get-EmailAddressPolicy** allows administrators to confirm that each policy reflects the correct **domain suffix**(for example, _@meetingroom365.com_) and that **EnabledEmailAddressTemplates** align with the company’s current branding.

This verification step prevents inconsistencies that can lead to **SMTP delivery issues** or **Outlook** client confusion when users’ display names and **proxy addresses** change.

### 3\. Troubleshooting recipient filter mismatches

When new **users** or **distribution groups** do not receive the expected email address, **Get-EmailAddressPolicy** helps identify the cause. Administrators can review each policy’s **RecipientFilter, RecipientContainer**, and **Priority** values to determine why a mailbox didn’t match a specific rule.

Combined with **Get-Mailbox**, it becomes straightforward to test which recipients are included or excluded by a policy, making it easier to resolve **policy application errors, Recipient Update Service** mismatches, or **custom filter issues**.

## Prerequisites

The following conditions must be met to use **Get-EmailAddressPolicy**:

-   You must have the **Email Address Policies** management role assigned. This role is included in both **Organization Management** and **Recipient Management** role groups.
-   Available in **Exchange Online** and **on-premises Exchange** (Exchange 2010 or later).
-   In **Exchange Online**, email address policies apply **only to Microsoft 365 Groups**.
-   For on-premises Exchange, if you specify **\-DomainController**, it must resolve to a valid Active Directory FQDN.
-   PowerShell access to Exchange must be configured through **Exchange Management Shell** (on-prem) or **Connect-ExchangeOnline** (cloud).

## How to Use Get-EmailAddressPolicy: 7 Practical Uses

Before modifying or applying any email address policies, it’s important to understand how to retrieve and interpret them. The **Get-EmailAddressPolicy** cmdlet lets administrators quickly inspect which policies exist, how they’re prioritized, and which filters or templates they use.

The examples below show the most common ways to run the command for daily management, troubleshooting, or documentation.

### 1\. View all email address policies

**Command:**

Get-EmailAddressPolicy

This lists every existing policy in your Exchange environment. It helps you quickly see the **policy names, priorities**, and **recipient filters** that determine which users or groups each policy applies to.

Admins typically run this first to verify that all policies are present and prioritized correctly, especially after Exchange upgrades or configuration changes.

### 2\. View details for a specific policy

**Command:**

Get-EmailAddressPolicy "Default Policy"

Use the **Identity** parameter to view detailed information about a single policy, including **EnabledEmailAddressTemplates, Priority**, and **RecipientFilter**.

This helps confirm how addresses are generated and **which recipients the policy targets**.

For example, checking the **Default Policy** is useful when new mailboxes receive **unexpected address formats** or when verifying that recent changes to accepted domains were applied correctly. It’s also **a good quick validation step** after modifying a policy with **Set-EmailAddressPolicy**.

### 3\. Include mailbox-only (legacy) policies

**Command:**

Get-EmailAddressPolicy -IncludeMailboxSettingOnlyPolicy

Some older Exchange environments may still have policies created under earlier versions (like Exchange 2003 or 2007).

By default, those aren’t shown. Adding this switch includes **mailbox-setting-only** policies, which is helpful during cleanup or migration audits to ensure no outdated policies remain active.

### 4\. Display complete policy details

**Command:**

Get-EmailAddressPolicy | Format-List

Running the cmdlet with **Format-List** expands all available properties, such as **EnabledEmailAddressTemplates, RecipientContainer**, and **Priority**.

This view is ideal when you need full visibility into policy structure or when comparing multiple Exchange servers to ensure configuration consistency.

### 5\. Check the order of policy priority

**Command:**

Get-EmailAddressPolicy | Sort-Object Priority | Select Name, Priority

Policies are applied in numerical order of **Priority**, where 1 is highest. Sorting them makes it clear which policy takes effect first when multiple policies could apply.

Use this to confirm that specialized rules (like for executives or specific departments) are evaluated before general organization-wide ones.

### 6\. Find policies by domain or filter

**Command:**

Get-EmailAddressPolicy | Where-Object {$\_.EnabledEmailAddressTemplates -match "meetingroom365.com"}

This command filters the results to display only the policies that include a specific **domain** in their email address templates. For example, if your organization is transitioning from _meetingroom365.com_ to _newbrand.com_, this helps you identify all the policies that still reference the old domain.

It’s also valuable when managing multiple **accepted domains** across departments or subsidiaries. You can quickly confirm that each domain in use has a corresponding address policy and that no legacy domains remain in production. For companies operating in hybrid Exchange environments, this ensures that on-premises and **Exchange Online** policies are aligned before performing domain removals or DNS changes.

**Tip:** Running this check proactively avoids delivery failures caused by policies that continue to generate SMTP addresses for domains no longer accepted by the organization.

### 7\. Export policy summary for documentation

**Command:**

Get-EmailAddressPolicy | Select Name, Priority, RecipientFilter | Export-Csv "C:\\Reports\\EmailPolicies.csv" -NoTypeInformation

Exporting policy information to a **CSV file** is one of the simplest but most effective ways to document your Exchange configuration.

This approach provides a structured snapshot of key details - the **policy name, priority**, and **recipient filter** - which can be reviewed in **Microsoft Excel** or shared with compliance teams for auditing.

For organizations with strict IT governance or multi-admin environments, this export doubles as an accountability record. It ensures transparency in how **address policies** evolve and supports consistent mailbox management across both **Exchange Server** and **Exchange Online** infrastructures.

## Final Note

The **Get-EmailAddressPolicy** cmdlet is strictly for reviewing and auditing - it doesn’t modify or apply policies on its own. Always use it before running **Set-EmailAddressPolicy** or **Update-EmailAddressPolicy**, especially in production environments. Having a clear picture of your existing policies prevents misapplied rules, unexpected SMTP address changes, and address conflicts that can disrupt mail flow across **Exchange Server** and **Exchange Online**.
