아래에 RFC 9989 §5.4, a DMARC pass는 받은편지함 배치를 보장하지 않습니다. 메시지에 대해 정렬된 도메인 인증 결과를 설정합니다. 수신 서비스는 다른 이유로 메시지를 거부하거나 스팸으로 분류하거나 받은 편지함에 넣거나 나중에 사용자별 처리를 적용할 수 있습니다.
잘못된 진단이 잘못된 변화를 가져오기 때문에 이 경계가 중요합니다. DNS 허술한 동의, 지속적인 불만 또는 원치 않는 콘텐츠를 복구할 수 없습니다. 반대로 평판 작업은 정렬되지 않은 인증 경로를 수정하지 않습니다.
배송 단계를 분리하세요
네 가지 고유한 측정값을 사용합니다.
- 단계: 인증; 질문: 그랬어요 SPF 또는 DKIM 통과하고 적어도 하나의 통과 신원이 From과 일치합니까?
- 단계: 수용; 질문: 수신 서버가 SMTP 중에 메시지를 수락했습니까?
- 단계: 배치; 질문: 수락 후 수신자는 메시지를 어디에 배치하거나 노출했습니까?
- 단계: 참여; 질문: 수신자는 무엇을 했으며, 그 측정값은 얼마나 신뢰할 수 있나요?
데이터 끝 후 긍정적인 SMTP 완료가 지정되었습니다. RFC 5321 §4.2.5. 메시지는 인증을 통과하고 수락에 실패할 수 있습니다. 수락되어 스팸메일로 분류될 수 있습니다. 받은 편지함에 도달할 수 있으며 유용한 참여를 받을 수 없습니다. 네 가지 결과를 모두 전달 가능성으로 설명하지 마십시오.
가상의 진단표 읽기
다음의 경우는 합성입니다. 그들은 관찰된 성과를 주장하지 않고 다음 조사를 선택하는 방법을 보여줍니다.
- 관찰: DMARC ; 사례 A: 통과; 사례 B: 통과; 사례 C: 실패
- 관찰: SMTP ; 사례 A: 승인됨; 사례 B: 승인됨; 사례 C: 인증 관련 응답으로 거부됨
- 관찰: 배치; 사례 A: 스팸; 사례 B: 받은 편지함; 사례 C: 전달된 사본이 없습니다.
- 관찰: 불만사항 또는 수신자 신호; 사례 A: 불만이 높아졌습니다. 사례 B: 정의된 집단에 대한 정상; 사례 C: 거부된 메시지에는 적용되지 않음
- 관찰: 다음 초점; 사례 A: 동의, 기대, 평판, 콘텐츠 및 전송 패턴 사례 B: 비교 가능한 트래픽을 계속 모니터링합니다. 사례 C: ID 체인, 서명, SPF 경로 및 공급자 응답
사례 A의 경우 DMARC 없음에서 거부로 변경해도 인증된 메시지가 원하지 않는 이유가 해결되지 않습니다. 목록 출처, 억제, 빈도, 콘텐츠 및 공급자 피드백을 조사합니다. Case C의 경우 인증 관련 거부를 이해할 때까지 받은 편지함 테스트를 시작할 수 없습니다.
인증을 평판 지름길이 아닌 전제 조건으로 사용
사서함 공급자는 다음과 같은 보낸 사람에 대한 요구 사항 및 권장 사항을 게시합니다. 개인 Gmail 수신자를 위한 Google 가이드라인. 이러한 요구 사항에는 SPF , DKIM , DMARC , 유효한 DNS , 전송 관행, 불만 사항 제어 및 해당 트래픽에 대한 간편한 구독 취소가 포함될 수 있습니다. 한 가지 요구 사항을 충족한다고 해서 다른 요구 사항이 포기되는 것은 아닙니다.
인증은 안정적인 도메인 ID를 생성하고 수신자가 메일 속성을 지정하는 데 도움이 되기 때문에 중요합니다. 이는 명성을 사거나 수령인의 동의를 입증하거나 유리한 대우를 보장하지 않습니다. 평판 및 분류 결정은 수신자별로 결정되며 트래픽 스트림, 수신자 및 시간에 따라 달라질 수 있습니다.
DNS 변경과 배치 변경이 동시에 발생하여 원인을 추론하지 마세요. 전송 프로그램은 볼륨, 청중, 콘텐츠 및 인프라를 동시에 변경할 수 있습니다. 결론을 내리기 전에 개입을 기록하고 유사한 집단을 비교하십시오.
해당 수신자의 증거로 진단
지정된 경계 내에서 실제 SMTP 응답과 신뢰할 수 있는 인증 결과로 시작합니다. RFC 8601 §7.1. 메시지가 거부된 경우 코드와 그에 수반되는 텍스트로 카테고리를 식별할 수 있지만 코드만으로는 완전한 진단이 될 수 없습니다. 이를 해석하려면 공급자 문서와 전송 로그가 필요합니다.
메시지가 수락된 경우 사용 가능한 공급자 원격 측정, 명시된 제한 사항이 있는 시드 테스트, 수신자 보고서 및 통제된 캠페인 데이터를 사용합니다. 테스트 사서함은 모든 수신자에 대한 보편적인 예측이 아니라 해당 사서함과 메시지에 대한 증거입니다.
인증을 위해 보낸 사람, 평가된 SPF ID, 모든 DKIM d= 도메인, 조정 그리고 해당 정책. 프로그램 상태를 위해 트래픽 스트림, 볼륨, 불만 사항 정보, 억제 동작, 목록 출처, 콘텐츠 변경 및 타이밍을 기록합니다.
참여 지표를 신중하게 다루십시오.
공개율은 받은 편지함 배치 또는 사람의 관심을 위한 신뢰할 수 있는 독립형 프록시가 아닙니다. Apple의 메일 개인 정보 보호 참여 여부에 관계없이 백그라운드에서 원격 콘텐츠를 다운로드합니다. Mailchimp 의 공개 추적 지침 또한 차단된 추적 이미지와 클라이언트 형식 제한 사항도 문서화합니다. 클릭에는 다음에 설명된 대로 자동화된 보안 검색이 포함될 수도 있습니다. Mailchimp 의 봇 활동 지침.
모집단과 측정 방법을 정의합니다. 배송 응답, 불만 사항, 구독 취소 행동, 제공업체 증거 및 비즈니스 결과를 결합합니다. 비교할 수 있는 기준과 혼란스러운 변화에 대한 설명 없이 하나의 측정항목으로 개선을 주장하지 마세요.
잘못된 문제를 대상으로 하는 DNS 변경 방지
인증된 캠페인이 스팸으로 분류되므로 다른 SPF 포함을 추가하지 마세요. 배치를 추적하기 위해 정렬을 약화시키지 마십시오. 중복 게시하지 마세요. SPF 레코드. 테스트 메시지가 받은 편지함에 도달했다는 이유만으로 거부로 이동하지 마세요.
DNS 변경은 입증된 신원 또는 정책 문제를 해결해야 합니다. 전송 관행 변경은 동의, 빈도, 콘텐츠, 세분화 또는 평판 문제를 해결해야 합니다. 두 작업 흐름이 모두 필요한 경우도 있지만 별도의 소유자와 증거를 유지해야 합니다.
공동 진단 기록 구축
유용한 사례 기록에는 다음이 포함됩니다.
- 정확한 발신자, 도메인 및 트래픽 스트림에서;
- 대표 메시지와 신뢰할 수 있는 인증 결과
- SMTP 응답 및 타임스탬프
- 방법과 제한사항을 고려한 배치 관찰;
- 해당 코호트에 대해 이용 가능한 불만 사항, 억압 및 수신자 증거;
- 최근의 기술 및 프로그램 변경 사항;
- 가설, 소유자, 개입 및 검토 날짜.
이 형식은 " DMARC 전달 가능성을 수정했습니까?"라는 질문을 던집니다. 테스트 가능한 질문으로. 인증이 좋아졌나요? 수용이 바뀌었나요? 비교 가능한 메일의 배치가 변경되었습니까? 청중의 변화 없이 수신자 반응이 개선되었습니까?
신원 증명을 위해 다음을 사용하십시오. 이메일 ID 체인 가이드. 모니터링 기준의 경우 다음을 계속 진행하세요. DMARC 모니터링 정책 가이드.
증거 내에서 결론을 유지하라
사례 A의 경우 인증되었지만 스팸인 관찰을 유지하고 명시된 불만 증거를 조사합니다. 사례 C의 경우 받은편지함 배치를 조사하기 전에 실제 거부를 유지하세요. 변화에 따라 동일한 측정 방법과 코호트를 비교합니다. 자동 열기 또는 클릭은 인간 행동의 증거가 아닙니다. 이러한 사례는 허구이며 캠페인 측정이나 개선 약속이 아닙니다.