Apa Itu SPF Record? Sintaks, Batas Lookup dan Kegagalan

Apa itu SPF record? Ini satu entri TXT di DNS domain Anda yang mendaftar server mana saja yang boleh mengirim email atas nama domain tersebut. Server penerima membaca entri itu, mencocokkan IP pengirim dengan daftarnya, lalu mengembalikan hasil pass, fail, softfail, atau neutral. SPF memverifikasi jalur pengiriman, bukan isi pesan, dan tidak mengatakan apa pun tentang alamat From yang dibaca orang.

Perbedaan itu menjelaskan sebagian besar tiket SPF yang kami temui di trace.

SPF record adalah daftar pengirim yang dipublikasikan di DNS

SPF adalah singkatan dari Sender Policy Framework, yang didefinisikan dalam RFC 7208. Record-nya berupa entri TXT di root domain yang diawali v=spf1. Contoh paling sederhana:

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"

Bacalah dari kiri ke kanan. Penerima memeriksa tiap term secara berurutan dan berhenti pada kecocokan pertama. Term all di akhir menangkap semua yang tidak cocok sebelumnya.

Domain yang diperiksa bukan header From. Yang diperiksa adalah domain di perintah SMTP MAIL FROM, yang juga disebut envelope sender atau Return-Path. Jika kosong, seperti pada bounce, penerima kembali ke nama HELO.

Mekanisme: ip4, ip6, a, mx, include, exists

Setiap term adalah sebuah mekanisme, dengan qualifier opsional di depannya. Enam mekanisme ini mencakup hampir semua record nyata.

• ip4: / ip6: cocok dengan alamat literal atau rentang CIDR. Tidak memakan lookup.

• a cocok dengan record A/AAAA sebuah domain. Memakan satu lookup.

• mx cocok dengan host di record MX domain. Memakan satu lookup ditambah satu per host.

• include: cocok dengan apa pun yang dicocokkan record SPF domain lain. Memakan satu lookup, ditambah semua yang bersarang di dalamnya.

• exists: cocok dengan record A untuk nama yang dibentuk. Memakan satu lookup.

• ptr cocok dengan reverse DNS dari IP yang terhubung. Memakan lookup, dan RFC 7208 menyarankan untuk tidak dipakai.

Qualifier menentukan hasil ketika sebuah term cocok. + berarti pass dan merupakan default, - berarti fail, ~ berarti softfail, ? berarti neutral. Jadi -all berarti "tolak semua yang tidak terdaftar", dan ~all berarti "terima, tapi tandai".

Utamakan ip4: dan ip6: setiap kali Anda mengendalikan alamatnya. Keduanya tidak memakan lookup dan tidak akan rusak ketika DNS pihak lain berubah.

Batas 10 lookup adalah kendala yang paling sering memutus record nyata

RFC 7208 membatasi satu evaluasi SPF hingga 10 term yang memicu query DNS: include, a, mx, ptr, exists, dan modifier redirect. Include yang bersarang ikut dihitung. Lebih dari 10, hasilnya permerror, dan pemeriksaan gagal secara permanen alih-alih kembali ke metode lain.

Ada batas kedua yang kurang mendapat perhatian. Term yang mengembalikan jawaban kosong atau NXDOMAIN disebut void lookup, dan spesifikasi membatasinya hingga dua. include: yang masih menunjuk ke vendor yang sudah Anda hentikan tahun lalu adalah void lookup yang tetap Anda bayar.

Begini tim biasanya menyentuh batas itu. Google Workspace memakai satu include. Penyedia transactional memakai satu. Platform marketing memakai satu dan di dalamnya bersarang tiga lagi. Help desk, CRM, dan tool penagihan menambah empat. Anda sudah di angka 11 tanpa melakukan hal yang tidak biasa.

Kegagalannya senyap. Email tetap terkirim, dan sebagian penerima tetap mengantarkannya, tetapi SPF tidak lagi mengautentikasi apa pun untuk Anda. Jika Anda mengandalkan alignment DMARC lewat SPF, jalur itu hilang sampai Anda meratakan record atau menghapus pengirim.

Ada tiga perbaikan yang terbukti, diurutkan dari yang paling disarankan:

1. Hapus pengirim yang sudah tidak Anda pakai. Audit include terhadap laporan agregat DMARC 90 hari terakhir.

2. Pindahkan trafik massal ke subdomain seperti mail.example.com dengan record SPF sendiri dan anggaran 10 lookup sendiri.

3. Ratakan include menjadi rentang ip4: literal, tetapi hanya dengan otomasi. Vendor merotasi IP, dan record yang diratakan manual akan usang tanpa peringatan apa pun.

Publikasikan tepat satu SPF record per domain

Sebuah domain tidak boleh mempublikasikan dua record SPF. Jika penerima menemukan dua entri TXT v=spf1, hasilnya permerror, sama seperti batas lookup. Ini sering terjadi ketika satu orang menambah record untuk tool baru, sementara orang lain sudah memasang record yang ada.

Perbaikannya mekanis. Gabungkan term ke dalam satu record, dengan satu v=spf1 di awal dan satu all di akhir. Semua yang diminta dokumentasi vendor ditambahkan di dalam record yang sudah ada sebagai include: lain, jangan pernah sebagai entri TXT baru.

Dua jebakan kecil. String TXT lebih dari 255 karakter harus dipecah menjadi beberapa string bertanda kutip di dalam record yang sama, dan sebagian besar penyedia DNS melakukannya untuk Anda. Jaga total respons di bawah sekitar 450 byte jika memungkinkan, karena respons yang lebih besar bisa berpindah dari UDP ke TCP dan beberapa resolver menanganinya dengan buruk.

Softfail atau hardfail: pilih sesuai apa yang bisa Anda lihat

Term all adalah pernyataan kebijakan, dan saran default ("pakai -all") melewatkan bagian yang penting. Hard fail hanya aman jika Anda tahu setiap pengirim yang sah.

Aturan praktis kami dari membaca trace:

• ~all selama Anda masih mendata pengirim, atau jika Anda meneruskan email dan tidak bisa mengendalikan jalurnya.

• -all setelah laporan DMARC menunjukkan setiap sumber yang sah lolos selama beberapa minggu.

• Jangan pernah +all, yang mengizinkan seluruh internet, dan jangan pakai ?all di domain produksi.

Dalam praktik, perbedaannya lebih kecil dari yang orang kira. Sebagian besar penerima besar memperlakukan SPF sebagai salah satu sinyal di antara beberapa sinyal, dan jika kebijakan DMARC sudah terpasang, vonis DMARC yang menentukan. Meski begitu, -all pada record yang belum lengkap adalah cara tercepat untuk kehilangan email invoice.

SPF rusak saat diteruskan, dan itu memang disengaja

SPF memvalidasi IP yang terhubung ke server penerima. Ketika sebuah pesan diteruskan, didistribusikan ulang oleh mailing list, atau dirilay oleh layanan alias, IP yang terhubung adalah milik forwarder, bukan milik Anda. Pemeriksaan SPF gagal walaupun Anda tidak melakukan kesalahan apa pun.

Anda tidak bisa memperbaikinya di dalam SPF. Itulah alasan DKIM ada di samping SPF: tanda tangan ikut melewati hop, sedangkan daftar IP tidak. Domain yang hanya bergantung pada SPF akan melihat kegagalan autentikasi di setiap email yang diteruskan.

Itu juga sebabnya SPF saja tidak memenuhi DMARC untuk email yang diteruskan. Rencanakan agar DKIM yang membawa pesan-pesan tersebut.

Alignment SPF: lolos saja tidak sama dengan cocok dengan domain From

Sebuah pesan bisa lolos SPF tetapi tetap gagal DMARC. DMARC membutuhkan domain yang lolos SPF, yaitu domain Return-Path, untuk cocok dengan domain From yang terlihat. Banyak penyedia bersama memakai domain bounce mereka sendiri secara default, jadi SPF lolos untuk provider-mail.net dan tidak berkata apa pun tentang example.com.

Periksa ini di raw header. Pada baris Authentication-Results, lihat smtp.mailfrom=. Jika itu bukan domain Anda atau subdomain dari domain Anda, SPF lolos tanpa membantu Anda.

Solusinya adalah Return-Path kustom di subdomain Anda sendiri, yang didukung sebagian besar pengirim serius. Postmark, Resend, Mailgun, dan SendGrid semuanya mendokumentasikan pengaturan ini, meski tidak selalu aktif secara default.

Penyedia inbox kini mengharapkan autentikasi dari setiap pengirim

Sejak Februari 2024, Google mewajibkan semua pengirim untuk mengautentikasi dengan SPF atau DKIM, dan pengirim yang mengirim lebih dari 5.000 pesan per hari ke Gmail wajib memiliki SPF, DKIM, dan DMARC. Rinciannya ada di panduan pengirim email Google. Yahoo menetapkan aturan serupa pada waktu yang sama.

Ini memindahkan SPF dari "bagus kalau ada" menjadi prasyarat pengiriman. Record yang hilang atau rusak sekarang muncul sebagai penolakan dan penempatan di spam, bukan sekadar skor reputasi yang turun.

Bacaan kami setelah beberapa tahun membaca trace: aturan ini sebagian besar menjaring domain tanpa autentikasi sama sekali dan pengirim dengan rasio keluhan spam tinggi. Record SPF yang benar saja tidak akan membawa Anda ke inbox, tetapi record yang hilang pasti membuat Anda tersisih.

Cara memeriksa dan memperbaiki SPF record dalam empat langkah

Kerjakan berurutan, dan periksa ulang setelah setiap perubahan DNS.

1. Ambil record saat ini. Jalankan dig +short TXT example.com dan cari entri yang diawali v=spf1. Jika ada dua, gabungkan.

2. Hitung lookup. Jumlahkan include, a, mx, exists, redirect, dan semua yang bersarang di dalam include. Jika sudah 8 atau lebih, rencanakan pembersihannya sekarang, bukan saat sudah di angka 11.

3. Daftar pengirim yang nyata. Gunakan laporan agregat DMARC atau header Authentication-Results dari kiriman uji. Tambahkan hanya sumber yang benar-benar muncul.

4. Kirim tes dan baca header-nya. Hasilnya harus spf=pass dengan smtp.mailfrom di domain Anda.

Perubahan DNS butuh waktu untuk menyebar, dan TTL record Anda saat ini menentukan berapa lama jawaban lama bertahan. Turunkan ke 300 detik sehari sebelum perubahan yang direncanakan.

Contoh record untuk perusahaan SaaS dengan tiga pengirim

Ambil produk yang mengirim dari Google Workspace, penyedia transactional, dan help desk. Record yang bersih terlihat seperti ini:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.transactional.example include:spf.helpdesk.example -all"

Itu tiga include, dan masing-masing menyembunyikan lookup bersarangnya sendiri. Hitung sebelum publikasi, karena panjang yang terlihat tidak memberi tahu anggaran yang sebenarnya. Record dengan tiga include bisa sudah berada di 7 atau 8 lookup.

Sekarang pisahkan berdasarkan tujuan. Simpan email manusia di root domain. Letakkan notifikasi produk di notify.example.com dengan record yang hanya mencantumkan penyedia transactional. Record root tetap pendek, subdomain mendapat anggaran 10 lookup sendiri, dan masalah reputasi di satu aliran tidak lagi menyeret aliran yang lain.

Pemisahan ini juga membuat laporan DMARC lebih mudah dibaca. Setiap aliran punya domain Return-Path sendiri, jadi kegagalan mengarah ke satu pengirim, bukan tumpukan pengirim.

Yang tidak bisa dilakukan SPF

SPF tidak bisa menghentikan seseorang memalsukan alamat From Anda, karena ia tidak pernah memeriksa header itu. SPF tidak mengenkripsi apa pun. SPF tidak akan memberi tahu Anda mengapa sebuah pesan masuk ke spam. Dan SPF tidak bisa diskalakan melewati anggaran 10 lookup tanpa pemeliharaan berkelanjutan.

Perlakukan SPF sebagai salah satu dari tiga record yang dipublikasikan bersamaan: SPF untuk jalur pengiriman, DKIM untuk integritas pesan, dan DMARC untuk kebijakan yang mengikat semuanya ke domain From Anda. Jika Anda sudah memasang SPF dan belum ada yang lain, langkah konkret berikutnya adalah mempublikasikan record DMARC dengan p=none dan membaca laporannya selama dua minggu.