SPF-구현해야합니까?

웹 개발자가 도메인 DNS 레코드에 SPF TXT 레코드를 포함하도록 요청했습니다. 나는 이것에 대해 다른 의견을 발견했습니다 ...

귀하가 제공 할 수있는 의견이나 통찰력은 높이 평가 될 것입니다. 나는 이것이 실증적 질문이 아니라는 것을 알고 있지만 그럼에도 불구하고 주관적 인 제안에 감사드립니다 ... 특히 그들이 참조와 함께 올 경우 나는 웹 게시물이나 온라인 문서 등과 같은 것을 볼 수 있습니다.

예. 나는 분명한 합의가 있기 때문에 이것을 주관적으로 부르지 않을 것입니다. SPF를 사용하십시오 .

구현은 매우 쉽고 인터넷 전체에 좋은 것입니다.

날짜가 표시된 참조가 표시 될 수 있습니다. SPF를 사용하는 서버에서 서버가 수신하는 유효한 전자 메일의 백분율을 기준으로 합의는 SPF를 사용하는 것입니다.

SPF를 설정하는 것이 좋습니다. 이메일 주소 및 이메일 주소에 사용하는 도메인뿐만 아니라 이메일을 보낼 수 있도록 MX에 대한 설정 레코드. 전자 메일 설정 SPF를 보내지 않는 도메인의 경우이를 나타냅니다.

전자 메일 서버의 SPF 레코드가 보낸 사람의 전자 메일 주소보다 스팸을 차단하는 데 더 유용하고 안정적입니다.

서버가 SPF 레코드를 지원하는 경우 TXT 레코드 외에 SPF 레코드를 구성하십시오. 구성을 변경하면 레코드 동기화를 유지하는 데 약간의 오버 헤드가있을 수 있지만 많은 시스템에서 SPF를 구성하여 MX 및 자동으로 변경 내용을 조정하도록 SPF를 구성 할 수 있습니다.

SPF를 사용한 이메일 평판 확보 에 대한 내 게시물을 검토 할 수 있습니다 . SPF의 첫 번째 구현은 전자 메일 서비스를 제공하는 도메인을 위조 한 스패머를 차단하는 것이 었습니다. 비교적 낮은 SPF 침투에도 불구하고 차단을 차단하는 데 매우 효과적이었습니다. 그러나 여전히 위조 된 주소로 스팸이 발송됩니다. (스패머 만 해당 주소를 사용하므로 스패머를 확인하는 가장 좋은 방법입니다.)

수신 측의 SPF 보급률이 게시 측의 보급률보다 클 것으로 생각합니다.

편집 : SPF 레코드를 사용하는 경우 자동화 된 메일 링을 제공하는 사람들이 서버를 추가해야한다는 것을 알고 있어야합니다. 자동화 된 시스템은 구성이 잘못되어 스팸봇과 유사한 프로필이있을 수 있으므로 서버를 철저히 검사해야합니다. 서버를 올바르게 설정하는 것은 어렵지 않습니다.

SPF를 확실히 설정하십시오-제대로 설정되고 테스트 된 경우에는 단점이 없어야하지만 다른 사이트가 사용자를 가장 한 것으로 위장하여 귀하의 이름으로 스팸을 보내지 못하게합니다. 좋은 이유는 도메인에 이메일을 보낼 수있는 특정 서버 / IP를 명시 적으로 허용하고 있기 때문입니다.

나는 그것이 좋은 것이라는 가장 좋은 증거는 몇 가지 주요 이메일 서비스를 보는 것입니다. SPF가 확인되었는지 확인하려면 원본 이메일에서 'Received-SPF'헤더를 찾으십시오. 예를 들면 다음과 같습니다.

야후 메일:

Received-SPF: pass (domain of example.com designates xxx.xxx.xxx.xxx as permitted sender)

Gmail :

Received-SPF: pass (google.com: domain of user@example.com designates xxx.xx.xx.xx as permitted sender) client-ip=xxx.xx.xx.xx;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of user@example.com designates xxx.xx.xx.xx as permitted sender) smtp.mail=user@example.com

Hotmail은 또한 SPF도 확인합니다 (그러나 발신자 ID라고 부릅니다). 전반적으로 도메인과 인터넷 전체에 많은 이점을 제공하는 쉬운 추가 기능입니다.

다른 응답자 (지금까지)로서 SPF를 구현하는 것이 좋습니다.

다른 게시물 중 일부는 다른 사람이 가장 무도회하기가 더 어렵다고 언급했지만 SPF가 부인의 근거가 아님을 의미하지는 않습니다 . 이러한 이벤트의 직접적인 영향이 매우 낮더라도 백스 캐터 를 줄이는 데 도움이됩니다 .

그러나 또 다른 매우 중요한 이유는 공급자가 SPF를 구현하는받는 사람에게 배달 가능성을 향상시키기 때문입니다.

SPF의 단점이 무엇인지 들어보고 싶었습니다. 현재 내가 아는 것은 다음과 같습니다.

1. 사용자는 지정된 서버를 통해 보내는 메일을 라우팅해야합니다. 보내는 메일을 제어하면 확실한 이점이 있지만 원격 사용자가있는 경우 약간의 문제가 발생할 수 있습니다. SMTP 인증 또는 VPN을 설정해야합니다.

2. 일부 전달 문제-IME는 매우 드 rare니다

SPF에서 볼 수있는 큰 문제는 앞으로 나아가는 것입니다. 이것은 현재 SPF의 wikipedia 항목에서 간단히 언급 한 것 입니다. 그리고 메일 서버에 SPF를 설정하지 않은 이유이기도합니다.

주소가있는 A a@a.org(MX가 SPF를 구현하는 사람)는 메일을 (으)로 b@b.org전달하기 위해이 주소를 설정 한 주소와 함께 B로 메일을 보냅니다 b@reallyb.org. MX reallyb.org는 A의 메일이 b.org의 MX 에서 시작된 것을보고 메시지를 버릴 수 있습니다.

따라서 SPF가 등장하기 전 수십 년 동안 일했던 것처럼 전달을 사용하는 사람들에게 계속 메일을 보내려면 적어도 사용하지 마십시오 -all.

b.org사용 된 SRS 의 MX 또는 reallyb.org메일 을 화이트리스트 용으로 MX가 들어오는 경우이 문제가 해결 될 수 있습니다 b.org. 그러나 현실에 대한 나의 견해에 따르면 대부분의 전달자는이 두 가지 중 하나를 수행하지 않습니다. 그리고 서버에서 SPF를 구현하려는 경우 A 위치에 있으므로 일반적으로 제어 할 수없는 것입니다.