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 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.
Using Sender ID to combat spoofing
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.
Sender ID status values
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.
Sender ID options for handling spoofed mail and unreachable DNS servers
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 5 xx 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.
Updating your organization's Internet facing DNS to support Sender ID
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.
Specifying recipients and sender domains to exclude from Sender ID filtering
You can exclude specific recipients and sender domains from Sender ID filtering by using the Set-SenderIdConfig cmdlet in the Exchange Management Shell. For more information, see Sender ID procedures.
We'd love to hear your thoughts. Choose the type you'd like to provide:
Our feedback system is built on GitHub Issues. Read more on our blog.