Alat populer

Tema

Cek SPF Record — Validasi Record SPF Domain

Cek SPF domain mana pun seperti server email penerima: setiap include beserta biaya lookup DNS-nya, total berjalan terhadap batas 10, void lookup, dan hasil untuk IP pengirim mana pun, lengkap dengan term yang menentukannya.

Sumber: record TXT domain dan setiap include, lewat Google Public DNS (Cloudflare 1.1.1.1 di belakangnya) · check_host RFC 7208, dijalankan di server kami · tidak ada yang disimpan

Persis nama yang Anda ketik: SPF tidak diwariskan, jadi mail.example.com butuh record sendiri.

Coba

Apa itu record SPF?

Record SPF adalah record TXT yang mencantumkan server yang boleh mengirim email atas nama sebuah domain. Diawali v=spf1, lalu menyebut pengirim term demi term, dan ditutup dengan sikap penerima terhadap semua pengirim lainnya (RFC 7208, April 2014, masih standar saat ini).

Penerima mengeceknya terhadap alamat server yang terhubung dan domain di envelope sender, yaitu MAIL FROM atau Return-Path, bukan baris From: yang dilihat pembaca. Mengaitkan SPF dengan From: adalah tugas DMARC.

Sebuah record hanya berlaku untuk nama persis tempatnya dipublikasikan: SPF tidak diwariskan, jadi mail.example.com butuh record sendiri. Domain yang tidak mengirim email sebaiknya memublikasikan v=spf1 -all.

Record SPF, term demi termgoogle.com · TXT · direkam 24 Oktober 2026 · TTL 5 menit
v=spf1Versiinclude:_spf.google.comMekanisme · 1 lookup~allQualifier ~ · mekanisme all

Include menunjuk ke _spf.google.com · 8 rentang, tanpa lookup lanjutan

ip4:74.125.0.0/16ip4:209.85.128.0/17ip6:2001:4860:4864::/56ip6:2404:6800:4864::/56ip6:2607:f8b0:4864::/56ip6:2800:3f0:4864::/56ip6:2a00:1450:4864::/56ip6:2c0f:fb50:4864::/56~all

VersiPersis v=spf1, di paling depan: record yang diawali dengan cara lain bukan record SPF.
Mekanismeinclude, a, mx, ip4, ip6, exists, ptr, dan all, dicoba dari kiri ke kanan: kecocokan pertama yang menentukan.
Qualifier+ pass (bawaan), - fail, ~ softfail, ? neutral, ditulis di depan mekanisme.
Modifierredirect= menyerahkan pengecekan ke record lain; exp= menjelaskan sebuah fail.
Seluruh record google.com hanya tiga term: penerima mengambil include, mencocokkan IP pengirim dengan rentangnya, atau sampai di ~all. Direkam lewat Google Public DNS pada 24 Oktober 2026.

Cara cek SPF record

Ketik domain di atas dan pengecek ini membaca record TXT-nya, memilih yang diawali v=spf1, lalu mengikuti setiap include dan redirect seperti yang dilakukan server penerima, sambil menghitung setiap lookup DNS.

Secara manual, minta record TXT-nya: dig TXT example.com +short atau nslookup -type=TXT example.com. Jawabannya berisi setiap record TXT di nama itu; record SPF adalah yang diawali v=spf1, dan yang panjang datang sebagai beberapa string berkutip yang digabung SPF tanpa spasi. Setiap include adalah satu query lagi, dan Anda harus menghitungnya sendiri.

Untuk melihat apakah server tertentu boleh mengirim, beralih ke Uji IP: pengecekan yang sama dijalankan untuk alamat itu dan menampilkan term yang cocok.

dig TXT example.com +short

Setiap record TXT di nama itu, seperti yang dimiliki resolver Anda; record SPF adalah yang diawali v=spf1. Jalankan lagi untuk setiap include.

Yang ditampilkan dig, dan yang tidakgithub.com · dig TXT · direkam 24 Oktober 2026
baris perintah1 dari 24 record TXT
$ dig TXT github.com @dns1.p08.nsone.net +norec +noall +answer
github.com.  300  IN  TXT  "v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.2" "27.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all"

# lalu setiap include, satu query per kali:
$ dig +short TXT _spf.salesforce.com
"v=spf1 exists:%{i}._spf.mta.salesforce.com -all"
  1. Satu record diawali v=spf1. 23 record TXT lain di sampingnya (token verifikasi dan sejenisnya) tidak memengaruhi SPF, kecuali ukuran jawabannya.
  2. 2 string, digabung tanpa spasi. Pemecahan 255 byte jatuh di dalam ip4:62.253.227.114: penerima menggabungkan kembali string-nya, jadi tidak masalah.
  3. TTL 5 menit. Berapa lama resolver boleh menyimpan salinan ini setelah perubahan. Server milik zona sendiri menyebut 5 menit; resolver menampilkan sisa waktu salinannya.
  4. Setiap include adalah query tersendiri. Mengikuti record github.com butuh 10 lookup, termasuk yang bersarang. dig menampilkan satu nama per kali: menghitung hingga 10 adalah tugas Anda.
Windows
$ nslookup -type=TXT github.com 8.8.8.8
PowerShell
# setiap record TXT di nama itu, dari Google Public DNS
PS> Resolve-DnsName -Name github.com -Type TXT -Server 8.8.8.8
Halaman ini
/id/spf-checker?domain=github.com
Jawaban TXT github.com dari nameserver-nya sendiri: record SPF datang sebagai dua string, digabung tanpa spasi, di antara record TXT lain milik domain.

Membaca hasilnya: pohon include

Kesimpulan menyebut apa yang didapat penerima untuk pengirim yang tidak tercantum di record: valid beserta akhirannya (softfail untuk ~all, fail untuk -all), atau permerror beserta penyebabnya, atau "tidak bisa dicek" jika DNS tidak menjawab.

Kolom biru tua adalah anggaran lookup: satu sel per lookup DNS, diwarnai menurut include yang memakainya, total berjalan terhadap 10, dan void lookup sebagai cincin. Setelah lookup ke-10, sel berubah merah dan cabang tempat penerima berhenti ditandai.

Tampilan Pohon mendaftar bacaan, yang gagal lebih dulu, masing-masing dengan bagian RFC dan cara memperbaikinya, lalu setiap lookup sesuai urutan penerima bertanya.

Cek SPF untuk github.com: 10 dari 10 lookup DNS, satu void, dan biaya setiap include dalam anggaran lookupCek SPF untuk github.com: 10 dari 10 lookup DNS, satu void, dan biaya setiap include dalam anggaran lookupKesimpulanApa yang didapat penerima untuk pengirim yang tidak tercantum di record, dan akhiran yang menentukannya.Record, term demi termSetiap term diwarnai menurut jenisnya; include membawa tanda pemiliknya dan biaya lookup-nya sendiri.BacaanSatu record, sintaks valid, lookup, void, akhiran, ptr, DMARC: yang gagal lebih dulu, masing-masing dengan cara memperbaikinya.Anggaran lookupSetiap lookup DNS sebagai sel, diwarnai menurut include yang memakainya, terhadap batas 10.Biaya setiap includeSatu cabang per include: sel miliknya sendiri, yang disarangkannya, dan total berjalan.Void lookupCincin untuk query yang kembali kosong; yang ketiga mengakhiri pengecekan.
Cek SPF untuk github.com: kesimpulan, record yang dipecah menjadi term, bacaan, dan anggaran lookup beserta biaya setiap include. Pilih sebuah nomor untuk melihat arti setiap bagian.

Batas 10 lookup dan "too many DNS lookups" (permerror)

Penerima menghitung setiap term yang butuh query DNS, yaitu include, a, mx, ptr, exists, dan redirect, melalui setiap include bersarang, dan berhenti di 10. Yang ke-11 menghasilkan permerror (RFC 7208 §4.6.4). ip4, ip6, all, dan exp tidak memakai biaya.

Ini permerror, bukan fail: apa yang dilakukan penerima terhadapnya adalah keputusannya sendiri, tetapi di bawah DMARC permerror tidak pernah dihitung sebagai pass. Dan karena pengecekan berhenti di kecocokan pertama, record yang melewati batas tetap pass untuk pengirim yang tercantum di awal dan hanya rusak untuk yang tercantum belakangan.

Biayanya tersembunyi di dalam include: include:_netblocks.mimecast.com memakai 9 sendirian, Yandex 360 memakai 8, Freshdesk 7, Mailgun 5. Include Google dan Microsoft 365 masing-masing memakai 1. Untuk turun di bawah 10, hapus pengirim yang tidak lagi dipakai dan pindahkan pengirim massal ke subdomain dengan record sendiri.

Siapa yang memakai 10 lookupBiaya diukur 24 Oktober 2026 · record rekaan berisi include sungguhan

v=spf1 include:spf.protection.outlook.com include:_netblocks.mimecast.com include:mailgun.org include:sendgrid.net -all

butuh 17 lookup
Tercantum dalam 10 lookup pertama: passMicrosoft 3651Mimecast2–10
Tercantum setelah lookup 10: permerrorMailgun11–15Twilio SendGrid16–17

Semua yang lain juga mendapat permerror, bukan fail dari -all di record: penerima berhenti sebelum mencapainya.

Biaya satu includeInclude yang didokumentasikan masing-masing penyedia · diukur 24 Oktober 2026
  • _netblocks.mimecast.comMimecast9 lookup
  • _spf.yandex.netYandex 3608 lookup
  • email.freshdesk.comFreshdesk7 lookup
  • mailgun.orgMailgun5 lookup
  • icloud.comiCloud+5 lookup
  • spf.titan.emailTitan Email4 lookup
  • secureserver.netGoDaddy3 lookup
  • _spf.google.comGoogle Workspace1 lookup
  • spf.protection.outlook.comMicrosoft 3651 lookup
Lookup dihitung seperti RFC 7208 §4.6.4: include itu sendiri ditambah semua yang ada di dalamnya. Hitungan langsung di halaman ini selalu berasal dari penelusuran, bukan tabel ini.

Apa itu void lookup?

Void lookup adalah query yang kembali tanpa record: namanya tidak ada (NXDOMAIN) atau ada tanpa record yang diminta. Penerima sebaiknya mengizinkan dua; yang ketiga adalah permerror (RFC 7208 §4.6.4).

Term yang menunjuk ke host yang sudah hilang, a:old.example.com, bukan error dengan sendirinya: hanya tidak cocok dan dihitung satu void. Begitu juga exists:%{i}._spf.mta.salesforce.com untuk setiap pengirim yang tidak dicantumkan Salesforce, itulah sebabnya urutan include penting.

Kegagalan server atau timeout bukan void: itu temperror, dan penerima biasanya mencoba lagi nanti.

Empat jawaban, tiga hasilRFC 7208 §4.6.4

Record salesforce.com sendiri untuk 192.0.2.1, direkam 24 Oktober 2026

v=spf1 include:_spf.google.com include:_spf.salesforce.com exists:%{i}._spf.corp.salesforce.com ~all

Void lookup2 / 2yang ketiga: permerror
  1. exists:%{i}._spf.mta.salesforce.com192.0.2.1._spf.mta.salesforce.com → NXDOMAIN · lookup ke-3 · di _spf.salesforce.com
  2. exists:%{i}._spf.corp.salesforce.com192.0.2.1._spf.corp.salesforce.com → NXDOMAIN · lookup ke-4 · di salesforce.com

Hasil: softfail, dengan kedua void yang diizinkan terpakai

Namanya ada, recordnya tidaka:mail.example.com untuk nama yang masih ada tetapi tidak lagi punya alamat: NOERROR tanpa jawaban. Tidak cocok, satu void, dan pengecekan berlanjut.NODATAlookup kosong
Namanya tidak adaexists:%{i}._spf.mta.salesforce.com membuat nama dari setiap IP pengirim; untuk alamat yang tidak dicantumkan Salesforce, jawabannya NXDOMAIN: satu void setiap kali.NXDOMAINlookup kosong
Void ketigamx:shop.example.com, nama yang sudah hilang, setelah 2 void terpakai: penerima berhenti di sini.NXDOMAINpermerror
Tidak ada jawaban sama sekaliSERVFAIL atau timeout untuk include:_spf.vendor.example: DNS gagal, jadi tidak ada yang dihitung sebagai void.SERVFAILtemperror, bukan void

Include include:spf.bmv.jp milik blastmail diawali dua term exists seperti itu: untuk alamat yang tidak dicantumkannya, kedua void yang diizinkan terpakai habis oleh include itu sendiri.

Hanya jawaban kosong yang dihitung sebagai void. Kegagalan adalah temperror, dan pengecekan dicoba lagi nanti.

SPF flattening: kapan membantu dan kapan merusak

Flattening mengganti include dengan alamat yang dicantumkannya, sehingga record memakai lebih sedikit lookup. Cara ini cocok untuk rentang yang jarang berubah, dan berbalik merugikan jika penyedia menambah server yang tidak Anda salin: email dari server itu lalu gagal SPF.

Microsoft menyarankan untuk tidak flatten include:spf.protection.outlook.com, dan include Google dan Microsoft sudah memakai satu lookup masing-masing. Memindahkan pengirim massal ke subdomain seperti news.example.com memberinya record, dan 10 lookup, sendiri.

Satu include, di-flattenmailgun.org · direkam 24 Oktober 2026

Sebelum

include:mailgun.org

Lookup
5
Record yang diambil
5
Byte di record Anda
19
Mailgun mengubah sebuah rentang
langsung terambil

Sesudah

ip4:159.135.224.0/20 ip4:69.72.32.0/20 ip4:204.220.90.0/23 ip4:204.220.92.0/22 +18 lagi

Lookup
0
Byte di record Anda
450
String TXT yang dibutuhkan
2
Mailgun mengubah sebuah rentang
salinan Anda usang

Risiko salinan usang. Anda menyalin 22 rentang hari ini; saat Mailgun menambah satu, email darinya gagal SPF sampai ada yang menyadari dan memperbarui record.

  1. disalin
  2. Mailgun menambah rentang
  3. email darinya gagal SPF
Flatten hanya rentang yang jarang berubah, seperti alamat server Anda sendiri.
Jangan flatten Microsoft 365: Microsoft menyebut alamat pengirimnya sering berubah, jadi pertahankan include-nya.
Pilih satu subdomain per pengirim massal: masing-masing mendapat record, dan 10 lookup, sendiri.
Flattening menukar lookup dengan perawatan: salinan hanya benar sampai penyedia mengubah rentangnya.

~all vs -all (dan DMARC)

Term terakhir menentukan apa yang terjadi pada setiap pengirim yang tidak tercantum. -all adalah fail, pernyataan terkuat; ~all adalah softfail, "mungkin bukan"; ?all adalah neutral, yang diperlakukan penerima seperti tanpa SPF sama sekali; +all membuat semua orang lolos dan tidak boleh dipublikasikan.

Antara ~all dan -all tidak ada jawaban yang salah. Google mendokumentasikan ~all untuk Google Workspace dan Microsoft -all untuk Microsoft 365. Dengan DMARC yang ditegakkan, ~all membiarkan DMARC memutuskan berdasarkan DKIM: sebagian penerima menolak karena -all sebelum DMARC melihat tanda tangan DKIM yang pass, sehingga email yang diteruskan bisa bounce (RFC 9989 §7.1).

Empat akhiranRFC 7208 §2.6 · RFC 9989 §7.1
~all
softfail“Mungkin tidak diotorisasi”: penerima sebaiknya tidak menolak hanya karena ini.
Didokumentasikan olehGoogle WorkspaceMailguniCloud+
-all
failPernyataan terkuat: penerima boleh menolak pesan di SMTP.
Didokumentasikan olehMicrosoft 365ZendeskGoDaddy
?all
neutralTidak ada pernyataan sama sekali: penerima memperlakukannya persis seperti tanpa SPF.
Didokumentasikan olehFastmailInclude IONOS dan OVHcloud juga berakhir dengan ?all: tidak berbahaya di sana, karena hanya pass di dalam include yang cocok.
+all
pass untuk semua orangServer mana pun di Internet lolos sebagai domain itu.
Jangan pernah dipublikasikan

-all dengan DMARC di p=reject

  1. SPF: fail
  2. ditolak di SMTP
  3. DKIM tidak pernah dicek

Sebagian penerima bertindak berdasarkan SPF lebih dulu, jadi pesan yang diteruskan dengan tanda tangan DKIM valid bisa ditolak sebelum DMARC berjalan, dan kerugiannya tidak pernah muncul di laporan DMARC.

~all dengan DMARC di p=reject

  1. SPF: softfail
  2. DMARC mengecek DKIM
  3. DKIM yang aligned: pass

DMARC yang memutuskan. Tanpa tanda tangan DKIM, Microsoft menyebut DMARC praktis diabaikan untuk kegagalan ~all, dan karena itu merekomendasikan -all.

~all dan -all sama-sama pilihan valid; ?all tidak menyatakan apa pun, dan +all membuat siapa pun lolos.

Kesalahan SPF yang umum dan cara memperbaikinya

Kebanyakan record yang rusak berasal dari tiga kekeliruan: record SPF kedua ditambahkan di samping yang pertama alih-alih digabung, include untuk vendor yang sudah tidak dipakai, dan nilai yang disalin dari dokumentasi dengan salah ketik.

Dokumentasi vendor sendiri mencetak sebagian dari ini: Mimecast menulis –all dengan en dash, Postmark include: spf.mtasv.net dengan spasi, Twilio SendGrid mencantumkan mekanisme aaaa yang tidak ada. Kesalahan sintaks apa pun membuat seluruh record permerror. Titik di akhir domain, sebaliknya, valid.

Delapan record, delapan hasilContoh rekaan dari kesalahan nyata

Dua record SPFpermerror

v=spf1 include:_spf.google.com ~allv=spf1 include:sendgrid.net ~all

Perbaikan: gabungkan menjadi satu: satu v=spf1, setiap include sekali, satu akhiran.

Lebih dari 10 lookuppermerror

v=spf1 include:_netblocks.mimecast.com include:mailgun.org -all

14 lookup

Perbaikan: hapus pengirim yang tidak lagi dipakai, atau beri pengirim massal subdomain sendiri.

Void lookup ketigapermerror

v=spf1 a:old.example.com mx:gone.example.net exists:%{i}.spf.example.org -all

3 void

Perbaikan: hapus term yang namanya sudah hilang, dan letakkan include exists paling akhir.

Include tanpa record SPF di baliknyapermerror

v=spf1 include:spf.retired-vendor.example -all

Perbaikan: perbaiki namanya, atau hapus vendor yang sudah Anda tinggalkan.

En dash di –allpermerror

v=spf1 include:_netblocks.mimecast.com –all

Dicetak seperti ini di dokumentasi Mimecast sendiri

Perbaikan: tanda hubung biasa: -all.

Spasi setelah include:permerror

v=spf1 a mx include: spf.mtasv.net ~all

Dicetak seperti ini di dokumentasi Postmark sendiri

Perbaikan: include:spf.mtasv.net

Mekanisme aaaapermerror

v=spf1 aaaa:example.com ~all

Dicetak seperti ini di dokumentasi Twilio SendGrid sendiri

Perbaikan: a:example.com; a sudah mencocokkan record AAAA untuk pengirim IPv6.

Titik di akhirsah

v=spf1 include:spf.protection.outlook.com. -all

Valid: RFC 7208 §7.3 menyarankan untuk tidak memublikasikannya, tetapi penerima wajib menerimanya.

Bantuan Zendesk juga menyebut “redirect: syntax is supported”: modifiernya ditulis redirect= (RFC 7208 §6.1).

Setiap record adalah contoh rekaan; kesalahannya adalah yang paling sering dilihat penerima.

Yang diwajibkan Gmail, Yahoo, dan Microsoft

Sejak Februari 2024 Gmail dan Yahoo mewajibkan setiap pengirim menyiapkan SPF atau DKIM. Pengirim massal butuh keduanya, record DMARC minimal p=none, dan domain From: yang aligned dengan salah satunya. Outlook.com meminta pengirim bervolume tinggi memiliki SPF dan DKIM sekaligus, dan menolak yang tidak memilikinya sejak 5 Mei 2025.

Ambang Gmail adalah lebih dari 5.000 pesan sehari ke akun pribadi; Yahoo tidak mempublikasikan ambang apa pun. SPF saja tidak pernah membuat email "aligned": domain MAIL FROM harus milik Anda, bukan domain bounce penyedia.

Aturan tiga penyedia kotak suratDibaca di halaman resmi masing-masing penyedia, 24 Oktober 2026
GmailYahooOutlook.com
Ambang massalGmaillebih dari 5.000 pesan sehari ke akun Gmail pribadi, dihitung per domain utamaYahootidak dipublikasikan: “We will not specify a volume threshold”Outlook.comlebih dari 5.000 sehari (blog Microsoft); 5.000 atau lebih dari satu domain From: (artikel dukungannya)
Semua pengirimGmailSPF atau DKIM, plus DNS forward dan reverse, TLS, dan tingkat spam di bawah 0,3%YahooSPF atau DKIM, plus DNS forward dan reverse, dan tingkat spam di bawah 0,3%Outlook.comtidak ada aturan keras
Pengirim massalGmailSPF dan DKIM, DMARC (p=none sudah cukup), From: aligned dengan SPF atau DKIM, berhenti berlangganan satu klik untuk email pemasaranYahooSPF dan DKIM, DMARC minimal p=none dan pass, From: aligned dengan SPF atau DKIM, berhenti berlangganan satu klikOutlook.comSPF harus pass dan DKIM harus pass, DMARC minimal p=none, aligned dengan SPF atau DKIM
Berlaku sejakGmail1 Februari 2024; penolakan ditingkatkan sejak November 2025YahooFebruari 2024Outlook.com5 Mei 2025 (penolakan)
Kegagalan SPF tampil sebagaiGmail4.7.275.7.27Yahootidak didokumentasikan untuk SPFOutlook.com550 5.7.515

Jepang: pengaturan paling ketat NTT docomo, 「全て拒否する」, menolak email yang IP pengirimnya tidak diotorisasi record SPF domain, dan email dari domain yang sama sekali tidak memublikasikan record SPF. docomo.ne.jp

Sumbersupport.google.comsenders.yahooinc.comtechcommunity.microsoft.com

Aturan setiap penyedia seperti yang dinyatakan halaman resminya pada 24 Oktober 2026.

SPF lookup vs dig dan nslookup

dig dan nslookup menampilkan record TXT seperti yang dimiliki resolver Anda: record SPF dan apa pun yang ada di nama itu. Keduanya tidak mengikuti include, menghitung lookup atau void, atau menyebut apa yang akan diputuskan penerima.

SPF lookup seperti ini menelusuri seluruh record, jadi angkanya sama dengan yang dihitung server penerima. Pakai dig untuk satu nama, pengecek ini untuk kesimpulannya.

Tiga cara melihat SPFYang ditampilkan masing-masing
Pengecek inidig TXTnslookup -type=TXT
Menampilkan record TXTPengecek iniYadipecah menjadi termdig TXTYanslookup -type=TXTYa
Menggabung string record yang panjangPengecek iniYaseperti penerimadig TXTTidakmenampilkan setiap string terpisahnslookup -type=TXTTidakmenampilkan setiap string terpisah
Mengikuti setiap includePengecek iniYaseluruh pohondig TXTTidaksatu nama per querynslookup -type=TXTTidaksatu nama per query
Menghitung lookup hingga 10Pengecek iniYatotal berjalan, per includedig TXTTidakmanualnslookup -type=TXTTidakmanual
Menghitung void lookupPengecek iniYabeserta namanyadig TXTTidaknslookup -type=TXTTidak
Menyebut dua record = permerrorPengecek iniYadig TXTTidakmencetak keduanyanslookup -type=TXTTidakmencetak keduanya
Menguji IP pengirimPengecek iniYacheck_host dan term yang cocokdig TXTTidaknslookup -type=TXTTidak
Bertanya ke resolver Anda sendiriPengecek iniTidakGoogle Public DNS, dari server kamidig TXTYanslookup -type=TXTYa
Pertanyaan yang sama dengan tiga cara: dig dan nslookup menampilkan yang dimiliki resolver Anda, pengecek ini yang dihitung penerima.

Cek SPF: pertanyaan yang sering diajukan

Apa itu cek record SPF?

Cek record SPF membaca record SPF sebuah domain, yaitu record TXT yang diawali v=spf1, lalu menelusurinya seperti server email penerima: setiap include dan redirect diikuti, setiap lookup DNS dihitung terhadap batas 10 dan setiap jawaban kosong terhadap batas 2. Hasil akhirnya adalah apa yang didapat penerima untuk pengirim yang tidak tercantum, atau permerror beserta penyebabnya.

Bagaimana cara menguji apakah sebuah alamat IP boleh mengirim email untuk domain saya?

Pilih Uji IP, masukkan domain dan alamat server pengirim, IPv4 atau IPv6, dan jika mau alamat MAIL FROM serta nama HELO. Pengecek ini menjalankan check_host untuk alamat itu dan menampilkan pass, fail, softfail, neutral, atau permerror, term persis yang cocok, qualifier-nya, dan rantai include yang menuju ke sana.

Apa arti "SPF too many DNS lookups"?

Artinya pengecekan record butuh lebih dari 10 lookup DNS, batas dalam RFC 7208. Setiap include, a, mx, ptr, exists, dan redirect memakai satu, termasuk yang bersarang di dalam include. Penerima berhenti di lookup ke-11 dengan permerror, sehingga pengirim yang tercantum setelah titik itu berhenti pass SPF. Hapus include yang tidak dipakai, atau pindahkan pengirim ke subdomain dengan record sendiri.

Apa itu permerror SPF?

Permerror adalah hasil SPF untuk "record ini tidak bisa dievaluasi". Penyebabnya lebih dari 10 lookup DNS, lebih dari 2 void lookup, dua record SPF di satu nama, include nama tanpa record SPF, atau kesalahan sintaks. Ini bukan fail: penerima yang memutuskan tindakannya, tetapi di bawah DMARC permerror tidak pernah dihitung sebagai pass.

Apa itu void lookup di SPF?

Void lookup adalah query DNS untuk sebuah term SPF yang kembali kosong: namanya tidak ada (NXDOMAIN) atau tidak punya record dengan tipe yang diminta. RFC 7208 menyebut penerima sebaiknya mengizinkan dua; yang ketiga adalah permerror. Kegagalan server atau timeout bukan void lookup melainkan temperror, yang biasanya dicoba lagi oleh penerima nanti.

Haruskah record SPF saya diakhiri ~all atau -all?

Keduanya valid. -all (fail) adalah pernyataan terkuat dan didokumentasikan Microsoft untuk Microsoft 365; ~all (softfail) adalah yang didokumentasikan Google untuk Google Workspace. Dengan tanda tangan DKIM dan DMARC di quarantine atau reject, ~all sering menjadi akhiran yang lebih aman, karena sebagian penerima menolak karena -all sebelum DMARC bisa menerima tanda tangan DKIM yang pass.

Bolehkah sebuah domain punya dua record SPF?

Tidak. Jika sebuah nama punya dua record TXT yang diawali v=spf1, penerima tidak bisa memilih salah satu dan pengecekan berakhir dengan permerror sebelum lookup apa pun, untuk setiap pengirim (RFC 7208 §4.5). Ini biasanya terjadi saat record penyedia baru ditambahkan di samping yang lama. Gabungkan menjadi satu record dengan satu v=spf1, setiap include sekali, dan satu akhiran.

Apa itu SPF flattening, dan haruskah saya memakainya?

Flattening mengganti include dengan rentang IP yang dicantumkannya, sehingga record butuh lebih sedikit lookup DNS. Cara ini membantu untuk rentang yang jarang berubah, tetapi salinan yang di-flatten menjadi usang begitu penyedia menambah server, dan email dari server itu lalu gagal SPF. Lebih baik hapus include yang tidak dipakai atau beri pengirim massal subdomain sendiri; jangan pernah flatten include Microsoft 365.

Apakah subdomain butuh record SPF sendiri?

Ya. SPF tidak diwariskan: sebuah record hanya berlaku untuk nama persis tempatnya dipublikasikan, jadi mail.example.com atau news.example.com butuh record sendiri jika muncul di MAIL FROM atau HELO. Ini berbeda dari DMARC, yang beralih ke domain organisasi. Subdomain yang tidak mengirim email bisa memublikasikan v=spf1 -all.

Mengapa SPF pass di sini tetapi fail di Gmail?

Biasanya karena Gmail mengecek domain atau alamat yang berbeda. SPF dievaluasi untuk domain MAIL FROM (Return-Path) dan IP server yang terhubung, yang bisa berupa domain bounce penyedia Anda, bukan domain Anda. Penerusan email juga merusak SPF, karena IP peneruslah yang bukan bagian dari record Anda. Periksa header Authentication-Results pesan asli dan uji IP serta domain itu di sini.

Apa perbedaan SPF, DKIM, dan DMARC?

SPF mencantumkan server yang boleh mengirim atas nama sebuah domain dan dicek terhadap envelope sender. DKIM menandatangani setiap pesan dengan kunci yang dipublikasikan di DNS, sehingga tanda tangannya bertahan saat diteruskan. DMARC mengaitkan keduanya dengan alamat From: yang dilihat pembaca: pesan lolos DMARC jika SPF atau DKIM pass untuk domain yang aligned dengan From:, dan kebijakannya menentukan tindakan jika tidak.

Berapa lama perubahan record SPF mulai berlaku?

Selama resolver masih menyimpan record lama: hingga TTL-nya, yang ditetapkan domain (300 detik untuk google.com dan github.com, satu jam untuk microsoft.com saat kami mengeceknya). Penerima bertanya ke resolver mereka, jadi perubahan terlihat setelah setiap salinan cache kedaluwarsa. Pengecek ini menampilkan TTL seperti yang disajikan nameserver domain sendiri; cek lagi setelah waktu itu.

Ada yang kurang?Usulkan fitur atau alat baru

Tool email dan DNS terkait