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:
We'll also explain how these techniques can be used selectively to include, or exclude selected subdomains.
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 term: -all.
As the name implies, the all mechanism matches every sender, thus every email.
By prefixing the term with the - (fail) policy, each email sent on behalf of the domain will fail SPF validation, thus failing SPF alignment.
Additionally, the - (hard fail) prefix will cause most email receivers to drop the email immediately, and not even attempting to perform DKIM verification. (Hence, why SPF -all should not be used for domains that are used to send email).
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
?allterm. 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
-allterm 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
_domainkeylabel anyway, you probably want to remove all TXT records published under the_domainkeylabel as part of good hygiene.
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.comin 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 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(orAAAA) records.Yes, you read that right. Even if a domain has no
MXtype records set up, delivery of email will still be attempted at the host pointed to by theAorAAAArecords.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:
To solve these issues, a 'null MX' record is proposed in 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.
MTA-STS (Mail Transfer Agent Strict Transport Policy) is a standard to force the use of TLS on SMTP connections for inbound email. Forcing TLS obviously makes little sense if a domain does not accept inbound email, but there are still reasons on why one would like to deploy MTA-STS for a domain that does not accept inbound email.
Traditionally, the DNS MX type resource records are used to publish the hostnames of inbound email services for a domain.
But the DNS is not encrypted, making it susceptible to Man-in-the-Middle attacks, cache poisoning, and denial attacks.
DNSSEC solves some of these issues, but not every DNS service provider supports DNSSEC.
Deploying DNSSEC may also be challenging for large organizations, a single mistake can make an entire domain unreachable for an extended period of time.
With MTA-STS, the delivery of the MX hosts (or the lack thereof) is performed over HTTPS, leveraging a PKI certificate for the source of trust. Using MTA-STS on a domain with a rfc7505 'null MX' record helps the domain to emit a 'positive rejection', letting SMTP services know that no email should be delivered to the domain.
The MTA-STS standard, rfc8461 does not specifically mention how to implement rfc7505 'null MX' records.
However, when reading the specification carefully, the STS policy should not include any mx lines, and use method none.
version: STSv1
mode: none
max_age: 604800Note that a mode other than none is not allowed if no mx are specified.
For Mailhardener customers, MTA-STS policy hosting is included in the Mailhardener suite, it requires only 2 CNAME DNS records to be set, and the rest happens automatically. Mailhardener MTA-STS will automatically detect when rfc7505 'null MX' is used, and serve the correct MTA-STS policy accordingly.
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.
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.
p= to the desired policy for that specific subdomain.sp= subdomain policy configuration in the domain apex DMARC record (at _dmarc.yourdomain.com), this policy will apply to all subdomains of yourdomain.comWhen 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.
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 jane@subdomain.mailhardener.com 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).
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 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 mechanism) 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.
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.
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.
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.
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.
On last thing: If you have questions, comments or thoughts on this article, don't hesitate to shoot us an email.
You can also follow and reach us on Twitter @Mailhardener.