Defaults.Exposed › Perbaikan › Guides

Email yang Diteruskan Gagal SPF — Mengapa Anda Tidak Bisa Memperbaikinya, dan Apa yang Benar-benar Berhasil (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.

Anda tidak bisa membuat SPF lulus untuk email yang diteruskan — penerusan merusak SPF by design, dan perbaikan yang jujur adalah DKIM yang selaras, yang bertahan dari penerusan. Skalanya mencakup seluruh sensus: 7,355,985 dari 138,927,207 domain yang menerbitkan SPF mengotorisasi include penerusan Namecheap saja, dengan pangsa SPF-ketat sebesar <0.1%, menurut sensus Defaults.Exposed dari 261 juta domain.

Di bawah ini: mengapa tidak ada record SPF yang bisa Anda tulis yang bertahan dari penerusan, mengapa SRS dan ARC bukan alat yang Anda kendalikan, dan perbaikan yang bertahan — penandatanganan DKIM dengan domain Anda sendiri sebagai kelulusan DMARC Anda — ditambah satu kasus yang juga merusak DKIM (mailing list yang menulis ulang pesan) dan apa yang harus dilakukan tentang sisa tersebut.

Mengapa penerusan merusak SPF?

Penerima mengevaluasi SPF terhadap domain Return-Path (RFC5321.MailFrom), bukan header From. Ketika Anda mengirim secara langsung, IP server Anda ada dalam record SPF Anda dan pemeriksaan lulus. Ketika penerima Anda meneruskan pesan secara otomatis — ke Gmail pribadi, melalui alias universitas, melalui produk penerusan registrar — server penerus meretransmisikan, biasanya mempertahankan domain Anda di Return-Path. Penerima akhir sekarang bertanya: apakah server penerusan ini diotorisasi dalam record SPF Anda?

Tidak, dan tidak akan pernah: Anda tidak memilih penerusnya, Anda tidak tahu keberadaannya, dan pesan yang sama yang diteruskan melalui layanan berbeda besok akan gagal dari IP yang berbeda. SPF menjawab satu pertanyaan — “apakah IP ini berasal dari server yang diotorisasi domain Return-Path?” — dan untuk email yang diteruskan jawabannya adalah tidak. Kegagalannya adalah SPF yang bekerja sesuai spesifikasi, bukan record Anda yang salah.

Sensus menunjukkan betapa umum jalur ini: 7,355,985 domain mengotorisasi include penerusan-email Namecheap (spf.efwd.registrar-servers.com) — produk penerusan satu provider, diambil dari 139 juta penerbit SPF — dengan pangsa SPF-ketat sebesar <0.1% dan hanya 0.2% yang menegakkan DMARC. Template lunak itu bukan kecerobohan: penerusan adalah tepat di mana -all yang ketat salah fungsi, dan provider yang produknya adalah penerusan mengapalkan sesuai. Cerita qualifier lengkap ada di laporan ~all vs -all kami, dan gambaran per provider di provider email mana yang memberikan SPF terkuat.

Bisakah saya menambahkan server penerus ke record SPF saya?

Tidak — dan alasannya adalah seluruh artikel ini:

1. Anda tidak bisa mendaftar penerus. Setiap penerima, di mana saja, bisa meneruskan email Anda melalui layanan apa pun. Record SPF Anda perlu mendaftar server yang tidak bisa Anda ketahui sebelumnya.
2. Mendaftar mereka akan mengalahkan tujuannya. Layanan penerusan besar meneruskan email untuk jutaan pelanggan. Masukkan rentang mereka ke dalam record Anda dan setiap pesan yang diteruskan pengguna mana pun dari mereka — termasuk penipu — akan lulus SPF sebagai Anda.

Logika yang sama mengesampingkan pelonggaran qualifier Anda untuk “membuat penerusan bekerja”: qualifier bukan alasan email yang diteruskan gagal, dan setelah DMARC berlaku itu mengubah lebih sedikit dari yang diklaim sebagian besar panduan — lihat data qualifier. Record bukan pengungkit di sini. Berhenti menggunakannya.

Bagaimana dengan SRS dan ARC — bukankah mereka memperbaiki penerusan?

Mereka mengatasinya — tetapi keduanya bukan milik Anda untuk di-deploy:

Data dan status mekanisme per 2026-06-29.

SRS membuat masalah SPF penerus hilang, bukan milik Anda: menulis ulang Return-Path mengubah SPF siapa yang diperiksa, sementara header From Anda — domain yang dipertahankan DMARC — tidak tersentuh. ARC adalah keputusan kepercayaan antara operator infrastruktur. Jika sebuah panduan menyuruh Anda “mengimplementasikan SRS” sebagai pemilik domain, itu telah mengacaukan Anda dengan provider penerusan.

Bagaimana cara membuat email saya bertahan dari penerusan?

Jadikan DKIM, yang selaras dengan domain Anda, sebagai kelulusan DMARC Anda. Tanda tangan DKIM adalah kriptografi yang dibawa dalam header pesan: tanda tangan terverifikasi di mana pun pesan berakhir, berapa pun server yang meneruskannya, selama konten yang ditandatangani tidak dimodifikasi. DMARC hanya membutuhkan satu kelulusan yang selaras — SPF atau DKIM — sehingga ketika penerusan mematikan leg SPF, DKIM yang selaras menjaga pesan tetap terautentikasi.

1. Jalankan pemindaian gratis di defaults.exposed sebelum menyentuh DNS. Ini menampilkan apakah Anda memiliki DKIM sama sekali, apakah menandatangani dengan domain Anda, dan di mana DMARC Anda berada — sehingga Anda memperbaiki celah nyata daripada memperjuangkan record SPF Anda.
2. Konfirmasi penerusan memang masalah Anda. Di header Authentication-Results pesan yang terdampak, email langsung lulus SPF sementara salinan yang diteruskan gagal dari IP layanan penerusan. Jika SPF dan DKIM lulus tetapi DMARC tetap gagal, Anda memiliki masalah keselarasan — lihat DMARC gagal tapi SPF dan DKIM lulus.
3. Aktifkan penandatanganan DKIM dengan domain Anda sendiri di setiap layanan pengiriman — provider kotak surat terlebih dahulu, kemudian ESP dan pengirim transaksional. Default provider sering menandatangani dengan domain provider, yang tidak selaras; Anda menginginkan d=yourdomain. Mulai di cara memperbaiki DKIM, dengan jalur klik untuk Google Workspace dan Microsoft 365.
4. Verifikasi keselarasan, bukan sekadar kelulusan. Domain d= dalam tanda tangan harus cocok dengan domain From Anda; dkim=pass pada domain orang lain tidak melakukan apapun untuk DMARC Anda.
5. Biarkan record SPF Anda apa adanya. Pertahankan akurasinya untuk email langsung Anda — ini masih mengautentikasi sebagian besar lalu lintas Anda dan tetap menjadi leg DMARC kedua Anda. Hanya berhenti mencoba membuatnya mencakup penerus.
6. Pindai ulang, kemudian bertahap dalam penegakan DMARC secara sengaja — bagian berikutnya, dan panduan peluncuran p=none ke p=reject.

Kombinasi ini — SPF ditambah penegakan DMARC yang berjalan pada DKIM yang selaras — adalah pola yang tahan penerusan, dan ini jarang: dari 77.5 juta domain yang menerbitkan ~all, hanya 9.2% (7,116,774) yang mendukungnya dengan kebijakan DMARC yang ditegakkan, dan hanya 3.87% dari 261 juta domain yang dinilai (10,092,481) yang melengkapi triad SPF + DKIM + DMARC-ditegakkan penuh, per sensus (2026-06-29).

Bagaimana dengan mailing list yang menulis ulang pesan?

Satu jalur penerusan yang tidak bisa bertahan dari DKIM yang selaras: mailing list yang memodifikasi pesan — tag subjek [nama-daftar], footer unsubscribe, lampiran yang dihapus. Ubah konten yang ditandatangani dan hash body tidak lagi cocok, sehingga DKIM juga gagal (dkim=fail: body hash did not verify adalah panduan kegagalan itu sendiri). Sekarang kedua leg DMARC mati, dan hanya daftar yang dapat memitigasinya (penulisan ulang From, ARC sealing).

Sisa ini adalah tepat untuk apa penegakan DMARC bertahap digunakan. Bergerak melalui p=quarantine dengan ramp pct sambil mengamati laporan agregat menunjukkan berapa banyak email nyata Anda mengalir melalui daftar yang menulis ulang sebelum kebijakan p=reject mulai memantulkannya. Jangan langsung ke reject di domain yang penggunanya hidup di mailing list; jangan juga terhenti di p=none selamanya. Panduan peluncuran bertahap memandu ramnya.

Pertanyaan yang Sering Diajukan

Apakah penerusan juga merusak DKIM? Penerusan biasa, tidak: tanda tangan berjalan bersama pesan dan terverifikasi di penerima akhir. DKIM rusak hanya ketika konten yang ditandatangani dimodifikasi dalam transit — tag subjek mailing list dan footer adalah kasus klasik — itulah mengapa sisa daftar ditangani oleh pementasan kebijakan DMARC, bukan oleh apapun di DNS.

Haruskah saya beralih dari -all ke ~all agar penerusan berhenti gagal? Mengubah qualifier tidak akan membuat penerus lulus — bukan itu alasan mereka gagal. Menarik bahwa include penerusan Namecheap, 7,355,985 domain dan populasi penerusan-khusus terbesar sensus (2026-06-29), mengapalkan dengan pangsa SPF-ketat sebesar <0.1%: SPF lunak bisa dibilang template yang benar untuk produk penerusan. Lihat laporan ~all vs -all untuk apa yang sebenarnya diubah qualifier.

Mengapa email saya lulus SPF ketika dikirim langsung tetapi gagal ketika seseorang meneruskannya? Penerima memeriksa apakah IP server yang terakhir mengirim diotorisasi oleh record SPF domain Return-Path Anda. Langsung: server Anda, dalam record Anda, lulus. Diteruskan: server penerus, tidak dalam record Anda, gagal. Record Anda tidak berubah — IP pengirimnya yang berubah.

Bisakah saya menyiapkan SRS untuk memperbaiki ini? Hanya jika Anda adalah penerusnya. SRS berjalan di server yang melakukan penerusan, dan bahkan di mana ia berjalan, kelulusan SPF yang dihasilkan milik domain penerus dan tidak selaras dengan From Anda — DMARC Anda masih membutuhkan leg DKIM.

Apakah SPF tidak berguna jika penerusan merusaknya? Tidak. Sebagian besar email dikirimkan secara langsung, di mana SPF bekerja persis seperti yang dimaksud, dan ini tetap menjadi salah satu dari dua leg DMARC Anda. Dari 261,086,232 domain dalam sensus (2026-06-29), 138,927,207 menerbitkan SPF — pertahankan akurasi milik Anda melalui halaman perbaikan SPF, dan biarkan DKIM membawa sisa yang diteruskan.

Kirimkan laporan kepada pemilik

Jika Anda memperbaiki ini untuk klien atau perusahaan Anda, tutup lingkaran dengan bukti. Setelah DKIM domain kustom aktif dan DMARC bertahap, jalankan ulang pemindaian gratis dan teruskan laporan yang dinilai kepada pemilik bisnis: bertanggal, berbahasa mudah dipahami, menampilkan domain tetap terautentikasi bahkan ketika emailnya diteruskan. Itulah artefak untuk perpanjangan asuransi siber dan kuesioner pemasok berikutnya — sebelum-dan-sesudah yang terdokumentasi, bukan “saya mengaktifkan sesuatu”.

Periksa domain Anda → · DMARC gagal tapi SPF dan DKIM lulus → · Perbaiki DKIM → · Cara kami menilai → · Hanya data agregat. Data disimpan dan diproses di EU.