이메일과 SMTP 공유 설정에 대한 별도의 테스트로 처리
SendPulse는 이메일 및 SMTP 에 대한 공유 인증 도메인 목록을 문서화합니다. 적용 가능한 도메인 허용량은 두 계획 중 더 높은 한도이며, 각 하위 도메인은 별도로 계산됩니다. 추적 도메인은 해당 인증 허용을 소비하지 않습니다. 현재 가이드에서는 두 개의 공유 항목을 허용하는 하나의 이메일 도메인과 두 개의 SMTP 도메인의 무료 계획 예를 제공합니다. 여러 브랜드 또는 하위 도메인을 계획하기 전에 라이브 계정의 허용량을 확인하세요. SendPulse 이메일 인증, DKIM 및 SPF 레코드 생성.
공유 설정은 중복된 DNS 작업을 줄이지만 모든 응용 프로그램이 의도한 보낸 사람 도메인을 선택한다는 것을 증명하지는 않습니다. SMTP 또는 API를 통해 제출하는 재고 마케팅 캠페인, 자동화 및 애플리케이션. 각 경로에 대한 계정과 의도한 도메인, 비즈니스 소유자, 애플리케이션 소유자 및 DNS 관리자를 캡처합니다. 이 워크시트 외부에 제출 자격 증명을 보관하세요.
이 가이드에서는 공급자의 공개 이메일 및 SMTP 인증 워크플로를 다룹니다. 무제한 도메인 허용, 독립적으로 선택 가능한 사용자 정의를 가정하지 않습니다. Return-Path 또는 모든 통합에서 동일한 최종 ID를 사용합니다. 비즈니스 요구사항이 엄격한 기준에 의존하는 경우 조정 또는 특정 봉투 도메인을 사용하려면 커밋하기 전에 SendPulse에서 지원되는 디자인을 얻으세요.
레코드를 생성하기 전에 기존 도메인을 확인하세요.
이메일에서 문서화된 진입점은 설정 > 도메인 설정이며 인증된 도메인 영역에서 활성화됩니다. SMTP 에서는 SMTP 설정 > 도메인 설정 및 발신 도메인 영역을 사용합니다. 두 워크플로 모두 생성 SPF 그리고 DKIM 입력한 도메인에 대한 기록입니다. SMTP 문서에는 서비스가 레코드 설정을 공유하기 때문에 기존 이메일 인증에는 다른 DKIM 설정이 필요하지 않다고 나와 있습니다. SendPulse SMTP DKIM , 공유 레코드 설정 및 새 도메인 추가.
기존 도메인이 이미 있는 경우 먼저 기존 도메인을 엽니다. 현재 연결 상태와 공개 값을 기록합니다. 단지 새로운 애플리케이션이 SMTP 사용하고 있다는 이유만으로 두 번째 배열을 생성하지 마십시오. 두 계정 또는 팀이 동일한 도메인을 주장하는 경우 공유 도메인을 변경하기 전에 현재 공급자가 발행한 지침을 비교하고 소유권을 명확히 하세요. 선택자.
별도로 인증된 하위 도메인을 포함하여 출시에 필요한 도메인 수를 계산합니다. 계정이 허용 범위에 있는 경우 단순히 추가 컨트롤을 노출하기 위해 작업 도메인을 제거하지 마십시오. 해당 도메인을 사용하는 곳을 파악하고 계정 소유자와 함께 계획이나 도메인 전략을 선택하세요. 상업적 자격 부여 결정은 DNS 오류와 별개입니다.
SPF 지침을 기존 정책과 조정합니다.
SendPulse SPF 가이드는 사용자에게 기존 SPF 레코드 두 번째 레코드를 생성하는 대신 해당 레코드에 제공자의 인증을 추가합니다. 인용된 가이드 이름에는 기존 정책에 추가된 include:mxsspf.sendpulse.com . 현재 계정의 도메인 설정에 대한 적용 가능성을 확인합니다. 샘플 a 및 mx 항은 자동 추가되지 않습니다. 기존 정책 위에 샘플 전체 정책을 복사하지 마십시오. SendPulse SMTP SPF , SPF 레코드 복사 및 DNS 공급자 웹 사이트에 항목 추가.
편집하기 전에 정확한 소유자에 대한 현재 TXT 답변을 내보내세요. SPF 정책에 의존하는 다른 서비스를 나열하고 가능한 경우 기본 메시지에서 실제 봉투 ID를 식별합니다. 회사의 From 도메인과 SPF 인증 도메인은 다를 수 있습니다. 임의의 정점에 포함을 게시하면 다른 곳에서 평가된 오류를 복구할 수 없습니다.
중첩된 포함을 포함하여 모든 DNS 쿼리 SPF 용어를 10년 평가 제한과 비교하여 검토합니다. 편집자의 길이 제약 조건에 맞는 DNS 레코드는 여전히 프로토콜의 평가 제한을 초과할 수 있습니다. 합법적인 권한 부여와 승인된 종료 한정자를 유지합니다. 도메인 소유자가 자신이 승인한 항목을 평가하지 않은 한 샘플 a 또는 mx 메커니즘을 사용하여 권한을 확장하지 마세요. RFC 7208 , 레코드 선택 및 DNS 조회 제한.
공급자 요청과 조직의 기존 정책을 안전하게 조정할 수 없는 경우 게시하기 전에 중지하세요. 메일 소유자에게 지원되는 전송 하위 도메인이나 다른 적절한 디자인을 평가해 달라고 요청하세요. 해당 결정이 내려지는 동안 기존 작업 경로를 계속 사용할 수 있습니다.
올바른 소유자에게 계정 공개 키를 게시하세요.
SendPulse의 지침에는 DKIM 다음과 같이 표시됩니다. TXT 레코드 데모 공개 키를 계정 자체 값과 명시적으로 구분합니다. 가이드는 표지판을 보여줍니다. TXT 소유자인 _domainkey ; 그림을 모든 계정에 대한 증거로 취급하는 대신 도메인 설정에서 현재 전체 이름과 공개 값을 검색합니다. 기사의 긴 샘플 키를 재사용하지 마세요. SendPulse SMTP DKIM , 기존 도메인 레코드 복사.
제안된 선택기 소유자의 기존 레코드를 검사합니다. 기존 키는 다른 계정, 공급자 또는 운영 경로를 지원할 수 있습니다. 자동으로 교체하거나 서비스에서 사용하지 않는 새로운 선택기를 고안하기보다는 지원되는 해상도를 요청하세요. 이전 공개 기록의 사본을 보관하면 검토자가 복구를 평가하는 데 도움이 되지만 서명 상태를 조정하지 않고 오래된 키를 복원하는 것을 승인하지는 않습니다.
반드시 도메인 등록 기관이 아닌 권한 있는 DNS 공급자를 사용하세요. 편집자가 상대 호스트 또는 완전한 이름을 기대하는지 확인하십시오. 저장 후 전체 소유자에게 쿼리하고 전체 공개 값을 계정 출력과 비교합니다. TXT 문자열은 세그먼트로 표시될 수 있습니다. 조각 사이에 공백을 삽입하는 대신 결합된 내용을 비교하십시오.
공개 검증 자료만 DNS 또는 구현 워크시트에 속합니다. DNS 검토에는 개인 서명 키, SMTP 비밀번호 및 API 비밀이 필요하지 않습니다. 자격 증명을 보내지 않고 영향을 받은 도메인 및 공개 기록 증거를 지원하십시오.
연결 상태 및 발신자 선택 확인
이메일 문서에서는 DNS 레코드 확인을 사용하고 성공적인 항목을 연결됨으로 변경합니다. 또한 설정 지침에 따라 보낸 사람 주소 도메인과 일치하는 인증된 도메인이 필요합니다. SendPulse 이메일 인증, DKIM 및 SPF 레코드 생성 및 항목 상태 확인.
서비스 보기와 기록 타임스탬프 모두에서 해당 상태를 확인하세요. 한 팀에 다른 도메인 목록이 표시되면 DNS 변경하기 전에 두 팀 모두 의도한 계정에 있는지 확인하세요. 한 계정의 상태가 다른 계정이 준비되었음을 증명한다고 가정하지 마십시오.
그런 다음 마케팅 작업 흐름과 모든 제출 신청서에서 구성된 보낸 사람 주소를 검사합니다. 마이그레이션 후 이전 도메인을 유지할 수 있는 자동화된 템플릿과 애플리케이션 기본값을 검토하세요. 미리보기 화면에서 선택한 발신자는 백그라운드 작업에서 사용하는 주소와 다를 수 있습니다. 테스트 중인 프로덕션과 유사한 워크플로의 실제 설정을 캡처합니다.
추적 도메인 구성을 별도로 유지하십시오. 브랜드 추적 도메인은 링크에 유용하지만 보낸 사람이 선택한 인증된 도메인을 대체하지는 않습니다. 수락 기록은 추적 호스트 이름이나 명백한 브랜드 메시지로부터 DKIM 또는 SPF 정렬을 추론해서는 안 됩니다.
이메일과 SMTP 경로를 독립적으로 증명
하나의 대표캠페인과 하나의 대표신청서를 통해 무해한 메시지를 보내세요. 다양한 From 도메인, 애플리케이션 재정의 또는 라우팅 배열에 대한 추가 사례를 추가합니다. 통제된 외부 수신자를 사용하고 원래 헤더, 메시지 ID, 제출 시간 및 워크플로 식별자를 유지합니다.
각 경우에 대해 표시되는 보낸 사람, SPF 인증 도메인, Return-Path 및 모든 DKIM d= 및 s= 값을 기록합니다. DKIM 서명 도메인 및 선택기는 공개 키 조회를 식별합니다. DNS 의 유효한 키만으로는 해당 키가 사용된 실제 메시지를 증명할 수 없습니다. RFC 6376 , DKIM-Signature 헤더 필드 및 메시지에서 서명 추출.
신뢰할 수 있는 수신기 결과를 사용하여 암호화 패스와 정렬된 패스를 구별합니다. DMARC 적격 정렬 SPF 또는 DKIM 결과를 통과할 수 있으며 정렬 모드는 도메인 비교에 영향을 미칩니다. "인증 통과"만 작성하는 대신 어떤 메커니즘이 결과를 제공하는지 기록합니다. RFC 9989 , 식별자 정렬 설명 및 DMARC 평가.
캠페인은 통과했지만 애플리케이션은 통과하지 못한 경우 먼저 실제 보낸 사람, 계정 및 경로를 비교하세요. 첫 번째 응답으로 공유 키를 순환하지 마세요. 해당 변경 사항은 애플리케이션의 잘못된 보낸 사람 주소를 그대로 유지하면서 작동 중인 마케팅 스트림에 영향을 미칠 수 있습니다.
두 서비스를 모두 중단하지 않고 공유 레코드 문제를 진단합니다.
DNS 확인이 실패한 경우 게시된 소유자, 레코드 유형, 전체 값 및 권한 있는 공급자를 검사하세요. 서명이 누락된 경우 테스트에서 인증된 도메인과 의도한 SendPulse 계정을 사용했는지 확인하세요. 서명 실패의 경우 관찰된 선택기와 키를 비교하고 다른 게이트웨이가 서명된 콘텐츠를 변경했는지 확인하세요.
SPF 통과했지만 DMARC 통과하지 못한 경우 승인을 추가하기 전에 ID를 비교하세요. 전송 전에 SMTP 제출이 거부된 경우 제출 오류를 수신자 인증 결과와 별도로 유지하세요. 자격 증명, 할당량 또는 응용 프로그램 형식 문제는 DNS 검사만으로는 진단할 수 없습니다. 비밀을 지원 번들에 복사하지 않고 정확한 오류를 유지하세요.
사용자 정의 봉투 요구 사항이 충족되지 않은 경우 정확한 계정에 대해 SendPulse에서 지원되는 옵션을 얻으십시오. 검토된 지침에서는 모든 고객이 원하는 Return-Path 도메인을 할당할 수 있음을 명시하지 않습니다. MX 발명하지 마십시오. CNAME 확인되지 않은 특징을 근사화하기 위한 배열입니다.
워크시트 복구 및 가상 테스트 실패
인증된 도메인당 하나의 행 그룹과 이메일 또는 SMTP 경로당 하나의 증거 항목을 사용하여 SendPulse 공유 도메인 워크시트를 완성합니다(여기에 설명된 필드를 사용하여 별도의 검토 레코드 생성). 계획 허용량, 기존 선택기 종속성, DNS 결과, 발신자 구성 및 수신된 메시지 결과를 기록합니다. 알 수 없는 항목을 명시적으로 표시합니다.
허구의 서면 사례 SP-01: From courses@example.org 캠페인에 d=example.org, 가 전달되었지만 강의 신청서가 From lessons@old.example 에 DKIM / SPF 결과를 알 수 없는 상태로 제출했다고 가정합니다. example.org 의 연결 상태는 old.example 의 인증을 설정하지 않습니다. 애플리케이션 소유자는 승인된 발신자를 확인하고, 공유 도메인 인벤토리를 비교하고, 작동 키를 순환하지 않고 수업 경로를 테스트해야 합니다. 계정이나 메시지에 액세스하지 않았으며 수정이나 테스트도 수행되지 않았습니다.
변경하기 전에 영향을 받는 각 스트림을 일시 중지하고 마지막으로 승인된 발신자 구성을 복원하는 방법을 결정하세요. 이를 공유하는 모든 서비스에서 키 교체를 조정합니다. 은퇴 시 인증 기록을 제거하기 전에 모든 종속 애플리케이션과 캠페인을 중지하세요. 계획 변경, 계정 마이그레이션, DNS 호스팅 변경 또는 새로운 애플리케이션 경로 후에 다시 테스트하십시오.
테스트된 범위만 닫습니다.
수락하려면 올바른 도메인 자격, 계정 발급 기록, 유효한 공용 DNS , 연결된 공급자 상태, 의도된 발신자 선택 및 각 자료 경로에 대한 신뢰할 수 있는 수신자 증거가 필요합니다. 검증된 캠페인은 테스트되지 않은 SMTP 통합을 종료하지 않습니다. 라이브 계정, DNS 및 메시지 확인, 독립적인 기술 검토, 시각적 검토 및 SME 승인은 아직 보류 중입니다. 이 초안은 게시되지 않았으며 완료된 배포를 주장하지 않습니다.
실행 준비 상태에서 전달 메시지를 분리합니다.
RFC 9989 섹션 7.4에는 도메인 게시를 위한 유효한 DKIM 필요합니다. p=reject 간접 메일 상호 운용성에 대한 주의 사항입니다. 단일 정렬된 SPF 결과만으로는 거부 정책 출시를 정당화하지 않습니다. 이 공급자 설정과 별도로 모든 합법적인 경로와 정책 소유권을 검토하세요.