The world’s first Email Authentication as a ServiceTM

www.valimail.cominfo@valimail.com367 14th Avenue, San Francisco, CA 94118

The world’s first Email Authentication as a ServiceTM

The Challenges and Promise of Email AuthenticationA White Paper for CISOs, IT Executives, and Messaging Teams

Email is Alive and Growing

Email still dominates our commercial communications. It accounts for the vast percentage of ecommerce conversations, is still growing at 6% annually (to 4.9 billion consumer mailboxes by 2017), and 80%+ of consumers sign up for email programs on websites. Some quick stats1 show just how effective a commercial communication channel email is:

• Large: 80 Billion consumer emails/day, 91% check email daily• Growing: 3.9 Billion active email boxes è 4.9 Billion by 2017• Preferred: 74% consumers prefer email for commercial communications• Popular: 82% of consumers sign up for email programs on websites

EMAIL IS HIGHLY EFFECTIVE:

• High open rates: 82% of consumers open marketing email• Effective: 66% of consumers buy online due to email• Efficient: Email marketing has an ROI of 4,300%

The Plague of Email Attacks: Brand, Channel, and Consumer Abuse

Yet email is also under increasing attack by cybercriminals eager to leverage its emails’ success. Email was involved in every major cyberattack in 2014 and 20152, and 84% of all email is spam or phishing attempts3. Of the 60 billion spam/phish emails, over 100 million malicious emails get through even the most sophisticated email providers’ filters, with a 1 in 10 chance of infecting a consumer4. Put another way, 10 million consumers are affected by email attacks every day. These attacks cost brands over $70 billion/year, averaging $1,950/phishing attack5.

2

Worse, email attacks overwhelmingly involve cyber criminals impersonating brands to trick consumers into opening the fake email and launching the attack. These domain email attacks have mushroomed, involving 60K domains/quarter in 2014 alone6.

• Email played a role in nearly EVERY major cyberattack in 2014 and 2015

• 84% of all email is spam/phish

• Each attack = many thousands of messages

• 100 million phishing messages get through every day

• Costs brands $70Bn/yr, ~$1,950/phishing attack

These email domain attacks don’t just dupe con-sumers into revealing personal information, they also directly affect consumers’ trust in a brand and erode their willingness to do any further busi-ness, despite the fact the brand had nothing to do with the attack.

All it takes is one attack on your brand, and your loyal consumer base can be decimated. In a recent report, Cloudmark reported that “42% of

consumers <are> less likely to do business <with your brand> following an email attack.” Forrester Research’s 2015 Predictions reports that “protect-ing your online consumer” should be a major fo-cus for any company hoping to sell to consumers.

Enter DMARC: Effective Employee, Brand, & Consumer Protection

Fortunately, a new standards-based approach is now available that can eliminate the vast majority of such attacks. DMARC (Domain-based Mes-sage Authentication, Reporting & Conformance) is a new technical specification adopted by the major consumer mailbox providers (Gmail, AOL, Microsoft, Yahoo!, Comcast, etc.) that effective-ly stops unauthorized email uses of a domain, thwarting the majority of email domain attacks.

Major brands have already implemented DMARC and have seen complete elimination or highly sig-nificant reduction in attacks. In recent case stud-ies published by companies having implemented DMARC, most report an 80-95% reduction in phishing attacks on their consumers7.

70% drop in suspicious email

25M phish blocked over 2 months period

5,000% drop in phish once DMARC-enabled

Immediately blocked

100M phish/day

DMARC is Effective

Source Agari

3

Large-scale email receivers, such as Google, Microsoft, and Yahoo!, are increasingly requiring that email messages be properly authenticated in a DMARC-compliant way8. So adding a DMARC record for a domain, in conjunction with properly configured SPF and/or DKIM re-cords, will help ensure proper delivery to recipi-ents using these services.

Furthermore, the proper use of DMARC en-sures that messages sent by spammers using a sender’s domain will not negatively impact the domain’s overall reputation. Such spam will be blocked and the sender’s brand will be protected.

DMARC works by enforcing existing authentication protocols that have lain nearly dormant for over a decade: SPF & DKIM.

Sender Policy Framework (SPF) is a protocol by which the owners of a domain can define a set of rules in the Domain Name System (DNS) designating which mail servers can deliver emails originating from that domain. Receiving mail servers evaluate those rules and, based on the IP address of the delivering server, determine whether the message in question is allowed to originate from that domain.

DomainKeys Identified Mail (DKIM) is a cryp-tographic signing protocol by which email can be authenticated as originating from a particular DNS domain. It’s a powerful technique for authenticat-ing email that may be relayed through any number of intermediate mail servers between its origin and destination.

DMARC uses both SPF and DKIM to authenticate email messages, with some additional authentica-tion requirements that guarantee a higher level of brand and consumer protection.

A domain owner can specify, via DMARC, how a receiver should handle an email that fails authenti-cation. A reporting mechanism, enabling domains to capture aggregate and individual information about failures for subsequent analysis, is also part of the standard, giving domain owners far more data about what’s going on with inbound and outbound emails.

The ability for a domain owner to state a policy in a standardized and internetscale way has allowed DMARC to explode in popularity, with over 2.5 billion consumer mailboxes covered by DMARC globally (80% of US consumer mailboxes)9.

4

The Unfortunate Complexity of DMARC

Despite the promise and effectiveness of DMARC, it has mostly remained a solution for specialized, global enterprises with large, dedicated Infosec organizations. The principal reasons for the limit-ed rollout include a lack of awareness (the stan-dard is only 3 years old) and the fact that current limitations of the authentication standards require dedicated resources and sustained focus to implement. These facts limited awareness and significant limitations in the standards make DMARC both an intensely resource-consuming and expensive proposition.

Even outsourcing to traditional DMARC vendors is challenging and limited to mostly large enterpris-es, with DMARC solutions currently on the market requiring large amounts of constant interactions with messaging teams, and requiring significant outlays of capital. The main source of complexity in DMARC implementations is the configuration of SPF and/or DKIM. Both of these standards are over a decade old, and each is highly complex. Moreover, each standard requires expert knowl-edge to configure properly and has unique pitfalls. All of the configuration changes require changes to a domain owner’s DNS, further complicating the process. Finally, these configurations are not static they constantly change as the company’s use of email evolves.

The end result is that many companies, even some with extensive experience with emailsystems, have misconfigured SPF and DKIM im-plementations. Our authentication checker andextensive experience has shown that fully 90%

of all domains have authentication errors. Correctly configuring and aligning SPF and DKIM is a multi-week/month and dedicated resource effort, which most companies cannot or do not want to spend capital on.

In the following pages, we’ll explain some of the complexities of SPF and DKIM.

SPF

First introduced as a standard in 2003, Sender Policy Framework (SPF) is an important if oftenneglected piece of today’s email infrastructure. Sender Policy Framework (SPF) is an open,DNS-based email authentication system that allows sending domains to define which IP addresses are allowed to deliver email to receiving mail servers on behalf of the domain. Unfortunately it is not always correctly implement-ed, due to common misunderstandings of the protocol’s limitations.

Until recently the cost of misconfiguring SPF was relatively minor. Email receivers did not weigh SPF heavily in determining whether an email would be delivered to the recipient, or potentially classified as spam. But with the widespread adoption of DMARC and a newfound focus on phishing by Internet Service Providers (ISPs), this situation has changed dramatically. SPF authentication can be crucial to ensuring that an email message is deliv-ered and so the cost of a misconfiguration can be very high.

However, SPF configuration is a challenge for many organizations. Let’s look at some of thereasons why that is the case.

5

Common SPF Pitfalls

THE DREADED 10 LOOKUP LIMIT

As part of evaluating whether an email message passes SPF authentication, a receiving mail server may have to make one or more DNS lookups. Typical situations where such a lookup might be required include:

• When evaluating an ‘include’ directive to pull in the SPF rule defined on another domain

• When checking an IP address against an ‘a’, ‘mx’, or ‘ptr’ directive—which require a A, MX, or PTR DNS lookup respectively to evaluate

To protect receiving mail servers from denial of service attacks the SPF standard includes a hard limit on the number of domain lookups such a server is permitted to make when evaluating whether an email message passes SPF. That limit is 10 lookups. Any additional lookups will result in the email message failing SPF.

In practice this limitation is a more significant restriction than it may first appear. Cloud-based services typically require their customers to add an ‘include’ directive to the SPF record to authen-ticate email sent by the service. This ‘include’ directive frequently refers to SPF records that themselves have ‘include’ directives, so including a single service may contribute 2, 3, or more look-ups to the overall count. This means that a cus-tomer using only a few services can easily exceed the SPF domain lookup limit.

HOSTED EMAIL ADDS COMPLEXITY

While some large organizations still host their own mail servers, smaller organizations have mostly

migrated to external services (e.g. Google Apps, Office 365) for mailbox hosting. As web services have become a more accepted feature of the landscape, even these larger organizations have outsourced management of their primary email.

PROLIFERATION OF CLOUD-BASEDSERVICES SENDING EMAIL

Another key change that has occurred over the last decade is the widespread dissemination ofresponsibility for sending email for a domain. At one time it was reasonable to assume that all ofthe email sent under a domain originated from one IT infrastructure. In today’s cloud-centric world this is no longer a realistic expectation. A com-pany may use any number of services—bulk mail systems, transactional email, content manage-ment systems, hosted ecommerce, accounting, etc.—that need to send email from the company’s domain. The IT team may not even know about all of these services, since departments can and do configure such services on their own.

For example, a small 30-person company might use Google Apps for its mailboxes, Salesforce for CRM, ZenDesk for customer support, Marketo for lead generations, SendGrid for email originating from the company’s web application, and Survey-Monkey for online surveys. Any of these services may need to send email from the company’s pri-mary domain or one or more subdomains. Manag-ing the email security requirements for this many services, especially as they change over time, can be a very significant burden on IT.

6

There are significant requirements for the configuration system that underlies a protocol like SPF. The system must be globally available on a 24/7 basis, able to respond to requests in hundreds of milliseconds, able to handle traffic at Internet scale, resistant to any kind of local failure, and support the kind of distributed ownership model that underlies SPF. It’s hard to think of another system that meets these stringent requirements.

That being said, DNS has some substantial limitations that present challenges for senders who wish to configure SPF for their domains. Configuring DNS records can be a very intimidat-ing process for nontechnical and inexperienced technical users.

Moreover, because so many important systems rely on DNS, it is easy to inadvertently break one or more of these services while modifying the DNS configuration for a domain. Even experienced sys-tem administrators usually shy away from making frequent changes to DNS records.

Finally, SPF records are configured using DNS TXT records, which are free-form text fields with no validation. So it is very easy to unintentionally intro-duce an error into a domain’s SPF configuration. The error may not be discovered until much later, after email delivery has already been impacted.

With all of the above in mind, configuring SPF by editing DNS records can be both challenging and error-prone.

DNS Configuration Can Be Tricky

Email deliverability & security impact

• Google, Yahoo!, AOL, and Microsoft struggling to pick out the “good from the bad”

• Heuristic guesses: restricting some good email, letting phish get through

Examples of Cloud Services Sending Email

Email’s Move to the Cloud

Email services multiply & move to the cloud

• The average company has a dozen cloud services sending email on their behalf

• Most cloud services lack proper email authentication and tracking

Little visibility into cloud email adoption & deliverability issues

• Most of these email services are turned on with little input by messaging team

• The messaging team has a lack of visibility and control, but is expected to manage deliverability issues

7

Domain Keys Identified Mail (DKIM) is used by email senders and receivers to authenticate the sender of email messages and validate the in-tegrity of the received messages. DKIM relies on two technologies—cryptographic signatures and DNS—to authenticate email messages.

With DKIM, the contents of each email messages is hashed, and the computed hash is encrypted into a message signature that is included with the message. With access to a sender’s public key, any recipient of the email can verify its integrity and origin using a well-known process.

While cryptographic signatures allow receivers to verify messages, there are still some remaining is-sues. First, how does the sender make their public key available to any receiver who wishes to verify a message? And second, how does the sender associate the private key with a meaningful and recognizable source of online identity?

DKIM uses the DNS to solve both of these prob-lems. DNS works well for this purpose, because organizational domains are registered to real world entities, giving them meaningful and easily verifi-able identities. And the structure of DNS ensures that all records published on the organizational domain and its subdomains are under the ultimate control of the organizational domain owner.

Subdomains can thus be used as sources of iden-tity directly linked to real world entities. The email message is linked to a particular organizational domain through the ‘From’ address of the email or other metadata. The sender establishes their

authority to send email on behalf the organizational domain by publishing the public key as a record inside the organizational domain.

However, many organizations find DKIM difficult, for a variety of reasons.

Common DKIM Pitfalls

EDITING DNS RECORDS IS INTIMIDATING

As with SPF, DKIM requires editing DNS records. This can be intimidating for less-technical users and is an error-prone and high-risk procedure for anyone, since misconfigurations can cause seri-ous problems with email and site accessibility.

COORDINATING WITH EMAIL SOLUTION PROVIDERS IS DIFFICULT

As mentioned in the previous section on SPF, many companies today use a constellation of Email Solution Providers (ESPs) to handle the wide variety of email-based communications they rely on.

To enable DKIM, each of these ESPs will need a DKIM record in the company’s organizational do-main. Moreover, each of these DKIM records will need to contain a distinct, provider-specific public key. Obtaining the public key for each provider is typically a manual process, requiring the email administrator to access the provider’s web appli-cation, get the public key, and cut and paste this value into the company’s DNS management tool.

DKIM

8

DKIM keys are supposed to be updated at regular intervals. Also, should a sender’s private keybecome compromised, the corresponding DKIM record needs to be deleted and a new publickey published in its stead. There is no automated notification and update process for public keys in either scenario. Notifying domain administrators and updates to DKIM records are entirely manual and, in practice, rarely happen.

ERRORS IN CONFIGURATION ARE DIFFICULT TO DETECT

Existing processes for DKIM configuration lack validation. Configuration is performed by updating free-form text records in DNS, usually by cutting and pasting. Errors in the DNS record are only detected when receiving systems attempt to verify DKIM signatures and fail to do so. These failures are often not reported back to the originating sys-tem, so a company may not become aware of an error in their DKIM record until days or weeks later, if at all.

A bad DKIM record can inadvertently cause email from the domain to be categorized as spam, or not delivered entirely. So the cost of an error can be high. Without tools to detect and prevent errors in DKIM records upon configuration may be an unacceptable risk for an organization.

Enter ValiMail: DMARC that “Just Works”

ValiMail’s extensive experience with both email and security has created a turnkey solution that is fully automated and shields users from the complexities laid out in earlier sections. Much as Software as a Service simplifies and dramatically reduces configuration and deployment issues, ValiMail’s Email Authentication as a Service™ was built from the ground up for organizations who want DMARC to just work. Through a unique approach and by partnering with key vendors, ValiMail has abstracted the steps and effort need-ed to set up DMARC to a simple point and click configuration.

The abstraction ValiMail has performed has several benefits. First, it allows for much simpler configuration and maintenance of email authenti-cation. Instead of working inside of a text-based and highly fragile DNS system, clients can make simple and human-readable changes. ValiMail has furthermore taken the approach of identifying and classifying senders so configurations and changes are accessible even to non-technical users.

Visibility and control, while detecting and blocking phishing attacks on our employees and consumers— Incredible. Chris Cravens Head of Technology Services, Uber

“ “

9

Manual Configuration vs. ValiMail

Without ValiMail With ValiMail

Second, by automating the process, ValiMail has been able to reduce the cost of implementation by several orders of magnitude. This has enabled ValiMail to offer a solution that is priced appropri-ately for any organization that wants a low cost, easy to implement DMARC solution.

Third, the approach ValiMail has taken has forced us to fix several existing issues with email authen-tication, most notably inherent limitations of the various email authentication standards. Without fixing these limitations, one is left with either con-tinuous manual modifications or severe restrictions on the number of partners or vendors who can

legitimately send emails on your behalf (eg, Sales-force, Zendesk, Marketo, Google apps, etc.).

The ValiMail solution is based on a combination of carefully curated data and innovative technology. ValiMail has built a comprehensive database of email services, mailing lists, and forwarders. This database, updated in real time, allows us to recognize known email sources, and to configure message authentication behavior based on the validated source. This data furthermore allows domain owners to configure authentication policy at the source level, substantially simplifying configuration.

Identify all email services

Find SPF & DKIM configurations

Log into DNS console

Update DNS TXT records

ERROR! SPF over lookup limit

Wait 24 hours: what broke?

Fix newly identified services

Monitor, Repeat...

1.2.3.4.5.6.7.

Log into ValiMailSimple “1-click” interface Auto-Correction

1.2.

10

Two new patent-pending technologies are central to ValiMail’s solution:

• Targeted SPF™

• Distributed DKIM™

These two new technologies allow ValiMail to take email authentication to the next level, fixing long-standing issues inherent in traditional con-figurations. The following two sections will briefly describe ValiMail’s breakthroughs in both SPF and DKIM, making Email Authentication as a Service™ possible.

VALIMAIL’S TARGETED SPF™ SOLUTION

ValiMail’s patent-pending Targeted SPF™ provides a scalable, service-oriented, easy-to-use SPF service that:

• Enables authorization and de-authorization of email services with a one-click interface

• Allows domains to support an arbitrary number of authorized services on a single domain

• Insulates domain owners from needing to know the underlying details of the services they use

• Works with any existing mail service or ISP that supports SPF

• Requires no additional explicit coordination with email service providers

As described earlier, SPF uses a recursive meth-od to look up the first 10 rule sets. Once 10 look-ups have been performed, if the rule set has not yet been ascertained, SPF responds with a failure. This is the most common reason for SPF failures and a major impediment to proper authentication. ValiMail’s Targeted SPF™ solution has inverted this

process, returning only the appropriate rule set for just that request, thereby avoiding the 10 lookup limit.

ValiMail’s solution takes advantage of a widely supported but rarely used portion of the SPFspecification known as SPF macros. Macros have been part of the SPF specification since itsintroduction as a means to capture additional information about the inbound SMTP connection.

Valimail’s system encodes this additional informa-tion into a domain name, which the receivingmail server queries as part of the SPF process. Our custom DNS infrastructure responds tothose queries and, based on our extensive data and the sending domain configuration, returnsthe appropriate SPF rule for just that request.

VALIMAIL’S DISTRIBUTED DKIM™ SOLUTION

The ValiMail system also reinvents DKIM configu-ration by making a significant departure from tradi-tional practices. Today, it is typically the ESP that generates the DKIM public key pair. The ESP keeps the private key secret, and it is the responsibility of the domain administrator to create the required DKIM DNS record containing the public key.

With ValiMail’s Distributed DKIM™ the domain owner is only required to make a one-time change to their DNS configuration. Unlike traditional DKIM, ValiMail—not the third party sender—generates the signing key. Instead, participating third party senders generate a single public key pair that is used for all of their customers, which is published in DNS. This key pair is not used for signing mes-sages, but rather for encrypting signing keys.

Solving Inherent Limitations of SPF & DKIM

11

When enabling a sender for a customer, ValiMail generates a DKIM signing key pair, encrypts the signing key with the sender’s encryption key, and discards the plaintext signing key. There is no database of plaintext signing keys, which vastly increases the security of the system.

ValiMail then uses DNS to distribute the encrypted signing key to third party senders. In addition to the security afforded by the encryption key, the use of DNS allows ValiMail to use the IP address of the requesting server as a factor in determining whether to provide the encrypted signing key re-cord. In essence, ValiMail has created two-factor authentication for DKIM key requests: the request-ing party needs to both know to ask for the key and the request needs to come from a recognized IP address.

ValiMail publishes the corresponding verifying key in a standard DKIM DNS record, making the

process invisible to receivers. This process also makes it trivial to rotate keys, as ValiMail can sim-ply generate a new DKIM key pair at any time.

With this patent-pending system ValiMail solves the core problems with traditional DKIM config-uration for its clients, ensuring that they do not need to concern themselves with key generation, encryption, or modifying DNS records. A ValiMail customer need only authorize an ESP that sup-ports Distributed DKIM™ and the rest is automatic.

The ValiMail system also represents a substantial improvement over the status quo for email service providers. Onboarding costs will be substantially reduced, as it will be much simpler for custom-ers to configure DKIM for use with the ESP. DKIM misconfiguration errors are a thing of the past, improving deliverability. And ValiMail will protect their customers’ brands from abuse.

Footnotes/Attributions:

1. The Radicati Group & The Direct Marketing Group2. Verizon breach report & The Radicati Group3. AntiPhishing Working Group4. AntiPhishing Working Group5. AntiPhishing Working Group6. http://docs.apwg.org/reports/APWG_Global_Phishing_Report_1H_2014.pdf7. Published case studies by ReturnPath and Agari8. https://dmarc.org/2015/10/globalmailboxprovidersdeployingdmarctoprotectusers/9. DMARC.org

Conclusion

Configuring DMARC, SPF, and DKIM can be difficult, time-consuming, and error-prone. ValiMail’s com-bination of proprietary technology and data makes it easy. Companies can leverage ValiMail’s expertise and systems to ensure that they are correctly authenticating their legitimate emails, wherever those mes-sages might originate. ValiMail makes it easy to selectively enable and disable services, without requiring complex and error-prone manual changes to DNS records.

PROTECTION AGAINST MODERN PHISHING ATTACKS

• Authentication creates dynamic white list, excluding criminals• Companies that have email authentication in place see a 95%+ drop in attacks

VISIBILITY INTO CLOUD-BASED EMAIL ISSUES

• Multiple cloud services send email on your clients’ behalf• Email authentication brings visibility and surfaces deliverability issues

EMAIL DELIVERABILITY IMPROVEMENTS

• Google, Yahoo!, AOL, and Microsoft will classify non-authenticated emails as suspicious• Proper authenticating emails get an automatic “pass” from ISPs

The upshot is authenticated email that is fully compliant with today’s DMARC standard, which improves your visibility into cloud-based email services, protects your brand, employees, and consumers from spam and phishing attacks, and helps ensure the deliverability of the emails you send.

RESOURCES AND COMPLIMENTARY ASSESSMENT

1. Our Domain Checker tool will assess any domain’s current authentication status: https://app.valimail.com/domain_status/2. Read more about email authentication on our blog: https://blog.valimail.com3. An email authentication FAQ can be found here: www.valimail.com/emailFAQ4. For a complimentary assessment, contact us at info@valimail.com