이 메일, SPF·DKIM·DMARC 결과를 어떻게 읽을까요? Email Header Analyzer

메일 인증 결과는 PASS 하나만 보면 안 돼요. SPF와 DKIM이 어떤 도메인을 인증했는지, DMARC가 화면에 보이는 From 주소와 정렬됐는지 함께 읽어야 합니다. 승인된 공개 도구의 예제를 다시 실행하니 SPF·DKIM은 PASS였지만 DMARC는 FAIL로 나왔어요. 이 조합부터 읽는 순서를 정리합니다.

1분 자가 점검

• 발신자 표시명보다 From 도메인을 먼저 봤나요?
• SPF·DKIM의 인증 도메인이 From 도메인과 맞나요?
• Reply-To가 다르면 업무 맥락상 필요한 주소인지 확인했나요?
• 링크를 누르지 않고 별도로 찾은 연락처로 요청을 재확인했나요?

승인된 Email Header Analyzer UI를 직접 렌더한 예제 결과 화면

1. PASS가 여러 개면 안전한 메일인가요?

아니에요. SPF는 연결한 서버와 SMTP 발신 식별자의 허용 관계를 확인하고, DKIM은 도메인 서명이 검증됐는지 보여 줍니다. 둘 다 사람의 신원이나 본문 의도까지 판단하지는 않아요.

DMARC는 SPF 또는 DKIM 결과에 화면에 보이는 From 도메인과의 정렬 조건을 더합니다. 그래서 SPF·DKIM이 PASS여도 서로 다른 도메인을 인증했다면 DMARC는 FAIL일 수 있어요.

2. 헤더에서는 어디부터 읽나요?

1. From: 사용자가 보는 발신 주소예요. 표시명만 믿지 말고 @ 뒤 도메인을 봅니다.
2. Authentication-Results: 수신 서버가 기록한 SPF·DKIM·DMARC 결과와 각 인증 도메인을 비교합니다. Gmail도 메시지 원본에서 이 결과를 확인하도록 안내해요. Google 공식 안내
3. Return-Path·Reply-To: 발송 대행이나 고객지원 시스템 때문에 다를 수 있어요. 결제·계정·파일 요청처럼 평소와 다른 행동을 요구한다면 별도 연락처로 확인합니다.
4. Received: 보통 새 서버가 위에 한 줄씩 추가합니다. 아래쪽의 오래된 경로부터 읽되, 누락되거나 위조된 줄이 섞일 가능성도 남겨 둡니다. Microsoft는 자사 보호 헤더의 의미와 확인 위치를 별도로 설명합니다. Microsoft 공식 문서

3. 자주 만나는 조합은 어떻게 해석하나요?

SPF PASS · DKIM PASS · DMARC FAIL

각 인증은 통과했지만 From 도메인과 정렬되지 않았을 가능성이 커요. 도구 예제가 이 경우입니다. 발신자를 안전한 별도 경로로 확인하기 전에는 요청을 실행하지 않는 편이 낫습니다.

SPF PASS · DKIM PASS · DMARC PASS

인증 신호가 일관된 편이에요. 그래도 탈취된 정상 계정, 위험한 링크, 사회공학 요청까지 걸러냈다는 뜻은 아닙니다.

SPF FAIL · DKIM PASS · DMARC PASS

메일 전달 과정에서 연결 서버가 바뀌어 SPF가 깨졌지만, From과 정렬된 DKIM 서명이 DMARC를 통과시킨 경우일 수 있어요. 전달·메일링리스트 맥락과 수신 시스템의 기록을 함께 봅니다.

4. Email Header Analyzer는 어떻게 쓰나요?

1. 메일 서비스에서 「원본 보기」나 「메시지 소스 보기」를 엽니다.
2. 본문과 첨부파일은 빼고 헤더만 복사합니다.
3. 도구에 붙여넣고 헤더 분석(Analyze header)을 누릅니다.
4. SPF·DKIM·DMARC, From·Return-Path·Reply-To, Received 경로를 차례로 확인합니다.
5. 텍스트 요약 복사(Copy text summary)로 결과를 복사하되, 외부 전달 전 개인 주소와 내부 서버명은 가립니다.

실측: 빈 입력과 한 줄짜리 불완전 헤더는 결과를 만들지 않았고, 예약 도메인 예제는 SPF PASS·DKIM PASS·DMARC FAIL·Received 2개로 분석됐어요. 결과 요약 복사도 다시 확인했습니다.

5. 도구 결과 뒤에 무엇을 직접 확인하나요?

• 메일 속 링크를 누르지 말고 기관·회사 주소를 직접 입력해 접속합니다.
• 송금·비밀번호·MFA 코드·첨부 실행 요청은 기존 연락처로 재확인합니다.
• 헤더를 공유할 때 실제 이메일 주소, 내부 서버명, 메시지 ID를 가립니다.
• 의심 메일은 조직의 신고 절차나 메일 서비스의 피싱 신고 기능으로 전달합니다. CISA 피싱 식별·신고 안내

한계: 이 점검을 통과해도 안전하다는 뜻은 아닙니다. 도구는 붙여넣은 헤더 문자를 브라우저에서 해석할 뿐 DNS 조회, 서명 재검증, 평판 조회, 본문·첨부파일 검사를 하지 않아요. 블로그 페이지 자체는 표시를 위해 일반 웹 리소스를 불러옵니다.

실제 메일 헤더를 읽어 보려면 Email Header Analyzer 열기

공식 참고자료

• RFC 7208 — Sender Policy Framework
• RFC 6376 — DomainKeys Identified Mail
• RFC 9989 — DMARC
• Google — Gmail 메시지 인증 확인
• Microsoft — Anti-spam message headers
• CISA — Recognize and Report Phishing