Unique to CheckTLS

A number of sites on the Internet will report on some of your SPF/DKIM/DMARC settings. Only CheckTLS will take a real email, from your real email system, lookup your real SPF, DKIM, and DMARC settings, apply them to the email, and report what you sent, what we looked up, and how everything matches up.

Open up "Select Extra Items to Show" in //email/testFrom: ("TestSender") to access these tests.

KnowBe4's Roger Grimes has a good presentation Implementing DMARC the Right Way to Keep Phishing Attacks Out of Your Inbox on DMARC, SPF, and DKIM that describes about How to Configure, Common Mistakes, Best Practices, and How Phishes Still Get By.

SPF / DKIM / DMARC Prove Email is Real

Email has been around since before the invention of the Internet. Email was arguably the biggest benefit of the early Internet. The early Internet was a technical thing, run by technical people, and hard to use.

Those three things worked together to prevent all of the bad things that now plague Internet email: things like spam, phishing, and embedded malware. Because it was new, these abuses had not been discovered or invented yet. Because it was hard to use, it was not easy for abusers to do their thing. Because it was run by technical people, it was easy for honest techs to root out abuse. Because it was was a technial thing, there was no dark web or hacker tools, so abuse was difficult.

As with all good things, Internet email became easier and more wide spread. Lots more wide spread. Which makes it a very inviting target for abuse.

SPF, DKIM, and DMARC are additions to Internet email that make it more difficult for abusers. They are technical things, so they put some control back in the hands of techs. But they require technical expertise to implement.

SPF limits which computers can send your email.
DKIM makes sure your email isn't changed after you send it.
DMARC says what to do about emails that SPF or DKIM discover are bad.

The US Government mandate to make federal communications more secure (CNN article) has made DMARC testing a hot topic.


SPF, Sender Policy Framework, connects your domain name with your IP address.

With plain old email, it is easy for someone to send an email that says it is from you. But Internet routers make it very difficult to send data that says it is from your IP address. If we compare email to a physical letter, your name is the first line. Anyone can put your name on the first line. But your IP address is your street/city. Like a super postmark, it shows exactly where the email came from.

SPF is a special entry in the Internet DNS Domain Name System database that tells the world that email that says it is from your domain can only come from certain IP address(es). DNS, like your IP address, is difficult for someone to modify or spoof.

So if someone sends an email that purports to be from you, the receiver can look at where the email came from and compare that to where SPF says it is allowed to come from.

The //email/testFrom: ("TestSender") CheckTLS test can report on your SPF. For example, the SPF settings in CheckTLS's DNS report as:

SPF_mfrom.Record:v=spf1 a mx -all
SPF_mfrom:pass: local="checktls.com: is authorized to use 'checktls.com' in 'mfrom' identity (mechanism 'a' matched)"
SPF_helo:none: local="www6.checktls.com: No applicable sender policy available"


DKIM, DomainKeys Identified Mail, signs your email with a public/private key signing process. DKIM takes the important headers and the content of your email and runs them through a mathmatical transformation and public/private key encryption algorythm. The result is a string of characters that:

  1. uniquely represents the important headers and the content of your email
  2. cannot be altered without breaking it
This string of characters is added in a new header to your email before it is sent.

The receiving email system looks up your public encryption key from a DNS DKIM entry and uses it to decode the new header. It then does the same mathematical transformation of the important headers and the content of your email and compares what it computed with what it decoded. If they match, the receiving systems knows that the email was not changed in any way.

The //email/testFrom: ("TestSender") CheckTLS test can report if your emailer is sending properly DKIM signed emails. For example, the DKIM settings in CheckTLS's DNS report as:

DKIM:pass: signature="@checktls.com" result="pass"
DKIM_policy.sender:"o=~"(default), result="accept"
DKIM_policy.author:"o=~"(default), result="accept"
DKIM_policy.ADSP:""(default), result="accept"

If the email had been altered somehow in transit, the DKIM settings in CheckTLS's DNS would report:

DKIM:fail (body has been altered): signature="@checktls.com" result="fail (body has been altered)"


DMARC, Domain-based Message Authentication, Reporting, and Conformance, enhances SPF and DKIM, and gives you more control over them. With DMARC you publish rules for SPF and DKIM: which one(s) to consider, how to consider them, and what to do if something is amiss.

DMARC is especially useful for larger domains because it is a means for receivers to send you information about problems they find with your emails. This can give you early notice that someone is doing something evil with your email domain.

The //email/testFrom: ("TestSender") CheckTLS test can report how your email looks to DMARC and what it is set to do with it. For example, the DMARC settings in CheckTLS's DNS report as:


Some other on-line DMARC testing services show mis-leading warnings and urge you to purchasing something. //email/testFrom: shows you the inner workings of your setup so you can see if it is setup correctly, and so you can debug and optimize it. //email/testFrom: works on real emails that you've sent, letting you know how your email is being seen and handled by the Internet at large.