When a Mailbox or an Edge Transport server receives incoming mail from a server using a non-SMTP connector, it stores the message in the Replay directory and then resubmits it for delivery by using SMTP. When a Mailbox or an Edge Transport server has a message to deliver to a non-SMTP connector, it stores the message in the Replay directory and then resubmits it for delivery to the foreign connector. In this way, messages received from non-SMTP connectors are processed and routed, and messages to non-SMTP connectors are delivered.

Your Transport servers automatically process any correctly formatted .eml message file copied into the Pickup directory. Exchange considers a message file that is copied into the Pickup directory to be correctly formatted if it meets the following conditions:

Transport servers check the Pickup directory for new message files every five seconds. Although you can’t modify this polling interval, you can adjust the rate of message file processing by using the –PickupDirectoryMaxMessagesPerMinute parameter on the Set-TransportService cmdlet. The default value is 100 messages per minute. When a transport server picks up a message, it checks the message against the maximum message size, the maximum header size, the maximum number of recipients, and other messaging limits.

For the Pickup directory, the maximum message size is 10 megabytes (MB), the maximum header size is 64 kilobytes (KB), and the maximum number of recipients is 100 by default. As may be necessary to meet the needs of your organization, you can change these limits by using the Set-TransportService cmdlet. If a message file doesn’t exceed any assigned limits, the Transport server renames the message file by using a .tmp extension, and then converts the .tmp file to an email message. After the message is successfully queued for delivery, the Transport server issues a “close” command and deletes the .tmp file from the Pickup directory.

Your Transport servers automatically process any correctly formatted .eml message file copied into the Replay directory. Exchange considers a message file that is copied into the Replay directory to be correctly formatted if it meets the following conditions:

Transport servers check the Replay directory for new message files every five seconds. Although you can’t modify this polling interval, you can adjust the rate of message file processing by using the –PickupDirectoryMaxMessagesPerMinute parameter of the Set-TransportService cmdlet. This parameter controls the rate of processing for both the Pickup directory and the Replay directory. The Transport server renames the message file by using a .tmp extension, and then converts the .tmp file to an email message. After the message is successfully queued for delivery, the server issues a “close” command and deletes the .tmp file from the Replay directory.

Exchange considers any improperly formatted email messages received in the Pickup or Replay directory to be undeliverable and renames them from the standard message name (MessageName.eml) to a bad message name (MessageName.bad). Because this is considered a type of message-processing failure, a related error is also generated in the event logs. In addition, if you restart the Microsoft Exchange Transport service when .tmp files are in the Pickup directory, Replay directory, or both directories, all .tmp files are renamed as .eml files and are reprocessed, which can lead to duplicate message transmissions.

Because of the way message pickup and replay works, Transport servers do not perform security checks on messages submitted through these directories. This means that if you’ve configured anti-spam, antivirus, sender filtering, or recipient filtering actions on a Send connector, those checks are not performed on the Pickup or Replay directory. To ensure that the Pickup and Replay directories are not compromised by malicious users, specific security permissions that must be tightly controlled are applied.

For the Pickup and Replay directories, you must configure the following permissions:

When you have a need to balance the load across a server’s disk drives or ensure ample free space for messages, you can move the Pickup and Replay directories to new locations. Move the location of the Pickup directory by using the –PickupDirectoryPath parameter on the Set-TransportServicer cmdlet. Move the location of the Replay directory by using the –ReplayDirectoryPath parameter on the Set-TransportService cmdlet. With either parameter, successfully changing the directory location depends on the rights that are granted to the Network Service account on the new directory location and whether the new directory already exists. Keep the following in mind:

Changing the Pickup directory provides the syntax and usage for moving the Pickup and Replay directories. If you want to move both the Pickup and Replay directories, you should do so in two separate commands to ensure that both directories get moved as appropriate.

Syntax
Set-TransportService -Identity ServerIdentity 
 [-PickupDirectoryPath LocalFolderPath]
 [-ReplayDirectoryPath LocalFolderPath]

Usage
Set-TransportService -Identity "CorpSvr127"
 -PickupDirectoryPath "g:Pickup"

By default, Transport servers simultaneously and separately process the Pickup and Replay directories. Transport servers scan the Pickup and Replay directories for new message files once every five seconds (or 12 times per minute), and they process messages copied to either directory at a rate of 100 messages per minute, per directory. Because the polling interval is not configurable, the maximum number of messages that can be processed in either the Pickup or Replay directory during each polling interval, by default, is approximately 8 (100 messages per minute divided by 12 messages processed per minute).

Although the polling interval is not configurable, the maximum number of messages that can be processed during each polling interval is configurable. You assign the desired processing rate by using the –PickupDirectoryMaxMessagesPerMinute parameter, because this processing speed is used with both the Pickup and Replay directories.

You might want to adjust the message processing rate in these situations:

You assign the desired processing rate by using the –PickupDirectoryMaxMessagesPerMinute parameter of the Set-TransportService cmdlet, as shown in Changing the message processing speed, and this processing speed is used with both the Pickup and Replay directories. Your Transport server then attempts to process messages in each directory independently at the rate specified. You can use a per-minute message processing value between 1 and 20,000.

Syntax
Set-TransportService -Identity ServerIdentity 
 [-PickupDirectoryMaxMessagesPerMinute Speed]

Usage
Set-TransportService -Identity "CorpSvr127"
 -PickupDirectoryMaxMessagesPerMinute "500"

The Pickup directory is used by administrators to test mail flow and by applications that create and submit their own messages. If applications are generating messages with expanded headers, such as when there are many recipients in To:, Cc:, and Bcc: header fields, you may need to modify the messaging limits for the Pickup directory.

You can set messaging limits for the Pickup directory for message header sizes and maximum recipients per message. The default message header size is 64 KB, which allows for 65,536 characters in the header. To change this setting, you can set the –PickupDirectoryMaxHeaderSize parameter of the Set-TransportService cmdlet to the desired size. The valid input range for this parameter is 32,768 to 2,147,483,647 bytes. When you specify a value, you should qualify the units for that value by ending with one of the following suffixes:

The following example sets the maximum header size to 256 KB:

Set-TransportService –Identity MailServer48
–PickupDirectoryMaxHeaderSize "256KB"

The default maximum recipients per message is 100. To change this setting, you can set the –PickupDirectoryMaxRecipientsPerMessage parameter of the Set-TransportService cmdlet to the desired size. The valid input range for this parameter is 1 to 10,000. The following example sets the maximum recipients to 500:

Set-TransportService –Identity MailServer48
–PickupDirectoryMaxRecipientsPerMessage "500"

Message throttling sets limits on the number of messages and connections that can be processed by a Mailbox or an Edge Transport server. These limits are designed to prevent the accidental or intentional inundation of transport servers and help ensure that transport servers can process messages and connections in an orderly and timely manner. Throttling works in conjunction with size limits on messages that apply to header sizes, attachment sizes, and number of recipients. Although the default throttling settings work in a typical messaging environment, you may need to modify these settings as your organization grows, especially if users or applications create and send a lot of email messages.

On Mailbox and Edge Transport servers, you can set some message throttling options in the Exchange Admin Center by using the options on the Transport Limits page in the transport server’s Properties dialog box. In the Exchange Management Shell, you can configure all message throttling options by using Set-TransportService and related parameters.

With Set-SendConnector, you can configure throttling by using ConnectionInactivityTimeOut. This parameter sets the maximum idle time before an open SMTP connection is closed. The default value is 10 minutes.

With Set-ReceiveConnector, you can configure throttling by using the following parameters:

Back pressure limits overuse of system resources on a Mailbox or an Edge Transport server. Transport servers monitor key system resources to determine usage levels. If usage levels exceed a specified limit, the server stops accepting new connections and messages to prevent server resources from being completely overwhelmed and to enable the server to deliver the existing messages. When usage of system resources returns to a normal level, the server accepts new connections and messages. Resources monitored as part of the back pressure feature include:

Levels of usage are defined as normal, medium, or high. With the normal level, the resource is not overused, and the server accepts new connections and messages. With the medium level, the resource is slightly overused, and limited back pressure is applied, allowing mail from senders in the authoritative domain to continue being sent while the server rejects new connections and messages from other sources. With the high level, the resource is severely overused and full back pressure is applied, meaning message flow stops and the server rejects all new connections and messages.

You have limited control over how back pressure is applied. Some related settings can be configured in the Edgetransport.exe.config file on Edge Transport servers; however, Microsoft recommends that you don’t change the default settings.

An organization can have more than one SMTP domain, and the set of email domains your organization uses are its authoritative domains. An accepted domain is considered authoritative when the Exchange organization hosts mailboxes for recipients in this SMTP domain. Transport servers should always accept email that is addressed to any of the organization’s authoritative domains. By default, when you install the first Mailbox server, one accepted domain is configured as authoritative for the Exchange organization, and this default accepted domain is based on the FQDN of your forest root domain.

In many cases, an organization’s internal domain name might differ from its external domain name. You must create an accepted domain to match your external domain name. You must also create an email address policy that assigns your external domain name to user email addresses. For example, your internal domain name might be cpandl.local, whereas your external domain name is cpandl.com. When you configure DNS, the DNS MX records for your organization will reference cpandl.com, and you will want to assign this SMTP namespace to users by creating an email address policy.

When email is received from the Internet by a Transport server and the recipient of the message is not a part of your organization’s authoritative domains, the sending server is trying to relay messages through your Transport servers. To prevent abuse of your servers, Transport servers reject all email that is not addressed to a recipient in your organization’s authoritative domains. However, at times you might need to relay email messages from another domain, such as messages from a partner or subsidiary, in which case, you can configure accepted domains as relay domains. When your Transport servers receive the email messages for a configured relay domain, they will relay the messages to an email server in that domain.

You can configure a relay domain as an internal or an external relay domain. You configure an internal relay domain when there are contacts from the relay domain in the global address list. If your organization contains more than one forest and has configured global address list synchronization, the SMTP domain for one forest can be configured as an internal relay domain in a second forest. Messages from the Internet that are addressed to recipients in internal relay domains are received and processed by your Edge Transport servers. These messages are then relayed to your Mailbox servers, which, in turn, route the messages to the Mailbox servers in the recipient forest. Configuring an SMTP domain as an internal relay domain ensures that all email addressed to the relay domain are accepted by your Exchange organization.

You configure an external relay domain when you want to relay messages to an email server that is both outside your Exchange organization and outside the boundaries of your organization’s network perimeter. For this configuration to work, your DNS servers must have an MX record for the external relay domain that references a public IP address for the relaying Exchange organization. When your Edge Transport servers receive the messages for recipients in the external relay domain, they route the messages to the mail server for the external relay domain. You must also configure a Send connector from the Edge Transport server to the external relay domain. The external relay domain can also be using your organization’s Edge Transport server as a smart host for outgoing mail.

You also can configure accepted domains for Microsoft Exchange Online. In this case, accepted domains can either be authoritative or internal relay domains. Although you manage previously defined domains in Exchange Admin Center under Mail Flow > Accepted Domains, you must initially define domains in Office 365 Admin Center by using the Domains > Add A Domain option.

If you are working in a hybrid organization, you’ll find that the Hybrid Configuration Wizard adds an accepted domain to the on-premises organization to enable hybrid mail flow. This domain, called the coexistence domain, is added as a secondary proxy domain to any email address policies that have primary SMTP address templates for domains selected in the wizard. By default, the coexistence domain is YourDomain.mail.onmicrosoft.com.

You can view the accepted domains configured for your organization by completing the following steps:

You can use the Get-AcceptedDomain cmdlet to list accepted domains or to get information on a particular accepted domain as well. If you do not provide an identity with this cmdlet, configuration information for all accepted domains is displayed. Get-AcceptedDomain cmdlet syntax and usage provides the syntax and usage, in addition to sample output, for the Get-AcceptedDomain cmdlet.

Syntax
Get-AcceptedDomain [-Identity DomainIdentity]
[-DomainController DCName] [-Organization OrganizationId]

Usage
Get-AcceptedDomain -Identity "pocket-consultant.com"

Output
Name                      DomainName              DomainType        Default
----                      ----------              ----------        -------
pocket-consultant.com     pocket-consultant.com   Authoritative      True
Relay to Trey Research    treyresearch.net        ExternalRelay      False
Relay to The Phone Company  thephone-company.com  ExternalRelay      False

You can create accepted domains for your organization by completing the following steps:

In the Exchange Management Shell, you can use the New-AcceptedDomain cmdlet to create accepted domains. New-AcceptedDomain cmdlet syntax and usage provides the syntax and usage.

Syntax
New-AcceptedDomain -Name Name 
 -DomainName DomainName 
 -DomainType <Authoritative|InternalRelay|ExternalRelay>
[-Organization OrganizationId]

Usage;
New-AcceptedDomain -Name "Relay to Cohowinery.com"
 -DomainName "*.cohowinery.com"
 -DomainType "ExternalRelay"

You can change an accepted domain’s type and identifier by completing the following steps:

In the Exchange Management Shell, you can use the Set-AcceptedDomain cmdlet to modify accepted domains. Set-AcceptedDomain cmdlet syntax and usage provides the syntax and usage. Use the –AddressBookEnabled parameter to enable recipient filtering for this accepted domain. You should set this parameter to $true only if all the recipients in this accepted domain are replicated to the AD LDS database on the Edge Transport servers. For authoritative domains and internal relay domains, the default value is $true. For external relay domains, the default value is $false.

Syntax
Set-AcceptedDomain -Identity AcceptedDomainIdentity 
[-AddressBookEnabled <$true | $false>] [-DomainController DCName]
[-DomainType <Authoritative|InternalRelay|ExternalRelay>]
[-MakeDefault <$true | $false>] [-Name Name]
[-OutboundOnly <$true | $false>]

Usage
Set-AcceptedDomain -Identity "Relay to Cohowinery.com"
 -DomainType "ExternalRelay"

You can remove an accepted domain that’s no longer needed by completing the following steps:

In the Exchange Management Shell, you can use the Remove-AcceptedDomain cmdlet to remove accepted domains. Remove-AcceptedDomain cmdlet syntax and usage provides the syntax and usage.

Syntax
Remove-AcceptedDomain -Identity AcceptedDomainIdentity
[-DomainController DCName]

Usage
Remove-AcceptedDomain -Identity "Relay to Cohowinery.com"

You can view the email address policies configured for your organization by completing the following steps:

You can use the Get-EmailAddressPolicy cmdlet to list email address policies or to get information on a particular email address policy. If you don’t provide an identity with this cmdlet, configuration information for all email address policies is displayed. Get-EmailAddressPolicy cmdlet syntax and usage provides the syntax and usage, in addition to sample output, for the Get-EmailAddressPolicy cmdlet.

Syntax
Get-EmailAddressPolicy [-Identity PolicyIdentity]
[-DomainController DCName] [-Organization OrgId]
[-IncludeMailboxSettingOnlyPolicy <$true | $false>]

Usage
Get-EmailAddressPolicy | ft name, priority, recipientfilter,
recipientfilterapplied, includedrecipients
Get-EmailAddressPolicy -Identity "Default Policy"

Output
Name                              Priority         RecipientFilter
----                              --------         ---------------
Default Policy                    Lowest           Alias -ne $null
Rewrite Litware, Inc. Email Ad... 1                Alias -ne $null

You can create email address policies for your organization by completing the following steps:

If you tap or click More Options in the Email Address Format dialog box, you’ll be able to specify a custom SMTP email address. With custom addresses, you use the following variables to specify how the email address should be formatted in addition to manually entered text:

For example, you could enter %g.%[email protected] to specify that email addresses should be formatted with the given name first, followed by a period (.) and the surname.

In the Exchange Management Shell, you create and apply email address policies by using separate tasks. You can create email address policies by using the New-EmailAddressPolicy cmdlet. After you create a policy, apply it using the Update-EmailAddressPolicy cmdlet. New-EmailAddressPolicy cmdlet syntax and usage and Update-EmailAddressPolicy cmdlet syntax and usage provide the syntax and usage for these cmdlets. Use the -EnabledPrimarySMTPAddressTemplate parameter to specify the custom format for email addresses. Although the syntax for custom email addresses is the same as when you are working with Exchange Admin Center, you must use the SMTP: prefix before specifying the format, as shown in the example.

Syntax
New-EmailAddressPolicy -Name PolicyName
-EnabledPrimarySMTPAddressTemplate Template
-IncludedRecipients RecipientTypes {AddtlParams} {ConditionalParams}
New-EmailAddressPolicy -Name PolicyName
-EnabledEmailAddressTemplates Templates -RecipientFilter Filter
[-DisabledEmailAddressTemplates Templates] {AddtlParams}
New-EmailAddressPolicy -Name PolicyName
-EnabledPrimarySMTPAddressTemplate Template
-RecipientFilter Filter {AddtlParams}
New-EmailAddressPolicy -Name PolicyName
-EnabledEmailAddressTemplates Templates 
-IncludedRecipients RecipientTypes
[-DisabledEmailAddressTemplates Templates]
{AddtlParams} {ConditionalParams}
{AddtlParams}
[-DomainController DCName] [-Organization OrgId]
[-Priority Priority] [-RecipientContainer OUId]
{ConditionalParams}
[-ConditionalCompany CompanyNameFilter1, CompanyNameFilter2, ... ]
[-ConditionalCustomAttributeN Value1, Value2, ...]
[-ConditionalDepartment DeptNameFilter1, DeptNameFilter2, ... ]
[-ConditionalStateOrProvince StateNameFilter1, StateNameFilter2, ... ]

Usage
New-EmailAddressPolicy -Name "Primary Email Address Policy"
-IncludedRecipients "MailboxUsers, MailContacts, MailGroups"
 -ConditionalCompany "City Power & Light"
 -ConditionalDepartment "Sales","Marketing"
 -ConditionalStateOrProvince "Washington","Idaho","Oregon"
 -Priority "Lowest"
 -EnabledEmailAddressTemplates "SMTP:%g.%[email protected]"

Syntax
Update-EmailAddressPolicy -Identity PolicyIdentity 
[-DomainController DCName] [-FixMissingAlias <$true | $false>]

Usage
Update-EmailAddressPolicy -Identity "Primary Email Address Policy"
Update-EmailAddressPolicy -Identity "Primary Email Address Policy"
 -FixMissingAlias

You can manage email address policies in several different ways. You can edit their properties or apply them to rewrite email addresses automatically for each recipient to which the policy applies. You can also change their priority to determine the precedence order for application in case there are conflicts between policies. When multiple policies apply to a recipient, the policy with the highest priority is the one that applies.

You can change the way email address policies work by completing the following steps:

You can change priority in the Exchange Admin Center by selecting the policy, and then using the Increase Priority and Decrease Priority buttons to change the priority of the policy. The valid range for priorities depends on the number of policies you’ve configured. The Default Policy always has the lowest priority.

You can apply an email address policy by selecting the policy Exchange Admin Center’s main pane, and then tapping or clicking Apply in the details pane.

In the Exchange Management Shell, you can use the Set-EmailAddressPolicy cmdlet to modify email address policies, as shown in Set-EmailAddressPolicy cmdlet syntax and usage. The Update-EmailAddressPolicy cmdlet, used to apply policies, was discussed previously.

Syntax
Set-EmailAddressPolicy -Identity PolicyIdentity
[-ConditionalCompany CompanyNameFilter1, CompanyNameFilter2, ... ]
[-ConditionalCustomAttributeN Value1, Value2, ...]
[-ConditionalDepartment DeptNameFilter1, DeptNameFilter2, ... ]
[-ConditionalStateOrProvince StateNameFilter1, StateNameFilter2, .... ]
[-DisbledEmailAddressTemplates Templates] [-DomainController DCName]
[-EnabledEmailAddressTemplates Templates]
[-EnabledPrimarySMTPAddressTemplate Template]
[-ForceUpgrade <$true | $false>] [-IncludedRecipients RecipientTypes]
[-Name PolicyName] [-Priority Priority]
[-RecipientContainer OUId] [-RecipientFilter Filter]

Usage
Set-EmailAddressPolicy  -Identity "Primary Email Address Policy"
 -Name "Cpandl.com Email Address Policy"
 -IncludedRecipients "MailboxUsers"
 -ConditionalCompany "City Power & Light"
 -ConditionalDepartment "Sales"
 -ConditionalStateOrProvince "Washington"
 -Priority "2"
 -EnabledEmailAddressTemplates "SMTP:%g.%[email protected]"

You can remove an email address policy that is no longer needed by completing the following steps:

In the Exchange Management Shell, you can use the Remove-EmailAddressPolicy cmdlet to remove email address policies. Remove-EmailAddressPolicy cmdlet syntax and usage provides the syntax and usage.

Syntax
Remove-EmailAddressPolicy -Identity EmailAddressPolicyIdentity
[-DomainController DCName]

Usage
Remove-EmailAddressPolicy -Identity "Cpandl.com
Email Address Policy"

Exchange 2013 Setup creates a separate container in Active Directory Domain Services to store Exchange 2013 journal rules. If you are installing Exchange 2013 in an existing Microsoft Exchange 2010 or Exchange 2007 organization, Setup copies any existing journal rules to this container so they will be applied to Exchange 2013. If you subsequently make changes to the journal rule configuration on your Exchange 2010 or Exchange 2007 servers, you must make the same changes on Exchange 2013 to ensure the journal rules are consistent across the organization (and vice versa). You can also export journal rules from Exchange 2010 or Exchange 2007 and import them to Exchange 2013.

Both Exchange Online and on-premises Exchange support a full set of compliance options for in-place eDiscovery and hold, auditing, retention policies, retention tags, and journal rules. These compliance options are configured in much the same way whether you are working with Exchange Online or Exchange 2013. If you are working in a hybrid configuration and have specific compliance requirements, you can ensure your on-premises compliance settings are applied to Exchange Online.

In a hybrid environment, inbound and outbound messages have separate routing configurations. If you enable centralized mail transport for inbound, outbound, or both types of messages in the hybrid configuration, messages sent by or to recipients in the online organization are set through the on-premises organization to ensure that compliance rules and any other processes or messaging requirements configured in the on-premises organization are applied. However, there is a noteworthy exception: Outbound messages sent from Exchange Online to other recipients in the same Exchange Online organization are delivered directly.

When you first configure journaling, you’ll need to specify an email address to receive any journal reports that are otherwise undeliverable. Typically, you’ll want to create a new, dedicated mailbox to receive these reports so that the mailbox will not be journaled and also won’t be subject to any transport rules or mailbox rule settings.

To specify the NDR journaling mailbox, complete the following steps:

You create journal rules to record messages in your organization in support of email retention and compliance requirements. You can target journal rules for the following:

When you enable journal rules for one or more of these scopes, the rules are executed on your organization’s Mailbox servers. Journal rules can be targeted to all recipients or to specific recipients. For example, you can create a rule to journal all messages sent to the AllEmployees distribution group.

You can create a journal rule by completing the following steps:

When you are working with the Compliance Management area and select Journal Rules, the currently defined journal rules are listed in the main pane by status, name, user journaled, and journal report recipient. You can easily enable or disable a rule by setting or clearing the corresponding check box in the On column. If you select a rule and then select Edit, you can modify the rule settings. If you select a rule and then select Remove, you can delete the rule.

In the Exchange Management Shell, you can manage journal rules by using the following cmdlets: New-JournalRule, Set-JournalRule, Get-JournalRule, and Remove-JournalRule.

You can use the Get-RemoteDomain cmdlet to list remote domains or to get information on a particular remote domain. Remote domains are listed by name and the domain to which they apply. The Default remote domain applies to all remote domains, unless you override it with specific settings.

If you do not provide an identity with the Get-RemoteDomain cmdlet, configuration information for all remote domains is displayed. Get-RemoteDomain cmdlet syntax and usage provides the syntax and usage, in addition to sample output, for the Get-RemoteDomain cmdlet.

Syntax
Get-RemoteDomain [-Identity DomainIdentity]
[-DomainController DCName] [-Organization OrgId]

Usage
Get-RemoteDomain -Identity "adatum.com"

Output
Name                       DomainName              AllowedOOFType
----                       -----------             --------------
Default                    *                       External
Adatum                     *.adatum.com            External

In the Exchange Management Shell, you can use the New-RemoteDomain cmdlet to create remote domains. Use the -Name parameter to specify a descriptive name that identifies the purpose of the remote domain or simply enter the actual SMTP domain name.

New-RemoteDomain cmdlet syntax and usage provides the syntax and usage. The way you set the –DomainName parameter determines whether the remote domain includes subdomains. To manage connections for a specific domain, you simply provide the fully qualified name of the domain. You insert an asterisk and a period before the domain name to include the domain and all child domains of the domain.

Syntax
New-RemoteDomain -Name Name  -DomainName DomainName
[-DomainController DCName] [-Organization OrgId]

Usage for parent domain only
New-RemoteDomain -Name "Cohowinery Managed Connection"
 -DomainName "cohowinery.com"

Usage for parent domain and child domains
New-RemoteDomain -Name "Cohowinery Managed Connection"
 -DomainName "*.cohowinery.com"

Remote domains are used to control how automated messages are used and to specify some types of messaging format options. In the Exchange Management Shell, you can use the Set-RemoteDomain cmdlet to configure remote domains. Set-RemoteDomain cmdlet syntax and usage provides the syntax and usage.

Syntax
Set-RemoteDomain –Identity "RemoteDomainIdentity"
 [-AllowedOOFType <"External"|"InternalLegacy"|"ExternalLegacy"|"None">]
 [-AutoForwardEnabled <$true | $false>]
 [-AutoReplyEnabled <$true | $false>]
 [-CharacterSet "CharacterSet"]
 [-ContentType <"MimeHtmlText"|"MimeText"|"MimeHtml">]
 [-DeliveryReportEnabled <$true | $false>]
 [-DisplaySenderName <$true | $false>]
 [-DomainController DCName]
 [-IsInternal <$true | $false>
 [-LineWrapSize "Size"]
 [-MessageCountThreshold Count]
 [-MeetingForwardNotificationEnabled <$true | $false>]
 [-Name "Name"]
 [-NDREnabled <$true | $false>]
 [-NonMimeCharacterSet "CharacterSet"]
 [-TNEFEnabled <$true | $false>]

Usage
Set-RemoteDomain -Identity "Cohowinery"
 -DeliveryReportEnabled $false

Use the -AllowedOOFType parameter to specify whether and how out-of-office messages are sent to the remote domain. The options are as follows:

You also can specify how Exchange should format messages. Allow messaging options by setting the related parameters to $true, or disallow messaging options by setting the related parameters to $false. The options available are as follows:

By default, text word-wrapping is disabled, which means that Exchange does not enforce a maximum line length. If you’d like message text to wrap at a specific line length, you can set the -LineWrapSize parameter to the specific column position at which text wrapping should start, such as at 72 characters.

Use the -ContentType parameter to set the outbound message content type and formatting. The options are as follows:

If you want to send Transport Neutral Encapsulation Format (TNEF) message data to the remote domain rather than Exchange Rich Text Format, set -TNEFEnabled to $true. TNEF is a Microsoft format for encapsulating MAPI message properties. Though this format is used by Outlook, it may not be recognized by other email clients. When you enable TNEF for remote domains, all messages sent to that domain are normally converted to TNEF format, except when overridden by Outlook client or mailbox user settings.

In the Exchange Management Shell, you can use the Remove-RemoteDomain cmdlet to remove remote domains. Remove-RemoteDomain cmdlet syntax and usage provides the syntax and usage.

Syntax
Remove-RemoteDomain -Identity RemoteDomainIdentity
[-DomainController DCName]

Usage
Remove-RemoteDomain -Identity "Cohowinery"

Sometimes, when you are filtering spam or other unwanted email, you’ll know specific email addresses or email domains from which you don’t want to accept messages. In this case, you can block messages from these senders or email domains by configuring sender filtering. Another sender from which you probably don’t want to accept messages is a blank sender. If the sender is blank, it means the From field of the email message wasn’t filled in and the message is probably from a spammer.

Sender filtering is enabled by default and is designed to filter inbound messages from non-authenticated Internet sources. You can view the current configuration of sender filtering by using Get-SenderFilterConfig. Use the -Enabled parameter of Set-SenderFilterConfig to enable or disable sender filtering. The following example disables sender filtering:

Set-SenderFilterConfig -Enabled $false

To configure filtering according to the sender of a message on a legacy Edge Transport server running Exchange 2010, follow these steps:

In the Exchange Management Shell, you can use the Set-SenderFilterConfig cmdlet to configure sender filtering. Set-SenderFilterConfig cmdlet syntax and usage provides the syntax and usage. By default, sender filtering rejects messages from blocked domains and senders. If you set the -Action parameter to StampStatus instead, a message header stamp will be added to the message and the message will be processed by other anti-spam agents. This stamp and any other issues found will then be used to set the spam confidence level as part of content filtering. A message that exceeds a spam confidence level is rejected, quarantined, deleted, or marked as junk mail. Set the -BlankSenderBlockingEnabled parameter to $true to block blank senders.

Syntax
Set-SenderFilterConfig [-Action <StampStatus | Reject>]
[-BlankSenderBlockingEnabled <$true | $false>]
[-BlockedDomains <domain1,domain2...domainN>]
[-BlockedDomainsAndSubdomains <domain1,domain2...domainN>]
[-BlockedSenders <email1,email2...emailN>]
[-DomainController DCName]
[-Enabled <$true | $false>]
[-ExternalMailEnabled <$true | $false>]
[-InternalMailEnabled <$true | $false>]
[-RecipientBlockedSenderAction <Reject | Delete>]

Usage
Set-SenderFilterConfig -BlankSenderBlockingEnabled $true
Set-SenderFilterConfig -BlockedDomains contoso.com, margiestravel.com,
proseware.com
Set-SenderFilterConfig -BlockedDomainsAndSubdomains fineartschool.com,
wingtiptoys.com
Set-SenderFilterConfig -BlockedSenders [email protected],
[email protected]

As shown in the examples, you can easily define the initial set of blocked domains and senders. If you want to modify these values, however, you must either enter the complete set of blocked domains or senders, or you must use a special shorthand to insert into or remove values from these multivalued properties. The shorthand for adding values is:

@{Add="<ValuetoAdd1>","<ValuetoAdd2>"...}

Such as:

Set-SenderFilterConfig -BlockedDomains @{Add="adatum.com","fabrikam.com"}

The shorthand for removing values is:

@{Remove="<ValuetoRemove1>","<ValuetoRemove2>"...}

Such as:

Set-SenderFilterConfig -BlockedDomains
@{Remove="adatum.com","fabrikam.com"}

If you want to add values and remove others, you can do this as well by using the following shorthand:

@{Add="<ValuetoAdd1>","<ValuetoAdd2>"...;
Remove="<ValuetoRemove1>","<ValuetoRemove1>"...}

You can confirm that values were added or removed as expected by using Get-SenderFilterConfig. In this example, you view the currently blocked domains:

Get-SenderFilterConfig | fl BlockedDomains

By default, -InternalMailEnabled is set to $false and -ExternalMailEnabled is set to true, which means authenticated internal email messages aren’t processed by the Sender Filter whereas unauthenticated external email messages are processed by the Sender filter. An unauthenticated external email messages is one from an untrusted or anonymous source rather than a trusted partner.

Finally, when users in your organization add senders to their blocked sender list, the SafeList aggregation feature in Exchange 2013 adds these senders to the Blocked Senders List in Exchange 2013. By default, messages from these users are rejected rather than deleted. To delete these messages, set -RecipientBlockedSenderAction to Delete.

In any organization, you’ll have users whose email addresses change, perhaps because they request it, leave the company, or change office locations. Although you might be able to forward email to these users for a time, you probably won’t want to forward email indefinitely. At some point, you, or someone else in the organization, will decide it’s time to delete the user’s account, mailbox, or both. If the user is subscribed to mailing lists or other services that deliver automated email, the automated messages continue to come in, unless you manually unsubscribe the user or reply to each email that you don’t want to receive the messages. Unfortunately, some Exchange administrators find themselves going through this inefficient process. It’s much easier to add the old or invalid email address to a recipient filter list and specify that Exchange shouldn’t accept messages for users who aren’t in the Exchange directory. After you do this, Exchange won’t attempt to deliver messages for filtered or invalid recipients, and you won’t see related nondelivery reports (NDRs).

Recipient filtering is enabled by default. To configure filtering according to the message recipient on a legacy Edge Transport server running Exchange 2010, follow these steps:

In the Exchange Management Shell, you can use the Set-RecipientFilterConfig cmdlet to configure recipient filtering. Set-RecipientFilterConfig cmdlet syntax and usage provides the syntax and usage. By default, recipient filtering rejects messages from blocked recipients but doesn’t block users from sending messages to blocked recipients. If you set -BlockListEnabled to $true, users won’t be able to send messages to blocked recipients. You also can specify whether Exchange 2013 validates recipients and then blocks messages sent to recipients who don’t exist. Although it doesn’t validate recipients by default, you can have it validate recipients by setting -RecipientValidationEnabled to $true.

Syntax
Set-RecipientFilterConfig [-BlockedRecipients <email1,email2...emailN>]
[-BlockListEnabled <$true | $false>] [-DomainController DCName]
[-Enabled <$true | $false>] [-ExternalMailEnabled <$true | $false>]
[-InternalMailEnabled <$true | $false>]
[-RecipientValidationEnabled <$true | $false>]

Usage
Set-RecipientFilterConfig -RecipientValidationEnabled $true
Set-RecipientFilterConfig -BlockedRecipients [email protected],
[email protected]

If you want to modify the blocked recipients, you must either enter the complete set of blocked recipients, or you use a special shorthand to insert into or remove values from this multivalued property. The shorthand for adding values is:

@{Add="<ValuetoAdd1>","<ValuetoAdd2>"...}

Such as:

Set-RecipientFilterConfig –BlockedRecipients
@{Add="[email protected]","[email protected]"}

The shorthand for removing values is:

@{Remove="<ValuetoRemove1>","<ValuetoRemove2>"...}

Such as:

Set-RecipientFilterConfig -BlockedRecipients
@{Remove="[email protected]","[email protected]"}

If you want to add values and remove others, you can do this as well by using the following shorthand:

@{Add="<ValuetoAdd1>","<ValuetoAdd2>"...;
Remove="<ValuetoRemove1>","<ValuetoRemove1>"...}

You can confirm that values were added or removed as expected by using Get-RecipientFilterConfig. In this example, you view the currently blocked domains:

Get-RecipientFilterConfig | fl BlockedRecipients

If you find that sender and recipient filtering isn’t enough to stem the flow of spam into your organization, you might want to consider subscribing to an IP block list service. Here’s how this service works:

The sections that follow discuss applying IP block lists, setting provider priority, defining custom error messages to return, and configuring block list exceptions. These tasks will need to be performed when you work with IP block lists.

Add-IPBlockListProvider -Name Proseware -LookupDomain proseware.com
-AnyMatch $true

Add-IPBlockListProvider -Name Proseware -LookupDomain proseware.com
-BitmaskMatch 0.0.0.4

Add-IPBlockListProvider -Name Proseware -LookupDomain proseware.com
-IPAddressesMatch 127.0.0.4, 127.0.0.5, 127.0.0.6, 127.0.0.7

Add-IPBlockListProvider -LookupDomain Proseware.com -Priority 2

Sometimes, you’ll find that an IP address, a network, or an email address shows up incorrectly on a block list. The easiest way to correct this problem is to create a block list exception that indicates that the specific IP address, network, or email address shouldn’t be filtered.

Set-IPBlockListProvidersConfig -BypassedRecipients [email protected],
[email protected]

@{Add="<ValuetoAdd1>","<ValuetoAdd2>"...}
@{Remove="<ValuetoRemove1>","<ValuetoRemove2>"...}
@{Add="<ValuetoAdd1>","<ValuetoAdd2>"...;
Remove="<ValuetoRemove1>","<ValuetoRemove1>"...}

Set-IPBlockListProvidersConfig -BypassedRecipients
@{Add="[email protected]","[email protected]";
Remove="[email protected]"}

Syntax
Add-IPAllowListEntry -IPAddress IPAddress {AddtlParams}
Add-IPAllowListEntry -IPRange IPRange {AddtlParams}
{AddtlParams}
[-Comment Comment] [-ExpirationTime DateTime] [-Server ServerId]

Usage
Add-IPAllowListEntry –IPAddress 192.168.10.45
Add-IPAllowListEntry –IPRange 192.168.10.0/24
Add-IPAllowListEntry –IPRange 192.168.10.1-192.168.10.254

Syntax
Get-IPAllowListEntry [-Identity IPListEntryId] {AddtlParams}
Get-IPAllowListEntry -IPAddress IPAddress {AddtlParams}
{AddtlParams}
[-ResultSize Size] [-Server ServerId]

Usage
Get-IPAllowListEntry
Get-IPAllowListEntry –IPAddress 192.168.10.45

Syntax
Remove-IPAllowListEntry -Identity IPListEntryId
[-Server ServerId]

Usage
Get-IPAllowListEntry | Where {$_.IPRange -eq '192.168.10.45'} |
Remove-IPAllowListEntry
Get-IPAllowListEntry | Where {$_.IPRange -eq '192.168.10.0/24'} |
Remove-IPAllowListEntry

Syntax
Add-IPBlockListEntry -IPAddress IPAddress {AddtlParams}
Add-IPBlockListEntry -IPRange IPRange {AddtlParams}
{AddtlParams}
[-Comment Comment] [-ExpirationTime DateTime] [-Server ServerId]

Usage
Add-IPBlockListEntry –IPAddress 192.168.10.45
Add-IPBlockListEntry –IPRange 192.168.10.0/24
Add-IPBlockListEntry –IPRange 192.168.10.1-192.168.10.254

Syntax
Get-IPBlockListEntry [-Identity IPListEntryId] {AddtlParams}
Get-IPBlockListEntry -IPAddress IPAddress {AddtlParams}
{AddtlParams}
[-ResultSize Size] [-Server ServerId]

Usage
Get-IPBlockListEntry
Get-IPBlockListEntry –IPAddress 192.168.10.45

Syntax
Remove-IPBlockListEntry -Identity IPListEntryId
[-Server ServerId]

Usage
Get-IPBlockListEntry | Where {$_.IPRange -eq '192.168.10.45'} |
Remove-IPBlockListEntry
Get-IPBlockListEntry | Where {$_.IPRange -eq '192.168.10.0/24'} |
Remove-IPBlockListEntry

Typically, you don’t want Exchange to apply Sender ID, content, or connection filters to servers on your organization’s network or to internal SMTP servers deployed in a perimeter zone. One way to ensure a filter is not applied is to configure message delivery options for your organization’s transport servers so that they don’t apply filters to IP addresses from internal servers and your perimeter network.

In Exchange Management Shell, you prevent internal servers from being filtered by the Sender ID, content or connection filters by using the -InternalMailEnabled parameter of Set-SenderIdConfig, Set-ContentFilterConfig, and Set-IPBlockListProvider. By default, -InternalMailEnabled is set to $false for Set-SenderIdConfig and Set-ContentFilterConfig, which means authenticated internal email messages aren’t processed by the Send ID filter or the content filter.

Transport rules have conditions, actions, and exceptions that you can apply. Conditions you can screen for include the following:

When a message meets all of the conditions you specify in a transport rule, the message is handled according to the actions you’ve defined. Actions you can apply to messages that meet your transport rule conditions include the following:

Transport rules can also have exceptions. Exception criteria are similar to condition criteria. For example, you can exclude messages from certain people or from certain members of distribution lists. You can also exclude messages sent to certain people or to particular members of a distribution list.

You can create a transport rule by completing the following steps:

You can manage transport rules in several different ways including editing their properties or disabling them. When you’ve created multiple rules, you can also change their priority to determine the precedence order for application in case there are conflicts between rules. When multiple rules apply to a message, the rule with the highest priority is the one that your Mailbox server applies.

When you select a transport rule in Exchange Admin Center, you can manage the rule in the following ways:

In the Exchange Management Shell, you can manage transport rules by using the following cmdlets: New-TransportRule, Set-TransportRule, Get-TransportRule, and Remove-TransportRule.