Registering domain names that are similar to an organisation's primary domain or brand is common practice in order to prevent competitors or malicious actors from registering them. Unfortunately the current state of email security means that whilst these registered domains can prevent phishing websites, they are typically left vulnerable to email spoofing.

This is problematic because it can increase the chances that users, both internal and external, will fall victim to a phishing attack. Some of the reasons for why you may face an increased risk include:

• You already use many domains and some users do not pay attention to this. For example Dropbox has over 10 variations of their domain in use.
• Your users are aware that you own this domain and just assume that it is another variation. For example: mail.google.com, gmail.com, and googlemail.com.
• Your filtering system knows that you own this domain and thus doesn't pay attention to it.

You may be thinking that a malicious actor could simply register their own domain or even use a domain that isn't registered. This is absolutely correct, however unlike those domains, you have control over domains you have registered so why not secure them?

Email Standards

Before we go any further it is worth me commenting on email standards and the real world. It is important to realise that there are many implementations of email software and most do no behave the same way. This is due to different interpretations of loose standards, ignoring standards, or otherwise making up things for when there are no standards. Most email software and providers try really hard to make sure your email is delivered which means they will make concessions for all these different implementations.

The end result is:

1. Email security is almost entirely opt-in. If you do not secure a domain, most email providers will happily deliver email for it. In some cases this applies to domains that do not exist!
2. When securing your domains, you may need to implement more than what would be required to account for email software that does not follow the standards.

Securing Parked Email Domains

Securing a parked email domain is similar to securing any domain using SPF, DKIM, and DMARC. If you have not encountered these standards or need a recap, the Australian Signals Directorate and Australian Cyber Security Centre have released an excellent document which covers SPF, DKIM, and DMARC. The document covers these from both a high level down to implementation, which you'll need for the rest of this section as I'm going to get straight into the implementation.

To protect our parked domains we will be setting up SPF, DKIM, DMARC, and MX records. These records can be used on both parked domains and domains that do not send any email (but are still in use in other capacities). These are based of M3AAWG Protecting Parked Domains Best Common Practices.

SPF

The Sender Policy Framework is used to identify which mail servers are allowed to send email on behalf of our domain. In the case of not sending any emails this results in a super simple record of "v=spf1 -all" which means no email servers. This must be setup on the primary domain example.com and, due to email implementations, should also be applied to all subdomains (e.g. *.example.com).

DKIM

DomainKeys Identified Mail allows emails to be cryptographically verified as coming from your domain. When not sending any emails we could get away without having any DKIM records however to allow for email having been sent in the past, or implementation quirks, we can set our records to have no key indicating that it has expired. To do this you will need to set a record of "v=DKIM1; p=" for all identifiers on the domain *._domainkey.example.com as well as all subdomains *._domainkey.*.example.com.

DMARC

SPF and DKIM may not be enough to get email rejected so we use Domain-based Message Authentication, Reporting, and Conformance to explicitly tell mail servers to reject any non-conforming mail. In this case because of our SPF and DKIM records, all mail from our domain and subdomains will be non-conforming.

The simplest record is "v=DMARC1; p=reject; sp=reject;" which must be set on the _dmarc subdomain (e.g. _dmarc.example.com). Although not all email providers implement DMARC, those that do, do so correctly and we don't need to set this record on subdomains.

Optionally you could extend this record to include rua= or ruf= statements in order to receive reports on attempts to spoof email from this domain. At this point the domain may still be able to receive email (due to MX records) which can be used for receiving reports. In the event that a domain cannot receive mail you can direct these reports to another domain, but there are extra configuration steps you will need to follow in order to allow receiving DMARC reports from outside a domain.

MX

Finally we set Mail Exchange records to indicate to email providers that we do not receive email. Some email providers use this as a proxy for if a domain should be sending emails. Due to the way discovery of mail servers works, we set an empty MX record to account for cases where the domain may still have A or AAAA records.

To do this we set a null MX record with a priority of 0 MX 0 .. This would then need to be published on the domain and all subdomains.

Enter domain-park

Doing all of the above can be a lot of work even for just your active domains. If you have hundreds of domains this becomes a huge task for minor gain. There are of course ways to automate this especially if you are already managing your DNS infrastructure as code using tools like terraform. However this still may cost a fair amount of time and money to implement.

Since all these domains will require name servers in order to provide these records, why not create a name server that can handle records for all domains?

This is the exact conclusion I came to and why I created domain-park, a DNS Name Server that implements the above best practices for any domain pointed at it. The server itself is implemented in Python and is available for install via PyPi. The source is available on GitHub.

Public Name Servers

In order to make domain-park as accessible as possible I have created domain-park.org which has public name servers that anyone can use. To use these you will need to set the name servers for your domain to at at least one of the following:

ns1.domain-park.org
ns2.domain-park.org
ns3.domain-park.org
ns4.domain-park.org

It may take up to 48 hours for the changes to take effect as a result of the default caching of records. There is no other configuration required! To confirm the domain is protected you can use checkdmarc which will analyse your domain using public DNS servers. If you wish to test an actual spoofing attempt you can use a tool like emkei's mailer to send an email to yourself from your now protected domain.

Risks, Caveats, and Notes

Depending on the technical maturity and risk tolerance of you or your organisation you may want to avoid using these public name servers. To make life easier below are risks and caveats that you may want to consider beforehand.

By setting the name servers for your domain to my name server, you are giving me almost complete control of your domain. Whilst I cannot steal the domain from you, I am able to set whatever DNS records I want and could use your domain for other purposes. Depending on your risk appetite you may wish to not use the public service, or you may wish to have other monitoring in place to detect if I have attempted to use your domains for anything other than parking them securely.

At the time of writing, the technical maturity of my own services is pretty low. Although I am taking as much care as I can, the service may be prone to downtime or in a worst case scenario the server may be compromised and your domains would be hijacked.

By setting your name servers to a domain-park instance, you will render the domain inoperable. You will not be able to use it for any email (including receiving email), nor will you be able to place any website on it. Due to caching your domain may be affected up to 48 hours after you stop use of domain-park.

In order to operate the service I may keep logs of DNS queries made to the public servers and thus would be aware of any domains that you have pointed to my servers.

In the future I may collect DMARC aggregate reports. I do not intend to collect forensic reports in case these contain any sensitive data. It's worth noting that most email providers no longer send out forensic reports.

If your organisation is interested in using the public servers but have concerns you would like to discuss in private, you can find me on LinkedIn or send an email to info (at) nicholashairs.com.

The Future

Despite the many hours spent bringing domain-park and domain-park.org to life, this is is just the beginning of the journey. What I've released today is very much a minimum viable product, and any continuing work is going to depend on the world finding it useful. On top of general software and documentation improvements, I hope to be able to leverage widespread use of the domain-park.org public name servers to provide intelligence on email abuse that can be shared and used to proactively prevent email abuse.

This has been a pretty deeply technical topic, so thank you for making it this far. If you have any questions, feedback, or concerns you can find me on LinkedIn or send an email to info (at) nicholashairs.com.