Knowledge base > Hardening unused (sub)domains

Hardening unused (sub)domains

Even if a domain is not intended to be used for email, whether it being inbound (receiving) or outbound (sending) email, it is still recommended to apply proper email hardening techniques to prevent the domain from being abused for fraudulent activities.

Domains that are not used for email may be parked domains, legacy domains, testing domains, black-hole domains, or any other domain that may be used for applications other than email. It is also possible that a domain accepts inbound email, but does not send email, or vise versa.

In this article we'll explain:

• How a domain can be set up with DMARC so that no email can be sent on behalf of the domain. This helps prevent fraudulent activities that may affect the reputation of the domain and brand.
• Using rfc7575 'null MX' records as a best practice for domains that do not accept inbound email. This improves the experience of the customer when accidentally sending email to the domain.

We'll also explain how these techniques can be used selectively to include, or exclude selected subdomains.

Outbound email

Domains that are not used to send email may still be susceptible to fraudulent abuse. An adversary may try to send email on behalf of the domain. That is: using the domain in the sender address. Proper hardening can prevent this.

The goal here is to leverage DMARC to prevent any email sent on behalf of the domain from being accepted by any receiver. We achieve this by configuring the domain so that it is no longer possible for any email to reach DMARC alignment, thus forcing the receiver to follow the DMARC policy, which we will set to 'reject'. By publishing the 'reject' policy, any email that is attempted to be sent on behalf of the domain will be rejected by (DMARC capable) receivers.

Remember that for an email to be considered DMARC aligned, at least one of DKIM and SPF must reach alignment. So, in order to prevent any email from reaching DMARC alignment, neither SPF nor DKIM may reach alignment.

To prevent any sender from reaching SPF alignment for a domain, we create an SPF DNS record with just one rule: -all.

As the name implies, the all mechanism matches every sender, thus every email. By prefixing the rule with the - (fail) policy, each email sent on behalf of the domain will fail SPF validation, thus failing SPF alignment.

To prevent any sender from reaching SPF alignment, a TXT record should be created at the domain apex with the following value:

v=spf1 -all

If the domain already has an (old) SPF record set, then that existing SPF record should be replaced with the one displayed above, since a domain should only have 1 SPF record.

Be aware that SPF does not propagate, meaning that for email sent from subdomain.yourdomain.com, the SPF record at the domain apex will not be used. So, it is recommended to also create this same SPF record for all subdomains, by creating a wildcard DNS record at *.yourdomain.com.

Note: an alternative option would be not to publish an SPF record at all. This is the same as publishing a ?all rule. The ? (neutral) policy means SPF is not to be used during evaluation of email by the receiver. It is effectively an opt-out from using SPF.

However, how a 'neutral' policy is handled differs with the various SMTP software implementations, so the email may still be accepted by some if a neutral policy (or no SPF record at all) is used. It is therefore recommended to use SPF with the -all rule to give a strong statement to receivers that email should not be accepted.

The goal is that no sender can ever reach DMARC alignment, which means that no sender should ever be able to reach DKIM alignment.

This is achieved by simply removing any existing DKIM DNS records. That are any TXT records at *._domainkey.yourdomain.com, or DKIM records published for subdomains at *._domainkey.subdomain.yourdomain.com.

Be aware that the v=DKIM1; part in a DKIM record is actually optional, so even if a TXT record does not start with 'v=DKIM1', it may actually be a valid DKIM record.

However, since no TXT type records other than DKIM records should be published under the _domainkey label anyway, you probably want to remove all TXT records published under the _domainkey label as part of good hygiene.

DMARC

With the SPF policy set to -all and any DKIM records removed, it will no longer be possible for any email that is sent on behalf of the domain to achieve DMARC alignment. As a result, a DMARC capable receiver will apply the DMARC policy that is published in the DMARC DNS record. By creating a DMARC record with the reject policy, any email sent on behalf of the domain should be rejected by the receiver.

Create a DNS TXT type record at _dmarc.yourdomain.com with the following content:

v=DMARC1; p=reject;

Note that a domain should only have one DMARC record (a TXT type record starting with v=DMARC1, at _dmarc.yourdomain.com ). If the domain already has a DMARC record, the existing record can be re-used by setting the p value to reject. If there is an existing DMARC record with the sp value set, remove that so that the reject policy will also apply to subdomains.

This DMARC record advises any receiver that email from the domain should be rejected if the email does not reach DMARC alignment. Since we ensured that no email can ever reach SPF or DKIM alignment, it is ensured that no email can ever be DMARC aligned. Therefore, any email sent on behalf of the domain should be rejected by the receiver.

Note: Unlike, for example with SPF, DMARC does propagate. This means that if an email is sent using subdomain.yourdomain.com in the sender address, and no DMARC record exists at _dmarc.subdomain.yourdomain.com, the receiver will look for a DMARC record at _dmarc.yourdomain.com. So, verify that no other DMARC records exist at subdomains, to ensure that no email can be sent from any subdomains.

With the SPF, DKIM and DMARC set up as explained above, it should no longer be possible for any sender to send email on behalf of the domain (using the domain in the sender address).

Inbound email

Inbound email is email that is being delivered to a domain. Not every domain is intended to accept inbound email, even if the domain is used for outbound (sending) email.

But even if a domain is not intended to accept inbound email, senders may still attempt to deliver email. This will obviously fail, but due to resend policies it may take up to a week before the user is notified that the email is undeliverable. By properly configuring the domain, we can indicate a 'positive denial' to potential senders that the domain does not accept inbound email. This gives a better experience to the end user, as they will get an immediate response that the email cannot be delivered to the domain.

There is a lesser known 'feature' in rfc5321 section 5.1, which describes how a sending SMTP service must locate the host to deliver email to. If a domain has no MX records, the sending SMTP server must attempt to deliver email on the host found in the DNS A (or AAAA) records.

Yes, you read that right. Even if a domain has no MX type records set up, delivery of email will still be attempted at the host pointed to by the A or AAAA records.

The reason for this behavior is to provide a fallback method in case of DNS misconfiguration, or if the DNS service does not support the MX type record (which, in 1982 when the original RFC for SMTP was released, was a concern).

So, not having any MX type records set for a domain, will cause two different issues:

• The sending SMTP service will retry delivery of an email message for an extended period (often up to a week). This results in the user not being notified on the delivery issue until the retry timeouts have passed.
• It causes undesired connection attempts to the hosts configured in the A/AAAA records on port 25.

To solve these issues, a 'null MX' record is proposed in rfc7505.

'null MX' records (rfc7505)

The rfc7505 standard describes a method of 'positive denial' of inbound email. By placing a "null MX" record, a domain can indicate that it does not accept inbound email.

This offers a better overall experience for the end user who is attempting to send the email, as delivery will fail immediately (instead of after a week or so). Properly designed email clients will be able to hint the user that the used domain in the recipient's address is likely mistyped.

A rfc7505 'null MX' record is an MX record with the highest priority (0), and an empty host label ("."). This 'null MX' record should be the only MX type record for the (sub)domain.

MX 0 .

This will cause a sending SMTP service to use this record, and not fall back to the A/AAAA record. Since the hostname in the 'null MX' record is not usable (it is empty), the sending SMTP service will not be able to use this record. Since there are no further MX records published by the domain, the SMTP service has no other delivery methods, and the email will hard-bounce.

Properly designed SMTP services, and email agents (MUA) will be able to recognize the rfc7505 'null MX' record (one MX record, with prio 0 and an empty host name), and will notify the user attempting to send the email that the domain does not accept email, and even hint the user that they may have mistyped the domain name, like an email client may do for non-existing domains.

Allowing (certain) subdomains

Up till this point, this article assumed that the entire domain should no longer be usable for email. However, if certain subdomains are still to be used for email, you can override your policies for a subdomain.

We want to allow email from a subdomain to reach SPF alignment, while still preventing email from the domain apex or other subdomains to reach alignment. To achieve that, an SPF record can be created for the specific subdomain, or by creating an SPF record for a wildcard subdomain (which will then apply to all subdomains). The SPF record is then used to designate the allowed senders for this specific subdomain. The domain apex can still use the -all policy as explained above.

DKIM DNS records may be created at the subdomain level (for example: selector._domainkey.subdomain.mailhardener.com). To ensure this key can only be used for the subdomain, it is recommended to set the 'strict' flag in the DKIM DNS record, by adding t=s to the record. Using strict mode will prevent the key from being accepted for any other subdomains.

DMARC

Strictly speaking, DMARC does not have to be changed if a subdomain is allowed to send email. If the SPF and/or DKIM configuration for the subdomain is set up correctly, then email from the subdomain will achieve DMARC alignment, thus the DMARC policy is not applied, thus the email will be accepted.

If needed, the DMARC policy for any (or all) subdomain(s) can be overridden by any of the following methods.

• Create a DMARC DNS record for the subdomain at _dmarc.subdomain.yourdomain.com, and set the p= to the desired policy for that specific subdomain.
• Or, set the sp= subdomain policy configuration in the domain apex DMARC record (at _dmarc.yourdomain.com), this policy will apply to all subdomains of yourdomain.com

MX (inbound email)

When a subdomain does accept inbound email (but the domain apex does not), then MX records can be created at the subdomain level. The domain apex, or other subdomains may still use the rfc7505 'null MX' record at the same time.

Disallowing (certain) subdomains

Conversely, it is also possible to disable email for a subdomain, while still retaining email functionality for the domain apex, or other subdomains. We apply the same techniques as described above, but in such a way that the domain apex, and/or other subdomains can still be used for email.

To prevent email from a subdomain from reaching SPF alignment, an SPF record can be created for the specific subdomain, or by creating an SPF record for a wildcard subdomain (which will then apply to all subdomains). This SPF record should then use the -all policy. Since SPF does not propagate, the domain apex (or any other subdomains) can still use permissive SPF records that designate permitted senders for that (sub)domain.

To prevent email from a subdomain from reaching DKIM alignment (and thus DMARC alignment), the obvious first step is to remove any existing DKIM DNS records published under the subdomain. That is for example: all TXT records at *._domainkey.subdomain.mailhardener.com. However, additional steps must be taken to prevent the subdomain from using any other DKIM records (from the domain apex, or other subdomains). By default, the used DKIM record does not have to be published under the exact subdomain. For example: it is possible for email from [email protected] to use a DKIM key from mailhardener.com.

Therefore, we must augment the existing DKIM records that are published under the domain apex and other subdomains, with the 'strict' flag. By adding t=s to the DKIM records, the DKIM record becomes 'strict', meaning that the DKIM signature will only be accepted if the DKIM record is published under the exact same (sub)domain as is used in the domain portion of the sender email address (the part after the '@' symbol).

DMARC

When disallowing email from a subdomain, we want a strict DMARC policy for that subdomain. Other subdomains, or the domain apex may still use a less-strict (or even no) DMARC policy. If no DMARC policy is published for the subdomain, a receiver will propagate 'up' to the domain apex looking for a DMARC policy.

So, in case it is desired to have a DMARC policy for a subdomain that differs from other subdomains, or the domain apex, a DMARC policy record can be published at the subdomain level:

_dmarc.[subdomain].example.com

Re-enabling email functionality

Re-enabling email functionality for a domain that was previously set up not to handle email, may actually be slightly simpler than hardening an existing domain, as there should not be any legacy to consider. It is like starting with a clean slate.

To re-enable email for the domain, add the sender (via for example an a, or include rule) to the existing SPF record. The -all that was placed earlier can remain in place, but the slightly less strict ~all ('soft fail') may be used during the initial setup period, to verify the SPF policy is correct and complete. It is recommended to use DMARC reporting to verify that all legitimate senders pass SPF alignment.

To re-enable email for a (sub)domain, add the DKIM DNS records as recommended by the vendor of the email service or software used to send the email. It is recommended to use DMARC reporting to verify and monitor that all legitimate senders are passing DKIM alignment.

DMARC

If a DMARC record was created following the examples above, then it should already be set up to use a strong (reject) policy, and have DMARC reporting enabled. During the initial setup of the email services, it might be beneficial to set a less strict policy (for example: quarantine, or even none), and use DMARC monitoring to verify the email services are aligned before switching back to the strong policy (reject).

Because the domain is starting from a 'clean slate' again, it is a great opportunity to use the strong reject policy, and ensure that all senders are (at least) reaching DKIM alignment.

Always be monitoring

Monitoring outbound email

Regardless if a (sub)domain is used for outbound (sending) email or not, it is always recommended to use rfc7489 DMARC monitoring. A DMARC report aggregation service such as Mailhardener can be used to create an overview of all sources of email.

Even if a (sub)domain is not used for outbound email, DMARC reports can still be used to verify that no email service is reaching alignment. It can also be used for digital forensics, fraud investigations and detecting suspicious activity of an adversary.

If a (sub)domain is used for outbound email, then DMARC reports are used to verify that all legitimate senders are reaching DKIM and/or SPF alignment. This helps improve deliverability, and allows for adopting a strong (reject) DMARC policy, which reduces fraudulent use of the domain in email.

Monitoring inbound email

Regardless if a domain accepts inbound email, it is always recommended to use rfc8460 SMTP TLS reporting.

SMTP TLS reports are used to monitor inbound email traffic from the sender's perspective, mostly (but not exclusively) related to TLS (SSL) aspects of the SMTP session. For (sub)domains that do not accept inbound email, SMTP TLS reporting can be used to verify that no SMTP session is ever successful for the monitored (sub)domain.

Conversely, for (sub)domains that do accept inbound email, SMTP TLS reports are used to verify that senders are not experiencing TLS (SSL) related delivery issues.

Conclusion

Proper implementation of email hardening techniques can be beneficial even to (sub)domains that are not intended to be used with email. These may be parked domains, legacy domains, testing domains, or any other domain that are used for other services than email.

Deploying a strict DMARC policy, whilst ensuring that email sent on behalf of the (sub)domain can never reach alignment, is an effective anti-fraud mechanism that helps maintain the reputation of the domain and brand.

By using a 'null MX' setup as defined by rfc7505, a better user-experience is created for customers that may be accidentally attempting to send email to a domain that is not intended to receive email.

Regardless if the domain is intended to be used for email or not, it is always recommended to use DMARC monitoring for outbound email, and SMTP TLS report monitoring for inbound email. It is recommended to use an email monitoring suite, such as Mailhardener, to monitor domain assets from being abused.

Further reading

Free validation tools

Related articles