Email Authentication Policy and
Deployment Strategy for
Financial Services Firms
A PUBLICATION OF THE BITS SECURITY PROGRAM
February 2013
BITS/The Financial Services Roundtable
1001 Pennsylvania Avenue NW
Suite 500 South
(202) 289-4322
Table of Contents
Executive Summary........................................................................................................................................ 4
Background....................................................................................................................................................... 5
Historical Perspective on Email Security ................................................................................................... 5
Emergence of DKIM and SPF ................................................................................................................ 5
Moving from Reactive to Proactive Security ............................................................................................. 6
Introduction of DMARC ......................................................................................................................... 6
Case Study for Email Authentication ......................................................................................................... 8
Very Large Bank ........................................................................................................................................ 9
Success.......................................................................................................................................................11
Implementation Approach .........................................................................................................................12
Five Phases of Deployment ...................................................................................................................12
Business and Process Considerations .....................................................................................................14
Identifying and Engaging Stakeholders ....................................................................................................14
Business Units ..........................................................................................................................................14
Enumerated Need Details ......................................................................................................................16
Policies...........................................................................................................................................................18
Implementing the Technology Recommendations ............................................................................23
Measuring Effectiveness .............................................................................................................................23
Metrics .......................................................................................................................................................23
BITS Trusted Email Registry .....................................................................................................................24
Responding to External Threats: Investigations and Takedowns ........................................................25
DKIM and SPF Implementation Guide .................................................................................................27
What Is Email Authentication And Why Is It Important? ....................................................................27
How Does Email Authentication Work? .................................................................................................27
General Considerations for Email Authentication Deployment ..........................................................27
Organizational Email Disciplines ..........................................................................................................27
Departmental Organization and Participation ....................................................................................28
Political Issues and Policy Determination............................................................................................29
Architectural and Technical Considerations ........................................................................................30
Third-Party Senders.................................................................................................................................31
Remote Employees..................................................................................................................................32
Domain Segmentation ............................................................................................................................33
Protecting Brand Domains That Do Not Send Email ......................................................................34
DomainKeys Identified Mail (DKIM) Implementation ........................................................................35
High-level Technical and Functional Overview..................................................................................35
Signing Versus Verifying ........................................................................................................................36
Technical Implementation and Best Practices ....................................................................................37
Sender Policy Framework (SPF) Implementation ..................................................................................40
High-level Technical and Functional Overview..................................................................................40
Publishing Considerations ......................................................................................................................42
The Forwarding Issue .............................................................................................................................43
Considerations for the Joint Use of SPF and DKIM .............................................................................44
Implementation tradeoffs .......................................................................................................................44
Combined DKIM/SPF use benefits ....................................................................................................44
Metrics and Reporting.................................................................................................................................46
Signing Validity ........................................................................................................................................46
Gathering Spoofing Data .......................................................................................................................47
Desirable Future Data .............................................................................................................................47
Technical Implementation of DMARC ...................................................................................................47
DMARC Overview..................................................................................................................................47
How DMARC Works: An Overview ...................................................................................................48
Anatomy of a DMARC Resource Record in the DNS ......................................................................48
Sender DMARC Implementation .........................................................................................................49
Appendix A Resources ...............................................................................................................................51
Appendix B Agari and Return Path Partnerships for Email Authentication .............................53
Appendix C Acknowledgements .............................................................................................................54
Executive Summary
The BITS Email Authentication Policy and Deployment Strategy for Financial Services Firms explains how
financial institutions can leverage several protocols and tools to detect and reduce the number of
spoofed email messages that reach consumers and business partners.
This paper was developed by the BITS Security Working Group and leverages previous papers
published in 2007 and 2009, and collaboration among technology leaders in financial institutions,
Internet Service Providers (ISPs), Email Service Providers (ESPs), and others to reduce the rampant
spoofing of email addresses. The paper discusses the Sender Policy Framework (SPF), Domain Keys
Identified Message (DKIM), and Domain-based Message Authentication, Reporting &
Conformance (DMARC) standards. Implementation of these standards provides a foundation for
building complete end-to-end email security solutions.
Email is a critical communications channel for business today. Fraudsters, criminals, and others have
learned how to create email messages that appear to come from another sender. Brands are regularly
and effectively abused by criminals who impersonate, or “spoof,” email addresses and Internet
domains of financial services and other companies. In a practice known as “phishing,” spoofed
email messages are sent in an attempt to persuade individuals to provide confidential personal or
company information to the spoofer. This information is then used to commit identity theft, gain
unauthorized access to computer systems, and other criminal acts.
Brands are regularly and effectively abused by criminals who spoof email addresses and Internet
domains of financial services and other companies. Email security has been a challenge, especially
when considering the original usage of the technology and the lack of security controls when email
was first created in 1971 to allow researchers to collaborate over the Advanced Research Projects
Agency Network (ARPANET). At the time, email security was not a priority because
communications occurred among a closed group of people over a trusted network. Today, email is
ubiquitous, travels across the open and unsecured Internet, and has become essential to personal,
consumer-to-business, and business-to-business communications.
This paper is designed as a guide for information security professionals to assist in developing
policies and procedures to implement the DMARC, SPF and DKIM protocols, and to leverage tools
such as the Trusted Email Registry. It discusses strategies for developing policies and procedures
and working with ISPs and ESPs, coordinating within large financial institutions to effectively
implement these protocols, and the benefits of adopting these protocols and metrics for measuring
success. Benefits include:
 Significant reduction in fraudulent email to customers and prospective customers
 Reduction in phishing attacks against high-value/trusted domains
 Increase in customer/partner confidence and trust in the authenticity of the sender’s email
 Enhanced brand and reducing the exposure of customers to phishing attacks that could lead
to fraud or malware infection.
Background
As email has evolved and become a ubiquitous business communication channel, the BITS Security
Working Group has actively tracked new developments and made recommendations to members on
best practices. This paper provides information about the BITS Trusted Email Registry1 and
guidance on how organizations can take advantage of new functionality to detect and reduce the
number of spoofed messages that reach consumers and business partners.
Historical Perspective on Email Security
Email security has been a challenge, especially when considering the original usage of the
technology. Modern email using a computer network was first established in 1971 to allow
researchers to collaborate over the Advanced Research Projects Agency Network (ARPANET). At
the time, email security was not a priority because communications occurred among a closed group
of people over a trusted network. Today, email is ubiquitous, travels across the open and unsecured
Internet, and has become essential to personal, consumer-to-business, and business-to-business
communications. Credit card numbers, social security numbers, intellectual property, and more are
sent using a technology that was never designed to be secure.
Figure 1 Merged Feedback Version – Lacking email authentication, ISPs are unable to reliably
determine the legitimacy of email.
Pranksters, criminals, and others have learned how to create email messages that appear to come
from another sender. In a practice known as “phishing,” spoofed email messages are sent in an
attempt to persuade individuals to provide confidential personal or company information to the
spoofer. This information is then used to commit identity theft, gain unauthorized access to
computer systems, and other criminal acts.
Emergence of DKIM and SPF
Efforts to reduce the rampant spoofing of email addresses began in earnest in the early 2000s and
resulted in the development of the Sender Policy Framework (SPF) in 2003. SPF provides a method
The BITS Trusted Email Registry provides complimentary domain-specific email reports to our member companies
that will help an institution strengthen the security of its email channel and reduce enterprise and consumer risks..
Information is available at http://www.bits.org/initiatives/trusted-email-registry.php.
1
that allows domain owners to publish lists of servers authorized to send emails on behalf of their
domains, granting receivers the ability to check emails against the authorized lists and easily detect
fraudulent messages. Several approaches based upon digital signatures emerged in 2004 and
culminated in the 2007 DomainKeys Identified Message (DKIM) standard. While SPF and DKIM
provide critical first steps towards improving email security, the effectiveness of these authentication
efforts is limited due to a lack of visibility as to who is sending email on behalf of an organization
and the lack of active policy enforcement to ensure receiving email service providers, such as
Google and Yahoo, are rejecting or quarantining suspicious messages.
Figure 2 Merged Feedback Version – With email authentication, ISPs can begin to determine the
legitimacy of email and reduce the volume of delivered fraudulent email.
Moving from Reactive to Proactive Security
In the past, detection of phishing attacks relied on mail receivers’ (ISPs) ability to perform statistical
analysis of large volumes of email. Unfortunately, most of the damage of a phishing campaign is
inflicted in the first few hours of an attack when email volumes remain low enough to avoid
detection by statistical analysis. The time difference between the initial phishing attack and eventual
detection forced organizations to respond reactively to phishing attacks, with response coming in
the form of remediating compromised accounts, cleaning up damage, and mitigating the breadth of
phishing attacks by attempting to shutdown infrastructure involved in an attack.
Introduction of DMARC
In January 2012, a consortium of email senders and receivers sought to address the continued
spoofing of high-value or trusted Internet domains by publishing a new specification: Domain-based
Message Authentication, Reporting & Conformance (DMARC). DMARC-based solutions, such as
the Trusted Email Registry, provide organizations with Internet-wide visibility into both legitimate
and malicious usage of an organization’s email domains, as well as the ability to direct receivers of
emails to enforce quarantine or reject policies against malicious messages. The DMARC
specification leverages the established technologies of SPF and DKIM and provides a foundation
for building complete end-to-end email security solutions. The DMARC specification builds upon
the successful prototype of an industry leading payments provider and is the result of a collaborative
effort between key members of the email ecosystem.
DMARC relies on SPF and DKIM to determine the authenticity of messages. When authenticity
cannot be established, a DMARC policy can cause inauthentic messages to be blocked before
reaching the inbox. Senders using DMARC see an increase in the value of email communication
through a significant reduction in the viability of phishing attacks against high-value/trusted
domains and an increase in customer/partner confidence in the authenticity of the sender’s email.
The Trusted Email Registry provides a convenient way to coordinate and visualize DMARC activity
across all of an institution’s domains and brands.
Figure 3 Merged Feedback Version – Audit/Detect/Remediate Phase.
Case Study for Email Authentication
In April of 2007, the BITS Security Working Group created a whitepaper titled BITS Email Security
Toolkit: Protocols and Recommendations for Reducing the Risks. The paper described technologies and
methods companies could use to mitigate the risks associated when using email to conduct business.
Although the paper’s core recommendations and observations remain relevant today, the email
ecosystem has evolved alongside increasingly sophisticated criminal attacks against institutions and
consumers.
Figure 4 Merged Feedback Version – Secure (Blocking) Phase.
Criminals have been relentlessly exploiting email’s weaknesses causing the amount of spam and
phishing to dramatically increase. The Gartner Group reports a 700% increase in email-based
phishing between 2008 - 2012, with 67% of those attacks targeting financial services and payment
firms, costing consumers and companies close to $8 billion. The estimated cost to victims by a single
phishing campaign is more than $1.4 million [Cyveillance (December, 2008)]. Credential theft also
occurs very quickly. For example, of all the credentials successfully obtained through criminal
phishing attacks, 50% are harvested in the first 60 minutes of a campaign [Trusteer].
The prevalence of phishing attacks has caused a decline in consumer trust of email. In a 2010
Identity Theft Resource Center survey, 81% of consumer respondents cited phishing emails as a
significant concern relating to the security of their personal and financial information when
conducting online transactions. Email continues to play a role as a significant propagation vector in
the spread of malware, causing 54 million U.S. adults in 2011 to report desktop malware infections.
The Gartner Group estimates that more than 40% of U.S. consumers have altered their level of trust
in email messages and online shopping as a result of this continuing threat (see Figure 5).
Figure 5 Security concerns have affected behaviors, Gartner Group.
Traditionally, email authentication has been an unreliable method of determining email legitimacy
due to complexities of deployment inconsistencies, gaps in coverage, and reliability concerns. As a
result, consumer mailbox providers (Hotmail/Outlook.com, AOL, GMail, Yahoo! Mail) have been
unable to leverage email authentication technologies when evaluating email that otherwise appears to
be legitimate – messages that are likely to be phishing attacks designed to fool consumers.
Very Large Bank
To illustrate a success story, a BITS member has provided the following case-study so that others
may learn from their experience in coordinating within a large organization the deployment of
authentication technology and policies. This institution, hereafter known as Very Large Bank (VLB)
had participated in the drafting of the 2007 BITS whitepaper. The widely circulated paper influenced
numerous banks and other financial service organizations (including VLB’s senior management) to
adopt many of its recommendations. Despite these positive steps, the problem of trust-eroding
phishing attacks continued to worsen. VLB decided in 2011 to launch a project to address the
problem of consumer phishing.
Figure 6 VLB Merged Feedback Version – Threat Intelligence Phase.
Data for the initial business case was based on an early estimate of 600,000 annual emails sent by
unauthorized third parties that purported to be VLB. Unauthorized third-party sources were located
in almost every country, despite VLB having no business operation in most countries. Annually,
VLB sent approximately 4 billion legitimate emails, forcing customers and potential customers to
determine which 20% (1 in 5) of the emails purporting to be VLB were fraudulent. The large
volume of unauthorized email competed with legitimate VLB email for consumers’ attention and
caused significant brand erosion as consumers lost confidence in the email channel.
To meet business case requirements, the VLB project sought to meet three specific objectives:
 Improve the customer’s email experience by eliminating fraudulent email and resulting
phishing and malware attacks
 Lower customer service call volume attributed to phishing attacks
 Enhance the VLB brand by improving email campaign results
Eliminating fraudulent email required enabling receivers with a way to easily identify legitimate VLB
email by implementing SPF and DKIM across all legitimate email streams. Discovering the sources
of all legitimate email streams can be problematic as large companies such as VLB often consist of
multiple lines of business. Each line of business can communicate directly with customers via email,
employ third-party Email Service Providers (ESPs) to send email on behalf of the business, or
partner with small consulting or marketing operations that send email on behalf of the business.
The VLB project team leveraged vendor-provided email intelligence to identify the sources of all
email sent to consumers using VLB-owned domains. Based on this intelligence, VLB identified lines
of businesses, ESPs, and third parties sending on behalf of VLB. As the project progressed, the
process of discovering legitimate sources was occasionally complicated by ESPs using other third
parties to deliver email, individuals sending email using residential networks while working from
home, and the presence of external campaign management software platforms used both by VLB
staff and third parties that originated email to customers and prospects.
During the process of installing controls to eliminate fraudulent email, the project team contacted
ISPs and asked them to only deliver email that originated from an authenticated VLB domain. Based
on this action, the project team identified several third parties that sent low volumes of legitimate
email on behalf of VLB that had not been made aware of the project’s domain authentication
requirements. To address needs for ongoing internal education, the project team implemented a
communications plan to inform all line of business marketing groups and product teams of the new
requirements for email authentication. Marketing teams quickly recognized the potential benefits of
the project and worked with their contracted ESPs to implement the necessary changes. VLB was
then able to notify all ISPs of the policy to drop email purporting to be from VLB-owned domains
that failed authentication checks.
During the execution of the project, the DMARC.ORG working group produced a draft
specification to allow domain owners to request quarantine or rejection of unauthenticated email.
The DMARC specification, published in January 2012, standardizes the SPF, DKIM, and policy
deployment model implemented by the VLB project team during 2011.
Success
As of late 2012, VLB has eliminated close to 90% of fraudulent email to customers and prospective
customers using VLB-owned domains, significantly enhancing the VLB brand and reducing the
exposure of VLB customers to phishing attacks that would otherwise lead to fraud or malware
infection. This is likely to increase as additional ISPs implement DMARC (with most large ISPs
expected to be DMARC-compliant at the end of 2012). The VLB project team is currently seeking
to determine the specific benefit of email-based brand protection by measuring the potential lift in
response rates due to fraud reduction. The elimination of fraudulent email is now easy to measure
due, in large part, to the feedback mechanisms provided by DMARC, and is available in an
enhanced form through the BITS Trusted Email Registry.
VLB’s project required an active internal communication program to reach and work with the
diverse service providers that originated email on behalf of VLB. Based on the success of the
communication program, various marketing teams requested to directly participate in the project.
Figure 7 VLB Authenticated Email Controls.
Implementation Approach
To implement controls based on email authentication, financial services organizations can adopt a
deployment lifecycle consisting of five phases. A summary of each phase appears below. Please note
that this document focuses primarily on outbound authentication, or email from the financial
services organization to customers and business partners. The equally important subject of inbound
authentication is out of scope of this paper.
Five Phases of Deployment
Monitor
Audit
Secure
Detect
Remediate
Figure 8 The Five Phase Deployment Lifecycle.
Audit: The Audit phase consists of creating an inventory of an organization’s email domains, email
streams, and email types. The domain inventory includes all domains actively sending email as well
as inactive domains registered for defensive or brand protection purposes. Active domains can
contain multiple email streams originating from different groups or vendors. Email streams can
contain different types of messages (e.g., transactional, corporate, marketing). Domains, email
streams, and email types must be discovered and tracked in order to implement controls. While
most of this information can be found through in-house research, DMARC-provided data and/or
the Trusted Email Registry can augment in-house research and reduce the cost of discovering email
streams.
Detect: The Detect phase compares and contrasts real-world data against the organization’s stated
email authentication implementation strategy. The result of this analysis directly informs the next
phase.
Remediate: The Remediate phase aims to resolve any email authentication implementation issues
or operational issues uncovered during the Audit or Detect phases. During this phase, all issues with
authorized senders should be corrected to ensure that quarantine or reject policies can be enforced
without impacting the delivery of legitimate email.
Secure: During the Secure phase, blocking policies are implemented for both active and inactive
domains. Publishing a blocking policy allows participating ISPs to either quarantine or reject
unauthenticated email on behalf of the organization, allowing only legitimate email to be delivered to
end-users.
Monitor: Successful implementers continuously monitor their deployment state, looking for new
signs of abuse, operational issues with authorized senders, changes in network topology, and other
anomalies. Monitoring can be performed in-house or through a vendor. Abuse such as new phishing
campaigns will show up in the reporting and can be turned over for investigation and takedown.
Operational issues can consist of newly hired third party senders, company acquisitions, new or
replacement email servers, and changes to DKIM signatures and SPF records.
An organization can begin implementing email authentication by following the five phases in the
presented order. The phases also represent an on-going process that can be used to maintain an
implementation after initial deployment. The continuing process can be used to detect, remediate,
and secure email streams that change due in a fluid business and technology environment. For
example, as new products and services are introduced, contracts with third-party senders begin and
end, portions of the business are sold off or acquired, or threats from bad actors appear on the
scene, existing implementations will need to be updated.
Business and Process Considerations
Identifying and Engaging Stakeholders
Technical and business groups within a company must incorporate email authentication into their
policies and procedures in order to successfully implement and operate these technologies.
Business Units
Business units or product teams are usually responsible for the use of email communications related
to their product or service, acting as the source of internal funding to support these operations and
as the arbiter of business risk decisions affecting the product. Depending on the size of the
company, business units may be focused around single products or services, ranges of products and
services, or be comprised of a number of different product teams. Business units must be made
aware of the damage that phishing has on their products and on the company brand as a whole, and
of the measures that can be taken to combat this threat. Business units will often champion email
authentication efforts that can be shown to improve communication with customers and partners.
Marketing / Brand Management
In many organizations, marketing groups maintain overall responsibility for developing, delivering,
and determining the effectiveness of communications to customers, clients, and prospects. Email
remains an important conduit for communicating to these various audiences. Marketing groups are
often responsible for the day-to-day business management of both third-party email service
providers and in-house capabilities for both bulk and transactional communications. As such,
marketing groups are key partners in interfacing with vendors in the implementation of email
authentication. Marketing groups may find significant value in monitoring the general “health” of
their email channels through feedback mechanisms such as provided by DMARC and the Trusted
Email Registry.
As a brand-strengthening activity, organizations often seek to communicate directly with customers
regarding improvements to email security and reliability. Marketing groups, in partnership with or on
behalf of business units and product teams, are often the best coordinators for developing and
delivering these messages. In addition, marketing groups may help promote consistent policies and
usage of email authentication across the organization, and serve as a clearinghouse for internal
education.
Customer Service
Customer service teams are important stakeholders in any email security deployment initiative since
they are the first line of engagement with customers. Customer service teams can help spread
awareness and education regarding the implementation and meaning of email security measures to
customers. This function is critical during periods when email authentication is being introduced,
especially as established practices may unexpectedly break during a transition period. For example,
customer use of alumni or affiliate email addresses may cause email to be blocked due to strict
blocking policies and poor forwarding implementations. Frontline customer services teams should
be supplied with training and materials to explain how these initially inconvenient measures benefit
customers in the long run, and how to address issues in the short term.
Email Engineering / Operations
Email engineering is responsible for the deployment and operation of email infrastructure operated
within an organization. Responsibilities include operation of externally facing Message Transfer
Agents (MTAs), internal email servers (such as Microsoft’s Exchange), and other related systems
within the email traffic flow. This function may be responsible for monitoring and managing
externally hosted email service providers, including fully outsourced employee email (e.g. Google
Apps, Microsoft Office 365) and bulk mail providers (e.g. Acxiom, Epsilon, ExactTarget) as well as
consultative support to business partners utilizing these service providers. In the context of this
document, email engineering is responsible for supplying addresses for SPF records, implementing
DKIM on managed MTAs, and providing public keys to DNS engineering for publication. This
group may also provide analytical support for reviewing DMARC reports and making corrective
actions as appropriate.
Network / DNS Engineering
Network/DNS engineering is responsible for managing the Domain Name System records for an
organizations registered domains. This includes publishing and updating SPF records, associated
DKIM keys, and DMARC records for all email sending domains. Network engineering may also
publish null (empty) SPF records and DMARC reject policies for non-sending domains to address
domain hijacking concerns.
IT Risk and Compliance
The following functions can span across multiple areas of an enterprise: vendor management,
fraud/investigations, and security operations.
Vendor Management
Companies increasingly rely on vendors to provide service solutions. This may include
administrative (corporate) email as well as marketing and other external email communications.
Vendor contracts should contain language requiring support for the organization’s email
authentication deployment policy and contain clear escalation paths should problems be identified
from either partner.
Fraud / Investigations
Corporate fraud and associated investigation teams may find the feedback reporting resulting from
the deployment of email authentication protocols, especially DMARC, an important source of
intelligence related to investigating fraudulent activity. Phishing and other email-borne attacks are
commonly used to both defraud customers and also gain footholds in corporate networks.
Aggregated and real-time reporting can provide valuable information on the source of attacks and
ways to counteract them.
Ma
rke
tin
g/B
r an
dM
gm
Cu
t
sto
me
rS
er v
ic e
Op
era
t io
ns
Inf
ras
t ru
ctu
IT R
re
isk
&C
om
plia
n ce
Ve
nd
or
Ma
nag
em
en
t
Fra
ud
/ In
ves
tig
ati
on
Sec
s
uri
ty
Op
er a
tio
ns
Security Operations
Some organizations may integrate security operations with fraud investigation teams. For purposes
of this paper, the security operations function manages detective and preventative controls to
protect corporate assets, particularly those related to IT. Security operations will most likely find
value in the added detective capabilities as well as the customer and employee protective capabilities
provided by email security and authentication.
1 General Awareness - Inside
2 Awareness Material - Customer
3 Implementation Strategy
4 Technical Deployment Details
5 Email Security Metrics / Reports
6 Operational Documentation
7 Data Taxonomy
8 Training
9 Email Asset Inventory
High Need
Moderate Need
Low or No Need
Figure 9 Role of Various Business Teams in DMARC Implementation.
Enumerated Need Details
The following is a list of actions that may be taken to build a strong email authentication program
within an organization and forms the basis for cultural change to increase the likelihood of success
over the long-term.
Marketing



Awareness: The value email security provides to both financial institutions and their
customers are significant.
Vendor Engagement: Develop plans to deploy email security mechanisms with existing
vendors and ensure future vendors support these tools from day one. Marketing should also
be the business gatekeeper to ensure appropriate oversight of all communication
engagements.
Customer Messaging for Email Security: Develop talking points and customer FAQs related
to the deployment of email security which may be shared with customers and clients.

Email Security Metrics: Partner with appropriate IT and/or risk staff to develop email
security metrics defining the “health” of the email channel which will assist in better
managing that resource.
Customer Service


Awareness: The implementation activities around email security that may change the
customer experience (e.g. my forwarded emails are being blocked…).
Training: How to answer customer questions regarding how to determine if an email is
legitimate. This may include training on the mechanisms deployed at major ISPs which may
leverage email authentication (e.g., new User Interface (UI) indicators).
Email Engineering / Operations




Inclusion in Planning: Email engineering should be included at the outset in any planning
and deployment of email authentication mechanisms. Email engineering provides expertise
as to the capabilities of various email platforms used in relation to email authentication, both
inbound and outbound.
Awareness: Raise awareness of business objectives related to email authentication. Providing
business context can help email engineering to solve business problems and reduces the risk
of inefficiently using finite organizational resources.
Data Analysis: Collect and analyze report data (both real-time and aggregate). Email
engineering should be provided with access to tools to fulfill this responsibility.
Service Management: Develop Service Level Agreements (SLAs) for making email platform
changes in support of email authentication, including business changes and tactical changes
addressing operational criteria and incidents.
Network / DNS Engineering




Domain Identification: Understand and document domain(s) subject to email
authentication.
Service Management: Service Levels for DNS-related changes for email authentication (e.g.
changes to SPF, DKIM keys, DMARC policies)
DNS Management: Coordination of DNS changes for domains with delegated authority,
such as may be in place with mail service providers.
Documentation: Operational documentation on the interpretation of email authentication
reports and response actions to address identified issues.
Vendor Management

Vendor Identification: Maintain an inventory of all vendors which may provide email
services directly (marketing email companies) or supplemental to their core services (e.g.
CRM, customer services, benefits, etc).



Vendor Communication: Document and convey to identified vendors expected best
practices to develop and maintain high levels of email reputation to support deployed email
authentication mechanisms.
Service Management: Develop and incorporate into business agreements expected Service
Level Agreements (SLAs) for important actions supporting email security. SLA items should
include problem resolution timelines dependent on defined severities, change requests (SPF
and DKIM record changes, DKIM key rotation, DMARC policy changes if not administered
internally).
Service Reporting: Define and document methods to deliver ongoing email authentication
reporting relevant to any given vendor.
Fraud/Investigations


Reporting: Access to regular and ad-hoc reporting capabilities, if available, related to email
authentication results.
Training: Training on the interpretation of provided reporting. Training on tools, both
internally developed and sourced as services, supporting the email security program.
Security Operations




Reporting: Access to regular and ad-hoc reporting capabilities, if available, related to email
authentication results.
Training: Training on the interpretation of provided reporting. Training on tools, both
internally developed and sourced as services, supporting the email security program.
Identification of Email Traffic Patterns: Profiles of normal email activity by source
including volumes.
Vendor Interaction: Operational contact information with email sending vendors. Work
with other security service providers, including integration of email authentication data with
phishing mitigation providers.
Policies
Successful email authentication deployments are achieved when organizations develop clear and
consistent policies across the entire enterprise. Clear and consistent policies allow various
stakeholders to coordinate activities between functions, maximizing the benefits of email
authentication while minimizing organizational friction. This section briefly touches on areas of
email governing policies to situate the additional policies needed to support email authentication.
Correspondence Versus Transactional Email
When the Internet was first opened to commercial use, companies commonly created one domain
and used it for all email communications – business correspondence, customer communications,
transactional email, etc. Companies largely continue to operate this way today, and often establish
separate domains or sub-domains to separate general correspondence from transactional email.
Separation may be done to simplify management and administration, to support regulatory
compliance and discovery, or to reflect internal administrative borders.
Domain / Sub-Domain Policies
Many companies initially allowed different internal groups to register new Internet domains with
little oversight or coordination. Over the course of several years, companies amassed large portfolios
of domains ranging from exact matches of major brands, to unwieldy constructs of product names,
business units, and overall brands. The variety of formats and conventions used to register domains
undermined customer attempts to discern imposters from legitimate senders, and on the whole
caused an increase in the attack surface for criminals trying to impersonate these companies.
Companies should employ consistent policies regarding how to map brands to domain names.
Policies may dictate when to create a sub-domain within a brand/domain for a new product or
service, versus creating a new Internet domain to support an advertising campaign lasting only a few
months or quarters. Overall brand management and marketing controls heavily influence policies
governing email domains, and can vary greatly from company to company.
Consistent Email “From” Addresses
The sending address and name shown on email coming from a company is part of the overall
impression a message delivers. Companies invest tremendous amounts of time and energy to create
and standardize logos and related colors, often concurrently standardizing policies to establish
consistency of email sending addresses.
Two different parts of the “From” line should be considered – the email address itself and the
display name (often called the “friendly from”). An example of an email address is
[email protected], and an example display name is “John Q Smith, Mortgage
Services.” Consistency allows customers to recognize and trust legitimate communications. Lastly,
consistent use of “From” addresses greatly eases the deployment of controls based on email
authentication.
Similar consideration should go into computer generated alert messages, marketing campaigns, and
other transactional communications.
Message Content Policies
The composition and design of the email content is often standardized within product groups, and,
depending on the company, across the enterprise. This is an extension of branding and
communications practices employed to create effective customer interaction. Depending on the
organization or business unit, these practices may be extended to correspondence.
An often overlooked facet of email content policy is the use of domain names in the hyperlinks and
graphical elements within the email body. Email containing links pointing to several different
domains can lead to the classification of such email as spam. Ideally, all elements of an email will
reference the same domain (or sub-domain), regardless if those elements are visible to the recipient.
An element containing an Internet domain, whether seen by the recipient or not, would optimally
use the same domain, or be sub-domains of the same parent domain.
Domain Inventory
Organizations possessing more than a few Internet domains should establish a central inventory
where individual domain status can be tracked. This inventory should identify all groups within the
organization that use the domain or sub-domain, regulatory status, whether the domain is
considered to be in a “production” state, the technical groups responsible for the operation of the
domain, etc. This inventory should be expanded to include the status of email authentication
measures implemented for all domains.
Static domain inventories quickly become outdated and therefore useless. Companies should modify
processes and activities that result in the creation of new domains or sub-domains to require those
domains to be added to a centralized domain inventory. This requirement should apply to any unit
within the enterprise, as well as third parties that may manage domains or sub-domains on behalf of
the company.
Authorized Third Parties
At some point, most companies will engage a third party to send email on their behalf. Contracts
with such entities should include provisions requiring third parties to implement any requisite email
authentication measures and to provide updates on operational matters that may impact any of these
measures or email delivery. For example, if an ESP begins sending email for a company from a
different IP address without notification, email sent from the new IP address could fail
authentication, impact delivery, and potentially disrupt business.
Third parties may be required to use addresses within one of the company’s domains, a separate
product or campaign-specific domain, or a sub-domain of one of the company’s domains. The exact
arrangement depends on the third party’s capabilities and will constrain a company’s operational
options, such as how to maintain or delegate control of DNS, how the necessary records are
published, and where reporting and analysis occur. Stakeholders should be aware of the operational
implications of these arrangements on change control, coordination of activity between operations
groups at each company, security and risk calculations, etc.
Domains and sub-domains used by third parties should always be included in the domain inventory.
Additional fields may be necessary to track external contacts, the business unit responsible for the
performance of the vendor, and the party managing the relationship.
Organizational Domains and Different Policies for Sub-Domains
In order to distinguish example.com from the top-level Internet domain .com, DMARC refers to the
domain owned by an email sender as the Organizational Domain (OD). Organizations typically publish
a DMARC policy at the Organizational Domain level. If sub-domains are in use, sub-domains would
normally inherit the policy published at the OD level. This feature allows a blocking policy to be
applied automatically to all sub-domains – including those invented or forged on-the-fly by
criminals.
This behavior may not be suitable for sub-domains that emit legitimate email, especially if subdomains are operated by different business units (or third parties) and maintain different timelines
for adopting email authentication. To provide flexibility, a flag may be set in the policy at the OD
level indicating an alternate policy to be applied to all sub-domains. For example, the policy
published for the OD example.com might be a quarantine policy, but a flag can be set to indicate that
a monitoring-only policy be applied to all sub-domains; or vice versa, depending on the needs of the
domain owner.
Organizations can also choose to publish a complete policy at the sub-domain level, which would
apply to any email using that sub-domain instead of the parent-domain’s policy. This allows for one
policy to be published for the domain and all sub-domains, but different policies to be published for
those sub-domains that require them. This works for sub-domains that are ready for blocking
policies before the rest of the domain, as well as for sub-domains that have not, or cannot, adopt
email authentication in time for a restrictive policy being applied to the parent domain.
Operations
Email authentication can provide data about a company’s email that was not available in the past, or
only available through special agreements and expensive services. This data can indicate when an
external attack is underway, when part of the legitimate infrastructure is misconfigured or broken, or
when an authorized third-party has failed to communicate a change in their infrastructure. Alerts to
the relevant operations teams can be triggered when this data exceeds baselines in different areas.
Reviews of the domain inventory and related contact information should be carried out periodically
to ensure the information is accurate.
Threat Response
Some of the raw data made available through email authentication technologies can identify
potential external threats before being reported by customers or partners. Clickable URLs found in
authentication-failing email can be sent to the company that owns the domain, or to a companydesignated third-party “mitigation provider.” Mitigation can dramatically decrease threats to brands
and customers and significantly shorten the time between when a phishing site first comes online
and when it is taken down.
Separating Correspondence and Transactional Messages
Email authentication is not a panacea. Even when a company has deployed DMARC, DKIM, and
SPF across the enterprise and third parties, some threat profiles are not covered. For example, email
that an employee sends to a mailing list, while legitimate, is likely to fail email authentication.
Forwarding means the email will not pass SPF, and the modifications will very likely cause the
DKIM check to fail.
However, failure of authentication does not mean non-delivery today. For example, most major ISPs
are able to identify mailing lists and after careful scrutiny and at their discretion, will allow delivery.
However, mixed use of the same domain or sub-domain might prevent a company from publishing
a more aggressive policy for that domain. Employees understandably become upset when messages
that were successfully sent to a mailing list yesterday stop working the day such a policy is published.
Therefore many companies should consider dividing these categories of traffic into separate
domains or sub-domains so the company can adopt stronger protections for transactional traffic
without impacting delivery of administrative/employee email.
Implementing the Technology Recommendations
Measuring Effectiveness
Metrics
Establishing baseline metrics is critical to ensuring the continued health of email authenticationbased control programs. Three distinct areas are described to help the reader assess the possible
scope, depth, and usefulness of metrics collection.
Scorecarding Technology Deployment
An important basic metric is assessment of the capabilities of the systems and services responsible
for your organization’s email. The results of an initial assessment will guide decision-making for
technology upgrades, required process changes, and partnership requirements.
When generating scorecards, consider creating one for each of the three distinct activities related to
email authentication-based controls, and including relevant questions and answers as part of the
scoring process:
 Outbound servers/services: Can they DKIM sign? Can your DNS publish SPF records and
related DKIM TXT records en masse? Can you monitor if outbound email is being rejected
due to authentication-based controls?
 Inbound servers: Check SPF? DKIM? DMARC? Act on auth. results?
 Partner capabilities: Do you know who your partners are? What are their outbound
practices? Can they perform inbound checks? Is there a (contractual) requirement in place to
do so?
Measuring Effectiveness Against Phishing Campaigns
A primary reason for deploying email authentication-based controls is to reduce the effectiveness of
phishing campaigns. To accomplish this, first determine the current impact of phishing, both on
your customers and on phishing attempts targeted at employees.
Ways to measure phishing:
 Track number of reported phishing incidents per day/week. Note exact-domain phishing if
possible.
 Attempt to correlate actual incidents of account fraud to phishing campaigns.
 Track amount of incoming email that purports to be from your organization.
Once initial metrics are in place concerning the amount of both customer and organization-facing
phishing, the effectiveness of email authentication based controls can be measured.
Ongoing Management and Monitoring
Below is a list of metrics organizations are encourage to collect and analyze on a regular basis:
 Phishing campaign (in)effectiveness
 Email volumes, per domain
 Control coverage, per domain
 Sources of blocked email, per domain
 Incident response time – time from submission of item into internal investigation queue until
resolution
 Time to create new domains/sub-domains when requested bylines of business
 Acquisition management – process to integrate newly acquired domains
 Partner monitoring
 Inbound monitoring
 Authorized server onboarding – when adding/creating new servers, make sure checklist is in
place to keep SPF, DKIM, DMARC up to date
 Third-party onboarding – when new partners come online, make sure checklists are in place so
that partner is aware of controls
BITS Trusted Email Registry
Once an organization determines it wants to deploy the DMARC standard in order to better secure
its email channel, it will need to consider how proceed with implementation. Organizations have two
implementation options. The first option is to build out their own DMARC platform. Since
DMARC is an open standard, there are resources, including open source tools and development
communities, available through DMARC.org that provide information on how to proceed.
A second implementation option is to subscribe to one of the pre-built DMARC platforms offered
by Agari and Return Path. Through their partnerships with the Financial Service Information
Sharing and Analysis Center (FS-ISAC) and BITS, Agari and Return Path offer member
organizations additional DMARC services and deployment expertise in addition to their
commercial-grade DMARC platforms. Both vendors offer cloud-based services that can be quickly
deployed and integrated with your existing infrastructure. To learn about the Agari and Return Path
offerings and their Trusted Email Registry Programs, visit http://www.bits.org/initiatives/trustedemail-registry.php.
The following table was prepared by member organizations with assistance from Agari and Return
Path to identify the differences between building out your own platform and subscribing to a prebuilt service.
Table 1: Comparison DMARC Deployment Options
Capability
Reporting Data Sources
 DMARC Data
- Aggregate
- Forensic 2
 Private Channel Data
- Aggregate
- Forensic
Data Processing, Visualization and Reporting
 Commercial-grade data processing,
visualization & reporting platform
 Discovery & management of third party
senders
Alerting (threats, infrastructure, etc.)
 Commercial-grade alerting platform
 Real-time malicious URL identification &
alerts
Policy Enforcement
 Policy enforcement - DMARC
 Policy enforcement - Non-DMARC ISPs
Integration with in-house and third-party
vendors for threat mitigation (i.e. URL
takedown)
In-House DMARC
Deployment
Trusted Email Registry
(via Agari and Return
Path)
Included
Included
Included
Included
Build
Build
Included
Included
Build
Included
Build
Included
Build
Build
Included
Included
Included
Build
Included
Included
Build
Included
Responding to External Threats: Investigations and Takedowns
In addition to the defensive capabilities made available through the use of email authentication
mechanisms, email senders might consider other methods to reduce exposure to further risks from
those who use email for malicious purposes. One such category has often been referred to as
“takedown operations” or the taking active measures to stem the flow of these email threats at or
2
Availability of forensic data published using DMARC is limited. Publication of forensic data by ISPs is optional.
near the source. These actions may include cooperation with Internet Service Providers (ISPs),
Registrars, security service companies, and others to stop the flow of illegitimate messages.
Derived from DMARC aggregate and forensic reporting, institutions are provided with more
detailed and structured information regarding problematic messages to help determine the source of
abuses. Forensic reports may also contain additional data which can identify the source of the email
attacks. They may also contain links that can be used to identify fraudulent websites intended to
trick customers into providing personal information, including IDs and passwords.
Armed with this information, financial institutions may choose to work with ISPs and hosting
providers to block SMTP traffic from identified systems, or take such systems off-line. In addition,
investigations conducted on such systems may lead to other upstream sources of the attack such as
command and control hosts, which are used to direct the activities of compromised or “botted”
systems during the conduct of an attack campaign. In parallel, action can be taken to disable access
to identified fraudulent sites whether through hosting providers, registrars or even anti-phishing
tools operating at a browser level.
Figure 10 Merged Feedback Version Threat Intelligence Phase.
Often it is difficult to build and maintain affiliation with the many ISPs and related companies,
particularly across geographic and jurisdictional boundaries. Companies have formed to address
these challenges and mediate such actions on behalf of their customers, building upon established
relationships to ease the execution of reactive security measures, both for victims and service
providers alike. Through the leverage of scale, these security service companies can establish
operating “playbooks” to gain both efficiency and speed of execution in taking appropriate actions.
DKIM and SPF Implementation Guide
This section provides guidelines and recommendations for improving email deliverability rates and
protecting brands from domain forgery and phishing scams.
What Is Email Authentication And Why Is It Important?
Email authentication allows the receiver of an email and the Internet Service Provider (ISP) to
confirm the identity of the sender, addressing one of the fundamental security problems inherent
with email – spoofing. By exploiting the ability to send unauthenticated email, phishers and spoofers
have been able to thrive as ISPs are not able to authenticate the sender of an email and cannot reject
the message or put it through additional filters to determine if it should be delivered.
Not only is authentication integral to preventing phishing and other fraud, email authentication plays
a key role in the emerging reputation and accreditation systems that will drive the future of email. As
a legitimate business, authentication should not be optional as it is an essential tool for securing
brand and online reputation.
How Does Email Authentication Work?
ISPs are utilizing two primary methods of authentication: IP and cryptographic. The IP solution ties
a responsible sending domain back to a set of permitted IP addresses, which requires publishing text
(TXT) records in the Domain Name System (DNS) record for each of your domains. An example of
an IP-based solution is SPF. Cryptographic authentication signs each message in a way that is
difficult to forge, proving that the message came from the indicated sending domain. The industry
standard for the cryptographic authentication is DKIM (DomainKeys Identified Mail).
Today, companies are moving towards adoption of SPF, DKIM, or both. Major email providers like
AOL, Microsoft, Yahoo! and Gmail are using both SPF and DKIM to authenticate email senders. In
addition, businesses must broadly adopt authentication across all their domains, not just those
associated with a large volume of commercial email. This includes domains used for corporate email,
customer support and other services. While most online fraud is associated with high-profile
marketing domains, without authentication it is possible for any of your domains to be spoofed –
and for critical business functions to be compromised.
General Considerations for Email Authentication Deployment
Organizational Email Disciplines
Some companies maintain disparate technology groups responsible for network infrastructure or
email that may be based on lines of business, acquired subsidiaries, or other business factors. These
groups may even have independent control over the email services provided to their respective
companies, yet have overlapping responsibilities with the use of company brands and domains.
Other companies will consolidate email operations across the enterprise, centralizing responsibility
in one department to the greatest extent possible. However, even with one global email services
group, large enterprises typically still have informal (i.e., “rogue”) departmental email deployments
The disadvantages of having separate email groups is that they each have to carefully coordinate
together all the steps of email authentication deployment. This coordination is critically important
when these groups have common use over company brand domains as the deployment of sender
authentication by one group affects all the others.
Additionally, there will be situations where email delivery may be partially or completely outsourced
to a third-party information technology group. In these situations, it is important to include in the
discussions all necessary personnel from these groups, as well as business management responsible
for ongoing contract maintenance between the company and its IT vendor.
Departmental Organization and Participation
Since email is a communications channel leveraged throughout all lines of business, and in some
businesses is considered a “mission critical” or “tier 1” service, enterprises are particularly sensitive
to issues concerning email. When planning a sender authentication deployment, the company must
consider the teams across the organization that will need to be involved. It is always best to include
representatives from areas that have the potential to positively sponsor, or negatively impact, a
project of this magnitude.
These areas include:
Networking / Infrastructure / Operations
These teams are primarily responsible for email infrastructure and support – the systems that will be
DKIM signing email, as well as the hosting networks and Internet-facing systems for corporate
email. These groups may also manage the corporate and Internet DNS systems responsible for
hosting SPF TXT records and DKIM public keys.
Information Security
These teams are responsible for ensuring systems are properly protected. They also are often
responsible for drafting security policy across technology applications, including email.
Operational Risk
Within financial services, operational risk works closely with regulatory compliance and audit teams
to ensure that overall activities do not incur too much risk for any particular protect, or line of
business, which may cause businesses to be interrupted or the company reputation to be tarnished.
E-commerce / Online Properties
These areas typically manage the company’s web presence, notably online banking, credit card, and
mortgage application processes. E-commerce is generally responsible for most of the high-risk (from
a phishing perspective) transactional email that is delivered to customers. Examples include online
banking alerts, confirmations, and encrypted statement delivery.
Marketing
Marketing is usually the most prolific senders of email within an organization, because their job is to
market and sell company products and services using email and other channels. Marketing is also
potentially problematic because marketing groups tend to be distributed among lines of business and
typically will outsource campaigns to third-party vendors.
Supply Chain / Procurement / Vendor Management
This area is responsible for approving new vendor relationships, maintaining existing vendor
relationships, writing and enforcing supply contracts, and in some cases, for managing outsourced
contracting agencies. These groups will establish policies that require new and existing vendors, by
contract, to provide an email service to support your corporate email sender authentication
practices.
Corporate Communications / Public Relations
Communications/PR will approve all broad-reaching internal project communications to lines of
business, and also assist in determining the best way to reach deep into the enterprise to target
individuals and teams that need to know appropriate details and required actions of the project.
They will also provide support to deal with external requests for information from third-party
vendors and press.
Privacy and Legal
It will be important for Legal to understand the ramifications of the sender authentication program
– especially edge cases where lines of business may have email tagged as spam or dropped by an ISP
if they do not follow appropriate email authentication policies.
Political Issues and Policy Determination
Email is a tool that is deployed across the entire organization. It is generated by people as well as by
applications. It will be sent to other applications for processing and people external to the company
– the company’s customers, business partners and alumni. It is in the best interests of companies to
establish policies that govern email generation, appearance, and other conventions that will allow
their email to be recognized by its receivers. In many situations, in addition to the company website,
email is the “face” of the organization that is most familiar to its customers.
Email “from” Policy
It is important to establish conventions for how the header sender address, also known as the
“friendly from” or “from name,” is going to appear in recipients’ email clients. The header sender
address is the one most commonly displayed to the email recipient in their client interface. Although
the email may be sent from [email protected], the “from name” may be configured to
display Clark Gable or Example Bank, or Example Bank Inc. Companies that send email using the
envelope header examplebank.com but have no convention on the header will confuse customers,
especially those lines of business that use their line of business internal common name that is
relatively unknown outside their immediate business network or customer base. These conventions
and policies may be applied consistently across a brand, or a line of business, or across the entire
enterprise, as appropriate for each organization.
Email Content
In addition to what the customer typically first sees in their inbox (the “header sender address”),
once they open the message their first impression is made by the overall look and feel of the email.
Some companies have standard disclaimers, trade membership logos, and company logos. Some
companies use a generic salutation while others use a salutation that includes the recipient’s name.
Although there are innumerable options, the company should establish policy on how the email is
going to be presented, in a consistent way, across all business units that leverage a like brand. This
will establish a comfortable “look and feel” of the company’s communication, much like a business
that uses consistent letterhead, envelopes and format in written communications.
As with the email “from” policy, email content policy can be applied to maintain consistency across
an enterprise, or across a line of business (each business keeping its own look and feel “identity”), as
appropriate.
Some will argue that establishing a static, consistent look and feel with the header sender address
and the message body will allow phishers to more easily create recognizable and trusted fraud email.
The fact is, many times the phishers create email messages that look more professional and
believable than many of the organization’s own authorized communications. Creating email
consistency across a brand will enable a company (and a customer) to more easily spot a fraudulent
message sent by an amateur fraudster that contains typos and non-standard form.
Domain provisioning policy
Many companies have lax controls or no restrictions that prevent business units from registering
new Internet domains. Many times, a business will roll out a new brand or product and register a
domain to support the new products or services. They will often not think about the security
implications of how that new domain could be used as a conduit for fraudulent email to customers
of that service.
It is important for companies to write and enforce policies that require the proper vetting of new
domains (and sub-domains) for business use – especially those that will be used to send email. These
policies should establish the proper control points and approval steps required to maintain the
domain, as well as the information required to register the domain in the sender authentication
system.
Architectural and Technical Considerations
Companies should evaluate several architectural and technical issues, including the two below.
Message Transfer Agent (MTA) support
MTA support for sender authentication protocols is slowly increasing as vendors recognize the
importance of email security and developers write plug-ins for standards-based SMTP systems.
Nevertheless, slow demand growth, performance considerations, and gaps in authentication
capabilities have slowed some vendors in incorporating authentication into their roadmaps. In those
situations, it is best to leverage contract renewals with supply chain’s assistance to encourage the
MTA vendor to support SPF and DKIM.
Although for the financial institution, sender (outbound) DKIM and SPF authentication is the
highest priority, many companies will want to eventually, if not immediately, seek to leverage
inbound authentication to filter fraudulent email being sent to their associates. Because of this, it is
best to have an MTA that supports both DKIM signing and validation, as well as SPF validation
(there is no requirement for an MTA to support SPF outbound since it relies completely on DNS in
that direction).
What network layer to deploy
In nearly all situations, DKIM signatures will be applied to a message at the perimeter MTA. The
perimeter MTA is the email gateway server that is the last hop between the company and the
Internet. This approach allows the message to travel through the company without the need for
internal systems to preserve the DKIM signature, as modification of the message header will
necessitate the signature to be re-applied to reflect the change in message status.
For systems that validate inbound DKIM, the best place for this activity is either at the edge MTA
or an intermediate MTA that will perform other hygiene activities such as anti-virus and anti-spam.
In most cases, authentication check results will be an input into the antispam heuristics engine.
Third-Party Senders
Companies should construct an “email sender inventory” to capture all entities –applications,
systems, vendors – that send email on the company’s behalf.
The sender inventory may consist of the following fields:
Compliance level
Used to track overall compliance of the sending entity with corporate policies and technical protocol
support (DKIM, SPF, etc).
Priority
Used to indicate the relative importance of a sender entity. For example, the main corporate MTA
will take priority over a smaller application that may maintain its own MTA but rarely sends
customer e-mail.
Email domain
The domains the entity uses to send email. These may be major corporate brand domains, or subdomains.
Line of business and technical contact information
The internal “owner” of the system who has responsibility for complying with policy.
Third-party business and technical contact information
The external “owner” of the system who is responsible for complying with policy, if this is a system
that is managed by a vendor or subsidiary.
SPF status and details
Information on how far along the entity is with SPF compliance. Also contains the DNS TXT
record defined for the SPF record, which in turn delineates authorized systems and the SPF fail
indicator.
DKIM status
Information on how far along the entity is with DKIM compliance. Also contains the DKIM
selector designation and DKIM reflector test results. It may contain a copy of the DKIM public key
for reference.
Remote Employees
Remote employees may send email in a number of ways. These methods are described and discussed
as follows.
Sending email directly from the employee PC to the Internet
This method is sometimes, but rarely, used by companies that allow employees to send email using
their corporate brand domains using a telecommuting connection via an ISP, hotel, or kiosk.
Although it is technically possible to establish DKIM signing for this arrangement, pursuant to
having a compliant Message User Agent (MUA), the administrative overhead is much too difficult to
maintain given the sheer number of employees in a typical large company, as well as the
impossibility of maintaining an authorized list of sending IP host addresses for employees who
could be literally anywhere in the world on any network. The only SPF solution is to enable the
entire Internet as authoritative for the sending domain, which would negate any benefits of
authentication and most likely cause the domain to be blacklisted by reputation systems. In most
instances, this method is not practically feasible.
Using a third-party messaging application, such as a contact management system or web
email that spoofs the corporate email domain
This method can be handled the same way as third-party senders described above. This option has
the least control over SMTP traffic. The difficulty in administering this is directly proportional to the
number of allowed third-party messaging systems used by employees. In many cases, smaller thirdparty systems allow open spoofing, do not allow for static IP address assignments, and will not allow
a successful sender authentication deployment. It should be noted that some third-party senders may
not be technically capable of supporting authentication.
Using a local SMTP server that is connected directly to the Internet
For this case, each SMTP server will need to be treated as its own separate, authorized sending
entity. IP addresses for each SMTP server will need to be registered in the sender inventory and
added to SPF records. In cases where these machines are network access translated (NAT’ed)
behind a firewall and assigned private IP addresses, the public-facing address or address range will
need to be static and monitored for changes.
Each remote office SMTP server will need to run an MTA that is capable of signing messages with
DKIM; a public/private key policy will need to be applied to the server; private keys should be
distributed by IT to the remote server administration personnel; and public keys that are used to sign
mail on the server should be added to the inventory of DKIM selectors used for that domain or
sub-domain for which the remote office is responsible. There may be security disadvantages to this
option, as private keys will be stored in multiple locations that may not be safeguarded as well.
Using a local network SMTP server that routes email to corporate SMTP gateways which
connect directly to the Internet
This is the most common way companies deal with remote employees or satellite offices. The local
SMTP server simply does its job as a basic mail router and does not have to perform any kind of
signing or validation. The mail is routed to the corporate gateways, which are centrally managed and
have the appropriate software for signing and validation (and other important hygiene steps such as
anti-virus). This model is least efficient from a “hop count” model, but most efficient in every other
way, including administration, security, and cost. This method is also used for remote employees
that connect to the enterprise via VPN. They are essentially “internal” to the network and will send
email via their enterprise mail platform.
Domain Segmentation
Companies frequently use separate domains and sub-domains for corporate, transactional, and
marketing email. In addition, they may assign these domains to third-party senders for their use.
Email from a company can be broadly assigned to one of three categories:
• Marketing: Email that has a primary purpose of selling, cross-selling or informing customers
or potential customers of products and services.
• Transactional: Email that contains information about a transaction the customer is affected by
or has performed. Examples include alerts for direct deposit, payment confirmation, or
scheduled bill reminders. Transactional email has information that directly relates to the
customer in a unique and personal way.
• Corporate: Email sent and received in the normal course of business activity among employees,
business partners, vendors and personal email.
During a company’s inventory activity to determine which lines of business have their own email
systems or third-party email vendors, it will become apparent that there are several, if not dozens or
more, domains in use for sending email. There will be significant challenges for companies that
allow third parties to use their main corporate domain (e.g., examplebank.com) for sending email.
There will be issues related to SPF TXT record size, as well as defining selectors and building public
keys for companies that have email coming from one domain but several systems, some of which
may not be directly controlled.
It will be much easier to perform a controlled rollout if third parties and LOB-specific systems can
be delegated their own domain or sub-domain for email use. For example, the main domain for
Example Bank may be examplebank.com, but the following domains can be distributed for use by
the following lines of business:
• card.examplebank.com: credit card main domain
• studentcard.examplebank.com: credit card marketing campaign for students
• onlinealert.examplebank.com: transaction email for online alerts
Many companies will want to use their primary domain for as much email traffic as possible since
that domain is well known to customers. However, as email filtering systems include characteristics
such as reputation score for domains, in the absence of specialized services, having the primary
domain used for marketing as well as transactional mail may cause transactional mail to have a high
spam score since a high proportion of marketing email gets flagged as spam by customers, which in
turn causes ISPs to have a heavy-handed approach to future email from that domain.
In the context of sender authentication, it will be easier to maintain authorized host IP addresses for
SPF and selectors and keys for DKIM if segmentation is maintained for third parties and lines of
business. As authentication matures and systems are built to provide granular metrics and improved
quality of service for transactional and corporate email, business value will increase as a more
complete view of email delivery becomes available. The domain segmentation approach makes it
easier for ISPs to provide better reporting and for businesses to sort through the data to measure
specific and relevant success.
Protecting Brand Domains That Do Not Send Email
To specially protect brand domains that do not send mail, companies can proactively assign SPF
records to those domains with “no send” parameters. A common tactic of online fraudsters is to
send emails from esoteric domains that may be owned by the target company. These domains pass
lookup checks because they do exist, but they may never be used to send email from the company.
The customer doesn’t know this, and neither will the ISPs, so any email sent from the company may
pass an initial visual or machine inspection. With the advances of reputation systems, this problem is
mitigated somewhat, but the method will still be used by criminals. Companies can address this by
publishing SPF records for all their domains, even if they do not send email. The following syntax is
an example of this:
“v=spf1 –all”
This SPF syntax simply states that the domain for which the SPF record is contained, no email is
sent and the policy for any email purporting to be from the domain is hard fail.
This will cause any email (fraudulent as well as valid) from the domain to be classified as
unauthorized spoofed or phished email by an SPF validation.
The administrative cost of this activity is relatively low since it involves one extra task for the DNS
administrators to add the TXT record for new domains that have no email intention. Of course, if
the domain were to be used for email in the future, the SPF record would need to be updated to
reflect the valid hosts.
To the extent that services are available to publish information about domains for an institution,
these domains should be included.
DomainKeys Identified Mail (DKIM) Implementation
High-level Technical and Functional Overview
This document does not attempt to serve as an in-depth tutorial on DKIM and the intricacies of the
protocol.
DKIM allows an organization to claim responsibility for, and assert the identity of, a particular email
message that it, or a trusted third party, has sent. The responsible organization adds a digital
signature to the email message, tying it to a domain name the organization owns. Messages are
signed using public key cryptography (RSA algorithm). The signing action must be performed by any
system maintained by the responsible organization, including the Mail User Agent (MUA), Mail
Submission Agent (MSA), or, most often, the edge MTA-gateway SMTP router. After a message has
been signed, any device that message comes in contact with may validate the signature. Usually, this
validation will be done by the edge MTA or other MTA of the recipient. Typically, any heuristic or
policy determination on the disposition of an email will be made by one of these MTAs, and not by
the recipient’s MUA or by the recipient himself.
•
•
•
•
•
•
The high-level requirements of DKIM configuration and setup are:
The message body is made canonical, and then hashed (typically SHA-2569).
Canonicalization helps prevent signature breakage from minor changes incurred by the
message during transmission.
Message headers are included in the signature. The header fields that are included are
determined by the signing organization as part of DKIM configuration.
A new field is appended to the message header named DKIM-Signature that contains
important information required by the verifier, including the body hash, the selector name,
the list of headers in the signature, and the canonicalization algorithm.
The header fields and the DKIM signature field itself are canonicalized and a hash of them is
created.
An RSA signature is generated for the hash, and the signature is inserted back into the
DKIM-Signature field.
The full DKIM-Signature field is added to the header of the message, and the modified
message is ready for transmission.
Below is an example of a DKIM header included in an SMTP message transmission from an
example bank’s domain, examplebank.com, using the selector 09-tx-lob. Note the selector (s=),
domain (d=), and the hashed (h=):
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=examplebank.com;
s= 09-tx-lob; t=1233611805;
bh=IohO4h5JgZbIJn2plMBlowgxB/SCuKtsFlU/iK3Ke
TI=; h=Date:From:Subject:To:Message-id:MIME-version:Content-type:
Content-language:Importance:Accept-Language:Thread-topic:
Thread-index:X-MS-Has-Attach:X-MS-TNEF-Correlator:
X-Proofpoint-Virus-Version;
b=bNzxG87h1dKpa/TX8B5tPY3K3Cw3qX8zDJnc
EIcBB/wNprTHYoQGFdxZ0uP+XN1Fk9QmXrAPx2oTewuH0WNpnvBeozVUo9qpw8VUT
3O
e6KZMC231Uo7ZaYbcvDb6aPflndyZX8oav5JnXr33GXX1pa2dLZCDdJxUUP5ZWBrA
Ieo=
Compare the above signature to the one below, which is also from examplebank.com, but from their
online banking alert system. Note the selector (=09-txt-alerts) and the subdomain
(=marketing.examplebank.com):
DKIM-Signature: v=1; a= rsa-sha256; c=relaxed/relaxed; s=09-txalerts;
d=marketing.examplebank.com;
h=From:To:Subject:Date:List-Unsubscribe:MIME-Version:ReplyTo:Content-Type:Content-Transfer-Encoding:Message-Id;
[email protected];
bh=ov0qr9N5GvayX1kfPyuljOL2ySE=;
b=LxCF+L+F6ltgxfker9eFHqZ1D4dgVpAIjkTz4veTpH8wnTk//jOVkevejjkOGKs
OYVqzubSF4TQO
wlhwjqONKbmkMKJjj9phfBTTwjZQb7uSd8rUbmkqPFhhrfqR4cS3zpy46S+/L5mIT
9mYEY7EDf1/
HYv0Mfvlwovgx23qi8M=
Signing Versus Verifying
The act of signing a message asserts the “ownership” or identity of the message as being sent from
the authorized sender. Because the sender has created the DKIM header information based on the
public/private key-encoded hash, and the public key is kept in DNS, only the owner of the domain
for which the message is identified can correctly sign messages for that domain.
The owner of the domain name used for a DKIM signature puts their reputation on the line for the
veracity of that message. Verifying a message can be done by any system that may have access to
that message because it has been routed to (or through) it. Verification means that the message’s
DKIM header has been identified, and the recipient system has fetched the purporting domain’s
appropriate DKIM public key from DNS based on the selector information contained in the header.
Receivers who validate a signature may then use the information on the sender’s domain as part of
anti-spam heuristics, which may include reputation data collected about that sender from other
parties.
Technical Implementation and Best Practices
This document does not serve as a technical deep-dive manual on deploying DKIM. For technical
details, refer to the Resources Appendix A. Where appropriate, certain steps of the deployment process
may include some technical information in order to provide the reader with enough background
information to understand the steps involved, as well as what kind of technical resources they
should have at their disposal for a successful deployment.
Creating Selectors
Selectors, which are mechanisms to subdivide the key namespace, allow a single domain to utilize
multiple keys to support periodic key changes and overlap of keys while old ones are phased out,
which are recommended security practices. Support of multiple keys for the same domain is also
useful for organizations that must support third-party use of the domain. Since the corporation will
not want any third parties to obtain their private keys, a special signing key may be created for the
third party, or the third party may create their own if they have access to OpenSSL or other
company-approved key generating mechanisms. Having a third party use a dedicated and unique key
pair assigned by the domain owner, selectors allow the domain owner more flexibility in dealing with
a security breach in the event the third-party systems are compromised and their private key
exposed. As an alternative, companies can also allow third parties to create their own keys, as the
company will still have control over the DNS publishing of the public key.
There should be consistent naming around selectors across the organization and its authorized third
parties. Naming conventions should be communicated as part of the project plan in order to prevent
any entities from creating selectors outside the standard, which would then need to be recreated or
grandfathered.
Selector names should contain information on the creation date (which allows for key rotation), as
well as administrative responsibility.
For example, the scheme: date.purpose.admin
• Date: used to delineate the creation date for selector rotation scheduling
• Purpose: the primary purpose of the domain: marketing, transactional, or corporate
• Admin: the administrative entity responsible for the domain or sub-domain, which may be a
designation of the company itself or a third-party agency.
The selector name can only contain dots, letters, numbers or the hyphen character, although
hyphens cannot be the first or last character.
Creating a Public/Private Key Pair
Keys pairs may be created using OpenSSL or purchased through a certificate authority. OpenSSL
documentation is available at www.openssl.org or contact a certificate issuer for more information.
Signing Policy Designation
Companies will want to consider the following steps for signing policy designation.
• Determine the selector naming conventions and inventory the selectors associated with each
sending entity (see Creating Selectors above).
• Canonicalization settings should be set to relaxed, at least during testing and through the
beginning of production. This will allow toleration of minor modifications such as header
line wrapping changes, capitalization, and whitespace replacement. Changing
canonicalization to simple is more secure, but tolerates almost no modification and may
result in invalidated signatures. Each organization will need to determine which setting
works best in their environment.
• Signing and verification algorithms will be rsa-sha1, which is the default if no algorithm is
specified and MUST be supported by all implementations.
• Key sizes should be no less than 1024-bit and the largest practical key size is 2048-bit. (2048
is the largest key that fits within a 512-byte DNS UDP response packet).
• Length tag (L=) is not recommended used for security purposes10
• Required tags include:
- a= : algorithm used to generate the signature (plain-text: rsa-sha1)
- b= : signature data (base64)
- c= : Header/body canonicalization (plain text: relaxed/simple; simple/simple)
- d= : domain of signing entity (plain text: company.com)
- h= : signed header fields (plain text: a colon-separated list of headers presented to
the signing algorithm)
o FROM, SUBJECT, DATE – must be included
o All MIME header fields should also be included
o Any other header field that describes the role of the signer (e.g., SENDER or
o RESENT-FROM must be included)
o Any header fields that are transient (perhaps added by an application to be
later removed by a downstream application) or likely to be modified or
removed in transit should NOT be included
o The DKIM-Signature header field is always implicitly signed and must not be
included in the h= tag; for further information on header tag, refer to the
header tag section of the DKIM specification11.
- s= : selector (plain text: date.purpose.admin: the selector subdividing the namespace
for the d= domain tag
• Optional tags should be researched prior to use, especially x= (signature expiration) and t=
(signature timestamp)
Install and Configure Supported Software
Upgrade or install software for the MTA(s) that will be signing the messages. Depending on the size
of the organization, and whether this is a test or production deployment, this process can take a few
minutes, or several weeks. For production deployment, this step should have a formal project
framework and consultation of the MTA vendor. See Appendix A for links to configuration
information for some common MTAs.
Test and Record Results
10 RFC 4871, Section 3.4.5 Body Length Limits http://www.ietf.org/rfc/rfc4871.txt
11 RFC 4871, Section 5.4 http://www.ietf.org/rfc/rfc4871.txt
Typically, most installations will cause all messages passing through the signing MTA to be DKIM
signed.
The following test cases can be used as a starting point to develop your own testing routine:
• Send a message to an external account that passes through the signing MTA and visually
inspect the message for the presence of a DKIM header and corresponding message hash.
• Send a message the same way to an external DKIM mirror site that will perform a DKIM
validation and display, or email back, results.
• Testing should be done to validate DKIM results for every domain, and all selectors for
domains, on all MTAs that are signing mail.
• Create a script or other automated system that periodically checks email sent from various
systems and campaigns, including third-party email that should be signed, from various
systems, to monitor for broken or missing signatures, etc.
Infrastructure Impact
Since DKIM is a cryptographically-based digital signature solution, there will be some CPU
processing overhead associated with the activity of canonicalization, hashing, and signing. Email
systems by nature tend to be more I/O intensive than CPU intensive, so most SMTP servers will
have the necessary free overhead to handle DKIM signing.
If the SMTP system is already delegated to some CPU-intensive activity such as anti-virus, antispam, or encryption, then it is recommended that performance testing be done on similarly
configured lab hardware. Also, if the performance of the MTA hardware is already at the limits of its
capability, then implementing DKIM may be enough to push it over the edge and experience
performance problems such as queuing.
It is impractical to outline a rule of thumb for performance, since overhead impact will depend
heavily on the hardware available as well as the MTA software (and even the MTA version) and how
it is configured. However, anecdotal evidence to date suggests that DKIM signing adds 1% or less
additional strain on system CPU performance, and some even suggest that it is a “drop in the
bucket” compared to processes like anti-spam which may be running on the same machine.
Performance will vary from product to product. It is important to test DKIM signing in a lab
environment to determine performance impact and whether additional system capacity will be
needed.
Selector and Key Rotation
The purpose of selector and key rotation is to augment security and mitigate breaches in the event
keys are compromised. In some organizations, key may “leak” as administrators move from job to
job, may not be secured properly, or may be maliciously shipped to individuals with criminal intent.
There will be two ways to rotate keys: either via prearranged schedule, or ad-hoc. Ad-hoc should be
done if there is any suspicion that a key has been compromised. Not only should the affected key be
replaced, but any key that is under similar storage conditions. The same process for key and selector
replacement should be followed for scheduled maintenance, as well as if it is being done to address a
sudden security concern (unscheduled maintenance). Key replacement allows a company to move, in
a controlled manner, from one selector naming routine to another, change the strength of key
encryption, or enforce security policy around key retention.
As described above, a selector is created for a domain (or multiple per domain) which specifies the
public key to retrieve from DNS. When keys are rotated, there will be a period of time when
messages signed by the new selector/key will exist on the Internet alongside the old selector/key. It
is important to keep the transition period where both selectors/keys are supported until the
organization determines the population of old selectors/keys have aged enough to be removed from
DNS with minimal disruption. Some security groups indicate this can be as long as several months,
but the timeline can be accelerated under exigent circumstances.
Since DKIM can be validated at the MUA, allowing keys to deprecate can result in valid messages
being considered invalid if a key is expired and the MUA tries to validate an old message. To date,
we see very little validation being performed by the MUA, but rather the MTA while messages are in
active transit. This being the most common case, it makes sense that a company determine for itself
when old keys and selectors can be retired by simply monitoring what they see in transit using
automated tests and monitoring described above. In other words, as part of routine testing, a
company should be able to determine the state of DKIM signatures on its own messages, as well as
determine that old selectors/keys are no longer being detected by test systems. At that point, it is
safe to retire the old keys.
Sender Policy Framework (SPF) Implementation
High-level Technical and Functional Overview
Sender Policy Framework (SPF) is a path-based authentication protocol that also communicates
policy, and is intended to prevent unauthorized spoofing of the envelope sender address in an email.
SPF provides the framework for domain owners to specify which mail servers (hosts) are allowed to
send email from those domains. The domain owner publishes information into an SPF record in the
domain’s DNS. Then, when the recipient’s mail system receives the message, it checks whether the
message actually was delivered to it by an authorized host, thereby checking the “path” the message
traveled. A message that originated from an unauthorized host, that is, one that is not specific in the
SPF DNS record, would be considered spoofed.
Contained within the SPF record is also policy information to instruct the receiving MTA on how to
dispose of the message. Today, most systems use SPF policy information to inform heuristics
(combined with reputation and other data) for filtering messages. In fact, systems can use SPF
information to improve existing reputation data by aggregating over time the sending pattern of
specific hosts and domains. The policy information integrated into SPF protocol is simple, yet
allows receiving systems a way to gradually “turn up the heat” on fraudulent messages.
Today, however, policy is not directly enforced by receivers due to concerns about deployment
inconsistencies leading to unacceptable rates of false positives. There have been examples where a
company deployed SPF, but they did not adequately collect metrics for what the Internet was seeing
regarding the company’s email status and SPF pass/fail results. For example, a company may
publish SPF hard-fail too soon, not realizing that a large and important line of business, which
maintained a separate email infrastructure, was not accounted for. That line of business will
experience loss of email service when some ISPs obey the hard-fail policy and reject all nonvalidated SPF. This situation may result in a reputation loss for the company, and an embarrassing
retreat from their sender authentication effort.
Due to the implications of the ascribed example above, ISPs have been reluctant to apply SPF
policy, mainly because a company may indicate a fail policy without adequate testing, resulting in
valid messages being dropped if the ISP enforces the fail indicator. Therefore it is very important to
coordinate uniform deployment and to test thoroughly before moving from neutral (?all) or soft-fail
(~all) to hard-fail (-all).
For this reason, most ISPs will not obey SPF policy. They are correct in assuming that if a company
does not publish SPF correctly and email is rejected (as is the correct policy with hard fail), then
their customers will hold the ISP responsible for missing email. However, it is the goal of most
financial institutions to encourage ISPs to enforce fail policies in order to provide a mechanism to
block unauthorized messages from arriving at customer inboxes. Coordinated efforts to improve the
validation of successful deployments should lead to SPF policy enforcement that supports automatic
dropping for messages that fail authentication.
Publishing Considerations
Keep host IP address inventory and SPF records updated
Special attention must be paid to the inventory process for sending hosts, as well as the ongoing
process to track sending host IP address changes. A common mistake is having a sending host IP
address change that is not updated in the SPF record, effectively putting that host “outside” the list
of approved systems. This situation will cause email received from that host to fail an SPF check. It
is important to ensure that when third-party senders make a change to their host addresses, bring up
a new host, or shift sending responsibility from one host to another, they communicate the changes
well in advance so the SPF records can be modified and DNS given enough time to propagate
changes.
Publish on the correct DNS server
Since SPF lookups are conducted over the Internet, it is important to publish SPF records on DNS
servers that are authoritative for the domains on the Internet. These are not internal DNS servers.
Use sub-domains to help segmentation
For each sub-domain that has an A or MX record in DNS, there should be corresponding SPF
records. Sites with wildcarded A or MX records should have corresponding wildcarded SPF records
in the form:
* IN TXT "v=spf1 -all"
This strategy fits nicely with DKIM practices of creating separate key pairs and selectors for subdomains used by third-party senders and special campaigns.
Establish SPF records for non-sending domains
Companies may use only a handful of domains to send email, but they may also own several
“brand” domains for online web presence or marketing that never send email. Preemptively
establishing “null” SPF records for those domains will prevent fraudsters from flying under the
radar by using them to send unauthorized spoofed email. For example, consider the following the
SPF record:
“v=spf1 –all”
This record indicates that the domain does not send any email, and any email received will be
fraudulent. Companies should also be sure to include third-party domain considerations as
appropriate.
Includes are useful, but be careful when using them
The SPF specification allows for the inclusion of another domain’s SPF TXT as a way of chaining
authoritative responsibility. While this can be a helpful administrative shortcut, it is important to
ensure the domain that is being included is set up correctly.
For example, SPF lookups that cause more than ten DNS requests violate the SPF specification.
SPF adopters should ensure their SPF records, especially with the recursion that occurs with the use
of “include” mechanism, do not require more than ten DNS requests as per the SPF RFC.
Do not publish hard fail too soon
It is important to establish SPF, test using neutral records, and then analyze traffic to determine if
there are any authorized hosts that are sending email that are not included in the SPF record.
Publishing hard fail indicates that it is acceptable for a receiving MTA to take an aggressive approach
to mail that fails an SPF check, including deleting the offending messages.
Publish SPF records for HELO names
The HELO command is used as part of the SMTP process. SPF lookups are performed on the
HELO domain name used in the HELO command by the Message Transfer Agent (MTA) sending
the email, in addition to SPF lookups on the email sender’s domain name. The HELO domain
names should be identified and SPF records published.
SPF syntax components are referred to as “mechanisms.” For a comprehensive description of the
syntax, refer to OpenSPF.org’s mechanism discussion. For each domain/sub-domain entity that will
have an SPF record, all mechanisms of the syntax must be defined and tracked as the company
implements SPF form test phase, through neutral and soft-fail policy, and finally to hard-fail (if
appropriate):
-
-
Policy: “+” (Pass) | “-“(Fail) | “~” (SoftFail) | “?” (Neutral)
all: The mechanism that indicates set of email (all is default and only choice).
ip: IP4 or IP6, depending on IP addressing numbering used for indicating host
addresses. May be single addresses or address ranges.
a: All the A records for domain are tested. If the client IP is found among them, this
mechanism matches. If domain is not specified, the current-domains used. The A
records have to match the client IP exactly, unless a prefix-length is provided, in which
case each IP address returned by the A lookup will be expanded to its corresponding
CIDR prefix, and the client IP will be sought within that subnet.
mx: Denotes the MX record for specified domain should be used, also can be used in
the form mx/24 where /24 denotes adjacent address range of potential sending hosts.
Other mechanisms that should be avoided, or will be used more rarely, include "ptr:", "exists:",
"include=", and modifiers such as redirect and exp=.
The Forwarding Issue
One of the more controversial aspects of SPF concerns forwarded mail. Some mail systems, most
notably list servers, will sometimes change header information and indicate that they are sending
mail on behalf of the original envelope sender. When this happens, this receiving MTA will perform
the SPF check and fail the authentication on the technical grounds that the “new” sending MTA is
not authoritative for the domain.
This will also be a common occurrence with those who set up forwarding or redirecting from a
“parked” email account such as a university alumni email system. For example, a graduate of MIT
will be allowed an alum.mit.edu email address. Many people will keep that email address and set their
mail settings at MIT to simply forward any mail delivered to their current “live” email address.
When a message is sent to them, it is sent first to MIT, which then re-delivers it (and takes
responsibility for sending it) and causes an SPF check to fail at the receiving MTA.
Over time, system administrators will increasingly update their MTAs to switch from forwarding,
where the envelope sender headers are preserved, to re-mailing. This switch requires changing the
envelope sender to that of the forwarding system (which will publish its own SPF records).
In the meantime, ISPs should take into consideration the major systems that serve as forwarders and
whitelist them. Additionally, senders (such as financial institutions) should carefully monitor test
email corpi for messages that fail due to forwarding issues.
Considerations for the Joint Use of SPF and DKIM
Companies that decide to implement both SPF and DKIM will find many areas of overlap in the
organizational preparations that must occur. Areas such as domain inventory, communication with
all relevant groups, and dealing with third-party senders, apply to both DKIM and SPF. However,
the technical implementation of each is unique and must be approached appropriately given that
protocol’s specific requirements.
Implementation tradeoffs
Each protocol provides its own set of benefits and drawbacks. With SPF, companies will have to
manage the message forwarding issue and risk of false positives from mailing lists and other
forwarders. With DKIM, companies will have to monitor for problems with MTAs, such as
“leaking” messages (i.e., the MTA is not signing all its messages). In either case, there is the potential
for false positives and possibly for false negatives.
Combined DKIM/SPF use benefits
Companies that use both SPF and DKIM can mitigate many of the perils inherent in using either
protocol alone. For example, messages from a leaking MTA that “breaks” the DKIM authentication
process for those messages can still be authenticated via SPF, assuming the SPF record has been
appropriately published. Likewise, a forwarded message that fails SPF authentication can still be
appropriately authenticated using DKIM. The combined use of the two protocols reduces the
number of false positives and can increase the receiving network’s confidence in authentication, to
the point of being willing to start blocking messages that fail both authentication processes.
Note that for these benefits to accrue, the receiving network must approve messages that pass either
DKIM or SPF (or both), and only fail a message if it fails both authentication processes. The
experiences of companies and ISPs who have begun to implement both protocols suggest that this
strategy is likely to result in the least number of errors. This approach also enables companies to
work more flexibly with third-party senders, who need implement only one of the two protocols to
be able to send messages (although third-party senders should ultimately support both protocols). In
addition, this strategy enables companies to have their messages authenticated at ISPs that only
support one of the two protocols, as ISP support of both protocols is not currently available in
many cases. ISPs today have not yet implemented blocking/failure based on authentication results.
Some improved policy capabilities may be required at ISPs to support the most beneficial dual
failure model for companies.
While the recommendation of this paper is for companies to implement both protocols (DKIM and
SPF), it is recognized that some companies may have limited resources for this initiative and must
decide what protocol to implement first. In that case, the company should take into account several
tradeoffs for the implementation of each in its decision. In some cases, implementing DKIM first
makes sense as it avoids a number of false positive risks associated with SPF and thus ensures the
highest rate of accuracy for authentication. However, it should be noted that DKIM is operationally
more complex to implement than SPF and thus the company’s technical expertise and available
resources should be taken into consideration. DKIM requires a much broader range of testing than
SPF, since SPF only requires DNS testing, and DKIM can have a high false positive rate if messages
are not being signed correctly. Please see a summary of these issues in the following table.
In addition, companies considering implementation should review the current relative levels of
support for DKIM and SPF by the ISPs that are most represented in their customer base.
DKIM Only
SPF Only
Combined DKIM and SPF
•
Advantages
Supported by major ISPs
• (excluding Microsoft)
• Signature stays with
message over
• multiple hops
• • Validates message
content as well as path
• Only requires DNSbased testing; no
additional software
required
• All advantages of DKIM
Only
• implementation
• Minimizes false positive
rate
Disadvantages
• Operationally complex to
implement and test
• False positive risk due to
message signing errors or
leakage
•
•
• Increased false positive
risk due to path-based
authentication breaking
on message forwarding
Requires additional
resources to implement
both protocols
Advantages
• (assuming receiver
network
• requires only one
protocol to pass)
Disadvantages
Metrics and Reporting
For effective deployment and use of authentication, it is important to gather data on authentication
results and email disposition outcomes. Today, however, there are fundamental limitations to the
data available, so it is important to leverage those capabilities that are possible.
Signing Validity
Companies may use test accounts to determine the validity of SPF and DKIM signing. End-user test
accounts can be set up across multiple ISP systems to establish a view into how those ISPs are
presenting the messages.
Evaluating outcomes
•
•
•
•
It is generally recommended that at least two test accounts are set up at each ISP.
In most cases, the validity of the DKIM check can be determined by examination of the
message header (this is difficult to automate because each ISP uses a different designation).
In some cases, it is possible to infer the overall disposition of a message based on the
heuristics scoring for the ISPs email hygiene process (approximation based on reputation).
Trends can be created and analyzed over time to approximate the efficacy of authentication
for messages delivered to the ISP that is hosting the test account.
Drawbacks
•
•
•
•
•
•
Using test accounts will not result in complete coverage of the company’s sending universe
as it will not be possible to cover every possible receiver; corporate accounts, in particular,
will not allow test accounts.
Every ISP system is different and can change without notice. Since this is a manual
procedure, it requires a great deal of administration to maintain test accounts across multiple
ISPs with email messages going in from multiple systems and third parties.
ISPs may drop messages for reasons unrelated to the authentication protocols, so it is
difficult to know what happened to messages that do not appear in the test accounts. Where
possible, it is recommended that the receiving networks whitelist the senders in order to
avoid these issues to minimize false positive risk.
It is also administratively difficult to have third-party senders routinely send email into test
accounts for analysis.
There is no way to detect non-participating third-party or internal systems.
Without special relationships with the ISP or with third-party data providers, it can be
difficult to know what happened to messages at the ISP. Overall, this procedure is
recommended today as the best available approach, but it is manually labor intensive,
difficult to automate, and frequently subject to change.
Gathering Spoofing Data
Data on the origins of spoof traffic is contained in the SMTP interactions and email messages from
senders. Today there are a several post-facto methods of gathering information:
•
•
•
Analysis of customer feedback: Some customers who receive suspicious emails forward
them to relevant support addresses at institutions or ISPs. Companies may wish to create an
abuse mailbox (for example, [email protected]) for the receipt of emails. These
emails can be processed for data on phishing sites, spoofing domains and IPs, and some
information on internal systems that are not sending email correctly. This method is
disadvantageous as a primary source of data since it allows spoof traffic to reach endrecipients prior to detection, and relies on end-recipients’ ability to identify suspicious traffic
and their reliability in reporting it accurately.
Honeypots: Honeypots can be established to draw phishing and spoofing traffic for
detection.
Third-party data phishing services: A number of third-party services collate data from
various sources to detect phishing traffic across the Internet.
All of these methods detect spoofing after it has occurred at some destinations, but it is
recommended that institutions support all of them.
Desirable Future Data
For accurate, timely, granular analysis of authentication and delivery, the following additional data
from receivers is desirable.
• Number of messages that arrived at each ISP/receiver for specified domains
• Number of messages that are unauthorized spoof for specified domains
• Origin of unauthorized spoof messages
• Breakdown of messages from authorized sources and their origins
• Percentage representation of the disposition of messages in each group for each specified
domain (what happened to the messages)
• For messages that fail authentication, granular results (why were they classified that way)
• Consistent and normalized standards and statistical presentation across ISPs/receivers
Technical Implementation of DMARC
DMARC Overview
To address the direct domain phishing and spoofing problem successfully, senders and ISPs need to
share information about what email is being authenticated and how the sender wants
unauthenticated email handled. DMARC (Domain-based Message Authentication, Reporting and
Conformance) allows senders to tell ISPs how they would prefer them to handle messages that do
not properly authenticate. It also allows ISPs to supply senders with information about the health of
their email authentication deployment. DMARC makes it possible for ISPs to use DKIM and/or
SPF to:
• Separate legitimate and fraudulent email
• Act appropriately on what they have found
• Report to senders on the effectiveness of their email authentication efforts, thereby
• Increasing the percentage of email that is authenticated and can be properly separated
The DMARC standard was developed by a group consisting of leading ISPs, financial institutions
and other high-profile senders, email service providers (ESPs), as well as Return Path and Agari with
the intent of building upon earlier work by Yahoo! Mail, Gmail and PayPal. The DMARC standard:
• Tells the ISPs, via a DNS record, what the sender wants done with any non-authenticated
email from their domains (monitor, quarantine, reject), eliminating ISP guesswork
• Provides ISPs with a standardized way to report to senders on authenticated and
unauthenticated emails purporting to be coming from the sender’s domains
How DMARC Works: An Overview
At the heart of DMARC is a new type of text resource record that the sender adds to its DNS
record. This record specifies the sender’s email authentication enforcement policies, including:
• What the ISP should do with non-authenticated mail from the domain (monitor, quarantine,
reject)
• Whether the process of matching the domain name to the sender name under SPF and/or
DKIM should be handled in a strict or relaxed way.
• An optional “percent” tag which indicates the maximum percent of mail from the domain
that the policy should be applied to (this allows senders to test and monitor the results of
applying the policy)
• The sender’s URI or URIs to which ISPs can send aggregate and forensic reporting data so
that senders can monitor and improve their email authentication deployment.
Typically, the sender will start by setting a policy of “monitor” so that they can assess the
performance of their email infrastructure. As the sender gains confidence that their entire
mailstream is authenticated, they can move their policy from “monitor” to “quarantine” (sending
email to users’ junk or bulk mail folders) and then to “reject” (blocking all unauthenticated mail).
The end goal for a sender that implements DMARC is to monitor their authentication results and
eventually authenticate their entire email stream, providing ability to implement a reject policy with
ISPs.
Anatomy of a DMARC Resource Record in the DNS3
DMARC policies are published in the DNS as text (TXT) resource records (RR) and announce what
an email receiver should do with non-aligned mail it receives.
3
Information in this section courtesy of DMARC (http://www.dmarc.org/overview.html).
Consider an example DMARC TXT RR for the domain “sender.dmarcdomain.com” that reads:
"v=DMARC1;p=reject;pct=100;rua=mailto:[email protected]"
In this example, the sender requests that the receiver outright reject all non-aligned messages and
send a report, in a specified aggregate format, about the rejections to a specified address. If the
sender was testing its configuration, it could replace “reject” with “quarantine” which would tell the
receiver they shouldn't necessarily reject the message, but consider quarantining it.
DMARC records follow the extensible “tag-value” syntax for DNS-based key records defined in
DKIM. The following chart illustrates some of the available tags:
Tag Name
v
pct
ruf
rua
p
sp
adkim
aspf
Purpose
Protocol version
Percentage of messages subjected to
filtering
Reporting URI for forensic reports
Reporting URI of aggregate reports
Policy for organizational domain
Policy for subdomains of the OD
Alignment mode for DKIM
Alignment mode for SPF
Sample
v=DMARC1
pct=20
ruf=mailto:[email protected]
rua=mailto:[email protected]
p=quarantine
sp=reject
adkim=s
aspf=r
Sender DMARC Implementation
Deploy DKIM and SPF
While not a requirement to begin using DMARC, a Domain Owner that wants to leverage DMARC
as a means to enforce blocking policies at ISPs should have already deployed and tested SPF and
DKIM. Simple deployment of a DMARC record can provide valuable insight into a company’s mail
streams and any server configuration issues.
Align Identifiers
Audit internal systems to ensure that mail received by ISPs will observe that all Authenticated
Identifiers (RFC5322.From domain and the SPF and DKIM domains) within messages are in
alignment. Senders can specify a "strict" or "relaxed" mode in terms of enforcing identifier checks.
In “strict” mode, all identifiers from authentication systems upon which DMARC is predicated must
match the RFC5322.From domain. In "relaxed" mode, the organizational domains must match.
The "relaxed" mode is the DMARC default.
Create a DMARC record and append to DNS
Publish a DMARC policy of “none” and include a feedback reporting email address to receive
aggregate feedback data from Mail Receivers. See sample record below.
_dmarc.senderdomain.com:
"v=DMARC1; p=none; rua=mailto:[email protected];
ruf=mailto:[email protected]; rf=afrf; pct=100“
Analyze the data and modify your mail streams as appropriate
Review and tune authentication deployments. Use the provided feedback data to remediate
unauthenticated email streams and correct identifier alignment issues. This is a good opportunity to
discover email that, for example, passes SPF checks but is missing DKIM signatures, since such
email will inevitably fail authentication when forwarded.
Modify your DMARC policy flags from “monitor” to “quarantine” to “reject” as you gain
experience
When confidence of authentication accuracy is gained, publish a DMARC policy of "quarantine"
with a reasonably small value for "pct". Debug false positives (due to missed unsigned mailstreams)
while gradually increasing the value of "pct" to 100. Fully secure mail streams. When "pct" reaches
100 with no observed ill effects, publish a DMARC policy of "reject" with a reasonably small value
for "pct". Repeat debugging and corrective process as necessary.
Appendix A
Resources
Authentication Guidelines for Financial Institutions
• BITS Email Security Toolkit: Protocols and Recommendations for Reducing the Risks (April, 2007):
http://www.bits.org/downloads/Publications%20Page/BITSSecureEmailFINALAPRIL1507.p
df
DomainKeys Identified Mail (DKIM) Information
• DKIM Overview: http://tools.ietf.org/html/draft-ietf-dkim-overview-10
• DKIM Signatures (RFC 4871): http://www.apps.ietf.org/rfc/rfc4871.html
• ADSP Draft Memo (Expired): http://www.dkim.org/specs/draft-ietf-dkim-ssp-04.html
Reflectors (Verifiers)
• DKIM.org: http://testing.dkim.org/reflector.html
• Sendmail: Send an email to [email protected] (supports DK, DKIM, SIDF and SPF)
• Port25: http://www.port25.com/domainkeys/
Sendmail
• Sendmail and DKIM: http://www.sendmail.org/dkim
• Eland’s Sendmail/DKIM Overview: http://www.elandsys.com/resources/sendmail/dkim.html
• Erik Berg’s Sendmail/DKIM/SIDF Overview: http://www.erikberg.com/notes/milters.html
Postfix
• Postfix MILTER support: http://www.postfix.org/MILTER_README.html
• DKIM with Postfix using dkimproxy:
http://anothersysadmin.wordpress.com/2008/01/16/domainkeysdkim-with-postfix/
Microsoft Exchange
• DKIM for IIS SMTP Service and Exchange Server:
http://www.emailarchitect.net/domainkeys/
• Exchange Server and SenderID:
http://technet.microsoft.com/enus/magazine/2006.12.sidf.aspx
Sender Policy Framework (SPF) Information
• SPF (RFC 4408): http://www.ietf.org/rfc/rfc4408.txt
• OpenSPF.org Syntax Discussion: http://www.openspf.org/SPF_Record_Syntax
• SPF Common Mistakes: http://www.openspf.org/FAQ/Common_mistakes
MTA Vendor Listings
• Online Trust Alliance (OTA) directory: https://otalliance.org/resources/2009OTADirect61HR.pdf
• DKIM.org’s vendor listing: http://www.dkim.org/deploy/
Industry Groups
•
•
•
•
•
BITS (a division of the Financial Services Roundtable): http://www.bits.org
The Financial Services Roundtable: http://www.fsround.org
Messaging Anti-Abuse Working Group (MAAWG): http://www.maawg.org
Anti-Phishing Working Group (APWG): http://www.antiphishing.org
Online Trust Alliance (OTA): https://otalliance.org/resources/authentication/index.html
Appendix B
Agari and Return Path Partnerships for Email Authentication
Agari and Return Path are proud to partner with BITS to produce the “Email Authentication Policy
and Deployment Strategy for Financial Services Firms.” The goal of this paper is to educate security
personnel at financial services firms on the best ways to authenticate their outbound email traffic to
prevent phishing attacks.
Agari is an innovator in email security and DMARC
compliance, providing protection to the world’s most trusted
brands. By collecting terabytes of email data from sources
across the Internet to create a hosted, cloud-based solution,
Agari offers the highest level of security against phishing and
other email fraud. Agari blocks over 4 million malicious
emails and identifies more than 40,000 malicious URLS every
day on behalf of the brands it has been entrusted to guard.
Agari ensures that the only emails that your customers receive
are the ones you send.
As an FS-ISAC or BITS member, Agari provides you with a
number of complimentary services, access to our staff of
email security experts and exclusive discounts on our Trusted
Registry service:
Instant Online Domain Analysis
Are your domains secure? Use Agari’s online domain analyzer
to assess domain vulnerability and standards-based
compliance
Schedule an Assessment
Are your customers exposed? Schedule a risk assessment with
an Agari expert to measure email channel vulnerability and
learn how to better protect your customers from email
threats.
Test Drive Agari Today
With Agari technology and expert guidance, you’ll have
the analytics and controls needed to properly protect
your brand and customers.
Learn more about Agari and its partnership with FS-ISAC
and BITS: http://agari.com/trustedregistry
Return Path is worldwide leader in email intelligence. We
analyze more data about email than anyone else in the world
and use that data to power products that ensure the safety
and security of the inbox. Our anti-phishing solution,
Domain Secure, proactively protects financial services
organizations and their customers against fraudulent email
activity. By blocking phishing and spoofing attacks before
they ever reach your customers’ inbox, Domain Secure places
trust back in the email channel.
Return Path is also proud to be part of the Trusted Email
Registry. As a member of BITS / FS-ISAC, you are entitled
to the following Return Path services, free of charge:
• Complimentary 90 Day Access to Domain Secure Includes technical support.
• Complimentary Email Authentication Scorecard –
Using data sources from over 70 ISP partners and 2+ billion
mailboxes worldwide, we prepare a custom scorecard with a
prioritized action list to improve your email security.
• Complimentary Inbox Placement and Email
Reputation Audit Across Your Network - In depth review
of whether email is being delivered across Return Path’s ISP
network and if there are any reputation issues (end-user
complaints, spam trap hits, high unknown user rates, low end
user engagement and other factors).
• Complimentary Fraudcasting Feeds – URLs and IP
addresses used in phishing attacks are automatically submitted
to security vendor partners providing the broadest protection
against emerging attacks.
Learn more about Return Path:
http://www.returnpath.com/solution-content/domainsecure/financial-services/
Appendix C
Acknowledgements
BITS would like to thank the following contributors to this paper.
Keith Gordon, Bank of America
Steven Jones, Bank of America
Jeff Laughton, Bank of America
Robert Reh, Nassau Financial
Alex Popowycz, Fidelity Investments
Jim Routh, JPMorgan Chase & Co.
Victor Talamo, JPMorgan Chase & Co.
David Johnson, U.S. Bancorp
Jim Pearsall, U.S. Bancorp
We would also like to thank the following individual for coordinating this effort:
Andrew Kennedy, BITS/Financial Service Roundtable
Tim Draegen, BITS Liaison to DMARC
Ann Brennan-Hecht, Agari
Mike Jones, Agari
Jesse McCabe, Return Path
Ken Takahashi, Return Path