2
DMARC causing problems.
Problem reported by Paul White - 2/11/2022 at 10:46 AM
Submitted
To help eliminate spoofing I enabled the setting on smartermail to use the FROM instead of the RETURN PATH field for SPF / DMARC.
Ever since then we have been having problems with DMARC rejecting emails coming in to specific people. I have added the SPF entry for the sending domain to our SPF, and it still is failing DMARC.  
Any advice?   I have swapped my client's domain and email for privacy reasons.  
Anywhere you see Last, First would actually be their name, and person@companyemail.com would actually be their real email address.

This is from our SMTP logs

[2022.02.11] 11:22:38.361 [147.253.217.248][64957876] Performing PTR host name lookup for 147.253.217.248
[2022.02.11] 11:22:38.376 [147.253.217.248][64957876] PTR host name for 147.253.217.248 resolved as mta-253-217-248.netsuite.com.sparkpostmail.com
[2022.02.11] 11:22:38.376 [147.253.217.248][64957876] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
[2022.02.11] 11:22:38.501 [147.253.217.248][64957876] senderEmail(2): system@sent-via.netsuite.com parsed using: "Last, First (person@companyemail.com)" <system@sent-via.netsuite.com>
[2022.02.11] Reply-To:"Last, First" <person@companyemail.com>11:22:38.501 [147.253.217.248][64957876] rsp: 550 Message rejected due to senders DMARC policy
[2022.02.11] 11:22:38.501 [147.253.217.248][64957876] A trace of the DMARC processing follows.
[2022.02.11] 11:22:38.501 [147.253.217.248][64957876] Beginning DMARC check for msprvs1=19041PBDFoaIN=bounces-183799-1@sent-via.netsuite.com from IP 147.253.217.248...
[2022.02.11] 11:22:38.501 [147.253.217.248][64957876] The from field for the message is ""Last, First (person@companyemail.com)" <system@sent-via.netsuite.com>".  Will look for DMARC policy record at _dmarc.companyemail.com
[2022.02.11] 11:22:38.501 [147.253.217.248][64957876] Retrieved the following DMARC policy record for "companyemail.com": v=DMARC1; p=reject
[2022.02.11] 11:22:38.501 [147.253.217.248][64957876] DMARC policy violated due to DKIM domain ("System.Collections.Generic.List`1[System.String]") not belonging to the same parent domain as the from address field domain ("companyemail.com").
[2022.02.11] 11:22:38.501 [147.253.217.248][64957876] DMARC policy violated due to SPF domain ("sent-via.netsuite.com") not belonging to the same parent domain as the from address field domain ("companyemail.com").
[2022.02.11] 11:22:38.517 [147.253.217.248][64957876] Received message size: 43577 bytes
[2022.02.11] 11:22:38.517 [147.253.217.248][64957876] Successfully wrote to the HDR file. (C:\SmarterMail\Spool\SubSpool6\960192956765.hdr)
[2022.02.11] 11:22:38.517 [147.253.217.248][64957876] Data transfer succeeded but message rejected by DMARC
[2022.02.11] 11:22:43.563 [147.253.217.248][64957876] cmd: QUIT
[2022.02.11] 11:22:43.563 [147.253.217.248][64957876] rsp: 221 Service closing transmission channel
[2022.02.11] 11:22:43.563 [147.253.217.248][64957876] disconnected at 2/11/2022 11:22:43 AM


14 Replies

Reply to Thread
0
Stefano Replied
It's something about your DNS.
I think that you've to take a look at them ;)
Or post them here
0
Paul White Replied
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
1
Stefano Replied
Without knowing your real domain, it's not possible to check if everything is working fine :)
0
Sébastien Riccio Replied
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:

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 Riccio
System & Network Admin

0
Stefano Replied
@Sébastien I think he has solved it.
He sent me the domain via PM and MXtoolbox said that there were too many lookups.
0
Sébastien Riccio Replied
Ah... okay good :)
Sébastien Riccio
System & Network Admin

0
Douglas Foster Replied
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.
1
Matt Petty Replied
Employee Post
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.
Matt Petty
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Miguel Enrique Replied
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.
0
Douglas Foster Replied
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.
0
Miguel Enrique Replied
Thanks for the explanation. The reasons are clear.
0
Paul Blank Replied
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.


0
Douglas Foster Replied
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.
0
Paul Blank Replied
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. 

Reply to Thread