The customer's top level domain (org domain) should almost always be delegated to Enforce for SPF and DKIM. This is not always the case for subdomains. In most cases, we will deliberately not delegate these subdomains. This article will cover when we do and do not delegate subdomains to Enforce. This will be broken down by the type or function of a subdomain.

The main reason we do not normally delegate these subdomains is because some vendors require full control of the subdomain (such as the NS option below) and some vendors have verification systems for SPF and DKIM (To make sure that their customers' get it right) that do not understand the Valimail SPF Macros

If in doubt, do not delegate the subdomain

Single sender subdomains are, as the name suggests, subdomains that will only be used by a particular sender. When looking at a domain, there are a few signs that we can look for to decide if this is a single sender subdomain.

Does the subdomain have an explicit MX record(s) that is different from the MX record(s) at the org domain?

You can test this with a dig query like this:

dig sub.domain.com MX

Does this MX record point to a third party? Examples of this can be SendGrid ( mx.sendgrid.net ) or Sparkpost ( smtp.sparkpostmail.com ).

If the MX record is pointed to a third party, there is no way another service can send from this subdomain legitimately.

If this is the case, it is a single sender subdomain

Does the domain have explicit NS servers for the subdomain that are different from the org domain?

You can test this with a dig query like this:

dig sub.domain.com NS

Does this NS record point to a third party? An Example of this is Salesforce Marketing Cloud (

ns1.exacttarget.com, ns2.exacttarget.com, ns3.exacttarget.com, ns4.exacttarget.com. )

If the NS record is pointed to a third party, there is no way another service can send from this subdomain legitimately. If this is the case, it is a single sender subdomain

While we can not depend on existing SPF records to be accurate, we can use them as a clue to determine if the subdomain is only used by a single service. Even if the MX record is not pointed to a third party (or there is no MX record at all), we can look at an existing subdomain to see if there is more than one service listed in the SPF record. If there is only one, and we do not see any other services sending on this subdomain in the DMARC data, we can ask the customer if they expect other services to send from that subdomain. In some cases you may need to ask this question of the business owner of the identified service on that subdomain.

You can test this with a dig query like this:

dig sub.domain.com TXT

In some cases, you may see that the SPF record is referenced by a CNAME on the subdomain. If this CNAME points to a third party sender, this is a single sender subdomain because any domain that has a CNAME can not have any other DNS records associated with it.

For example: u1234567.wl123.sendgrid.net as a CNAME that points to v=spf1 ip4:167.89.1.2 -all

For Single Sender subdomains, do not delegate them to Enforce but do add them to the configuration page for the domain in Enforce and select the option "This domain will only be used for a single sender". This will require you to associate a sender with the subdomainWhile we will not be responding to SPF or DKIM queries for this subdomain, adding it to the configuration as a single sender subdomain will ensure that all emails sent with this subdomain as an EnvelopeFrom/ReturnPath will be categorized as being sent by this service

Even if the subdomain is not dedicated to a single third party sender, we still do not delegate it due to possible issues with the vendors' verification process that may not understand SPF Macros. If the customer expects that senders will change over time on this subdomain, we should consider delegating the subdomain.

The main example of when we would delegate a subdomain is for Internal Sources. It is not uncommon for multiple internal sources to send from the same subdomain, or even the org domain. Since internal sources are more likely to change over time and we don't need to worry about vendor verification systems, we can delegate these subdomains to Enforce.

For internal sources and subdomains that will change frequently, add these subdomains to the Configuration in Enforce and delegate SPF and DKIM