Secure your domains that don't send email

“I’m not using this domain for email, so i don’t have to configure it.”

Wrong. In this post I’ll show why you should put in some configuration for that domain you do not use for email.

A lot of domains do not do anything with email.#

A company may have many different domains and websites and will probably only use one for email. You may own old domains that you just keep registed but have no use for at the moment. There are domains that just redirect users to other domains. For instance you have registered multiple top level domains that all redirect to 1 website on 1 domain.

Your registered domain may have a number of subdomain.

There are many reasons why a domain is registered but used for email.

These domain names could be open to abuse.#

Email is an old standard and by default has no mechanism to validate the sender addresses, and yes adresses is no type there are multiple. A major problem can be that you can easily forge(spoof) a From sender address so it looks like the email was sent from your domain.

Because of this your name could be abused by anyone online.

Your name could be used for SPAM phishing or other scams. This could be used cause actual harm to your organisation or others. Even domains that that do not send or receive email can be abused when you do not take the correct measures. Let’s learn how you can secure your domain against this.

Email standards against email-spoofing.#

That’s where the standards SPF, DKIM and DMARC come in.

These standards are increasingly configured to improve email security for domains that send and receive email. Domains that do not deal with email are often overlooked and remain open for abuse.

Let’s look at these 3 standards to see what they do.

SPF#

SPF(Sender Policy Framework) defines which servers, by IP-address, are allowed to send email from this domain using the enevelope from address.

When an email server receives an email it will retrieve the SPF record from the domain that claims to be the sender. It then uses that addresses in the SPF record to determine, if the email was sent from a server that is allowed to send email for that domain.

DKIM#

DKIM(DomainKeys Identified Mail) work with digital signatures. Every email sent from your domain has to be signed with a signature. When a server receives email that contains such a signature, it will retrieve the public key for that message from the correct domainkeys record in DNS. Using that it can validate if the sigature is correct. If so that says that the domain was the actual sender and the message was not altered along the way.

DMARC#

DMARC(Domain-based Message Authentication, Reporting and Conformance) is a standard the validates the second from address in an email. This is the address mostly shown in email clients, but is not validate by SPF or DKIM. This second address does not have to be the same as the first from address on the message envelope. Very often it is not the same especially for automated email like newsletters.

DMARC tells receiving email servers that the second from address must also match either a DKIM signature or SPF, and it tells servers what to do if that is not the case.

What should you do?#

First check.#

Are you absolutely sure the domain does not send email. There may not be an emailserver, but maybe there is an external newsletter sending email, a website that sends emails or some other legitimate service. Just make sure, because if you go on with the changes these emails will stop being delivered.

//: # (TODO add link(s) here on how to configure SPF, DKIM and DMARC. )

Now you need to get access to the DNS records of your domain, that’s where we will configure that the domain does not send email.

Set your SPF record#

Normally SPF is used to tell the world(receiving email servers) which servers are allowed to send email from this domainname.

We’re going to tell that this domain has no valid senders.

If you set a TXT record on the domain with this content:

v=spf1 -all

Since there are no IP-addresses mentioned that are allowed to send, this tells receiving servers to reject all email from this domain.

SPF does not cover subdomains. If you have configured subdomains, or wildcard domains, and they should send email. Add the same TXT record on those subdomains.

Set your DMARC record#

Unfortunately email messages have two from addresses and SPF only deals with one of them.

To make sure the other From address is also protected against spoofing you have to configure DMARC. DMARC protects the second From address.

To make sure no emails are sent from your domain set the following TXT record on the DNS record _dmarc.yourdomainname.tld Note the prefix of _dmarc.

v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s

This says that all email that is not from a valid SPF sender or has a valid DKIM signature must be rejected. Since we have set no servers on SPF this should be enough.

Also note that we do not only tell to reject this domain(p), but also tell that all subdomains(sp) should reject email from this domain.

Make sure there is only one TXT record on _dmarc.yourdomainname.tld.

Set your DKIM record#

Just to be on the safe side we will also set a DKIM record that states there are no valid signatures.

set the following wildcard record: *._domainkey.yourdomainname.tld to the TXT record.

v=DKIM1; p=

Now any mailserver that checks SPF, DKIM and DMARC will know that emails from your domain are spoofed and will be rejected. Allmost all email servers do this now.

Conclusion#

Have you made sure the changes as described above have been to your domains that did nothing with email?

Good job.

You’ve just:

• prevented reputation damage on your (domain) name.
• prevented possible impersonation of your domainname.
• made the internet a little safer.

Added bonus#

You could also set your MX record to 0.

This specifies that this domain does not receive email so no attempts will be made to deliver email to your servers.

To do this set the MX record priority to 0 and the hostname to .