1 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)
2 Table of Contents Executive Summary... 4 Background... 5 Historical Perspective on Security... 5 Emergence of DKIM and SPF... 5 Moving from Reactive to Proactive Security... 6 Introduction of DMARC... 6 Case Study for Authentication... 8 Very Large Bank... 9 Success Implementation Approach Five Phases of Deployment Business and Process Considerations Identifying and Engaging Stakeholders Business Units Enumerated Need Details Policies Implementing the Technology Recommendations Measuring Effectiveness Metrics BITS Trusted Registry Responding to External Threats: Investigations and Takedowns DKIM and SPF Implementation Guide What Is Authentication And Why Is It Important? How Does Authentication Work? General Considerations for Authentication Deployment Organizational Disciplines Departmental Organization and Participation Political Issues and Policy Determination Architectural and Technical Considerations Third-Party Senders... 31
3 Remote Employees Domain Segmentation Protecting Brand Domains That Do Not Send DomainKeys Identified Mail (DKIM) Implementation High-level Technical and Functional Overview Signing Versus Verifying Technical Implementation and Best Practices Sender Policy Framework (SPF) Implementation High-level Technical and Functional Overview Publishing Considerations The Forwarding Issue Considerations for the Joint Use of SPF and DKIM Implementation tradeoffs Combined DKIM/SPF use benefits Metrics and Reporting Signing Validity Gathering Spoofing Data Desirable Future Data Technical Implementation of DMARC DMARC Overview How DMARC Works: An Overview Anatomy of a DMARC Resource Record in the DNS Sender DMARC Implementation Appendix A Resources Appendix B Agari and Return Path Partnerships for Authentication Appendix C Acknowledgements... 54
4 Executive Summary The BITS 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 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), Service Providers (ESPs), and others to reduce the rampant spoofing of 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 security solutions. is a critical communications channel for business today. Fraudsters, criminals, and others have learned how to create messages that appear to come from another sender. Brands are regularly and effectively abused by criminals who impersonate, or spoof, addresses and Internet domains of financial services and other companies. In a practice known as phishing, spoofed 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 addresses and Internet domains of financial services and other companies. security has been a challenge, especially when considering the original usage of the technology and the lack of security controls when was first created in 1971 to allow researchers to collaborate over the Advanced Research Projects Agency Network (ARPANET). At the time, security was not a priority because communications occurred among a closed group of people over a trusted network. Today, 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 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 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 Enhanced brand and reducing the exposure of customers to phishing attacks that could lead to fraud or malware infection.
5 Background As 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 Registry 1 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 Security security has been a challenge, especially when considering the original usage of the technology. Modern 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, security was not a priority because communications occurred among a closed group of people over a trusted network. Today, 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 authentication, ISPs are unable to reliably determine the legitimacy of . Pranksters, criminals, and others have learned how to create messages that appear to come from another sender. In a practice known as phishing, spoofed 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 addresses began in earnest in the early 2000s and resulted in the development of the Sender Policy Framework (SPF) in SPF provides a method 1 The BITS Trusted Registry provides complimentary domain-specific reports to our member companies that will help an institution strengthen the security of its channel and reduce enterprise and consumer risks.. Information is available at
6 that allows domain owners to publish lists of servers authorized to send s on behalf of their domains, granting receivers the ability to check s 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 security, the effectiveness of these authentication efforts is limited due to a lack of visibility as to who is sending on behalf of an organization and the lack of active policy enforcement to ensure receiving service providers, such as Google and Yahoo, are rejecting or quarantining suspicious messages. Figure 2 Merged Feedback Version With authentication, ISPs can begin to determine the legitimacy of and reduce the volume of delivered fraudulent . 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 . Unfortunately, most of the damage of a phishing campaign is inflicted in the first few hours of an attack when 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 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 Registry, provide organizations with Internet-wide visibility into both legitimate and malicious usage of an organization s domains, as well as the ability to direct receivers of s to enforce quarantine or reject policies against malicious messages. The DMARC
7 specification leverages the established technologies of SPF and DKIM and provides a foundation for building complete end-to-end 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 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 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 . The Trusted 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.
8 Case Study for Authentication In April of 2007, the BITS Security Working Group created a whitepaper titled BITS 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 to conduct business. Although the paper s core recommendations and observations remain relevant today, the 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 s weaknesses causing the amount of spam and phishing to dramatically increase. The Gartner Group reports a 700% increase in -based phishing between , 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 . In a 2010 Identity Theft Resource Center survey, 81% of consumer respondents cited phishing s as a significant concern relating to the security of their personal and financial information when conducting online transactions. 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 messages and online shopping as a result of this continuing threat (see Figure 5).
9 Figure 5 Security concerns have affected behaviors, Gartner Group. Traditionally, authentication has been an unreliable method of determining 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 authentication technologies when evaluating 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.
10 Data for the initial business case was based on an early estimate of 600,000 annual s 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 s, forcing customers and potential customers to determine which 20% (1 in 5) of the s purporting to be VLB were fraudulent. The large volume of unauthorized competed with legitimate VLB for consumers attention and caused significant brand erosion as consumers lost confidence in the channel. To meet business case requirements, the VLB project sought to meet three specific objectives: Improve the customer s experience by eliminating fraudulent and resulting phishing and malware attacks Lower customer service call volume attributed to phishing attacks Enhance the VLB brand by improving campaign results Eliminating fraudulent required enabling receivers with a way to easily identify legitimate VLB by implementing SPF and DKIM across all legitimate streams. Discovering the sources of all legitimate 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 , employ third-party Service Providers (ESPs) to send on behalf of the business, or partner with small consulting or marketing operations that send on behalf of the business. The VLB project team leveraged vendor-provided intelligence to identify the sources of all 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 , individuals sending 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 to customers and prospects. During the process of installing controls to eliminate fraudulent , the project team contacted ISPs and asked them to only deliver that originated from an authenticated VLB domain. Based on this action, the project team identified several third parties that sent low volumes of legitimate 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 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 purporting to be from VLB-owned domains that failed authentication checks.
11 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 . The DMARC specification, published in January 2012, standardizes the SPF, DKIM, and policy deployment model implemented by the VLB project team during Success As of late 2012, VLB has eliminated close to 90% of fraudulent 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 -based brand protection by measuring the potential lift in response rates due to fraud reduction. The elimination of fraudulent 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 Registry. VLB s project required an active internal communication program to reach and work with the diverse service providers that originated 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 Controls.
12 Implementation Approach To implement controls based on 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 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 domains, streams, and types. The domain inventory includes all domains actively sending as well as inactive domains registered for defensive or brand protection purposes. Active domains can contain multiple streams originating from different groups or vendors. streams can contain different types of messages (e.g., transactional, corporate, marketing). Domains, streams, and 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 Registry can augment in-house research and reduce the cost of discovering streams. Detect: The Detect phase compares and contrasts real-world data against the organization s stated authentication implementation strategy. The result of this analysis directly informs the next phase. Remediate: The Remediate phase aims to resolve any 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 .
13 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 on behalf of the organization, allowing only legitimate 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 servers, and changes to DKIM signatures and SPF records. An organization can begin implementing 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 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.
14 Business and Process Considerations Identifying and Engaging Stakeholders Technical and business groups within a company must incorporate 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 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 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. 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 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 authentication. Marketing groups may find significant value in monitoring the general health of their channels through feedback mechanisms such as provided by DMARC and the Trusted Registry. As a brand-strengthening activity, organizations often seek to communicate directly with customers regarding improvements to 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 authentication across the organization, and serve as a clearinghouse for internal education. Customer Service Customer service teams are important stakeholders in any 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 security measures to customers. This function is critical during periods when authentication is being introduced, especially as established practices may unexpectedly break during a transition period. For example, customer use of alumni or affiliate addresses may cause to be blocked due to strict blocking policies and poor forwarding implementations. Frontline customer services teams should
15 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. Engineering / Operations engineering is responsible for the deployment and operation of infrastructure operated within an organization. Responsibilities include operation of externally facing Message Transfer Agents (MTAs), internal servers (such as Microsoft s Exchange), and other related systems within the traffic flow. This function may be responsible for monitoring and managing externally hosted service providers, including fully outsourced employee (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, 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 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) as well as marketing and other external communications. Vendor contracts should contain language requiring support for the organization s 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 authentication protocols, especially DMARC, an important source of intelligence related to investigating fraudulent activity. Phishing and other -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.
16 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 security and authentication. Marketing/Brand Mgmt Customer Service Operations Infrastructure IT Risk & Compliance Vendor Management Fraud / Investigations Security Operations 1 General Awareness - Inside 2 Awareness Material - Customer 3 Implementation Strategy 4 Technical Deployment Details 5 Security Metrics / Reports 6 Operational Documentation 7 Data Taxonomy 8 Training 9 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 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 security provides to both financial institutions and their customers are significant. Vendor Engagement: Develop plans to deploy 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 Security: Develop talking points and customer FAQs related to the deployment of security which may be shared with customers and clients.
17 Security Metrics: Partner with appropriate IT and/or risk staff to develop security metrics defining the health of the channel which will assist in better managing that resource. Customer Service Awareness: The implementation activities around security that may change the customer experience (e.g. my forwarded s are being blocked ). Training: How to answer customer questions regarding how to determine if an is legitimate. This may include training on the mechanisms deployed at major ISPs which may leverage authentication (e.g., new User Interface (UI) indicators). Engineering / Operations Inclusion in Planning: engineering should be included at the outset in any planning and deployment of authentication mechanisms. engineering provides expertise as to the capabilities of various platforms used in relation to authentication, both inbound and outbound. Awareness: Raise awareness of business objectives related to authentication. Providing business context can help 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). engineering should be provided with access to tools to fulfill this responsibility. Service Management: Develop Service Level Agreements (SLAs) for making platform changes in support of authentication, including business changes and tactical changes addressing operational criteria and incidents. Network / DNS Engineering Domain Identification: Understand and document domain(s) subject to authentication. Service Management: Service Levels for DNS-related changes for 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 authentication reports and response actions to address identified issues. Vendor Management Vendor Identification: Maintain an inventory of all vendors which may provide services directly (marketing companies) or supplemental to their core services (e.g. CRM, customer services, benefits, etc).
18 Vendor Communication: Document and convey to identified vendors expected best practices to develop and maintain high levels of reputation to support deployed authentication mechanisms. Service Management: Develop and incorporate into business agreements expected Service Level Agreements (SLAs) for important actions supporting 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 authentication reporting relevant to any given vendor. Fraud/Investigations Reporting: Access to regular and ad-hoc reporting capabilities, if available, related to authentication results. Training: Training on the interpretation of provided reporting. Training on tools, both internally developed and sourced as services, supporting the security program. Security Operations Reporting: Access to regular and ad-hoc reporting capabilities, if available, related to authentication results. Training: Training on the interpretation of provided reporting. Training on tools, both internally developed and sourced as services, supporting the security program. Identification of Traffic Patterns: Profiles of normal activity by source including volumes. Vendor Interaction: Operational contact information with sending vendors. Work with other security service providers, including integration of authentication data with phishing mitigation providers. Policies Successful 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 authentication while minimizing organizational friction. This section briefly touches on areas of governing policies to situate the additional policies needed to support authentication. Correspondence Versus Transactional When the Internet was first opened to commercial use, companies commonly created one domain and used it for all communications business correspondence, customer communications, transactional , etc. Companies largely continue to operate this way today, and often establish separate domains or sub-domains to separate general correspondence from transactional .
19 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 domains, and can vary greatly from company to company. Consistent From Addresses The sending address and name shown on 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 sending addresses. Two different parts of the From line should be considered the address itself and the display name (often called the friendly from ). An example of an address is 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 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 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 content policy is the use of domain names in the hyperlinks and graphical elements within the body. containing links pointing to several different domains can lead to the classification of such as spam. Ideally, all elements of an will
20 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 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 on their behalf. Contracts with such entities should include provisions requiring third parties to implement any requisite authentication measures and to provide updates on operational matters that may impact any of these measures or delivery. For example, if an ESP begins sending for a company from a different IP address without notification, 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 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