따라서 개별 SPF 항목이 255 자 여야하거나 include연산자를 사용하여 체인을 형성하는 여러 항목을 함께 연결 해야한다는 인상을 받았습니다 . 그러나 RFC 4408 3.1.3. 특히 평가 전에 여러 문자열을 연결 IN TXT "v=spf1" " 1.2.3.4 -all"해야 하므로 동일하게 취급해야합니다 IN TXT "v=spf1 1.2.3.4 -all". 특히, 이는 임의로 큰 SPF 레코드를 허용하며 include다른 사람이 관리하는 SPF 레코드를 포함하는 도구가됩니다.
이것이 스펙의 올바른 해석입니까? 더 중요한 것은 현재 메일 서버가이 다중 문자열 유형의 TXT 레코드를 존중하는 것입니까?
답변
예, 당신은 그것을 올바르게 해석하고 있습니다. 나는 최근에 이것을 다루었 다.
이 기사는 나에게 도움이되었다 :
255 자보다 긴 TXT 또는 SPF 레코드를 가질 수 있습니까?
실제로이 개념의 주목할만한 예는 2016 년 2 월 25 일 현재 cisco.com의 SPF 레코드입니다.
> ;; QUESTION SECTION: ;cisco.com. IN TXT
>
> ;; ANSWER SECTION: cisco.com. 12775 IN TXT
> "926723159-3188410" cisco.com. 12775 IN TXT
> "v=spf1 ip4:173.37.147.224/27 ip4:173.37.142.64/26
> ip4:173.38.212.128/27 ip4:173.38.203.0/24 ip4:64.100.0.0/14
> ip4:72.163.7.160/27 ip4:72.163.197.0/24 ip4:144.254.0.0/16
> ip4:66.187.208.0/20 ip4:173.37.86.0/24" " ip4:64.104.206.0/24
> ip4:64.104.15.96/27 ip4:64.102.19.192/26 ip4:144.254.15.96/27
> ip4:173.36.137.128/26 ip4:173.36.130.0/24 mx:res.cisco.com
> mx:sco.cisco.com ~all" cisco.com. 12775 IN TXT
> "MS=ms65960035"
이미 표시된대로 레코드의 공백을 고려해야합니다.
또한 SPF RFC 에 따라 레코드에서 DNS 조회 수를 10 개로 제한해야합니다 .
SPF 구현은 “include”메커니즘 또는 “redirect”수정 자의 사용으로 인한 조회를 포함하여 DNS 조회를 수행하는 메커니즘 및 수정 자의 수를 SPF 확인 당 최대 10 개로 제한해야합니다. 점검 중에이 숫자를 초과하면 PermError가 리턴되어야합니다.