Pilih identitas bisnis sebelum mengedit DNS
FreeAgent dapat mengirimkan perkiraan dan faktur menggunakan identitas Dari defaultnya sendiri atau domain khusus terverifikasi. Putuskan identitas mana yang harus dilihat pelanggan dan kotak surat mana yang harus menerima balasan mereka. Dokumentasikan faktur dan perkirakan alur kerja, pemiliknya, dan administrator DNS sebelum mengubahnya. Pengiriman aplikasi keuangan yang berhasil tidak sama dengan bukti bahwa domain bisnis yang dimaksud diautentikasi.
Panduan FreeAgent yang ditinjau mengatakan alamat Dari default adalah noreply@remail.freeagentcentral.com . Domain yang Anda miliki dapat diotorisasi melalui pengaturan domain khusus; kotak surat konsumen di domain publik bersama tidak dapat memberi Anda kendali atas DNS domain tersebut. Verifikasi alamat individu dan otorisasi domainnya merupakan langkah yang berbeda. Sumber: FreeAgent, Otorisasi FreeAgent untuk mengirim email dari alamat bisnis Anda.
Selesaikan alur kerja domain khusus saat ini
Buka Pengaturan > Mengirim Email, pilih Tambahkan Domain Email Khusus dan pilih domain yang terkait dengan alamat pengirim terverifikasi. Jika tidak ada, tambahkan dan verifikasi alamat di domain tersebut terlebih dahulu. Salin informasi host/kunci dan nilai yang ditampilkan pada langkah 2 ke layanan DNS otoritatif, lalu kembalikan dan tambahkan domain. FreeAgent memeriksa catatan tersebut. Sumber: Panduan domain khusus FreeAgent.
Perlakukan rekaman akun yang ditampilkan sebagai otoritatif untuk pengaturan ini. Jangan menggantinya dengan sejarah pemilih, kunci atau SPF nilai yang ditemukan dalam artikel lama. Tangkap jenis catatan, nama pemilik lengkap, nilai dan tanggal dalam catatan perubahan. Jika layar dan dokumentasi berbeda, selesaikan perbedaan tersebut sebelum melanjutkan daripada menggabungkan kedua generasi pengaturan.
Periksa catatan yang ada di setiap pemilik sebelum mengedit. Kunci publik TXT dan token verifikasi dapat memiliki tujuan berbeda meskipun keduanya muncul dalam satu wizard. Pertahankan entri aplikasi lain. Pendaftar dan host DNS mungkin berbeda: verifikasi yang didelegasikan server nama alih-alih berasumsi perusahaan tempat pembelian domain memublikasikan catatannya.
Tinjau instruksi SPF dalam konteksnya
Nama panduan FreeAgent saat ini include:spf.mtasv.net ketika kebijakan SPF ketat yang ada diakhiri dengan -all . Dikatakan bahwa kebijakan SPF baru yang terpisah umumnya tidak diperlukan untuk alur kerjanya. Jangan mengganti penyertaan FreeAgent lama yang ditemukan di tempat lain. Sumber: Bagian SPF FreeAgent.
Instruksi produk tersebut bukan alasan untuk menghapus kebijakan SPF yang berfungsi, melemahkan kualifikasi akhirnya, atau menganggap semua email kini lolos DMARC. Jika perubahan SPF diperlukan, gabungkan otorisasi ke dalam kebijakan yang ada setelah menginventarisasi semua pengirim dan memeriksa batas pencarian DNS. Pertahankan layanan lainnya. Pisahkan tugas otorisasi sempit ini dari desain ulang kebijakan seluruh domain.
Verifikasi perubahan menggunakan rute faktur terkontrol
Sebelum pengujian, hindari transaksi pelanggan nyata atau komitmen keuangan. Gunakan alur kerja pengujian resmi dan penerima yang dikontrol, dengan konten yang jelas-jelas fiktif. Catat alur kerja FreeAgent mana yang mengirimkan pesan dan apakah pesan Dari yang terlihat cocok dengan alamat bisnis yang disetujui. Periksa Reply-To secara mandiri dengan memeriksa dan, jika perlu, menguji tujuan balasan.
Simpan pesan asli yang diterima pada penerima tepercaya Authentication-Results, Dari, amplop identitas dan DKIM menandatangani domain/pemilih. SPF mengautentikasi identitas amplop, bukan secara otomatis Dari. DKIM memverifikasi tanda tangan yang terkait dengan domain d=-nya. DMARC memerlukan identitas SPF atau DKIM yang sesuai dengan Dari di bawah yang berlaku penyelarasan mode. Verifikasi produk dan tampilan kotak masuk tidak dapat menggantikan bukti ini.
Contoh sintetik: perkiraan diterima dengan Dari accounts@example.com , tiket SPF untuk domain amplop milik penyedia, dan tiket DKIM dengan d=example.com. Pencocokan persis tanda tangan DKIM dapat menyediakan jalur DMARC yang selaras; keberhasilan SPF yang tidak terkait tidak bisa. Jika pesan selanjutnya menggunakan Dari default penyedia, pesan tersebut mungkin mengautentikasi dengan benar untuk identitas default tersebut namun tetap gagal dalam kondisi penerimaan merek Anda. Perlakukan penyampaian dan identitas yang diinginkan sebagai hasil yang terpisah.
Diagnosis pengembalian dan pertahankan pemulihan yang aman
FreeAgent memperingatkan bahwa menghapus atau mengubah catatan DNS yang diperlukan dapat membuat domain khusus tidak terverifikasi dan mengembalikan alamat Dari ke defaultnya; itu juga mengirimkan pemberitahuan. Pantau konsekuensi operasional migrasi DNS , tidak hanya apakah zona baru dimuat. Pertahankan catatan yang diperlukan saat mengubah penyedia DNS , dan uji alur kerja yang dihadapi pelanggan setelahnya.
Jika validasi gagal, bandingkan nilai akun dengan DNS otoritatif, periksa duplikasi akhiran nama pemilik dan karakter yang dihilangkan sebelum menunggu masa berlaku cache habis. Jika konfigurasi sudah benar tetapi surat hilang, simpan status pengiriman dan bukti penerima yang sebenarnya, lalu selidiki pengiriman secara terpisah. Jangan berjanji bahwa penundaan waktu saja akan menyelesaikan masalah.
Sebelum menghapus catatan historis khusus FreeAgent, pastikan catatan tersebut sudah usang dan tidak digunakan oleh rute aktif lainnya. Simpan salinan yang dapat dibalik dan pengaturan pengirim yang diketahui berfungsi dan disetujui. Penyelesaiannya memerlukan verifikasi akun, catatan resmi, dan bukti pesan aktual yang diterima untuk rute faktur dan perkiraan yang relevan. Panduan dokumenter ini tidak melakukan satu pun operasi langsung tersebut; tinjauan independen, persetujuan dan publikasi UKM manusia masih menunggu keputusan.
Klasifikasikan perkiraan yang disampaikan tanpa membuat tes pembayaran
Kasus tertulis FA-01 mengasumsikan Dari yang disetujui adalah accounts@example.com , tetapi sampel perkiraan fiktif menunjukkan Dari default penyedia yang terdokumentasi setelah data DNS yang diperlukan dihapus. Hasil otentikasi penerima dan Reply-To tidak diketahui. Pengiriman yang berhasil saja tidak dapat menetapkan identitas yang diinginkan atau autentikasi yang selaras misalnya example.com . Pemilik alur kerja keuangan harus merekonsiliasi verifikasi akun saat ini dan DNS dengan administrator, kemudian menggunakan tes tidak mengikat resmi dan memeriksa bidang pengirim dan balasan yang sebenarnya. Jangan membuat invoice atau kewajiban pembayaran sebenarnya hanya untuk mendapatkan header. Tidak ada pelanggan, transaksi, catatan atau pesan yang diakses untuk kasus ini.
Pertahankan batas penegakan hukum
RFC 9989 Bagian 7.4 memerlukan DKIM yang valid, bukan SPF saja, untuk penerbitan domain p=reject, dan memperingatkan tentang interoperabilitas surat tidak langsung dan milis. Sebuah uji coba pesan langsung yang sukses bukanlah bukti bahwa setiap jalur yang sah siap untuk menerapkan kebijakan yang lebih kuat. Pertahankan perlindungan yang disetujui saat mendiagnosis kesenjangan yang sebenarnya; setiap perubahan kebijakan memerlukan keputusannya sendiri.