At SparkPost, we love email. The way you feel about those pictures of your cat you posted on Instagram? That’s how we feel about email. But we know not everyone shares our excitement about email RFCs. Which is why we work to share our knowledge of email standards and make sure that setting up and sending email is as easy as possible for as many people as possible. Except for you, Mr. Western Union scammer.

Email has grown a lot over the past 40+ years and along the way several standards have cropped up, meant to combat spam, phishing, and spoofing. Keeping up with these standards and implementing them correctly can be tough. On the flip side, setting them up the wrong way can really hurt your business. Set up incorrectly, your email won’t get delivered or, more dangerously for your customers, will let any malicious sender impersonate you online, even to the point of letting someone change your content while it’s in flight.

That’s why today we’re happy to announce the release of three new tools for building and verifying the state of your email. I’ll walk you through each of them quickly and how they can help you win the trust of ISPs and your users.

DKIM Validator

DKIM is a content authentication standard meant to let ISPs (Internet Service Providers, the ones who manage the inboxes you send to) verify that the email you sent is the one they received and that no content has changed since it left your system. DKIM requires you to set up a special DNS record with a public key and other metadata that receivers use to verify the content of the message they receive.

Our DKIM Validator lets you safely verify that your DKIM is set up correctly. It will give you a unique email address; send to that address from your domain (through the system you’re validating) and we will check your DNS entry and make sure the email we received complies with the DKIM policy you set up. We’ll even give you recommendations if we find something that could help you out.

Find something surprising in the results and want to share them? We got ya covered: all results are deep-linkable for easy sharing (click the “Share” button, and we’ll even put the URL in your clipboard).

Not sure about any of this DKIM stuff? Sign up for a SparkPost account and we’ll take care the hard parts for you.

SPF Builder

SPF is a standard used by ISPs to verify that an email addressed “from” your domain is coming from a server that you’ve specifically said is allowed to send for your domain. Setting up a correct SPF DNS record is one of the best ways to combat spoofing attacks and keep your email reputation high.

The thing is, SPF is deceptively complicated. There are only a handful of simple mechanisms in the SPF standard, but when they’re combined into your domain’s record, it soon becomes a complicated tree of hosts, any of which can send for your organization. It’s quite easy to be too broad and leave yourself open to spoofing attacks, or be too narrow and have your email appear to be illegitimate.

That’s why we made the SPF Builder – it will walk you through a series of simple questions to build out your SPF record. You don’t need to know any special syntax, we’ll translate everything for you and even copy it to your clipboard for easy pasting into your favorite DNS provider!

SPF Inspector

Whether your SPF record came from our builder or is artisanally hand-crafted, it’s good to check the validity of your record once it’s live. Our new SPF Inspector will not only verify your record’s syntax (and the syntax of any others you’ve included), it will also show you all IPs and hosts that are allowed to send on your behalf. If we find anything wrong, or slightly not great, we’ll give you a heads up along with some pointers on how to fix what’s not quite right.

All your results are shareable, just like the DKIM Validator. In addition, if you are signed in to your SparkPost account, we’ll keep a history of the domains you inspect over time. That becomes really useful as you start to manage and send from several domains.

Find SPF too confusing? Send through SparkPost and we’ll handle all the messy SPF details for you!

Go Check ‘em Out

We’re really proud of these SparkPost email tools and we think they will make your life easier and your email better. Do you have ideas for other tools that would help you send better email? Let us know on Twitter, Slack, or in the comments!

— Cole Furfaro-Strode

Here’s the full press release on the SparkPost email tools

DMARC passport

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.

RFC5322.From Domain

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 <sales@joesbaitshop.com>

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.

Return-Path 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:

Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@sparkpostmail1.com>

We are contemplating giving our customers the ability to personalize this domain in the future.

Organizational Domain

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.

Domain Alignment

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:

  1. Figure out the message’s RFC5322.From domain
  2. Look up that domain’s DMARC policy in DNS
  3. Perform DKIM Signature validation
  4. Perform SPF Validation
  5. Check domain alignment
  6. 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:

  1. Making preparations to receive DMARC reports
  2. Deciding on what DMARC policy to use for your domain
  3. 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 agg_reports@yourdomain.com and afrf_reports@yourdomain.com. 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:

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:agg_reports@joesbait.com is the mailbox to which aggregate reports should be sent
  • ruf=mailto:afrf_reports@joesbait.com 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.

Summary

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!

—Todd

Weekly Email Marketing News Digest

One of the biggest tech news this week has to be the phenomenal rise of Netflix’s stock price to more than 40% since Wednesday. Some have called it the triumph of legacy media over new media – Netflix’s international subscribers grew by 229% last year and the company gained 2 million domestic subscribers. Just as reports of the demise of big entertainment are greatly exaggerated, so too are those that predict the end of email. In the world today, it’s no longer about marketing in winning silos, but integration and convergence.

And it’s also about listening to your customers.

Email Marketing: Why don’t you want to hear from your customers?

Note: This email was automatically generated from a mailbox that is not monitored.

Looks familiar? We’ve probably all seen this at some point in our inbox. Most likely, it’s a transactional email that companies send with your personal information included to remind you of a flight you booked or money you withdrew. In some sense it’s a highly personal email. On the other hand, it’s become incredibly impersonal for something that contains such delicate personal information.

Having a no-reply email means a missed opportunity for marketers to connect with customers that want to reach them. It’s like telling them to talk to the hand. Do that, and you could be losing some serious upsell opportunity.

Email-Social Integration: Past, Present and Future

We’ve seen a great example from Bonobos on how the company is using an innovative tactic to integrate email and social. Here are 5 other things a business can do:

1. Sharing email content into social streams.
2. Email acquisition via social channels.
3. Socializing email content.
4. Using social sign-in for account registration/opt-in.
5. Social CRM.

Personalization key for email in 2013

Personalization was big news in 2012, and it continues to be big news in 2013. You know what else is key? Email and mobile integration. Julia Rieger, Director of Marketing, LiveIntent says:

“Along with the rise of ‘Smartphones’ has come a resurgence of email as the primary tool for information exchange.  The first thing that most people set up on a new Smartphone is going to be their email accounts.

As the email address continues to gain in importance as the unique identifier necessary for joining and using services like Facebook, Twitter and Instagram, former detractors will come to realize that email isn’t something to fix, it’s something to leverage to create greater engagement.

Beyond its messaging applications, email addresses retain their position as unique identifiers and database primary keys and as such key ingredients for ‘big data’ and CRM.”

We agree and we’d go one step further to declare that a marketer who is going to be a runaway success is one that integrates email, mobile and social into one seamless messaging stream.

Key Email Engagement Tactics: Benchmarks and Trends

A study has found that 50% of marketers are planning to optimize email campaigns for the mobile experience. Their plans include developing a rich-text mobile version (36%), promoting mobile apps (21%), and optimizing email dimensions (18%). Other findings:

• 71.5% of marketers are inviting subscribers to fill in surveys through email. 25% of these surveys are opt-out surveys, where marketers try to glean some info on why these customers are unsubscribing.
• More than 52% of marketers have used gifs in their campaign and the report states that gifs are a good way to attract attention.
• 21% of marketers use symbols in subject lines – a study has found that it could increase open rate by more than 15%.
• When it comes to social integration, Facebook (98%) is the number one platform, followed by Twitter (91%) and YouTube (45%).

Industry slow to adopt DMARC email standards

For those of you not in the know, DMARC was created by a group of companies, including our partner, Return Path, to set certain standards to reduce online security threats such as phishing. As our Chief Revenue Officer, Ralph Lentz notes:

“If you’re a bank, retailer, publisher or any kind of brand, do you want your email to be the only message in your customer’s inbox not flagged as DMARC-secure?”

While the speed of adoption by the industry may be in a grey area, adoption by the email community has been rapid. As of now, it is an email marketing best practice, but in a few months, it might not even be a choice for marketers, as all the leading gatekeepers such as Google, Microsoft and Yahoo are already on board.

Is your company’s email DMARC secure? Are you effectively integrating social, mobile and email? We’d love to hear from you in the comments section! Or you could find out more about DMARC when you download the How DMARC Is Saving Email eBook!

How DMARC Is Saving Email