실제 DreamHost 전송 경로 식별
이 가이드는 DreamHost에 등록된 도메인에 연결된 모든 애플리케이션이나 메일 서비스가 아닌 DreamHost에서 호스팅되는 메일에 적용됩니다. 등록, 권한 있는 DNS 호스팅 및 아웃바운드 메일 전송은 별개의 사실입니다. 웹메일, 데스크톱 메일 클라이언트, 웹사이트 문의 양식 및 뉴스레터 플러그인을 개별적으로 인벤토리에 포함합니다. 도메인의 일반 메일함은 DreamHost SMTP 사용할 수 있지만 해당 웹 사이트는 서명 동작을 변경하는 PHP 메일을 사용하여 로컬로 보냅니다.
DreamHost는 웹 메일, 메일 클라이언트 또는 SMTP 양식을 사용하여 메일 서버를 통해 전송된 메일이 자동으로 DKIM 서명되었다고 말합니다. 해당 문서에서는 일반적인 sendmail 또는 PHP 메일 경로를 포함하여 SMTP 사용하지 않는 웹사이트 메일을 명시적으로 제외합니다. 게시된 키는 자체적으로 메시지에 서명할 수 없습니다. 누락된 서명을 수정하기 위해 DNS 편집하기 전에 애플리케이션이 실제로 인증된 메일 서버를 통해 제출되는지 확인하세요.
계정 DKIM 레코드 찾기 및 게시
DreamHost가 호스팅하는 메일의 경우 DreamHost가 생성하고 관리합니다. DKIM 이메일 서비스를 사용하여 도메인 및 하위 도메인에 대한 기록. 웹사이트 관리를 열고 도메인의 점 3개 메뉴를 사용하여 DNS 설정을 선택합니다. 그리드 보기에서는 메뉴가 도메인 아래에 나타납니다. 목록 보기에서는 오른쪽에 나타납니다. 검사 TXT 레코드 이름에 _domainkey 포함되어 있습니다. 설명서에는 dreamhost가 설명되어 있습니다. _domainkey 선택자 그리고 2048비트 키가 필요하지만 도메인 값은 자체 패널에서 가져와야 합니다.
권위있는 경우 네임서버 DreamHost 외부에 있는 경우 해당 계정의 전체 레코드를 실제 DNS 서비스에 복사합니다. 기록 DreamHost 패널에 표시되는 것은 다른 공급자가 신뢰할 수 있는 경우 공개 게시를 설정하지 않습니다. 해당 편집자의 상대 이름 또는 정규화된 이름 규칙에 맞게 소유자 이름을 조정하고 결과 공개 이름을 검사합니다. 키 데이터에 공백을 삽입하지 않고 공개 키를 보존합니다. 도움말 문서에 인쇄된 예시 키를 게시하지 마세요.
다른 활성 서비스에서 사용하는 선택기는 그대로 유지되어야 합니다. 개별 서비스는 개별 선택기를 게시할 수 있지만 각 서명은 해당 d= 도메인에서 자체 s= 선택기를 확인해야 합니다. 예제 선택기를 사용한다고 가정하기 전에 메시지의 실제 서명을 확인하세요. 도메인이 다른 공급자를 통해 전송하는 경우 트래픽을 인증하기 위해 DreamHost 키를 기대하는 대신 해당 공급자의 서명 지침을 얻으세요.
기본 및 맞춤 SPF 주의 깊게 검토하세요.
DreamHost는 메일 서비스에 대한 자동 정책을 문서화합니다: v=spf1 mx include:netblocks.dreamhost.com include:relay.mailchannels.net -all . 기존 다중 제공자 정책을 보편적으로 대체하는 것이 아니라 현재 구성과 비교할 수 있는 문서화된 기본값으로 취급하십시오. 실제로 인증이 필요한 호스트와 봉투 도메인을 확인하세요. SPF 하위 도메인에 대해 별도로 평가되므로 Apex 레코드는 별도의 봉투 하위 도메인을 자동으로 포함하지 않습니다.
사용자 정의 추가 SPF 레코드 DreamHost에서는 기본 레코드를 제거합니다. DreamHost가 여전히 승인된 발신자인 경우 활성 경로 및 조회 종속성을 검토한 후 결합된 사용자 지정 정책에서 적절한 권한을 유지합니다. 또한 설명서에는 사용자 지정 SPF 레코드를 삭제하면 기본값이 자동으로 반환된다고 나와 있습니다. 이러한 동작은 복구 중에 중요합니다. 삭제한다고 해서 반드시 SPF 인증이 제거되는 것은 아니며 복원된 기본값으로 인해 다른 합법적인 서비스가 생략될 수 있습니다.
외부 권한 있는 DNS 에서 관련 정책을 관리합니다. 소유자에게는 적용 가능한 SPF TXT 정책 하나만 유지하세요. 기본값을 유지하기 위해 두 번째 항목을 추가하지 말고, 기록 예제에 표시된 모든 포함이 영원히 필요하다고 가정하지 마세요. 자동으로 복원된 기록의 영향을 포함하여 변경 후 및 롤백 후에 게시된 정책을 다시 확인하세요.
전송 계층에서 웹사이트 메일 수정
sendmail 또는 PHP 메일을 사용하는 문의 양식 또는 WordPress 플러그인의 경우 의도한 경로가 DreamHost 호스팅 메일인 경우 지원되는 인증된 SMTP 구성을 선호합니다. 플러그인의 연결 테스트뿐만 아니라 양식의 실제 출력을 확인하세요. 실제 워크플로를 트리거하고 수신된 메시지를 유지하며 서명자와 표시되는 보낸 사람 ID를 확인합니다. 애플리케이션이 성공적으로 연결될 수 있지만 프로덕션에서는 여전히 다른 보낸 사람 주소를 사용합니다.
DreamHost는 또한 관리자가 있는 전용 서버 또는 DreamCompute에 자체 관리형 DKIM 설치를 문서화하고 있지만 수동으로 설치된 소프트웨어는 지원할 수 없다고 말합니다. 이는 관리되는 SMTP 경로에 해당하는 확인란이 아닌 별도의 시스템 관리 프로젝트입니다. 문의 양식에 대해 검토되지 않은 해결 방법으로 소개하지 마세요. 이를 선택하는 경우 키, 서명, 업데이트 및 복구에 대한 별도의 운영 계획이 필요합니다.
대시보드뿐만 아니라 발신 신원도 확인하세요
녹색 설정 표시기는 제품이 수행한 확인만을 나타냅니다. 승인을 받으려면 실제 워크플로를 통해 수신된 헤더를 검사할 수 있는 사서함으로 제어된 메시지를 보냅니다. 성공적인 DNS 조회의 스크린샷이 아닌 원본 메시지를 보존하세요. 보이는 From 도메인, 수신 시스템에 표시된 SMTP 봉투 도메인을 각각 기록합니다. DKIM 서명'sd= 서명 도메인, s= 선택자, 수신 시스템 Authentication-Results. 발신자가 인증 결과 필드를 삽입했다는 이유만으로 Authentication-Results 필드를 신뢰하지 마십시오.
SPF 표시되는 보낸 사람 주소를 자동으로 인증하는 것이 아니라 봉투 ID를 인증합니다. DKIM 서명 도메인에 대한 서명을 확인합니다. DMARC 해당 항목 아래에 표시되는 From 도메인과 일치하는 전달 경로가 필요합니다. 조정 방법. 공급자 소유 봉투는 브랜드에 맞게 정렬된 SPF 생성하지 않고도 SPF 통과할 수 있습니다. 반대로, 유효하게 정렬된 DKIM 서명은 SPF 정렬되지 않은 경우에도 통과 DMARC 경로를 제공할 수 있습니다. DNS 변경하기 전에 실제 신원을 검사하십시오.
공급자의 기본값에 대한 주장이 아닌 이 예시적인 승인 사례를 사용하십시오. 메시지에는 From learning@example.com , 봉투 bounce@vendor.example.net 및 d=example.com으로 확인된 DKIM 서명이 있습니다 d=example.com. vendor.example.net 단독의 SPF 성공은 example.com 과 일치하지 않습니다. d=example.com 의 유효한 서명은 정확한 DKIM 정렬을 제공합니다. 수신자가 잘못된 서명을 보고하는 경우 해당 예시에는 더 이상 정렬된 통과 경로가 없습니다. 인증 결과와 인증이 적용되는 도메인을 모두 기록합니다.
고정된 순서로 오류 진단
먼저 정확한 도메인에 위임된 네임서버가 귀하가 편집한 서버인지 확인하세요. 예상 소유자 이름과 레코드 유형에 대해 권한 있는 서버를 쿼리합니다. 실수로 발생한 도메인 접미사 중복, 선택기 라벨 누락, 잘린 키, CNAME 충돌 등을 확인하면서 답변을 계정에 제공된 값과 비교하세요. 신뢰할 수 있는 답변이 올바른 후에만 재귀 캐싱을 조사하거나 이전 TTL이 만료될 때까지 기다려야 합니다. 보장된 전 세계 전파 마감일은 하나도 없습니다.
다음으로 실패한 경로에서 메시지 테스트를 반복합니다. 웹 애플리케이션은 사람 사서함과 다른 전송을 사용할 수 있으며 성공적인 미리 보기는 프로덕션 알림이 동일한 ID를 사용한다는 증거가 아닙니다. DNS 는 맞지만 서명이 누락된 경우 관련 없는 SPF 권한을 추가하는 대신 전송 전송 및 제품 구성을 조사하세요. 인증에 성공했지만 메일이 스팸으로 분류된 경우 헤더를 유지하고 평판, 콘텐츠 및 수신자 처리를 별도로 조사하십시오. 인증은 받은편지함 배치를 보장하지 않습니다.
변경 제어 및 완료 증거
변경하기 전에 이전 기록 세트, 승인된 새 값, 도메인 소유자, 영향을 받는 각 워크플로우의 비즈니스 소유자 및 특정 복구 결정을 유지하십시오. 보낸 사람을 추가하기 위해 동일한 소유자에게 두 번째 SPF 정책을 만들지 마십시오. 하나의 결합된 정책과 해당 DNS 조회 종속성을 검토합니다. 관련되지 않은 TXT 레코드가 공존할 수 있지만 여러 후보 SPF 정책은 오류입니다. 다른 보낸 사람의 선택기를 덮어쓰지 마십시오. 통합 실패를 위장하기 위해 전체 도메인의 DMARC 정책을 약화시키지 마십시오.
수락하려면 모든 범위 내 전송 경로에 대해 신뢰할 수 있는 DNS 증거, 제품 검증 및 수신된 메시지 ID 기록이 필요합니다. 테스트는 워크플로에서 예상하는 위치에 별도로 응답합니다. 이는 완료된 테스트가 아닌 제안된 검사입니다. 이 가이드는 실시간 테넌트 변경, DNS 측정 또는 전달된 메시지 결과 없이 보관된 문서 및 종합적 추론을 기반으로 합니다. 인간 소유자는 증거를 검토하고 생산 개시를 승인해야 합니다. 교체가 시연될 때까지 기존 작업 경로를 사용 가능하게 유지하고, 남은 종속성이 이를 사용하지 않는다는 것을 확인한 후에만 사용되지 않는 권한을 제거하십시오.
정책을 변경하기 전에 전송 불일치를 평가하세요.
서면 사례 DH-01의 경우 help@example.com 의 직원 웹 메일에 신뢰할 수 있는 전달 DKIM 서명 d=example.com, s=dreamhost. 웹사이트 양식은 대신 PHP 메일을 사용하며 DKIM 서명이 관찰되지 않습니다. SPF 결과는 알려져 있지 않습니다. 첫 번째 경로에는 규정된 정렬 경로가 있지만 두 번째 경로는 모든 메커니즘이 자동으로 실패하는 대신 해결되지 않은 상태로 유지됩니다. 웹사이트 소유자에게 지원되는 SMTP 구성을 확인하고 승인된 테스트에서 무해한 양식 이벤트를 트리거하도록 요청하세요. 패널 키는 누락된 서명을 제공하지 않습니다. 실제 메시지, 플러그인 또는 DNS 레코드는 테스트되거나 변경되지 않았습니다.
복구를 위해 사용자 지정 정책을 삭제하기 전에 현재 SPF 기록을 승인된 기준과 비교하세요. 이 공급자의 문서화된 동작에서 삭제하면 기본값이 복원됩니다. 이는 이전 다중 보낸 사람 정책 전체를 복원하는 것과 반드시 동일하지는 않습니다.
시행 경계 유지
RFC 9989 섹션 7.4에서는 p=reject, 게시하는 도메인에 대해 SPF 만 아닌 유효한 DKIM 필요하며 간접 메일과 메일링 목록 상호 운용성에 대해 경고합니다. 단일 성공적인 직접 메시지 테스트가 모든 합법적인 경로가 더 강력한 정책을 수용할 준비가 되어 있다는 증거는 아닙니다. 실제 격차를 진단하는 동안 기존에 승인된 보호를 유지합니다. 모든 정책 변경에는 자체 결정이 필요합니다.