Alat populer

Tema

Analisis Header Email

Header analyzer ini membantu analisis header email: tempel header sebuah email untuk melihat jalur yang dilalui pesan, berapa lama setiap hop, dan apa kata pengecekan SPF, DKIM, dan DMARC dari penyedia email Anda.

Dibaca di browser Anda · hanya IP server publik yang dicari, dan domain pengirim jika Anda memintanya · tidak ada yang disimpan

Header Anda tidak pernah meninggalkan perangkat Anda. Hanya alamat IP dan domain yang tercantum di bawah hasil yang dicari.

Yang akan Anda lihat

  • Siapa yang benar-benar mengirimnya, dinilai hanya dari pengecekan penyedia Anda sendiri
  • Setiap server di jalurnya, delay di masing-masing, dan apakah memakai TLS
  • SPF, DKIM, DMARC, dan ARC, dan apakah cocok dengan alamat From
  • Domain tiruan, hasil palsu, dan tanda lain, masing-masing disertai buktinya
  • Header spam Microsoft 365, Gmail, dan SpamAssassin, sudah didekode
  • Aturan bulk sender Gmail dan Yahoo, termasuk unsubscribe satu klik

Header email adalah apa, dan apa isinya?

Header email adalah blok baris di atas teks pesan: siapa pengirim dan penerimanya, kapan dikirim, dan catatan dari setiap server yang menanganinya. Aplikasi email menyembunyikan sebagian besarnya; “Show original” atau “View source” menampilkan semuanya.

Setiap baris terdiri dari nama, titik dua, dan nilai; nilai yang panjang dilanjutkan di baris yang diawali spasi (RFC 5322). Header berakhir di baris kosong pertama. Semua setelahnya adalah isi pesan, yang tidak pernah dibaca alat ini.

Tiga pihak yang menulisnya: aplikasi pengirim (From, To, Subject, Date), setiap server di tengah jalur (satu baris Received masing-masing), dan penyedia Anda (Authentication-Results, verdict spam). Hanya yang terakhir yang dicek oleh pihak yang Anda percaya.

Contoh newsletter30 field header · 4,6 KB

Ditambahkan oleh penyedia Anda (Google)11 field

  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 …

Ditambahkan oleh server di tengah jalur (SendGrid, example.org)5 field

  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

Ditulis oleh aplikasi pengirim14 field

  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

baris kosong: isi pesan dimulai di sini, dan alat ini tidak pernah membacanya

Diringkas: satu baris per field, bernomor seperti di header. Warna sama seperti di hasil: penyedia Anda, server di tengah jalur, pengirim.
Hasil analisis header email untuk pesan PayPal tiruan: verdict, temuan, dan jalur pengiriman dengan jeda 41 menitHasil analisis header email untuk pesan PayPal tiruan: verdict, temuan, dan jalur pengiriman dengan jeda 41 menitVerdictSiapa pengirimnya, dinilai hanya dari Authentication-Results yang ditulis penyedia Anda, beserta server yang mengeceknya.Yang menonjolSetiap temuan beserta tingkat keparahan, alasan, dan baris header persisnya.Jalur pengirimanSetiap server dari header Date sampai inbox, jeda digambar sesuai skala, dan batas kepercayaan melintasinya.FaktaBerapa lama pengiriman, berapa hop, apakah setiap hop eksternal memakai TLS, dan folder mana yang dipilih Microsoft.
Contoh mencurigakan: pengecekan Microsoft 365 sendiri tidak mengonfirmasi pengirimnya, temuan menyebutkan buktinya, dan jalurnya menunjukkan di mana pesan menunggu. Pilih sebuah nomor untuk melihat arti setiap bagian.

Cara analisis header email: baca dari bawah ke atas

Untuk menganalisis header email, baca baris Received dari bawah ke atas. Setiap server menambahkan barisnya di atas baris yang sudah ada, jadi yang paling bawah adalah hop pertama dan yang paling atas adalah penyedia Anda menyerahkan pesan ke mailbox (RFC 5321 §4.4).

Sebuah baris menyebutkan siapa yang menerima (by), dari server dan alamat mana (from, alamat yang terlihat pada koneksi), bagaimana (with: ESMTPS berarti STARTTLS, ESMTPSA berarti STARTTLS plus login), dan kapan. Server menstempel waktu lokalnya sendiri, jadi ubah masing-masing ke UTC sebelum mengurangkan: 07:02:47 -0700 adalah 14:02:47 UTC.

Hanya baris yang ditulis penyedia Anda yang pasti. Semua di bawah baris pertamanya berasal dari server yang tidak bisa Anda cek, dan pengirim bisa menambahkan barisnya sendiri.

Di header · atas adalah yang terbaru

Perjalanannya · hop 1 lebih dulu

#2 by 2002:a05:6214:5a0b:…with SMTP id kq11csp…07:02:48 -0700
5internal Google14:02:48 UTC+1 dtk
#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 dtk

Batas kepercayaan

#14 by filterdrecv-7d9c8b5f6-2kqzrwith SMTP id filterd…2026-10-21 14:02:13.517 +0000 UTC
3filter SendGrid14:02:13 UTC+0,6 dtk
#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 dtk
#16 from localhost [127.0.0.1]by app-01.example.org (Postfix) with ESMTP14:02:10 +0000
1app-01.example.org14:02:10 UTCpertama

Baca ke atas: setiap server menambahkan barisnya di bagian atas

Lima baris Received milik newsletter. Hop 1 adalah aplikasi newsletter; jeda 33 dtk antara SendGrid dan Google adalah yang terbesar.

SPF, DKIM, dan DMARC di header email

SPF menanyakan apakah server pengirim boleh mengirim untuk domain envelope (Return-Path). DKIM menanyakan apakah sebuah domain menandatangani pesan dan tanda tangannya masih cocok. DMARC menanyakan apakah domain SPF atau DKIM yang pass cocok dengan alamat From yang Anda lihat.

Penyedia Anda menulis jawabannya ke Authentication-Results. Percayai blok yang ditulis penyedia Anda di samping baris Received miliknya sendiri. Salinan lain, salinan ARC, dan yang berada di antara baris pengirim bisa ditambahkan oleh siapa saja (RFC 8601).

Pass membuktikan domainnya, bukan niatnya: examp1e.com bisa lolos ketiganya untuk dirinya sendiri.

Authentication-Results, dibedahnewsletter · lalu contoh yang mencurigakan
Authentication-Results: mx.google.com;1

Siapa yang mengecekauthserv-id: server milik penyedia Anda sendiri

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

DKIM: example.org menandatanganinyakuncinya ada di s1._domainkey.example.org

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

Tanda tangan keduamilik layanan pengirim sendiri; tidak bisa selaras dengan example.org

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

SPF: diizinkan mengirim untuk sendgrid.netdomain envelope (Return-Path), bukan From

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

DMARC: domain From cocok dengan ②p=quarantine adalah yang diminta example.org kepada penerima untuk menangani kegagalan

#3 Authentication-Results: spf=softfail (sender IP is 198.51.100.77) … dkim=none … dmarc=none action=none … compauth=fail reason=001DihitungMicrosoft 365 menulisnya, di atas baris Received pertama yang ditambahkannya.

Batas kepercayaan

#7 Authentication-Results: protection.outlook.com; spf=pass … dkim=pass … dmarc=pass action=none … compauth=pass reason=100DiabaikanBlok ini menyebut Microsoft tetapi berada di bawah semua baris Received: ia datang di dalam pesan. Penerima tidak pernah menulis di sana.
Di bawah garis: dua Authentication-Results milik contoh yang mencurigakan. Posisi menentukan mana yang dihitung.

Apakah email ini asli atau spoofed?

Header tidak bisa memberi tahu apakah sebuah tawaran jujur, tetapi header menunjukkan apakah domain From benar-benar mengirimnya dan apakah domain itu menirukan milik orang lain. Mulailah dari verdict yang ditulis penyedia Anda, lalu cari tanda-tanda ini.

Tidak ada satu pun yang membuktikan phishing dengan sendirinya, dan beberapa perbedaan yang umum itu wajar. Microsoft mencatat bahwa domain tiruan bisa lolos SPF, DKIM, dan DMARC jika pemiliknya mengaturnya (Microsoft).

  • Domain From yang menirukanTinggi

    paypa1-billing.examplevspaypal.com

    Satu angka atau huruf serupa ditukar. Domain itu bisa lolos SPF, DKIM, dan DMARC untuk dirinya sendiri.

  • Huruf dari alfabet lainTinggi

    xn--pypal-4ve.exampletampil sebagaipаypal.example

    Huruf а itu Sirilik. Header menyimpan bentuk xn-- (punycode), yang membongkarnya.

  • Penyedia Anda menyatakan failTinggi

    compauth=fail reason=001 · spf=softfail

    Penerima tidak bisa mengaitkan domain From dengan server yang mengirimnya.

  • Nama yang memuat alamat lainSedang

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

    Aplikasi menampilkan nama, bukan alamatnya. Pengirim sebenarnya ada di dalam tanda kurung.

  • Verdict filter sendiriSedang

    CAT:PHSH · dest:J · SFTY:9.25

    Microsoft mengklasifikasikannya sebagai phishing dan memasukkannya ke Junk; 9.25 adalah tips kontak pertama.

  • Hasil pass di bawah garisSedang

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

    Ditulis di bawah semua baris Received, jadi pengirimlah yang menulisnya. Hanya milik penyedia Anda yang dihitung.

Wajar, bukan tanda bahaya dengan sendirinya

  • Return-Path berbeda dari From

    sendgrid.netvsexample.org

    Layanan email mengirim untuk Anda; DKIM yang membawa kecocokannya.

  • Reply-To berbeda dari From

    Reply-To: support@example.org

    Balasan masuk ke help desk. Layak dilihat hanya jika domain itu menirukan domain lain.

  • Waktu yang berjalan mundur

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

    Setiap server menstempel jamnya sendiri, dan jam bisa berselisih satu detik atau lebih.

  • Server di negara lain

    CTRY:US · 209.85.208.54

    Itu lokasi servernya, bukan orangnya. Penyedia besar mengirim dari mana-mana.

Tanda-tanda dari contoh yang mencurigakan dan varian rekaan. Tidak ada yang membuktikan phishing dengan sendirinya.

Mengapa email saya tertunda?

Kurangkan setiap waktu Received dari waktu di atasnya, dalam UTC. Jeda terbesar menunjukkan di mana pesan menunggu. Jeda 30 menit atau lebih sesuai dengan percobaan ulang (RFC 5321 menyarankan menunggu setidaknya 30 menit).

Header Date berasal dari perangkat pengirim, jadi waktu dari Date sampai server pertama mencakup jam yang lambat atau draf yang ditulis jauh sebelum dikirim. Waktu juga bisa mundur satu detik saat jam dua server berbeda.

Tidak ada standar yang menyebutkan berapa lama yang terlalu lama.

Contoh yang mencurigakanwaktu dalam UTC
Header Date09:05:44 UTC
+7 dtk
mail.paypa1-billing.example09:05:51 · server pertama
41 mnt 21 dtk≥ 30 mnt: percobaan ulang

Microsoft 365

  • 09:47:12edge, baris pertama
  • 09:47:11internal (dalam) · −1 dtk
  • 09:47:13server mailbox
  1. 09:05:44Header Datejam pengirim
  2. +7 dtk
  3. 09:05:51mail.paypa1-billing.exampleserver pertama
  4. 41 mnt 21 dtk≥ 30 mnt: sesuai dengan percobaan ulang
  5. 09:47:12edge Microsoft 365baris pertama yang ditulis Microsoft
  6. −1 dtkjam berbeda
  7. 09:47:11internal Microsoft
  8. +2 dtk
  9. 09:47:13server mailbox Microsoft
dari header Date
41 mnt 29 dtk
dari server pertama
41 mnt 22 dtk
Contoh newsletter · 44 dtkke mana waktu terpakai
  • Date → server pertama 6 dtk
  • masuk ke SendGrid 2,9 dtk
  • filter SendGrid 0,6 dtk
  • SendGrid → Google, jeda terbesar 33 dtk
  • di dalam Google 1 dtk

Header spam Microsoft 365 dan Gmail, didekode

Microsoft 365 menulis verdict filternya ke X-Forefront-Antispam-Report: CAT adalah verdict-nya, SFV bagaimana pemfilteran spam memutuskan, dan X-Microsoft-Antispam-Mailbox-Delivery menyebutkan folder tujuannya.

SCL masih ditulis, tetapi Microsoft menyatakan nilainya tidak lagi menentukan apa pun di Microsoft 365: baca CAT sebagai gantinya (Microsoft). BCL menilai email bulk berdasarkan keluhan dari 0 sampai 9, dan ambang batas kebijakan Anda (7 secara default) yang menentukan.

Gmail tidak menulis verdict spam yang terdokumentasi. Server yang menjalankan SpamAssassin menambahkan X-Spam-Status berisi skor, ambang batas, dan aturan yang terpicu.

X-Forefront-Antispam-Reportcontoh yang mencurigakan
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 verdict-nya: phishing (SPM spam, SPOOF, BULK, HPHSH…)
  2. 2SFV:SPM pemfilteran spam menandainya sebagai spam (NSPM: bukan spam)
  3. 3SCL:5 masukan untuk pemfilteran, bukan keputusan di Microsoft 365
  4. 4SFTY:9.25 tips keamanan kontak pertama ditampilkan
  5. 5IPV:NLI IP tidak ada di daftar reputasi mana pun
  6. 6DIR:INB masuk; SFS dan ARA adalah diagnostik internal Microsoft

Tingkat keluhan email massalBCL:0

01–3 sedikit4–7 campuran8–9 banyak

Ambang batas 5 strict, 6 standard, 7 default: pada atau di atasnya, dianggap bulk.

Ke mana perginyadest:J

Junk EmailX-Microsoft-Antispam-Mailbox-Delivery

dest:I adalah inbox. ucf, jmr, dan ENG bersifat internal.

Gmail dan SpamAssassin

Gmail tidak menulis verdict spam yang terdokumentasi: X-Received, X-Google-Smtp-Source, dan X-Gm-* bersifat internal.

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

SpamAssassin: spam hanya jika skornya mencapai atau melebihi skor yang dibutuhkan.

Setiap nilai dari contoh yang mencurigakan, dibaca dengan tabel header antispam Microsoft.

Cara menemukan header email di Gmail, Outlook, Apple Mail, dan lainnya

Salin header lengkap, atau seluruh pesan aslinya, dari komputer atau browser web. Lalu tempel di atas, atau simpan pesan sebagai file .eml dan unggah.

Setiap aplikasi menyembunyikannya di menu yang berbeda. Pilih aplikasi Anda: langkah-langkahnya mengikuti halaman bantuan resmi tiap penyedia.

  1. 1Buka pesan
  2. 2Lainnya ⋮
  3. 3Tampilkan versi asli
  4. 4Salin ke papan klip

Sumber: support.google.com/mail/answer/29436

Pakai ponsel? Aplikasi Gmail, Outlook, dan Apple Mail tidak menampilkan header lengkap. Buka pesan di browser (Gmail, Outlook di web) atau aplikasi desktop, atau teruskan sebagai lampiran lalu unggah file .eml di sini.

Cara melacak email, dan apa yang bisa dan tidak bisa ditunjukkan sebuah IP

Untuk melacak email, ambil alamat from di baris Received pertama yang ditulis penyedia Anda: server yang menyerahkan pesan. Cari tahu siapa pemiliknya dan Anda tahu server siapa itu, yang bisa jadi forwarder, bukan pengirim aslinya.

Header menampilkan server email, dan hanya kadang-kadang jaringan pengirim sendiri, di X-Originating-IP.

Bahkan alamat itu hanya menunjuk ke sebuah jaringan dan kira-kira sebuah negara, tidak pernah ke seseorang atau sebuah jalan.

Contoh Gmail → Outlookdicari dari browser Anda
Komputer Anatidak ada di header
209.85.208.54mail-ed1-f54.google.com
Microsoft 365baris Received pertama yang ditulisnya

Yang ditunjukkan 209.85.208.54

Pemilik
Google LLC · 209.85.128.0/17 (ARIN)
Negara
Amerika Serikat, tempat server berada
Peran
server pengirim Gmail, yang dicek SPF

Yang tidak bisa ditunjukkannya

Siapa
Ana, atau siapa pun di example.net
Di mana
kota atau jalan tempat tinggalnya
Perangkat
komputer atau ponselnya
Analyzer hanya mencari alamat publik server, di registry-nya, dan menampilkan persis apa yang ditanyakannya.

Header email: tanya jawab

Bagaimana cara analisis header email?

Salin header lengkap dari aplikasi email Anda, tempel di atas, lalu pilih Analisis header. Analisis header email ini membacanya dari bawah ke atas: verdict yang ditulis penyedia Anda, jalur server demi server beserta delay di masing-masing, dan temuan beserta buktinya.

Apa bedanya header analyzer ini dengan Message Header Analyzer milik Microsoft?

Message Header Analyzer milik Microsoft adalah add-in Outlook sekaligus halaman web yang mendekode header sebuah pesan. Header analyzer ini membaca header Microsoft yang sama dan juga milik Gmail, SpamAssassin, serta jejak setiap hop, menentukan hasil mana yang dipercaya berdasarkan posisinya, dan berjalan sepenuhnya di browser Anda.

Amankah menempel header email di sini?

Header dibaca di browser Anda dan tidak pernah dikirim ke kami. Hanya IP server publik yang dicari: pemiliknya di registry (RDAP, ditanyakan oleh browser Anda) dan negaranya dari file DB-IP yang diambil dari situs kami sendiri, jadi server kami melihat rentang alamat mana yang ditanyakan. Domain pengirim dicari di dns.google hanya jika Anda memintanya. Header memang memuat alamat dan nama server, jadi bagikan dengan hati-hati.

Apakah header email bisa dipalsukan?

Ya: semua yang ditulis sebelum penyedia Anda menerima pesan. Setiap server menambahkan barisnya di bagian atas, sehingga pengirim bisa menaruh baris Received palsu di bawah dan bahkan Authentication-Results palsu yang menyatakan pass. Baris milik penyedia Anda di bagian atas, beserta hasil yang ditulisnya di sampingnya, adalah bagian yang bisa Anda percaya; analyzer menampilkan sisanya sebagai klaim.

Bagaimana cara mengetahui sebuah email palsu?

Mulailah dari Authentication-Results penyedia Anda: DMARC fail, atau compauth fail di Microsoft 365, berarti domain From tidak terkonfirmasi. Lalu baca domainnya sendiri: domain tiruan seperti paypa1-billing.example bisa lolos semua pengecekan untuk dirinya sendiri. Terakhir, lihat ke mana balasan dikirim dan server mana yang menyerahkan pesan; analyzer mendaftar setiap temuan beserta buktinya.

Bisakah saya menemukan alamat IP pengirim dari sebuah email?

Anda bisa menemukan server yang menyerahkan pesan ke penyedia Anda: alamat from di baris Received pertama penyedia Anda, yang dicek SPF. Biasanya itu server email, bukan komputer orangnya. Beberapa penyedia juga menambahkan X-Originating-IP, biasanya perangkat atau jaringan pengirim, dan itu pun hanya menunjuk ke sebuah jaringan dan kira-kira sebuah negara, tidak pernah ke seseorang.

Mengapa Gmail tidak menampilkan alamat IP pengirim?

Pesan yang dikirim dari web dan aplikasi Gmail biasanya hanya memuat server Google: baris Received pertama tidak punya bagian from, jadi alamat pengirim sendiri tidak ada di header. Alamat yang bisa Anda lihat milik server Google yang meneruskan pesan, yang dicek SPF, sehingga pencarian menunjukkan Google sebagai pemiliknya, bukan jaringan pengirim.

SPF pass, lalu mengapa DMARC fail?

SPF mengecek domain envelope (Return-Path), yang bisa berbeda dari From yang Anda lihat. DMARC mengharuskan SPF atau DKIM pass untuk domain yang cocok dengan From, persis sama atau dalam organisasi yang sama; jika domain yang pass adalah milik orang lain, seperti domain bounce sebuah layanan email, DMARC fail. Tanda tangan DKIM oleh domain From sudah cukup untuk lolos DMARC.

Apa arti delay negatif antar-hop?

Server yang lebih akhir menstempel waktu yang lebih awal daripada server sebelumnya. Setiap server menulis waktu dari jamnya sendiri, dan jam itu bisa berbeda, jadi analyzer menampilkan selisih jam, bukan delay. Waktu pada baris di bawah yang ditulis penyedia Anda juga bisa dipalsukan, jadi anggap urutan dan jedanya sebagai klaim.

Apa arti SCL dan BCL?

Keduanya adalah skor Microsoft 365 di header anti-spamnya. BCL menilai email bulk berdasarkan tingkat keluhannya, dari 0 (bukan dari pengirim bulk) sampai 9. SCL masih ditulis, tetapi di Microsoft 365 nilainya hanya masukan untuk pemfilteran, bukan keputusan: CAT yang membawa verdict, dan SFV menyatakan bagaimana pemfilteran spam memperlakukan pesan.

Apakah header email menampilkan penerima BCC?

Tidak. Blind copy tidak pernah ditulis ke header: server pengirim mengirimkannya dari envelope, dan baris To serta Cc hanya menampilkan penerima yang terlihat. Klausa for di baris Received bisa menyebut satu penerima, itulah sebabnya server diminta memakainya dengan hati-hati. Delivered-To juga bisa menunjukkan kotak surat yang dituju pesan.

Mengapa ada beberapa header Authentication-Results?

Setiap server yang mengecek pesan bisa menambahkan satu, dan pengirim bisa menambahkan yang palsu, sehingga sebuah pesan sering membawa beberapa. Hanya yang ditulis penyedia Anda yang dihitung: di bagian atas, di samping baris Received miliknya, menyebut servernya sendiri. ARC-Authentication-Results adalah hasil yang disegel oleh peneruskan, supaya server berikutnya bisa melihat apa yang pass sebelum penerusan mengubah pesan.

Ada yang kurang?Usulkan fitur atau alat baru

Alat email lainnya