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.
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. 1: Generate a DMARC failure report if both SPF and DKIM produce something other than a “Pass” result. This is the recommended option. D: Generate a DKIM failure report if the message had a DKIM signature that failed the evaluation, regardless of why. S: Generate an SPF failure report if the message failed SPF evaluation, regardless of why.
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:
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:
Within this text record, you’d show just a few fields. Here’s an example:
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
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.
Dkim Wizard
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.
Now you can quickly view your DomainKeys, DKIM, and SPF validity, and SpamAssassin score in one place.Just send an email to any address @dkimvalidator.com. Then check here to see the results.
Dkim Wizard Vs
Here is a random address that you can use:
This is useful for verifying the end-to-end functionality of your DKIM and SPF configuration,as well as your actual SpamAssasin score. Since your email is sent through regular mail servers,all of the headers that these tools see are the same as your email recipients will see.
Configuring DKIM from scratch is difficult since it involves changes to your DNS configuration.DNS records are heaviliy cached, so making changes to the DNS configuration often involves waitingfor hours between each test. This tool attempts to look up DKIM records directly from yourauthoritative server on each tests as a way to try to minimize that delay.
A few quick notes about how this works:
- Messages sent to any @dkimvalidator.com address are routed to our Mandrill Inbound mail account
- Mandrill submits the email messages to our server where it is saved for the other tools to read
- We use the Perl Mail::DKIM::Verifier package to display DKIM information
- We use the Perl Mail::SPF package for information about SPF validity
- We use the Perl Mail::SpamAssassin package for SpamAssassin results
- We use the Perl Net::DNS::Resolver::Programmable for some more detailed DNS Lookups
Our SpamAssassin is just a vanilla installation with nothing extra installed.sa-update is run dailyso that the SpamAssassin rules should always be current.
Dkim Wizard Name
It will accept messages sent to anything @dkimvalidator.com. Messages will be deleted a few hoursafter they are received. The message is saved once, and the tests are performed each time you loadthe page. This gives you the opportunity to change your DNS records and check the message againwithout having to resend the message. We try to lookup DKIM and SPF records directly from theauthoritative servers whenever possible.
Dkim Record Wizard
Dkim Dns Record
If you have any questions, comments, or concerns, please feel free to Contact Us