SPF PermError Too Many DNS Lookups: Penyebab & Solusi

Record SPF Anda terlihat benar: diawali v=spf1, memuat semua layanan yang mengirim email atas nama domain Anda, dan ditutup dengan -all. Tapi SPF checker justru menampilkan "PermError: too many DNS lookups", dan email dari domain Anda makin sering masuk folder spam. Penyebabnya hampir selalu sama: record tersebut memaksa server penerima melakukan lebih dari 10 DNS lookup, dan evaluasi SPF berhenti di situ.

Artikel ini membahas asal batas 10 lookup, cara menghitungnya sendiri (bagian include bersarang adalah tempat kebanyakan orang salah hitung), dan langkah perbaikan yang diurutkan dari yang paling aman.

Seperti apa error-nya?

Biasanya masalah ini terlihat di dua tempat. Pertama, di header email yang diterima Gmail, Outlook, atau penyedia besar lainnya. Baris Authentication-Results akan berisi kurang lebih seperti ini:

Authentication-Results: mx.example.net;
       spf=permerror (sender SPF record for example.com: too many DNS lookups)
       smtp.mailfrom=newsletter@example.com

Teks di dalam kurung bisa berbeda di tiap penerima, tetapi yang penting adalah spf=permerror. Kedua, di tool pengecek SPF online, dengan pesan seperti "too many DNS lookups", "exceeded 10 lookup limit", atau sekadar "PermError".

Kenapa ini serius?

PermError berarti penerima sama sekali tidak bisa mengevaluasi record Anda. Hasil ini tidak netral. Kebanyakan penerima memperlakukannya sama dengan SPF gagal, bahkan ada yang menganggapnya tanda konfigurasi yang rusak. Akibatnya, lebih banyak email masuk spam, sebagian ditolak, dan sinyal autentikasi yang Anda kira sudah beres ternyata tidak berfungsi.

Dampaknya juga sampai ke DMARC. DMARC lolos jika SPF atau DKIM lolos dan selaras (aligned) dengan domain di header From. Kalau SPF menghasilkan PermError, DMARC sepenuhnya bergantung pada DKIM. Jika layanan pengirim menandatangani dengan domain mereka sendiri, atau tidak menandatangani sama sekali, DMARC gagal. Dengan kebijakan p=quarantine atau p=reject, penerima akan langsung menindaklanjutinya. Periksa kebijakan Anda saat ini lewat DMARC checker.

Dari mana batas 10 lookup berasal?

SPF didefinisikan dalam RFC 7208. Bagian 4.6.4 menyatakan bahwa implementasi WAJIB (MUST) membatasi jumlah term yang memicu query DNS maksimal 10 dalam satu kali evaluasi SPF. Jika batas ini terlampaui, hasilnya permerror.

Tujuannya adalah perlindungan, baik untuk penerima maupun untuk infrastruktur DNS. Setiap email yang dicek bisa memicu rangkaian query DNS, dan rangkaian itu dikendalikan oleh record milik pengirim. Tanpa batas, record yang ditulis asal-asalan, atau sengaja dibuat jahat, bisa membuat satu email memicu puluhan bahkan ratusan lookup. Pada skala penyedia besar, itu cara murah untuk membebani server DNS. Batas ini menjaga biaya evaluasi satu record SPF tetap kecil dan bisa diprediksi.

Term apa saja yang dihitung?

Menurut RFC 7208, term berikut dihitung:

• include: dihitung satu, ditambah semua lookup di dalam record yang di-include
• a dan a:
• mx dan mx:
• ptr (RFC sendiri menyebut mekanisme ini SHOULD NOT dipublikasikan)
• exists:
• modifier redirect=

Sedangkan term berikut tidak dihitung karena tidak butuh DNS:

• ip4:
• ip6:
• all

Ada dua aturan lain di bagian yang sama. Pertama, evaluasi satu mekanisme mx tidak boleh melibatkan lebih dari 10 lookup alamat (A/AAAA) untuk host yang dikembalikannya; jika lebih, hasilnya juga PermError. Kedua, RFC menyarankan (SHOULD) agar void lookup, yaitu query yang tidak mengembalikan jawaban atau NXDOMAIN, dibatasi dua kali saja. Melebihi batas itu juga menghasilkan PermError. Aturan kedua ini sering menjebak record yang masih merujuk ke host lama atau provider yang sudah lama tidak dipakai.

Cara menghitung lookup: contoh kasus

Bagian inilah yang paling sering membingungkan. Batas 10 berlaku untuk seluruh proses evaluasi, bukan hanya record di level atas. Setiap include menarik record SPF lain, dan semua lookup di dalamnya ikut ditambahkan ke total Anda.

Misalkan sebuah perusahaan memakai layanan mailbox hosted, CRM yang mengirim notifikasi, dan platform newsletter. Nama domain provider di bawah ini hanya contoh, tetapi strukturnya umum ditemui:

example.com.  TXT  "v=spf1 a mx include:_spf.mailsuite.example include:spf.crm.example include:send.newsletter.example ip4:203.0.113.10 -all"

Di level atas ada lima term yang memicu DNS: a, mx, dan tiga include. Kelihatannya aman. Sekarang telusuri tiap include:

_spf.mailsuite.example     "v=spf1 include:_nb1.mailsuite.example include:_nb2.mailsuite.example include:_nb3.mailsuite.example ~all"
spf.crm.example            "v=spf1 include:spf1.crm.example include:spf2.crm.example ~all"
send.newsletter.example    "v=spf1 a include:relay.newsletter.example ~all"

Anggap record terdalam (_nb1, spf1.crm, relay.newsletter, dan seterusnya) hanya berisi rentang ip4/ip6. Hitungannya:

a                                  1
mx                                 1
include:_spf.mailsuite.example     1
  include:_nb1 / _nb2 / _nb3       3   (subtotal 4)
include:spf.crm.example            1
  include:spf1 / spf2              2   (subtotal 3)
include:send.newsletter.example    1
  a                                1
  include:relay.newsletter.example 1   (subtotal 3)
ip4:203.0.113.10                   0
-all                               0
-----------------------------------------
Total                             12   → PermError

Record yang terlihat hanya punya lima lookup ternyata butuh dua belas. Kasus seperti ini sangat umum: satu include dari provider bisa berisi beberapa lookup tambahan, dan provider bisa mengubah record mereka kapan saja tanpa memberi tahu Anda. Record yang tahun lalu masih 9 lookup bisa saja sekarang sudah 11, padahal Anda tidak mengubah apa pun.

Menghitung manual melelahkan dan rawan salah. SPF checker akan menelusuri semua include secara rekursif dan menampilkan jumlah lookup-nya, sehingga Anda bisa langsung melihat cabang mana yang paling boros.

Cara memperbaiki, dari yang paling aman

Kerjakan secara berurutan. Beberapa langkah awal nyaris tanpa risiko, sementara langkah-langkah berikutnya punya konsekuensi yang perlu dipertimbangkan.

1. Hapus include yang sudah tidak dipakai

Ini perbaikan paling mudah dan biasanya paling berdampak. Seiring waktu, record SPF menumpuk include: tool helpdesk lama, platform marketing yang hanya dicoba sebulan, hosting yang sudah ditinggalkan. Jika sebuah layanan sudah tidak mengirim email atas nama domain Anda, include-nya hanya menghabiskan jatah lookup. Hapus yang sudah tidak aktif.

2. Buang a, mx, dan ptr jika host tersebut tidak mengirim email

Banyak record memuat a dan mx karena ditambahkan otomatis oleh generator atau panel hosting. a mengizinkan IP dari A record domain Anda (sering kali web server), sedangkan mx mengizinkan server email masuk Anda. Jika website Anda tidak mengirim email langsung dan server MX bukan yang mengirim email keluar (hal yang lazim pada layanan mailbox hosted), keduanya hanya membuang lookup. Untuk ptr, hapus saja: RFC 7208 menyarankan agar tidak dipublikasikan, dan mekanisme ini lambat serta tidak andal.

3. Ganti lookup dengan ip4/ip6 untuk rentang yang stabil

Jika server milik Anda sendiri mengirim dari IP tetap, tuliskan dengan ip4: atau ip6:, bukan a:mail.example.com. Biayanya nol lookup. Cara yang sama bisa dipakai untuk provider yang memublikasikan rentang IP pengiriman resmi, tetapi hati-hati: provider bisa menambah atau mencabut IP, dan begitu Anda menulisnya secara manual, Anda yang bertanggung jawab mengikuti perubahannya. Kalau ragu, pertahankan include dari provider dan gunakan IP manual hanya untuk infrastruktur milik sendiri.

4. Pindahkan email massal atau marketing ke subdomain

Setiap domain dan subdomain punya record SPF sendiri dengan jatah 10 lookup sendiri. Jika platform newsletter mengirim dari news.example.com dan layanan email transaksional dari mail.example.com, masing-masing subdomain cukup memuat include untuk pengirimnya saja. Domain utama pun cukup mencakup penyedia mailbox Anda. Bonusnya, reputasi juga terpisah: kampanye marketing yang banyak dilaporkan spam tidak ikut menyeret email harian Anda. Gunakan SPF generator untuk membuat record yang rapi di tiap subdomain.

5. Andalkan DMARC dengan DKIM yang selaras

Karena DMARC lolos jika SPF atau DKIM lolos dan selaras, layanan yang menandatangani DKIM dengan domain Anda sebenarnya tidak wajib ada di record SPF agar DMARC lolos. Ada juga layanan pihak ketiga yang mengirim dengan return-path milik mereka sendiri. Dalam kasus itu SPF dicek terhadap domain mereka, bukan domain Anda, sehingga menambahkan include mereka ke record Anda tidak membantu alignment sama sekali. Aktifkan DKIM dengan domain sendiri di setiap layanan yang mendukungnya, dan Anda mungkin menemukan beberapa include yang ternyata tidak berguna. Namun jangan buang SPF sepenuhnya: sebagian penerima masih menilai SPF secara terpisah, dan forwarding dalam kondisi tertentu bisa merusak DKIM.

6. SPF flattening (pahami untung-ruginya)

"Flattening" berarti menerjemahkan semua include menjadi rentang IP di baliknya, lalu memublikasikannya sebagai entri ip4/ip6. Jika dilakukan manual sekali jalan, hasilnya rapuh. Layanan flattening biasanya mengotomatiskannya: mereka memantau record provider Anda lalu memperbarui record hasil flattening, sering kali lewat include yang mereka host atau lewat otomasi DNS.

Manfaatnya nyata: banyak pengirim bisa diizinkan dengan sangat sedikit lookup. Tapi risikonya juga nyata:

• IP basi. Jika provider menambah rentang IP baru dan record Anda belum diperbarui, email dari rentang itu gagal SPF. Flattening manual sama sekali tidak punya mekanisme pembaruan.
• Ukuran record. Menguraikan banyak include bisa menghasilkan record yang panjang. Respons DNS yang terlalu besar bisa bermasalah di sebagian resolver, sehingga tool flattening sering memecahnya ke beberapa record.
• Ketergantungan. Dengan layanan hosted, autentikasi email Anda bergantung pada vendor tersebut tetap online dan datanya selalu mutakhir.

Flattening masuk akal jika Anda memang butuh banyak pengirim di satu domain dan langkah 1–5 belum cukup. Jangan jadikan langkah pertama.

Checklist singkat

1. Cek domain dengan SPF checker dan catat total lookup, termasuk include bersarang.
2. Daftar semua layanan yang benar-benar mengirim email atas nama domain Anda saat ini.
3. Hapus include untuk layanan yang sudah tidak mengirim.
4. Hapus ptr, serta a/mx jika host tersebut tidak mengirim email keluar.
5. Ganti lookup untuk server ber-IP tetap milik sendiri dengan ip4/ip6.
6. Pindahkan pengirim massal atau marketing ke subdomain dengan record SPF sendiri.
7. Aktifkan DKIM dengan domain sendiri di setiap layanan, lalu pastikan record DMARC sudah benar.
8. Pastikan hanya ada satu record SPF per domain, lalu cek ulang setelah propagasi DNS.
9. Cek ulang secara berkala karena provider bisa mengubah include mereka.

FAQ

Apakah include bersarang ikut dihitung dalam batas 10?

Ya. Batas ini berlaku untuk seluruh evaluasi. Setiap include dihitung satu, ditambah setiap term pemicu DNS di dalam record yang di-include, termasuk include di dalamnya lagi.

Apakah ip4, ip6, dan all dihitung?

Tidak. RFC 7208 hanya menghitung include, a, mx, ptr, exists, dan modifier redirect. Tiga term tersebut tidak memerlukan query DNS.

Bolehkah saya membuat dua record SPF untuk membagi jatah lookup?

Tidak. Satu domain hanya boleh punya satu record SPF; dua record justru menghasilkan PermError tersendiri. Jika butuh ruang lebih, gunakan subdomain karena masing-masing punya record dan jatah lookup sendiri.

Apa itu void lookup?

Query DNS saat evaluasi SPF yang tidak mengembalikan record atau berujung NXDOMAIN, misalnya include ke domain yang sudah tidak punya record SPF. RFC 7208 menyarankan batas dua kali; jika lebih, hasilnya PermError meskipun total lookup Anda di bawah 10.

Apakah mengganti -all menjadi ~all bisa mengatasi error ini?

Tidak. Qualifier pada all hanya berpengaruh jika evaluasi selesai normal. PermError terjadi sebelum itu, jadi mengganti -all dan ~all tidak akan menyelesaikannya. Kurangi jumlah lookup-nya.