It's something about your DNS.

I think that you've to take a look at them ;)

Or post them here

I added their SPF to ours a few days ago

include:sent-via.netsuite.com

And even after DNS flush, and smartermail restart, it still fails DMARC

To get around this I have been forced to Whitelist all their IP blocks, which is not my preferred method of dealing with these types of issues.

Here is our DMARC record

v=DMARC1; p=reject

Here is our SPF record

v=spf1 a mx ip4:208.117.55.132 ip4:52.10.202.35 ip4:192.174.80.0/20 ip4:54.218.184.235 ip4:44.235.121.132 include:_spf.salesforce.com include:sparkpostmail.com include:_phishspf.knowbe4.com include:sent-via.netsuite.com -all

Without knowing your real domain, it's not possible to check if everything is working fine :)

Looking at your SPF record, it *might* be because it causes too much recursive lookups. It is limited to 10 if I'm correct.

This can happen particulary when you use includes and these includes includes other records needing a DNS lookup.

You can read explanation here:

https://dmarcly.com/blog/spf-permerror-too-many-dns-lookups-when-spf-record-exceeds-10-dns-lookup-limit 

And check if it is the cause of your issue and maybe consider flattening of your spf record.

As said by Stefaon, without knowing the domain name to troubleshoot it will be difficult to assist you.

@Sébastien I think he has solved it.

He sent me the domain via PM and MXtoolbox said that there were too many lookups.

Ah... okay good :)

Using FROM with SPF on your incoming mail will cause a world of problems.   A large portion of all email comes from email service providers, where the SMTP domain is the service provider and the FROM domain is the client.  If you use test SPF against the client domain, you can expect a lot of SPF false positives, because you are evaluating the wrong domain.   DMARC is the working method to validate FROM.   Of course, the headache is that not all senders publish a DMARC policy.   

When you detect an impersonation, you should trace it back to the perpetrator IP address and / or domain names, then block that source.  Impersonation is a small percentage of all spam, while both SPF and DMARC are subject to false positives.   I am not satisfied with the SmarterMail tools for overriding false positives, so I do my sender authentication with custom scripts within Declude,  My current DMARC logic has a number of imperfections relative to the specification, but I have found it useful for evaluating all traffic, regardless of policy.   Periodically, I review the authentication failures, adding block rules for unwanted senders and whitelist rules for the ones that are allowed to impersonate.  (And yes, there are "wanted impersonators".   Some perpetrators are legitimately acting on behalf of a real person's email account, albeith without domain owner participation, and they are too important to block.

SPF and DMARC validation for your own domains is a separate and unrelated issue, which you seem to have solved.

I would recommend not using the "check from" setting. This was added in because we had edge cases that insisted we check the 'from' addresses, so we made this setting for this desired behavior. Using the 'from' instead of return-path as it was designed means it's no longer following standards and will likely create a bunch of false positives as Douglas mentioned.

Hi Matt.

On topic: I would recommend not using the "check from" setting.

Could you specify a little better how to perform the configuration you suggest?

Honestly, I can't find what I have to change in the smartermail configuration.

Thanks.

You said

"To help eliminate spoofing I enabled the setting on smartermail to use the FROM instead of the RETURN PATH field for SPF / DMARC. "

Then you said

"This change is not working well."

So Matt said:

"Change it back"

Matt is right.   You cannot solve the problem of fraudulent From addresses by doing SPF incorrectly.

Thanks for the explanation. The reasons are clear.

Too Many Lookups solution...

Unsolicited Plug: AutoSPF (autospf.com) is a terrific cloud-based SPF flattening service. Flattening an SPF record means extracting all the IP addresses from the individual lookups and placing those addresses directly into the SPF record or into fewer lookups.

Turns out that SPF records can be very long. AutoSPF does this, and does it dynamically, so if the contents of a lookup changes, AutoSPF keeps your SPF record up to date. 

For one of my clients, AutoSPF has reduced everything to 3 AutoSPF lookups. The domain's SPF record contains a URL for the first AutoSPF lookup. The first two AutoSPF lookups each contain many IP ranges, plus a URL to the next lookup. The third lookup in this case contains additional IP ranges, but doesn't need a further lookup embedded. Has worked for years now without a glitch.

Sorry, I was abrupt the other day.

A large portion of all email is sent by third-parties like sendgrid.net and constantcontact.com.   They use their own address for SMTP MailFrom to ensure SPF PASS, and the clients address for the message's FROM address.  The client domain will not have the vendor's addresses in it SPF record, so you will get false SPF FAIL. 

To enforce SPF, you first need to collect data about SPF failures from desired senders.  Then you need a way to configure exceptions for those senders.   Then you can assess whether SPF PASS + Corrections gives you an SPF PASS rate which is high enough to begin blocking or quarantining messages that do not.    Many products fail to give  you those tools.  I have done this using SM+Declude running as an incoming gateway, and a Barracuda appliance behind it to provide message visiblity.

In my client's case, they have third-party servers (e.g. Mimecast) sending email on behalf of some users, from the client's domain, so we want those email/sendmail servers to be listed in their SPF record. Hence so many lookups. 

good information