요약

이 이메일 헤더 분석 도구는 이메일의 원본 헤더 블록을 읽어, 수신 메일 서버가 이미 계산해 둔 Authentication-Results 줄을 바탕으로 SPF, DKIM, DMARC가 실제로 통과했는지 알려줍니다. Received 줄에서 릴레이 홉 수를 세고, 타임스탬프가 허용하는 경우 홉 사이의 전송 시간도 추정합니다. Gmail의 원본 보기, Outlook의 소스 보기, Apple Mail의 모든 헤더 화면에서 복사한 헤더를 그대로 붙여넣으면 됩니다. 아무것도 업로드되지 않고 파싱은 브라우저 안에서 실행되며, 가입도 필요 없습니다.

이메일 헤더로 SPF, DKIM, DMARC 바로 확인

이메일 원본 헤더를 붙여넣으면 이 이메일 헤더 분석 도구가 수신 메일 서버가 이미 판정한 결과를 그대로 읽어줍니다: SPF, DKIM, DMARC 통과 여부, 릴레이 홉 수, 홉 간 전송 시간까지 한 번에 보여줍니다.

헤더 분석하기

이메일 헤더 분석기

아래에 원본 헤더 전체를 붙여넣으세요. 파싱과 채점은 전부 브라우저 안에서 실행되며, 어디에도 업로드되지 않습니다.

이메일의 원본 헤더 블록을 붙여넣으세요 (원본 보기, 소스 보기, 또는 메시지 세부정보 메뉴). 확인 작업은 브라우저 안에서만 실행됩니다.

-
위에 헤더를 붙여넣으면 분석 결과가 표시됩니다
SPF, DKIM, DMARC 값은 Authentication-Results 헤더에서 읽어옵니다.
    작동 방식

    점수가 실제로 읽는 것은 무엇인가

    Authentication-Results 파싱

    분석기는 수신 서버가 남긴 Authentication-Results 줄을 찾아 이미 계산된 spf=, dkim=, dmarc= 값을 읽습니다. DNS 조회를 직접 다시 실행하지 않으며, 실제로 메시지를 수신한 메일함 제공자가 남긴 그 값을 그대로 신뢰합니다.

    릴레이 홉 카운트

    Received 줄 하나가 메일 서버 사이의 홉 하나입니다. 아래에서 위 순서로 읽어 집계합니다. 두 개 이상의 홉에 파싱 가능한 날짜가 있으면 첫 홉과 마지막 홉 사이의 전송 시간도 추정합니다. 타임스탬프가 파싱되지 않으면 추측하는 대신 그 수치를 숨깁니다.

    서버가 아니라 브라우저에서 실행

    헤더에는 내부 호스트명, 티켓 번호, IP 주소처럼 아무 웹 폼에나 붙여넣고 싶지 않은 정보가 담길 수 있습니다. 이 도구는 텍스트를 어디로도 전송하지 않습니다. 정규식 파싱, 채점, 홉 카운트 모두 지금 보고 있는 탭 안에서 클라이언트 측으로 실행됩니다.

    헤더 확인에 대해 자주 묻는 질문

    이 이메일 헤더 분석 도구는 무료인가요?
    네. 가입도 요청 횟수 제한도 없습니다. 점수는 브라우저 안에서 헤더 텍스트를 파싱해 계산하므로, 서버 측에서 요청당 비용을 제한할 필요가 없습니다.
    이메일 원본 헤더는 어디서 확인하나요?
    Gmail에서는 메일을 열고 원본 보기를 선택하세요. Outlook에서는 보기 메뉴의 소스 보기 또는 메시지 세부정보 패널을 이용하세요. Apple Mail에서는 보기, 메시지, 모든 헤더 순으로 들어가세요. Authentication-Results와 모든 Received 줄을 포함해 전체 블록을 복사하세요.
    여기에 붙여넣은 헤더를 저장하나요?
    아니요. 텍스트 영역은 사용자 기기에서 실행되는 자바스크립트가 읽습니다. 어디에도 업로드, 기록, 전송되지 않습니다. 이 페이지가 보내는 유일한 네트워크 요청은 사이트 전체 페이지에 공통으로 쓰이는 익명 페이지뷰 비콘뿐입니다.
    왜 Authentication-Results 헤더를 찾을 수 없다고 나오나요?
    일부 수신 서버는 이 줄을 추가하지 않으며, 전달되거나 내보낸 사본은 도중에 이 줄이 제거되기도 합니다. 티켓이나 스레드에서 붙여넣은 전달 사본이 아니라, 메시지가 처음 도착한 원본 받은편지함을 확인하세요.
    SPF는 통과했는데 DMARC는 실패했습니다. 무슨 뜻인가요?
    DMARC는 SPF와 DKIM 각각의 통과 여부만이 아니라 정렬(alignment)까지 확인합니다. 봉투 발신자(envelope sender) 기준으로는 SPF가 통과하더라도, 화면에 보이는 From 도메인이 도메인 소유자의 DMARC 정책과 충분히 일치하지 않을 수 있습니다. 여기서 DMARC 실패는 보통 From 도메인과 인증된 도메인이 다르다는 뜻입니다.
    점수 100이면 발신자가 정상이라는 뜻인가요?
    아니요. 수신 메일 서버가 이미 실행한 기술적 확인, 즉 발신 서버가 해당 도메인에 대해 권한을 가졌고 서명과 정렬이 일치했다는 사실만 의미합니다. 의도는 전혀 알려주지 않습니다. 탈취되거나 유사 도메인을 이용한 인증된 피싱도 여전히 존재합니다.
    왜 전송 시간이 표시되지 않거나 시간 오차로 나오나요?
    Received 타임스탬프는 각 릴레이 자체 시계로 기록되며, 시계는 어긋나기 마련입니다. 한 홉의 시계가 이전 홉보다 뒤처져 있거나 헤더에 파싱 가능한 날짜가 없으면, 이 도구는 확신할 수 없는 숫자를 보여주는 대신 그 값을 생략합니다.
    릴레이 홉 수 자체만으로 뭔가 알 수 있나요?
    그 자체만으로는 크게 알 수 있는 것이 없습니다. 대부분의 B2B 발송은 발신 서버와 받은편지함 사이에서 두세 개에서 네 개 정도의 릴레이를 거칩니다. 홉 수가 많다고 자동으로 의심스러운 것은 아니지만, 발신자의 알려진 인프라와 다른 낯선 호스트명이 체인에 나타나면 한 번 더 확인할 가치가 있습니다.

    직접 보내는 이메일의 인프라를 추적하세요

    이 체커는 다른 사람이 보낸 메일의 헤더를 사후에 읽는 도구입니다. Notification Harbor는 여러분이 직접 통제하는 발송을 위한 인프라입니다: 도메인 워밍업, 트레이스 단위 관찰 가능성, 그리고 첫 발송부터 올바르게 설정된 SPF, DKIM, DMARC를 제공합니다. 불만 접수 후에 진단하는 방식이 아닙니다.

    Notification Harbor가 작동하는 방식 보기
    notificationharbor
    무료로 시작하기