2. Creating a Sender Policy Framework Record
This section walks you through setting up an SPF record using the Microsoft Sender ID Framework SPF Record Wizard located at http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/.
On
the Microsoft Sender ID Framework SPF Record Wizard web page, first
enter the domain for which you want to create a record (for example, companyabc.com) in Step 1 of 4:
Identify Your Domain field on the website, and click Next. The website
checks DNS information about the domain to see what records, including
SPF, exist. If no records exist, you are taken to the next step, Step 2 of 4:
Display Published DNS Records. Review the information provided to
ensure its accuracy, and click Next when you are ready to proceed to Step 3: Create SPF Record.
In Step 3 of 4:
Create SPF Record of the Microsoft Sender ID Framework SPF Record
Wizard, seven sections can be configured to support the organization’s
email structure. On this page, you can create an SPF record to reflect
the following:
That the domain does not send email.
That inbound email servers also send email for the domain.
That outbound email servers are different from the domain’s inbound email servers.
That all reverse DNS records (PTR) resolve to the domain’s outbound email servers.
That a domain’s outbound email is routed through another domain (outsourced).
That the domain will send email from an IP address not listed in the SPF record being created.
That
the SPF record can be used to validate either the Purported Responsible
Address (PRA) derived from the message headers, or from the MAIL FROM
(or reverse-path) address derived from the SMTP protocol’s MAIL
command, or both. The PRA is the [nonforged] IP address of the system
responsible for sending the email message and the MAIL FROM tag (often
forged) designates the email address the message is being delivered as.
For this example, you will create an SPF record in which companyabc.com’s
SMTP server is running the Edge Transport server role and handles both
incoming and outgoing email. No other domains or IP addresses should be
allowed to route email for companyabc.com.
In
the form, specify that the domain’s inbound email servers can send
email by selecting the check box of the same name in the Inbound Mail
Servers Send Outbound Mail section of the form. Next, specify that the
IP address of the outbound email server for companyabc.com is
192.168.2.150 by adding that IP address to the Outbound Mail Server
Addresses field in the form. Accept the default of Discouraged to the
question regarding whether legitimate email can or will originate from
an IP address not included in this record, and allow the record to be
used to validate both the Purported Responsible IP address (PRA) and
MAIL FROM address in the message headers. Now that the information has
been entered, you can proceed to Step 4 of 4: Generate SPF Record, where the record can be created so it can be reviewed and saved for later use.
The record example for companyabc.com looks like this:
v=spf1 mx ip4:192.168.1.150 –all <or> ~all
The v=spf1 designates that this is an SPF record and it is version 1. The portion mx IP4:192.168.2.150 signifies the email server at 192.168.2.150 is authorized to send and receive email for company abc.com. The -all closes the record by stating that no one besides the IP addresses in companyabc.com’s MX records are authorized to send email using a companyabc.com
and can be rejected. From here, you can copy the syntax, paste it into
a Notepad or WordPad document, save the file in standard ASCII text
(TXT) format, and add it to DNS so other organizations using Edge
Transport servers or an implementation of SPF can look up companyabc.com’s SPF record.
Note
The
SPF record must be published in DNS as a text file to be properly
recognized. Beyond formatting of input on the form, the Sender ID
Framework SPF Record Wizard does not test or validate the settings
entered. After the wizard has finished creating your SPF record, take a
moment to view it for accuracy before exporting it for use on the DNS
servers.
More
information about SPF—extensive SPF record creation, supporting
different SPF configurations, multiple domains, and advanced syntax
use—is beyond the scope of this text. More information can be obtained
at the Microsoft website (http://www.microsoft.com/mscorp/safety/technologies/senderid/resources.mspx) or Sender Policy Framework (http://www.openspf.org).
So
far, we’ve covered how SenderID works, how to create and manage simple
SPF records, and considered the impact SenderID can have on legitimate
email. At this point, the SenderID Agent on the Edge Transport
server(s) can be configured.
3. Configuring the SenderID Agent on the Exchange Edge Transport Server
The
SenderID Agent is enabled by default on Exchange 2007 Edge Transport
servers. Configuration is quick and straightforward because SenderID
only relies on a couple of items to function properly. SenderID like
other spam-filtering technologies can impact legitimate email but, as
discussed earlier, there are ways to mitigate this impact while still
identifying messages that don’t have an SPF record.
To begin configuring SenderID, do the following:
1. | Launch
the Exchange Management Console by doing the following on the Exchange
server. Click Start, Programs, Microsoft Exchange Server 2007.
|
2. | Choose Exchange Management Console.
|
3. | Double-click the SenderID Agent in the action pane.
|
4. | |
From
here, you can change the action taken on messages if the SenderID check
fails. There are different actions to choose from. One action is to
Stamp Message with Sender ID Result and Continue Processing. This is
the default action and appends certain information to the message
headers for further processing by the Content Filtering Agent. The
Content Filtering Agent then takes this information into account when
tabulating the overall spam score assigned to the message, also known
as the Spam Confidence Level (SCL).
Tip
When
you first implement SenderID filtering, it is a recommended to “stamp”
messages to assist in filtering out false positives and generate a
white list of legitimate senders and domains. After the organization is
comfortable with the established white list, messages can be rejected.
Another
option is to use the “exp” modifier in your SPF record and include a
uniform resource locator (URL) to an Internet web page where others can
retrieve information about your email policy, SPF records, and contact
information. This helps offset false positives when rejecting email
messages that fail to comply with SPF.
The actions available if a SenderID check fails include the following:
Reject the message.
Delete the message.
Choosing
to reject the message sends an error response to the sending server.
The text contained in this error message corresponds to the Sender ID
status derived from processing the SPF record of the message.
Choosing
to delete the message sends a fake OK SMTP command to the sending
server. The message is deleted and the sender is not notified.
Accepting
the default action of Stamp Message with Sender ID Result and Continue
Processing appends the Sender ID status derived from the SPF record
lookup into the message headers for further processing by the
Content/IMF filter. This information, often called metadata, is used by
the Content/IMF filter to create the SCL.
4. Using the Exchange Management Shell to Configure SenderID
One
limitation of SenderID is the inability to exclude recipients and
domains from SenderID filtering through the Exchange Management
Console. Exclusion of recipients and domains from SenderID filtering
can only be accomplished using the Exchange Management Shell’s Set-SenderIdConfig
command. The following example enables the SenderID Agent on external
SMTP connections, bypasses checking one external domain, and sets the
action on spoofed messages.
Set-SenderIdConfig -BypassedSenderDomains Microsoft.com -Enabled $true
-ExternalMailEnabled $true -SpoofedDomainAction Delete
The Get- command is used to retrieve the configuration of the Sender Filtering Agent. For example, entering Get-SenderIDConfig displays the Sender Filtering configuration on the local system.
You can test the configuration of SenderID using the Test-SenderID Exchange shell command. The following example tests to see if the SPF record resolves correctly.
Test-SenderId -IPAddress 192.168.1.150 -PurportedResponsibleDomain mail.companyabc.com
