Email Spam Tester Jalankan pengujian · Untuk agen · API · Blog

Cara kerja pengujian

Kirim satu pesan ke alamat sekali pakai dan 42 pemeriksaan akan dijalankan terhadapnya. Halaman ini memuat semuanya: apa yang diperiksa masing-masing, dampaknya pada skor Anda jika gagal, dan bagian standar yang menjadi sumbernya.

Tidak ada yang merupakan opini kami yang disamarkan sebagai aturan. Jika suatu pemeriksaan menerapkan sesuatu yang dinyatakan oleh standar, kalimat dari standar tersebut dikutip di bawahnya. Jika pemeriksaan menerapkan sesuatu yang diwajibkan oleh Google atau Yahoo, halaman mereka ditautkan. Jika itu merupakan penilaian kami sendiri, hal tersebut dinyatakan.

Diperbarui:

PemeriksaanGrupSkor kamiSkor klasik
Rantai ARCAutentikasi−20
Tanda tangan DKIMAutentikasi−18−1
Penyelarasan DKIMAutentikasi−10−1
Hasil DMARCAutentikasi−140
Sender IDAutentikasi−5−0.5
SPFAutentikasi−18−1
Penyelarasan SPFAutentikasi−5−0.5
Nama host pengirim diresolusikanInfrastruktur dan reputasi−5−3
Daftar blokirInfrastruktur dan reputasi−25−3
Nama HELOInfrastruktur dan reputasi−50
Catatan MXInfrastruktur dan reputasi−5−3
DNS terbalikInfrastruktur dan reputasi−12−1.5
Enkripsi transportasiInfrastruktur dan reputasi−50
Penilai AIMesin spam
Putusan gabunganMesin spam−250
Postmark SpamCheckMesin spam
RspamdMesin spam
SpamAssassinMesin spam0−3
Teks alt gambarKonten−4−0.5
Ketersediaan tautanKonten−5−1
Script dan iframeKonten−10−1
Keseimbangan teks dan HTMLKonten−3−0.3
Bagian teks dan HTMLKonten−50
Ukuran HTMLKonten−3−0.3
Ukuran gambarKonten−3−0.3
Tujuan tautan yang ditampilkanKonten−30
Reputasi tautanKonten−400
Pemindaian lampiranKonten−600
PreheaderKonten−20
Baris subjekKonten−30
Tautan pendekKonten−5−0.5
Kebijakan DMARC dipublikasikanAturan pengirim massal−60
List-UnsubscribeAturan pengirim massal−10−1
Berhenti berlangganan sekali klikAturan pengirim massal−80
TLS untuk email massalAturan pengirim massal−50
BIMIRekomendasi00
Usia dan panjang kunci DKIMRekomendasi00
Pengiriman laporan DMARCRekomendasi00
DNSSECRekomendasi00
MTA-STSRekomendasi00
Panjang jalur pengembalianRekomendasi00
Pelaporan TLSRekomendasi00

Autentikasi

Apakah server penerima dapat membuktikan bahwa pesan berasal dari sumber yang dinyatakannya. Ini adalah bagian keterkiriman yang sepenuhnya bergantung pada DNS, dan bagian yang diwajibkan Gmail dan Yahoo bagi pengirim massal pada 2024.

Rantai ARC auth.arc

ARC mempertahankan hasil autentikasi saat melewati penerus. Tanpanya, milis yang menambahkan footer merusak tanda tangan DKIM Anda dan salinan yang diteruskan gagal DMARC di tujuan akhir.

Jika gagal: Tidak ada yang perlu dilakukan sebagai pengirim. Ini penting jika Anda menjalankan milis atau penerus, dan menjelaskan mengapa sebagian email Anda gagal DMARC setelah seseorang meneruskannya.

Dampaknya hingga 2 poin dari 100 pada skor kami.

RFC 7960 §1 — Introduction

DMARC with restrictive policies causes problems for many Mailing Lists.

RFC 8617 §2.1 — Evidence

In ARC's situation, the "evidence" is a message's authentication assessment at any point along the delivery path between origination and final delivery.

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Tanda tangan DKIM auth.dkim

DKIM menandatangani bagian-bagian pesan dengan kunci privat dan memublikasikan kunci publik di DNS. Kami memverifikasi setiap tanda tangan yang dibawa pesan serta melaporkan domain penandatangan, selector, dan panjang kunci.

Jika gagal: Aktifkan DKIM di platform pengiriman Anda dan publikasikan kunci yang diberikannya. Gunakan 2048 bit: 1024 masih dapat diverifikasi, tetapi kunci sependek itu dapat dibobol dan tidak lagi aman.

Dampaknya hingga 18 poin dari 100 pada skor kami dan hingga 1 dari 10 pada skor klasik.

RFC 6376 §3.5 — The DKIM-Signature Header Field

The signature of the email is stored in the DKIM-Signature header field.

RFC 6376 §6.1 — Extract Signatures from the Message

Verifiers MUST NOT attribute ultimate meaning to the order of multiple DKIM-Signature header fields.

RFC 8301 §3.1 — Signing and Verification Algorithms

rsa-sha1 MUST NOT be used for signing or verifying.

RFC 8463 §6 — Transition Considerations

For backward compatibility, signers can add multiple signatures that use old and new signing algorithms.

Google — Set up DKIM

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Penyelarasan DKIM auth.dkim_alignment

Tanda tangan yang valid tidak cukup untuk DMARC. Domain penandatangan harus cocok dengan domain dalam header From, secara persis atau berdasarkan domain organisasi, tergantung pada kebijakan yang Anda publikasikan.

Jika gagal: Tandatangani dengan domain Anda sendiri, bukan domain platform Anda. Sebagian besar platform mendukung ini dan menyebutnya domain pengiriman khusus atau terautentikasi.

Dampaknya hingga 10 poin dari 100 pada skor kami dan hingga 1 dari 10 pada skor klasik.

RFC 9989 §4.4.1 — DKIM-Authenticated Identifiers

A single email can contain multiple DKIM signatures, and it is considered to produce a DMARC "pass" result if any DKIM-Authenticated Identifier aligns with the Author Domain.

Google — Set up DMARC

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Hasil DMARC auth.dmarc

DMARC mengaitkan SPF dan DKIM dengan domain yang dilihat pembaca Anda serta memberi tahu penerima tindakan yang harus dilakukan ketika keduanya tidak selaras. Kami melaporkan kebijakan yang dipublikasikan dan apakah pesan ini memenuhinya.

Jika gagal: Publikasikan catatan DMARC. Mulai dengan p=none, baca laporannya selama beberapa minggu, lalu beralih ke quarantine setelah Anda mengetahui pihak lain yang mengirim atas nama Anda.

Dampaknya hingga 14 poin dari 100 pada skor kami.

RFC 9989 §5.3.5 — Determine DMARC "Pass" or "Fail"

If no Authenticated Identifiers exist for the domain, or none of the Authenticated Identifiers align with the Author Domain, the message is considered to fail the DMARC mechanism check.

RFC 9989 §4.7 — DMARC Policy Record Format

DMARC Policy Records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [RFC6376].

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

Sender ID auth.sender_id

Pemeriksaan yang sama seperti SPF, dijalankan terhadap domain dalam header From, bukan envelope. Pemeriksaan ini menjawab pertanyaan yang berbeda: apakah domain yang dilihat pembaca Anda mengizinkan server yang mengirim pesan tersebut. Pesan dapat lulus SPF pada envelope-nya sementara domain yang terlihat tidak menjamin siapa pun.

Jika gagal: Publikasikan SPF untuk domain dalam header From Anda, bukan hanya untuk domain bounce yang diberikan platform Anda.

Dampaknya hingga 5 poin dari 100 pada skor kami dan hingga 0.5 dari 10 pada skor klasik.

RFC 4406 §4 — Record Selection

After the above steps, there should be one record remaining and evaluation can proceed.

SPF auth.spf

SPF adalah catatan DNS yang mencantumkan server mana yang boleh mengirim untuk domain Anda. Server penerima mengambil alamat dalam envelope, mencari catatan domain tersebut, lalu memeriksa apakah IP yang terhubung tercantum di dalamnya. Kami melaporkan hasilnya dan jumlah pencarian DNS yang diperlukan catatan tersebut, karena evaluasi berhenti pada sepuluh dan apa pun yang melebihi batas itu merupakan kesalahan permanen, bukan hasil lulus.

Jika gagal: Publikasikan catatan yang hanya mencantumkan platform pengiriman Anda. Jika catatan Anda mendekati batas sepuluh pencarian, ratakan include yang tidak Anda gunakan (catatan yang lulus hari ini mulai gagal ketika penyedia menambahkan include miliknya sendiri).

Dampaknya hingga 18 poin dari 100 pada skor kami dan hingga 1 dari 10 pada skor klasik.

RFC 7208 §4.6.4 — DNS Lookup Limits

SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror".

RFC 7208 §2.6 — Results of Evaluation

Section 4 defines check_host(), a model function definition that uses the inputs defined above and the sender's policy published in the DNS to reach a conclusion about client authorization.

Google — Set up SPF

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Penyelarasan SPF auth.spf_alignment

Apakah alamat bounce cocok dengan alamat From yang dilihat pembaca. SPF mengizinkan envelope, dan DMARC hanya memperhitungkan izin tersebut ketika keduanya selaras.

Jika gagal: Minta platform pengiriman Anda menyediakan subdomain bounce dari domain Anda sendiri. Jika DKIM Anda sudah selaras, ini tidak mendesak, tetapi tanpa ini Anda tidak memiliki cadangan ketika DKIM rusak dalam perjalanan.

Dampaknya hingga 5 poin dari 100 pada skor kami dan hingga 0.5 dari 10 pada skor klasik.

RFC 9989 §4.4.2 — SPF-Authenticated Identifiers

Only an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain is enough to validate the authorized use of the Author Domain.

RFC 9989 §5.3.5 — Determine DMARC "Pass" or "Fail"

If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check.

Google — Set up DMARC

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Infrastruktur dan reputasi

Mesin dan alamat asal pengiriman pesan, serta penilaian internet lainnya terhadap keduanya.

Nama host pengirim diresolusikan infra.a_record

Apakah nama host yang diumumkan saat HELO memiliki catatan alamat.

Jika gagal: Publikasikan catatan A untuk nama yang diumumkan server Anda.

Dampaknya hingga 5 poin dari 100 pada skor kami dan hingga 3 dari 10 pada skor klasik.

RFC 5321 §5.1 — Locating the Target Host

If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.

Google — Set up MX records

Daftar blokir infra.dnsbl

Apakah IP pengirim tercantum pada salah satu daftar blokir yang benar-benar diperiksa oleh penerima. Daftar kami diperiksa terhadap titik uji terdokumentasi milik setiap zona alih-alih disusun dari pencarian web, karena zona mati menjawab NXDOMAIN dan itu terbaca sebagai "bersih".

Jika gagal: Ikuti proses penghapusan dari daftar di situs operator yang mencantumkannya. Pencantuman pada zona utama langsung menghentikan email, jadi tangani itu sebelum hal lain di halaman ini.

Dampaknya hingga 25 poin dari 100 pada skor kami dan hingga 3 dari 10 pada skor klasik.

RFC 5782 §2.1 — IP Address DNSxL

Each IPv4 address listed in the DNSxL has a corresponding DNS entry.

RFC 5782 §5 — Test and Contact Addresses

IPv4-based DNSxLs MUST contain an entry for 127.0.0.2 for testing purposes.

Google — Postmaster Tools: reputation and delivery errors

Google — Email sender guidelines

Nama HELO infra.helo

Nama yang digunakan server pengirim untuk memperkenalkan dirinya pada awal percakapan SMTP. Nama tersebut harus berupa domain yang sepenuhnya memenuhi syarat dan dapat diresolusikan.

Jika gagal: Tetapkan nama host server email Anda ke nama nyata dalam domain Anda, bukan ke ID kontainer atau nama internal.

Dampaknya hingga 5 poin dari 100 pada skor kami.

RFC 5321 §4.1.1.1 — Extended HELLO (EHLO) or HELLO (HELO)

The argument clause contains the fully-qualified domain name of the SMTP client, if one is available.

Google — Email sender guidelines

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Catatan MX infra.mx

Apakah domain dalam header From Anda dapat menerima email. Tanpanya, balasan dan pantulan tidak memiliki tujuan, dan filter menganggap domain pengirim yang tidak dapat menerima email sebagai tanda buruk.

Jika gagal: Publikasikan catatan MX untuk domain yang Anda gunakan untuk mengirim, meskipun catatan tersebut hanya merutekan ke kotak surat yang Anda baca sebulan sekali.

Dampaknya hingga 5 poin dari 100 pada skor kami dan hingga 3 dari 10 pada skor klasik.

RFC 5321 §5.1 — Locating the Target Host

The lookup first attempts to locate an MX record associated with the name.

Google — Set up MX records

DNS terbalik infra.rdns

Apakah IP pengirim diresolusikan kembali ke nama host, dan apakah nama host tersebut diresolusikan maju ke IP yang sama. Resolusi pulang-pergi adalah intinya: PTR yang menunjuk ke sembarang tujuan mudah dibuat, sedangkan pasangan yang cocok merupakan bukti bahwa alamat tersebut milik Anda.

Jika gagal: Minta pihak yang memiliki IP untuk menetapkan PTR ke nama yang Anda kendalikan, dan pastikan nama tersebut memiliki catatan A yang menunjuk kembali.

Dampaknya hingga 12 poin dari 100 pada skor kami dan hingga 1.5 dari 10 pada skor klasik.

RFC 1912 §2.1 — Inconsistent, Missing, or Bad Data

Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain.

Google — Email sender guidelines

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Enkripsi transportasi infra.tls

Apakah pesan tiba melalui TLS, dan dengan cipher apa. Semua sistem modern menegosiasikannya; pesan yang tiba tanpa enkripsi menunjukkan sesuatu tentang konfigurasi pengirim.

Jika gagal: Aktifkan STARTTLS pada server pengirim. Setiap platform utama sudah melakukan ini, jadi kegagalan di sini biasanya berarti ada relai yang dihosting sendiri dalam jalur tersebut.

Dampaknya hingga 5 poin dari 100 pada skor kami.

RFC 3207 §2 — STARTTLS Extension

The STARTTLS extension to SMTP is laid out as follows:

Google — Send email over a secure TLS connection

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Mesin spam

Penilaian filter konten independen terhadap pesan. Dua mesin, bukan satu, karena skor dari satu mesin merupakan opini mesin tersebut.

Penilai AI spam.ai_judge

Sebuah model memperkirakan bagaimana filter pembelajaran mesin modern akan memperlakukan pesan, berdasarkan temuan teknis dan pengukuran konten. Model ini melihat fakta, bukan teks isi pesan.

Jika gagal: Jika berdiri sendiri, hanya berupa detail. Perkiraannya menjadi masukan bagi putusan gabungan di bawah ini.

Ditampilkan sebagai perincian. Tidak pernah dinilai.

Putusan gabungan spam.panel

Satu angka dari mesin yang memberikan jawaban, diberi bobot agar pendapat paling kuat tidak sekadar hilang dalam perhitungan rata-rata. SpamAssassin dan Postmark dihitung sebagai satu suara karena keduanya menggunakan basis aturan yang sama.

Jika gagal: Tangani setiap temuan satu per satu. Baris ini berubah ketika temuan tersebut berubah.

Dampaknya hingga 25 poin dari 100 pada skor kami.

Google — Why Gmail marks messages as spam

How this score is calculated

Postmark SpamCheck spam.postmark

Pendapat ketiga, dinonaktifkan secara default. Endpoint-nya menerima seluruh pesan dan kami tidak dapat menyunting bagian apa pun tanpa merusak hal yang sedang diukur, jadi mengaktifkannya berarti menerima bahwa setiap pesan yang diuji disalin ke pihak ketiga.

Jika gagal: Tidak ada yang perlu dilakukan. Saat dinonaktifkan, pemeriksaan melaporkan bahwa fitur ini dinonaktifkan, yang tidak sama dengan lulus.

Ditampilkan sebagai perincian. Tidak pernah dinilai.

Rspamd spam.rspamd

Filter kedua yang dikembangkan secara independen. Filter ini cukup sering berbeda pendapat dengan SpamAssassin sehingga layak diperiksa, dan itulah alasan filter ini ada di sini.

Jika gagal: Hanya detail. Pendapat mesin ini dimasukkan ke dalam putusan gabungan alih-alih diberi skor tersendiri.

Ditampilkan sebagai perincian. Tidak pernah dinilai.

SpamAssassin spam.spamassassin

Filter klasik berbasis aturan, masih menjadi mesin di balik sebagian besar alat pengujian email. Setiap aturan yang terpicu dicantumkan beserta bobotnya.

Jika gagal: Baca aturan yang terpicu, bukan totalnya. Sebagian besar mudah diatasi setelah Anda dapat melihat aturan mana yang terpicu.

Dampaknya hingga 3 dari 10 pada skor klasik.

Google — Why Gmail marks messages as spam

Apache SpamAssassin — rule documentation

Konten

Pesan itu sendiri: strukturnya, tautannya, gambarnya, dan hal-hal yang dibaca filter sebelum mengambil keputusan.

Teks alt gambar content.alt_attributes

Apakah gambar memiliki atribut alt. Klien email memblokir gambar jarak jauh secara default, jadi selama beberapa detik pertama, teks alt adalah pesan Anda.

Jika gagal: Tulis teks alt yang menyampaikan maknanya, dan jangan pernah membiarkan visual utama tanpa teks alt.

Dampaknya hingga 4 poin dari 100 pada skor kami dan hingga 0.5 dari 10 pada skor klasik.

Google — Email sender guidelines

Script dan iframe content.forbidden_tags

Apakah HTML berisi tag yang tidak akan dijalankan oleh klien email mana pun. Tag tersebut paling tidak akan dihapus dan paling buruk dianggap sebagai sinyal upaya pengelakan.

Jika gagal: Hapus script, iframe, object, dan embed. Semua hal interaktif harus ditempatkan di balik tautan.

Dampaknya hingga 10 poin dari 100 pada skor kami dan hingga 1 dari 10 pada skor klasik.

Google — Email sender guidelines

Keseimbangan teks dan HTML content.html_text_ratio

Seberapa banyak pesan berupa markup dibandingkan teks yang dapat dibaca. Satu halaman markup yang membungkus satu kalimat adalah pola yang dikenali filter.

Jika gagal: Tulis bagian teks yang menyampaikan hal yang sama dengan HTML, bukan teks pengganti.

Dampaknya hingga 3 poin dari 100 pada skor kami dan hingga 0.3 dari 10 pada skor klasik.

RFC 2046 §5.1.4 — Alternative Subtype

Systems should recognize that the content of the various parts are interchangeable.

Google — Why Gmail marks messages as spam

Bagian teks dan HTML content.html_version

Apakah pesan menyertakan alternatif teks biasa bersama HTML. Beberapa filter mempertimbangkan ketiadaannya, dan setiap pembaca layar memerlukannya.

Jika gagal: Kirim multipart/alternative dengan versi teks yang sebenarnya, bukan bagian kosong atau baris yang meminta penerima melihatnya di peramban.

Dampaknya hingga 5 poin dari 100 pada skor kami.

RFC 2046 §5.1.4 — Alternative Subtype

The "multipart/alternative" type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, each of the body parts is an "alternative" version of the same information.

Google — Email sender guidelines

Ukuran HTML content.html_weight

Seberapa besar bagian HTML. Gmail memotong pesan yang melebihi sekitar 102 KB dan menyembunyikan sisanya di balik tautan, yang juga membuat footer berhenti berlangganan Anda ikut tersembunyi.

Jika gagal: Kurangi CSS inline dan blok gaya yang berulang (sebagian besar templat hanya menggunakan sepertiga batas setelah aturan yang tidak digunakan dihapus).

Dampaknya hingga 3 poin dari 100 pada skor kami dan hingga 0.3 dari 10 pada skor klasik.

Google — Email sender guidelines

Ukuran gambar content.images_weight

Ukuran total gambar yang dimuat oleh pesan. Gambar berukuran besar membuat pesan lambat dimuat di ponsel, dan email yang hanya berisi gambar memiliki bentuk yang dicurigai oleh filter.

Jika gagal: Kompres gambar dan pastikan pesan tetap dapat dibaca saat gambar dinonaktifkan.

Dampaknya hingga 3 poin dari 100 pada skor kami dan hingga 0.3 dari 10 pada skor klasik.

Google — Email sender guidelines

Pemindaian lampiran content.malware

Apakah lampiran mengandung malware yang diketahui. Pada penerapan yang pemindainya dinonaktifkan, bagian ini melaporkan bahwa pemindaian tidak dijalankan, bukan melaporkan bahwa lampiran bersih.

Jika gagal: Jika ini terpicu, hentikan pengiriman dan cari tahu apa yang ada di mesin yang membuat pesan tersebut.

Dampaknya hingga 60 poin dari 100 pada skor kami.

Google — Why Gmail marks messages as spam

ClamAV — how detection works

Preheader content.preheader

Baris pratinjau yang ditampilkan klien di sebelah subjek. Tanpa baris ini, klien akan menampilkan apa pun yang muncul pertama kali dalam isi pesan, yang biasanya merupakan tautan untuk melihat pesan di peramban.

Jika gagal: Tambahkan blok preheader tersembunyi sebagai elemen pertama isi pesan.

Dampaknya hingga 2 poin dari 100 pada skor kami.

Google — Email sender guidelines

Baris subjek content.subject

Panjang, kapitalisasi, dan pola yang dinilai oleh filter. Kami mengukur subjek yang telah didekodekan, sehingga baris dalam aksara Kiril atau CJK dinilai sebagai teks, bukan sebagai pengodeannya.

Jika gagal: Pertahankan panjangnya di bawah sekitar 60 karakter, hindari huruf kapital berlebihan dan tanda seru.

Dampaknya hingga 3 poin dari 100 pada skor kami.

RFC 5322 §2.2 — Header Fields

Header fields are lines beginning with a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF.

RFC 2047 §2 — Syntax of encoded-words

An 'encoded-word' is defined by the following ABNF grammar.

Google — Why Gmail marks messages as spam

Tautan pendek content.url_shortener

Apakah tautan melewati layanan pemendek publik. Layanan pemendek menyembunyikan tujuan, yang merupakan hal yang memang dilatih untuk tidak dipercaya oleh filter.

Jika gagal: Tautkan domain Anda sendiri, atau gunakan domain pelacakan platform Anda pada subdomain milik Anda.

Dampaknya hingga 5 poin dari 100 pada skor kami dan hingga 0.5 dari 10 pada skor klasik.

Google — Why Gmail marks messages as spam

Aturan pengirim massal

Persyaratan yang dipublikasikan Gmail dan Yahoo bagi siapa pun yang mengirim dalam volume besar. Persyaratan ini berlaku untuk pengiriman massal dan dilewati untuk pesan yang tidak tampak seperti pengiriman massal.

Kebijakan DMARC dipublikasikan compliance.dmarc_present

Apakah domain From memublikasikan catatan DMARC, terpisah dari apakah pesan ini lolos pemeriksaannya. Gmail dan Yahoo mewajibkannya dari pengirim massal.

Jika gagal: Publikasikan catatan. p=none cukup untuk memenuhi persyaratan dan memberi Anda laporan yang dapat digunakan sebagai dasar kerja.

Dampaknya hingga 6 poin dari 100 pada skor kami.

RFC 9989 §4.7 — DMARC Policy Record Format

If this tag is not present in an otherwise syntactically valid DMARC Policy Record, then the record is treated as if it included "p=none".

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

List-Unsubscribe compliance.list_unsubscribe

Apakah pesan memiliki header berhenti berlangganan yang dapat ditindaklanjuti oleh klien email. Gmail dan Yahoo mewajibkannya dari pengirim massal, dan ketiadaannya tetap difilter terlepas dari hal lainnya. Aturan ini berlaku untuk pengiriman massal. Pesan yang meminta penerima mengonfirmasi langganan, atau memberi tahu bahwa langganan telah berhasil, dikirim kepada satu orang mengenai sesuatu yang baru saja mereka lakukan; CAN-SPAM menyebutnya pesan transaksional atau hubungan, dan baik Gmail maupun Yahoo tidak meminta header berhenti berlangganan pada pesan tersebut. Jadi pemeriksaan ini membaca pesan terlebih dahulu. Konfirmasi langganan, pesan selamat datang, pesan transaksional, atau notifikasi tanpa header milis tidak dikenai penalti, dan laporan menyebutkan pesan tersebut dianggap sebagai apa. Pesan selamat datang yang dipenuhi penawaran pada dasarnya adalah edisi pertama pengiriman massal; tanpa header milis, pemeriksaan tidak dapat membedakan keduanya, dan tidak memberikan penalti berdasarkan dugaan. Jika pesan memiliki List-Unsubscribe atau List-Id, Anda sendiri telah menyatakannya sebagai email milis, dan pemeriksaan berjalan seperti biasanya.

Jika gagal: Tambahkan header List-Unsubscribe dengan URI HTTPS. Setiap platform pengiriman dapat melakukan ini.

Dampaknya hingga 10 poin dari 100 pada skor kami dan hingga 1 dari 10 pada skor klasik.

RFC 2369 §3.2 — List-Unsubscribe

The List-Unsubscribe field describes the command (preferably using mail) to directly unsubscribe the user (removing them from the list).

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

Berhenti berlangganan sekali klik compliance.one_click_unsubscribe

Bentuk yang lebih ketat: URI HTTPS, header "List-Unsubscribe-Post", dan satu tanda tangan DKIM yang valid yang mencakup kedua header. Ketiganya harus ada, atau penerima tidak menampilkan tombol. Seperti pemeriksaan List-Unsubscribe, pemeriksaan ini berlaku untuk pengiriman massal, bukan untuk konfirmasi atau pesan selamat datang.

Jika gagal: Kesalahan yang umum adalah tanda tangan: platform menandatangani "List-Unsubscribe" dan melupakan "List-Unsubscribe-Post". Kedua nama header harus muncul dalam tag h= pada tanda tangan yang sama.

Dampaknya hingga 8 poin dari 100 pada skor kami.

RFC 8058 §4 — Additional Requirements

The List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature and included in the "h=" tag of a valid DKIM-Signature header field.

RFC 8058 §3.1 — Mail Senders

The List-Unsubscribe header field MUST contain one HTTPS URI.

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

Rekomendasi

Layak dilakukan dan tidak pernah dinilai. Tidak ada dalam bagian ini yang dapat mengurangi poin, yang merupakan keputusan produk yang diterapkan oleh pengujian.

BIMI advisory.bimi

Apakah domain memublikasikan catatan BIMI, yang menempatkan logo di samping pesan Anda pada beberapa klien. Ini terlebih dahulu memerlukan kebijakan DMARC yang diterapkan, serta sertifikat merek terverifikasi yang berbayar.

Jika gagal: Layak dilakukan setelah DMARC berada pada quarantine atau reject dan volumenya membenarkan biaya sertifikat.

Rekomendasi. Tidak mengurangi skor.

BIMI — draft specification, not yet an RFC

Usia dan panjang kunci DKIM advisory.dkim_key_rotation

Panjang kunci penandatanganan dan berapa lama kunci tersebut telah digunakan. Biaya untuk menyerang kunci pendek secara offline semakin murah setiap tahun yang berlalu.

Jika gagal: Beralihlah ke 2048 bit dan lakukan rotasi sesuai jadwal. Publikasikan selector baru, alihkan penandatanganan kepadanya, lalu nonaktifkan selector lama.

Rekomendasi. Tidak mengurangi skor.

RFC 8301 §3.2 — Key Sizes

Since short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits.

Google — Set up DKIM

Pengiriman laporan DMARC advisory.dmarc_reporting

Apakah alamat dalam catatan DMARC Anda benar-benar akan menerima sesuatu. Jika alamat laporan berada di luar domain Anda sendiri, RFC 9990 mewajibkan domain tersebut menerbitkan izinnya sendiri terlebih dahulu, sebagai catatan TXT di your-domain._report._dmarc.their-domain. Tanpa catatan itu, penerima menghapus alamat tersebut: tidak ada pantulan, tidak ada kesalahan, tidak ada laporan. Ini adalah konfigurasi biasa, bukan konfigurasi yang tidak umum, karena alamat tersebut biasanya berada di vendor pemantauan, atau di domain utama Anda sementara kebijakannya berada di subdomain pengirim. Aturan yang sama berlaku untuk laporan kegagalan, dengan RFC 9991 mengacu pada prosedur yang sama untuk tag ruf. Kami mencari catatan yang sama seperti yang akan dicari oleh penerima dan menunjukkan nama yang kami tanyakan.

Jika gagal: Minta pihak yang mengelola domain tujuan untuk menerbitkan catatan TXT yang berisi v=DMARC1 pada nama yang ditampilkan dalam temuan. Vendor pemantauan biasanya melakukan ini untuk Anda setelah Anda menambahkan domain ke akun mereka, jadi jika catatan tersebut tidak ada, domain itu mungkin belum pernah ditambahkan di pihak mereka. Jika laporan dikirim ke domain Anda sendiri, tidak ada yang perlu dilakukan.

Rekomendasi. Tidak mengurangi skor.

RFC 9990 §4 — Verifying External Destinations

When a Mail Receiver discovers a DMARC Policy Record in the DNS, and the Organizational Domain at which that record was discovered is not identical to the Organizational Domain of the host part of the authority component of a [RFC3986] specified in the "rua" tag, the following verification steps MUST be taken:

RFC 9990 §4 — Verifying External Destinations

Where the above algorithm fails to confirm that the external reporting was authorized by the Report Consumer, the URI MUST be ignored by the Mail Receiver generating the report.

RFC 9991 §5 — Verifying External Destinations

In case of external destinations, a Mail Receiver who generates failure reports MUST use the Verifying External Destinations procedure described in Section 4 of [RFC9990], substituting the "ruf" tag where the "rua" tag appears in that procedure.

Google — Set up DMARC

DNSSEC advisory.dnssec

Apakah domain ditandatangani. SPF, DKIM, dan DMARC semuanya berada di DNS, sehingga penyerang yang dapat memalsukan jawaban DNS dapat memalsukan ketiganya.

Jika gagal: Aktifkan di registrar Anda. Biasanya hanya perlu satu tombol, dan registrar menangani sisanya.

Rekomendasi. Tidak mengurangi skor.

RFC 4033 §2 — Definitions of Important DNSSEC Terms

Authentication Chain: An alternating sequence of DNS public key (DNSKEY) RRsets and Delegation Signer (DS) RRsets

MTA-STS advisory.mta_sts

Apakah domain memublikasikan kebijakan yang memberi tahu server lain untuk menolak pengiriman tidak terenkripsi kepada Anda. Ini melindungi email yang dikirim kepada Anda, bukan email yang Anda kirim.

Jika gagal: Publikasikan catatan TXT dan file kebijakan melalui HTTPS (pekerjaan selama satu sore, dan ini menutup serangan downgrade).

Rekomendasi. Tidak mengurangi skor.

RFC 8461 §3 — Policy Discovery

To discover if a recipient domain implements MTA-STS, a sender need only resolve a single TXT record.

Panjang jalur pengembalian advisory.return_path_length

Seberapa panjang alamat pantulan. RFC 5321 mewajibkan server penerima untuk menerima 64 oktet sebelum @, dan menyatakan dalam bagian yang sama bahwa implementasi tidak boleh menetapkan batas yang dapat dihindarinya. Namun, banyak implementasi tetap menetapkan batas, dan pesan yang melampaui batas ditolak pada MAIL FROM, bahkan sebelum isi pesan dikirim. Platform pengiriman mengalami masalah ini karena mengodekan penerima ke dalam jalur pengembalian agar pantulan dapat dicocokkan kembali, sehingga panjangnya bergantung pada siapa yang Anda kirimi pesan, bukan pada Anda.

Jika gagal: Perpendek bagian tetap yang ditambahkan platform Anda di awal, atau ganti domain pantulan dengan yang lebih pendek. Jika Anda tidak dapat mengubah keduanya, alamat yang berisiko adalah alamat pelanggan terpanjang, jadi sebaiknya ukur alamat terpanjang dalam daftar Anda, bukan nilai rata-rata.

Rekomendasi. Tidak mengurangi skor.

RFC 5321 §4.5.3.1.1 — Local-part

The maximum total length of a user name or other local-part is 64 octets.

RFC 5321 §4.5.3.1 — Size Limits and Minimums

Every implementation MUST be able to receive objects of at least these sizes.

Haraka — the address parser that enforces the 64-octet local-part, and the flag that relaxes it

Pelaporan TLS advisory.tls_rpt

Apakah domain meminta laporan ketika seseorang gagal mengirimkan email kepadanya melalui TLS. Dipasangkan dengan MTA-STS: kebijakan tanpa pelaporan membuat Anda tidak dapat mengetahui apakah kebijakan tersebut berfungsi.

Jika gagal: Tambahkan catatan TXT dengan alamat yang menerima laporan harian.

Rekomendasi. Tidak mengurangi skor.

RFC 8460 §3 — Reporting Policy

A domain publishes a record to its DNS indicating that it wishes to receive reports.