SPF and DMARC use on GOV domains in different ccTLDs
Although e-mail is one of the cornerstones of modern interpersonal communication, its underlying Simple Mail Transfer Protocol (SMTP) is far from what we might call “robust” or “secure”[1]. By itself, the protocol lacks any security features related to ensuring (among other factors) integrity or authenticity of transferred data or the identity of their sender, and creating a “spoofed” e-mail is therefore quite easy. This poses a significant issue, especially when one considers that most ordinary people don’t tend to question the validity of officially looking messages if it appears that they were sent from a respectable/well-known domain.
Even disregarding the current geopolitical situation, it is clear that certain domains are of significantly higher interest than others to criminals as well as state-sponsored actors when it comes to spoofing e-mail. Among the more interesting ones are – without a doubt – governmental domains, i.e., domain.GOV in the US or domain.GOV.ccTLD in other countries. Which brings us to the topic of today’s diary, which is “how big of an issue e-mail spoofing might be for these particular domains”.
But first things first. Because of the aforementioned lack of "integral" security features, numerous extensions and additions to SMTP were introduced over time that were intended to add different security mechanisms to it – either on end-to-end or hop-to-hop (or originating server to recipient server) basis.
Three of these additions, which deserve special attention from any domain owner, are SPF[2] , DKIM[3] and DMARC[4], which enable domain owners to specify which servers are “allowed” to send e-mail for a specific domain, and implement a corresponding verification and reporting framework. In general, it is considered a good practice to ensure that special SPF, DKIM and DMARC DNS records are set (and corresponding mechanisms and keys are configured on relevant mail servers) for any domain which is going to be used for sending e-mail.
“Enabling” SPF is relatively straightforward, however making sure that DKIM (and, potentially, DMARC) functions correctly is somewhat more complicated. This is the reason why SPF adoption is much wider than it is for either of the other two mechanisms[5].
It is worth adding that it is also considered a good practice[6] to set “blocker” SPF and DMARC DNS records for any domain, that is not going to be used for sending e-mail. These have the following contents and specify that no server is allowed to send e-mail on behalf of the particular domain.
SPF record (TXT record published for domain.tld):
v=spf1 -all
DMARC record (TXT record published as _dmarc.domain.tld):
v=DMARC1; p=reject;
With this short overview out of the way, it should be clear that for any gov.ccTLD domain, at least a valid SPF DNS record (though, ideally, DKIM and DMARC records as well) should be published, even if it was just a “blocking” one.
To discover what percentage of second-level GOV domains actually employ the aforementioned security mechanisms, I wrote a short script that identified ccTLDs in which such domains existed, and gathered and evaluated the corresponding SPF and DMARC records, if these were published (determining whether DKIM is being used by a specific domain is unfortunately impossible without direct communication with the corresponding e-mail server, so no data could be gathered regarding support of this mechanism).
The results were…interesting, if not necessarily optimistic.
A second-level GOV domain existed in 178 of the 247 ccTLDs listed on Wikipedia[7], but only 78 of these gov.ccTLD domains (cca 45%) had an SPF record published. Furthermore, records for 5 domains were either malformed or did not contain an explicit “all” directive, which made them effectively meaningless. Only 33 domains (cca 19 %) had a valid DMARC record published.
You may see detailed results for DMARC and SPF support on the GOV domains in different ccTLDs in the following charts.
Since – as we mentioned – these results were not overly positive, I’ve filtered out only NATO and EU countries hoping that the numbers would look somewhat better for their ccTLDs. However, as you may see from the following chart, results for these countries were not significantly better (in fact, in some areas, thay were a little worse)...
As the previous charts show, SPF and DMARC (and most likely DKIM as well) use on second-level governmental domains in ccTLDs around the world is far from optimal, and even a less sophisticated threat actor could therefore easily spoof e-mail for these domains…
Which is unfortunate, to say the least.
It should be mentioned, however, that the fact that second-level GOV domains are often not used for anything by themselves probably had a negative impact on the results. In many – If not most – ccTLDs, only third-level domains (e.g., domain.gov.cctld) are actually being used by governmental organizations. In such cases, the third-level domains may well have SPF, DMARC and other security measures configured in accordance with good industry practice, however since the second-level GOV domain is not actually being “used” on its own, no one might have realized the need to make sure that no one can “misuse” it either, at least by setting up relevant “blocker” records, such as the ones we mentioned above.
To end on at least a slightly positive note, 8 of the second-level GOV domains actually had just such a “blocker” SPF record published, which is perhaps more than one might expect.
[1] https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
[2] https://www.rfc-editor.org/rfc/rfc7208.html
[3] https://www.rfc-editor.org/rfc/rfc6376.html
[4] https://www.rfc-editor.org/rfc/rfc7489.html
[5] https://redhuntlabs.com/blog/internet-wide-study-state-of-spf-dkim-and-dmarc.html
[6] https://www.cloudflare.com/learning/dns/dns-records/protect-domains-without-email/
[7] https://en.wikipedia.org/wiki/Country_code_top-level_domain
-----------
Jan Kopriva
@jk0pr
Nettles Consulting
Comments
One person's opinion is that the only domains listed in the SPF should be those in the return-path in the header, ie your email servers, meanwhile you cryptographically sign every single email (DKIM) and closely monitor those DMARC reports (which small businesses and most domain owners are will probably never do until someone makes this easier). Then I can easily categorize direct email vs bulk email vs spam. :)
Sam
Dec 31st 2022
1 year ago
Sam
Dec 31st 2022
1 year ago
We have a force-TLS policy on all outgoing domains, but have some exceptions for vendors in Asia, France used to be a problem (Old monopolistic former governement owned telecoms are the worst). Our biggest problem is that almost no polish authorities can accept SMTP-TLS mails. Cities, police, legal system etc. The Polish administration seems to be our least secure "partner"
PHP
Jan 2nd 2023
1 year ago
Back in July 2018 I've done a similar analysis for UK Local Authorities, excluding Parich Councils [3]:
DMARC Policy
• reject: 2%
• quarantine: 11%
• none (monitoring): 11%
• no DMARC policy: 76%
SPF Policy
• -all: 32%
• ~all: 31%
• ?all: 8%
• wrong SPF record: 1%
• no SPF: 28%
Although, strictly speaking, UK Government Digital Service guidance [2] doesn't apply to Local Authorities, it has updated promptly [2.1] to remove the requirement to pass an assessment in April 2018.
U.S. Department of Homeland Security Binding Operational Directive 18-01 required federal agencies to set DMARC policy p=reject for all second-level domains and mail-sending hosts by 16th October 2018.
I'd guess accountability is too expensive to maintain, and Binding Operational Directives aren't that binding.
DMARC Challenges:
• If the implementation isn't well planned, there is a risk of cutting off transactional email. This is something no entity can afford
• Planning and implementation does require a lot of human interactions which is expensive
• It's not a trivial subject to comprehend. Various parts of The Internet Bible (IETF RFCs) are written by different people. Independent authors are free to cherry pick whatever seems appropriate for their needs (RFC5321.MailFrom by SPF vs. RFC5322.From by DMARC and DKIM), and frequently talk about the same thing in different words.
• Some popular reporting tools [6] may leak information about entity's email traffic patterns without any consent and for no good reason
References
~~~~~~~~~~
[1] U.S. DHS BOD 18-01
https://cyber.dhs.gov/bod/18-01/
[2] UK Government Central Digital and Data Office (Cabinet Office) Guidance
https://www.gov.uk/guidance/set-up-government-email-services-securely
https://www.gov.uk/guidance/securing-government-email#full-publication-update-history
[3] List of .gov.uk domain names
https://www.gov.uk/government/publications/list-of-gov-uk-domain-names
[4] parsedmarc
https://domainaware.github.io/parsedmarc/
[5] UK National Cyber Security Centre Mail Check Open Source
https://github.com/ukncsc/MailCheck.Public
[6] Information Disclosure
https://eu.dmarcian.com/dmarc-data-providers/?_ga=2.125615754.1676040333.1649344600-1505189905.1646852422
王維
Feb 8th 2023
1 year ago