Overview

Ensuring that your domain isn’t used maliciously for sending emails can be a battle at times, especially since you don’t have any control over what remote systems send and if they can try and claim to be from your domain or not.

While most mail servers do a good job of determining the legitimacy of where emails originated from, some mail systems still accept fake emails and can exploit this fact to send phishing emails by using your domain name. This of course becomes important to ensure you protect your brand reputation.

The steps below covers our recommendations to protect your domain and email reputation.

Step 1: Ensure the basics are complete

We have a guide on Optimising Email Deliverability, which covers the basic steps to ensure details such as SPF and DKIM signing have been completed for your domain.

This offers about 98% of the total protection possible.

Without these critical steps, none of the steps below will offer you any meaningful protection.

Step 2: Set Ensure your DMARC record covers subdomains

We cover the setup of DMARC in our dedicated support article, which steps you through the various configuration options as the record itself is quite complex. Unlike SPF and DKIM, DMARC implicitly covers subdomains and provides the same protection specified as the main domain.

However, if you don’t send from any subdomains or you have explicit DKIM and SPF records for these subdomains, you can set the subdomains to reject:

sp=reject

If you have the root domain key (signified by “p”) set to reject, the above record isn’t necessary. However, many have it set to quarantine instead.

Step 3: Set blank SPF and blank DKIM signing

If you have a domain which won’t ever be sending email (eg you may have a .com and a .com.au for your company name but only the .com.au is used for email), you can set blank SPF records and blank DKIM signing records to ensure no mailserver ever validates any emails from that domain.

SPF TXT record:

v=spf1 -all

This tells any remote system that there are no valid senders for the domain.

Likewise, we can configure a null DKIM value in our DNS for the TXT record:

v=DKIM1; p=

The empty public key (the p= part) tells the mail server validating the email that the key has either been revoked or expired and therefore reject the email.

Both records can also optionally be set as wildcard records to cover any attempts to use subdomains which don’t exist.

Step 4: Use null MX records for domains without email

A null MX is a specific type of DNS record (detailed in RFC 7505) which explicitly tells a mail server that there’s no email for that domain.

<yourdomain.com.au> 0 .

Instead of specifying a server, a dot (.) is used to signify not to attempt any delivery to that domain. This can also be set as a wildcard record for systems where there’s subdomains as well:

*.<yourdomain.com.au> 0 .

Note

Currently, Conetix doesn’t support null MX records due to a limitation in Plesk. We will update this article once there is support.

Step 5: Use a DMARC rejection monitoring service

One feature of DMARC is the ability to send any non-compliant emails off to a specific email address to be reviewed. Currently, this is one of the most misunderstood parts of DMARC and we see hundreds of thousands of emails bounce as the report address has either changed or contains spam filtering (it’s the one mailbox where this must be turned off!).

Unless you’re using a proper DMARC monitoring service, we very strongly advise you to leave this reporting turned off.

Most of the monitoring services aren’t free, so you’ll likely need to subscribe to a service to set this up. Here’s a list of services (in no particular order) to get you started:

Further Reading

Was this article helpful?

Related Articles