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


8 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.
0
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

Reply to Thread