DMARC does not only protect your email domains in use. It can be used to protect what are called “cousin” domains.
Many organizations will own a variation of their domain (or “cousin” domain) in order to prevent others (potential malicious users) from using a version of the organization’s name. This is a great preventative measure for all organizations to take. For example, an organization may actually utilize .com for their website and email domain, but they may also own the .net, .org, .gov, etc. version.
You can still protect these domains by using Sender Policy Framework (SPF) and DMARC, even if they are not being used for email. Just because you own the domain doesn’t mean it can’t be spoofed or used in a phishing attack.
The best part is that only two steps are necessary:
1. Implement SPF
The SPF record in DNS will look as follows:
Domain.net. 7199 IN TXT “v=spf1 -all”
Domain.org. 7199 IN TXT “v=spf1 -all”
Since no IPs or domains are indicated in the record, that means no systems are authorized to send mail using that domain.
2. Implement DMARC
The DMARC record in DNS will look as follows:
_dmarc.domain.net. 7199 IN TXT “v=DMARC1; p=reject“
The policy indicates that any messages that fail SPF and/or DKIM should be rejected (as in not delivered at all). Since the SPF record has no servers, and DKIM doesn’t exist, then DMARC will let the recipient know to reject the emails.
If you want to take a step further, you can add the rua and ruf tag. This way if a report is generated, then you know when and if those domains are being used for spam or phishing. However, since these domains are not used for email, then where do you send the reports? You can send the reports to another domain that uses email, but that domain can not just accept reports. The other domain must create the follow record in DNS:
domain.net._report._dmarc.receivingdomain.com. 7199 IN TXT “v=DMARC1;”
Repeat each of the steps above for each domain you own and is not used. Once complete, you are now protecting those domains as well.