How to Verify your Sugar Market SPF, DKIM, and DMARC authentications are setup correctly

1. ​​​​​​​Navigate to the URL: https://dmarcian.com/dkim-inspector/
2. Enter the domain or sub-domain under Enter Domain.
3. Enter msgapp under Enter Selector.
4. Click Inspect DKIM
5. Verify you receive a Congratulations! Your DKIM record is Valid. 

Verifying DMARC

There are a few online tools to validate DKIM records. For the purposes of this article, we will be using Dmarcian.

Note: DMARC should only exists either the main domain or sub-domain, but not both.

1. Navigate to the URL: https://dmarcian.com/domain-checker
2. Enter in both your domain and sub-domain under Enter Domain.
3. Submit
4. Verify you receive a valid DMARC
5. Dmarcian offers an inspector tool in case there are errors via this URL: https://dmarcian.com/dmarc-inspector/

FAQ And SPF Troubleshooting

SPF Error: Two or More Type TXT SPF Records Found

The RFC 7208 standard states that there should only be one SPF record string for your domain. The reason is that when you’re sending an email to a recipient's server, if you have multiple SPF records for your domain, the recipient server might only look at one of the SPF records to validate and not consider the rest. This is because all email servers are different and might not adhere to standards.

As mentioned above, if you have multiple SPF records within a domain, you need to merge them together or consider suggesting a sub-domain for your marketing efforts. Here is another example pulled from a Kitterman SPF validation query:

In the example above, I would suggest that they remove the following:
v=spf1 mx include:auth.msgapp.com ~all
123.456.789.123

Instead, they should merge what’s needed into the existing record:

v=spf1 a mx ip4:123.456.789.123 a:customer@domain.com include:auth.msgapp.com ~all

To validate the syntax, you can use an SPF validation tool such as Kitterman as mentioned in the next FAQ.

Using Kitterman to validate SPF Syntax

We provide customers with the following SPF record for them to enter in on their DNS:

v=spf1 mx include:auth.msgapp.com ~all

If the customer doesn't have an SPF record, they can simply add this SPF record. However, if the customer has a pre-existing SPF record, they will need to merge our SPF into theirs. As mentioned earlier, you should only have one SPF record. Because of this, you can use an SPF validation tool to validate the syntax of the SPF record prior to making the change live.

Example:
If the client's SPF record is as follows and passes the SPF checker:

v=spf1 include:spf.protection.outlook.com include:customer@domain.com ip4:123.456.789.123 ~all

The suggestion would be to add the mechanism include:auth.msgapp.com into their SPF string, such as:

v=spf1 include:spf.protection.outlook.com include:customer@domain.com ip4:123.456.789.123 include:auth.msgapp.com ~all

Then, use the syntax validation tool to validate the syntax.

1. Go to Kitterman SPF Validation Tool
2. Under the 'Syntax Validation' tool, in the 'Is this SPF record valid - syntactically correct?' section, enter their domain followed by the potential SPF record.
3. Verify that you receive an SPF record passed validation message.

SPF Error: Too Many DNS Lookups

For each SPF record, there is a limited amount of DNS lookups per RFC 7208, with a maximum of 10 records. Dmarcian is a highly effective tool to use if this error is present, as it allows you to easily delve into each 'include' of the SPF record individually.

SPF implementations MUST limit the number of mechanisms and modifiers that perform DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the 'include' mechanism or the 'redirect' modifier. If this number is exceeded during a check, a PermError MUST be returned. The 'include', 'a', 'mx', 'ptr', and 'exists' mechanisms, as well as the 'redirect' modifier, do count against this limit. The 'all', 'ip4', and 'ip6' mechanisms do not require DNS lookups and therefore do not count against this limit.

Below is an example of the 'Too many DNS Lookups' error" from the kitterman tooling:

How to Identify how many DNS Lookups are within an SPF string?

As mentioned previously, anytime a DNS needs to be translated within a string, it counts as 1 DNS Lookup. To reiterate, the 'include', 'a', 'mx', 'ptr', and 'exists' mechanisms, as well as the 'redirect' modifier, do count against this limit. Also, if DNS is nested within DNS mechanisms, those count as well and are often forgotten. Luckily, there are tools you can use to easily identify these DNS lookups.

Let's look at an example using the Dmarcian SPF Survey tool.

In the above example, we can see their SPF is:

v=spf1 mx include:spf.protection.outlook.com include:auth.msgapp.com ip4:123.456.789.123 ~all

In the screenshot, we've highlighted three DNS mechanisms that we can see on the surface:

1. mx
2. include:spf.protection.outlook.com
3. include:auth.msgapp.com

So this customer is still within the limit of 10. However, if you notice, Dmarcian actually says it counts 4 out of the 10 limit. This is because within those mechanisms, there is a nested DNS lookup, which also counts. So if we expand, we can see the nested DNS lookup that was nested within the 'Include: spf.protection.outlook.com:

Using tools like Dmarcian can help you quickly and easily identify why there are too many DNS lookups when you receive that error "Too many DNS lookups.

How do I fix 'Too Many DNS' lookups error?

Now that you understand what this error means from the previous section, there are generally two paths to consider:

1. Informing your IT team: If you're facing this issue, we recommend checking with your IT team to review the DNS entries in your SPF string. Sometimes, outdated entries from previous marketing automation, email providers, or spam filtering services may linger in your SPF record. Cleaning these up can help resolve the issue.

2. Utilizing an alternate domain or sub-domain: Another recommended practice is to use a sub-domain for different business ventures. This approach helps segregate technologies, making them easier to manage. This is a highly recommended configuration, commonly employed in the marketing industry. Here are some examples from other companies to take examples from:

   @e.paypal.com
   @emails.newegg.com
   @r.groupon.com
   @mailer.last.fm
   @email.zazzle.com

To emphasize, many marketing companies use subdomains for various reasons, including SPF DNS lookup limitations. Additionally, it helps minimize the risk of being blacklisted on the main domain, even if everything is configured correctly. For instance, large companies may use a sub-domain like corp.example.com for their marketing emails, reducing the impact on their main domain, example.com. This practice is common among industry leaders.

If you have any questions or need further assistance, feel free to reach out to our support team via support@sugarcrm.com or drop a comment below. We're here to help!