Mengapa email dikirim secara normal meskipun ada "kegagalan" SPF?

Saya mencoba mencari tahu mengapa email palsu dikirim ke penyedia email utama (gmail.com, outlook.com) meskipun email ditandai dengan SPF hardfail. Email tersebut juga dikirimkan ke Microsoft Exchange, yang melemparkan PermErroruntuk catatan SPF yang sama.

Saya mengirim email menggunakan domain SOME_DOMAIN.com, yang mendefinisikan catatan SPF yang rusak. Email ditransmisikan dari alamat IP saya sendiri yang tidak secara eksplisit tercantum dalam catatan SPF SOME_DOMAIN.com. Catatan SPF untuk SOME_DOMAIN.com memiliki tiga properti berikut, dua yang pertama merupakan pelanggaran terhadap SPF RFC-4408:

1. Diperlukan lebih dari 10 permintaan DNS untuk menyelesaikan seluruh catatan SPF, karena include:.
2. Kesalahan sintaks di salah satu catatan SPF, python-spf melempar kesalahan parse.
3. Catatan SPF berisi aturan ~alldan -all, keduanya mengatakan bahwa himpunan semua alamat harus softfaildanhardfail

Email yang dikirim ke alamat outlook.com yang menyamar sebagai admin@SOME_DOMAIN.com akan berisi kesalahan berikut dalam header SMTP dari email yang dikirimkan. Email ini dikirimkan secara normal ke kotak masuk pengguna :

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

Gmail juga akan mengirimkan email ke kotak masuk pengguna, tetapi akan menimbulkan kesalahan SPF yang berbeda:

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

Jadi apa yang terjadi di sini? Mengapa email dikirim meskipun ada SPF hardfail? Apakah memiliki catatan SPF yang rusak berarti bahwa server SMTP lainnya mengabaikan SPF sepenuhnya? Atau ada sesuatu yang saya lewatkan di sini ...

SPF sangat buruk dikonfigurasi oleh begitu banyak situs yang menerima MTA sering dianggap hardfailhanya sebagai penasihat, dan hanya memasukkannya ke dalam skor deteksi spam mereka. Pada akhirnya tergantung pada administrator MTA tentang bagaimana kegagalan SPF akan diperlakukan.

Kondisi kesalahan SPF tidak menunjukkan apa pun tentang kebijakan yang diinginkan. Karena itu mereka tidak memberikan panduan, apakah menerima pesan atau tidak. Mungkin saja kebijakan yang dimaksud adalah +all. Adalah normal untuk menerima email dalam hal ini. Tampaknya Google bersikap lunak terhadap kegagalan domain ini untuk mematuhi standar.

Bahkan penolakan kebijakan SPF ( -all) tidak dapat diandalkan saat memvalidasi alamat pengirim. Ada beberapa kasus di mana penolakan terhadap surat semacam itu tidak pantas termasuk:

• Email yang dikirim oleh pengirim yang dikontrak (Orang-orang ini dibayar untuk melanggar kebijakan.);
• Email yang dikirim dari formulir web dan sistem otomatis lainnya;
• Surat diteruskan oleh milis atau mekanisme penerusan lainnya; dan
• Hanya kesalahan konfigurasi pada catatan SPF (tidak umum, tetapi tidak cukup langka).

Saya menjalankan server yang cukup kecil di mana saya dapat menunda hard-gagal. Ini memungkinkan saya membuat daftar putih kegagalan yang sah. Jika pengirim memperhatikan bahwa surat tidak terkirim, mereka dapat memperbaiki konfigurasinya. Dalam beberapa kasus saya akan mencoba menghubungi yang relevan postmaster, tetapi banyak domain tidak memiliki postmasteralamat.

Pengguna yang ingin menerapkan kebijakan yang lebih kuat dapat menggunakan DMARC, yang belum menjadi standar. Mail kemungkinan masih akan dikirim, tetapi dapat dikarantina atau ditolak sebagaimana ditentukan dalam kebijakan tersebut. Mail yang gagal kebijakan mungkin dikirim ke folder spam, bukan inbox normal.

SPF hard gagal tampaknya dapat diandalkan untuk memvalidasi identitas server pengirim. Saya melakukan riset beberapa waktu yang lalu, dan menemukan bahwa kegagalan soft pada nama HELO adalah alasan yang masuk akal untuk gagal atau menunda pesan yang masuk.

Banyak server email yang tidak memiliki catatan SPF. Jika server email tidak memiliki catatan SPF, saya memeriksa terhadap domain induk untuk catatan SPF. Ini tidak standar, tetapi efektif. Saya mendorong administrator email untuk memastikan ada catatan SPF untuk IP server seperti yang tercantum dalam catatan PTR. Server Anda juga harus mengidentifikasi dirinya dengan nama yang dikembalikan oleh catatan PTR-nya. Pastikan Anda memiliki catatan A yang sesuai untuk verifikasi DNS terbalik.