Cara Membaca Header yang Diterima dan Melacak Jalur Pengiriman Email

Sebuah email dapat melewati server aplikasi, relai keluar, layanan pemfilteran, dan penukar surat penerima sebelum mencapai kotak masuk. Setiap server SMTP penerima biasanya menambahkan bidang Received. Membaca kolom tersebut dapat membantu menemukan penundaan, mengidentifikasi server yang mengirimkan email ke penyedia Anda, dan membuat jadwal pengiriman.

Lahan tersebut merupakan bukti diagnostik, bukan lacak balak yang lengkap. Pengirim dapat menambahkan saluran palsu sebelum transmisi, jam bisa berbeda dan infrastruktur swasta mungkin menyembunyikan atau menulis ulang rinciannya. Gunakan pelacakan bersama dengan log penyedia, hasil autentikasi, dan konteks pesan.

Catatan lapangan yang Diterima

RFC 5321 bagian 4.4 memerlukan server SMTP yang menerima pesan untuk pengiriman atau pemrosesan lebih lanjut untuk menambahkan informasi jejak. Bidang tipikal terlihat seperti ini:

Received: from outbound.example.com (outbound.example.com [192.0.2.10])
        by mx.example.net with ESMTPS id ABC123
        for <[email protected]>;
        Mon, 03 Aug 2026 10:30:04 +0000

Klausa umum menjawab pertanyaan yang berbeda:

• from menjelaskan host yang disajikan oleh pihak pengirim dan mungkin menyertakan alamat yang diamati pada koneksi jaringan;
• by mengidentifikasi server yang menerima hop ini dan menulis kolomnya;
• with menjelaskan varian transport atau protokol, seperti ESMTP atau SMTP terenkripsi;
• id adalah antrian atau pengidentifikasi transaksi yang berguna ketika administrator dapat mencari log server tersebut;
• for dapat mengidentifikasi satu penerima amplop, meskipun bersifat opsional dan dapat dihapus demi privasi;
• tanggal setelah catatan titik koma ketika server penerima menerima pesan, termasuk offset zona waktu numerik.

Tidak setiap bidang berisi setiap klausa. Gateway dan sistem non-SMTP dapat menghasilkan format yang asing. RFC 5321 secara eksplisit memberi tahu sistem penerima untuk menjadi kuat dengan format jejak yang tidak terduga daripada menolak pesan hanya karena garis jejak terlihat tidak biasa.

Baca rute dari bawah ke atas

Server SMTP menambahkan kolom Received baru di atas kolom yang sudah ada. Oleh karena itu, hop penerima terbaru berada di bagian atas blok header; lompatan paling awal yang tercatat biasanya berada di bagian bawah.

Pertimbangkan jejak yang disederhanakan ini:

Received: from filter.example.net by mx.recipient.example;
        Mon, 03 Aug 2026 10:30:07 +0000
Received: from outbound.sender.example by filter.example.net;
        Mon, 03 Aug 2026 10:30:04 +0000
Received: from app.internal.example by outbound.sender.example;
        Mon, 03 Aug 2026 10:29:59 +0000

Bacalah sebagai:

1. app.internal.example menyerahkan pesan kepada outbound.sender.example.
2. Server keluar menyerahkannya ke filter.example.net.
3. Filter menyerahkannya ke server mx.recipient.example penerima.

Jangan mengurutkan bidang berdasarkan stempel waktunya yang terlihat. Urutan bidang yang ditentukan protokol lebih berguna karena jam server mungkin salah atau tidak tersinkronisasi. Ubah setiap stempel waktu menjadi satu zona waktu hanya saat memperkirakan penundaan, dan pertahankan nilai aslinya dalam catatan bukti apa pun.

Hitung penundaan dengan cermat

Untuk setiap pasangan yang berdekatan, kurangi waktu penerimaan sebelumnya dari waktu penerimaan berikutnya setelah menerapkan offset numerik. Celah positif yang besar dapat mengindikasikan antrian, pembatasan laju, kegagalan jaringan sementara, atau pemrosesan pada layanan berikutnya. Itu tidak mengidentifikasi penyebabnya dengan sendirinya.

Kesenjangan negatif biasanya menunjukkan ketidaksejajaran jam, kesalahan penguraian, atau bidang yang tidak dipercaya—bukan perjalanan waktu dan bukan bukti pemalsuan otomatis. Periksa apakah offset ditangani dengan benar dan apakah kedua baris tersebut ditulis oleh sistem yang Anda kendalikan.

Saat menyelidiki aplikasi Anda sendiri, hubungkan jejaknya dengan:

• waktu UTC saat aplikasi meminta pesan;
• ID antrian pengirim dan log pengiriman;
• bidang Received pertama yang ditulis oleh infrastruktur yang Anda percayai;
• waktu penyedia penerima melaporkan menerima atau menampilkannya;
• status percobaan ulang atau respons SMTP apa pun yang direkam oleh sistem pengirim.

Daftar periksa pengujian email pengembang menjelaskan cara mencatat garis waktu permintaan hingga kedatangan tanpa memperlakukan satu pengamatan kotak masuk sebagai keseluruhan sistem pengiriman.

Putuskan hop mana yang dapat Anda percayai

Bidang Received paling atas ditambahkan oleh server yang paling dekat dengan kotak surat yang Anda lihat. Jika penyedia kotak surat tersebut tepercaya, bidang ini biasanya merupakan titik awal yang paling kuat: bidang ini dapat melaporkan alamat jaringan asal penyedia sebenarnya menerima pesan tersebut.

Lakukan pekerjaan ke bawah hanya sejauh bidang tersebut tetap konsisten dengan infrastruktur yang Anda kenali. Garis yang diduga dibuat sebelum pesan masuk ke penyedia tepercaya dapat dibuat oleh pengirim. Pengirim yang jahat biasanya tidak dapat menulis ulang kolom yang telah ditambahkan kemudian oleh sistem penerima, namun ia dapat menempatkan teks jejak yang tampak masuk akal dalam pesan sebelum sistem tersebut melihatnya.

Nama host juga memerlukan konteks. Nama from mungkin berasal dari salam SMTP, DNS terbalik, atau konfigurasi lokal. Alamat pribadi seperti 10.0.0.0/8 dapat menggambarkan hop internal tetapi tidak dapat dilacak secara langsung di Internet publik. Hasil geolokasi IP merupakan perkiraan dan tidak menetapkan identitas atau lokasi fisik penulis.

Bidang yang diterima tidak menggantikan autentikasi

Bidang Received menjelaskan lompatan transportasi. SPF, DKIM, dan DMARC mengevaluasi berbagai bukti tentang otorisasi, tanda tangan, dan penyelarasan domain. Rute yang terlihat biasa saja dapat membawa pesan berbahaya, dan pesan yang diteruskan secara sah dapat memiliki rute yang rumit.

Gunakan panduan SPF, DKIM dan DMARC untuk menafsirkan hasil autentikasi secara terpisah. Jangan menyimpulkan bahwa alamat From yang terlihat mengendalikan setiap host di rute, atau bahwa relai yang familiar membuat konten aman.

Gunakan penganalisis header lokal tanpa berbagi secara berlebihan

Once Email penganalisis header email mengekstrak hop Received, hasil autentikasi, dan bidang berulang di browser. Tempelkan kolom header saja—tidak pernah sandi, kode verifikasi, isi pesan, atau lampiran. Alat ini tidak menghubungi server yang terdaftar, memverifikasi log mereka atau membuktikan bahwa suatu bidang asli.

Sebelum membagikan hasil, ganti alamat pribadi, alamat IP publik, ID antrean, dan nama host internal sambil tetap mempertahankan urutan dan waktu yang diperlukan untuk mereproduksi masalah. Panduan redaksi bukti uji memberikan pola pelaporan yang lebih aman.

Daftar periksa interpretasi yang andal

Mulailah dari atas untuk mengidentifikasi sistem penerima akhir, kemudian rekonstruksi jalur dari bawah ke atas. Percayai urutan lapangan sebelum jam. Normalisasikan zona waktu, tandai interval negatif atau sangat panjang, dan tandai batas antara infrastruktur tepercaya dan infrastruktur yang dikontrol pengirim. Hubungkan ID antrean dengan log server resmi bila tersedia.

Yang terpenting, sebutkan limit kesimpulannya. Pelacakan mungkin mendukung “penyedia penerima menerima koneksi ini dari relai ini saat ini.” Biasanya tidak dapat membuktikan siapa yang menulis pesan tersebut, apakah setiap lompatan sebelumnya adalah asli atau apakah tautan dan lampirannya aman.