피싱 메일 확인하는 법, 이메일 헤더로 발신자 확인하기

이메일에 표시되는 발신자 이름과 주소는 비교적 쉽게 위조할 수 있습니다. 예를 들어 받은편지함에는 은행이나 쇼핑몰 이름이 표시되지만 실제로는 전혀 다른 서버에서 발송된 피싱 메일일 수 있습니다.

이럴 때는 본문에 표시된 발신자만 보지 말고 이메일 전체 헤더를 확인해야 합니다. 전체 헤더에는 이메일이 거쳐 온 서버, 실제 발송에 사용된 도메인, SPF·DKIM·DMARC 인증 결과, Return-Path 등의 정보가 기록됩니다.

다만 인증 결과가 모두 pass라고 해서 무조건 안전한 메일은 아닙니다. 공격자가 정상적으로 인증된 자신의 도메인을 사용하거나 정상 계정을 탈취해 메일을 보낼 수도 있기 때문입니다.

1. 이메일 전체 헤더란 무엇인가?

이메일 전체 헤더는 메일이 발송되고 수신되는 과정에서 만들어진 기술 기록입니다. 우리가 평소에 보는 보낸 사람, 받는 사람, 제목 외에도 다음 정보가 포함됩니다.

• 이메일이 거쳐 온 서버
• 실제 발신 서버의 IP 주소
• 발송에 사용된 도메인
• SPF 인증 결과
• DKIM 전자서명 결과
• DMARC 검사 결과
• Return-Path 주소
• 발송 및 수신 시간
• Message-ID
• 메일 전송 프로그램 정보

피싱 메일을 확인할 때는 특정 항목 하나만 보는 것이 아니라 보이는 From 주소, Return-Path, SPF, DKIM, DMARC, Received 기록을 서로 비교해야 합니다.

2. Gmail과 Outlook에서 전체 헤더 확인하기

Gmail에서 확인하는 방법

컴퓨터의 웹브라우저에서 Gmail을 열고 검사할 이메일을 선택합니다.

1. 이메일 오른쪽 위의 점 3개 더보기를 누릅니다.
2. 원본 보기를 선택합니다.
3. 새 화면에서 전체 헤더와 인증 결과를 확인합니다.
4. 필요하면 클립보드에 복사를 선택합니다.

Gmail은 원본 보기 화면에서 SPF·DKIM·DMARC 결과를 비교적 쉽게 보여줍니다. Google의 공식 안내에도 웹 Gmail에서 메일을 열고 더보기 메뉴의 ‘원본 보기’를 선택하도록 설명돼 있습니다. Google Gmail 고객센터

Outlook 데스크톱에서 확인하는 방법

Outlook의 버전과 화면 구성에 따라 메뉴 이름이 다를 수 있지만, 클래식 Outlook에서는 일반적으로 다음 경로를 이용합니다.

이메일 열기 → 파일 → 속성 → 인터넷 머리글

새 Outlook이나 웹용 Outlook에서는 이메일의 기타 작업 또는 점 3개 메뉴에서 메시지 원본이나 메시지 세부 정보에 해당하는 메뉴를 찾습니다.

전체 헤더를 복사할 때는 발신자와 수신자의 이메일 주소, 내부 서버 이름, IP 주소 등이 포함될 수 있으므로 공개 게시판에 그대로 올리지 않는 것이 좋습니다.

3. Authentication-Results에서 인증 결과 확인하기

전체 헤더를 열었다면 먼저 다음 항목을 찾습니다.

Authentication-Results:

이 항목에는 수신 메일 서버가 검사한 SPF·DKIM·DMARC 결과가 함께 기록될 수 있습니다.

예시는 다음과 같습니다.

Authentication-Results: mx.example.com; spf=pass smtp.mailfrom=notice.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com

주요 결과의 의미는 다음과 같습니다.

• pass: 인증을 통과했습니다.
• fail: 인증에 실패했습니다.
• softfail: 발신 도메인이 허용하지 않을 가능성이 있지만 강한 거부 정책은 아닙니다.
• neutral: 도메인 정책만으로 허용 여부를 판단하기 어렵습니다.
• none: 확인할 인증 정보나 정책이 없습니다.
• temperror: DNS 또는 서버의 일시적인 오류가 발생했습니다.
• permerror: 인증 정책이나 DNS 설정에 지속적인 오류가 있습니다.

주의할 점은 헤더 안의 모든 Authentication-Results를 그대로 믿으면 안 된다는 것입니다. 공격자가 가짜 결과를 헤더에 미리 넣을 수도 있습니다. 일반 사용자는 수신한 메일 서비스가 가장 최근에 추가한 인증 결과를 우선 확인해야 합니다.

4. SPF로 발신 서버의 허용 여부 확인하기

SPF(Sender Policy Framework)는 해당 IP 주소가 특정 도메인을 대신해 이메일을 보낼 수 있도록 허용된 서버인지 확인하는 기술입니다.

헤더에서는 다음과 같은 형태로 나타날 수 있습니다.

spf=pass smtp.mailfrom=mailer.example.com

또는 다음 항목에서 확인할 수도 있습니다.

Received-SPF: pass

SPF 결과가 pass라면 메일을 보낸 서버의 IP 주소가 smtp.mailfrom 또는 Return-Path에 사용된 도메인의 SPF 정책에서 허용됐다는 의미입니다. SPF 결과는 Authentication-Results나 Received-SPF에 기록될 수 있습니다. SPF 표준 RFC 7208

그러나 SPF에는 중요한 한계가 있습니다. SPF는 사용자가 화면에서 보는 From 주소 자체를 직접 인증하는 것이 아니라, 주로 메일 전송 과정의 MAIL FROM 도메인을 검사합니다.

따라서 다음과 같이 서로 다른 도메인이 나타날 수 있습니다.

From: 고객센터 <notice@famous-bank.example>Return-Path: <bounce@unknown-mail.example>Authentication-Results: spf=pass smtp.mailfrom=unknown-mail.example

이 경우 SPF는 통과했지만 유명 은행 도메인이 아니라 unknown-mail.example의 발송 권한을 확인한 것일 수 있습니다. 즉, spf=pass만으로 화면에 표시된 발신자가 진짜라고 단정할 수 없습니다.

5. DKIM 서명 도메인 확인하기

DKIM(DomainKeys Identified Mail)은 발신 측 서버가 이메일에 전자서명을 추가하고 수신 서버가 DNS에 공개된 키로 서명을 검증하는 방식입니다.

헤더에서 다음 항목을 찾습니다.

DKIM-Signature:

그 안에서 특히 중요한 부분은 d=입니다.

DKIM-Signature: v=1; d=example.com; s=mail2026;

• d=: 메일에 서명한 도메인
• s=: 공개키를 찾는 데 사용하는 선택자
• b=: 디지털 서명값
• bh=: 본문 해시값

인증 결과는 다음과 같이 표시될 수 있습니다.

dkim=pass header.d=example.com

dkim=pass는 서명이 정상적으로 검증됐으며 서명 이후 인증 대상 내용이 변조되지 않았음을 의미합니다. DKIM은 d=에 지정된 도메인이 메시지에 일정한 책임을 주장하고 이를 암호학적 서명으로 검증하는 방식입니다. DKIM 표준 RFC 6376

하지만 DKIM을 통과했다고 해서 From에 표시된 회사가 진짜라는 의미는 아닙니다. 서명 도메인이 화면에 표시된 발신 도메인과 전혀 다를 수 있기 때문입니다.

다음 세 항목을 비교해야 합니다.

From: support@example.comDKIM-Signature: d=example.comAuthentication-Results: dkim=pass header.d=example.com

From 도메인과 header.d 도메인이 같거나 정상적인 관계에 있다면 신뢰도가 높아집니다. 반대로 유명 기업을 사칭했는데 전혀 다른 도메인이 서명했다면 피싱 가능성을 의심해야 합니다.

6. DMARC로 From 도메인의 정렬 확인하기

DMARC는 사용자가 실제로 보는 From 도메인이 SPF 또는 DKIM에서 인증된 도메인과 정렬돼 있는지를 검사합니다.

헤더에서는 다음과 같이 표시될 수 있습니다.

dmarc=pass header.from=example.com

DMARC를 통과하려면 일반적으로 다음 중 하나가 충족돼야 합니다.

• SPF가 통과하고 MAIL FROM 도메인이 보이는 From 도메인과 정렬됨
• DKIM이 통과하고 d= 서명 도메인이 보이는 From 도메인과 정렬됨

따라서 피싱 여부를 판단할 때는 SPF나 DKIM 하나보다 DMARC 결과가 더 직접적인 참고 자료가 될 수 있습니다. DMARC는 화면에 표시되는 작성자 도메인과 인증된 SPF 또는 DKIM 도메인 사이의 정렬을 평가합니다. DMARC 표준 RFC 9989

다만 dmarc=pass도 메일 내용의 안전성까지 보장하지는 않습니다. 공격자가 자신이 소유한 도메인에 SPF·DKIM·DMARC를 정상 설정한 다음 피싱 메일을 보내면 모두 통과할 수 있습니다.

따라서 다음 사항도 반드시 확인해야 합니다.

• From 도메인이 공식 회사 도메인과 정확히 일치하는지
• 철자를 살짝 바꾼 유사 도메인이 아닌지
• 회신 주소가 다른 도메인으로 설정됐는지
• 본문의 링크가 실제 공식 사이트로 연결되는지
• 예상하지 못한 결제나 개인정보 입력을 요구하는지

7. Return-Path와 From 주소 비교하기

From은 사용자의 받은편지함에 표시되는 발신 주소입니다. 반면 Return-Path는 전송 실패나 반송 메일을 받을 목적으로 사용하는 봉투 발신자 주소입니다.

예시는 다음과 같습니다.

From: 쇼핑몰 고객센터 <service@shop.example>Return-Path: <bounce@mailer.shop.example>

정상적인 대량 발송 서비스에서는 From과 Return-Path의 세부 주소나 하위 도메인이 다를 수 있습니다. 따라서 두 주소가 다르다는 이유만으로 피싱이라고 단정하면 안 됩니다.

그러나 다음과 같은 경우에는 주의해야 합니다.

From: 보안센터 <security@bank.example>Return-Path: <sender@unrelated-example.net>

은행을 사칭했는데 Return-Path가 전혀 관련 없는 도메인이라면 의심할 필요가 있습니다. 이때는 다음 항목을 함께 비교해야 합니다.

• From
• Return-Path
• Reply-To
• smtp.mailfrom
• header.d
• header.from

특히 Reply-To가 From과 전혀 다른 주소라면 답장을 공격자가 관리하는 주소로 유도하려는 것일 수 있습니다.

8. Received에서 실제 발신 경로 확인하기

Received 항목은 이메일이 서버를 통과할 때마다 추가되는 이동 기록입니다. 일반적으로 새로운 기록이 위쪽에 추가되기 때문에 이메일의 이동 경로를 읽을 때는 아래쪽에서 위쪽 방향으로 확인합니다.

예시는 다음과 같습니다.

Received: from mail.example.com (mail.example.com [192.0.2.10]) by mx.receiver.example with ESMTPS;

여기에서 확인할 수 있는 정보는 다음과 같습니다.

• from: 메일을 전달한 서버 이름
• 대괄호 안의 주소: 연결에 사용된 IP 주소
• by: 이메일을 받은 다음 서버
• 날짜와 시간: 해당 서버를 통과한 시각
• ESMTP 또는 ESMTPS: 전송 방식

가장 아래쪽에 있는 Received 기록이 최초 발송 경로에 가까울 수 있지만, 무조건 실제 발신 서버라고 단정해서는 안 됩니다. 공격자가 자신이 만든 헤더에 가짜 Received 항목을 추가할 수 있기 때문입니다.

따라서 수신 메일 서비스가 신뢰할 수 있게 기록한 다음 정보가 더 중요합니다.

• Authentication-Results의 인증 서버
• Received-SPF의 client-ip
• 수신 서버가 직접 기록한 Received 항목
• 발신 서버의 호스트명과 IP 주소
• SPF에서 허용된 발신 IP인지 여부

헤더는 아래에서 위로 읽되, 사용자의 메일 서비스가 직접 추가한 신뢰 가능한 구간과 발신자가 임의로 작성할 수 있는 구간을 구분해야 합니다.

9. 실제 발신 서버가 정상인지 판단하기

헤더에서 발신 IP나 서버 이름을 찾았다면 공식 발송 인프라와 관련이 있는지 확인합니다.

예를 들어 정상적인 메일이라면 다음과 같은 특징이 나타날 수 있습니다.

• 회사의 공식 도메인 또는 하위 도메인을 사용함
• 공인된 대량메일 서비스의 서버를 사용함
• SPF 검사에서 해당 IP가 허용됨
• DKIM 서명이 정상적으로 검증됨
• DMARC 정렬이 통과함
• Received 시간 순서가 자연스러움

반대로 다음과 같은 경우에는 의심할 수 있습니다.

• 발신 서버 이름과 From 도메인이 전혀 관련 없음
• SPF·DKIM·DMARC가 모두 실패함
• Reply-To가 다른 국가나 생소한 도메인을 사용함
• Message-ID의 도메인이 발신 조직과 무관함
• 날짜와 서버 이동 순서가 비정상적임
• 유사 문자로 만든 도메인을 사용함
• 공식 기업을 사칭하면서 개인 무료메일 주소를 사용함

다만 기업은 외부 이메일 발송 서비스를 사용할 수 있으므로 서버 도메인이 다르다는 이유만으로 사기라고 확정해서는 안 됩니다. 해당 기업의 공식 홈페이지나 고객센터를 통해 발송 사실을 별도로 확인하는 것이 가장 안전합니다.

10. SPF·DKIM·DMARC 결과를 종합해서 판단하기

다음 표는 인증 결과를 이해하는 데 참고할 수 있습니다.

인증 결과	의미	판단
SPF·DKIM·DMARC 모두 통과	도메인 인증과 정렬이 정상적일 가능성	내용과 링크도 추가 확인
SPF만 통과	MAIL FROM 발송 서버는 허용됨	보이는 From과의 관계 확인
DKIM만 통과	특정 서명 도메인의 서명은 정상	header.d와 From 비교
DMARC 통과	SPF 또는 DKIM이 From 도메인과 정렬됨	도메인 철자와 내용 확인
SPF·DKIM 실패	서버 권한 또는 서명에 문제	피싱 가능성 주의
DMARC 실패	From과 인증 도메인이 정렬되지 않음	사칭 가능성 주의
결과 없음	인증 정책이 없거나 검사가 수행되지 않음	다른 요소로 신중히 판단

정상적인 메일도 전달 서비스나 메일링 리스트를 거치면서 인증에 실패할 수 있습니다. 반대로 피싱 메일도 공격자가 관리하는 도메인을 사용하면 인증을 모두 통과할 수 있습니다.

따라서 인증 결과는 신원 확인을 돕는 기술적 단서이지 안전 보증서가 아닙니다.

11. 헤더가 정상이어도 확인해야 할 피싱 징후

전체 헤더에서 특별한 문제가 발견되지 않더라도 다음과 같은 내용이 있으면 주의해야 합니다.

• 계정이 곧 정지된다고 불안감을 조성함
• 즉시 결제하거나 송금하라고 재촉함
• 비밀번호나 인증번호 입력을 요구함
• 첨부파일의 매크로나 실행을 요구함
• 실제 주소와 다른 링크를 사용함
• 거래한 적 없는 결제 취소를 유도함
• 대표나 상사를 사칭해 비밀 송금을 요구함
• 정상적인 절차를 건너뛰라고 요구함
• 전화번호나 계좌번호가 공식 정보와 다름

링크를 확인할 때는 바로 누르지 말고 컴퓨터에서는 마우스 포인터를 올려 실제 연결 주소를 확인합니다. 휴대전화에서는 링크를 길게 눌러 주소를 미리 확인할 수 있지만, 실수로 열지 않도록 주의해야 합니다.

12. 피싱이 의심될 때 안전하게 대응하기

피싱이 의심되는 이메일에서는 링크, 첨부파일, QR코드를 열지 않는 것이 가장 중요합니다.

다음 순서로 대응합니다.

1. 이메일에 답장하지 않습니다.
2. 본문의 전화번호로 연락하지 않습니다.
3. 링크와 QR코드를 열지 않습니다.
4. 첨부파일을 실행하지 않습니다.
5. 메일 서비스의 피싱 신고 기능을 이용합니다.
6. 공식 홈페이지를 주소창에 직접 입력해 접속합니다.
7. 공식 고객센터에 발송 사실을 문의합니다.
8. 업무용 메일이라면 보안 담당자에게 원본 헤더와 함께 전달합니다.

이미 비밀번호를 입력했다면 안전한 기기에서 즉시 비밀번호를 변경하고, 동일한 비밀번호를 사용하는 다른 계정도 함께 변경해야 합니다. 가능하면 2단계 인증을 설정하고 최근 로그인 기록도 확인합니다.

금융정보를 입력하거나 송금했다면 해당 금융기관과 관계 기관에 즉시 신고해야 합니다.

전체 헤더 확인의 장점

• 화면에 표시된 발신자 이외의 기술 정보를 확인할 수 있습니다.
• SPF·DKIM·DMARC 인증 결과를 비교할 수 있습니다.
• Return-Path와 Reply-To의 불일치를 발견할 수 있습니다.
• 이메일이 거쳐 온 서버 경로를 추적할 수 있습니다.
• 반복적인 피싱 메일의 공통 발송 정보를 찾을 수 있습니다.
• 보안 담당자에게 구체적인 분석 자료를 제공할 수 있습니다.

전체 헤더 확인의 단점

• 항목이 많아 초보자가 해석하기 어렵습니다.
• 헤더 일부는 공격자가 임의로 추가할 수 있습니다.
• 정상적인 메일도 전달 과정에서 인증에 실패할 수 있습니다.
• 인증을 통과한 피싱 메일도 존재합니다.
• 외부 발송 서비스를 사용하면 회사 도메인과 서버 이름이 다를 수 있습니다.
• 헤더만으로 메일의 안전성을 완전히 확정할 수 없습니다.

사용자 경험을 정리한 평가

이메일 전체 헤더는 발신자 이름만으로 구분하기 어려운 피싱 메일을 분석할 때 매우 유용합니다. 특히 Gmail의 원본 보기처럼 인증 결과를 요약해주는 기능을 이용하면 전문 지식이 많지 않아도 SPF·DKIM·DMARC의 통과 여부를 확인할 수 있습니다.

하지만 spf=pass라는 문구만 보고 정상 메일로 판단하는 실수도 자주 발생합니다. SPF가 통과해도 화면에 표시된 From 주소가 아니라 Return-Path 측 도메인만 인증됐을 수 있기 때문입니다.

초보자는 먼저 DMARC 결과를 확인하고, From·Return-Path·Reply-To·DKIM의 d= 도메인을 비교하는 방식으로 접근하는 것이 이해하기 쉽습니다.

나의 의견

이메일 전체 헤더는 피싱 메일을 판단하는 강력한 자료지만 하나의 결과만 믿어서는 안 된다고 생각합니다. SPF·DKIM·DMARC가 모두 통과했더라도 발신 도메인 자체가 가짜이거나 정상 계정이 탈취됐을 가능성이 있기 때문입니다.

가장 안전한 판단 방법은 다음 세 가지를 함께 확인하는 것입니다.

1. 기술적 인증: SPF·DKIM·DMARC 결과
2. 도메인 일치: From·Return-Path·Reply-To·DKIM 서명 도메인
3. 메일 내용: 링크·첨부파일·송금 및 개인정보 요구 여부

특히 금융기관이나 공공기관을 사칭한 메일은 이메일 안의 링크와 연락처를 사용하지 말고, 공식 홈페이지나 공식 앱을 통해 사실 여부를 별도로 확인하는 것이 좋습니다.

핵심 확인 경로

이메일 열기 → 더보기 → 원본 보기 또는 메시지 원본 → Authentication-Results 확인 → SPF·DKIM·DMARC 비교 → From·Return-Path·Reply-To 확인 → Received 발신 경로 점검

간단히 정리하면 다음 순서입니다.

1. Authentication-Results에서 SPF·DKIM·DMARC를 확인합니다.
2. 화면의 From 도메인과 header.from을 비교합니다.
3. Return-Path와 smtp.mailfrom을 비교합니다.
4. DKIM의 header.d 또는 d= 도메인을 확인합니다.
5. Reply-To가 다른 주소로 설정됐는지 확인합니다.
6. Received 항목에서 발신 서버와 IP를 살펴봅니다.
7. 본문의 링크와 첨부파일을 별도로 점검합니다.
8. 의심되면 링크를 누르지 말고 공식 고객센터에 확인합니다.

전체 헤더는 피싱 여부를 판단하는 중요한 근거이지만 최종 판단은 인증 결과, 도메인 일치 여부, 메일 내용을 종합해서 내려야 합니다.