SPF mencatat detail server mana yang diizinkan mengirim email untuk domain Anda.
Pertanyaan 1-3 benar-benar merangkum seluruh poin SPF: Anda seharusnya mencantumkan alamat semua server yang berwenang mengirim email yang berasal dari domain Anda.
Jika Anda tidak memiliki daftar lengkap saat ini, umumnya bukan ide yang baik untuk membuat catatan SPF. Juga sebuah domain hanya dapat memiliki satu catatan SPF, jadi Anda harus menggabungkan semua informasi menjadi satu catatan.
Pertanyaan-pertanyaan individu benar-benar hanya membantu memecah daftar untuk Anda.
- meminta Anda untuk domain lain yang server emailnya mungkin menyampaikan email dari Anda; jika Anda memiliki mis. server MX sekunder di mail-relay.example.org, dan itu adalah server mail utama (data MX) untuk domain
example.org, maka Anda harus memasukkan mx:example.org. Data SPF Anda harus menyertakan data MX domain Anda sendiri di hampir semua keadaan ( mx).
- meminta Anda untuk netblocks ip Anda. Jika Anda memiliki server colocated di 1.2.3.0/28, dan ruang alamat kantor Anda adalah 6.7.8.0/22, masukkan
ip4:1.2.3.0/28 ip4:6.7.8.0/22. Ruang IPv6 harus ditambahkan seperti misalnya ip6:2a01:9900:0:4::/64.
- jika (misalnya) Anda juga mematikan mesin di kantor orang lain yang harus diizinkan mengirim email dari domain Anda, masukkan juga, dengan mis
a:mail.remote.example.com.
Pengguna ponsel Anda bermasalah. Jika mereka mengirim email dengan menghubungkan ke server email Anda menggunakan misalnya SMTP AUTH, dan mengirim melalui server itu, maka Anda sudah berurusan dengan mereka dengan mencantumkan alamat server email di (2). Jika mereka mengirim email dengan hanya menghubungkan ke mail server apapun persembahan penyedia 3G / HSDPA, maka Anda tidak bisa melakukan SPF bermakna sampai Anda telah rearchitected infrastruktur email Anda sehingga Anda lakukan mengontrol setiap titik dari mana email yang mengaku dari Anda hits Internet.
Pertanyaan 4 agak berbeda, dan menanyakan apa yang harus dilakukan penerima dengan email yang mengklaim berasal dari domain Anda yang tidak berasal dari salah satu sistem yang tercantum di atas. Ada beberapa tanggapan hukum, tetapi yang menarik hanyalah ~all(gagal lunak) dan -all(gagal keras). ?all(tidak ada jawaban) sama tidak bergunanya dengan ~all(qv), dan +allmerupakan kekejian.
~alladalah pilihan sederhana; ini memberi tahu orang-orang bahwa Anda telah mendaftarkan banyak sistem yang berwenang mengirim email dari Anda, tetapi Anda tidak berkomitmen untuk daftar itu menjadi lengkap, jadi email dari domain Anda yang berasal dari sistem lain mungkin masih legal. Saya mendorong Anda untuk tidak melakukan itu. Tidak hanya membuat SPF benar-benar tidak berguna, tetapi beberapa admin surat di SF dengan sengaja mengkonfigurasi penerima SPF mereka untuk diperlakukan ~allsebagai lencana dari seorang spammer. Jika Anda tidak akan melakukannya -all, jangan repot-repot dengan SPF sama sekali .
-alladalah pilihan yang berguna; itu memberi tahu orang-orang bahwa Anda telah mendaftarkan sistem yang diizinkan mengirim email dari Anda, dan bahwa tidak ada sistem lain yang diizinkan melakukannya, jadi mereka boleh menolak email dari sistem yang tidak tercantum dalam catatan SPF Anda. Ini adalah poin SPF, tetapi Anda harus yakin bahwa Anda telah mendaftarkan semua host yang berwenang untuk memulai atau menyampaikan email dari Anda sebelum Anda mengaktifkannya .
Google diketahui menyarankan hal itu
Menerbitkan catatan SPF yang menggunakan -all bukannya ~ semua dapat menyebabkan masalah pengiriman.
baik, ya, mungkin; itulah inti dari SPF . Kami tidak tahu pasti mengapa Google memberikan saran ini, tetapi saya sangat curiga bahwa ini untuk mencegah sysadmin yang tidak tahu persis dari mana email mereka berasal menyebabkan masalah pengiriman. Jika Anda tidak tahu dari mana semua email Anda berasal, jangan gunakan SPF . Jika Anda akan menggunakan SPF, daftarkan semua tempat asalnya, dan beri tahu dunia bahwa Anda yakin dengan daftar itu -all.
Perhatikan bahwa tidak ada yang mengikat server penerima; fakta bahwa Anda mengiklankan catatan SPF sama sekali tidak mengharuskan orang lain untuk menghormatinya. Terserah admin server surat yang diberikan, email apa yang mereka pilih untuk terima atau tolak. Apa yang saya pikir SPF lakukan adalah memungkinkan Anda untuk melepaskan tanggung jawab lebih lanjut atas email yang diklaim berasal dari domain Anda, tetapi ternyata tidak. Admin email mana pun yang mendatangi Anda mengeluh bahwa domain Anda mengirimi mereka spam ketika mereka tidak mau repot-repot memeriksa catatan SPF yang Anda iklankan yang akan memberi tahu mereka bahwa email yang seharusnya ditolak dapat dengan adil dikirim dengan kutu di telinga mereka.
Karena jawaban ini dikanonikalisasi, saya lebih baik mengatakan beberapa hal tentang includedan redirect. Yang terakhir lebih sederhana; jika catatan SPF Anda, katakanlah example.com, katakan redirect=example.org, maka example.orgcatatan SPF Anda menggantikan milik Anda. example.orgjuga diganti untuk domain Anda di mereka lihat-up (misalnya, jika example.orgrecord 's meliputi mxmekanisme, yang MXlookup harus dilakukan pada example.org, bukan pada domain Anda sendiri).
includesecara luas disalahpahami, dan sebagai penulis standar mencatat " nama 'termasuk' kurang dipilih ". Jika SPF record Anda includes example.org'catatan s, maka example.org' s catatan harus diperiksa oleh penerima untuk melihat apakah itu memberikan alasan apapun (termasuk +all) untuk menerima email Anda . Jika ya, email Anda harus lulus. Jika tidak, penerima harus terus memproses catatan SPF Anda hingga mendarat di allmekanisme Anda . Dengan demikian, -allatau memang ada penggunaan lain allkecuali +all, dalam includecatatan d, tidak berpengaruh pada hasil pemrosesan.
Untuk informasi lebih lanjut tentang catatan SPF http://www.openspf.org adalah sumber yang bagus.
Tolong jangan mengambil ini dengan cara yang salah, tetapi jika Anda mendapatkan catatan SPF yang salah, Anda dapat menghentikan sebagian besar internet dari menerima email dari Anda sampai Anda memperbaikinya. Pertanyaan Anda menunjukkan bahwa Anda mungkin tidak sepenuhnya puas dengan apa yang Anda lakukan, dan jika itu masalahnya, maka Anda mungkin ingin mempertimbangkan untuk mendapatkan bantuan profesional sebelum Anda melakukan sesuatu yang menghentikan Anda mengirim email ke banyak sekali orang.
Sunting : terima kasih atas kata-kata baik Anda, mereka sangat dihargai.
SPF terutama teknik untuk mencegah joe-jobbing , tetapi beberapa orang tampaknya sudah mulai menggunakannya untuk mencoba mendeteksi spam. Beberapa dari mereka mungkin memang melampirkan nilai negatif untuk Anda yang tidak memiliki catatan SPF sama sekali, atau catatan overbroad (misalnya a:3.4.5.6/2 a:77.5.6.7/2 a:133.56.67.78/2 a:203.54.32.1/2, yang agak menyamakan dengan +all), tetapi itu terserah mereka dan tidak banyak yang dapat Anda lakukan tentang hal itu.
Secara pribadi saya pikir SPF adalah hal yang baik, dan Anda harus mengiklankan catatan jika struktur surat Anda saat ini mengizinkannya, tetapi sangat sulit untuk memberikan jawaban resmi, valid untuk seluruh internet, tentang bagaimana orang menggunakan catatan DNS yang dirancang untuk tujuan khusus, ketika mereka memutuskan untuk menggunakannya untuk tujuan yang berbeda. Semua saya dapat mengatakan dengan pasti adalah bahwa jika Anda melakukan beriklan catatan SPF dengan kebijakan -all, dan Anda mendapatkan salah, banyak orang tidak akan pernah melihat email Anda.
Sunting 2 : dihapus berdasarkan komentar, dan untuk menjaga agar jawabannya tetap terbaru.