안 MTA-STS mx 라인은 허용된 수신 호스트 이름을 설명합니다. 이는 MX DNS 레코드도 아니고 라우팅을 생성하는 명령도 아닙니다. 발신자는 여전히 DNS 통해 수신 경로를 얻고 후보 MX 호스트에 정책을 적용합니다.
주소가 아닌 호스트 이름을 비교하세요
DNS mx1.provider.example 및 mx2.provider.example 을 광고한다고 가정합니다. mx1에 대한 정확한 정책 패턴은 두 이름이 모두 동일한 주소로 확인되더라도 mx2도 허용하지 않습니다. 반대로 호스트 이름을 허용한다고 해서 그 뒤에 있는 모든 서버 주소가 작동되는 것은 아닙니다. 이름 비교와 별도로 DNS 경로 데이터 및 전송 테스트를 유지합니다.
패턴당 하나의 mx 라인을 사용하십시오. 정책 패턴은 완전히 지정된 이름이거나 가장 왼쪽 레이블 전체인 와일드카드일 수 있습니다. 국제화된 이름은 A-레이블 표현을 사용해야 합니다. 이메일 주소, IP 리터럴 또는 공급자 콘솔 레이블을 MX 패턴 목록에 입력하지 마세요.
단일 레이블 와일드카드 이해
RFC 8461 섹션 4.1에 따라 *. example.net 은 mail.example.net 과 일치합니다. example.net 또는 foo.bar.example.net 과 일치하지 않습니다. 메일*과 같은 부분 라벨. example.net 허용되는 와일드카드 형식이 아닙니다. *를 선택합니다. 따라서 example.net 임의 깊이의 모든 하위 항목을 승인하지 않고 허용된 세트를 단일 레이블 하위 항목으로 확장합니다.
해당 범위를 실제 수신 인프라와 연결하여 유지하세요. 광범위한 공급자 와일드카드는 지원되는 마이그레이션 중에 편리할 수 있지만 자동으로 가장 안전한 정책은 아닙니다. 브랜드 이름에 와일드카드를 사용하기보다는 공급자의 현재 문서화된 요구 사항과 실제 MX 답변을 확인하세요.
이름 비교 살펴보기
이러한 합성 예제는 RFC 8461 섹션 4.1을 직접 적용합니다. 이는 실행된 네트워크 테스트나 완전한 정책 유효성 검사기가 아닌 수작업으로 수행된 비교입니다.
- 패턴 *. example.net , 후보 mail.example.net : 일치합니다. 가장 왼쪽 레이블 전체를 바꾸면 필수 example.net 접미사가 남습니다.
- 패턴 *. example.net , 후보 example.net : 일치하지 않습니다. 후보에는 추가적인 맨 왼쪽 라벨이 없습니다.
- 패턴 *. example.net , 후보 foo.bar.example.net : 일치하지 않습니다. 가장 왼쪽 레이블을 제거하면 example.net 이 아닌 bar.example.net 남습니다.
- 정확한 패턴 mx1.provider.example , 후보 mx2.provider.example : IP 주소가 동일하더라도 일치하지 않습니다.
- 패턴 메일*. example.net : 잘못된 와일드카드 형식이므로 허용되는 패턴으로 처리하지 마세요.
비교에서는 정규화된 ASCII 이름을 사용합니다. 프로덕션 구현에는 완전한 구문 분석, 국제화된 이름 처리, 정책 검색 및 TLS 유효성 검사도 필요합니다. 이러한 사례를 이해하는 데에는 동반 스크립트가 필요하지 않습니다.
나머지 연결을 확인하세요.
후보가 패턴과 일치하면 수신 서버는 여전히 필요합니다. STARTTLS 해당 후보 호스트 이름과 일치하는 유효하고 신뢰할 수 있으며 만료되지 않은 인증서. 인증서의 subjectAltName에 일치하는 DNS-ID가 포함되어 있어야 합니다. 인증서 와일드카드와 정책 와일드카드는 서로 다른 문서를 차지하므로 독립적으로 확인해야 합니다. 관련되지 않은 인증서는 허용된 mx 라인으로 복구할 수 없습니다.
변경 중에 모든 현재 및 계획된 MX 이전 정책과 새 정책 모두와 비교하십시오. 이는 현재 정책이 새로 추가된 호스트를 허용하지만 여전히 이전 정책을 시행하는 발신자는 허용하지 않는 중요한 경우를 포착합니다. 정책이 에이징 또는 새로 고침을 캐시하는 동안 이전에 허용된 경로는 계속 작동합니다.
정책 모드 중요: MTA 유효한 시행 정책을 준수하는 것은 MX 일치, 인증서 검증 또는 STARTTLS 요구 사항에 실패한 후보에게 전달되어서는 안 됩니다. 테스트 중에는 검증 실패에도 불구하고 배송이 진행될 수 있습니다. 이러한 검사는 모든 발신자가 MTA-STS 구현한다는 것을 증명하지 않습니다.
이주 체크카드를 사용하세요
- 백업을 포함하여 현재 및 계획된 모든 DNS MX 호스트 이름을 나열합니다.
- 각각을 이전 정책 패턴과 제안된 정책 패턴과 비교하십시오. 대신 IP 주소를 비교하지 마십시오.
- 허용된 각 후보에 대해 STARTTLS 및 인증서 체인, 유효 기간 및 호스트 이름을 독립적으로 확인하세요.
- _mta-sts TXT 정책 식별자를 변경하기 전에 새 HTTPS 정책 본문을 게시하세요.
- 발신자가 변경 사항을 발견하는 동안 이전 정책과 호환되는 전달을 유지합니다. DNS TTL 및 캐시된 정책 수명을 고려하세요.
- 정책 범위를 확장하거나 트래픽을 이동하기 전에 알 수 없는 사항이나 실패한 검사를 기록하세요.