TransIP가 신뢰할 수 있는지 확인
이는 TransIP 메일 서비스 온보딩 가이드가 아닌 DNS 게시 가이드입니다. 도메인은 권한이 있는 동안 TransIP에 등록될 수 있습니다. 네임서버 다른 곳에 있습니다. 편집하기 전에 도메인의 공개 위임을 확인하고 권한 영역을 식별하세요. 단지 DNS 양식에 액세스할 수 있도록 하기 위해 네임서버를 전환하지 마십시오. 기존 영역 내보내기 및 승인된 변경 범위와 함께 보낸 사람의 정확한 기록 이름, 유형 및 값을 얻습니다.
이름과 값을 올바르게 입력하세요.
제어판에서 도메인을 선택하고 DNS 설정을 엽니다. 사용자 정의 편집을 위해서는 자동 TransIP 설정을 꺼야 합니다. 해당 설정을 다시 활성화하면 맞춤 레코드와 이름 서버를 덮어쓸 수 있습니다. 이름 필드에서는 zone apex에 @를 사용하고 하위 도메인에 대해 상대 이름을 사용합니다. 외부 CNAME 대상에는 전체 이름과 뒤에 점이 필요합니다. 이러한 인터페이스 규칙은 아래 TransIP 제어판 소스에 문서화되어 있습니다.
TXT 의 경우 DKIM 키를 사용하는 경우 DKIM 소스는 사용자에게 주변 따옴표와 불필요한 백슬래시를 생략하도록 지시합니다. 생성된 샘플이 아닌 보낸 사람의 공개 키를 사용하세요. 에이 선택자 보내는 하위 도메인에는 상대 소유자 이름으로 해당 하위 도메인이 필요합니다. 발신자가 실제로 CNAME 위임을 발행한 경우에만 CNAME 사용하십시오. 키를 게시해도 전송 서비스의 서명이 시작되지는 않습니다.
원본 기록 매핑 워크시트
다음은 프로덕션 구성이 아닌 example.org 영역에 대한 가상 매핑 연습입니다. 전체 DKIM 소유자 review._domainkey.news.example.org 가 검토에 매핑됩니다. 이름 필드의 _domainkey.news . 에이 DMARC 소유자 _dmarc.news.example.org 는 _dmarc.news. 그만큼 SPF owner news.example.org 는 뉴스에 매핑됩니다. 검토자가 실수로 발생한 example.org.example.org 접미사를 감지할 수 있도록 변경 티켓에 예상되는 전체 이름을 표시하세요.
SPF 및 DMARC 올바른 소유자 이름으로 TXT 정책으로 유지하세요. 클래스 및 유형을 포함한 전체 영역 파일 행을 값 필드에 입력하지 마십시오. 다수의 TXT 레코드 서로 관련 없는 목적으로 공존할 수 있지만 하나의 평가 이름에 있는 두 개의 SPF 정책은 유효하지 않습니다. 긴 DKIM 값은 주의 깊게 처리해야 합니다. 검색된 TransIP 페이지는 범용 긴 문자열 분할 절차를 설정하지 않습니다. 패널이 공급자의 전체 값을 거부하는 경우 이를 잘라내기보다는 중단하고 현재 TransIP 지침을 얻으십시오.
메일을 테스트하기 전에 게시를 확인하세요.
전체 SPF , DMARC 및 선택기 이름에 대해 각 권한 있는 서버를 쿼리합니다. 반환된 연결된 TXT 문자열을 포함하여 전체 값을 비교합니다. 위임된 키의 경우 CNAME 대상과 최종 TXT 응답을 확인하세요. 재귀 확인자를 통해 반복하고 TTL 관찰을 유지합니다. 공개 답변이 없는 올바른 제어판 디스플레이는 단순히 전파 속도가 느린 것이 아니라 잘못된 권한이나 저장되지 않은 데이터를 나타낼 수 있습니다.
그런 다음에만 전송 서비스를 통해 제어된 메시지를 트리거합니다. DNS 측 롤백은 변경된 레코드를 복원해야 하며, 자동 설정을 다시 활성화하거나 관련 없는 변경 사항을 비교하지 않고 전체 이전 영역을 복원해서는 안 됩니다.
수신자에게 신원을 증명하세요.
제어된 외부 사서함을 사용하고 무해한 콘텐츠와 고객 데이터 없이 생산 작업 흐름을 통해 보냅니다. 원시 메시지, 타임스탬프 및 수신 시스템을 저장합니다. Authentication-Results. 신뢰할 수 없는 발신자가 삽입한 인증 어설션을 무시합니다. 보이는 From 도메인을 기록하고, Return-Path 또는 인증된 봉투 ID, 모든 DKIM d= 및 s= 쌍. 표시 이름이나 회신 주소는 DMARC ID가 아닙니다.
SPF 통과는 평가된 봉투 ID에 대해 연결 서버에 권한을 부여합니다. DKIM 패스는 서명 도메인에 대한 서명의 유효성을 검사합니다. DMARC 도메인이 표시되는 From: strict와 일치하는 전달 방법이 필요합니다. 조정 동일한 도메인이 필요합니다. 완화된 정렬은 적용 가능한 조직-도메인 관계를 허용합니다. 공급자 소유 서명은 표시되는 보낸 사람을 인증하지 않고도 통과할 수 있습니다. 패스 1개 정렬 DKIM 서명 다른 서명이 실패하더라도 DMARC 만족시킬 수 있습니다. 이러한 프로토콜 규칙은 RFC 7208 , RFC 6376 및 RFC 9989, 아래에 나열되어 있습니다.
캐시를 진단하기 전에 신뢰할 수 있는 DNS 확인하세요. 정확한 이름과 유형을 신뢰할 수 있는 서버에 문의한 다음 캐시된 수명 이후 재귀 확인자를 비교하세요. DKIM 의 경우 공개 키 TXT 응답에 대한 CNAME 따릅니다. 개인 키를 게시하지 마십시오. 평가된 각 이름마다 하나의 SPF 정책을 유지하고 중첩된 포함 전체에 걸쳐 10개의 DNS 조회 유발 기간 제한을 확인하세요. 공유 SPF 정책을 공급자 예시로 대체하지 마세요.
회복과 수용
테스트에 새로운 회귀가 표시되면 영향을 받은 워크플로를 일시 중지합니다. 변경된 기록을 저장된 버전과 비교하고 다른 보낸 사람을 확인한 후 해당 변경 내용만 취소하세요. DNS 다시 확인하고 복구 후 다시 보냅니다. 값을 되돌려도 모든 확인자가 즉시 플러시되지는 않습니다. 보안 사고로 인해 취소가 필요한 경우를 제외하고 이전에 서명된 메시지가 계속 전송되는 동안 이전 DKIM 확인 기록을 사용 가능하게 유지하세요.
DNS , 애플리케이션 상태 및 실제 수신된 메시지가 일치하는 경우에만 변경 사항을 수락합니다. 흐름 소유자, 증거 타임스탬프 및 다음 검토 트리거를 기록합니다. 받은 편지함 배치만으로는 인증을 증명할 수 없으며 성공적인 인증이 받은 편지함 배치를 보장하지 않습니다. 한 공급자의 테스트에 힘입어 공유 도메인의 DMARC 정책을 강화하지 마세요. 다른 합법적인 소스를 먼저 조사하십시오.
잘못된 영역에서 올바르게 보이는 항목을 진단합니다.
서면 사례 TI-01은 도메인이 TransIP에 등록되어 있다고 가정하지만 공개 위임은 다른 DNS 운영자를 가리킵니다. 검토를 위해 저장된 TransIP 패널 항목입니다. _domainkey.news review._domainkey.news.example.org 에 게시를 설정하지 않습니다. 도메인 소유자는 권한 있는 운영자를 확인하고 거기에 승인된 기록을 정리해야 합니다. 네임서버를 변경하거나 자동 설정을 활성화하는 것은 올바른 지름길이 아닙니다. 공개 답변, 내보낸 d=/s= 및 수신자 결과는 별도로 수집될 때까지 알 수 없는 상태로 유지됩니다. 이 시나리오는 실제 DNS 조회나 패널 작업이 아닌 규정된 것입니다.
시행 경계 유지
RFC 9989 섹션 7.4에서는 p=reject, 게시하는 도메인에 대해 SPF 만 아닌 유효한 DKIM 필요하며 간접 메일과 메일링 목록 상호 운용성에 대해 경고합니다. 단일 성공적인 직접 메시지 테스트가 모든 합법적인 경로가 더 강력한 정책을 수용할 준비가 되어 있다는 증거는 아닙니다. 실제 격차를 진단하는 동안 기존에 승인된 보호를 유지합니다. 모든 정책 변경에는 자체 결정이 필요합니다.