How to enable Sender ID filtering for Exchange 2013 or 2016 mailbox servers to prevent email spoofing

search cancel

How to enable Sender ID filtering for Exchange 2013 or 2016 mailbox servers to prevent email spoofing

book

Article ID: 178825

calendar_today

Updated On:

Products

Mail Security for Microsoft Exchange

Issue/Introduction

This article is intended for Exchange Administrators that have not deployed a perimeter or gateway solution (such as a Symantec Messaging Gateway) that contains anti-spoofing technology. The discussion topics in this article will cover the basic installation and setup of Sender ID Agent on Exchange 2013 and Exchange 2016 mailbox servers. This document will not cover the setup, configuration, or utilization of any other Exchange antispam agents.

This guide is provided “As is”. No troubleshooting or walk-through assistance will be provided by Symantec Technical Support on these steps. Any detailed documentation or assistance with Microsoft or other third-party technologies discussed in this article should be referred to the vendor of the technology in question.

Resolution

What is sender spoofing?

Email spoofing is a method utilized by spammers and other malicious individuals attempting social engineering methods to increase the odds of messages being viewed by end-users. Common spoofing methods include sending email to individuals with both the sender & recipient displaying the same value, for example: Sender [email protected] Recipient [email protected]. Another common type of spoofing is to masquerade as a legitimate organization such as a financial institution.

SMTP is an older protocol that lacks any sort of sender verification by default, which allows a sender to tag any address they would like in the Mail from: or From: fields of the message with no way for the recipient to verify the sender is legitimate by default.

What methods can we use to combat sender spoofing?

Sender Policy Framework (SPF) is a method available tailored to combat email spoofing. SPF uses the following method to verify the envelope sender (RFC 5321) of a message matches against the IP of the sending server:

Email is sent and reaches the recipients mail server.
The Recipients mail server performs a DNS lookup for a .TXT record attempting to identify an SPF record for the Senders mail domain.
If no record is available, no action is taken. The message is delivered normally.
If a record is available the emails connecting IP will be matched against the SPF record to determine if the IP is an expected sender of emails from the sender mail domain.
If the IP matches the message will be delivered.
If the IP fails the specified action in the recipients SPF record can be taken against the message.

Note: SPF actions are dictated by the sender domain specified during the SMTP conversation. The recipient may or may not have a solution that can perform lookups and take the actions designated by the sender domain’s SPF record; which means that even if an SPF record is published, not all recipients will take action against messages that spoof a domain with a published SPF record. If the SPF record is set to anything other than than –all (Fail) state then no action will be taken against the message

For more information about Sender Policy Framework and how it can be utilized see: http://www.openspf.org/

Microsoft Exchange provides a method to implement SPF record lookups called Sender ID using the Sender ID Transport Agent, which is not installed by default on mailbox servers. Sender ID is capable of performing lookups and taking action against spoofed messages similar to SPF with a key difference. Sender ID as implemented in Exchange performs the record check against the body FROM instead of envelope FROM. The body FROM is the value displayed in the From: field within email clients. If no body TO or FROM are specified by the sender, envelope TO & FROM will be utilized instead.

Creating an SPF record:

The initial setup of Sender Policy Framework or Sender ID filtering requires the creation of a text (TXT) record. The record must include all senders that are allowed to send email on behalf of your mail domain in order to both prevent a sender from spoofing your mail domain, and allow messages to be delivered to recipient domains that are performing SPF lookups.

Example: An organization has an internal Exchange server with a public (routable) IP address of xx.xx.xx.xx. The same organization has an off-site company managing servers at a remote location which is authorized to send emails masquerading as its mail domain. That organization would need to investigate with that vendor to determine if there are specific IP address(es) or a specific SPF DNS record that needs to be included to prevent messages from being rejected due to SPF failure. For the sake of this example the record in question is spf.example.com. The SPF record would look like the following:

"v=spf1 a mx include:spf.example.com ip4:xx.xx.xx.xx -all"

This record is typically published publicly so all recipients of email containing a FROM: address utilizing the sending mail domain can perform DNS lookups against this SPF record. However, this is not actually a requirement. An SPF record can be published to an internal DNS server that is only accessible to local mail servers. This method allows testing of the configured SPF record for accuracy prior to publishing the SPF record publicly. To test using this method, send an SMTP mail to your “email domain” from your “email domain” to confirm the SPF record is behaving as expected.

The following are examples of simple and complex SPF (TXT) records:

Simple:

"v=spf1 a mx ip4:xx.xx.xx.xx -all"

Complex:

v=spf1 include:spf.example.com ip4:xx.xx.xx.xx include:spf.messagelabs.com include:spf-ilg.example.com include:spf-mtv.example.com ip4:yy.yy.yy.yy ipzz.zz.zz.zz ipvv.vv.vv.vv include:spf.example2.com include:_spf.example3.com ~all

Note: A detailed explanation of SPF record creation can be reviewed at the following link: http://www.openspf.org/SPF_Record_Syntax

Installing Sender ID agent within Exchange 2013 or 2016:

Microsoft has created a Technet article detailing the steps required to enable the entire suite of Exchange antispam agents on an Exchange Mailbox server. For this article we are only discussing the enabling and usage of Sender ID. The instructions outlined below will be specific to Sender ID and will include instructions to disable all other antispam agents.

Enable antispam functionality on Mailbox servers:

https://technet.microsoft.com/en-us/library/bb201691%28v=exchg.160%29.aspx

Installation and configuration of the Exchange antispam agents can be completed by running the following commands utilizing the Exchange Management Shell:

1. Launch the Exchange Management shell by right clicking and selecting “Run as administrator” to ensure the shell has full permissions to run the script.

2. In the Exchange management shell, run the following command:

& $env:ExchangeInstallPath\Scripts\Install-AntiSpamAgents.ps1

Performing the above command will install the following Transport Agents in an enabled state:

Sender ID Agent
Content Filter Agent
Sender Filter Agent
Recipient Filter Agent
Protocol Analysis Agent

3. Disable the Agents that are not within the scope of this article. To disable the agents, run the following commands in the Exchange management shell:

Disable-TransportAgent –Identity “Content Filter Agent”

Disable-TransportAgent –Identity “Sender Filter Agent”

Disable-TransportAgent –Identity “Recipient Filter Agent”

Disable-TransportAgent –Identity “Protocol Analysis Agent”

4. To confirm the agents have been disabled run the command Get-TransportAgent. Ensure the agents listed in step 3 all have the value “False” listed in the “Enabled” column.

Enabling and Configuring Sender ID within Exchange 2013 or 2016:

After installing the Antispam Agents the default configuration of the Sender ID for both SpoofedDomainAction and TempErrorAction is “Stampstatus”. This default action does not take any action against spoofed messages except to stamp the headers of the message. To block spoofed messages the SpoofedDomainAction should be set to Reject. Symantec does not recommend modifying the TempErrorAction to Reject as this setting will cause Sender ID to fail closed (It will drop all emails as a spoofed message if for some reason it cannot complete the Sender ID check).

To set SpoofedDomainAction to Enabled run the following command in the Exchange Management Shell:

Set-SenderIDConfig -SpoofedDomainAction Reject

To confirm the configuration run the following command in the Exchange Management Shell to identify if the SpoofDomainAction is now set to Reject:

Get-SenderIDConfig | Format-List *Enabled*,*Action,Bypassed*

Note: There are additional options that allow for configuration of exclusions for Recipients and Sender Domains. The scope of the article does not include configuring these options. For information on these options please see the following Microsoft article:

https://technet.microsoft.com/en-us/library/aa997136%28v=exchg.150%29.aspx

Now that the Sender ID Agent is installed, enabled, and configured the Microsoft Exchange Transport service must be restarted for the Sender ID Agent to become active. To restart the Microsoft Exchange Transport service, run the following command inside the Exchange Management Shell:

Restart-Service –name MSExchangeTransport

Final testing to confirm successful deployment:

1. Confirm DNS records using NSlookup tool:

Within the same Exchange Management Shell window (Or cmd.exe) perform the following actions:

Type: nslookup <enter/return>
Type: set q=txt <enter/return>
Type: YourMailDomain.com (Symantec.com)

The results should be similar to the following:

exchange2013.local text =

"v=spf1 a mx ipxx.xx.xx.xx -all"

>

2. Simple Testing Procedure using Telnet:

The following process is designed to send an email utilizing telnet. This allows for easy manipulation of the sender / recipient addresses. This test can typically be performed from a workstation assuming the network allows connectivity to the Exchange server on port SMTP port 25. This test can be performed in the Exchange Management Shell or in a Command prompt (cmd.exe) on a workstation or a different server in the environment.

Type: Telnet <enter/return>
Type: Open <enter/return>
Type: <Ip of Server> 25 (Example: 192.168.10.10 25) <enter/return>
Type: mail from: [email protected] <enter/return>
Type: rcpt to: [email protected] <enter/return>
Type: data <enter/return>
Type: subject: This is a test <enter/return> <enter/return>
Type: Test body <enter/return>
Type: . (period on its own line) <enter/return>

If this test is performed from an IP address that is not allowed in the configured SPF record this message will be returned from the Exchange server: 550 5.7.1 Sender ID <PRA> Not Permitted.

Example Session: