SPF Berhenti Bekerja Setelah Ganti Provider Email — Perbaikan Migrasi (2026)

Diterbitkan 2026-07-08

Angka per 2026-06-29 · metodologi v7. Data sensus agregat dari 261 juta domain yang dinilai. Lihat cara kami menilai.

SPF biasanya rusak setelah pergantian provider email karena record provider baru ditambahkan di sebelah yang lama. Dua record v=spf1 adalah error permanen — SPF dibatalkan sepenuhnya. 1,013,416 domain — sekitar satu dari 138 yang mencoba SPF — berada dalam kondisi itu, menurut sensus Defaults.Exposed dari 261 juta domain. Gabungkan menjadi satu.

Perbaikannya membutuhkan sekitar sepuluh menit: pindai domain untuk melihat tepat apa yang ditinggalkan migrasi, daftar setiap record SPF di nameserver otoritatif Anda, gabungkan menjadi satu record yang hanya menyertakan provider baru, dan verifikasi ulang dengan dig. Panduan ini memandu setiap langkah, ditambah pemeriksaan DKIM dan nameserver yang dilupakan sebagian besar migrasi.

Mengapa SPF rusak tepat setelah migrasi?

Karena panduan setup provider baru menyatakan “tambahkan record TXT ini” — dan Anda melakukannya, di sebelah yang lama. Itulah satu hal yang tidak diizinkan standar SPF. RFC 7208 (§3.2, hasil error ditetapkan di §4.5) mengizinkan tepat satu record v=spf1 per domain; penerima yang menemukan dua atau lebih harus mengembalikan PermError daripada menebak mana yang otoritatif. PermError berarti SPF batal: bukan record lama, bukan yang baru, tidak ada SPF sama sekali.

Dan tidak berhenti di situ. DMARC memperlakukan PermError sebagai gagal di leg SPF, sehingga email Anda kini sepenuhnya bergantung pada DKIM. Jika DKIM provider baru belum diatur juga — umum di pertengahan migrasi — Anda mengirim tanpa autentikasi tepat saat Anda mengubah infrastruktur, yang merupakan saat penerima paling cermat mengawasi Anda.

Inilah copy-paste yang membatalkan perlindungan saat Anda mengganti provider, dan ini bukan hal yang jarang: 1,013,416 domain menerbitkan dua atau lebih record SPF saat ini — sekitar satu dari 138 dari populasi 139 juta yang mencoba SPF, menurut sensus Defaults.Exposed dari 261 juta domain (data per 2026-06-29). Angka lengkap tentang jebakan dua record memiliki laporannya sendiri; halaman ini adalah perbaikan prosedural.

Apa yang ditinggalkan migrasi?

Lima sisa menyebabkan hampir setiap kegagalan SPF pasca-migrasi. Periksa dalam urutan ini:

Yang tertinggal	Yang Anda lihat	Perbaikannya
Record SPF lama, masih di DNS di sebelah yang baru (dua record `v=spf1`)	Pemeriksa melaporkan “multiple SPF records” atau PermError; SPF berhenti bekerja sepenuhnya	Gabungkan menjadi satu record, hapus sisanya — langkah di bawah
`include:` provider lama di dalam satu record Anda	SPF berfungsi, tetapi Anda membuang lookup DNS dan server provider lama masih bisa mengirim sebagai Anda	Hapus setelah email sepenuhnya selesai diproses dari sistem lama
`include:` provider baru tidak pernah ditambahkan	Email dari provider baru gagal SPF di penerima	Tambahkan ke record tunggal yang ada — jangan pernah sebagai record baru
Selector DKIM tidak dibuat untuk provider baru	`dkim=fail` atau tanda tangan dari domain default provider; DMARC tidak memiliki leg kedua	Terbitkan selector baru — langkah 6 di bawah
Record hanya diperbarui di nameserver lama	Jawaban berbeda tergantung siapa yang ditanya; kegagalan tidak menentu	Perbaiki zona di nameserver otoritatif; verifikasi kedua set saat cutover

Bagaimana cara memperbaikinya? Daftar periksa migrasi

Jalankan pemindaian gratis di defaults.exposed terlebih dahulu. Ini membaca DNS aktif Anda dan memberi tahu apakah Anda memiliki beberapa record SPF, include yang hilang, atau celah DKIM — diagnosis sebelum menyentuh apapun.
Daftar setiap record SPF di nameserver otoritatif. dig +short NS yourdomain.com, lalu dig +short TXT yourdomain.com @<nameserver> terhadap salah satunya. Hitung string yang dimulai v=spf1. Satu-satunya jumlah yang aman adalah 1.
Gabungkan menjadi satu record. Satu record, dimulai v=spf1, berisi include provider baru dan pengirim lain yang masih Anda gunakan (alat faktur, CRM, platform newsletter), satu terminal -all atau ~all. Contoh — Google Workspace lama, Microsoft 365 baru, sedang dalam masa draining:
```
Sebelum: "v=spf1 include:_spf.google.com ~all"
         "v=spf1 include:spf.protection.outlook.com -all"

Setelah:  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Nanti:    "v=spf1 include:spf.protection.outlook.com -all"
```
Nilai provider dan kekhasan panel DNS ada di panduan setup untuk Google Workspace dan Microsoft 365.
Hapus record ekstra. Menggabungkan tanpa menghapus tidak memperbaiki apapun — PermError berasal dari jumlahnya.
Pertahankan include provider lama hanya selama sistem lama masih mengirim — laporan terjadwal, konektor CRM lama, kotak surat yang terlupakan. Setelah draining selesai, hapus: include yang usang membiarkan infrastruktur lama diizinkan mengirim sebagai Anda, dan setiap include menggunakan lookup DNS terhadap batas keras SPF sebesar 10 — setidaknya 797,263 domain telah membatalkan SPF dengan melampaui batas tersebut (sensus, 2026-06-29).
Siapkan DKIM provider baru — dan jangan hapus selector lama dulu. Selector baru menandatangani email baru; selector lama harus tetap diterbitkan sampai setiap pesan yang ditandatangani dengannya terkirim dan penerusan apapun selesai. Panduan lengkap di DKIM gagal setelah mengganti alat email.
Jika Anda juga mengganti nameserver, periksa keduanya. Migrasi DNS sering berjalan bersamaan dengan migrasi email. Kueri set NS lama dan baru secara langsung (dig TXT yourdomain.com @old-ns dan @new-ns) — sampai delegasi registrar sepenuhnya dipropagasi, beberapa penerima masih menanyakan server lama, sehingga record yang diperbaiki harus ada di set yang menjawab.
Jalankan ulang pemindaian dan konfirmasi SPF menampilkan satu record valid dengan hasil pass.

Domain mana yang sebenarnya diperiksa SPF?

Penerima mengevaluasi SPF terhadap domain Return-Path (RFC5321.MailFrom) — alamat bounce — bukan header From yang dilihat penerima Anda. Setelah migrasi ini penting dua kali: provider baru Anda mungkin menggunakan bounce domain-nya sendiri sampai Anda mengonfigurasi yang kustom, dan SPF “lulus” di domain yang bukan milik Anda tidak akan selaras untuk DMARC. Perbaikannya adalah DKIM provider baru, ditandatangani dengan domain Anda.

Migrasi dan rebranding sekaligus?

Juga mengganti domain sekaligus dengan provider? Perlakukan sebagai dua pekerjaan. Domain baru membutuhkan stack lengkap — SPF, DKIM, DMARC — dari hari pertama; gunakan daftar periksa email domain baru. Domain lama tetap terautentikasi selama lalu lintas penerusan atau balasan masih berjalan melaluinya, dan dikunci secara eksplisit (bukan sekadar ditinggalkan) setelah terparkir. Domain lama dengan SPF yang setengah rusak adalah target pemalsuan yang menggunakan nama lama Anda.

Pertanyaan yang Sering Diajukan

Bisakah saya mempertahankan dua record SPF selama migrasi? Tidak. Tidak ada masa tenggang dalam standar — dua record v=spf1 adalah PermError dari saat record kedua ada, dan 1,013,416 domain berada dalam kondisi itu per sensus (2026-06-29). Pola yang aman untuk migrasi adalah satu record yang membawa include kedua provider selama periode tumpang tindih.

Berapa lama saya harus mempertahankan include provider lama? Sampai tidak ada yang mengirim melalui provider lama — biasanya sepanjang jendela tumpang tindih Anda, hari hingga beberapa minggu. Perhatikan Return-Path dari apapun yang masih datang melalui sistem lama; ketika lalu lintas itu berhenti, hapus include dan periksa ulang jumlah lookup Anda.

Mengapa pemeriksa masih menampilkan record lama saya setelah diperbaiki? Cache DNS menghormati TTL record, dan jika nameserver Anda berubah, beberapa resolver masih menanyakan set lama. Verifikasi langsung di nameserver otoritatif dengan dig TXT yourdomain.com @<ns> — jika jawabannya benar di sana, perbaikan selesai dan cache akan menyusul. Jika salah di satu set NS, lihat ‘SPF record not found’ — penyebab sebenarnya.

Apakah saya perlu mengubah DMARC saat mengganti provider? Biasanya bukan record itu sendiri — yang menyebut kotak surat laporan dan kebijakan Anda, bukan provider Anda. Tetapi hasil DMARC Anda bergantung pada SPF dan DKIM yang baru saja Anda migrasi: harapkan penurunan dalam laporan saat cutover, dan konfirmasi kedua leg lulus sebelum memperketat kebijakan. Mulai di perbaiki SPF jika pemindaian menampilkan leg SPF masih gagal.

Kirimkan laporan kepada pemilik

Jika Anda melakukan migrasi ini untuk klien, selesaikan dengan bukti. Jalankan ulang pemindaian gratis setelah penggabungan aktif dan teruskan laporan yang dinilai kepada pemilik bisnis: SPF, DKIM dan DMARC lulus di provider baru, dalam bahasa mudah dipahami, bertanggal. Itulah artefak yang mereka arsipkan untuk perpanjangan asuransi siber dan kuesioner keamanan pemasok berikutnya — bukti bahwa migrasi meninggalkan domain lebih terautentikasi dari sebelumnya.

Periksa domain Anda → · DKIM gagal setelah mengganti alat email → · ‘SPF record not found’ — penyebab sebenarnya → · Cara kami menilai → · Hanya data agregat. Data disimpan dan diproses di EU.