Applies to: Exchange Server 2016
Topic Last Modified: 2016-03-02
Learn how Sender ID in Exchange 2016 evaluates inbound email messages to detect spoofed senders.
Sender ID is used to detect spoofing. A spoofed email message is modified to appear as if it originates from a sender other than the actual sender of the message. In the past, it was relatively easy to send spoofed email messages, because the sender's email address in the message header wasn't validated. Sender ID uses the RECEIVED SMTP header and a query to the DNS records for the sender's domain to determine if the sender's email address is spoofed. Sender ID in Exchange Server 2016 is provided by the Sender ID agent, and is basically unchanged from Exchange Server 2010.
By default, the Sender ID agent is enabled on Edge Transport servers, but you can enable it on Mailbox servers. For more information, see Enable antispam functionality on Mailbox servers.
For more information about how to configure the Sender ID agent, see Sender ID procedures.
When the Exchange server receives an inbound message, the Sender ID agent verifies the sender's IP address by querying the DNS records for the sender's domain. This check confirms that the message was received from an authorized IP address for the sender's domain. The IP address of the authorized sending server is referred to as the purported responsible address (PRA).
Administrators publish sender policy framework (SPF) records in DNS that identify the authorized outbound messaging servers for the domain. If an SPF record is available in DNS for the sender's domain, the Sender ID agent parses the SPF record to determine if the source IP address is authorized to send email for the domain that's specified in the sender's email address. For more information about what an SPF record contains and how to create an SPF record, see Sender Policy Framework: SPF Record Syntax.
The Sender ID agent generates a Sender ID status for the message. The Sender ID status can be set to one of the following values:
Pass Both the IP address and the PRA passed the Sender ID verification check.
Neutral The published Sender ID data is explicitly inconclusive.
Soft fail The IP address for the PRA might be in the not permitted set.
Fail The IP Address is not permitted. No PRA is found in the incoming mail, or the sender's domain doesn't exist.
None No published SPF data exists in DNS for the sender's domain.
TempError A temporary DNS failure occurred, such as an unavailable DNS server.
PermError The DNS record is invalid, such as an error in the record format.
Note: If the source IP address is missing, the Sender ID status can't be set. Exchange continues to process the message without including a Sender ID status, and the message isn't returned or rejected. In this scenario, the Sender ID status isn't set, and an application event is logged.
The Sender ID status is added to the message metadata, and is later converted to a MAPI property. The junk email filter in Outlook uses this MAPI property during the calculation of the spam confidence level (SCL).
Outlook neither displays the Sender ID status, nor flags a message as junk based solely on the Sender ID value. Instead, Outlook uses the Sender ID status value only during the calculation of the SCL for the message.
For more information about how the Sender ID status is displayed in messages, see Antispam stamps.
You can configure the actions to take when the Sender ID agent identifies messages that contain spoofed senders (the Sender ID status is
Fail), and when a DNS server can't be reached (the Sender ID status is
Stamp status The Sender ID agent stamps the Sender ID status in the metadata of the message, and allows the delivery of the message to continue. This is the default option.
Reject The Sender ID agent rejects the message with a 5xx level SMTP error response, which includes text that corresponds to the Sender ID status.
Delete The Sender ID agent silently deletes the message without an SMTP error response. The Exchange server sends a fake OK SMTP command to the source server, and then deletes the message. Because the source server assumes the message was sent, it doesn't try to resend the message in the same session.
For more information about how to configure the action to take for spoofed mail and unreachable DNS servers, see Sender ID procedures.
The effectiveness of Sender ID depends on specific DNS data. The more organizations that configure SPF records for their domains, the more effectively Sender ID is able to identify spoofed messages.
To support the Sender ID infrastructure, you need to create SPF records for the domains that your organization sends messages from. For more information about how to create and deploy SPF records, see Sender Policy Framework: SPF Record Syntax.