[ 발송서비스 안내 ]

Web.com을 통해 전송된 이메일 인증: 구성 및 확인

제품 경계 내에서 이전 Web.com Cloud Mail SPF 지침을 검토하여 기존 발신자를 보존하고 현재 적용 가능성과 문서화되지 않은 DKIM 구현을 공개 상태로 유지합니다.

EmailAuth 연구팀 제공 · 8분 읽기

[ 핵심사항 ]

  • Cloud Mail 지침은 보편적인 Web.com 이메일 레시피가 아닙니다.
  • 문서화된 SPF 예를 선택하기 전에 기존 발신자를 검토하세요.
  • 현재 계정 적용 여부 및 DKIM 구현은 아직 해결되지 않은 상태입니다.
이 페이지에서

범위: Cloud Mail이 모든 Web.com 서비스는 아닙니다.

이 가이드에서는 카탈로그의 Web.com 인증 주제를 유지하지만 문서화된 구현을 Cloud Mail로 제한합니다. SPF. 검증된 내용은 아닙니다 DKIM 모든 Web.com 이메일 패키지에 대한 구성 가이드입니다. 사용 가능한 공급자 지침은 이전 Cloud Mail 캡처이므로 변경하기 전에 현재 계정 적용 가능성을 확인해야 합니다. Web.com에서 구입한 도메인은 그 사실만으로는 아웃바운드 이메일 서비스를 식별하지 않습니다. 등록기관 로고 대신 구독 및 전송 경로부터 시작하세요.

Cloud Mail 페이지는 해당 제품을 다른 이메일 제품과 구별합니다. 전체 DNS 설정 내에서 SPF 선택 사항으로 나열합니다. 일반적인 예는 v=spf1 include:spf.cloudus.oxcs.net ~all 입니다. 호스팅 패키지 또는 웹 사이트 문의 양식의 경우 대신 spf.registeredsite.com 및 spf.cloudus.oxcs.net 이 모두 포함됩니다. 그것은 하나를 요구한다 SPF 레코드. 이는 문서화된 예이며 현재 고객 계정에 대해 검증된 값이 아닙니다. Web.com 클라우드 메일 DNS 설정

정책을 선택하기 전에 경로를 설정하세요.

메시지 생성 애플리케이션의 소규모 인벤토리를 만듭니다. 호스팅된 메일함을 통해 제출하는 사람과 알림을 생성하는 웹사이트, 동일한 표시 주소를 사용하는 마케팅 플랫폼, 제3자 청구 서비스를 구별하세요. 각 경로에 대해 실제 구성을 확인할 수 있는 팀을 식별합니다. 불확실성을 명시적으로 기록합니다. 도메인이나 웹사이트에 대한 구매 영수증은 모든 애플리케이션이 동일한 아웃바운드 인프라를 사용한다는 증거로 충분하지 않습니다.

SPF 정책은 SMTP ID에 대한 승인된 전송 인프라를 설명합니다. 표시되는 보낸 사람 필드에 도메인이 포함된 모든 메시지를 단순히 인증하는 것은 아닙니다. 관련 봉투 ID는 표시되는 필드와 다를 수 있습니다. 이는 웹사이트가 다른 서비스를 통해 제출하거나 애플리케이션이 공급자가 제어하는 ​​서비스를 사용할 때 중요합니다. 반송 주소. 정책은 구문상 정확하지만 평가되는 ID와 관련이 없을 수 있습니다. RFC 7208 , HELO 및 MAIL FROM ID

따라서 인벤토리는 알려진 사실과 계정 액세스를 기다리는 질문을 구별해야 합니다. 표시되는 작성자 도메인, 예상 봉투 도메인, 예정 제출 경로 및 애플리케이션 소유자를 표시합니다. 알 수 없는 값은 웹메일 주소에서 파생되지 않고 비워 두세요. 이는 제안된 증거 수집 계획이며 메시지를 이미 검사했다는 보고서가 아닙니다.

SPF 준비 시 기존 발신자 유지

제안하기 전에 기록, 승인된 변경 프로세스를 통해 현재 신뢰할 수 있는 TXT 응답과 수집 시간을 유지합니다. 관련 소유자 이름에서 단일 SPF 정책을 식별합니다. 다른 TXT 레코드 해당 이름으로 공존할 수 있지만 단순히 최신 버전을 선택하는 것만으로는 여러 SPF 정책을 해결할 수 없습니다. 하나의 TXT 리소스 레코드 내의 여러 문자열도 여러 리소스 레코드와 다릅니다. RFC 7208 , DNS 리소스 레코드 및 여러 문자열

여전히 승인된 발신자를 유지하는 전후 비교를 준비합니다. 예제가 이해하기 쉽다는 이유만으로 프로덕션 정책을 짧은 공급자 예제로 바꾸지 마십시오. 마지막 all 메커니즘은 정책 의도도 표현합니다. softfail 로 끝나는 샘플은 기존 정책의 약화를 승인하지 않으며, 더 엄격한 종료로 인해 검토되지 않은 발신자 인벤토리가 완성되지 않습니다.

중첩된 포함을 포함하여 전체 평가 경로를 검토하세요. SPF 제한은 단순히 최상위 문자열에 표시되는 포함 단어의 수가 아니라 평가된 DNS 쿼리 용어와 관련됩니다. 캐싱은 과도한 정책을 유효하게 만들지 않습니다. 현재 실시간 평가가 성공했다는 주장과 별도로 제안된 종속성 검토를 캡처합니다. 여기서는 그러한 평가가 주장되지 않습니다. RFC 7208 , DNS 조회 제한 및 포함

라우팅 및 인증 변경 사항을 별도로 유지

인증 변경이 조용히 사서함 마이그레이션이 되어서는 안 됩니다. 변경 소유자는 제안된 모든 DNS 편집이 필요한 이유를 설명해야 합니다. 사서함 대상 변경은 SPF 인증 변경과 다른 서비스 결과를 가져옵니다. 롤백 계획은 이전 내보내기에서 전체 영역을 복원하라는 광범위한 지침이 아니라 실제로 승인된 레코드에 특정해야 합니다.

이러한 분리는 관련되지 않은 애플리케이션도 보호합니다. 도메인은 공개 웹사이트, 수신 메일, 서비스 검색 기록 및 위임된 제3자 서비스를 호스팅할 수 있습니다. 인증 워크시트는 정확한 소유자 이름, 유형 및 의도된 내용을 식별해야 합니다. 결과를 이해하지 못한 채 운영자에게 전체 공급자 DNS 테이블을 복사하도록 요청해서는 안 됩니다. DNS 프레젠테이션은 편집기에 따라 상대 이름이나 절대 이름을 사용할 수 있습니다. 운영자는 범용 인터페이스 규칙을 가정하는 대신 결과 소유자 이름을 확인해야 합니다. RFC 1035 , 마스터 파일 형식

DKIM 과 DMARC 별도의 승인 질문으로 남아 있습니다.

문서화된 SPF 범위가 확인된 Cloud Mail을 제공하지 않습니다. DKIM 선택기, 공개 키 또는 서명 활성화 절차. 해당 필드는 해결되지 않은 상태로 남아 있습니다. 기본 선택기를 만들거나, 다른 호스팅 제품에서 키를 빌리거나, SPF 포함의 존재를 메시지가 서명되었다는 증거로 취급하지 마십시오. DKIM 확인은 서명의 서명 도메인 및 선택기와 해당 게시 키에 따라 달라집니다. 호스팅이 보안 이메일을 지원한다는 일반적인 주장에 의해 확립되지 않습니다. RFC 6376 , DKIM-Signature 및 키 저장소

DMARC 표시되는 작성자 도메인과 필요한 관계가 있는 인증된 식별자를 전달해야 합니다. 관련되지 않은 봉투 도메인에 SPF 전달하는 것만으로는 충분하지 않습니다. 반대로, 정렬된 DKIM 통과하면 SPF 정렬되지 않는 경우에도 적격 인증 경로를 제공할 수 있습니다. 운영 검토에서는 고안된 범용 조합을 요구하기보다는 어떤 경로가 각 실제 경로를 지원하는지 기록해야 합니다. 인증은 받은 편지함 배치를 보장하거나 메시지의 비즈니스 요청이 적법하다는 것을 증명하지 않습니다. RFC 9989 , 식별자 정렬 및 범위

허구적 진단: 두 가지 적용, 하나의 경로 추정

가상의 조직인 Marlin Workshop을 생각해 보세요. 관리자는 "Web.com"을 직원 이메일과 웹사이트 영수증의 소유자로 나열합니다. 제안된 변경 사항은 가장 짧은 SPF 예를 복사하고 어떤 애플리케이션이 이를 계속 사용하는지 확인하지 않고 기존 인증을 제거합니다. 이는 보고된 사건이나 실행된 테스트가 아닌 가상의 계획 오류입니다.

검토자는 변경을 중지하고 두 개의 응용 프로그램 행을 분리합니다. 직원 사서함 소유자는 실제 제품을 식별해야 합니다. 웹사이트 소유자는 영수증 제출 방법을 설정해야 합니다. DNS 운영자는 기존 정책을 유지하고 해당 사실이 확인된 후에만 검토된 비교를 준비합니다. 경로가 다르면 증거도 달라야 합니다. 진단은 공유 인프라에 대한 지원되지 않는 가정이며 특정 공급자가 메일을 인증하지 못했다는 증거는 아닙니다.

빈 승인 워크시트

승인된 관찰 내용으로만 이 워크시트를 작성하십시오. 빈 셀은 실패한 라이브 테스트가 아니라 해결되지 않은 증거를 의미합니다.

  • 제품 및 구독 증거: ______
  • 현재 제공자 확인 및 날짜: ______
  • 애플리케이션 및 책임 소유자: ______
  • 표시되는 작성자 도메인: ______
  • 실제 봉투 신원 및 증거: ______
  • 현재 권한 있는 SPF 소유자 및 값: ______
  • 보관된 발신자에 대한 제안된 변경 사항: ______
  • 중첩된 종속성 및 조회 제한 검토: ______
  • DKIM 기능, 선택기 및 활성화 증거: ______
  • 실제 정렬 인증 결과: ______
  • 변경 승인, 롤백 및 관찰 기간: ______

릴리스 경계

이 원고는 완성된 구성이 아닌 범위가 지정된 검토 방법을 제공합니다. 현재 제품 적용 가능성, 생성된 계정 값, 신뢰할 수 있는 출판, 수신된 메시지 증거, 인간 주제 검토, 생산 경로, 시각적 접근성 및 소유자 공개는 계속 열려 있습니다. 카탈로그의 광범위한 구현 증거 요구 사항은 변경되지 않았습니다. 이 초안에 대해서는 DNS 편집, 지원 요청, 메시지 또는 테넌트 테스트가 수행되지 않았습니다.

[ 테이크아웃 ]

현재 계정을 확인한 후에만 경로별 SPF 변경을 승인하세요. 더 광범위한 인증 승인을 별도로 유지하세요.

[ 역할별 ]

이것이 당신에게 의미하는 바

실용적인 다음 단계를 위해 역할을 선택하세요.

메일 관리자

구독 확인

브랜드 이름은 발송 경로를 식별하지 않습니다.

다음 단계

  1. 실제 제품을 문서화하세요.
  2. 현재 계좌 안내를 확인하세요.

DNS 운영자

승인된 발신자 보존

샘플 정책은 기존 재고를 안전하게 대체할 수 없습니다.

다음 단계

  1. 전체 SPF 경로를 검토하세요.
  2. 라우팅 편집과 인증 편집을 분리하세요.

릴리스 소유자

DKIM 보류를 표시하세요.

SPF 설정이 완전한 인증 증거가 아닙니다.

다음 단계

  1. 서명 능력 증거를 확보합니다.
  2. 실제 정렬된 메시지 결과가 필요합니다.

[ 자주 묻는 질문 ]

자주 묻는 질문

어떤 Web.com 제품이 적용됩니까?

클라우드 메일 전용; 유지된 이전 지침에서는 다른 이메일 제품을 명시적으로 제외합니다.

Web.com: Cloud Mail DNS 설정(이전의 제한된 리더 캡처)

해당 DNS 설정 페이지에서 SPF 필수인가요?

이 페이지에는 전체 DNS 설정에서 SPF 선택 사항으로 표시되어 있습니다. 이는 인증 목적과 관련이 없다는 의미는 아닙니다.

Web.com: Cloud Mail DNS 설정(이전의 제한된 리더 캡처)

가장 짧은 예가 웹사이트 문의 양식을 다루고 있나요?

이 페이지에서는 호스팅 또는 문의 양식 사용을 위한 다양한 결합 SPF 예를 제공합니다. 선택하기 전에 현재 경로를 확인하세요.

Web.com: Cloud Mail DNS 설정(이전의 제한된 리더 캡처)

기존 SPF 레코드 옆에 다른 SPF 레코드를 게시할 수 있나요?

아니요. 적용 가능한 단일 SPF 정책을 유지하고 결합된 승인을 검토하세요.

RFC 7208 : 발신자 정책 프레임워크

SPF 패스는 표시되는 From을 자동으로 인증합니까?

아니요. SPF SMTP ID를 평가합니다. DMARC 표시되는 작성자 도메인과의 정렬을 추가로 평가합니다.

RFC 9989: DMARC

어떤 DKIM 선택기를 설치해야 합니까?

이 초안에서는 Cloud Mail 선택기 또는 활성화 워크플로가 설정되지 않습니다. 추측보다는 현재 계정과 관련된 증거를 확보하세요.

이 검토를 위해 MX 레코드를 변경해야 합니까?

이 인증 검토에서는 사서함 마이그레이션을 승인하지 않습니다. 제안된 모든 라우팅 변경에는 자체적인 근거와 승인이 필요합니다.

계정이 구성되었거나 테스트되었습니까?

아니요. 현재 적용 가능성, 실시간 기록, 수신된 메시지 증거 및 릴리스 승인은 계속 열려 있습니다.

[ 출처 ]

출처

  1. RFC 1035 : 도메인 이름 구현 및 사양

    섹션 §3.3.14 TXT RDATA 형식 · §5.1 형식

  2. RFC 9989: DMARC

    섹션 §2.4 범위 외 · §4.4 식별자 정렬 설명 · §5.3 메일 수신자 작업

  3. RFC 6376: DKIM

    섹션 §1 소개 · §3.5 DKIM-Signature 헤더 필드 · § 3.6.2.2 키 저장을 위한 리소스 레코드 유형

  4. RFC 7208 : 발신자 정책 프레임워크

    섹션 §2.3 HELO ID · §2.4 MAIL FROM ID · §3.1 DNS 리소스 레코드 · §3.2 다중 DNS 레코드 · §3.3 단일 DNS 레코드의 다중 문자열 · §4.6.4 DNS 조회 제한 · §5.2 "포함"

  5. Web.com: Cloud Mail DNS 설정(이전의 제한된 리더 캡처)

    섹션 클라우드 메일 전용 공지(20행) · 클라우드 메일 DNS 설정 방법(23~37행) · SPF 레코드(54~64행)

[ 어휘 ]

어휘

SMTP ID
SPF 로 평가된 HELO 또는 MAIL FROM ID입니다.

RFC 7208 : 발신자 정책 프레임워크

발송인 인벤토리
각 전송 애플리케이션을 소유자 및 실제 경로에 연결하는 편집 목록입니다.
DKIM 선택기
서명 도메인으로 키 조회 위치를 식별하는 서명 매개변수입니다.

RFC 6376: DKIM

조정
전달된 인증 식별자와 표시되는 작성자 도메인 간의 DMARC 관계입니다.

RFC 9989: DMARC

기업 출처

최고의 금융 기관과 정부가 필요한 이유 이메일 보안 대시보드를 폐기했습니다.

기존 이메일 인증 플랫폼은 대시보드를 판매하고 엔지니어에게 작업을 요청합니다. 위험이 높은 환경에서 수동 감독은 시행 지연, 구성 드리프트 및 모니터링되지 않는 섀도우 도메인을 의미합니다.

EmailAuth 는 에이전트 이메일 출처 플랫폼입니다. 우리 대리인은 집행합니다 p=reject, 제3자 발신자를 정렬하고 도메인을 전체로 이동하세요. RFC 9989 인간 참여형 감사 기능을 갖춘 새로운 DMARC 표준을 준수합니다.

정부 대기업 1등급 금융기관

SaaS · 전용 테넌시 · Air-Gapped 온프레미스 · BYOK 암호화

기술 자료