Strange SPF result

[Andrew Grudtsin]

Hello.

We try to implement spf verification on our ironport (c370 9.7.0-125). We have enabled SPF verification in mail flow policy. In message tracking we have found strange situation for one of external domain:

Sending Host Summary
Reverse DNS Hostname:	forward10j.cmail.yandex.net (verified)
IP Address:	5.255.227.111
SBRS Score:	5.6

10 Dec 2015 09:07:46 (GMT +03:00)	Protocol SMTP interface Internal (IP 10.72.35.14) on incoming connection (ICID 60710202) from sender IP 5.255.227.111. Reverse DNS host forward10j.cmail.yandex.net verified yes.
10 Dec 2015 09:07:46 (GMT +03:00)	(ICID 60710202) ACCEPT sender group UNKNOWNLIST match sbrs[0.0:10.0] SBRS 5.6
10 Dec 2015 09:07:46 (GMT +03:00)	Incoming connection (ICID 60710202) successfully accepted TLS protocol TLSv1.2 cipher DHE-RSA-AES256-GCM-SHA384.
10 Dec 2015 09:07:46 (GMT +03:00)	Start message 19934475 on incoming connection (ICID 60710202).
10 Dec 2015 09:07:46 (GMT +03:00)	Message 19934475 enqueued on incoming connection (ICID 60710202) from irina-dareeva@yandex.ru.

10 Dec 2015 09:07:46 (GMT +03:00)	Message 19934475 SPF: helo identity postmaster@forward10j.cmail.yandex.net None
10 Dec 2015 09:07:46 (GMT +03:00)	Message 19934475 SPF: mailfrom identity username@yandex.ru PermError

Ironport says what SPF mailfrom PermError. But if I use http://www.kitterman.com/spf/validate.html validator with these params or mxtoolbox spf check - they says what everything is fine and SPF pass:

Mail sent from this IP address: 5.255.227.111
Mail from (Sender): username@yandex.ru
Mail checked using this SPF policy: v=spf1 redirect=_spf.yandex.ru
Results - PASS sender SPF authorized

Mail sent from this IP address: 5.255.227.111
Mail Server HELO/EHLO identity: postmaster@forward10j.cmail.yandex.net

HELO/EHLO Results - none

Why ironport gives PermError in spf verification in this case?

[exMSW4319]

Both Kitterman and MX Toolbox are excellent choices, but have you tried  Dmarcian's SPF surveyor? [https://dmarcian.com/spf-survey/yandex.ru]

Your IronPort appliance's SPF check is only as good as the DNS service you give it. If the problem has since gone away, then it may simply have been DNS propagation.

If the problem persists then I'd point a client at the same DNS servers as the appliance is using and then use an nslookup to see what TXT record it returns. If the response matches the value validated by the above lookup services, I suppose you'll have to speak to Cisco TAC.

[Andrew Grudtsin]

Hello, thank you for answer.

I start dig on appliance and request txt record for domain. It seems everything is fine - dig show me correct answer, but in tracing PermError

; <<>> DiG 9.8.4-P2 <<>> yandex.ru TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25778
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;yandex.ru. IN TXT

;; ANSWER SECTION:
yandex.ru. 3197 IN TXT "mailru-verification:
530c425b1458283e"
yandex.ru. 3197 IN TXT
"google-site-verification=XyQDB5000-0rTv33yw7AX-EiuH1v5yW5PjkYeYxxPEg"
yandex.ru. 3197 IN TXT "v=spf1
redirect=_spf.yandex.ru"

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 11 11:38:20 2015
;; MSG SIZE rcvd: 201

(Machine )> dig _spf.yandex.ru txt

; <<>> DiG 9.8.4-P2 <<>> _spf.yandex.ru TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52473
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_spf.yandex.ru. IN TXT

;; ANSWER SECTION:
_spf.yandex.ru. 3132 IN TXT "v=spf1
include:_spf-ipv4.yandex.ru include:_spf-ipv6.yandex.ru ~all"

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 11 11:38:42 2015
;; MSG SIZE rcvd: 112

(Machine )> dig _spf-ipv4.yandex.ru txt

; <<>> DiG 9.8.4-P2 <<>> _spf-ipv4.yandex.ru TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20954
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_spf-ipv4.yandex.ru. IN TXT

;; ANSWER SECTION:
_spf-ipv4.yandex.ru. 3600 IN TXT "v=spf1 ip4:213.180.223.192/26
ip4:37.9.109.0/24 ip4:37.140.128.0/18 ip4:5.45.192.0/19 ip4:5.255.192.0/18
ip4:77.88.0.0/18 ip4:84.201.128.0/18 ip4:87.250.224.0/19 ip4:93.158.136.48/28
ip4:95.108.130.0/23 ip4:95.108.192.0/18 ip4:141.8.132.0/24 ~all"

;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 11 11:38:52 2015
;; MSG SIZE rcvd: 296

[exMSW4319]

It would seem that you'll be having an interesting conversation with TAC then.

Do please let us know how it turns out. Every PERMERROR I've looked into has been down to a clear mistake on the part of the sending organisation.

[Mathew Huynh]

Hey Andrew,

For deeper investigation, please open a TAC case with us and we'll be more than happy to assist you with it.

However is this happening for every email from this domain where SPF Is coming up with PermError?

Or was it a one-off for this particular sender at this time.

While the DIGs are now showing it as available, so logically the PermError should not be there, but there may have been circumstances with the DNS TXT query lookup at the time  of the noted issue.

Regards,

Matthew