Pertanyaan yang sering diajukan

echo.email menganalisis satu email per alamat dan menjelaskan hasilnya. Jawaban di bawah ini menjelaskan cara kerja layanan dan arti setiap pemeriksaan dalam laporan.

Bagaimana cara kerja echo.email?

Halaman beranda memberikan alamat baru yang terdiri dari tiga kata, misalnya power.file.tube@echo.email. Pesan yang dikirim ke alamat itu tiba di server email echo.email, yang mencatat percakapan SMTP dan meneruskan pesan untuk dianalisis. Beberapa detik kemudian halaman beralih ke laporan yang mencakup autentikasi, konten, kepatuhan, dan pengiriman. Anda tidak perlu memasang apa pun, dan tidak ada akun.

Berapa lama alamat tetap berlaku?

Alamat tetap aktif selama halaman tetap terbuka. Halaman memeriksa status setiap dua detik. Jika halaman dimuat ulang dalam waktu 10 menit, tab yang sama tetap memakai alamat yang sama. Setelah halaman ditutup lebih dari 10 menit, server email menolak email baru ke alamat itu dengan kesalahan permanen.

Pesan pertama yang tiba yang dipakai. Pesan berikutnya ke alamat yang sama ditolak, sehingga setiap laporan milik tepat satu email. Pesan yang lebih besar dari 10 MB ditolak selama percakapan SMTP.

Berapa lama laporan disimpan?

Setiap laporan, pesan yang disimpan, dan data gambar yang diunduh dihapus otomatis 24 jam setelah pesan tiba. Selama 24 jam itu, link laporan dapat dibuka oleh siapa pun yang memiliki link, dan setelah itu link tidak berfungsi lagi. Contoh laporan adalah satu-satunya pengecualian, karena contoh itu berasal dari pesan tes yang dikirim khusus untuk tujuan tersebut.

Apa yang terjadi pada isi pesan?

echo.email menyimpan seluruh pesan, yaitu header, isi, dan lampiran, bersama detail sesi SMTP seperti alamat IP pengirim, nama HELO, dan versi TLS. Penyimpanan berada di Uni Eropa, dan server email berjalan di Falkenstein, Jerman. Siapa pun yang memiliki link laporan dapat melihat pesan lengkap, jadi pesan tes paling cocok berisi konten yang aman untuk dibagikan. Newsletter sering membawa link pelacakan dan link berhenti berlangganan yang terikat pada satu penerima, dan salinan yang dikirim ke daftar tes menjaga link tersebut tetap privat.

Dua alamat langsung terhubung ke operator: contact@echo.email untuk pertanyaan dan laporan, dan privacy@echo.email untuk permintaan terkait data. Kebijakan privasi berisi detail lengkapnya.

Apa yang diuji oleh pemeriksaan SPF?

SPF mencantumkan server yang diizinkan mengirim email atas nama sebuah domain di return path. echo.email mengambil domain dari pengirim amplop (alamat MAIL FROM, yang juga disebut return path) dan mengevaluasi record SPF domain itu terhadap alamat IP server yang mengirimkan pesan. Hanya pass yang dihitung sebagai hasil baik. Softfail, neutral, dan none membuat server penerima tidak memiliki bukti SPF tentang pengirim.

echo.email tidak memeriksa nama HELO. Penyedia kotak surat besar juga mengevaluasi SPF untuk email massal dengan cara ini. Laporan menampilkan setiap record dan mekanisme di sepanjang proses, sehingga jalur menuju hasil akhir tetap terlihat.

Mengapa jumlah pencarian DNS penting?

Satu evaluasi SPF boleh melakukan paling banyak 10 pencarian DNS. Mekanisme include, a, mx, ptr, exists, dan redirect masing-masing dihitung dalam batas itu, termasuk yang berada di dalam include bertingkat. Jika melewati batas, hasilnya menjadi kesalahan permanen, dan server penerima lalu memperlakukan pesan seolah tidak memiliki SPF yang valid sama sekali. Pencarian tanpa hasil, yaitu kueri yang tidak mengembalikan record, memiliki batas tersendiri, yaitu dua. Rantai panjang include dari pihak ketiga adalah penyebab yang umum, dan mengurangi daftar layanan menyelesaikan masalah ini.

Apa yang dibuktikan oleh DKIM?

DKIM menambahkan tanda tangan kriptografis ke header pesan. Domain penanda tangan menerbitkan kunci publik di DNS di bawah sebuah selector, lalu echo.email mengambil kunci itu dan memverifikasi tanda tangan terhadap header dan isi pesan sebagaimana diterima. Pass berarti bagian yang ditandatangani tiba tanpa perubahan dan domain penanda tangan menjamin bagian tersebut.

Laporan mencantumkan domain penanda tangan (d=), selector (s=), header yang ditandatangani (h=), serta jenis dan ukuran kunci. Batas panjang isi (l=) ditandai, karena batas itu memungkinkan konten tambahan disisipkan di akhir pesan setelah penandatanganan.

Apa itu DMARC?

DMARC mengaitkan SPF dan DKIM dengan domain di alamat From yang terlihat. Domain From menerbitkan kebijakan di _dmarc.<domain> yang memberi tahu server penerima cara menangani email yang gagal autentikasi: none, quarantine, atau reject. Pesan lolos DMARC jika SPF atau DKIM lolos untuk domain yang selaras dengan domain From.

DMARC tidak menambahkan autentikasi sendiri. Nilainya terletak pada persyaratan keselarasan dan pada laporan agregat (rua=) yang dikirim server penerima kembali ke pemilik domain.

Apa arti selaras?

Keselarasan membandingkan domain yang terautentikasi dengan domain From. Keselarasan longgar memerlukan domain organisasi yang sama, sehingga mail.example.com selaras dengan example.com. Keselarasan ketat memerlukan nama host yang persis sama. Domain organisasi berasal dari Public Suffix List, yang tahu bahwa nama seperti example.co.uk dihitung sebagai satu domain yang dapat didaftarkan. Jika laporan menyebut selaras tanpa keterangan tambahan, perbandingannya adalah dengan domain From.

Apa itu BIMI?

BIMI menerbitkan logo merek yang ditampilkan penyedia kotak surat di samping email yang terautentikasi. Record-nya berada di default._bimi.<domain> dan menunjuk ke logo SVG (l=) dan, untuk sebagian besar penyedia, Verified Mark Certificate (a=). BIMI hanya berlaku untuk domain dengan kebijakan DMARC yang menegakkan aturan, yaitu quarantine atau reject pada 100 persen. echo.email menampilkan record tersebut dan apakah kebijakan DMARC memenuhi persyaratan.

Mengapa reverse DNS penting?

Setiap alamat IP yang mengirim email memerlukan record PTR yang menunjuk ke nama host, dan nama host itu memerlukan record A atau AAAA yang menunjuk kembali ke alamat IP yang sama. Perjalanan bolak-balik ini disebut forward-confirmed reverse DNS, atau FCrDNS. Penyedia kotak surat besar menganggap FCrDNS sebagai syarat minimum untuk server pengirim, dan email dari alamat IP tanpa record PTR sering langsung ditolak.

Apa itu reverse DNS generik?

Sebagian record PTR mengikuti pola penamaan ISP, misalnya 192-0-2-10.dynamic.example.net. Nama seperti ini menunjukkan koneksi rumahan atau server yang tidak pernah dikonfigurasi untuk email, dan filter memperlakukannya dengan curiga. Nama khusus di domain milik pengirim sendiri, seperti mail.example.com, terbaca sebagai server email yang sengaja dikonfigurasi.

Nama HELO apa yang paling baik?

Server pengirim memperkenalkan diri dengan nama HELO atau EHLO di awal percakapan SMTP. Nama yang baik dimiliki oleh server pengirim, dapat di-resolve di DNS, dan cocok dengan record PTR alamat IP pengirim. Alamat IP polos, nama seperti localhost, dan string acak umum dipakai oleh malware dan spam snowshoe, dan filter menilainya sesuai hal itu.

Mengapa memeriksa TLS?

TLS oportunistik mengenkripsi percakapan SMTP jika server penerima menawarkan STARTTLS. echo.email menawarkan STARTTLS pada setiap koneksi dan mencatat versi TLS dan cipher yang dipilih pengirim. Email yang dikirim tanpa TLS berjalan sebagai teks biasa di antara kedua server, dan Google serta Yahoo mencantumkan TLS sebagai persyaratan untuk pengirim massal. Laporan juga menghitung link dan gambar yang dimuat melalui http biasa, karena permintaan tersebut juga berjalan tanpa enkripsi.

Mengapa memeriksa IPv6?

Dua pertanyaan menentukan kesiapan IPv6. Pertanyaan pertama adalah apakah pengirim dapat menjangkau server email yang hanya mendukung IPv6. Pesan yang tiba melalui IPv6 langsung menjawab ya. Pesan yang tiba melalui IPv4 tetap dihitung mendukung IPv6 jika host pengirim memiliki record AAAA, reverse DNS alamat IPv6 itu menyebut host yang sama, dan SPF lolos untuk alamat tersebut. Sebagian besar server email memilih IPv4 atau IPv6 per koneksi, sehingga pesan berikutnya dari host yang sama sering tiba melalui IPv6. Pertanyaan kedua adalah apakah setiap host yang menyajikan gambar dan link dalam pesan memiliki record AAAA, sehingga pembaca di jaringan khusus IPv6 atau di balik carrier-grade NAT tetap dapat memuat konten. Laporan menandai pesan siap untuk IPv6 jika kedua jawabannya ya.

Bagaimana ukuran email diukur?

Ukuran email adalah jumlah byte saat dikirim: semua header, setiap bagian MIME, lampiran, dan tambahan dari encoding base64 atau quoted-printable. Gmail memotong pesan dengan HTML lebih dari sekitar 102 KB dan menyembunyikan sisanya di balik link, dan bagian yang terpotong sering berisi link berhenti berlangganan dan piksel pelacakan.

Apa itu bobot gambar?

Bobot gambar adalah total ukuran gambar jarak jauh yang dirujuk dalam tag <img>, diukur dengan mengunduh setiap gambar satu kali. Angka ini adalah nilai minimum, karena gambar dari atribut srcset dan latar belakang CSS tidak dihitung. Pesan yang berat dimuat lambat di koneksi seluler dan menghabiskan kuota data pembaca.

Apa itu kelebihan ukuran gambar?

Kelebihan ukuran gambar memperkirakan jumlah byte yang dapat dihemat pengirim dengan menyajikan setiap gambar mendekati ukuran tampilannya di pesan. Gambar hingga dua kali ukuran tampilan dihitung tanpa kelebihan, karena layar berkepadatan tinggi memakai piksel tambahan itu. Di atas dua kali ukuran tampilan, piksel tambahan menambah byte tanpa menambah detail. Gambar di bawah 1 KB, seperti spacer, tidak dihitung dalam angka ini.

Bagaimana echo.email menangani gambar?

Analisis mengunduh setiap gambar jarak jauh satu kali dan mencatat status HTTP, pengalihan, ukuran, jenis konten, dan dimensi piksel, lalu membandingkan dimensi tersebut dengan ukuran yang dinyatakan dalam HTML. Mengunduh gambar adalah hal yang dilakukan aplikasi email saat pembaca membuka pesan, sehingga pelacakan pembukaan mencatat satu pembukaan. Unduhan berasal dari jaringan Cloudflare, dan permintaan ke alamat privat atau internal ditolak.

Link diurai dari HTML dan dikelompokkan berdasarkan host, dengan parameter kueri didekode agar lebih mudah dibaca. echo.email tidak pernah membuka link biasa, karena membuka link berisiko mengonfirmasi langganan, memicu suatu tindakan, atau mencatat klik. Satu-satunya pengecualian adalah URL berhenti berlangganan satu klik yang dijelaskan di bawah.

Apa itu List-Unsubscribe?

List-Unsubscribe adalah header yang didefinisikan dalam RFC 2369. Header ini berisi satu atau beberapa cara untuk keluar dari daftar, berupa alamat mailto:, URL https:, atau keduanya. Penyedia kotak surat menggunakan header ini untuk menampilkan tombol berhenti berlangganan mereka sendiri di samping nama pengirim. URL http biasa sudah usang, dan https adalah bentuk yang diharapkan.

Apa itu berhenti berlangganan satu klik?

RFC 8058 menambahkan header kedua, List-Unsubscribe-Post, dengan nilai tetap List-Unsubscribe=One-Click. Jika kedua header ada, penyedia kotak surat mengirim permintaan POST ke URL https, dan penerima keluar dari daftar tanpa membuka halaman web. Google dan Yahoo mewajibkan berhenti berlangganan satu klik untuk pengirim massal.

echo.email mengirim permintaan POST yang sama dan melaporkan responsnya. Setiap status 2xx dihitung berhasil. Yang berhenti berlangganan hanya alamat tes sementara dari echo.email.

Apa arti berhenti berlangganan secara non-interaktif?

Berhenti berlangganan non-interaktif selesai tanpa penerima membuka browser atau mengonfirmasi apa pun. Satu klik RFC 8058 adalah metode yang lebih disukai. Alamat mailto: di List-Unsubscribe juga dihitung, meskipun berhenti berlangganan lewat email lebih lambat dan tidak memberi konfirmasi kepada penerima, sehingga penyedia memperlakukan mailto sebagai cadangan.

Mengapa link berhenti berlangganan di isi pesan masih diperlukan?

Undang-undang pemasaran di sebagian besar negara mengharapkan cara yang terlihat untuk keluar dari daftar di dalam pesan, biasanya berupa link di footer. Header melayani penyedia kotak surat, dan link di footer melayani pembaca. echo.email mencari link dengan kata-kata berhenti berlangganan atau URL bergaya berhenti berlangganan. Deteksi ini bersifat heuristik dan sesekali memilih link yang salah. Parameter pelacakan tersendiri pada link footer memisahkan berhenti berlangganan lewat footer dan lewat header dalam statistik pengirim.

Apa itu List-Id?

List-Id (RFC 2919) menyebut nama milis tempat sebuah pesan berasal, misalnya News <news.example.com>. Google dan Yahoo tidak mewajibkan header ini. Server penerima dan para penerima menggunakan header ini untuk mengurutkan dan menyaring email berdasarkan aliran, sehingga menambahkannya adalah praktik yang baik.

Apa itu daftar periksa praktik yang baik?

Daftar periksa ini mengikuti persyaratan yang diterbitkan Google dan Yahoo untuk pengirim massal pada tahun 2024: SPF yang selaras, DKIM yang selaras, forward-confirmed reverse DNS, TLS, domain From di luar penyedia email gratis dengan DMARC yang tidak gagal, kebijakan DMARC yang diterbitkan, setidaknya satu metode autentikasi yang selaras, berhenti berlangganan satu klik, dan link berhenti berlangganan yang terlihat. Setiap baris berisi ya atau tidak. Baris merah kemungkinan menjadi penyebab penempatan di kotak masuk yang lebih lemah di penyedia besar, dan skor penuh adalah standar dasar untuk email massal.

Sebagian baris hanya dihitung jika berlaku. Dua baris berhenti berlangganan dihitung jika pesan membawa header email massal: List-Unsubscribe, List-Unsubscribe-Post, List-Id, atau Precedence dengan nilai bulk, list, atau junk. Pesan pribadi tanpa header tersebut melewati kedua baris itu. Keselarasan SPF tidak masuk ke skor jika pengirim amplop ditulis ulang dengan SRS dan DMARC lolos melalui DKIM yang selaras. Setelah penulisan ulang SRS, SPF memeriksa domain server yang menulis ulang, bukan domain From. Layanan penerus email memang memakai SRS, dan sebagian server pengirim menerapkan SRS ke semua email keluar, sehingga keselarasan SPF hilang. Skor menunjukkan jumlah baris yang lolos dari baris yang dihitung.

Bagaimana pesan dirender?

Tampilan render menampilkan bagian HTML di dalam bingkai sandbox. Browser yang melakukan render, sehingga hasilnya sesuai dengan browser desktop, bukan aplikasi email atau perangkat tertentu. Skrip, formulir, dan link dinonaktifkan di pratinjau. Tampilan terpisah menunjukkan pesan dengan gambar diblokir dan dengan teks alt di tempat setiap gambar, yang merupakan cara banyak pembaca pertama kali melihat sebuah pesan.

Apa yang ditampilkan bagian MIME?

MIME adalah struktur di dalam pesan: bagian-bagiannya, jenis konten, set karakter, encoding transfer, dan boundary yang memisahkannya. Newsletter umumnya memiliki wadah multipart/alternative dengan bagian text/plain dan bagian text/html. Bagian teks biasa yang tidak ada, boundary penutup yang tidak ada, atau susunan bertingkat yang tidak biasa akan terlihat jelas di struktur pohon.

Apa yang ditampilkan bagian payload?

Bagian payload menampilkan pesan mentah sebagaimana diterima, beserta statistik: ukuran total, jumlah baris, baris terpanjang, karakter di luar ASCII, dan line feed tanpa carriage return. RFC 5322 membatasi satu baris hingga 998 karakter, dan sebagian server memotong atau menolak baris yang lebih panjang. Line feed tanpa carriage return adalah penyebab umum kegagalan DKIM, karena server di sepanjang jalur menulis ulang karakter tersebut.

Tampilan pesan mentah diawali dengan header jejak yang dicatat mx.echo.email saat pengiriman: Return-Path, Authentication-Results, Received-SPF, dan Received. Di bawahnya terdapat pesan persis seperti saat diterima, dan link unduhan menyediakan file .eml yang tidak diubah.

Blocklist mana yang diperiksa laporan?

Server penerima mencari alamat IP pengirim dan domain pengirim di blocklist DNS, dan terdaftar di daftar yang banyak dipakai membuat email ditolak atau difilter. Laporan memeriksa daftar yang sama dengan scan.mx: Spamhaus ZEN dan AuthBL untuk alamat IP, Spamhaus DBL dan ZRD untuk domain From dan domain amplop, serta SpamCop, GBUdb Truncate, dan PSBL untuk alamat IPv4. Setiap baris berisi terdaftar atau tidak terdaftar, dengan link ke halaman penghapusan dari daftar milik operator daftar tersebut.

Pendaftaran kebijakan di Spamhaus PBL menandai rentang alamat yang tidak dimaksudkan untuk mengirim email secara langsung, seperti koneksi rumahan. Email dari alamat seperti itu seharusnya dikirim melalui server email penyedia. Hasil disimpan dalam cache selama dua jam, sehingga perbaikan terlihat di tes baru paling lambat setelah dua jam.

Apa arti skor SpamAssassin?

SpamAssassin adalah filter spam open source yang digunakan oleh banyak server penerima. Server email memberi skor setiap pesan tes dengan SpamAssassin dan aturan standarnya, yang diperbarui setiap hari. Laporan menampilkan total, ambang spam 5, dan setiap aturan yang cocok, dimulai dari poin tertinggi. Poin negatif menguntungkan pesan, misalnya tanda tangan DKIM yang valid.

Tes jaringan mencari alamat IP pengirim dan domain di dalam link di Spamhaus (melalui DQS), URIBL, SURBL, dan daftar lain dalam aturan standar. Pembelajaran Bayes dan jaringan hash bersama Razor, Pyzor, dan DCC dinonaktifkan, sehingga skor hanya bergantung pada pesan itu sendiri. Server juga tidak mengirim informasi apa pun tentang pesan ke luar untuk pembelajaran.

Skor ini bersifat saran dan tidak dihitung dalam skor praktik yang baik. Setiap server penerima menjalankan filternya sendiri dengan aturan dan ambang batasnya sendiri, dan Gmail serta Outlook sama sekali tidak menggunakan SpamAssassin. Skor di atas nol adalah hal yang normal. Aturan dengan poin terbanyak menunjukkan bagian yang paling diuntungkan oleh perubahan. Pesan yang lebih besar dari 500 KB tidak diberi skor.

Mengapa domain pengirim memerlukan server email?

Balasan dikirim ke domain From, dan bounce dikirim ke domain pengirim amplop. Keduanya memerlukan record MX, atau setidaknya record alamat, yang digunakan server email sebagai cadangan. Null MX, yaitu satu MX yang menunjuk ke titik (RFC 7505), menyatakan bahwa sebuah domain sama sekali tidak menerima email, dan sebagian server penerima menolak pesan dari domain seperti itu.

Elemen HTML mana yang dianggap berisiko?

Skrip, formulir, iframe, object, dan embed jarang cocok untuk email. Sebagian besar aplikasi email menghapusnya, dan filter spam menilainya sebagai tanda phishing. Link dan gambar biasa melakukan tugas yang sama tanpa penalti. Bagian konten juga menampilkan ukuran HTML dan seberapa banyak teks terlihat yang dibawa HTML, karena pesan yang hampir seluruhnya terdiri dari markup atau gambar terlihat mencurigakan bagi filter.

Mengapa penyingkat link ditandai?

Penyingkat publik seperti bit.ly menyembunyikan tujuan sebenarnya. Kampanye phishing banyak memakainya, sehingga filter tidak memercayai link yang melewatinya. Link yang langsung mengarah ke domain pengirim justru membangun reputasi.

Apa yang ditampilkan bagian DNS?

Setiap kueri DNS yang dibuat untuk laporan muncul di bagian DNS, dikelompokkan berdasarkan tujuan: reverse DNS, SPF, DKIM, DMARC, BIMI, server email, dan pemeriksaan IPv6. Pencarian blocklist tidak dimasukkan ke daftar, karena nama kuerinya membawa kunci akses. Setiap entri menampilkan nama, jenis record, kode respons, jawaban beserta TTL, dan record authority jika ada. Daftar ini menunjukkan record mana yang menghasilkan setiap hasil, yang membantu ketika perubahan DNS terbaru belum mencapai semua resolver.

Alat gratis lainnya

scan.mx
Periksa pengaturan email sebuah domain: MX, SPF, DKIM, DMARC, BIMI.
portscan.com
Periksa port TCP mana yang terbuka pada sebuah alamat IP, termasuk port 25.