다른 Salesforce 이메일 제품과 별도로 계정 참여 유지
Salesforce Account Engagement에는 자체 도메인 관리 작업 과정이 있습니다. 메시지가 핵심 Salesforce 이메일이나 Marketing Cloud Engagement가 아닌 이전에 Pardot이라고 불렸던 Account Engagement를 통해 전송되었는지 확인하는 것부터 시작하세요. 다른 Salesforce 제품에 대한 DNS 레시피는 다른 컨트롤을 사용할 수 있으며 단순히 조직이 동일한 공급업체를 사용한다는 이유로 가져와서는 안 됩니다. 이 가이드에서는 계정 참여 전송 도메인 확인, DKIM 선택적 지원 지원 사용자 정의 반환 경로.
계정에서 사용하는 각 사업부, 브랜드 및 대상 도메인을 나열합니다. 캠페인 및 자동화 설정에서 선택한 실제 발신자를 포함합니다. 사용자의 사서함 주소에 나타나는 도메인은 모든 계정 참여 경로에 대해 자동으로 구성되지 않습니다. 공유 도메인의 기록을 변경하기 전에 마케팅 소유자와 DNS 관리자를 지정하여 함께 인벤토리를 검토하세요.
수락 목표는 정렬된 통과 인증 메커니즘을 사용하여 제어된 수신 메시지입니다. 도메인 소유권 확인, DNS 게시 및 친환경 관리 상태는 유용한 중간 증거입니다. 아무것도 단독으로 특정 캠페인이 의도한 ID를 사용했거나 수신 서버가 해당 인증을 수락했음을 입증하지 못합니다.
루트 DNS 편집하기 전에 기본 SPF 경로를 이해하세요.
Salesforce's 계정 참여 DNS 지침 계정 참여 메일이 통과되었다고 명시되어 있습니다. SPF 제어된 전송 인프라를 통해 이루어지며 해당 기본 설정에 대해 고객 SPF 변경이 필요하지 않습니다. Salesforce 제품 SPF 이 DMARC 보고서. 실제 경로와 평가된 ID를 먼저 확인하세요.
SPF SMTP 인증합니다. 메일 보낸 사람 ID에 대한 별도의 처리 HELO, 아래에 RFC 7208. 그 결과는 다음과 다릅니다. 조정 표시되는 From. 성공적인 공급자 도메인 SPF 검사는 정렬되지 않은 SPF 와 공존할 수 있습니다. 다른 도메인의 정책을 변경해도 메시지가 사용하는 봉투 도메인은 변경되지 않습니다.
조직의 다른 서비스에 필요한 SPF 정책을 유지합니다. 별도로 인증된 사용자 지정 설정에 정책 변경이 필요한 경우 중첩된 DNS 쿼리 용어 및 프로토콜 조회 제한을 포함하여 해당 소유자의 전체 정책 하나를 검토하세요. 두 번째를 만들지 마십시오 SPF 레코드 또는 확인되지 않은 요구 사항을 위한 공간을 확보하기 위해 관련 없는 보낸 사람을 제거합니다.
소유권과 DKIM 별도의 기록으로 확인
도메인 관리를 사용하여 의도한 이메일 전송 도메인과 예상 DNS 항목을 식별합니다. 그만큼 DNS 지침 도메인의 유효성 검사 키를 DomainKey와 구별합니다. 유효성 검사 값은 전송에 대한 소유권을 설정합니다. DKIM 값은 메시지 서명을 지원합니다. 두 가지 목적 중 하나를 다루기보다는 워크시트에서 두 가지 목적을 모두 유지하세요. TXT 레코드 Salesforce 값을 상호 교환 가능한 증거로 포함합니다.
실제 계정에서 값을 복사합니다. DNS 변경하기 전에 전체 레코드 소유자, 유형, 값 및 지시 날짜를 저장하십시오. 다른 Account Engagement 계정이나 다른 서비스가 이미 동일한 소유자에게 종속되어 있는지 확인하세요. 충돌하는 기록을 덮어쓰거나 다른 고객의 값을 재사용하거나 변경하지 마십시오. 선택자 발명 된 이름으로. 계정 계약이 충돌할 경우 지원되는 해결 방법에 대해 지원을 요청하세요.
이메일 전송 도메인을 트래커 도메인과 다르게 유지하세요. Salesforce 두 기능에 동일한 도메인을 사용하지 말라고 명시적으로 경고합니다. 브랜드 추적 호스트 이름은 보낸 도메인과 상위 도메인을 공유하는 경우에도 동일하지 않습니다. 인벤토리는 종속성을 별도로 추적하므로 인증 작업으로 인해 자산 URL이나 캠페인 링크가 실수로 변경되지 않습니다.
문서화된 워크플로를 통해 DomainKey 게시
Salesforce's DKIM 구현 지침 Account Engagement 관리자 역할이 필요합니다. Lightning 앱에서 계정 참여 설정, 도메인 관리를 차례로 엽니다. 대체 Account Engagement 인터페이스에서 문서화된 시작점은 Admin입니다. 이메일 전송 도메인에서 선택한 도메인에 대한 예상 DNS 항목을 열고 TXT 로 게시할 DomainKey 값을 복사합니다.
해당 계정 및 도메인에 대해 표시된 소유자 및 값을 사용하십시오. 현재 기사에는 레코드가 추가된 후 서명이 적용되기까지 최대 24시간이 소요된다고 나와 있습니다. 모든 DNS 캐시나 수신기가 동시에 업데이트된다는 보장이 아니라 공급자 타이밍 지침으로 간주하세요. 새로운 테스트를 판단하기 전에 출판 시간을 기록하고 예상되는 상태를 기다리십시오.
정확한 정규 소유자를 포함하여 공개 DNS 답변을 확인하세요. DNS 편집자는 때때로 호스트 필드에 영역 이름을 추가하여 전체 이름을 입력할 때 중복된 접미사를 생성합니다. 입력 양식을 신뢰하기보다는 결과 답변을 검토하세요. 지원팀이 의역된 상태 대신 실제 실패를 조사할 수 있도록 도메인 관리 오류와 해당 세부 정보를 저장하세요.
사용자 정의 반환 경로가 필요한지 결정
Salesforce's DMARC 지원 기사 정렬된 DKIM 일반 DMARC 경로로 설명하고 기본값이 반환 경로 도메인이 보이는 보낸 사람과 일치하지 않습니다. 또한 지원 지원 사용자 지정 반환 경로 요청도 문서화합니다. 명시된 제한은 모든 메시지에 대해 선택되는 가변 도메인이 아니라 사업부당 하나의 고정된 사용자 지정 반환 경로 도메인입니다.
이 옵션을 요청하기 전에 비즈니스 요구 사항을 확인하세요. SPF 및 DKIM 조정이 필요한 조직은 지원을 통해 실제 도메인 배열 및 조정 모드를 평가해야 합니다. 관련 없는 브랜드로 보내는 사업부는 하나의 고정된 반품 경로가 모든 보낸 사람 도메인과 일치할 수 있다고 가정해서는 안 됩니다. 관찰된 ID와 지원되는 구성으로 문제가 해결될 때까지 해당 설계 질문을 열어두세요.
지원 사례에서 정확한 DNS 레코드를 얻고 DNS 소유자가 충돌 및 종속성을 검토하도록 합니다. 이 문서에서는 범용 사용자 지정 반환 경로 대상이나 활성화 스위치를 제공하지 않습니다. 추측된 기록을 게시하거나 다른 제품의 바운스 도메인 구성을 복사하면 요구 사항을 충족하지 못한 채 작업 경로가 중단될 수 있습니다.
실제 메시지 흐름을 통해 선택된 발신자를 테스트합니다.
실질적으로 서로 다른 각각의 전송 도메인 및 사업부 경로를 통해 무해하게 통제된 메시지를 보냅니다. 계획된 캠페인 또는 자동화와 동일한 발신자 선택을 사용하십시오. 캠페인 참조, 메시지 ID, UTC 시간 및 외부 테스트 수신자를 기록합니다. 미리 보기 또는 테스트 기능이 프로덕션과 다른 경로를 사용하는 경우 대표적인 증거로 처리하기 전에 해당 차이점을 해결하세요.
신뢰할 수 있는 수신 시스템에서 From, Return-Path 및 모든 DKIM 서명 도메인과 선택기를 캡처합니다. RFC 6376 공개 확인 키를 찾는 데 사용되는 d= 및 s= 값을 정의합니다. 관찰된 서명 도메인을 구성된 전송 도메인과 비교합니다. 메시지가 예상치 못한 발신자 또는 다른 경로를 사용하는 동안에도 DNS 레코드는 정확할 수 있습니다.
적용하다 RFC 9989 실제 결과에. DMARC 통과 정렬을 통과할 수 있습니다. DKIM 서명 또는 정렬된 SPF 통과합니다. 결과를 제공한 메커니즘과 적용된 정렬 모드를 기록합니다. SPF 인증, SPF 정렬, DKIM 인증 및 DKIM 정렬을 별도의 필드에 유지하세요. 이렇게 하면 단일 녹색 상태가 테스트되지 않은 요구 사항을 숨기는 것을 방지할 수 있습니다.
모든 컨트롤을 변경하는 대신 실패한 경계 문제를 해결하세요.
전송 도메인이 확인되지 않은 경우 유효성 검사 키와 정확한 DNS 소유자를 예상 DNS 항목과 비교하세요. 예상 활성화 기간 이후 DKIM 누락된 경우 선택한 도메인 및 계정에서를 확인한 다음 도메인 관리 오류를 확인하세요. 서명이 실패하면 선택기와 공개 값을 확인하고 서명 후 메시지를 변경하는 다운스트림 시스템을 검사하십시오.
SPF 통과했지만 DMARC 실패하면 정렬을 조사하고 해당 발신자에 대해 정렬된 DKIM 구성되었는지 여부를 확인하세요. 기본 SPF 성공을 DMARC 성공의 약속으로 여기지 마십시오. 사용자 정의 반환 경로가 포함된 경우 관찰된 봉투 ID를 고정 사업부 설정 및 지원 제공 지침과 비교하십시오. 진단을 위해 대표적인 실패 메시지를 보존합니다.
조직의 DMARC 정책 및 보고 대상을 기존 소유권으로 유지합니다. Salesforce 기사에서는 Account Engagement가 이를 수집하는 대신 외부 DMARC 모니터링이 필요하다고 설명합니다. 실패 보고서. DNS 인증 작업은 보고 대상을 자동으로 대체하거나 관련 없는 발신자에 대한 시행을 낮추어서는 안 됩니다. 메일 및 보안 소유자와 별도로 제안된 정책 변경 사항을 검토하십시오.
계정 참여 도메인 워크시트
- 계정, 사업부, 브랜드 및 전송 워크플로: ____.
- 보낸 사람 주소를 선택하고 이메일 전송 도메인을 구성했습니다: ____.
- 별도의 추적기 도메인 및 기존 종속성: ____.
- 예상 DNS 항목의 유효성 검사 키 및 DKIM 레코드 참조: ____.
- 공개 DNS 답변, 게시 시간 및 관리 상태: ____.
- 기본 또는 지원 지원 사용자 정의 반환 경로 설계: ____.
- 관련되는 경우 사용자 지정 반환 경로 제한 및 지원 확인: ____.
- 테스트 메시지 ID, UTC 시간, 보낸 사람, Return-Path 및 DKIM ID: ____.
- 신뢰할 수 있는 인증 결과 및 조정된 DMARC 메커니즘: ____.
- 예외, 소유자 모니터링 및 복구 승인: ____.
정렬 없이 SPF 성공을 보여주는 가상의 예
허구의 서면 사례에만 해당: AE-01은 North 사업부가 news@example.org 로 전송하고 South 사업부가 news@example.net 으로 전송한다고 가정합니다. bounce.example.org 에서 제안된 고정 사용자 지정 반환 경로는 완화된 SPF 정렬의 첫 번째 정렬과 정렬될 수 있지만 관련되지 않은 두 번째 정렬과 정렬된다고 가정할 수는 없습니다. DKIM 서명과 SPF 결과는 알 수 없는 상태로 남아 있으므로 두 경로 모두 DMARC 결과를 주장하지 않습니다. 마케팅 및 메일 소유자는 루트 SPF 편집을 요청하기 전에 사업부 설정을 분리하고 선택한 보낸 사람 도메인별로 정렬된 DKIM 검증해야 합니다. 모든 정체성과 배열은 만들어집니다. 지원 사례가 없으며 DNS 쿼리 또는 메시지가 실행되었습니다.
완료 상태를 실시간 증거와 연결하여 유지
문서화된 워크플로는 실제 테넌트의 권한, 생성된 값 또는 사용자 지정 반환 경로 기능을 확인하지 않습니다. 이러한 계정 확인, 실시간 DNS 및 헤더 확인, 시각적 검토 및 SME 승인은 아직 보류 중입니다. 이 가이드는 출판되지 않았으며 조직의 캠페인이 프로덕션에서 인증되었다는 증거로 제시되어서는 안 됩니다.
실행 준비 상태에서 전달 메시지를 분리합니다.
RFC 9989 섹션 7.4에서는 p=reject 게시하는 도메인에 대해 유효한 DKIM 필요하며 간접 메일 상호 운용성에 대한 주의가 필요합니다. 단일 정렬된 SPF 결과만으로는 거부 정책 출시를 정당화하지 않습니다. 이 공급자 설정과 별도로 모든 합법적인 경로와 정책 소유권을 검토하세요.