One issue in controlling fraudulent Email with all of the above technical controls, SPF, DKIM and DMARC, is they are only effective on domains you control. If you don’t own or control a domain then clearly you cannot publish an appropriate DNS record to control spam quoting that domain name. SMTP even allows mail to be sent quoting a domain name that does not exist at all, although ISPs may check for the existence of a domain and suitable MX and rDNS records as part of their spam checks, however, this is very dependent upon the ISP or receiving Email infrastructure.
Consequently it is important to protect your organisation’s name or brand by securing variations on your name and ‘parking’ these domains. The idea of a ‘parked domain’ is that having secured the domain, you can set SPF, DKIM, ADSP and DMARC records to all indicate the domain sends no Email, thereby denying a fraudster the opportunity to use the name to launch a fraudulent Email attack against your organisation and your customers.
Your ‘parked domain’ list can quickly become a long list and requires some thought about variants on your name or brand. So for instance, not only are there variants in top-level domain names (TLDs) and country code top-level domain names (ccTLDs), i.e. .com, .net, .org, .co.uk, .org.uk, but the name may be represented in different ways by introducing hyphens, suffixes or even common misspellings. For example the domain name creditcardbrand.co.uk might be represented as credticardbrand.co.uk or something ‘more creative’ such as creditcardbrand-offers.co.uk.
It can require a degree of ‘lateral thought’ in identifying potential names that could be abused and of course sometimes an organisation’s own marketing efforts can be all-too effective in creating legitimate variants of an organisations’ name which only assist fraudsters in duping customers with ‘dodgy domains’ of their own creation.
Sadly the explosion in top-level domains acts to make such ‘brand protection’ yet more complex.
*.example.com. IN TXT "v=spf1 -all"
_domainkey.example.com. IN TXT "o=-"
_adsp._domainkey.example.com. IN TXT "dkim=discardable;"
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100;
- The first record is an SPF record including no servers and a ‘hard SPF’ mechanism of -all, therefore defining that there are no legitimate mail servers sending mail for the domain (the domain sends no mail) and all mail should be rejected
- The second record is a wildcard SPF that covers all subdomains, thereby preventing attempted use of invented sender addresses such as email@example.com
- The third record is a DKIM record saying that the domain signs all its Email (o=-). DKIM does not of course define an action a recipient should take should a message fail a DKIM check; this is picked-up by the third record…
- The fourth record is an ADSP record defining that the domain signs all mail and advising the receiver that unsigned mail or mail failing a signature check should be discarded
- The fifth and final record is a DMARC policy to reject (p=reject) 100% of failing Email (pct=100). It also defines an aggregate reporting Email addresses so that the domain owner can gain insight to the handling of Email quoting the domain name (note the record is wrapped only to aid reading and would ordinarily be entered into DNS as one single text string)
The combination of these four settings should advise any recipient that this domain should not be sending any Email and anything received quoting the domain can be considered to be fraudulent and should be rejected / deleted.
Note that while SPF permits the setting of a wildcard record so that the ‘no Email’ setting can apply against any invented subdomain an attacker might attempt to use, this isn’t possible with DKIM, ADSP and DMARC all of which use domain name prefixes and so preclude the use of wildcard records.