Home
익명 17:00

OpenDMARC is rejecting valid spf record include:

OpenDMARC is rejecting valid spf record include:

I'm running postfix and I'm having emails rejected by opendmarc that appear to be valid. Here is an example:

Apr  9 17:51:40 primary postfix/smtpd[517925]: D4FAB20161: client=lg95.mta.exacttarget.com[13.111.200.95]
Apr  9 17:51:40 primary postfix/cleanup[517934]: D4FAB20161: message-id=<[email protected]>
Apr  9 17:51:40 primary opendkim[744]: D4FAB20161: lg95.mta.exacttarget.com [13.111.200.95] not internal
Apr  9 17:51:40 primary opendkim[744]: D4FAB20161: not authenticated
Apr  9 17:51:40 primary opendkim[744]: D4FAB20161: message has signatures from services.barclaysus.com, s10.y.mc.salesforce.com
Apr  9 17:51:40 primary opendkim[744]: D4FAB20161: bad signature data
Apr  9 17:51:41 primary opendmarc[745]: D4FAB20161: SPF(mailfrom): bounce.emails.barclaysus.com pass
Apr  9 17:51:41 primary opendmarc[745]: D4FAB20161: services.BarclaysUS.com fail
Apr  9 17:51:41 primary postfix/cleanup[517934]: D4FAB20161: milter-reject: END-OF-MESSAGE from lg95.mta.exacttarget.com[13.111.200.95]: 5.7.1 rejected by DMARC policy for services.BarclaysUS.com; from=<bounce-18_HTML-217530911-7649892-515001007-1@bounce.emails.barclaysus.com> to=<[email protected]> proto=ESMTP helo=<lg95.mta.exacttarget.com>

The dmarc record looks like:

v=DMARC1; p=reject; fo=1; rua=mailto:[email protected]; ruf=mailto:[email protected]

So, it's set to reject.

If I look at the spf record for services.barclaysus.com I see:

services.barclaysus.com. 3600   IN  TXT "v=spf1 include:cust-spf.exacttarget.com -all"

If I look at the spf record for cust-spf.exacttarget.com I see:

cust-spf.exacttarget.com. 169   IN  TXT "v=spf1 ip4:64.132.92.0/24 ip4:64.132.88.0/23 ip4:66.231.80.0/20 ip4:68.232.192.0/20 ip4:199.122.120.0/21 ip4:207.67.38.0/24 " "ip4:128.17.0.0/20 ip4:128.17.64.0/20 ip4:128.17.128.0/20 ip4:128.17.192.0/20 ip4:128.245.0.0/20 ip4:128.245.64.0/20 ip4:13.111.191.0/24 " "ip4:128.245.242.0/24 ip4:128.245.243.0/24 ip4:128.245.244.0/24 ip4:128.245.245.0/24 ip4:128.245.246.0/24 ip4:128.245.247.0/24 ip4:128.245.176.0/20 ip4:136.147.224.0/20 " "ip4:207.67.98.192/27 ip4:207.250.68.0/24 ip4:209.43.22.0/28 ip4:198.245.80.0/20 ip4:136.147.128.0/20 ip4:136.147.176.0/20 ip4:13.111.0.0/16 ip4:161.71.32.0/19 ip4:161.71.64.0/20 ip4:13.110.208.0/21 ip4:13.110.216.0/22 " "ip4:13.110.224.0/20 ip4:159.92.157.0/24 ip4:159.92.158.0/24 ip4:159.92.159.0/24 ip4:159.92.160.0/24 ip4:159.92.161.0/24 ip4:159.92.162.0/24 ip4:159.92.154.0/24 ip4:128.245.240.0/24 ip4:128.245.241.0/24 ip4:159.92.155.0/24 ip4:159.92.163.0/24 ip4:159.92.16" "4.0/22 ip4:159.92.168.0/21 ip4:128.245.248.0/21 -all"

Which includes ip4:13.111.0.0/16, so the sending IP [13.111.200.95] should pass.

Google's AI seemed to think I could test from the command line with:

opendmarc -v -c /etc/opendmarc.conf -t ./test.eml -s 13.111.200.95

But, the "-s" is invalid for my opendmarc version. I'm not sure how to extract any additional information about the issue at this point.

Maybe I'm barking up the wrong tree. Thank you in advance!!


Top Answer/Comment:

The thing tripping you up is that "SPF passes" and "DMARC passes" are two different tests, and DMARC needs one extra thing on top of an SPF pass: alignment.

Walk through what your logs actually say:

  • opendkim reports "bad signature data" for both signatures, so DKIM is out entirely. There's nothing to align on that side
  • opendmarc reports SPF(mailfrom): bounce.emails.barclaysus.com pass. So SPF authorized the sending IP, but it did so for the envelope (Return-Path / MAIL FROM) domain, which is bounce.emails.barclaysus.com
  • The From header, and therefore the domain DMARC is judged against, is services.barclaysus.com (the one publishing p=reject)

With DKIM gone, the whole verdict rests on whether that SPF pass aligns with the From domain. Alignment compares the SPF-authenticated domain (bounce.emails.barclaysus.com) against the From domain (services.barclaysus.com). Your DMARC record doesn't set aspf, so you're in relaxed mode, and relaxed alignment passes as long as both share the same organizational domain. Both of those reduce to barclaysus.com, so this message should align on SPF and should pass DMARC. Your instinct that it's valid mail is correct: it's genuine Barclays-via-Salesforce-Marketing-Cloud traffic, and Gmail or any spec-correct evaluator will pass it.

So the problem is in how your OpenDMARC computes the organizational domain. To do relaxed alignment it has to know that emails.barclaysus.com and services.barclaysus.com roll up to the same registrable domain, and it can only work that out from a Public Suffix List. Straight from the opendmarc.conf docs for the PublicSuffixList setting:

Specifies the path to a file that contains top-level domains (TLDs) that will be used to compute the Organizational Domain for a given domain name [...] If not provided, the filter will not be able to determine the Organizational Domain and only the presented domain will be evaluated.

"Only the presented domain will be evaluated" is exactly your symptom. With no PSL, relaxed alignment quietly collapses into an exact-string match, bounce.emails.barclaysus.com is not services.barclaysus.com, SPF is treated as not aligned, and since DKIM already failed you land on DMARC fail and the milter rejects.

The fix is to install the public suffix list and point OpenDMARC at it. In /etc/opendmarc.conf:

PublicSuffixList /usr/share/publicsuffix/public_suffix_list.dat

The file ships in the publicsuffix package on most distros (sometimes named effective_tld_names.dat); you can also grab it from https://publicsuffix.org/list/ and refresh it periodically. Restart opendmarc and re-check. The same sender should now log a pass, and the Authentication-Results header OpenDMARC stamps will read dmarc=pass.

Two side notes:

  • The "the SPF record is too long, maybe it stops reading before 13.111.0.0/16" comment is a red herring. A TXT record split into several quoted strings is normal; the resolver concatenates them back into one string, and your own spfquery already returned pass. SPF authorization was never the failing part
  • You're right that -s isn't valid on your opendmarc; that option isn't there to use. You don't actually need it here, because the milter log already told you everything: SPF pass on the envelope domain, DMARC fail on the From domain. That gap is the alignment issue above
상단 광고의 [X] 버튼을 누르면 내용이 보입니다