Defaults.Exposed › Perbaikan › Guides
SPF Gagal untuk Alat SaaS Anda? Mengapa Ini Terjadi dan Urutan Perbaikan — Edisi Eropa (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.
Ketika alat SaaS “gagal SPF”, record Anda biasanya bukan masalahnya: email gagal keselarasan DMARC, atau rantai include Anda telah melampaui batas 10-DNS-lookup SPF. 2,119,539 dari 138,927,207 domain yang menerbitkan SPF berada di 9–10 lookup — satu include SaaS dari tepi jurang — menurut sensus Defaults.Exposed dari 261,086,232 domain.
Di bawah ini: cara mengetahui masalah mana yang Anda hadapi, kemudian urutan perbaikan — pindai dulu, temukan domain yang benar-benar digunakan alat, alihkan vendor ke DKIM domain kustom, dan hanya tambahkan include SPF di mana benar-benar membantu — beserta spesifik untuk HubSpot, Salesforce, Mailchimp dan SendGrid.
Mengapa email dari alat SaaS gagal SPF?
Tiga pola mencakup hampir setiap kasus:
| Yang dikatakan laporan atau bounce | Yang sebenarnya salah | Perbaikan |
|---|---|---|
| SPF lulus, DMARC masih gagal | Keselarasan: alat lulus SPF di bounce domain-nya, bukan domain Anda | Aktifkan DKIM domain kustom vendor (CNAME) |
SPF permerror | Rantai include Anda melebihi batas 10-DNS-lookup SPF | Pangkas include; lihat perbaikan terlalu banyak lookup |
SPF fail / softfail | Alat benar-benar mengirim dengan return-path Anda dan tidak ada di record Anda | Tambahkan include vendor atau aktifkan bounce domain kustomnya |
Data per 2026-06-29.
Baris yang dicetak tebal adalah tempat kebanyakan orang berada. Menambahkan baris include: untuk setiap alat tidak menyentuhnya — dan setiap baris memindahkan Anda lebih dekat ke baris kedua: setidaknya 797,263 domain sudah melampaui batas 10 lookup, dan SPF mereka sekarang mengembalikan PermError yang tidak melindungi apapun. Angka lengkap di laporan SPF PermError.
Domain mana yang benar-benar diperiksa SPF?
Bukan yang ada di header From Anda. Penerima mengevaluasi SPF terhadap domain Return-Path (RFC5321.MailFrom, juga disebut bounce atau envelope-from) — header From yang dilihat penerima tidak berperan dalam pemeriksaan SPF itu sendiri.
Fakta tunggal ini menjelaskan sebagian besar “kegagalan SPF SaaS”. Platform pemasaran Anda mengirim dengan Return-Path seperti [email protected]; SPF diperiksa terhadap vendor.com dan lulus dengan bersih. Kemudian DMARC menanyakan apakah domain yang diperiksa SPF itu cocok dengan domain From Anda. Tidak cocok, jadi leg SPF DMARC gagal dan dashboard Anda mengatakan “SPF gagal”. Mengedit record SPF Anda sendiri tidak dapat memperbaiki itu — record Anda tidak pernah dikonsultasikan.
Apa urutan perbaikannya?
- Jalankan pemindaian gratis terlebih dahulu. Ini memberi tahu Anda dalam satu kali apakah SPF Anda hilang, duplikat, melebihi batas lookup, atau baik-baik saja, dan di mana posisi DMARC — sebelum menyentuh DNS.
- Temukan Return-Path yang benar-benar digunakan alat. Kirim uji coba dari alat dan baca header Return-Path (dan Authentication-Results) di pesan mentah. Ini memberi tahu Anda baris tabel mana yang Anda masuki.
- Aktifkan DKIM domain kustom vendor. Setiap alat SaaS serius menawarkan “autentikasi domain”: beberapa record CNAME yang memungkinkannya DKIM-sign sebagai domain Anda. Tanda tangan itu selaras dengan domain From Anda, sehingga DMARC lulus melalui DKIM — secara tahan lama, bahkan ketika email diteruskan. Ini adalah perbaikan yang bertahan.
- Tambahkan include SPF vendor hanya jika menggunakan return-path Anda — Anda telah mengaktifkan bounce domain kustomnya, atau benar-benar mengirim dengan domain Anda di envelope. Include untuk vendor yang memantul melalui domainnya sendiri tidak menghasilkan apa-apa dan menghabiskan anggaran lookup.
- Hitung DNS lookup sebelum menyimpan. Batasnya adalah 10 resolved lookup, include dihitung secara rekursif, dan 2,119,539 domain sudah berada di 9–10 — p99 sensus adalah 9. Mendekati tepi? Hapus include untuk alat yang tidak lagi Anda gunakan terlebih dahulu. Baru saja mengganti provider email? Periksa ada tidaknya record kedua yang tertinggal — dua record SPF sama dengan PermError.
- Pindai ulang dan konfirmasi. SPF lulus di domain yang benar, DKIM selaras, DMARC lulus. Referensi lengkap ada di cara memperbaiki SPF; panduan provider seperti SPF di GoDaddy dan DMARC di IONOS mencakup klik panel DNS.
Apa yang harus dilakukan untuk HubSpot, Salesforce, Mailchimp dan SendGrid?
HubSpot. Hubungkan domain pengiriman Anda di pengaturan HubSpot dan terbitkan dua DKIM CNAME yang diberikannya (hs1-… / hs2-…). Ini menyelaraskan DKIM dengan domain From Anda. Anda tidak memerlukan include SPF HubSpot kecuali Anda telah mengonfigurasi HubSpot untuk menggunakan bounce domain Anda sendiri.
Salesforce. Buat kunci DKIM di Salesforce Setup dan terbitkan pasangan CNAME yang dihasilkannya. Jika Salesforce mengirim dengan return-path organisasi Anda, tambahkan include:_spf.salesforce.com dan konfigurasikan bounce domain — ini adalah satu CRM besar di mana include SPF sering benar-benar diperlukan.
Mailchimp. Autentikasi domain Anda dan terbitkan DKIM CNAME k2 / k3. Keselarasan Mailchimp hanya DKIM — tidak ada include SPF yang perlu ditambahkan lagi, dan menambahkan satu dari tutorial lama hanya membuang lookup.
SendGrid. Selesaikan autentikasi domain (“automated security”): tiga CNAME yang menangani DKIM dan return-path di subdomain Anda sendiri. Tidak diperlukan include SPF. Dari 740,321 domain yang SPF-nya mengotorisasi sendgrid.net, hanya 18.0% yang memiliki DMARC yang menegakkan (data per 2026-06-29) — sebagian besar pengirim SendGrid berhenti satu langkah sebelum selesai.
Zendesk dan lainnya: pola yang sama. Temukan halaman “autentikasi domain” alat, terbitkan DKIM CNAME-nya, dan hanya sentuh SPF jika alat mendokumentasikan bahwa ia menggunakan return-path Anda.
Apakah SPF berbeda untuk bisnis Eropa?
Tidak — SPF, DKIM dan DMARC bekerja identik di mana saja. Yang berbeda di Eropa adalah konteksnya: siapa yang bertanya, dan apa yang sudah dilakukan tetangga Anda.
ccTLD Anda menetapkan standar lokal. ccTLD Eropa menerbitkan SPF jauh di atas tingkat .com, tetapi domain yang menyelesaikan pekerjaan — kebijakan DMARC yang menegakkan di atasnya — adalah minoritas di mana saja:
| TLD | Adopsi SPF (dari domain yang dinilai) | DMARC yang menegakkan (dari domain yang dinilai) |
|---|---|---|
| .nl | 75.91% | 29.43% |
| .ie | 70.89% | 8.79% |
| .de | 64.67% | 21.38% |
| .dk | 50.42% | 19.88% |
| .com | 54.14% | 9.50% |
Data per 2026-06-29. Prancis: 13.65% menegakkan DMARC; Italia: 5.24%.
Default host Eropa Anda penting. 4,346,526 domain mengotorisasi server email EU IONOS (_spf-eu.ionos.com) dalam SPF mereka — dan hanya 0.3% yang berakhir dengan -all yang ketat, dengan 1.0% DMARC yang menegakkan. 2,132,049 OVH melakukan lebih baik dalam keketatan (43.7%) tetapi hanya 2.2% yang menegakkan DMARC (data per 2026-06-29). Jika Anda tidak pernah menyentuh record Anda, Anda berdiri di atas default tersebut.
Regulator kini menyebut hal ini. Artikel 21(2)(j) NIS2 mewajibkan entitas dalam cakupan untuk mengamankan komunikasi mereka, dan Commission Implementing Regulation (EU) 2024/2690 merinci langkah-langkah keamanan email dan DNS. Autentikasi email adalah bagian yang konkret dan dapat diperiksa — dan, luar biasanya untuk kepatuhan, gratis untuk diperbaiki.
Tentang residensi data: scanner dan sensus Defaults.Exposed berjalan di AWS eu-west-1, kami hanya menerbitkan angka agregat, dan pemindaian hanya memeriksa domain yang Anda tanyakan.
Pertanyaan yang Sering Diajukan
Pemeriksa SPF saya mengatakan “pass” tetapi dashboard alat mengatakan SPF gagal — mengapa? Pemeriksa menguji record Anda; penerima menguji domain Return-Path yang benar-benar digunakan alat, kemudian DMARC membandingkannya dengan domain From Anda. Itu kegagalan keselarasan, bukan kegagalan record — diperbaiki dengan DKIM domain kustom vendor, bukan dengan pengeditan SPF.
Haruskah saya menambahkan include SPF untuk setiap alat yang kami gunakan? Tidak. Setiap include menghabiskan sebagian anggaran 10-lookup SPF, secara rekursif: 2,119,539 dari 138,927,207 domain yang menerbitkan SPF berada di 9–10 lookup, dan setidaknya 797,263 sudah melebihi — SPF mereka mengembalikan PermError dan tidak melindungi apapun (data per 2026-06-29).
Apakah include juga memperbaiki DMARC? Hanya jika alat mengirim dengan return-path Anda, sehingga SPF lulus dan selaras. Untuk sebagian besar alat SaaS tidak demikian — itulah mengapa DKIM yang selaras, bukan SPF, adalah leg yang membuat DMARC lulus untuk email SaaS.
Apakah ini persyaratan hukum di EU? Untuk entitas dalam cakupan NIS2, Artikel 21(2)(j) dan Implementing Regulation (EU) 2024/2690 menjadikan keamanan email sebagai kewajiban. Bahkan di luar cakupan, penanggung asuransi dan kuesioner pelanggan semakin banyak bertanya — dan per 2026-06-29, tidak ada ccTLD EU yang bahkan sepertiga dari domain-domainnya mencapai kebijakan DMARC yang menegakkan (29.43% di .nl terbaik; 5.24% di .it).
Kirimkan laporan kepada pemilik
Setelah CNAME aktif, jalankan ulang pemindaian dan teruskan laporan yang dinilai kepada pemilik bisnis atau klien. Laporan menunjukkan, dalam bahasa yang mudah dipahami, apa yang gagal, apa yang Anda perbaiki dan di mana domain sekarang berdiri — tepat bukti yang mereka butuhkan untuk perpanjangan asuransi atau kuesioner keamanan pemasok pelanggan, secara tertulis bukan hanya berdasarkan kata-kata Anda.
Periksa domain Anda gratis
Lihat tepat leg mana dari SPF, DKIM dan DMARC yang gagal — secara privat dan hanya untuk pemilik.
Periksa domain Anda → · Perbaiki SPF → · SPF PermError: “terlalu banyak DNS lookup” → · Cara kami menilai → · Hanya data agregat. Data disimpan dan diproses di EU.