Kenapa SPF Jadi Permerror Setelah Menambah Record Relay Email Baru

Banyak pengelola domain baru menyadari ada yang salah ketika email keluar tiba-tiba ditolak oleh server penerima besar atau berakhir di folder spam tepat setelah mereka menambahkan satu baris relay email baru. Di header pesan, status autentikasi yang tadinya spf=pass mendadak berubah menjadi spf=permerror. Kesalahan ini hampir selalu bermuara pada satu aturan fundamental di protokol email: batas sepuluh DNS lookup yang terlampaui. Di meja bantuan hosting, kasus ini sangat sering muncul saat sebuah bisnis berkembang. Awalnya domain hanya memakai Google Workspace atau Microsoft 365, lalu tim marketing menambahkan platform buletin, tim support menambahkan helpdesk pihak ketiga, dan tim developer menyematkan layanan SMTP transaksional. Tanpa disadari, tumpukan mekanisme include di dalam satu baris TXT record memicu pohon pencarian DNS yang melebihi batas toleransi standar internet.

Kenapa Batas Sepuluh Lookup Itu Ada di RFC 7208

Spesifikasi Sender Policy Framework (SPF) dalam RFC 7208 secara eksplisit membatasi proses validasi maksimal sepuluh DNS lookup query. Pembatasan ini bukan angka acak yang dibuat untuk mempersulit kita, melainkan pengaman terhadap serangan denial of service (DoS) dan pengurasan memori pada resolver DNS. Bayangkan jika tidak ada batas evaluasi. Seorang penyerang bisa saja membuat domain dengan SPF record yang merujuk pada puluhan domain lain secara berantai, membentuk lingkaran (loop), atau sengaja menunjuk ke ratusan nameserver target. Ketika server penerima menerima kiriman email dari domain tersebut, mail server penerima akan dipaksa melakukan ratusan query rekursif ke seluruh penjuru internet hanya untuk memverifikasi satu baris alamat pengirim. Untuk mencegah amplifikasi beban dan eksploitasi loop pada sistem resolver, mail transfer agent (MTA) penerima diinstruksikan untuk langsung berhenti dan membuang status validasi menjadi permerror begitu hitungan query kesebelas diminta. Bagi server penerima yang menjalankan kebijakan DMARC secara ketat (p=reject), status permerror ini diperlakukan sebagai kegagalan validasi total. Akibatnya, email penting perusahaan seperti faktur pembayaran, tagihan, atau notifikasi login akan dibuang di tingkat gateway sebelum menyentuh kotak masuk penerima.

Menghitung Rantai Lookup yang Sering Tidak Terlihat

Kesalahan umum yang sering terjadi adalah mengira batas sepuluh lookup dihitung dari jumlah kata atau tag yang kita ketik di DNS control panel. Kita melihat baris SPF di domain sendiri hanya punya empat entri include, lalu berasumsi jatah lookup masih tersisa enam. Asumsi ini berbahaya karena mekanisme include bersifat rekursif. Mekanisme yang memakan kuota pencarian DNS meliputi include, a, mx, ptr, exists, dan redirect. Sebaliknya, mekanisme ip4, ip6, dan all sama sekali tidak menambah kuota lookup karena nilainya dievaluasi langsung secara lokal dari teks record tanpa perlu query resolver tambahan. Ketika kamu menyematkan include:relaypihakketiga.com, server penerima akan melakukan DNS request baru untuk membaca record SPF milik layanan tersebut. Masalahnya, layanan pihak ketiga itu sering kali memecah konfigurasi mereka ke dalam beberapa include internal lainnya. Misalnya, satu include dari platform marketing besar bisa memicu tiga hingga empat DNS query lanjutan di balik layar. Jika kamu memasukkan tiga layanan berbeda ke dalam domain utama, kalkulasi kumulatifnya bisa langsung menembus angka 11 atau 12 lookup dalam sekejap. Selain itu, banyak orang masih mempertahankan mekanisme mx atau a di dalam record SPF mereka tanpa sadar bahwa mekanisme tersebut memakan jatah lookup. Jika domain kita sudah mengarahkan pengiriman lewat relay tertentu, mengecek record mx ke DNS sering kali menjadi pemborosan kuota yang sia-sia.

Melacak Pohon DNS dengan dig Secara Mandiri

Untuk mengetahui apakah SPF domain kita sudah berada di ambang batas atau melewati kuota, kita tidak perlu selalu bergantung pada alat validasi web pihak ketiga. Melakukan query langsung lewat terminal memberikan pemahaman yang jauh lebih akurat tentang bagaimana resolver melihat rantai record kita. Kita bisa menggunakan utilitas standar dig untuk memeriksa isi record TXT dan menelusuri setiap include yang ada di dalamnya secara bertahap:

BASH

# Ambil SPF record dari domain utama
dig +short TXT example.com | grep 'v=spf1'

# Contoh output yang didapat:
# "v=spf1 include:_spf.google.com include:relay.transaksional.com include:mail.marketing.com -all"

# Periksa rantai include dari salah satu penyedia transaksional
dig +short TXT relay.transaksional.com | grep 'v=spf1'

# Contoh output jika penyedia memecah record mereka lagi:
# "v=spf1 include:_netblocks.relay.com include:_netblocks2.relay.com ~all"

Dari penelusuran manual seperti di atas, kita bisa mencatat berapa total hop DNS yang dijalankan MTA penerima. Jika satu vendor transaksional saja membutuhkan 3 lookup, ditambah Google Workspace yang memakan beberapa lookup, total kuota cepat terkikis. Latihan membaca rantai rekursif ini sangat membantu tim teknis memahami di include mana beban query melonjak.

Menata Ulang Arsitektur dan SPF Record

Solusi paling instan yang sering dipilih orang saat terkena permerror adalah teknik yang disebut SPF flattening. Teknik ini mengganti seluruh mekanisme include menjadi daftar blok IP mentah menggunakan format ip4: atau ip6:. Karena notasi IP tidak membutuhkan DNS query tambahan, jumlah lookup langsung turun menjadi nol. Namun, pendekatan flattening membawa risiko operasional yang nyata. Penyedia relay cloud secara rutin mengubah, menambah, atau memensiunkan subnet IP mereka untuk pemeliharaan jaringan. Jika kita menyalin IP mentah ke record domain kita tanpa proses pembaruan berkala, email akan kembali gagal terkirim (softfail atau fail) saat vendor mulai merutekan email melalui rentang IP baru yang belum sempat kita catat. Langkah paling sehat dan stabil adalah memisahkan fungsi pengiriman email berdasarkan domain atau subdomain, bukan menumpuk semua layanan pihak ketiga ke dalam satu domain apex (example.com).

TEXT

# Record untuk domain utama (khusus komunikasi internal dan surat bisnis)
example.com.         TXT "v=spf1 include:_spf.google.com -all"

# Record terpisah untuk email transaksional aplikasi web
notify.example.com.  TXT "v=spf1 include:relay.transaksional.com -all"

# Record terpisah untuk pengiriman promosi dan newsletter
promo.example.com.   TXT "v=spf1 include:mail.marketing.com -all"

Dengan memisahkan subdomain pengirim seperti contoh di atas, kuota lookup masing-masing fungsi berdiri sendiri dan tidak saling mengganggu. Layanan marketing bisa memperbarui konfigurasi rantai server mereka tanpa membahayakan reputasi atau kapasitas lookup domain utama yang digunakan oleh para staf kantor. Jika pemisahan subdomain belum memungkinkan karena keterbatasan integrasi aplikasi legacy, bersihkan mekanisme lama yang mubazir. Hapus tag ptr yang sudah usang, buang mekanisme a dan mx jika pengiriman memang tidak pernah berasal dari IP server web lokal, dan evaluasi kembali apakah ada platform pengirim email lama yang layanannya sudah dihentikan tetapi record-nya masih tertinggal di DNS. Menjaga SPF tetap valid bukan soal seberapa banyak layanan yang bisa kita jejalkan ke dalam satu baris teks, melainkan bagaimana kita mengisolasi tanggung jawab pengiriman email dengan batas arsitektur yang rapi. Sebelum menambahkan include baru dari instruksi dokumentasi vendor apa pun, selalu biasakan menghitung kedalaman include bawaan mereka agar integritas pengiriman email domain kamu tetap terjaga.