Kerangka Kebijakan Pengirim (SPF): Lapisan Perlindungan dalam Infrastruktur Email

Diterbitkan: 2020-03-04

Pernahkah Anda memiliki seseorang (bermain-main atau jahat) mengambil ponsel Anda dan mengirim pesan kepada seseorang yang berpura-pura menjadi Anda? Rasanya sangat tidak enak, bukan? Bahkan setelah Anda mengklarifikasi fakta dengan penerima, mereka kemungkinan akan waspada terhadap semua SMS Anda di masa mendatang. Dan Anda mungkin akan lebih berhati-hati dengan siapa Anda meminjamkan telepon Anda. Kepercayaan telah rusak.

Skenario serupa mungkin terjadi di dunia email, dan calon phisher tidak memerlukan nama pengguna dan sandi Anda untuk meniru identitas bisnis Anda. Menakutkan, bukan?

Untungnya, kami mengetahui trik sederhana dan tidak terlalu rahasia untuk melindungi reputasi merek Anda. Ini disebut Kerangka Kebijakan Pengirim (SPF), dan ini adalah penyelamat reputasi email.

Ketika email dikirim dari satu server ke server lain, protokol transfer surat sederhana (SMTP) digunakan untuk mengirimkan pesan dari pengirim ke penerima. Sebagai layanan SMTP, Twilio SendGrid memfasilitasi proses ini.

Salah satu kelemahan keamanan dalam infrastruktur email adalah kemampuan pengirim atau host mana pun untuk mengidentifikasi diri mereka sendiri, dan email mereka, sebagai domain apa pun yang mereka inginkan (seperti bagaimana orang membuat BANYAK akun Twitter Donald Trump). Hal ini membuat penerima sulit untuk percaya bahwa pesan sebenarnya dari siapa yang dikatakan. Itu juga membuat pengirim tidak nyaman mengetahui siapa pun di luar sana dapat mengirim email dari domain mereka dan berpotensi merusak reputasi merek mereka.

Penerima kehilangan kepercayaan pada keaslian email dan pengirim adalah penipu paranoid yang menyamar sebagai merek mereka— tidak baik untuk siapa pun! Bagian dari solusinya adalah catatan SPF yang disimpan dalam catatan txt di DNS. Dalam artikel ini, kita akan menjelajahi semua hal tentang SPF—mulai dari menemukan kesalahan pada kesalahan Anda sendiri, kami membahas semuanya.

Apa itu Catatan SPF?

SPF adalah singkatan dari Sender Policy Framework. Ini adalah metode otentikasi email yang membantu mengidentifikasi server email yang diizinkan untuk mengirim email dari domain tertentu. Dengan menggunakan protokol validasi ini, ISP dapat menentukan kapan spoofer dan phisher mencoba memalsukan email dari domain Anda untuk mengirim email berbahaya ke pengguna Anda.

Dengan SPF, penerima dapat merasa yakin bahwa pesan email yang mereka terima berasal dari orang yang mereka harapkan. Dan pengirim dapat merasa tenang karena mengetahui bahwa phisher tidak memalsukan email atau mengelabui audiens mereka dari merek mereka.

Secara lebih teknis, data SPF adalah baris teks pendek yang ditambahkan oleh administrator domain ke data txt mereka. Data txt disimpan dalam DNS (sistem nama domain) bersama dengan data A, PTR, dan MX. Catatan SPF terlihat seperti ini:

“v=spf1 ip4:12.34.56.78 sertakan:contoh.com -semua”

Bagaimana SPF bekerja?

Baris teks di atas digunakan untuk memberi tahu server SMTP penerima host mana yang diizinkan untuk mengirim email dari domain tertentu.

Catatan SPF biasanya diperiksa sangat awal dalam percakapan SMTP, jauh sebelum isi pesan dikirim. Ketika upaya dilakukan untuk mengirim pesan, koneksi TCP dibuka antara pengirim dan server penerima.

Setelah koneksi dibuat, perintah HELO dikeluarkan, yang pada dasarnya memberi tahu server penerima domain mana yang mencoba mengirimnya surat. Ini diikuti oleh perintah MAIL FROM yang memberi tahu server penerima dari alamat email mana pesan itu berasal. Domain yang ditemukan dalam perintah MAIL FROM (juga dikenal sebagai amplop dari dan jalur kembali) adalah domain yang digunakan untuk pemeriksaan catatan SPF.

Jadi misalkan sebuah pesan telah diterima, dan alamat MAIL FROM adalah [email protected]. Server penerima akan memeriksa catatan DNS publik untuk example.com dan mencari catatan TXT yang dimulai dengan v=spf1. Jika tidak ada data TXT yang dimulai dengan v=spf1, otentikasi akan lolos. Jika ada lebih dari satu catatan TXT yang berisi v=spf1, kesalahan mungkin terjadi.

Asumsikan satu ditemukan, dan sepertinya contoh kita sebelumnya:

“v=spf1 ip4:12.34.56.78 sertakan:contoh.com -semua”

Server penerima sekarang akan memeriksa untuk melihat apakah alamat IP klien SMTP yang mencoba mengirim pesan disertakan dalam catatan SPF. Jika alamat IP terdaftar, pesan akan melewati otentikasi SPF.

Seluk-beluknya: memecah setiap bagian dari catatan SPF

Catatan SPF terdiri dari berbagai mekanisme, termasuk:

TERMASUK

Selalu diikuti oleh nama domain. Saat server penerima menemukan mekanisme penyertaan, data SPF untuk domain tersebut diperiksa. Jika IP pengirim muncul di catatan itu, email diautentikasi dan pemeriksaan SPF selesai. Jika tidak ditemukan, pemeriksaan SPF beralih ke mekanisme berikutnya.

SEBUAH

Juga diikuti oleh nama domain. Namun dalam kasus ini, SPF hanya memeriksa alamat IP yang terkait dengan domain tersebut. Jika cocok dengan IP pengirim, itu lolos, dan pemeriksaan SPF berhenti. Jika tidak, ia beralih ke mekanisme berikutnya.

MX

Mirip dengan "A." Itu selalu diikuti oleh nama domain. Jika domain yang terdaftar ditetapkan ke alamat IP klien pengirim, otentikasi lolos, dan pemeriksaan SPF selesai. Jika tidak, ia beralih ke mekanisme berikutnya.

IP4 dan IP6

Selalu diikuti dengan alamat IP atau rentang CIDR tertentu. Jika IP klien pengirim terdaftar setelah mekanisme IP4 atau IP6 apa pun, otentikasi akan lolos dan pemeriksaan SPF selesai. Jika tidak, ia beralih ke mekanisme berikutnya.

PTR

Tidak boleh disertakan dalam catatan SPF. Untuk beberapa alasan teknis, mereka rentan terhadap kesalahan dan menghabiskan banyak memori dan bandwidth untuk diselesaikan oleh server penerima. Beberapa server akan gagal dalam otentikasi SPF berdasarkan adanya mekanisme PTR.

MENGALIHKAN

Meskipun secara teknis pengubah, bukan mekanisme, ini memungkinkan administrator domain untuk mengarahkan domain ke catatan SPF domain lain. Jika fungsi REDIRECT digunakan, tidak ada mekanisme lain yang dapat disertakan dalam catatan SPF, termasuk mekanisme "semua". Contoh catatan pengalihan: “v=spf1 redirect:example.com”

Mekanisme "INCLUDE," "A," "MX," "PTR," "EXISTS," dan "REDIRECT" semuanya memerlukan pencarian DNS, jadi tidak boleh lebih dari 10 di antaranya. Ini tampaknya cukup sederhana, tetapi ini juga mencakup pencarian DNS bersarang, yang berarti "TERMASUKKAN" yang mengarah ke catatan SPF lain yang memiliki dua mekanisme "TERMASUKKAN" lagi akan dihitung sebagai tiga pencarian DNS. Mereka bertambah dengan cepat!

Bagaimana dengan pelanggan Twilio SendGrid?

Sebagian besar pengirim kami telah menyiapkan CNAME yang mengarahkan domain pengiriman mereka ke sendgrid.net. Ini berarti server penerima melihat CNAME menunjuk ke sendgrid.net, dan memeriksa catatan SPF itu. Jadi, jangan heran jika sebagian besar data SPF yang Anda kueri identik.

Untuk pertanyaan spesifik Twilio SendGrid lainnya, lihat halaman dokumen Kerangka Kebijakan Pengirim kami. Ini memiliki jawaban tambahan untuk beberapa pertanyaan dan skenario umum.

Bagaimana cara memeriksa data SPF saya?

Tidak semua orang menggunakan otentikasi SPF, tetapi penerima yang menolak berdasarkan kegagalan SPF akan menolak pengiriman. Beberapa penerima juga dapat mengarantina email yang gagal SPF tanpa memblokirnya.

Setiap catatan SPF akan sedikit berbeda, tetapi Anda harus memeriksa untuk memastikan Anda melakukannya dengan benar. Berikut adalah tiga alat yang dapat membantu memvalidasi catatan Anda:

Alat Pengujian SPF Scott Kitterman : Periksa apakah data SPF sudah ada untuk domain Anda, periksa validitasnya, atau uji kinerjanya.
OpenSPF.org : Tinjau serangkaian formulir dan penguji berbasis email.
Pemeriksaan Catatan SPF: Pemeriksaan Catatan SPF bertindak sebagai pencarian data SPF dan validator. Ini akan mencari catatan SPF untuk nama domain yang ditanyakan dan menjalankan tes diagnostik terhadap catatan, menyoroti kesalahan yang dapat mempengaruhi pengiriman email.
SPF Wizard : SPF Wizard adalah alat pembuatan catatan SPF berbasis browser. Isi formulir dan situs menghasilkan catatan SPF untuk Anda.

Jadikan Kerangka Kebijakan Pengirim sebagai prioritas

Sederhananya, pesan email berbahaya merugikan bisnis Anda dan menurunkan saluran email. Saat phisher melihat domain Anda yang dilindungi Kerangka Kebijakan Pengirim, kemungkinan besar mereka akan beralih ke target yang lebih mudah. Meskipun SPF tidak akan mencegah spam, SPF dapat berfungsi sebagai pencegah dan membuat Anda tidak terlalu rentan terhadap serangan. Dan siapa yang tidak menginginkan itu, bukan? Itu sebabnya kami mendorong semua klien email untuk membuat data SPF.

Dikombinasikan dengan ID Pengirim, DKIM, dan DMARC, SPF memberikan tingkat keamanan email ekstra yang akan lebih mendukung pengguna Anda dengan membantu ISP mengidentifikasi email Anda dengan benar dan, pada gilirannya, para spammer.