๐Ÿ“ Memperkenalkan MapLeads: ubah Google Maps, Bing Maps & Apple Maps jadi daftar lead Anda.Coba MapLeads
Alat Gratis

Generator Record SPF

Buat record TXT SPF yang valid untuk domain Anda. Tambahkan alamat IP, server email, dan pengirim pihak ketiga โ€” dapatkan nilai DNS tepat yang perlu dipublikasikan.

Buat Record SPF Anda

Tambahkan alamat IPv4 atau IPv6 yang diizinkan mengirim email untuk domain ini.

Tambahkan layanan pengiriman pihak ketiga seperti Google Workspace atau SendGrid.

Apa Itu Record SPF dan Mengapa Penting?

Record SPF (Sender Policy Framework) adalah record DNS TXT yang menentukan server email mana yang diizinkan mengirim email atas nama domain Anda. Ketika server penerima menerima pesan yang mengaku berasal dari domain Anda, server itu menanyakan record SPF Anda untuk memverifikasi bahwa IP pengirim tercantum. Jika IP tidak diizinkan, pesan dapat ditolak atau ditandai sebagai spam.

SPF adalah salah satu dari tiga standar autentikasi email dasar, bersama DKIM dan DMARC. Tanpanya, siapa pun dapat memalsukan domain Anda di kolom pengirim envelope, sehingga domain Anda menjadi sasaran serangan phishing dan spoofing. Sebagian besar penyedia kotak surat modern dan gateway email perusahaan memeriksa SPF sebelum menerima email.

Memahami Sintaks Record SPF

Setiap record SPF dimulai dengan v=spf1, yang menyatakan versinya. Setelah itu, Anda menambahkan mekanisme yang mencantumkan pengirim yang diizinkan. Record diakhiri dengan kualifikasi yang disebut mekanisme all.

  • ip4:x.x.x.x โ€” mengizinkan satu alamat IPv4
  • ip4:x.x.x.x/24 โ€” mengizinkan rentang CIDR IPv4
  • ip6:::1 โ€” mengizinkan alamat IPv6
  • include:domain.com โ€” mengimpor record SPF domain lain (digunakan untuk pengirim pihak ketiga)
  • a โ€” mengizinkan IP record A domain
  • mx โ€” mengizinkan IP record MX domain

Penjelasan Kualifikasi Kebijakan SPF

Kualifikasi di akhir record SPF Anda mengontrol apa yang dilakukan server penerima terhadap email dari pengirim yang tidak diizinkan.

KualifikasiPerilaku
+allSemua pengirim lulus. Jangan pernah menggunakan ini โ€” ini meniadakan SPF sepenuhnya.
~allSoftfail โ€” email yang tidak diizinkan diterima tetapi ditandai. Gunakan saat pengujian.
-allHard fail โ€” email yang tidak diizinkan ditolak. Gunakan di produksi.
?allNeutral โ€” tidak ada kebijakan. Jarang berguna.

Direktif Include SPF yang Umum

Jika Anda menggunakan layanan email pihak ketiga, Anda perlu menambahkan domain pengiriman mereka yang diizinkan menggunakan direktif include:. Berikut yang paling sering digunakan:

  • Google Workspace: include:_spf.google.com
  • Microsoft 365: include:spf.protection.outlook.com
  • Mailchimp: include:servers.mcsv.net
  • SendGrid: include:sendgrid.net
  • Mailgun: include:mailgun.org

Batas Lookup SPF dan Cara Tetap di Bawahnya

SPF memiliki batas keras 10 lookup DNS selama evaluasi. Setiap mekanisme include:, a, dan mx dihitung sebagai satu lookup. Banyak record SPF pihak ketiga sendiri memicu lookup tambahan secara internal. Jika record Anda melebihi total 10 lookup, evaluasi SPF mengembalikan PermError, yang diperlakukan sebagai kegagalan. Agar tetap di bawah batas, gunakan alamat IP langsung bila memungkinkan dan hindari rantai include bersarang.

SPF Paling Efektif Bersama DKIM dan DMARC

SPF saja melindungi pengirim envelope (Return-Path), bukan alamat From yang terlihat. Untuk perlindungan spoofing yang lengkap, Anda juga memerlukan DKIM untuk menandatangani pesan dan DMARC untuk menyelaraskan hasil autentikasi dengan header From. Ketiga standar ini bersama-sama membentuk dasar autentikasi email yang diharapkan oleh Gmail, Outlook, dan Yahoo Mail.

Setelah menyiapkan SPF, pastikan daftar Anda juga bersih. Verifikasi email menghapus alamat yang tidak valid dan berisiko sebelum Anda mengirim, sehingga tingkat bounce tetap rendah dan melindungi reputasi pengirim yang Anda bangun dengan autentikasi yang benar. Anda juga dapat memverifikasi alamat secara massal melalui verifikasi email massal atau mengintegrasikan verifikasi langsung ke stack Anda melalui API validasi email.

Bangun dari pengirim nyata

Apa yang dibutuhkan generator record SPF sebelum menyusun kebijakan yang tepat

Record SPF adalah daftar otorisasi untuk domain pengirim envelope. Generator dapat memformat daftar itu, tetapi daftar harus dimulai dengan inventaris akurat dari setiap sistem yang mengirim email untuk domain Anda.

Inventarisasi setiap sumber pengiriman sebelum menambahkan mekanisme

Cantumkan penyedia workspace, layanan transaksional, platform pemasaran, meja dukungan, CRM, dan setiap server yang mengirim dengan domain ini di MAIL FROM atau HELO. Sumber yang terlewat menciptakan kegagalan SPF palsu; sumber yang usang membuat otorisasi lebih luas dari yang diperlukan.

Gunakan domain include yang disediakan penyedia hanya jika penyedia itu benar-benar mengirim untuk Anda. Jangan menyalin record SPF dari perusahaan lain atau menambahkan mekanisme hanya karena terlihat familiar.

Publikasikan satu kebijakan SPF pada domain pengirim yang tepat

Nilai yang dihasilkan dimulai dengan v=spf1 dan berada dalam satu record DNS TXT. Dua record v=spf1 terpisah pada nama yang sama menyebabkan kesalahan evaluasi permanen; gabungkan semua sumber yang diizinkan ke dalam satu kebijakan.

SPF dievaluasi pada domain pengirim envelope, yang mungkin berupa subdomain return-path, bukan domain From yang terlihat. Konfirmasikan domain yang digunakan penyedia Anda sebelum memublikasikan di root berdasarkan asumsi.

Mekanisme dan kualifikasi

Baca record SPF yang dihasilkan sebagai urutan keputusan otorisasi

Setiap mekanisme menjawab dari mana email boleh berasal. Kualifikasi akhir menyatakan bagaimana penerima harus mengklasifikasikan pengirim yang tidak cocok dengan salah satunya.

Mekanisme IP langsung bersifat eksplisit; include mendelegasikan pemeliharaan

ip4 dan ip6 mengizinkan alamat atau jaringan yang ditentukan tanpa lookup DNS lain. include meminta penerima mengevaluasi kebijakan SPF domain lain, yang memungkinkan penyedia memelihara infrastrukturnya sendiri tetapi menambah pekerjaan DNS rekursif.

Mekanisme a dan mx mengizinkan alamat yang diselesaikan dari DNS. Keduanya bisa praktis, tetapi juga memperluas kebijakan ketika record tersebut melayani sistem yang tidak pernah dimaksudkan untuk mengirim email.

Kualifikasi all adalah batas kebijakan, bukan sakelar kemampuan kirim

~all menandai sumber yang tidak cocok sebagai softfail, sedangkan -all menandainya fail. Tidak satu pun instruksi memaksa setiap penerima untuk mengirimkan atau menolak pesan; penerima menggabungkan SPF dengan DKIM, DMARC, reputasi, konten, dan kebijakan lokal.

Jangan memublikasikan +all. Ini mengizinkan setiap sumber di internet dan menghilangkan perlindungan yang seharusnya diberikan record SPF.

Publikasikan dengan aman

Cara memakai generator record SPF gratis ini tanpa mengganggu email yang sah

Perlakukan pembuatan sebagai langkah draf. Verifikasi dan observasi menyelesaikan perubahan.

  1. 1

    Buat satu record dari inventaris pengirim

    Tambahkan setiap alamat IP dan include penyedia yang diperlukan, hapus duplikat, pilih kualifikasi yang hati-hati untuk peluncuran, dan salin nilai TXT lengkap tanpa tanda kutip pintar atau jeda baris.

  2. 2

    Publikasikan di DNS dan tunggu TTL yang berlaku

    Buat atau ganti record TXT pada domain pengirim envelope. Panel kontrol DNS menampilkan nama host secara berbeda, jadi pastikan apakah penyedia mengharapkan @, domain utama, atau hanya label subdomain.

  3. 3

    Jalankan Pemeriksa SPF dan periksa header pesan nyata

    Gunakan Pemeriksa SPF untuk memastikan DNS publik mengembalikan satu kebijakan yang dapat diurai. Kemudian kirim melalui setiap platform yang sah dan periksa Authentication-Results sebelum memperketat kualifikasi.

  4. 4

    Periksa ulang setiap kali pengirim ditambah atau dinonaktifkan

    SPF adalah konfigurasi operasional, bukan lencana yang dipasang lalu dilupakan. Perbarui record saat vendor, return path, rentang IP, atau arsitektur email berubah, dan hapus otorisasi yang tidak lagi diperlukan.

Apa yang tidak dapat dibuktikan generator

Generator record SPF memformat kebijakan; alat ini tidak memvalidasi seluruh sistem pengiriman

Jaga agar batas ini tetap terlihat agar record yang sintaksnya bersih tidak disalahartikan sebagai autentikasi email yang lengkap.

Record yang dihasilkan tidak otomatis menjadi record yang lulus

Alat ini tidak dapat mengetahui apakah setiap sumber telah diungkapkan, apakah include bersarang masih valid, atau apakah record dipublikasikan pada identitas yang digunakan email nyata. Pengujian DNS publik dan header pesan tetap diperlukan.

SPF memiliki batas evaluasi sepuluh lookup

include, a, mx, exists, redirect, dan dependensi rekursifnya dapat menghabiskan lookup DNS. Kebijakan yang terlihat singkat tetap dapat melebihi batas setelah record penyedia bersarang dievaluasi dan mengembalikan permerror.

SPF tidak menandatangani konten pesan atau melindungi domain From yang terlihat sendirian

Penerusan juga dapat merusak SPF karena IP yang terhubung berubah. Tambahkan DKIM untuk tanda tangan pesan dan DMARC untuk penyelarasan domain yang terlihat dan kebijakan penerima.

Autentikasi tidak membersihkan daftar penerima

Hasil SPF yang sempurna tidak mengatakan apa pun tentang apakah kotak surat penerima ada. Gunakan Verifikator Email sebelum mengirim untuk memisahkan autentikasi pengirim dari validasi penerima.

Referensi otoritatif

Sintaks dan evaluasi SPF berasal dari RFC 7208

Generator mengikuti kosakata standar SPF dan menjaga pemeriksaan terkait di alat terpisah.

RFC 7208 mendefinisikan SPF versi 1

Standar IETF RFC 7208 mendefinisikan publikasi TXT, mekanisme, pengubah, kualifikasi, evaluasi rekursif, dan batas pemrosesan. Gunakan standar ini ketika instruksi penyedia bertentangan dengan saran penyiapan umum.

Alat Email Terkait

Pilih alat berikutnya berdasarkan jenis bukti: penerima, penemuan, DNS dan infrastruktur, atau alur kerja pengirim.

Pertanyaan yang Sering Diajukan

1. Apa kepanjangan SPF dan mengapa penting?

SPF adalah kepanjangan dari Sender Policy Framework. Ini adalah metode autentikasi email berbasis DNS yang memungkinkan pemilik domain menentukan server email mana yang diizinkan mengirim email atas nama mereka. Tanpa SPF, server mana pun dapat mengaku mengirim email dari domain Anda, sehingga phishing menjadi sangat mudah. ISP dan filter spam menggunakan hasil SPF sebagai sinyal kepercayaan utama saat memutuskan apakah akan mengirimkan email Anda.

2. Bagaimana cara memublikasikan record SPF?

Buat record SPF Anda menggunakan alat ini, lalu masuk ke penyedia DNS Anda dan tambahkan record TXT di root domain (sering ditampilkan sebagai @ atau domain utama Anda) dengan nilai yang dihasilkan. Perubahan biasanya menyebar dalam 30 menit, tetapi secara global dapat memakan waktu hingga 48 jam.

3. Apa perbedaan antara ~all dan -all?

~all (softfail) memberi tahu server penerima bahwa email dari IP yang tidak tercantum mencurigakan tetapi tetap harus diterima. -all (hardfail) menginstruksikan server untuk menolak atau sangat menghukum pengirim yang tidak tercantum. Gunakan ~all saat pertama kali menyiapkan SPF, lalu beralih ke -all setelah Anda yakin semua layanan pengiriman Anda sudah tercantum.

4. Bisakah saya memiliki beberapa record SPF pada satu domain?

Tidak. Satu domain harus memiliki tepat satu record SPF. Jika dua record TXT yang dimulai dengan v=spf1 ada pada domain yang sama, evaluasi SPF menghasilkan kesalahan permanen, sehingga semua email gagal pemeriksaan SPF. Gabungkan semua mekanisme Anda ke dalam satu record.

5. Berapa banyak lookup DNS yang diizinkan record SPF?

SPF membatasi jumlah total mekanisme yang melakukan kueri DNS (include, a, mx, ptr, exists) menjadi 10 per evaluasi. Melebihi batas ini menghasilkan permerror. Hitung include Anda dengan cermat โ€” banyak penyedia merantai beberapa include bersarang yang masing-masing dihitung terhadap batas Anda.

6. Apakah SPF saja mencegah spoofing email?

SPF hanya mengautentikasi alamat envelope-from (MAIL FROM), bukan header From yang terlihat oleh penerima. Penyerang tetap dapat memalsukan header From meskipun SPF lulus. Untuk sepenuhnya mencegah spoofing domain yang terlihat di kotak masuk, Anda memerlukan kebijakan DMARC yang selaras dengan SPF dan DKIM.

Langkah Berikutnya

Verifikasi dan bersihkan daftar email Anda

Record autentikasi yang baik melindungi domain Anda. BillionVerify menjaga daftar Anda tetap sehat dengan verifikasi email akurat 99.9%.

600 kredit gratis/bulan + 20/hari bonus login ยท Akurasi SMTP 99.9% ยท Akses API instan ยท Tanpa kartu kredit

99.9%
Akurasi
Real-time
Kecepatan API
$0.00014
Per email
600/mo
Gratis selamanya