[ DMARC 및 정책 ]

DMARC 격리 대 거부: 영향을 받을 수 있는 메일 평가

요청된 DMARC 실패 처리를 합법적인 경로 증거, 수신자 재량 및 잘못된 결정의 영향과 비교합니다.

EmailAuth 연구팀 제공 · 5분 읽기

[ 핵심사항 ]

  • 요청된 정책과 실제 처리는 별개의 사실입니다.
  • 정책을 변경하기 전에 소량의 심각한 오류를 조사하세요.
  • 경로 수준 증거, 예외 및 복구 조건을 유지합니다.
이 페이지에서

격리 및 거부는 실패한 메일에 대한 다양한 도메인 소유자 평가를 전달합니다. DMARC. 둘 중 하나를 선택하려면 도메인의 합법적인 메시지와 해당 메시지가 잘못 처리될 경우의 결과에 대한 증거가 필요합니다.

결정을 통제된 변경으로 간주합니다. 실패할 수 있는 흐름, 실패 이유, 수신 시스템이 실제로 수행하는 작업을 식별합니다. 더 제한적으로 보이는 기록은 해당 조사를 대체할 수 없습니다.

처리와 평가를 별도로 유지

아래에 RFC 9989 §5.3.5, DMARC 합격 여부를 평가합니다. SPF 또는 DKIM ID는 표시되는 보낸 사람 도메인과 일치합니다. 정책은 검증이 실패할 경우 도메인 소유자의 평가를 나타냅니다.

아래에 RFC 9989 §4.7, 격리에서는 사용 실패를 의심스러운 것으로 분류합니다. 거부(Reject)는 실패한 사용이 유효하지 않다는 평가를 표현합니다. 아래에 RFC 9989 §5.4, 수신자는 자신의 처분 결정에 대한 책임을 지며 다른 정보를 사용할 수 있습니다.

결과적으로 격리는 하나의 보편적인 스팸 폴더 결과를 약속하지 않으며 거부는 모든 참여 수신자가 모든 실패를 거부했음을 증명하지 않습니다. 수사 중인 사건에 대한 실제 접수된 증거를 확인합니다.

정당한 실패를 먼저 조사하라

승인된 애플리케이션의 경우 표시되는 보낸 사람 도메인을 SPF ID 및 모든 관련 DKIM 서명 도메인과 비교하세요. 지원되는 구성을 설정하고 동일한 경로를 통해 새 메시지를 테스트합니다.

정책 변경으로 인해 오류가 발생했다는 이유만으로 광범위한 전송 권한을 추가하지 마십시오. 먼저 회사에서 실제로 승인한 계정, 작업 흐름 및 ID를 확인하세요.

전달 및 메일링 목록은 유지되는 인증 경로에 영향을 미칠 수 있습니다. 간접적인 오류에는 소스 도메인의 다른 포함보다는 메시지 변경 사항 및 수신 동작에 대한 분석이 필요할 수 있습니다. SPF 레코드.

도메인 목적을 사용하여 장단점 평가

전용 트랜잭션 ID는 직원 서신 도메인보다 더 작고 더 통제된 전송 인구를 가질 수 있습니다. 그에 따라 각각을 검토하세요.

RFC 9989 §7.4 범용 이메일 도메인에 대한 거부에 대한 주의 사항과 사용자가 인터넷 메일링 목록에 게시하는 도메인에 대해 논의합니다. 이는 해당 상황에 대한 관찰 및 비교 지침과 사용자 참여에 대한 의미를 제시합니다.

거부를 위한 자동 이동 시 격리를 필수 대기실로 처리하는 대신 관련 지침을 적용합니다. 그만큼 정책 선택 가이드 더 폭넓은 의사결정 기록을 제시합니다.

글로벌 비율이 아닌 구체적인 실패를 검토하세요.

직원 메시지는 통과했지만 월별 송장 시스템이 실패하는 종합적인 예를 생각해 보세요. 조정. 송장 흐름은 전체 요율에 거의 영향을 미치지 않을 만큼 작습니다.

더 강력한 요청 정책은 수신자가 해당 오류에 대해 조치를 취하는 경우 여전히 상당한 비즈니스 영향을 미칠 수 있습니다. 송장 서비스를 식별하고, 지원되는 ID를 수정하고, 실제 워크플로를 테스트합니다.

알 수 없는 실패한 트래픽에는 다른 조사가 필요합니다. 그것이 합법적인 우편물인지, 간접 경로인지, 무단 사용인지 또는 다른 원인인지 여부가 증거로 입증될 때까지 불확실성을 유지하십시오. 알려지지 않은 모든 행을 예방된 공격으로 간주하지 마세요.

변경 및 승인 증거 계획

현재 정책을 저장하고 제안된 범위를 정의합니다. 테스트된 서비스, 에스컬레이션 또는 복원이 필요한 나머지 예외 및 조건을 기록합니다.

변경이 승인된 후 신뢰할 수 있는 기록과 담당자가 받은 메시지를 확인합니다. 보고 간격 및 정책 컨텍스트를 통해 보고 관찰 내용을 조사합니다. 정책 변경 보고는 다음에서 다룹니다. RFC 9990 §3.3. 현재 DNS 수신자가 이전에 본 정책을 재구성하지 않습니다.

인증, 처리 및 비즈니스 영향에 대해 별도의 증거를 사용합니다. 아래에 RFC 9990 §3.1.6, 보고서 처리 및 재정의 이유는 유용한 컨텍스트이지만 최종 받은 편지함 배치나 결제 또는 알림 워크플로의 결과를 증명하는 것은 아닙니다.

결정 후 운영 프로세스 유지

새로운 애플리케이션, 변경된 경로 및 오래된 권한을 계속 모니터링하세요. 조직이 도메인 사용 방법을 변경하면 유효한 정책 결정이 부적절해질 수 있습니다.

의미 있는 결과는 검증된 적법한 흐름, 이해된 한계 및 복구 프로세스를 통해 지원되는 문서화된 선택입니다. 메시지 수준 진단의 경우 다음을 사용하십시오. 정렬 가이드; 증거 해석을 위해 DMARC 집계 보고서.

결정과 그 한계를 기록하십시오.

단지 계획의 예로 9,900개의 직원 메시지가 통과하고 100개의 송장 메시지가 실패했다고 가정해 보겠습니다. 전체 합격률은 99%인데 송장 경로는 실패율이 100%입니다. 이러한 발명된 숫자는 중요한 경로를 수리해야 하는 이유를 보여줍니다. 이는 캠페인 측정이나 약속된 정책 결과가 아닙니다.

[ 테이크아웃 ]

요청된 정책과 실제 처리는 별개의 사실입니다. 정책을 변경하기 전에 소량의 심각한 오류를 조사하세요. 경로 수준 증거, 예외 및 복구 조건을 유지합니다.

[ 역할별 ]

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

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

IT/메일 관리자

전후 증거를 보관하십시오.

여러 컨트롤을 한 번에 변경하는 대신 정렬, 정책 검색 및 실제 수신자 결과를 통해 영향을 받은 발신자를 추적하세요.

다음 단계

  1. 합법적인 신원 격차를 해결하세요.
  2. 효과적인 정책과 보고 기간을 기록합니다.
  3. 수정 후 원래 사업경로를 확인하세요.

CISO/SecOps

적합성과 잔여 위험을 승인합니다.

정책 가치만으로도 보편적인 시행이나 안전이 확립된다는 영역별 정당성과 이의 제기 주장이 필요합니다.

다음 단계

  1. 범용 및 메일링 리스트 사용을 검토합니다.
  2. 예외 및 복구 소유권을 확인하십시오.
  3. 독립적인 계정 및 거래 통제를 유지하십시오.

창립자 / 비기술자

합법적인 메시지가 잘못 처리되면 어떻게 되는지 물어보세요.

잘못된 결정으로 인한 비용은 단순히 메시지 양이 아니라 영향을 받는 워크플로에 따라 달라집니다.

다음 단계

  1. 고객 접근 및 금융 커뮤니케이션을 우선시합니다.
  2. 주기적인 흐름이 테스트되었는지 물어보십시오.
  3. 변경하기 전에 에스컬레이션 소유자에게 동의하세요.

[ 자주 묻는 질문 ]

자주 묻는 질문

검역소에서는 실패한 모든 메시지가 스팸으로 분류되는 것을 보장합니까?

아니요. 실패한 메일에 대한 소유자의 평가를 전달하는 반면, 수신 시스템은 자체 처리 및 필터링 결정을 적용합니다.

RFC 9989 §4.7 RFC 9989 §5.4

거부하면 피싱으로부터 완전한 보호가 보장되나요?

아니요. 수신자의 행동은 다양하며 도메인 인증은 유사하거나 손상된 계정, 사기성 표시 이름 또는 안전하지 않은 비즈니스 요청을 모두 처리하지는 않습니다.

RFC 9989 §5.4

수정 정렬을 거부하도록 격리를 변경합니까?

아니요. 지원되는 발신 ID를 복구하고 새 메시지에서 전달 정렬 경로를 확인하세요. 정책과 인증은 별도의 레이어입니다.

RFC 9989 §5.3.5

모니터링되는 모든 도메인은 거부를 위해 격리를 거쳐야 합니까?

보편적인 진행은 적절하지 않습니다. 도메인 목적, 합법적인 흐름 및 현재 상호 운용성 지침에 따라 평가가 결정됩니다.

RFC 9989 §7.4

합격률이 높을 때 작은 실패 서비스가 중요한 이유는 무엇입니까?

볼륨이 중요함을 숨길 수 있습니다. 적은 양의 송장이나 액세스 복구 흐름은 건강한 직원 메일이 분모를 지배하는 경우에도 중요할 수 있습니다.

정책 변경을 승인하기 전에 무엇이 필요합니까?

정의된 범위, 중요 경로 테스트, 간접 메일 평가, 소유 예외, 보고 제한, 승인자 및 복구 조건이 필요합니다.

보고서가 최종 받은 편지함 결과를 증명할 수 있습니까?

처리 필드만으로는 그렇지 않습니다. 인증, 정렬된 평가 및 처리 컨텍스트를 별도로 읽고 필요한 경우 수신자 또는 서비스 증거를 얻습니다.

RFC 9990 §3.1.6 RFC 9989 §5.4

정책 결정 이후에는 무엇을 계속해야 합니까?

보고, 발신자 소유권, 신규 또는 변경된 서비스 검토를 유지합니다. 도메인의 합법적인 사용 또는 관련 수신자 행동이 변경되면 재평가하세요.

[ 출처 ]

출처

  1. RFC 9989

    섹션 §4.7 · §5.3.5 · §5.4 · §7.4

  2. RFC 9990

    섹션 §3.1.6 · §3.3

[ 어휘 ]

어휘

처분
보고된 처리 및 무시되는 설명은 인증 결과 및 업무 결과와 구별되어야 합니다.

RFC 9990 §3.1.6

중요 경로
메시지 양이 적더라도 실패가 비즈니스에 중요한 워크플로입니다.

기업 출처

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

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

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

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

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

기술 자료