발신자 이름은 가장 쉽게 위장될 수 있습니다
이메일에 표시된 발신자 이름은 브랜드, 상사 또는 동료로 포장될 수 있으며, 실제로 중요한 단서는 이메일 헤더에 있습니다. 헤더를 한 번에 모든 기술 세부 사항을 이해할 필요는 없습니다; 그것의 목적은 발신 경로를 찾고, 검증 결과와 이메일의 요구 사항 간의 모순을 확인하는 것입니다.
From, Reply-To 및 Return-Path 먼저 확인하기
From은 이메일에 표시된 발신인이고, Reply-To는 회신했을 때 이메일이 전송될 위치이며, Return-Path는 주로 반송 이메일에 사용됩니다. 사기 이메일은 From을 브랜드나 상사로 위장할 수 있지만, 회신 주소는 낯선 도메인일 수 있습니다; 이 세 가지 항목이 서로 비합리적이라면 경계를 높여야 합니다.
Received 경로를 통해 이메일의 경로 확인하기
Received 필드는 이메일이 지나간 서버의 단서를 남깁니다. 일반인이 이것을 한 줄씩 추적하기에는 적합하지 않을 수 있지만, 이메일이 예상한 이메일 서비스, 회사의 게이트웨이 또는 마케팅 플랫폼을 통과했는지 판단하는 데 도움이 됩니다.
검증 결과는 디자인보다 더 신뢰할 수 있습니다
SPF, DKIM, DMARC는 일반적인 발신 인증 단서입니다. 검증에 통과했다고 해서 내용이 안전하다는 것은 아니지만, 실패하거나 도메인과 일치하지 않는 경우에는 경계를 높여야 합니다. 브랜드, 은행, 플랫폼 알림 또는 내부 상사의 이메일에 대해 검증 결과와 도메인 일관성이 이메일의 레이아웃보다 더 신뢰할 수 있습니다.
낯선 IP는 단독으로 사기 증거로 삼을 수 없습니다
이메일은 클라우드 이메일 서비스, 마케팅 플랫폼, 고객 서비스 시스템 또는 회사의 게이트웨이를 통해 이동할 수 있으므로 낯선 IP를 보았다고 해서 반드시 사기가 되는 것은 아닙니다. 판단할 때는 발신 도메인, 검증 결과, 회신 주소, 링크 URL 및 요구 사항 내용이 서로 일관되는지 확인해야 합니다.
결제, 인증 코드 또는 비밀번호 변경 요청이 있을 때
우선 이메일 안의 링크를 클릭하지 마십시오. 원본 이메일을 열거나 헤더를 확인하여 발신 도메인과 회신 주소를 확인한 후, SPF, DKIM, DMARC 결과를 보고 마지막으로 이메일 안의 링크가 공식 메인 도메인으로 유도되는지를 확인하십시오. 이메일이 결제, 인증 코드 제공 또는 비밀번호 변경을 요구한다면 공식 웹사이트 또는 내부 시스템에 돌아가 확인해야 합니다.
이메일 헤더는 모든 것을 증명할 수는 없지만, 많은 겉모습을 드러낼 수 있습니다. 실제 목적은 이메일 감식 전문가가 되는 것이 아니라 출처 확인, 검증 결과 및 이메일 요구 사항이 일치하는지를 확인하는 것입니다.