This is no doubt the driest and most technical topic in my list of “Email Deliverability 101” articles, so rather than ask you to buckle down as I slog through 19 years’ (!) worth of RFCs and competing standards, I’ll just skip that whole chore and instead briefly link to this history of SPF, and this brief description of DKIM, and these notes about DMARC.

Still with me? If so, let’s jump straight into the practical matters:

Do I need to set up all three, SPF, DKIM, and DMARC?

Yes, assuming you want to send marketing or commercial email, you’ll need all three. DMARC, in fact, relies on SPF and DKIM.

None of these are particularly difficult or time-consuming to set up, though.

Why should I care about any of this?

Having properly-configured email authentication headers can improve your inbox rates. Furthermore, authentication can prevent malware and phishing attacks from being spoofed to your customers.

If your brand name or organization is large enough to be familiar, you should definitely implement all these security policies. This will prevent spammers from exploiting your good name for malicious ends.

Jump to: [ SPF | DKIM | DMARC ]

SPF Reference for Beginners

How do I set up SPF?

Implementing SPF is as easy as adding a text record (technically called a TXT record) within your DNS zone file. Your Ops/IT team already has to maintain the DNS information, so really the only new challenge here is figuring out the contents of this new TXT record.

The contents of the TXT record can be generated by one of these SPF “wizard” systems: MX Toolbox, SPF Wizard. You will first need to make a list of everyone who sends mail on behalf of your domain. If you send all your email through an ESP, the ESP’s support staff should be able to provide a complete SPF record.

After your new SPF data has been saved to the DNS system and propagated (which could take more time, depending on the TTL or “time to live” settings within the zone file), you can test the new record using these tools: MX Toolbox, DMARC Analyzer.

Sample SPF Record With Explanation

Here’s a sample record and term-by-term explanation:

v=spf1 mx a ip4:192.168.1.0/24 include:example.com -all

The first term, v=spf1 , simply indicates the version of SPF syntax used herein. There is no other version than spf1 as of this writing, which means every SPF record begins with this term.

The mx term whitelists the IPs named within the mx (mail exchange) record of this domain’s zone file. Similarly, the a term whitelists all address records of the zone file. Use these options if, for example, the webservers for your domain generate email to users.

The ip4 term whitelists an arbitrary IP address or range. For example, you could state your own network here.

The include term is used to identify a third-party network that sends mail for you. We recommend using domain names rather than IP addresses here. This insulates our SPF record from IP range changes made by partners.

The all term of the record tells remote ISPs what to do with messages that don’t match any of the terms in the record. SPF can instruct ISPs to accept the mail, or reject it, or accept it with a “spoofed” flag.

The most strict setting, -all , tells ISPs to reject any mail that is not specifically allowed by the terms of the SPF record. But this will block most forwarded mail. That is, if your subscribers forward your emails to friends, those forwards would likely bounce if you use the -all rule.

The setting least likely to block mail delivery is +all. This option negates prior restrictions. It instructs remote ISPs to accept mail bearing your domain from anybody in the world. Further, it states that all such uses are approved by you. +all is a free pass for spoofing; therefore, don’t use it. Also don’t use all without a prefix symbol, because the default interpretation if no symbol is explicitly provided is +.

The ?all option is interpreted as “neither pass nor fail.” This is a good option for new SPF records for a trial/debug period, to ensure that you don’t inadvertently block legitimate mailstreams due to SPF misconfiguration.

The least restrictive, somewhat safe option is ~all, which is described as a “soft fail.”

In practice, most high-volume senders should probably end up with ~all or -all, depending on how much legitimate forwarding they have, and how many spoofed/phishing campaigns they face. (For reference, Paypal and LinkedIn use ~all , while Facebook and Amazon use -all .)

If you run into questions regarding SPF setup, contact us; email security and authentication configuration is one of the services we offer.

DKIM Reference for Beginners

Setting up DKIM is both easier and more complex than SPF. There is less need (or, really, no need) to research your email infrastructure to list the authorized servers and domains that can send mail on your behalf, but you will need to generate a cryptographic key pair, and post the public key to your DNS record, and configure your outbound mail server(s) to “sign” outbound mail with the private key.

You’ll also need to think of a “selector,” which can be any arbitrary short string such as “key1” or “dkim1”. It doesn’t matter what you use, but it’s best to pick something you can remember, because you’ll need it when you test your DKIM setup later.

There are numerous ways to generate a key pair. One easy way is to use Port25’s key pair generator.

Then look up your mail server (MTA) documentation to learn how to configure it to use the private key to cryptographically “sign” outbound messages.

The final step is to contact your pals in the IT group to have them add yet another TXT record to your DNS zone file — this time with the DKIM selector and public key.

Sample DKIM Record With Explanation

The record name includes your selector, plus the subdomain _domainkey. For example, if you chose “dkim1” as your selector, your resource record name would look like this:

dkim1._domainkey.example.com

Within this text record, you’d show just a few fields. Here’s an example:

"v=DKIM1\;k=rsa\;p= ... "

The first term is is the DKIM version number, which as of this writing is v=DKIM1 . The second term (k) identifies the cryptographic algorithm used to generate the public/private key pair. For the Port 25 wizard, the value would be “rsa”.

The third term (p) is the public key itself. I’ve omitted it here; it is necessarily different for every sender.

Testing Your DKIM Configuration

You can run a syntax check on your DKIM resource using MX Toolbox. But a better test would be to actually send mail to a tool that will use the key pair to validate your MTA’s behavior. The Port 25 wizard will do this for you; instructions appear at the bottom of the page after you generate a key pair. (Even if you’ve already configured your keys, use the tool to generate another key pair just to see the testing instructions.)

DMARC Reference for Beginners

Setting up DMARC is simple, compared to SPF and DKIM — but it leverages those systems, so you need to do those first. (If you’re interested, the DMARC website contains a nice graphic overview of how these three authentication systems work together.)

Configuring DMARC means generating yet another TXT record for your DNS zone. You can find online “wizards,” but this one is so simple that you could do it manually too.

The first step is to decide whether you have, or someone on your staff has the bandwidth to review DMARC policy warning emails (aka “forensic DMARC failure reports”). Remote ISPs will send these messages when they detect unauthorized use of your domain.

If you want to do this, create a mailbox on your domain, e.g. dmarc-reports@example.com . We’ll use this in the DMARC record.

Sample DMARC Record With Explanation

"v=DMARC1\; p=reject\; pct=100\; rua=mailto:anyaddress@example.com\; ruf=mailto:dmarc-reports@example.com\; aspf=r\;"

DMARC provides two levels of reporting: individual forensic reports, sent to the address in the ruf parameter, and aggregate reports, sent to the address in the rua parameter. The ruf address should be on the same domain that you’re sending mail from.

The most important term here is the policy (p), which will be either none , quarantine , or reject . New DMARC configurations should typically be set to none , as this allows all mail to be delivered without interference.

Once you have set up appropriate monitoring of the various individual forensic and aggregate reports, and you are confident this record is not likely to block legitimate email, you can change the policy to quarantine , or eventually to reject , depending on your needs, and the amount of spoofing your domain experiences.

If you are struggling to configure any of these headers, or you need assistance testing them to make sure they’re doing what you expect, please reach out; email authentication configuration and monitoring is one of the services we offer.