
관리자가 SPF 레코드에서 주로 +a
병용을 사용하는 이유는 무엇입니까 ? +mx
예는 다음과 같습니다.
@ 10800 IN TXT "v=spf1 +a +mx -all"
매개변수 만 사용하는 것만으로는 충분하지 않습니다 +mx
. 예:
@ 10800 IN TXT "v=spf1 +mx -all"
MX 레코드의 작업은 A 레코드가 아닌 이메일을 보내는 것이라고 생각했습니다. 누구든지 왜 그런 다음 사용하는 시나리오를 설명할 수 있습니까 +a
?
답변1
솔직히 그들은 SPF의 기본 원칙을 모르고 일부 튜토리얼이나 예제 구성에서 구성을 복사했기 때문입니다. 때로는 웹 서버가 들어 a
오고 들어오는 것이 모두 필요합니다.메일교환 mx
메일을 보내는 데에도 사용되지만 거의 항상 그런 것은 아닙니다.
추가 DNS 쿼리 가 적은 메커니즘 을 선호하는 것이 더 좋습니다 ip4
.ip6
a
a
mx
RFC 7208, 10.1.1) 그리고 더 쉬운 관리를 위해 (10.1.2), 메커니즘이 선택됩니다. 항상 또는 은 a
아니지만 예를 들어 .a mx
a
a:relay.example.com
답변2
기록 에 나열된 호스트의 임무 MX
는 다음과 같습니다.받다이메일(반드시 그럴 필요는 없음)배달하다이메일.
인바운드 및 아웃바운드 이메일을 처리하는 호스트가 동일하지 않은 비대칭 설정을 갖는 것은 완전히 유효하며 특히 대규모 작업의 경우 매우 일반적입니다.
mx
즉, SPF의 (aka +mx
) 또는 a
(aka +a
)가 어떤 호스트가 예상되는지 지정하는 것과 관련이 있다는 보장은 없습니다.배달하다이메일.
예를 들어, 자체 메일 서버를 운영하지 않는다면 아마도 다음과 같은 것이 v=spf1 include:spf.majoremailserviceprovider.example -all
더 관련성이 있을 것입니다.
SPF 레코드에서 특정 조합이 과도하게 나타나는 이유에 대한 질문에 직접적으로 답하기 위해 a mx
, 내 생각에는 이 상황은 정책에 무엇을 넣을지 판단할 만큼 SPF 개념을 충분히 이해하지 못한 채 SPF 레코드를 추가하는 너무 많은 관리자로 귀결되는 것 같습니다. , 대신 임의로 구성된 일부 예제를 복사하여 붙여넣기만 하면 됩니다.
답변3
+a +mx
나는 아마도 화물 숭배 반관용어일 가능성이 있는 다른 답변에 동의합니다 .
를 사용하는 경우에 대해 +a
RFC 문서는 이에 대해 답변합니다.섹션 10.1.2:
개별 호스트에 대한 SPF 레코드를 게시하는 것도 모범 사례입니다. 호스트 이름은 일반적으로 5321.HELO/.EHLO 명령에 사용되는 ID입니다. null 5321.MailFrom이 있는 메시지의 경우 이는 5321.HELO/.EHLO 기반 SPF 검사에 사용되는 것 외에도 5321.MailFrom SPF 검사를 위한 도메인으로 사용됩니다. 메일 처리와 관련된 개별 호스트의 표준 SPF 레코드는 다음과 같습니다.
relay.example.com. IN TXT "v=spf1 a -all"
mail.mydomain.org
예를 들어, HELO 신원을 먼저 확인하는 검증자의 이익을 위해 메일 서버에 대한 기록을 게시합니다 . (물론 v=spf1 mx -all
메일 도메인 mydomain.org
자체에도 관례적인 기록을 게시합니다.)
답변4
길이면에서 이점이 있을 수 있지만 이것이 실제 동기가 될 가능성은 거의 없습니다.
TXT 레코드의 크기가 단일 UDP 패킷이 너무 작을 정도로 커질 수 있다는 점을 고려하십시오. 따라서 요청은 TCP로 다시 전송되고 응답은 여러 TCP 패킷과 관련 핸드셰이크 설정 시간입니다.
A 및 MX 요청을 주의 깊게 사용하면 SPF 레코드에 대해 2개의 ~1500바이트 UDP 응답(A에 대해 하나, MX에 대해 하나)을 얻을 수 있을 뿐만 아니라 모든 TXT 레코드에 대해 나머지 ~1400바이트를 얻을 수 있습니다.
이는 SPF 레코드에 3000바이트를 초과할 만큼 충분한 승인된 "사물"이 있다고 가정합니다. 포함은 길이 제한을 해결할 수도 있지만 각각 별도의 UDP 요청이거나 단일 TCP 요청 세션이라면 모호합니다.