인기 도구

테마

이메일 헤더 분석기

이메일 헤더 분석은 메일 헤더를 붙여 넣는 것으로 시작합니다. 메시지가 거쳐 온 경로, 구간마다 걸린 시간, 메일 제공업체의 SPF, DKIM, DMARC 검사 결과를 확인하세요.

브라우저에서 읽음 · 공개 서버 IP만 조회하며, 요청할 때만 발신 도메인도 조회 · 저장하는 정보 없음

헤더는 내 기기를 벗어나지 않습니다. 결과 아래에 표시되는 IP 주소와 도메인만 조회합니다.

확인할 수 있는 내용

  • 제공업체 자체 검사만으로 판단한 실제 발신자
  • 경로상의 모든 서버, 구간별 지연, TLS 사용 여부
  • SPF, DKIM, DMARC, ARC와 From 주소와의 일치 여부
  • 유사 도메인, 위조된 결과 등의 징후와 각각의 근거
  • Microsoft 365, Gmail, SpamAssassin 스팸 헤더 해석
  • 원클릭 수신 거부를 포함한 Gmail과 Yahoo 대량 발송자 규정

이메일 헤더란 무엇인가요?

이메일 헤더는 메시지 본문 위에 있는 줄 묶음입니다. 누가 누구에게 언제 보냈는지, 그리고 메시지를 처리한 모든 서버의 기록이 들어 있습니다. 메일 앱은 대부분을 숨기며, “원본 보기”나 “소스 보기”를 선택하면 전체가 나타납니다.

각 줄은 이름, 콜론, 값으로 이루어지며, 긴 값은 공백으로 시작하는 다음 줄에 이어집니다 (RFC 5322). 헤더는 첫 번째 빈 줄에서 끝납니다. 그 뒤는 모두 본문이며, 이 도구는 본문을 읽지 않습니다.

헤더는 세 종류의 주체가 기록합니다. 발신자의 앱(From, To, Subject, Date), 경로상의 모든 서버(서버마다 Received 줄 하나), 그리고 제공업체(Authentication-Results, 스팸 판정)입니다. 신뢰할 수 있는 주체가 검사한 것은 마지막뿐입니다.

뉴스레터 샘플필드 30개 · 4.6 KB

제공업체(Google)가 추가필드 11개

  1. 1Delivered-To: reader@example.com
  2. 2Received: by 2002:a05:6214:5a0b:… with SMTP id kq11csp1342871qvb; Wed, 21 Oct 2026 07:02:48 -0700
  3. 3–7 X-Google-Smtp-Source, X-Received, ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results
  4. 8Return-Path: <bounces+48213-9f1c-reader=example.com@sendgrid.net>
  5. 9Received: from o1.ptr1234.example.org ([167.89.118.37]) by mx.google.com with ESMTPS id …; Wed, 21 Oct 2026 07:02:47 -0700
  6. 10Received-SPF: pass (google.com: domain of …@sendgrid.net designates 167.89.118.37 as permitted sender) client-ip=167.89.118.37;
  7. 11Authentication-Results: mx.google.com; dkim=pass …; dkim=pass …; spf=pass …; dmarc=pass …

경로상의 서버(SendGrid example.org)가 추가필드 5개

  1. 12DKIM-Signature: v=1; a=rsa-sha256; d=example.org; s=s1; h=content-type:from:…
  2. 13DKIM-Signature: v=1; a=rsa-sha256; d=sendgrid.info; s=smtpapi; h=content-type:from:…
  3. 14Received: by filterdrecv-7d9c8b5f6-2kqzr with SMTP id … 2026-10-21 14:02:13.517 +0000 UTC
  4. 15Received: from app-01.example.org ([198.51.100.24]) by geopod-ismtpd-3 (SG) with ESMTPSA id …; Wed, 21 Oct 2026 14:02:12.902 +0000
  5. 16Received: from localhost ([127.0.0.1]) by app-01.example.org (Postfix) with ESMTP id 4Xc9Fq2Lb1z9vKs; Wed, 21 Oct 2026 14:02:10 +0000

발신자의 앱이 기록필드 14개

  1. 17Content-Type: multipart/alternative; boundary=8a1f4c2e9b7d3a6c5e0f
  2. 18Date: Wed, 21 Oct 2026 14:02:04 +0000 (UTC)
  3. 19From: Example Weekly <news@example.org>
  4. 20Mime-Version: 1.0
  5. 21Message-ID: <3qX0b1wZTcO2pN9sKd4ZfA@geopod-ismtpd-3>
  6. 22Subject: This week at Example: five things worth reading
  7. 23List-Unsubscribe: <https://u48213.ct.sendgrid.net/lu/unsubscribe?…>, <mailto:unsubscribe@example.org?…>
  8. 24List-Unsubscribe-Post: List-Unsubscribe=One-Click
  9. 25–29 List-Id, Feedback-ID, X-SG-EID, X-SG-ID, X-Entity-ID
  10. 30To: reader@example.com

빈 줄: 여기서부터 본문이 시작되며, 이 도구는 본문을 읽지 않습니다

줄여서 표시했습니다. 필드마다 한 줄이며 헤더의 번호를 따릅니다. 색상은 결과와 같습니다: 제공업체, 경로상의 서버, 발신자.
PayPal 유사 도메인 메일의 이메일 헤더 분석기 결과: 판정, 주요 발견 사항, 41분 지연이 표시된 전달 경로PayPal 유사 도메인 메일의 이메일 헤더 분석기 결과: 판정, 주요 발견 사항, 41분 지연이 표시된 전달 경로판정제공업체가 기록한 Authentication-Results만으로 판단한 발신자와, 이를 검사한 서버입니다.눈에 띄는 점각 발견 사항의 심각도, 이유, 근거가 된 헤더 줄을 보여 줍니다.전달 경로Date 헤더부터 받은편지함까지 모든 서버를 구간 길이에 비례해 그리고, 그 위에 신뢰 경계를 표시합니다.요약 정보전달에 걸린 시간, 홉 수, 모든 외부 홉의 TLS 사용 여부, Microsoft가 선택한 폴더를 보여 줍니다.
의심스러운 샘플입니다. Microsoft 365의 자체 검사는 발신자를 확인하지 못했고, 발견 사항에는 근거가 표시되며, 경로에는 메시지가 대기한 구간이 나타납니다. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

이메일 헤더 보기: 아래에서 위로 읽는 방법

이메일 헤더를 분석하려면 Received 줄을 아래에서 위로 읽습니다. 서버는 이미 있는 줄 위에 자기 줄을 추가하므로, 가장 아래가 첫 번째 홉이고 맨 위는 제공업체가 메시지를 메일함에 넘기는 단계입니다 (RFC 5321 §4.4).

한 줄에는 받은 주체(by), 어느 서버와 주소에서 왔는지(from, 연결에서 확인된 주소), 방식(with: ESMTPS는 STARTTLS, ESMTPSA는 STARTTLS와 로그인), 시각이 나옵니다. 서버는 자기 현지 시간을 기록하므로 빼기 전에 각각 UTC로 바꿔야 합니다. 07:02:47 -0700은 14:02:47 UTC입니다.

확실한 것은 제공업체가 기록한 줄뿐입니다. 제공업체의 첫 줄 아래에 있는 내용은 모두 확인할 수 없는 서버에서 온 것이며, 발신자가 자기 줄을 추가할 수도 있습니다.

헤더에서 · 위가 최신

여정 · 홉 1이 처음

#2 by 2002:a05:6214:5a0b:…with SMTP id kq11csp…07:02:48 -0700
5Google 내부14:02:48 UTC+1초
#9 from o1.ptr1234.example.org [167.89.118.37]by mx.google.com with ESMTPS07:02:47 -0700
4mx.google.com14:02:47 UTC+33초

신뢰 경계

#14 by filterdrecv-7d9c8b5f6-2kqzrwith SMTP id filterd…2026-10-21 14:02:13.517 +0000 UTC
3SendGrid 필터14:02:13 UTC+0.6초
#15 from app-01.example.org [198.51.100.24]by geopod-ismtpd-3 (SG) with ESMTPSA14:02:12.902 +0000
2SendGrid14:02:12 UTC+2.9초
#16 from localhost [127.0.0.1]by app-01.example.org (Postfix) with ESMTP14:02:10 +0000
1app-01.example.org14:02:10 UTC처음

위로 읽습니다: 서버는 자기 줄을 맨 위에 추가합니다

뉴스레터의 Received 줄 다섯 개입니다. 홉 1은 뉴스레터 앱이며, SendGrid와 Google 사이의 33초가 가장 큰 지연입니다.

이메일 헤더의 SPF, DKIM, DMARC

SPF는 발송 서버가 엔벌로프 도메인(Return-Path)을 대신해 메일을 보낼 수 있는지 묻습니다. DKIM은 도메인이 메시지에 서명했고 서명이 아직 일치하는지 묻습니다. DMARC는 통과한 SPF 또는 DKIM 도메인이 화면에 보이는 From 주소와 일치하는지 묻습니다.

제공업체는 그 답을 Authentication-Results에 기록합니다. 제공업체가 자기 Received 줄 옆에 기록한 블록을 신뢰하세요. 다른 사본, ARC 사본, 발신자의 줄 사이에 있는 것은 누가 추가했는지 알 수 없습니다 (RFC 8601).

통과는 도메인을 증명할 뿐 의도를 증명하지 않습니다. examp1e.com도 자기 도메인에 대해 세 가지를 모두 통과할 수 있습니다.

Authentication-Results 해부뉴스레터 · 이어서 의심스러운 샘플
Authentication-Results: mx.google.com;1

검사한 곳authserv-id: 제공업체 자체 서버

dkim=pass header.i=@example.org header.s=s1 header.b=Xk3Pq9aZ;2

DKIM: example.org이(가) 서명함키는 s1._domainkey.example.org에 있음

dkim=pass header.i=@sendgrid.info header.s=smtpapi …;3

두 번째 서명발송 서비스 자체의 서명이며 example.org과(와) 정렬될 수 없음

spf=pass (google.com: … designates 167.89.118.37 as permitted sender) smtp.mailfrom=…@sendgrid.net;4

SPF: sendgrid.net을(를) 대신해 발송 허용됨From이 아니라 엔벌로프(Return-Path) 도메인

dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.org5

DMARC: From 도메인이 ②와 일치p=quarantine은(는) example.org이 실패한 메일에 대해 수신 서버에 요청하는 조치

#3 Authentication-Results: spf=softfail (sender IP is 198.51.100.77) … dkim=none … dmarc=none action=none … compauth=fail reason=001인정됨Microsoft 365이(가) 추가한 첫 번째 Received 줄 위에 기록했습니다.

신뢰 경계

#7 Authentication-Results: protection.outlook.com; spf=pass … dkim=pass … dmarc=pass action=none … compauth=pass reason=100무시됨Microsoft을(를) 내세우지만 모든 Received 줄 아래에 있습니다. 메시지 안에 들어 있던 것입니다. 수신 서버는 그 위치에 기록하지 않습니다.
선 아래: 의심스러운 샘플의 Authentication-Results 두 개입니다. 위치가 어느 쪽을 인정할지 결정합니다.

이 이메일은 진짜일까요, 위조일까요?

헤더만으로는 제안이 정직한지 알 수 없지만, From 도메인이 실제로 보냈는지와 다른 곳을 흉내 내는지는 알 수 있습니다. 제공업체가 기록한 판정부터 보고, 다음 징후를 찾아보세요.

이 중 어느 것도 그 자체로 피싱을 증명하지 않으며, 흔한 차이 중 여럿은 정상입니다. Microsoft는 유사 도메인도 소유자가 설정했다면 SPF, DKIM, DMARC를 통과할 수 있다고 밝혔습니다 (Microsoft).

  • 유사한 From 도메인높음

    paypa1-billing.example대paypal.com

    숫자나 비슷한 글자로 바꿔 놓았습니다. 자기 도메인에 대해서는 SPF, DKIM, DMARC를 통과할 수 있습니다.

  • 다른 문자 체계의 글자높음

    xn--pypal-4ve.example표시pаypal.example

    а는 키릴 문자입니다. 헤더에는 xn-- 형식(punycode)이 남아 있어 이를 알아볼 수 있습니다.

  • 제공업체가 fail이라고 함높음

    compauth=fail reason=001 · spf=softfail

    수신 서버가 From 도메인을 메시지를 보낸 서버와 연결하지 못했습니다.

  • 다른 주소를 담은 이름중간

    "accounts@example.com" <notice@mailer.example>

    앱은 주소가 아니라 이름을 보여 줍니다. 실제 발신자는 꺾쇠괄호 안에 있습니다.

  • 필터의 자체 판정중간

    CAT:PHSH · dest:J · SFTY:9.25

    Microsoft가 피싱으로 분류해 정크로 보냈습니다. 9.25는 첫 연락 팁입니다.

  • 선 아래의 통과 결과중간

    #7 Authentication-Results: protection.outlook.com; spf=pass dmarc=pass

    모든 Received 줄 아래에 있으므로 발신자가 기록한 것입니다. 제공업체의 것만 인정됩니다.

그 자체로는 위험 신호가 아닌 정상적인 경우

  • Return-Path가 From과 다름

    sendgrid.net대example.org

    이메일 서비스가 대신 보냅니다. 일치는 DKIM이 담당합니다.

  • 거꾸로 가는 시간

    Reply-To: support@example.org

    서버마다 자기 시계로 기록하며, 시계는 1초 이상 다를 수 있습니다.

  • Reply-To가 From과 다름

    09:47:12 → 09:47:11 (−1초)

    답장은 고객 지원 창구로 갑니다. 그 도메인이 다른 곳을 흉내 낼 때만 살펴볼 만합니다.

  • 다른 나라에 있는 서버

    CTRY:US · 209.85.208.54

    서버의 위치일 뿐 사람의 위치가 아닙니다. 대형 제공업체는 여러 곳에서 발송합니다.

의심스러운 샘플과 가상의 변형에서 가져온 징후입니다. 어느 것도 그 자체로 피싱을 증명하지 않습니다.

내 이메일은 왜 늦게 도착했나요?

각 Received 시각을 바로 위 시각에서 UTC로 뺍니다. 가장 큰 간격이 메시지가 대기한 곳입니다. 30분 이상의 간격은 재시도와 일치합니다 (RFC 5321은 최소 30분을 기다릴 것을 권장합니다).

Date 헤더는 발신자의 기기에서 나오므로, Date에서 첫 번째 서버까지의 시간에는 느린 시계나 발송 훨씬 전에 작성한 임시 보관 메일이 포함됩니다. 두 서버의 시계가 다르면 시각이 1초 거꾸로 갈 수도 있습니다.

어느 정도가 너무 긴지 알려 주는 표준은 없습니다.

의심스러운 샘플시간은 UTC 기준
Date 헤더09:05:44 UTC
+7초
mail.paypa1-billing.example09:05:51 · 첫 번째 서버
41분 21초30분 이상: 재시도

Microsoft 365

  • 09:47:12엣지, 첫 줄
  • 09:47:11내부 · −1초
  • 09:47:13메일함 서버
  1. 09:05:44Date 헤더발신자의 시계
  2. +7초
  3. 09:05:51mail.paypa1-billing.example첫 번째 서버
  4. 41분 21초30분 이상: 재시도와 일치
  5. 09:47:12Microsoft 365 엣지Microsoft이(가) 기록한 첫 줄
  6. −1초시계 차이
  7. 09:47:11Microsoft 내부
  8. +2초
  9. 09:47:13Microsoft 메일함 서버
Date 헤더 기준
41분 29초
첫 번째 서버 기준
41분 22초
뉴스레터 샘플 · 44초시간이 걸린 곳
  • Date → 첫 번째 서버 6초
  • SendGrid로 진입 2.9초
  • SendGrid 필터 0.6초
  • SendGrid → Google, 가장 큰 지연 33초
  • Google 내부 1초

Microsoft 365와 Gmail 스팸 헤더 해석

Microsoft 365는 필터의 판정을 X-Forefront-Antispam-Report에 기록합니다. CAT은 판정, SFV는 스팸 필터링의 결정이며, X-Microsoft-Antispam-Mailbox-Delivery는 어느 폴더로 갔는지 알려 줍니다.

SCL은 여전히 기록되지만 Microsoft는 Microsoft 365에서 더 이상 아무것도 결정하지 않는다고 밝혔으므로 CAT을 읽으세요 (Microsoft). BCL은 불만 건수로 대량 메일을 0에서 9까지 평가하며, 정책의 임계값(기본 7)이 결정합니다.

Gmail은 문서화된 스팸 판정을 기록하지 않습니다. SpamAssassin을 실행하는 서버는 점수, 임계값, 적용된 규칙이 담긴 X-Spam-Status를 추가합니다.

X-Forefront-Antispam-Report의심스러운 샘플
CIP:198.51.100.77CTRY:LANG:en3SCL:5SRV:5IPV:NLI2SFV:SPMH:mail.paypa1-billing.examplePTR:mail.paypa1-billing.example1CAT:PHSH4SFTY:9.25SFS:(13230040)(376014)(1800799024)(8096899003)6DIR:INB
  1. 1CAT:PHSH 판정: 피싱 (SPM 스팸, SPOOF, BULK, HPHSH…)
  2. 2SFV:SPM 스팸 필터링이 스팸으로 표시함 (NSPM: 스팸 아님)
  3. 3SCL:5 필터링의 입력값이며 Microsoft 365에서 결정이 아님
  4. 4SFTY:9.25 첫 연락 안전 팁이 표시됨
  5. 5IPV:NLI IP가 어떤 평판 목록에도 없음
  6. 6DIR:INB 인바운드. SFS와 ARA는 Microsoft 내부 진단 정보

대량 메일 불만 수준BCL:0

01–3 적음4–7 보통8–9 많음

임계값은 엄격 5, 표준 6, 기본 7이며, 이 값 이상이면 대량 메일입니다.

전달된 위치dest:J

정크 메일X-Microsoft-Antispam-Mailbox-Delivery

dest:I는 받은편지함입니다. ucf, jmr, ENG는 내부 값입니다.

Gmail과 SpamAssassin

Gmail은 문서화된 스팸 판정을 기록하지 않습니다. X-Received, X-Google-Smtp-Source, X-Gm-*는 내부 값입니다.

X-Spam-Status: No, score=2.307 required=6.31

SpamAssassin: 필요한 점수 이상일 때만 스팸입니다.

의심스러운 샘플의 모든 값을 Microsoft의 스팸 방지 헤더 표로 읽은 것입니다.

Gmail, Outlook, Apple Mail 등에서 메일 헤더 보기

컴퓨터나 웹 브라우저에서 전체 헤더 또는 원본 메시지 전체를 복사하세요. 그런 다음 위에 붙여 넣거나, 메시지를 .eml 파일로 저장해 업로드하세요.

앱마다 헤더가 있는 메뉴가 다릅니다. 사용하는 앱을 고르세요. 단계는 각 제공업체의 공식 도움말을 따랐습니다.

  1. 1메일 열기
  2. 2더보기 ⋮
  3. 3원본 보기
  4. 4클립보드로 복사

출처: support.google.com/mail/answer/29436

휴대폰을 쓰시나요? Gmail, Outlook, Apple Mail 앱에서는 전체 헤더를 볼 수 없습니다. 브라우저(Gmail, 웹의 Outlook, 네이버 메일 웹 등)나 데스크톱 앱에서 메일을 열거나, 첨부 파일로 전달한 뒤 .eml을 여기에 업로드하세요.

이메일 추적 방법과 IP로 알 수 있는 것, 알 수 없는 것

이메일을 추적하려면 제공업체가 기록한 첫 번째 Received 줄의 from 주소를 확인하세요. 메시지를 넘겨준 서버입니다. 그 소유자를 조회하면 누구의 서버였는지 알 수 있으며, 원래 발신자가 아니라 전달 서버일 수도 있습니다.

헤더에 나타나는 것은 메일 서버이며, 발신자 자신의 네트워크는 X-Originating-IP에 가끔 나타날 뿐입니다.

그 주소도 네트워크와 대략적인 국가를 가리킬 뿐, 사람이나 거리를 가리키지 않습니다.

Gmail → Outlook 샘플브라우저에서 조회
Ana의 컴퓨터헤더에 없음
209.85.208.54mail-ed1-f54.google.com
Microsoft 365기록된 첫 번째 Received 줄

209.85.208.54에서 알 수 있는 것

소유자
Google LLC · 209.85.128.0/17 (ARIN)
국가
미국, 서버가 있는 곳
역할
Gmail 발송 서버, SPF가 검사한 서버

알 수 없는 것

누가
Ana 또는 example.net의 다른 누군가
어디서
Ana의 도시나 거리
기기
Ana의 컴퓨터나 휴대폰
분석기는 서버의 공개 주소만 해당 레지스트리에서 조회하며, 요청한 내용을 그대로 보여 줍니다.

이메일 헤더: 질문과 답변

이메일 헤더 분석은 어떻게 하나요?

메일 앱에서 전체 헤더를 복사해 위에 붙여 넣고 헤더 분석을 선택하세요. 이메일 헤더 분석은 헤더를 아래에서 위로 읽어, 제공업체가 기록한 판정, 서버별 경로와 구간별 지연, 근거가 있는 발견 사항을 보여 줍니다.

여기에 이메일 헤더를 붙여 넣어도 안전한가요?

헤더는 브라우저에서 읽으며 저희에게 전송되지 않습니다. 공개 서버 IP만 조회합니다. 소유자는 레지스트리(RDAP, 브라우저가 요청)에서, 국가는 저희 사이트에서 가져온 DB-IP 파일에서 확인하므로, 저희 서버는 어느 주소 범위를 요청했는지 알게 됩니다. 발신자의 도메인은 요청할 때만 dns.google에서 조회합니다. 헤더에는 주소와 서버 이름이 들어 있으므로 공유할 때는 주의하세요.

메일 헤더는 위조될 수 있나요?

네, 제공업체가 메시지를 받기 전에 기록된 내용은 모두 위조될 수 있습니다. 각 서버는 자기 줄을 맨 위에 추가하므로, 발신자는 그 아래에 가짜 Received 줄과 pass라고 쓴 가짜 Authentication-Results까지 넣을 수 있습니다. 믿을 수 있는 부분은 맨 위에 있는 제공업체 자신의 줄과 그 옆에 제공업체가 기록한 결과이며, 분석기는 나머지를 주장으로 표시합니다.

가짜 이메일인지 어떻게 알 수 있나요?

제공업체의 Authentication-Results부터 보세요. DMARC fail이거나 Microsoft 365의 compauth fail이면 From 도메인이 확인되지 않았다는 뜻입니다. 그다음 도메인 자체를 읽어 보세요. paypa1-billing.example 같은 유사 도메인은 자기 도메인에 대해 모든 검사를 통과할 수 있습니다. 마지막으로 답장이 어디로 가는지와 어느 서버가 메시지를 넘겨줬는지 보세요. 분석기는 각 발견 사항을 근거와 함께 보여 줍니다.

이메일에서 발신자의 IP 주소를 알 수 있나요?

제공업체에 메시지를 넘겨준 서버는 알 수 있습니다. 제공업체의 첫 번째 Received 줄에 있는 from 주소이며 SPF가 검사한 주소입니다. 보통 메일 서버이지 그 사람의 컴퓨터가 아닙니다. 일부 제공업체는 X-Originating-IP도 추가하는데, 보통 발신자의 기기나 네트워크를 가리키지만 이것도 네트워크와 대략적인 국가까지만 알려 줄 뿐 개인을 가리키지는 않습니다.

Gmail은 왜 발신자의 IP 주소를 보여 주지 않나요?

Gmail 웹이나 앱에서 보낸 메시지에는 보통 Google의 서버만 들어 있습니다. 첫 번째 Received 줄에 from 부분이 없어 발신자 자신의 주소는 헤더에 없습니다. 보이는 주소는 메시지를 다음으로 넘긴 Google 서버, 즉 SPF가 검사한 서버의 것이므로, 조회하면 소유자는 발신자의 네트워크가 아니라 Google로 나옵니다.

SPF는 통과했는데 DMARC는 왜 실패했나요?

SPF는 엔벌로프 도메인(Return-Path)을 검사하며, 이는 화면에 보이는 From과 다를 수 있습니다. DMARC는 From과 정확히 또는 같은 조직 안에서 일치하는 도메인에 대해 SPF 또는 DKIM이 통과해야 합니다. 통과한 도메인이 다른 곳의 것, 예를 들어 이메일 서비스의 반송 도메인이면 DMARC는 실패합니다. From 도메인의 DKIM 서명만 있어도 DMARC를 통과합니다.

홉 사이의 지연이 음수이면 무슨 뜻인가요?

나중 서버가 바로 앞 서버보다 이른 시각을 기록했다는 뜻입니다. 서버마다 자기 시계의 시각을 기록하며 그 시계는 다를 수 있으므로, 분석기는 지연이 아니라 시계 차이로 표시합니다. 제공업체가 기록한 줄 아래에 있는 줄의 시각은 위조되었을 수도 있으므로, 그 순서와 간격은 주장으로 보세요.

SCL과 BCL은 무슨 뜻인가요?

둘 다 Microsoft 365의 스팸 방지 헤더에 있는 점수입니다. BCL은 불만 수준으로 대량 메일을 0(대량 발신자가 아님)에서 9까지 평가합니다. SCL은 여전히 기록되지만 Microsoft 365에서는 필터링의 입력값일 뿐 결정이 아닙니다. 판정은 CAT에 들어 있고, SFV는 스팸 필터링이 메시지를 어떻게 처리했는지 알려 줍니다.

이메일 헤더에 숨은참조(BCC) 수신자가 나타나나요?

아니요. 숨은참조는 헤더에 기록되지 않습니다. 발송 서버가 엔벌로프에서 전달하며, To와 Cc 줄에는 보이는 수신자만 표시됩니다. Received 줄의 for 절에 수신자 한 명이 나올 수 있으며, 그래서 서버는 이를 신중하게 쓰도록 권고됩니다. Delivered-To에는 메시지가 도착한 사서함이 표시될 수도 있습니다.

Microsoft의 Message Header Analyzer와 같은 도구인가요?

아니요. Microsoft의 Message Header Analyzer는 메시지의 헤더를 해석하는 Outlook 추가 기능이자 웹 페이지입니다. 이 도구는 같은 Microsoft 헤더에 더해 Gmail과 SpamAssassin의 헤더, 모든 홉의 추적도 읽고, 결과의 위치를 보고 어느 것을 신뢰할지 판단하며, 전부 브라우저에서 실행됩니다.

Authentication-Results 헤더가 여러 개인 이유는 무엇인가요?

메시지를 검사하는 서버는 모두 하나씩 추가할 수 있고, 발신자가 가짜를 추가할 수도 있으므로 한 메시지에 여러 개가 붙어 있는 경우가 많습니다. 제공업체가 기록한 것만 인정됩니다. 맨 위에서 제공업체 자신의 Received 줄 옆에 있고 자기 서버를 가리키는 것입니다. ARC-Authentication-Results는 전달한 쪽이 봉인한 결과로, 전달 때문에 메시지가 바뀌기 전에 무엇이 통과했는지 다음 서버가 볼 수 있게 합니다.

부족한 점이 있습니까?기능 또는 새 도구 제안하기

더 많은 이메일 도구