나는 이 도메인을 대신하여 메일을 보내는 다양한 다른 서비스에서 권장하는 SPF 레코드가 있는 도메인을 담당하고 있습니다.
Mailchimp를 설정할 때 Mailchimp의 권장 SPF 설정에 대한 문서가 없다는 사실에 놀랐습니다. 지원팀에 문의했을 때 Mailchimp는 기본적으로 SPF 레거시를 고려하고 6개월 이상 SPF를 사용하지 않았으며 기록을 갖는 것이 도움이 되지 않거나 방해가 되지 않는다고 생각한다는 말을 들었습니다. SPF 레코드를 완전히 삭제하라고 제안하기까지 했습니다.
나는 Mailchimp가 나보다 이메일 전달 가능성에 대해 무한히 더 많이 알고 있다는 것을 의심하지 않습니다. 그러나 Mailchimp가 이 결정을 설명하는 내용을 게시하지 않는다는 사실이 놀랍습니다. 특히 우리를 대신하여 이메일을 보내는 다른 모든 제공업체가 G-Suite를 포함하여 계속해서 SPF 사용을 권장한다는 점을 고려하면 더욱 그렇습니다.
그렇다면 무슨 일이 일어나고 있는 걸까요, 2020년에는 SPF가 쓸모없게 될까요? SPF 레코드에 Mailchimp의 서버가 없는 것에 대해 걱정해야 할까요? SPF 레코드를 완전히 삭제해야 할까요?
답변1
@jornane으로지적, Mailchimp는 자신의 도메인을봉투 보낸 사람, 고객 도메인의 SPF 레코드가 배송 계획과 관련이 없게 됩니다. 따라서 SPF 측에서는 정렬이 없으므로 적절한 DMARC 정렬을 위해 DKIM 서명이 반드시 필요합니다.
그러나 SPF가 기존 도메인이라고 말하는 것은 자신의 도메인에 SPF가 설정되어 있다는 점을 고려하면 이상한 표현입니다 mailchimp.com. DMARCLY의 기사에 따르면 자체적으로 문서화되지는 않았지만Mailchimp용 SPF 및 DKIM을 설정하는 방법(2020년 12월 9일 업데이트됨) Mailchimp에 대한 올바른 SPF 포함은 다음과 같습니다.
include:servers.mcsv.net
이 SPF 레코드는 여전히 존재하며 그들이 사용하는 IP 주소를 가지고 있는 것으로 추정됩니다.
"v=spf1 ip4:205.201.128.0/20 ip4:198.2.128.0/18 ip4:148.105.8.0/21 ?all"
나는 이 진술이 이메일 전송 업계가 SPF, DKIM 및 DMARC에 대해 갖고 있는 편향된 관점에서 나온 것이라고 생각합니다. 그들의 수사에서 이러한 기술은 모두 더 나은 평판이나 최적화된 전달에 관한 것입니다. 그들은 이를 받은편지함으로 메시지를 가져오는 도구로만 여기며 다른 사람이 귀하의 도메인에서 메일을 스푸핑하는 것을 방지하는 또 다른 측면은 아닙니다. 그러한 회사가 해당 기술의 이점을 설명하려고 할 때 거의 항상 그렇습니다. 그러나 그것은 실제 이점도 아니고 처음에 발명된 이유도 아닙니다!
Mailchimp는 "SPF가 메일 전달에 도움이 되지 않는다면 쓸모가 없을 것입니다"라고 생각했을 수도 있습니다. 내 생각에는 그들이 정말로 그런 말을 했는지는 전혀 알 수 없는 것 같습니다. 이러한 사고방식은 고객이 보다 엄격한 DMARC 정책을 따르지 못하게 할 수도 있기 때문에 해롭습니다. 이는 Mailchimp가 자신의 도메인을 봉투 발신자로 사용하고 있다는 관찰로 더 잘 설명되었습니다.
답변2
SPF의 역사로 인해 다소 복잡하지만 다음과 같습니다.
- MailChimp는 기술적으로 정확합니다.
SPF기록TXT( SPF 정책에 따라 기록을 제공하는 것과 반대 ) - SPF 사용을 완전히 중단하라고 제안하는 것은 거의 확실하지 않습니다.
SPF의 원래 구현은 TXT도메인 자체에서 특정 형식( v=spf1유효한 SPF 정책으로 시작하고 나머지를 포함하는)에 맞는 DNS 레코드를 찾았습니다. 2005년에 IANA는 SPF이론적으로 SPF 정책 제공을 위해 이를 대체하기 위해 특정 레코드에 리소스 레코드 유형 99를 할당했습니다 (모든 레코드를 쿼리한 다음 모든 레코드를 구문 분석하는 SPF대신 특정 레코드를 쿼리할 수 있다는 이론적 이점이 있음). TXT유효한 정책이 있는지 확인합니다.)
그러나 호환성상의 이유로 전용 SPF레코드 유형의 실제 사용량은 결코 그리 높지 않았습니다. 네트워크 운영자는 기존 SPF 구현이 계속 작동할 수 있도록 SPF 정책으로 기록을 정의해야 했고 TXT, 구현자는 기존 네트워크와의 호환성을 유지하기 위해 기록에서 SPF 정책을 찾는 것을 지원해야 했기 TXT때문에 어느 쪽도 이에 대한 실질적인 인센티브가 없었습니다. SPF특히 대부분의 도메인에는 많은 양의 레코드가 없으므로 TXT해당 레코드에서 정책을 구문 분석하는 것이 일반적으로 매우 빠르기 때문에 전용 레코드 유형을 사용하도록 독점적으로 전환합니다 .
이러한 저조한 활용의 결과로 SPF 작업 그룹은 2014년에 전용 SPF레코드 유형에 대한 지원을 공식적으로 중단하기로 결정했습니다. 왜냐하면 이 유형은 실제로 아무 것도 기여하지 않고 실제로 사용되지도 않았으며 어떤 경우에는 혼란을 야기했기 때문입니다(예: 혼란 여기).
그래서SPF 기록실제로 더 이상 사용되지 않지만 SPF를 제공합니다.정책도메인 에서 TXT실제로 이메일을 처리하지 않는 경우에도 레코드에 저장하는 것이 좋습니다(이 경우 정책을 정의해야 함 v=spf1 -ALL).
답변3
MailChimp가 메일을 보내는 방식은 SPF와 호환되지 않습니다., 따라서 더 이상 사용하지 않는 것이 합리적입니다.그들이 당신을 대신해 그들이 하는 방식으로 보내는 맥락에서.
MailChimp는 반송 메일을 처리하려고 합니다. 이를 위해서는 봉투 보낸 사람 주소를 자신의 도메인으로 설정해야 합니다. 즉, SPF는 귀하의 도메인이 아닌 자신의 도메인에 대해 확인해야 함을 의미합니다. 따라서 그들이 SPF 정책에서 이를 허용하도록 요청하는 것은 의미가 없습니다. 이는 일부 클라이언트가 보낸 사람 필드에 "mailchimp를 통해"를 표시하는 이유이기도 합니다.
SPF는 더 이상 사용되지 않지만 메일링 리스트 및 유사한 경우에는 적합하지 않습니다. DKIM은 From 헤더에서 작동하고 보낸 사람이 암호화하여 서명하므로 전달자에 대한 저항력이 더 강하고 제3자에게 위임하기가 더 쉽습니다. MailChimp가 이에 집중하는 것이 더 합리적입니다.
자신의 발신 메일 서버의 경우 SPF, DKIM 및 DMARC(처음 두 가지를 올바르게 수행하면 기본적으로 무료로 얻을 수 있는 세 번째)를 유지해야 합니다.
답변4
(대부분 올바른) 다른 답변 외에도 SPF와 관련하여 고려해야 할 또 다른 사항이 있습니다.
외부 서비스를 사용하여 사용자를 대신하여 이메일을 보내거나 클라우드 서비스에 이메일을 설정하고 SPF를 설정한 경우 해당 서비스 SPF 레코드를 자체적으로 포함해야 합니다.
현재 이러한 서비스의 대부분은 대형 클라우드 제공업체를 사용하므로 자체 SPF 레코드에는 매우 거대한 IP 블록, 즉 기본적으로 모든 거대 제공업체 IP 공간이 포함됩니다.
즉, 기본적으로 수십억 개의 IP 주소가 사용자를 대신하여 이메일을 보내도록 명시적으로 허용하고 스패머는 해당 IP 주소를 사용합니다(클라우드의 손상된 VM에서 이메일 보내기, M365 이메일 계정 해킹 또는 해당 서비스에서 임시 VM 생성).
따라서 귀하는 스패머가 귀하의 이름으로 이메일을 보내는 것을 명시적으로 허용하게 됩니다!
이 때문에 SPF만으로는 SPF가 없는 것보다 더 나쁩니다.
이제 이 현상에 대응하려면 DKIM과 DMARC를 사용해야 합니다.