Executive Summary:
Spam and phishing are not only an annoyance but also a security risk. Sender Policy Framework (SPF) records can protect against forged emails and reduce the number of spam messages. Besides enabling SPF record checking in your mail-server or spam-filtering software, you should place an SPF record in your own Windows Domain Name System (DNS) entries. An SPF record is a DNS TXT record that a mail server or spam filter will access to verify the source of email messages as they arrive. Here's how you can add a TXT record in Windows DNS. |
Everybody knows that unsolicited
email advertising, commonly
referred to as spam, and
its even more evil descendant,
phishing, can be both an annoyance
and a security risk to an
organization. Everyday phishers
send emails purporting to be
from organizations you do business
with, attempting to convince
the recipient to provide
sensitive information, typically
of a financial nature.
Sender Policy Framework
(SPF) records are designed to
protect against forged emails
and reduce the number of
incoming spam messages a
mail system (and sometimes
users) have to process. Many
times spammers or phishers
send email with a forged
From address, hoping that the
domain name they forge will
catch a victim’s attention or at
least be allowed through spam
filters. An SPF record is a DNS
TXT record that a mail server or
spam filter will access to verify
the source of email messages as
they arrive. Many email services
began checking SPF records as
early as 2004.
Enabling SPF record checking
in your mail server software
or spam filtering software
varies by vendor. Many Open
Source email platforms support
SPF record checking natively,
and plugins (both free and
commercial) are available for
Microsoft Exchange platforms.
You should, however, do more
than just implement SPF record
checking—you should place an
SPF record in your own DNS
entries to help fight spam and
reduce the chance that a phishing
attack utilizing your domain
name is successful. Larger organizations
might host their own
external DNS servers, while others rely on their Web-hosting or
domain-registration company’s
DNS servers.
To add a TXT record in Windows
DNS, select Administrative
Tools under the Start menu,
then choose DNS. From there,
navigate to Forward Lookup
Zones, then to the domain to
which you want to add a TXT
record. Right-click an empty
space and select Other New
Records. From there, choose
Text (TXT). You can name the
TXT record anything you want.
Strings of code need to be
entered into the Text field. For
most organizations, the following
TXT record value is acceptable
to implement SPF:
“v=spf1 a mx –all”
This string essentially states that
if the mail is received from an
IP address that’s listed in the
sending domain’s A or mail
exchanger (MX) records, the
mail is legitimate and should
be processed. If specific IPs
send email that isn’t part of the
A or MX records, they can be
included using the ip4: mechanism,
as the following shows:
“v=spf1 a mx ip4:1.1.1.1 –all”
In this example, the IP address
of the additional mail server is
1.1.1.1.
Prior to implementing
SPF, you must make sure that
you’ve identified each IP that
mail originates from and each
domain name used by your
organization. For domains that
mail should never be sent from,
the following SPF record can be
used:
“v=spf1 –all”
This SPF record states that the
domain has no IPs that send
mail, and the mail system
receiving mail from this domain
should automatically reject the
message.
As with all things technical,
you need to test your implementation
to ensure it functions
as you expect. The Sender Policy
Framework Web site (www.openspf.org) has some excellent
tools to help you implement
and test your SPF records.
If the vast majority of DNS
records contained SPF values
and if the vast majority of email
servers used SPF to check for
valid email server IP addresses,
the volume of spam and phishing
email would be significantly
reduced. We could then all go
about the business of doing
business without the nuisance
and security risks associated
with spam and phishing.
—Nolan Garrett,
Co-Founder
and Chief IT Consultant,
Intrinium, and Jeff Jones,
Co-Founder and Chief Security
Consultant, Intrinium
End of Article
Register
