SPF and DMARC use on GOV domains in different ccTLDs

Published: 2022-12-30
Last Updated: 2022-12-30 15:43:16 UTC
by Jan Kopriva (Version: 1)
4 comment(s)

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
Nettles Consulting

Keywords: DKIM DMARC Email SPF
4 comment(s)


In the commercial spaces where I work I feel like DNS hosts would need to take an active role in creating these DNS records for any change to happen. For example, Google Workspace and Office 365 can connect to a DNS host to setup the DNS records automatically for their services to work on a new domain. There is no reason they cant also put the DNS records in place for SPF and DKIM if they do not already exist, but these don't. A simple "do you plan on sending email from this domain" question before you hit the button to put those DNS records in place could determine if the DNS record should be a block or a basic default setting. DMARC is a little trickier because you really should have someone or some service interpret the reports but if DKIM and SPF are working then email should do well.

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. :)
If only I could edit my comments, haha. In regard to the return-path in my previous comment I was referring to the fact that many bulk email service providers use bounce management so if you send me something from your server the return path will be from your domain but if you send me something from Mailchimp or some bulk platform the return-path will be their domain. This would allow email to be easily categorized as direct, bulk, or spoofed (I realize I said spam previously but I meant to say spoofed/fake).
Denmark is a NATO member, and we do not have .gov.dk domain. BUT, we have a requirement that all government institutions MUST use DNSSEC on their zones, the MUST use DMARC REJECT, and finally, they are only allowed to send mails using a minimum of TLS 1.2 encryption.

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"
TL;DR In my view, the major challenge with any DMARC implementation is 'R' - reporting. Has anybody got a positive experience of using Open Source DMARC reporting tools, e.g. [4],[5]?

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

[1] U.S. DHS BOD 18-01

[2] UK Government Central Digital and Data Office (Cabinet Office) Guidance

[3] List of .gov.uk domain names

[4] parsedmarc

[5] UK National Cyber Security Centre Mail Check Open Source

[6] Information Disclosure

Diary Archives