Công cụ phổ biến

Giao diện

Phân Tích Email Header

Dán header của một email để phân tích email header: xem đường đi của email, thời gian ở mỗi chặng và kết quả kiểm tra SPF, DKIM, DMARC mà nhà cung cấp email của bạn đã ghi lại.

Đọc ngay trong trình duyệt · chỉ tra cứu IP công cộng của máy chủ, và tên miền người gửi nếu bạn yêu cầu · không lưu lại gì

Header của bạn không bao giờ rời khỏi thiết bị. Chỉ các địa chỉ IP và tên miền liệt kê dưới kết quả mới được tra cứu.

Bạn sẽ thấy gì

  • Ai thực sự đã gửi, chỉ dựa trên các kiểm tra của chính nhà cung cấp của bạn
  • Mọi máy chủ trên đường đi, độ trễ ở từng nơi và có dùng TLS hay không
  • SPF, DKIM, DMARC và ARC, và chúng có khớp với địa chỉ From hay không
  • Tên miền nhái, kết quả giả mạo và các dấu hiệu khác, mỗi cái kèm bằng chứng
  • Header spam của Microsoft 365, Gmail và SpamAssassin, đã được giải mã
  • Quy định cho bên gửi hàng loạt của Gmail và Yahoo, gồm cả hủy đăng ký một lần bấm

Email header là gì?

Email header là khối các dòng nằm phía trên nội dung email: ai gửi và gửi cho ai, khi nào, cùng bản ghi của từng máy chủ đã xử lý nó. Ứng dụng email ẩn gần hết phần này; “Show original” hoặc “View source” sẽ hiện toàn bộ, nên đó cũng là cách xem header email.

Mỗi dòng gồm một tên, dấu hai chấm và một giá trị; giá trị dài sẽ tiếp tục ở các dòng bắt đầu bằng khoảng trắng (RFC 5322). Header kết thúc ở dòng trống đầu tiên. Mọi thứ sau đó là nội dung thư, phần mà công cụ này không bao giờ đọc.

Có ba bên viết ra chúng: ứng dụng của người gửi (From, To, Subject, Date), mọi máy chủ trên đường đi (mỗi máy chủ một dòng Received) và nhà cung cấp của bạn (Authentication-Results, kết luận spam). Chỉ phần cuối cùng là do bên bạn tin tưởng kiểm tra.

Mẫu bản tin30 trường · 4,6 KB

Do nhà cung cấp của bạn thêm vào (Google)11 trường

  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 …

Do các máy chủ trên đường đi thêm vào (SendGrid, example.org)5 trường

  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

Do ứng dụng của người gửi viết14 trường

  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

dòng trống: nội dung thư bắt đầu từ đây, và công cụ này không bao giờ đọc nó

Đã rút gọn: một dòng cho mỗi trường, đánh số như trong header. Màu sắc như trong kết quả: nhà cung cấp của bạn, các máy chủ trên đường đi, người gửi.
Kết quả phân tích email header cho một email nhái PayPal: kết luận, các phát hiện và đường chuyển thư có khoảng trễ 41 phútKết quả phân tích email header cho một email nhái PayPal: kết luận, các phát hiện và đường chuyển thư có khoảng trễ 41 phútKết luậnAi đã gửi email, chỉ dựa trên Authentication-Results do nhà cung cấp của bạn ghi, kèm máy chủ đã thực hiện kiểm tra.Điểm đáng chú ýTừng phát hiện kèm mức độ, lý do và đúng dòng header mà nó dựa vào.Đường chuyển thưMọi máy chủ từ header Date đến hộp thư, khoảng cách vẽ theo tỷ lệ và ranh giới tin cậy cắt ngang.Số liệuThời gian chuyển thư, số chặng, mọi chặng bên ngoài có dùng TLS hay không và Microsoft đã chọn thư mục nào.
Mẫu đáng ngờ: các kiểm tra của chính Microsoft 365 không xác nhận được người gửi, các phát hiện nêu rõ bằng chứng và đường đi cho thấy email đã chờ ở đâu. Chọn một số để xem từng phần thể hiện điều gì.

Cách xem header email và đọc từ dưới lên trên

Để phân tích email header, hãy đọc các dòng Received từ dưới lên trên. Mỗi máy chủ thêm dòng của nó lên trên các dòng đã có, nên dòng thấp nhất là chặng đầu tiên và dòng trên cùng là nhà cung cấp của bạn giao email vào hộp thư (RFC 5321 §4.4).

Một dòng cho biết ai đã nhận (by), từ máy chủ và địa chỉ nào (from, địa chỉ thấy được trên kết nối), bằng cách nào (with: ESMTPS nghĩa là STARTTLS, ESMTPSA là STARTTLS cộng đăng nhập) và khi nào. Máy chủ đóng dấu theo giờ địa phương của mình, nên hãy đổi từng giờ sang UTC trước khi trừ: 07:02:47 -0700 là 14:02:47 UTC.

Chỉ những dòng do nhà cung cấp của bạn ghi là chắc chắn. Mọi thứ bên dưới dòng đầu tiên của nó đến từ các máy chủ bạn không kiểm tra được, và người gửi có thể tự thêm dòng của riêng mình.

Trong header · trên cùng là mới nhất

Hành trình · chặng 1 trước

#2 by 2002:a05:6214:5a0b:…with SMTP id kq11csp…07:02:48 -0700
5Google nội bộ14:02:48 UTC+1 giây
#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 giây

Ranh giới tin cậy

#14 by filterdrecv-7d9c8b5f6-2kqzrwith SMTP id filterd…2026-10-21 14:02:13.517 +0000 UTC
3bộ lọc SendGrid14:02:13 UTC+0,6 giây
#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 giây
#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đầu tiên

Đọc ngược lên: mỗi máy chủ thêm dòng của nó lên trên cùng

Năm dòng Received của bản tin. Chặng 1 là ứng dụng bản tin; 33 giây giữa SendGrid và Google là khoảng cách lớn nhất.

SPF, DKIM và DMARC trong email header

SPF hỏi máy chủ gửi có được phép gửi thay cho tên miền envelope (Return-Path) hay không. DKIM hỏi một tên miền có ký email hay không và chữ ký còn khớp không. DMARC hỏi tên miền SPF hoặc DKIM đã pass có khớp với địa chỉ From mà bạn thấy hay không.

Nhà cung cấp của bạn ghi các câu trả lời vào Authentication-Results. Hãy tin khối do nhà cung cấp của bạn ghi bên cạnh dòng Received của chính nó. Các bản sao khác, bản sao ARC và bất kỳ khối nào nằm lẫn giữa các dòng của người gửi đều có thể do bất kỳ ai thêm vào (RFC 8601).

Pass chứng minh tên miền, không chứng minh ý định: examp1e.com có thể tự pass cả ba cho chính nó.

Authentication-Results, mổ xẻ từng phầnbản tin · rồi đến mẫu đáng ngờ
Authentication-Results: mx.google.com;1

Ai đã kiểm traauthserv-id: máy chủ của chính nhà cung cấp của bạn

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

DKIM: example.org đã kýkhóa của nó nằm ở s1._domainkey.example.org

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

Chữ ký thứ haicủa chính dịch vụ gửi; nó không thể khớp với example.org

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

SPF: được phép gửi cho sendgrid.nettên miền envelope (Return-Path), không phải From

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

DMARC: tên miền From khớp với ②p=quarantine là điều example.org yêu cầu bên nhận làm với thư không đạt

#3 Authentication-Results: spf=softfail (sender IP is 198.51.100.77) … dkim=none … dmarc=none action=none … compauth=fail reason=001Được tínhMicrosoft 365 đã ghi nó, phía trên dòng Received đầu tiên mà nó thêm vào.

Ranh giới tin cậy

#7 Authentication-Results: protection.outlook.com; spf=pass … dkim=pass … dmarc=pass action=none … compauth=pass reason=100Bị bỏ quaNó nêu tên Microsoft nhưng nằm dưới mọi dòng Received: nó đến cùng với email. Bên nhận không bao giờ ghi ở đó.
Bên dưới đường kẻ: hai Authentication-Results của mẫu đáng ngờ. Vị trí quyết định cái nào được tính.

Email này là thật hay bị giả mạo?

Header không cho bạn biết một lời đề nghị có trung thực hay không, nhưng chúng cho thấy tên miền From có thực sự đã gửi email hay không và nó có giả dạng người khác hay không. Hãy bắt đầu với kết luận do nhà cung cấp của bạn ghi, rồi tìm các dấu hiệu sau.

Tự thân không dấu hiệu nào chứng minh được phishing, và nhiều khác biệt thường gặp là bình thường. Microsoft lưu ý rằng một tên miền nhái có thể pass SPF, DKIM và DMARC nếu chủ sở hữu đã thiết lập chúng (Microsoft).

  • Tên miền From nháiCao

    paypa1-billing.exampleso vớipaypal.com

    Một chữ số hoặc một chữ cái giống nhau bị thay vào. Nó có thể tự pass SPF, DKIM và DMARC cho chính nó.

  • Chữ cái từ bảng chữ khácCao

    xn--pypal-4ve.examplehiển thị làpаypal.example

    Chữ а là chữ Kirin. Header giữ dạng xn-- (punycode), và dạng này làm lộ điều đó.

  • Nhà cung cấp của bạn ghi failCao

    compauth=fail reason=001 · spf=softfail

    Bên nhận không gắn được tên miền From với máy chủ đã gửi.

  • Một tên chứa địa chỉ khácTrung bình

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

    Ứng dụng hiển thị tên, không phải địa chỉ. Người gửi thật nằm trong dấu ngoặc.

  • Kết luận của chính bộ lọcTrung bình

    CAT:PHSH · dest:J · SFTY:9.25

    Microsoft xếp nó vào loại phishing và đưa vào Junk; 9.25 là gợi ý liên hệ lần đầu.

  • Kết quả pass nằm dưới đường kẻTrung bình

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

    Nằm dưới mọi dòng Received, nên do người gửi ghi. Chỉ kết quả của nhà cung cấp của bạn mới được tính.

Bình thường, tự chúng không phải dấu hiệu đáng ngờ

  • Return-Path khác From

    sendgrid.netso vớiexample.org

    Các dịch vụ email gửi thay bạn; DKIM đảm nhiệm việc khớp.

  • Reply-To khác From

    Reply-To: support@example.org

    Thư trả lời gửi tới bộ phận hỗ trợ. Chỉ đáng xem xét nếu tên miền đó giả dạng một tên miền khác.

  • Thời gian chạy ngược

    09:47:12 → 09:47:11 (−1 giây)

    Mỗi máy chủ đóng dấu theo đồng hồ của mình, và đồng hồ có thể lệch nhau một giây hoặc hơn.

  • Một máy chủ ở quốc gia khác

    CTRY:US · 209.85.208.54

    Đó là nơi đặt máy chủ, không phải nơi người gửi ở. Các nhà cung cấp lớn gửi từ khắp nơi.

Các dấu hiệu từ mẫu đáng ngờ và các biến thể tự tạo. Tự thân không dấu hiệu nào chứng minh được phishing.

Vì sao email của tôi bị chậm?

Lấy từng thời gian Received trừ đi thời gian của dòng ngay phía trên nó, theo UTC. Khoảng cách lớn nhất cho thấy email đã chờ ở đâu. Khoảng cách từ 30 phút trở lên phù hợp với một lần gửi lại (RFC 5321 gợi ý chờ ít nhất 30 phút).

Header Date lấy từ thiết bị của người gửi, nên khoảng thời gian từ Date đến máy chủ đầu tiên bao gồm cả đồng hồ chạy chậm hoặc một bản nháp được viết từ rất lâu trước khi gửi. Thời gian cũng có thể lùi lại một giây khi đồng hồ của hai máy chủ lệch nhau.

Không có tiêu chuẩn nào quy định bao lâu là quá lâu.

Mẫu đáng ngờthời gian theo UTC
Header Date09:05:44 UTC
+7 giây
mail.paypa1-billing.example09:05:51 · máy chủ đầu tiên
41 phút 21 giây≥ 30 phút: gửi lại

Microsoft 365

  • 09:47:12edge, dòng đầu tiên
  • 09:47:11nội bộ · −1 giây
  • 09:47:13máy chủ hộp thư
  1. 09:05:44Header Dateđồng hồ của người gửi
  2. +7 giây
  3. 09:05:51mail.paypa1-billing.examplemáy chủ đầu tiên
  4. 41 phút 21 giây≥ 30 phút: phù hợp với một lần gửi lại
  5. 09:47:12máy chủ edge của Microsoft 365dòng đầu tiên Microsoft ghi
  6. −1 giâyđồng hồ lệch nhau
  7. 09:47:11Microsoft nội bộ
  8. +2 giây
  9. 09:47:13máy chủ hộp thư Microsoft
tính từ header Date
41 phút 29 giây
tính từ máy chủ đầu tiên
41 phút 22 giây
Mẫu bản tin · 44 giâythời gian đã trôi qua ở đâu
  • Date → máy chủ đầu tiên 6 giây
  • vào SendGrid 2,9 giây
  • bộ lọc SendGrid 0,6 giây
  • SendGrid → Google, khoảng cách lớn nhất 33 giây
  • bên trong Google 1 giây

Giải mã header spam của Microsoft 365 và Gmail

Microsoft 365 ghi kết luận của bộ lọc vào X-Forefront-Antispam-Report: CAT là kết luận, SFV là cách bộ lọc spam phán quyết, còn X-Microsoft-Antispam-Mailbox-Delivery cho biết email đã vào thư mục nào.

SCL vẫn được ghi, nhưng Microsoft nói nó không còn quyết định gì trong Microsoft 365: hãy đọc CAT thay thế (Microsoft). BCL đánh giá thư hàng loạt theo số khiếu nại từ 0 đến 9, và ngưỡng trong chính sách của bạn (mặc định là 7) sẽ quyết định.

Gmail không ghi kết luận spam nào có tài liệu. Các máy chủ chạy SpamAssassin thêm X-Spam-Status kèm điểm số, ngưỡng và các quy tắc đã kích hoạt.

X-Forefront-Antispam-Reportmẫu đáng ngờ
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 kết luận: phishing (SPM spam, SPOOF, BULK, HPHSH…)
  2. 2SFV:SPM bộ lọc spam đánh dấu là spam (NSPM: không phải spam)
  3. 3SCL:5 một đầu vào cho việc lọc, không phải quyết định trong Microsoft 365
  4. 4SFTY:9.25 gợi ý an toàn về liên hệ lần đầu đã được hiển thị
  5. 5IPV:NLI IP không nằm trong danh sách uy tín nào
  6. 6DIR:INB hướng đến; SFS và ARA là chẩn đoán nội bộ của Microsoft

Mức khiếu nại thư hàng loạtBCL:0

01–3 ít4–7 trung bình8–9 nhiều

Ngưỡng 5 strict, 6 standard, 7 mặc định: bằng hoặc cao hơn là thư hàng loạt.

Nó đã đi đâudest:J

Junk EmailX-Microsoft-Antispam-Mailbox-Delivery

dest:I là inbox. ucf, jmr và ENG là nội bộ.

Gmail và SpamAssassin

Gmail không ghi kết luận spam nào có tài liệu: X-Received, X-Google-Smtp-Source và X-Gm-* là nội bộ.

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

SpamAssassin: chỉ là spam khi bằng hoặc cao hơn điểm yêu cầu.

Mọi giá trị từ mẫu đáng ngờ, đọc theo các bảng header chống spam của Microsoft.

Cách xem header email trong Gmail, Outlook, Apple Mail và các ứng dụng khác

Hãy sao chép toàn bộ header, hoặc cả email gốc, từ máy tính hoặc trình duyệt web. Sau đó dán chúng vào ô phía trên, hoặc lưu email thành tệp .eml rồi tải lên.

Mỗi ứng dụng giấu chúng trong một menu khác nhau. Hãy chọn ứng dụng của bạn: các bước dựa theo trang trợ giúp của chính từng nhà cung cấp.

  1. 1Mở thư
  2. 2Tuỳ chọn khác ⋮
  3. 3Hiện thư gốc
  4. 4Sao chép vào khay nhớ tạm

Nguồn: support.google.com/mail/answer/29436

Đang dùng điện thoại? Các ứng dụng Gmail, Outlook và Apple Mail không hiển thị đầy đủ header. Hãy mở email trên trình duyệt (Gmail, Outlook trên web) hoặc ứng dụng máy tính, hoặc chuyển tiếp email dưới dạng tệp đính kèm rồi tải lên tệp .eml tại đây.

Cách truy vết email, và một IP cho bạn biết gì và không cho biết gì

Để truy vết email, hãy lấy địa chỉ from trong dòng Received đầu tiên do nhà cung cấp của bạn ghi: đó là máy chủ đã giao email cho nhà cung cấp. Tra cứu chủ sở hữu của nó là bạn biết đó là máy chủ của ai, và đó có thể là một bên chuyển tiếp chứ không phải người gửi ban đầu.

Header cho thấy các máy chủ email, và chỉ đôi khi cho thấy mạng của chính người gửi, trong X-Originating-IP.

Ngay cả địa chỉ đó cũng chỉ tới một mạng và đại khái một quốc gia, không bao giờ chỉ tới một người hay một con phố.

Mẫu Gmail → Outlooktra cứu từ trình duyệt của bạn
Máy tính của Anakhông có trong header
209.85.208.54mail-ed1-f54.google.com
Microsoft 365dòng Received đầu tiên mà nó ghi

209.85.208.54 cho bạn biết gì

Chủ sở hữu
Google LLC · 209.85.128.0/17 (ARIN)
Quốc gia
Hoa Kỳ, nơi đặt máy chủ
Vai trò
một máy chủ gửi của Gmail, chính là máy chủ mà SPF đã kiểm tra

Nó không cho bạn biết gì

Ai
Ana, hoặc bất kỳ ai khác ở example.net
Ở đâu
thành phố hay con phố của cô ấy
Thiết bị
máy tính hay điện thoại của cô ấy
Công cụ phân tích chỉ tra cứu địa chỉ công cộng của các máy chủ, tại registry của chúng, và hiển thị chính xác những gì nó đã hỏi.

Email header: câu hỏi và trả lời

Làm sao để phân tích email header?

Sao chép toàn bộ header từ ứng dụng email của bạn, dán vào ô phía trên rồi chọn Phân tích header. Phần phân tích email header sẽ đọc chúng từ dưới lên trên: kết luận do nhà cung cấp của bạn ghi, đường đi qua từng máy chủ kèm độ trễ ở mỗi chặng, và các phát hiện kèm bằng chứng.

Dán email header vào đây có an toàn không?

Header được đọc ngay trong trình duyệt của bạn và không bao giờ gửi cho chúng tôi. Chỉ IP công cộng của máy chủ được tra cứu: chủ sở hữu của chúng tại các registry (RDAP, do trình duyệt của bạn truy vấn) và quốc gia của chúng từ các tệp DB-IP lấy từ chính trang của chúng tôi, nên máy chủ của chúng tôi biết dải địa chỉ nào đã được hỏi. Tên miền của người gửi chỉ được tra cứu tại dns.google nếu bạn yêu cầu. Header có chứa địa chỉ và tên máy chủ, nên hãy chia sẻ cẩn thận.

Email header có thể bị giả mạo không?

Có: mọi thứ được ghi trước khi nhà cung cấp của bạn nhận email. Mỗi máy chủ thêm dòng của mình lên trên cùng, nên người gửi có thể đặt các dòng Received giả ở bên dưới và thậm chí cả Authentication-Results giả báo pass. Các dòng của chính nhà cung cấp của bạn ở trên cùng, cùng kết quả nó ghi bên cạnh, là phần bạn có thể tin; analyzer hiển thị phần còn lại như các tuyên bố.

Làm sao biết một email có phải là giả không?

Hãy bắt đầu với Authentication-Results của nhà cung cấp của bạn: một kết quả DMARC fail, hoặc compauth fail trong Microsoft 365, nghĩa là tên miền From chưa được xác nhận. Sau đó đọc chính tên miền: một tên miền nhái như paypa1-billing.example có thể tự pass mọi kiểm tra cho chính nó. Cuối cùng, xem thư trả lời được gửi đến đâu và máy chủ nào đã giao email; analyzer liệt kê từng phát hiện kèm bằng chứng.

Có xem được địa chỉ IP của người gửi qua header email không?

Bạn tìm được máy chủ đã giao email cho nhà cung cấp của bạn: địa chỉ from trong dòng Received đầu tiên của nhà cung cấp, chính là địa chỉ mà SPF đã kiểm tra. Đó thường là một máy chủ email, không phải máy tính của người đó. Một số nhà cung cấp còn thêm X-Originating-IP, thường là thiết bị hoặc mạng của người gửi, và ngay cả địa chỉ đó cũng chỉ trỏ tới một mạng và đại khái một quốc gia, không bao giờ tới một con người.

Vì sao Gmail không hiển thị địa chỉ IP của người gửi?

Email gửi từ web và ứng dụng Gmail thường chỉ mang các máy chủ của Google: dòng Received đầu tiên không có phần from, nên địa chỉ của chính người gửi không có trong header. Địa chỉ bạn nhìn thấy thuộc về máy chủ Google đã chuyển tiếp email, chính là địa chỉ mà SPF đã kiểm tra, nên tra cứu sẽ cho thấy Google là chủ sở hữu, không phải mạng của người gửi.

SPF đã pass, vậy sao DMARC lại fail?

SPF kiểm tra tên miền envelope (Return-Path), có thể khác với From mà bạn thấy. DMARC cần SPF hoặc DKIM pass với một tên miền khớp với From, khớp chính xác hoặc trong cùng một tổ chức; nếu tên miền đã pass là của người khác, chẳng hạn tên miền bounce của một dịch vụ email, DMARC sẽ fail. Chữ ký DKIM của chính tên miền From tự nó đã đủ để pass DMARC.

Độ trễ âm giữa các chặng nghĩa là gì?

Một máy chủ phía sau đã đóng dấu thời gian sớm hơn máy chủ trước nó. Mỗi máy chủ ghi thời gian theo đồng hồ của riêng mình, và các đồng hồ đó có thể lệch nhau, nên analyzer hiển thị độ lệch đồng hồ chứ không phải độ trễ. Thời gian ở các dòng bên dưới những dòng do nhà cung cấp của bạn ghi cũng có thể bị làm giả, nên hãy coi thứ tự và khoảng cách của chúng là các tuyên bố.

SCL và BCL nghĩa là gì?

Cả hai đều là điểm số của Microsoft 365 trong các header chống thư rác của nó. BCL đánh giá thư hàng loạt theo mức khiếu nại, từ 0 (không phải từ người gửi hàng loạt) đến 9. SCL vẫn được ghi, nhưng trong Microsoft 365 nó là một đầu vào cho việc lọc chứ không phải quyết định: CAT mang kết luận, và SFV cho biết bộ lọc thư rác đã xử lý email như thế nào.

Email header có hiển thị người nhận BCC không?

Không. Bản sao ẩn không bao giờ được ghi vào header: máy chủ gửi chuyển chúng từ envelope, còn các dòng To và Cc chỉ hiển thị những người nhận nhìn thấy được. Mệnh đề for trong một dòng Received có thể nêu tên một người nhận, vì vậy các máy chủ được khuyến cáo dùng nó thận trọng. Delivered-To cũng có thể cho biết hộp thư mà email đã tới.

Công cụ này có giống Message Header Analyzer của Microsoft không?

Không. Message Header Analyzer của Microsoft là một add-in Outlook và một trang web giải mã header của một email. Công cụ này đọc cùng các header của Microsoft, cộng với của Gmail, của SpamAssassin và dấu vết của từng chặng, quyết định tin kết quả nào dựa vào vị trí của nó, và chạy hoàn toàn trong trình duyệt của bạn.

Vì sao có nhiều header Authentication-Results?

Mọi máy chủ kiểm tra email đều có thể thêm một header, và người gửi có thể thêm header giả, nên một email thường mang nhiều header. Chỉ header do nhà cung cấp của bạn ghi mới được tính: ở trên cùng, cạnh dòng Received của chính nó, nêu tên máy chủ của chính nó. ARC-Authentication-Results là các kết quả được bên chuyển tiếp niêm phong, để máy chủ kế tiếp thấy được điều gì đã pass trước khi việc chuyển tiếp làm thay đổi email.

Còn thiếu điều gì?Đề xuất tính năng hoặc công cụ mới

Thêm công cụ email