- API & Integration
- SparkPost vs SendGrid
- Learn More
- Volume Pricing
Choose your sending volume and get up and running in minutes.
- Add-on Plans
Combine with any volume tier for a custom tailored plan.
- Get Started for Free
- Help & Docs
- Deliverability Guide
- Case Studies
- Email Explained
- White Papers & Guides
- Webinars & Videos
A little late to the game, I recently binge-watched season 7 of the Game of Thrones. One thing I noticed is that for all the thick walls, barred doors, and armed guards, most of the castles in the show were not taken through a direct attack on their outer defenses, but rather through infiltration. Invaders circumvented the castle’s defenses using backdoors and hidden tunnels. They even walked through the castle gate while impersonating a resident.
SaaS applications that send email—which is all SaaS applications—are similarly vulnerable. As an engineering leader, you may have followed security best practices: training, code reviews, third-party penetration testing, secured your infrastructure, and more. And yet all your efforts could come to naught if a bad actor steals a user’s credentials from that user.
A common approach bad guys take to stealing user credentials is to impersonate your email: a phishing attack. A malicious third party sends your users an email that looks like it came from your application. A link in the email takes users to a website resembling your own and requests their username and password to log in. The attackers now have access to your application, allowing them to walk right through your castle gate.
An attack like this—impersonating your application—could result in customers losing trust in your service and present an existential threat to your business.
You may believe that you’re not liable for a customer’s internal security training and that there’s not much you can do to stop attacks like this. And you’re right in thinking you can’t easily stop these emails being sent. You can, however, strongly influence whether your users receive these emails.
Phishing is possible because, in the early days of email, the small group of organizations using it trusted one another. The Simple Mail Transfer Protocol (SMTP) lives up to the “simple” part of its name. A mail client can send a message by connecting to a remote Mail Transfer Agent (MTA), provide the To and From addresses of the message, and then the message body itself. The SMTP protocol does not specify a way to validate that the party sending the email has the right to send from any given address, allowing the sender to claim they are sending a message on behalf of anyone.
Fortunately, new standards are making it easier for companies to protect themselves and their users from phishing. These standards add the ability to authenticate the identity of a message sender. They allow mailbox providers such as Gmail and Microsoft, along with corporate email administrators and others, to filter messages that don’t pass validation and alert the company targeted by phishing to the impersonation attempt.
The first of these technologies is Sender Policy Framework, or SPF. SPF defines a way to validate that an email message was sent from an authorized mail server. SPF establishes a method for receiving mail servers to verify that incoming email was sent from a host IP authorized by the sender’s domain administrators. It piggybacks on the existing Domain Name System (DNS).
While SPF can define which servers are allowed to send messages on behalf of your domain, it doesn’t offer a mechanism to verify whether the message headers or body have been altered or forged. This is handled by DomainKeys Authenticated Mail, or DKIM. It works by using a private key to creating a unique digital signature for the email’s header and content and adding this to the existing headers of the message. The signature can then be validated against a public key in your DNS records.
The third standard that serves to bring the first two together is Domain-based Message Authentication, Reporting, and Conformance, or DMARC. DMARC is another DNS-based technology that enables an organization to publish their authentication practices, advise receivers on how to treat messages that don’t validate against SPF and DKIM and to request that notifications be sent to the organization when non-authenticated messages are encountered.
With these combined standards, mailbox providers can identify messages that have been legitimately sent from your application and ensure that they are delivered to your user’s mailboxes. Those that aren’t may be sent to a spam folder or quarantined, with your team notified. The email purportedly sent from your application asking the user to change their password would likely not have been delivered to their inbox.
Your customer’s data may not be pilfered via a frontal assault on your application. Rather, using deception, a bad actor can fool your users into giving away the keys to your castle. There are, however, actions you can take to mitigate this risk and ensure that your customers remain safe.
—Steve Murray, SparkPost CISO
P.S. Want to learn more about preventing phishing and ensuring that your messages reach your user’s inbox? Our Email Deliverability Guide is a great resource. And if you’re implementing email authentication standards, check out our free tools for inspecting and validating your SPF and DKIM records.
When we speak of “Email Authentication”, we’re referring to a technique that provides to the recipient of a message some level of certainty that the message actually originated with the claimed source of the message. The idea behind such techniques is to achieve some level of defense against fraudulent email, such as phishing and spoofing, mail that could erode a recipient’s trust in receiving email. That said, the act of sending authenticated email does not assert that the email is good or wanted email; it only means that the mail is such that a reputation for the authenticated party can be reliably established and used in email acceptance and placement decisions.
There are two forms of email authentication in use today:
- Sender Policy Framework (SPF)
- Domain Keys Identifed Mail (DKIM)
In today’s post, I’m covering what DKIM is and how it works.
Unlike its authentication counterpart SPF, which provides a way for a domain to authorize a host to send mail on its behalf, DKIM provides a way for an entity (domain, organization, person, etc.) to take responsibility for a message, independent of the entity that actually sent the message. While in many cases the responsible entity and the sending entity will be the same, or at least closely related, with DKIM there’s no requirement that this be so.
My goals for you with this post are that you learn and understand the following concepts about DKIM:
- DKIM is a “content-based” authentication, unlike the “path-based” SPF.
- The responsible entity asserts its responsibility by “signing” the message with a pair of cryptographic hashes inserted in a message header.
- DKIM validation is done by the receiving domain attempting to generate the same two hashes.
- DKIM validation cannot be completed in many cases until the full message has been transmitted by the sending server.
- Validation failures can be difficult to troubleshoot.
DKIM is referred to as “content-based” authentication, rather than “path-based”, because whether or not a message passes DKIM validation is based solely on whether or not the content has changed between the time it was signed and the time validation was attempted.
DKIM Signing and Validation
Organizations wishing to DKIM sign mail will first generate two cryptographic keys. One of the keys is kept private and available to the sending server for the signing of mail, and the other is to be made public in DNS for use by receiving domains in attempts to validate the signature. The methods for generating these keys and installing them are platform-dependent and beyond the scope of this post, although later I will describe the publishing in DNS of the public DKIM key.
The DKIM-Signature Header
To begin our understanding of DKIM, let’s first look at a DKIM-Signature header:1234567DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed;q=dns/txt; firstname.lastname@example.org; t=1454417737;h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type;bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=;b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
The DKIM-Signature header is a series of key-value pairs, some of more interest to the reader than others, but I’ll describe all of them here.
First, we’ll look at the ones that are mostly of passing interested to the reader:
- v=1; – Specifies the DKIM version (1 is the only valid value)
- a=rsa-sha256; – The algorithm used to construct the cryptographic hashes
- c=relaxed/relaxed; – There are two sets of rules regarding removal of whitespace in the headers and body that can be applied when creating the hashes in a DKIM signature; these rules are called “canonicalization rules” (hence the key of c) and the rulesets are either “relaxed” or “strict”.
- t=1454417737; – The timestamp of when the signature was created.
These three header parts contain the actual signature information:
- bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – This is the hash of the body of the message.
- h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – This is a list of the headers that were used to create the signature data shown below.
- b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – This is the acutal DKIM signature data
These three parts are of most interest to the receiving server that will be validating the signature:
- d=welcome.foo.com; – This identifies the domain that signed the message
- s=notices; – The selector; domains can have multiple selectors that they use when signing messages.
- email@example.com; – This is the identity on whose behalf the message was signed. Syntactically, this will look like an email address, and might even be one; the localpart of the email address can be empty, as in this example, and the domain part must be the same as, or a subdomain of, the domain in the d= part of the signature.
The reason these parts are of interest to the receiving server is that they provide the information necessary to help the receiver validate the signatures.
In addition to the requirement mentioned that the i= domain must be the same as or a sub-domain of the d= domain, the d= and s= bits are used by the validator to look up the signer’s public DKIM key in DNS. The key is a TXT record in DNS, and it’s always found at the location selector._domainkey.domain. So, in our example here, with s=notices and d=welcome.foo.com, the public DKIM key would be found in DNS at notices._domainkey.welcome.foo.com, and it might look something like this:123456notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\;h=sha256\;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzNNoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwRpod8n+//qIpQIDAQAB\; s=email"
The validator uses that key (the p= bits) to produce its own set of hashes of the message; if those hashes match, then the message hasn’t been altered in transit, and so the message can contribute to, and perhaps benefit from, whatever reputation is in place for the signer of the message.
Validation Failure and Troubleshooting
I mentioned above that DKIM failures can be difficult to troubleshoot, and I’ll explain why that’s so here.
Some DKIM validation failures have obvious causes, such as the message not being signed, or the signing domain’s public key not being found in DNS or not being syntactically correct, or perhaps the message was obviously altered in transit. When those kinds of failures happen, it’s easy to figure out the problem and recommend a solution. The tough ones, though, and the ones which lead to the most frustrating support experience, are the cases where the message was signed, the public key exists in DNS, and the message wasn’t obviously altered, but the validator reports that the signature failed to validate.
The reason that these are tough to troubleshoot is because there’s no real way for either side to reproduce the conditions under which the message was signed and validated. The message has in its DKIM-Signature header the hashes that were generated by the signer at the time of signing, but the validator likely has no access to the signer’s infrastructure and so cannot try to reproduce the signature under the signer’s conditions. Similarly, the signer likely has no access to the validator’s infrastructure and so has no way to try to validate the message in the way that the validator did.
Failures like I’m describing here are rare occurrences, and DKIM validation failures by themselves usually don’t have an impact on delivery placement. It’s been my experience that such failures drive more support tickets than any other kind of DKIM issue.
For further reading on the topic of email authentication, please see our blog for posts on SPF and DMARC
Often mentioned in the same breath as the email authentication protocols SPF and DKIM, DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is not in itself an authentication protocol. Instead, the purpose of DMARC is to allows you, the domain owner, to protect your email reputation by:
- Announcing email authentication practices,
- Requesting treatment for mail that fails authentication checks, and
- Soliciting reports about mail claiming to be from its domain.
DMARC can be an effective tool for you to to use in your fight against fraudulent mail that targets their domain name (e.g., phishing and spoofing), and that can promote higher trust by your recipients for your mail. This higher trust should in turn lead to higher engagement with your mail, and mail that’s opened and generating clicks drives sales and higher ROI for your email campaigns.
In addition to protecting your domain, I predict that implementing DMARC now will be an excellent way to “future-proof” your domain. Here at SparkPost, we believe that as the industry moves to IPv6, it is almost certain to move from an IP-based reputation model to a domain-based reputation model. Domain-based reputation will require domain-based authentication, and DMARC, in concert with DKIM and SPF, will help domains in establishing a domain-based reputation long before one might be absolutely necessary.
In this post, I’ll tell you all you need to know about leveraging DMARC to protect your email reputation, and give you pointers on how to set it up for your domains.
Terms To Know
Before I get into setting up DMARC for your domain, I want to make sure we’re speaking the same language. Let’s start by defining some terms I’ll use throughout the rest of this document.
The RFC5322.FromDomain is the domain part of the email address that’s usually seen by a recipient of your email when it’s being read. In the following example, the RFC5322.From domain is “joesbaitshop.com”
From: Joe’s Bait and Tackle <firstname.lastname@example.org>
DKIM d= Domain
DKIM is an authentication protocol that allows a domain to take responsibility for a message in a way that can be validated by the receiver of the message; this is done through the use of cryptographic signatures inserted into the message’s headers as it’s leaving its origination point. These signatures are effectively snapshots of what the message looked like at that point in time, and the receiver can use these snapshots to see if the message has arrived unchanged at its destination. The process of producing and inserting these snapshots is called DKIM signing, and the domain that takes responsibility for the message by signing it inserts its name into the header in a key-value tag as “d=signingDomain”, and so it’s referred to as the DKIM d= domain.
The Return-Path domain, sometimes called the RFC5321.From Domain or the Mail From domain, is the domain to which bounces are routed; it is also the domain on which SPF checks are done during the email transaction. This domain is usually not seen by the recipient unless the recipient is savvy enough to look at all the headers in a given message.
At this time, all mail sent through sparkpost.com will have sparkpostmail.com as its Return-Path domain, as in the following example:
We are contemplating giving our customers the ability to personalize this domain in the future.
The term “Organizational Domain” refers to the domain that was submitted to a registrar to create the domain’s presence on the internet. For SparkPost, our organizational domains are sparkpost.com and sparkpostmail.com.
The last term to understand regarding DMARC is “Domain Alignment,” and it comes in two variants: “relaxed” and “strict.”
Relaxed Domain Alignment
Any two domains are said to have relaxed domain alignment when their Organizational Domains are the same. For example, a.mail.sparkpost.com and b.foo.sparkpost.com have relaxed domain alignment, because of their common Organizational Domain, sparkpost.com.
Strict Domain Alignment
Two domains are said to be in strict domain alignment if and only if they are identical. So, foo.sparkpost.com and foo.sparkpost.com are in strict alignment, as the two domains are identical. On the other hand, foo.sparkpost.com and bar.foo.sparkpost.com, are only in relaxed alignment.
DMARC Domain Alignment Requirements
In order for DMARC validation checks to pass, DMARC requires that there be domain alignment as follows:
- For SPF, the RFC5322.From domain and the Return-Path domain must be in alignment
- For DKIM, the RFC5322.From domain and the DKIM d= domain must be in alignment
The alignment can be relaxed or strict, based on the published policy of the sending domain.
How DMARC Works to Protect Your Email Reputation
When I speak of a mailbox provider or other domain “checking DMARC”, or “validating DMARC”, or “applying DMARC policy”, what I mean is that the domain receiving a message is performing the following steps:
- Figure out the message’s RFC5322.From domain
- Look up that domain’s DMARC policy in DNS
- Perform DKIM Signature validation
- Perform SPF Validation
- Check domain alignment
- Apply DMARC policy
In order for a message to pass DMARC validation, the message must pass only one of the two authentication and alignment checks. So, a message will pass DMARC validation if any of the following are true:
- The message passes SPF checks and the RFC5322.From domain and Return-Path domain are in alignment, or
- The message passes DKIM validation and the RFC5322.From domain and DKIM d= domain are in alignment, or
- Both of the above are true
By default, mail sent through sparkpost.com will have “sparkpostmail*.com” as its Return-Path domain, so the only possible path to passing DMARC validation is through the DKIM check. We ensure that messages are signed twice, so there will be one DKIM-Signature with a d= domain matching the customer’s domain, and this domain should align with the RFC5322.From domain on the message.
It is possible for customers to get a custom Return-Path domain, as described by this support article. There are a number of reasons, in addition to DMARC, that a domain owner may want to pursue this option, but the choice is up to you.
Making DMARC Work for Your Domain
Now that I’ve explained the mechanics of DMARC, let’s talk about how to make DMARC work for you, which involves the following three steps:
- Making preparations to receive DMARC reports
- Deciding on what DMARC policy to use for your domain
- Publishing your DMARC record
I’ll cover each of these in detail below, but I’ll tell you straight out that step 1 above will consume about 95% of your preparation time.
Preparing to Receive DMARC Reports
Any domain that publishes a DMARC policy should first prepare to receive reports regarding their domain. These reports will be generated by any domain that does DMARC validation and sees mail claiming to be from your domain, and will be sent to you on at least a daily basis. The reports will come in two formats:
- Aggregate reports, which are XML documents showing statistical data of how much mail was seen by the reporter from each source, what the authentication results were, and how the messages were treated by the reporter. Aggregate reports are designed to be machine-parsed, with their data stored somewhere to allow for overall traffic analysis, auditing of your domain’s message streams, and perhaps identification of trends in sources of unauthenticated, potentially fraudulent, email.
- Forensic reports, which are individual copies of messages which failed authentication, each enclosed in a full email message using a format called AFRF. The forensic reports are supposed to contain full headers and message bodies, but many reporters strip or redact some information due to privacy concerns. Nonetheless, the forensic report can still be useful both for troubleshooting a domain’s own authentication issues and for identifying, from URIs in the message bodies, malicious domains and websites used to defraud the domain owner’s customers.
The preparation to receive these reports involves first creating two mailboxes in your domain to handle these reports, such as email@example.com and firstname.lastname@example.org. Note that those mailbox names are completely arbitrary, and there are no requirements for the naming of the local part of the mailbox; you are free to choose any names you wish, but keep the two separate for easier processing.
Once the mailbox names are selected and created in your domain, the next thing to do here is to put tools in place to read these mailboxes and make use of the data, especially the aggregate data reports, which again are designed to be machine-parsed, rather than read by a human. The forensic reports, on the other hand, might be manageable simply by reading them yourself, but your ability to do so will depend both on your mail client’s understanding of how to display messages in the AFRF format and on the volume of reports you receive.
While it’s possible for you to write your own tools to process DMARC reports, until such time as we provide such services for sparkpost.com customers (something we’re considering, but not promising yet), we recommend that you make use of tools that are already available for the task.
Which DMARC Policy to Use
The DMARC specification provides three choices for domain owners to use to specify their preferred treatment of mail that fails DMARC validation checks. They are:
- none, meaning treat the mail the same as it would be treated independent of DMARC validation checks
- quarantine, meaning accept the mail but place it somewhere other than the recipient’s Inbox (typically the spam folder)
- reject, meaning reject the message outright
It is important to keep in mind that the domain owner can only request such treatment in its DMARC record; it’s up to the recipient of the message to decide whether or not to honor the requested policy. Some will do so, while others may be a bit more lenient in applying policy, such as only spam-foldering mail when the domain’s policy is reject.
We recommend to all of our customers that they launch with a policy of none, simply to be safe. While we are confident in our ability to properly authenticate your mail through DKIM signing, it’s still best to take some time to examine reports about your domain before getting more aggressive with your DMARC policy.
Publishing Your DMARC Policy
A domain’s DMARC policy is announced by publishing a DNS TXT record at a specific place in the DNS namespace, namely “_dmarc.domainname.tld” (note the leading underscore). A basic DMARC policy record for our example domain from earlier, joesbaitshop.com, might look something like this:1_dmarc.joesbaitship.com. IN TXT "v=DMARC1\; p=none\; rua=mailto:email@example.com\; ruf=mailto:firstname.lastname@example.org\; pct=100"
Breaking down this record, we have:
- v=DMARC1 specifies the DMARC version (1 is the only choice right now)
- p=none specifies the preferred treatment, or DMARC policy
- rua=mailto:email@example.com is the mailbox to which aggregate reports should be sent
- ruf=mailto:firstname.lastname@example.org is the mailbox to which forensic reports should be sent
- pct=100 is the percentage of mail to which the domain owner would like to have its policy applied. Domains just getting started with DMARC, especially those likely to generate a high volume of reports, may want to start with a much lower number here to see how their report-handling processes stand up to the load.
There are other configuration options available for a domain owner to use in its DMARC policy record as well, but the tips I’ve provided should be a good start.
There’s a lot to unpack in the information above! I hope you find the how-to for creating a DMARC policy record helpful. I also hope that my explanation of why DMARC matters helps make clear why you should start using this important tool for protecting your email reputation.
Of course, this isn’t a complete or authoritative document on the subject. If you want to dig in deeper or want more help, a great place to start is the official DMARC FAQ. And, it goes without saying that the crackerjack SparkPost support team is ready to help you with configuring your SparkPost account for DMARC as well.
Thanks for reading—and get started protecting your domains with DMARC today!
Do not go gentle into that new normal
At SparkPost’s recent Insight user conference, Steve Jones, executive director of DMARC.org, didn’t hold back. He began his talk on email authentication by bluntly observing that “spam and phishing are the new normal.” I sucked in my breath. Steve’s comment felt like a punch to the gut. I felt like I wanted to defend the honor of email. Yeah, bad guys—sometimes really bad guys—are out there, I thought to myself, but it’s the exception, not the rule! But I knew he was right. I settled down and nodded my head, knowing that Steve’s perspective squared with the experiences of people who manage the front-lines of defense at ISPs and corporate email hosts, as well as the findings of email industry organizations like M3AAWG.
Steve noted that 28 billion spam messages are sent every day. By some estimates, phishing is a $3.7-million annual cost for the average enterprise. And for publicly-traded companies, a disclosure of phishing leads to a loss of stock value of $411 million or more. As Steve put it, costs like these are fraudulent email’s “hit to reputation and brand, made tangible. And there’s no bottom to what bad actors will do to get your money.”
So, spam and phishing really are the new normal. Companies must incorporate a security posture that takes into account email as a major attack vector that’s exploitable through phishing, malware, and socially engineered content designed to defraud recipients of sensitive information and to steal credentials that grant access to systems.
And this new normal is why Steve’s organization does its work. DMARC, or “Domain-based Message Authentication, Reporting & Conformance,” is a technical specification that builds on earlier SPF and DKIM email authentication mechanisms. In his talk at Insight, Steve presented an overview of the current landscape of email authentication, including why DMARC is important, how it works, and recent developments.
ISPs are moving to an authentication-only world. So should you.
The biggest consumer mailbox providers prefer authenticated email. But that preference may be changing to a mandate. In 2015, Yahoo took the plunge and published a “p=Reject” DMARC record. By doing so, Yahoo essentially told receivers, “if you can’t verify an email came from Yahoo, throw it away. No exceptions.” There are reports that Google may take a similar step for Gmail in 2016.
There have been issues with this “strict” posture—in some cases, legitimate email has suffered because of this spam counter-measure. But, I remind you that false positives are nothing new. It’s frankly just a cost of doing business for senders (and a much smaller cost than those that result from successful phishing attacks). Legitimate senders long have been operating in the shadow of compromised hosts, spam, phishing and other abusive digital communications, and incurring short-term inconveniences to stem that tide is worth the effort. Truth be told, what disturbs me more is the fact that everyone hasn’t yet adopted SPF, DKIM and DMARC as a means of combating spam and protecting their own reputations!
It’s time to splice email authentication into corporate DNA.
The watch guards of enterprise security (especially CISOs) often talk about a company’s “security posture,” the plan and cultural shift that a business puts into place to protect its employees, customers, intellectual property, and systems from attack, both cyber and physical. We’re likely all familiar with defenses like firewalls, multi-factor authentication mechanisms, access and password policies, and more.
But what about email? It’s the lifeblood of every company doing business on the internet today. But at too many businesses, email security is limited to spam filters or malware scans. Those are fine front-line tools to help protect against brute force bad guys, but they do little for phishing (and spear-phishing) attacks.
The simple power of email is its ability to connect people and businesses the world over. But the simplicity and ubiquity that makes email the Internet’s “connective tissue” also allows the spread of viruses, fraud, phishing, and compromises to accelerate to pandemic speed as they move from one email box to another.
Every company that works with customer data, financials, or has a broad national or global presence is nothing short of a flame in the night that draws all sorts of malicious attacks. In the digital marketing industry, ESPs, marketing automation companies, anyone who purports to be a marketing system of record… are just some of the inevitable targets for phishing attacks.
Adopting email authentication standards like DMARC (and transport layer encryption standards such as STARTTLS) will go a long, long way to improving your digital messaging security posture. What are you waiting for? Do it.
Ready to learn more about DMARC and email authentication? Here are a few resources to get going.
- How DMARC Is Saving Email, a great ebook written by our deliverability team
- The Validator, the free, all-in-one DKIM validation, SPF checker, and DMARC validator app from SparkPost
- Understanding SPF and DKIM In Sixth Grade English
- Twitter’s Email Privacy Report, powered by SparkPost
Message Systems is pleased to announce today that we have qualified for the Online Trust Alliance’s 2014 Email Integrity Honor Roll. The audit evaluates a company’s adoption of email authentication practices and focuses in particular on email authentication that helps detect and block spoofed and forged email such as Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting & Conformance (DMARC) practices.
Companies are recognized as leaders in the space of email security and brand protection if they have:
- Implemented SPF and DKIM at the corporate or top-level domain
- Have a DMARC record published
As part of this audit, the Online Trust Alliance reviewed over 800 companies and brands, out of which only 12% passed, and Message Systems is honored to make the list!
From the positive effects we’re seeing across the industry, it’s clear that DMARC is succeeding as intended in deterring malicious email attacks – which is great news. Message Systems will continue to provide the technologies our customers need to quickly implement SPF, DKIM and DMARC to protect their brands and customers.
– Phillip Merrick CEO, Message Systems
Earlier this year, we also qualified for the Online Trust Alliance’s 2014 Online Trust Audit and Honor Roll – this latest honor further recognizes our commitment to educating the industry on email security for online brand protection through leading by example.
Here’s the Good News
The 2014 Email Integrity Audit had several key findings, both positive and negative, on the state of email authentication in the various industries. As always, let’s start with the good:
- Adoption of SPF and DKIM is rising across all the industries. The Internet Retailer 100 had an 88% adoption rate, while the Internet Retailer 500 had the largest growth, rising from 56% to 74% adoption.
- Adoption of DMARC is increasing slowly but steadily, and the top social sites had the highest score for DMARC adoption at 36%.
Among the list of companies that made the 2014 Email Integrity Honor Roll, many were our customers and partners, and we’d like to offer everyone a hearty congratulations!
Internet Retailer Top 500
Social Top 50
DMARC allowed us to dramatically reduce the number of forged emails sent to our users. DMARC was a direct benefit to our users by blocking these impersonations.
– Josh Aberant Postmaster, Twitter
SPF and DKIM are vitally important for email senders to implement today, but they are merely table stakes in an escalating battle against email fraud. DMARC is a powerful solution empowering senders who are prone to brand infringement and malicious attacks.
– Robert Holmes General Manager, Fraud & Brand Protection Services, Return Path
… And Now for the Bad News
While adoption rates for SPF, DKIM and DMARC continued to grow, the news about the state of email authentication in the industry wasn’t all quite as rosy:
- Of all the consumer domains sampled, only 8.3% have implemented SPF, DKIM and DMARC.
- Brands are failing to authenticate at top level domains; SPF and DKIM adoption only grew at the level of sub domains, thus leading to limited brand and consumer protection.
- While DMARC adoption is growing, it still remains low.
- Top FDIC insured banks had the highest failure rate compared to all sectors due to a lack of email authentication – only 17% passed the audit.
- The top 50 federal government sites consistently scored at the bottom of all email authentication metrics – only 4% passed the audit.
The 2014 Email Integrity Audit findings revealed that consumers are at a higher risk of receiving forged and spoofed email from major banks and federal government sites – a scary thought as these are institutions that generally command the trust of the public. The 2014 Email Integrity Audit report also specifically called out the security weaknesses in email infrastructure in enterprises and commodity message/mail transfer agents:
Unfortunately, in many enterprises the email infrastructure does not natively support outbound signing or inbound checking for SPF, DKIM or DMARC. Equally as concerning is the lack of support for inbound authentication from leading MTAs (Mail Transfer Agents), the hosting community and email technology providers.”
– 2014 Email Integrity Audit report
The report points to the inconsistency of email authentication in organizations due to email marketing being outsourced to disparate third party systems. We’d like to point out that our email infrastructure platform, Momentum, (available in on-premise and managed cloud versions) fully supports both inbound and outbound email authentication – one of the many reasons why the world’s largest senders choose us to send 20% of global legitimate email through Momentum.
Finally, we’d like to end with a note of caution from the audit report: a lack of email authentication exposes businesses to the risk of liability and class action suits in the event of a data breach. If you’re interested to find out whether your email service provider is authenticating your mail, test it with our email Validator – it checks for DKIM, SPF and DMARC email authentication.
It’s our great pleasure to announce that we will be hosting the Online Trust Alliance’s Email Security Training Academy on July 9 at our San Francisco office. As a member of the OTA, Message Systems has made it our mission to continuously educate and promote the adoption of DMARC email standards among our clients and the industry as a whole. We were honored to be placed on OTA’s honor roll for two years in a row, and happy to support OTA’s goal of enhancing online trust in the industry and among organizations.
Covering the fundamentals of DMARC, SPF and DKIM, OTA’s full-day intensive training will include case studies from Microsoft, Facebook, Twitter and American Greetings, as well as best practices for implementing, managing and optimizing email and domain authentication. During training, technical details about deploying SPF, DKIM and DMARC will be discussed and attendees will also come to understand the importance and benefits of implementing and managing email authentication.
We believe that online businesses have a responsibility to protect users from phishing and other email abuse. OTA’s training and guidance has been invaluable to our team and ultimately our customers, said Within 90 days of implementing we were able to block over 100,000 deceptive emails targeting our customers.
Sal Tripi Assistant Vice President of Digital Operations & Compliance, Publishers Clearing House.
Whether you’re an IT or security professional, an email administrator, email marketer or a brand owner, OTA’s email security training offers knowledge for everyone such as:
- Enhancing brand reputation
- Communicating with ISPs on what to do with malicious mail
- Receiving email intelligence reports from ISPs and receiving networks
- Reducing malicious mail
- Optimizing email deliverability and clickthrough
If you’d like to learn more about why protecting customers and your brand from abuse is so important, have a look at the 2014 Data Protection & Breach Readiness Guide released by OTA earlier this year. According to the report, 2013 was the worst year for data breaches with 740 million records being exposed. Sadly, 89% of these incidents could have been avoided with simple security best practices such as DMARC email authentication.
Need another reason to register? Here’s one: The early bird discount ends this Friday, July 4, so be sure to sign up before then. Only 10 seats remain at the moment, so the sooner you act, the better!
Find out about DMARC, DKIM and SPF before you attend OTA’s workshop with the How DMARC Is Saving Email E-Book.
In 2014, the Online Trust Alliance increased weighting on phishing and fraudulent email protection at the top-level domain, and implementation of Domain-based Message Authentication, Reporting & Conformance (DMARC) policies in scoring websites for the annual Honor Roll. After earning this honor last year, we wanted to strive for “valedictorian” this year by continuing to stay on top of these security upgrades.
- We made our Privacy Policies a bit clearer, and we’re already planning on improving them further for next year’s awards.
- We took our website’s score from a 95/100 to a perfect 100 by upgrading our SSL Certificates to TLS 1.2.
- We even strove for extra credit above and beyond the norms by having our product teams work toward perfecting all of our DMARC policies.
We’re also always working toward improving the experiences of all users of our products and sites. In the coming year, we’re adding several awesome new features to the websites and upgrading them to be fully responsive! These things aren’t required by OTA’s Honor Roll this year, but we feel that they may be in the near future. In fact, the 2014 Trust Audit now evaluates variances between websites and their mobile apps on the iOS and Android platforms, in the interest of security controls and privacy best practices.
Thank You to the Online Trust Alliance
Message Systems strives toward a more trustworthy internet. Receiving this honor from the OTA is a welcome pat on the back for those efforts and a significant achievement. Overall only 30.2% of the 800+ sites made the Honor Roll, with 22% making the Honor Roll for the past two years. Conversely, nearly 53% failed in one of the three categories. With this in mind, we will continue to push the envelope year after year.
In addition to reaching this goal ourselves, several of our clients have also been awarded Honor Roll status in 2014. They include:
Congratulations to all our clients, especially Twitter and American Greetings for achieving the best Honor Roll scores!
For more information about the Online Trust Alliance Honor Roll, check out our press release. You can also read the 2014 OTA Honor Roll Report here. For a visual summary of top takeaways from this year’s report, check out the following infographic.
Find out more about how you can better protect your brand with DMARC email authentication. Watch The Benefits of Adopting DMARC Email Authentication webinar today!
Another major mailbox provider has moved to the DMARC policy reject mode due to recent spoofing attacks on its members. Yesterday, AOL announced that it was following in Yahoo’s footsteps with p=reject.
Over the past few days, “You’ve Got Mail” users have complained about hackers gaining access to their AOL accounts and sending many emails with malicious links to their friend lists. The link in the email leads to malware, phishing attacks and viruses. If you have an AOL account, it is highly recommended that you check your sent folder to see if your account is affected. If you see a suspicious email in your sent folder, you need to delete the email and change your account password immediately.
Although the number of affected users is unknown, this attack has received a lot of attention on Twitter with the trending hashtag #AOLHacked. The AOL anti-spam team regard this as a serious attack, and has taken firm action to defend their users (full disclosure: I’m a former AOL employee). In order to stop hackers and cyber criminals, as well as restore trust in their brand, they announced publicly yesterday that their DMARC policy has been changed from (p=none) to reject (p=reject). With this DMARC policy change, AOL will now only allow traffic from AOL.com users through their mail servers. Other providers who honor DMARC policies such as Gmail, Yahoo and outlook.com are now been instructed to reject mail sent on behalf of AOL Mail users via non-AOL servers.
This big step and revolutionary DMARC reject policy was recently initiated by Yahoo following the earlier lead of Twitter, Facebook & Linkedin, and is now followed by AOL. Hopefully, other major mailbox providers will soon follow suit. The Message Systems’ team fully supports Yahoo’s and AOL’s decision to put stricter DMARC policies in place to battle spam and phishing attacks. Our core messaging engine, Momentum, fully supports all authentication methods such as DKIM and DMARC out of the box, and our support and technical teams are available to address any questions and concerns customers might have with regards to complying with these new email authentication polices.
Want to learn more about DMARC? Read the How DMARC Is Saving Email E-Book today!
It’s been about seven months since we launched our Validator tool, so we thought it would be a good time to provide something of a status report. A quick recap: the Validator is an online tool to test outgoing email. It flags and identifies issues or failures for the major email authentication and validation schemes used today, including DKIM (DomainKeys Identified Mail), SPF (Sender Policy Framework) and DMARC (Domain-based Message Authentication, Reporting & Conformance).
The Validator also scans message content for viruses, scans headers, checks for blacklist hits, and performs a series of virus and spam tests. An easy way for high-volume email senders to uncover and avoid potential problems with ISPs, the Validator is a valuable tool to protect sender reputation and ensure high deliverability rates on email campaigns and programs.
So, now that we have two full quarters of usage data, what exactly have we learned? Several interesting trends.
- First, senders using the tool have very good IP reputation. The rate of blacklist hits for the entire six month data set we crunched was .0074%.
- DMARC and the authentication schemes underlying it appear to be gaining acceptance. That is to say, we saw rising rates of test messages that passed for DKIM, SPF and DMARC.
SPF pass rate
DKIM pass rate
DMARC pass rate
Not exactly earthshaking news, but pretty decent anecdotal evidence that DMARC continues to gain acceptance and support in the industry.
Tell Us What You Think
Have you tried the Validator yet? Please share your thoughts with us! We’re eager to hear from Validator users – especially from Message Systems customers who are using it. The first 10 respondents from companies that are current Message Systems customers will receive a $10 Starbucks gift card. Just click on the Validator image below to take a quick survey. We hope to hear from you, and may the odds be in your favor!SparkPost © 2017 All Rights Reserved