SPF "hardfail"에도 불구하고 왜 이메일이 정상적으로 전달됩니까?

이메일에 SPF가 표시되어 있어도 위조 된 이메일이 주요 이메일 제공 업체 (gmail.com, outlook.com)에 전달되는 이유를 알아 내려고합니다 hardfail. 전자 메일은 Microsoft Exchange에도 전달되어 PermError동일한 SPF 레코드를 처리합니다.

깨진 SPF 레코드를 정의하는 SOME_DOMAIN.com 도메인을 사용하여 이메일을 보내고 있습니다. 이메일은 SOME_DOMAIN.com의 SPF 레코드에 명시 적으로 나열되지 않은 내 자신의 IP 주소에서 전송됩니다. SOME_DOMAIN.com의 SPF 레코드에는 다음과 같은 세 가지 속성이 있으며 처음 두 가지는 SPF RFC-4408을 위반 한 것입니다.

1. 로 인해 전체 SPF 레코드를 해결하려면 10 개 이상의 DNS 쿼리가 필요합니다 include:.
2. SPF 레코드 중 하나의 구문 오류 인 python-spf는 구문 분석 오류를 발생시킵니다.
3. SPF 레코드는 모두 규칙을 포함 ~all하고 -all모두 말하는 모든 주소 설정해야 softfail하고hardfail

admin@SOME_DOMAIN.com으로 가장 한 outlook.com 주소로 전송 된 전자 메일에는 배달 된 전자 메일의 SMTP 헤더에 다음 오류가 포함됩니다. 이 이메일은 일반적으로 사용자의받은 편지함 에 전달 되었습니다 .

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

Gmail은 이메일을 사용자의받은 편지함에도 전달하지만 다른 SPF 오류가 발생합니다.

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

무슨 일이야? SPF에도 불구하고 이메일이 전달되는 이유는 무엇 hardfail입니까? SPF 레코드가 손상되었다는 것은 다른 SMTP 서버가 SPF를 완전히 무시한다는 의미입니까? 아니면 내가 여기서 놓친 것이 있습니까?

SPF는 MTA를받는 많은 사이트에 의해 잘못 구성되어 종종 hardfail자문으로 만 간주 되며 스팸 탐지 점수에 반영하기 만합니다. 결국 SPF 장애를 처리하는 방법은 MTA 관리자에게 달려 있습니다.

SPF 오류 조건은 원하는 정책에 대해 아무 것도 나타내지 않습니다. 따라서 메시지를 수락할지 여부에 대한 지침을 제공하지 않습니다. 의도 한 정책은 다음과 같습니다 +all. 이 경우 메일을받는 것이 일반적입니다. Google이이 도메인이 표준을 준수하지 못한 것에 대해 관대함을 나타냅니다.

-all발신자 주소를 확인할 때 SPF 정책 거부 ( ) 조차 신뢰할 수 없습니다. 이러한 메일을 거부하는 것이 부적절한 경우는 다음과 같습니다.

• 계약 된 우송 자에 의해 발송 된 우편물 (이 사람들은 정책을 위반하여 돈을 받는다);
• 웹 양식 및 기타 자동 시스템에서 발송 된 메일
• 메일 링리스트 또는 다른 전달 메커니즘에 의해 전달되는 메일 과
• SPF 레코드를 잘못 잘못 구성한 경우 (흔하지는 않지만 충분하지는 않음)

하드 실패를 미연에 방지 할 수있는 상당히 작은 서버를 운영하고 있습니다. 이를 통해 합법적 인 실패를 허용 할 수 있습니다. 발신자가 메일이 배달되지 않는 것을 확인하면 구성이 수정 될 수 있습니다. 경우에 따라 관련에 연락하려고 시도 postmaster하지만 많은 도메인에 postmaster주소 가 없습니다 .

보다 강력한 정책을 적용하려는 사용자는 아직 표준이 아닌 DMARC를 사용할 수 있습니다. 메일은 여전히 ​​배달 될 가능성이 있지만 해당 정책에 지정된대로 격리 또는 거부 될 수 있습니다. 정책에 실패한 메일은 일반받은 편지함이 아닌 스팸 폴더로 배달 될 수 있습니다.

SPF 하드 실패는 보내는 서버의 ID를 확인하는 데 신뢰할 수있는 것 같습니다. 나는 얼마 전에 조사를 해본 결과, HELO 이름에 대한 소프트 실패조차도 수신 메시지를 실패하거나 연기하는 합리적인 이유임을 발견했습니다.

많은 메일 서버에는 SPF 레코드가 없습니다. 메일 서버에 SPF 레코드가 없으면 SPF 레코드가 있는지 부모 도메인을 확인합니다. 이것은 비표준이지만 효과적입니다. 전자 메일 관리자는 PTR 레코드에 나열된 서버 IP에 대한 SPF 레코드가 있는지 확인하는 것이 좋습니다. 서버는 PTR 레코드가 리턴 한 이름으로 자신을 식별해야합니다. 역방향 DNS 확인을위한 해당 A 레코드가 있는지 확인하십시오.