Openprovider가 활성 영역을 제공하는지 여부 설정
이 가이드에서는 Openprovider DNS 의 인증 레코드 게시에 대해 설명합니다. Openprovider의 별도 메일박스나 포워딩 제품에 대한 구성 가이드가 아닙니다. Microsoft 365 , 캠페인 서비스 또는 다른 공급자가 메일을 보내는 동안 도메인을 Openprovider에 등록할 수 있습니다. 발신자는 인증 지침을 제공합니다. 권한 있는 DNS 운영자는 승인된 기록을 게시합니다. 작업을 할당할 때 이러한 역할을 별도로 유지하십시오.
Openprovider는 자체적으로 지원합니다. 네임서버 그리고 외부 네임서버. 네임서버 가이드에서는 외부 호스팅 영역은 외부 DNS 공급자에서 구성해야 하며, Openprovider 호스팅 영역은 DNS 관리 및 DNS 영역 개요를 통해 관리된다고 설명합니다. 실제 공개 위임과 변경 중인 정확한 영역부터 시작하세요. 등록된 도메인과 계정에 보이는 영역만으로는 권한을 확립하기에 충분하지 않습니다. Openprovider 네임서버 지침
단지 이름을 만들기 위해 네임서버를 변경하지 마세요. SPF 편집 가능. 이는 웹사이트, 인바운드 메일, 검증 토큰 및 DNSSEC. 외부 공급자가 권한이 있는 경우 승인된 기록 변경 사항을 해당 공급자의 관리자에게 전달합니다. Openprovider가 신뢰할 수 있는 경우 나중에 사용할 템플릿이 아닌 라이브 영역을 편집하고 있는지 확인하세요.
전송 서비스에서 레코드 변경 사항을 수집합니다.
현재 발신자가 발급한 SPF 인증을 요청하고, DKIM 소유자 및 값, 사용자 정의 봉투 지침, 각각이 적용되는 정확한 도메인. Openprovider SPF 설정이라는 범용 레코드를 피하세요. DNS 호스트는 단순히 영역을 호스팅한다고 해서 인증된 메일 발신자가 되는 것은 아닙니다. DKIM 에도 동일한 구별이 적용됩니다. Openprovider의 DKIM 기사에는 보내는 메일 서버가 기록 내용을 결정하고 공급자나 시스템 엔지니어가 이를 제공한다고 나와 있습니다. Openprovider DKIM 출판물
소유자 이름, 유형, TTL 및 값을 포함하여 영향을 받는 전체 레코드 세트를 내보내거나 보존합니다. 관련되지 않은 TXT 토큰을 그대로 유지하세요. 서비스 소유자 및 이유와 함께 제안된 각 작업을 추가, 교체 또는 폐기로 기록합니다. 에이 선택자 오래된 것으로 보이는 메일은 여전히 대기 중인 메일의 유효성을 검사하거나 다른 응용 프로그램을 지원할 수 있습니다. 새로운 서비스의 명령은 이전 서비스의 키 삭제를 승인하지 않습니다.
정규화된 의도 소유자를 편집자 입력에서 분리하세요. DKIM 의 경우 선택기와 _domainkey 라벨이 필수적입니다. 도메인 정점과 상호 교환할 수 없습니다. 을 위한 DMARC, 해당 _dmarc 소유자를 식별합니다. SPF 의 경우 실제 SMTP 봉투 도메인을 식별합니다. 검색된 DNS 레코드 가이드는 현재의 보편적인 정점 항목 규칙을 설정하지 않습니다. 저장하기 전에 루트 소유자 및 추가된 접미사의 현재 인터페이스 처리를 확인하십시오. 모든 입력 모드에서 빈 필드나 @가 허용된다고 가정하지 마세요. Openprovider DNS 레코드 규칙
확인된 TXT 형식을 사용하여 SPF 하나의 정책으로 게시합니다.
Openprovider의 SPF 가이드는 다음을 사용합니다. TXT 레코드 사용자에게 콘텐츠를 곧은 따옴표로 묶으라고 구체적으로 지시합니다. 현재 편집자의 문서화된 입력 규칙을 따른 다음 게시된 TXT 답변을 검사하여 형식이 올바르게 해석되었는지 확인하세요. 워드 프로세서에서 복사한 둥근 따옴표는 동일하지 않습니다. 해석기가 이미 따옴표가 포함된 문자열을 표시하는 경우 인용 레이어를 반복적으로 추가하지 마십시오. Openprovider SPF 게시
프로토콜 의미론이 수용 기준입니다. 평가된 소유자에는 하나의 후보 SPF 정책이 있어야 합니다. TXT 레코드에는 SPF 처리를 위해 결합된 여러 문자열이 포함될 수 있으므로 표시 분할이 반드시 여러 정책일 필요는 없습니다. 반대로, SPF 버전 표시로 시작하는 두 개의 개별 레코드는 두 명의 보낸 사람을 수용하는 유효한 방법이 아닙니다. 재구성된 값에 필요한 공간과 전체 메커니즘 시퀀스를 보존합니다. SPF RFC 7208
공급자의 일반 SPF 문서에는 TXT 길이에 대한 단순화된 언어가 포함되어 있으며, DNS 레코드 가이드에서는 큰 TXT 값을 하나의 레코드 내에서 더 작은 문자열로 분할하는 방법을 명시적으로 설명합니다. 문자열 제한은 총 레코드 제한으로 처리되어서는 안 됩니다. 현재 편집자의 처리를 확인하고 재구성된 답변을 확인합니다. Openprovider TXT 레코드 지침 긴 값이 거부되면 공급자 지침을 얻으세요. 공개 키를 단축하거나 SPF 정책을 독립된 기록으로 분할하지 마십시오.
병합된 정책을 저장하기 전에 SPF 의 재귀 조회 제한을 평가하십시오. 시각적으로 짧은 정책도 포함된 정책을 통해 한도를 초과할 수 있습니다. 유지 관리 모델이 의도적으로 승인 및 지원되지 않는 한 공급자가 유지 관리하는 메커니즘을 현재 IP 주소의 스냅샷으로 대체하지 마십시오. 향후 인프라 변경 사항을 추적해야 하는 정적 평면화 변경 사항입니다.
DKIM 레코드 유형 및 선택기 소유권을 그대로 유지
일부 전송 서비스는 TXT 공개 키를 제공합니다. 다른 사람들은 CNAME 별명. 제공된 선택기 소유자에 제공된 유형을 게시합니다. CNAME 대상을 TXT 필드에 넣거나 정점에 키를 게시하지 마세요. 수신자는 메시지의 서명 도메인 및 선택기에서 조회를 파생하므로 다른 소유자의 그럴듯해 보이는 레코드가 도움이 되지 않습니다. DKIM RFC 6376
Openprovider는 CNAME 소유자를 다른 일반 레코드 데이터와 공유할 때 오류를 문서화합니다. 편집자가 중복 또는 CNAME 충돌을 보고하는 경우 해당 소유자의 전체 레코드 세트를 검사하세요. 해당 레코드를 소유한 발신자를 식별하기 전에 충돌하는 TXT 레코드를 삭제하지 마십시오. 새 발신자에게 지원되는 충돌하지 않는 선택기를 요청하거나 제어된 순환을 계획하세요. 충돌은 단순한 입력 검증 문제가 아니라 신뢰 소유권 문제입니다. Openprovider CNAME 충돌 지침
공개 키 또는 위임 레코드로 인해 전송 서비스가 서명을 시작하지 않습니다. 발신자 측 활성화를 별도로 완료하고 실제 메시지의 서명을 확인하십시오. 영역이나 워크시트에 개인 키, API 자격 증명 또는 SMTP 비밀번호를 게시하지 마십시오.
수동 DMARC 와 호스팅 위임 구별
Openprovider의 EasyDMARC 통합은 두 가지 관리 경로, 즉 CNAME 별칭을 통해 도달하는 호스팅 정책과 수동으로 유지 관리되는 TXT 정책을 설명합니다. 예시에 표시된 위임 대상은 사용할 값이 아님을 경고합니다. 제어판은 실제 목표를 제공합니다. 또한 Openprovider 네임서버를 사용하여 적격 구매 또는 활성화 흐름에서 자동 CNAME 생성에 대해 설명합니다. 따라서 수동으로 항목을 추가하기 전에 기존 _dmarc 소유자를 검사하십시오. Openprovider EasyDMARC 관리
승인된 관리 모델 하나를 선택하세요. 호스팅 위임을 사용하면 Openprovider 영역에서 해당 편집 없이 호스팅 서비스에서 운영 정책이 변경될 수 있습니다. 해당 서비스의 소유자를 할당하고 승인된 정책 설정을 유지합니다. 수동 TXT 사용하면 변경사항이 게시된 값에 반영되어야 합니다. TXT 정책과 CNAME 동일한 소유자에게 두지 말고 단지 통합 마법사를 따르기 위해 기존 보고 대상을 교체하지 마십시오.
DMARC 정렬된 SPF 또는 DKIM ID 전달과 비교하여 표시되는 보낸 사람 도메인을 평가합니다. 출판은 그 과정의 한 부분입니다. 이는 도메인의 발신자가 일치함을 증명하지 않습니다. 요청된 정책과 수신자 동작을 구별하고 시행을 강화하기 전에 도메인 전체의 발신자 인벤토리를 유지하세요. DMARC RFC 9989
재사용 가능한 Openprovider 게시 워크시트
변경된 각 소유자에 대해 하나의 행을 만들고 도메인에 대한 공유 변경 기록을 유지합니다.
- 도메인, 신뢰할 수 있는 네임서버 및 라이브 영역 식별자: ______.
- DNS 관리자, 보낸 사람 관리자 및 변경 승인자: ______.
- 전송 서비스 및 현재 구성 증거: ______.
- 의도된 완전한 소유자 및 별도의 편집자 호스트 입력: ______.
- 기록 유형, 전체 승인 값 및 TTL: ______.
- 살아남아야 하는 이전 레코드 세트 및 종속성: ______.
- SPF 평가 봉투 소유자 및 재귀 정책 확인: ______.
- DKIM 선택기 소유권, 충돌 검토 및 발신자 활성화: ______.
- DMARC 수동 TXT 또는 호스팅된 CNAME 선택 및 정책 소유자: ______.
- 신뢰할 수 있는 변경 후 답변 및 재귀 비교: ______.
- 받은 메시지 참조, 보낸 사람, 봉투, 서명 및 신뢰할 수 있는 결과: ______.
- 롤백 단계, 소유자 재테스트, 육안 확인 및 사람의 승인: 보류 중입니다.
선택기 충돌의 가상 진단
이 예는 허구입니다. 리셀러는 Openprovider가 호스팅하는 DNS 의 도메인에 새로운 마케팅 서비스를 추가합니다. 새 서비스는 송장 발신자의 TXT 키를 이미 보유하고 있는 선택기에서 CNAME 요청합니다. Openprovider는 충돌로 인해 변경 사항을 거부합니다. 새 설정 가이드에 선택기가 필요하다고 나와 있으므로 리셀러는 TXT 제거를 제안합니다.
안전한 조사를 통해 송장 보낸 사람을 식별하고 해당 선택기로 나가는 메시지에 여전히 서명하는지 확인합니다. 제안된 복구는 마케팅 서비스에서 지원되는 다른 선택기를 요청하거나 두 소유자 모두와 확인된 키 전환을 조정하는 것입니다. 무작정 송장키를 삭제하는 것이 아닙니다. 변경이 승인되면 별도의 송장 및 마케팅 메시지가 테스트됩니다. 이 시나리오에서는 실제 영역, 보낸 사람 또는 성공적인 테스트를 나타내지 않습니다.
DNS 및 메시지 증거로 종료
응답을 저장하고 보존한 후 권한 있는 네임서버에서 정확한 소유자를 쿼리합니다. 캐싱을 인식하여 재귀적 답변을 별도로 비교합니다. 그런 다음 영향을 받은 각 발신자가 독립적인 사서함에 대해 제어된 메시지를 생성하고 신뢰할 수 있는 수신자 결과를 기록하도록 합니다. DNS 전용 유효성 검사기는 보낸 사람이 실제로 어떤 선택기를 사용하는지 또는 전달하는 ID가 일치하는지 확인할 수 없습니다.
복구가 필요한 경우 영향을 받은 이전 레코드 세트만 복원하고 관련 워크플로 테스트를 반복합니다. 호스팅 정책 설정과 DNS 값의 증거는 독립적으로 변경될 수 있으므로 보존하십시오. 이 가이드에 대한 현재 계정 액세스, 인터페이스 스크린샷, 신뢰할 수 있는 전후 캡처, 수신된 메시지 증거 및 인간 SME 승인이 보류 중입니다. DNS 편집이나 라이브 테스트가 수행되지 않았습니다.
공개 기록을 암호화 작업과 별도로 보관하세요.
공개 키를 게시한다고 해서 이메일 본문이 암호화되거나, 서명이 생성되거나, 전체 메시지가 안전한지 확인되지는 않습니다. 공급자 문서의 단순화된 암호화 설명 대신 서명 의미에 대해 DKIM 표준을 사용하십시오. 발신자 운영자가 활성화를 완료한 후 실제 서명된 콘텐츠와 수신자 결과를 확인합니다.
정책 출시와 별도의 메시지 승인
정렬된 SPF 결과를 통과하면 메시지 평가를 만족할 수 있지만 전체 도메인을 거부하도록 이동하는 것만으로는 충분하지 않습니다. RFC 9989 섹션 7.4에는 도메인 게시를 위한 유효한 DKIM 필요합니다. p=reject 간접 메일 상호 운용성에 대해 경고합니다. 정책 소유자가 시행을 승인하기 전에 모든 합법적인 발송인과 간접 경로의 목록을 작성하십시오. 이 문서에서는 DNS 변경, 테넌트 작업 또는 메시지 수신 테스트가 실행되지 않았습니다.