Server yang terotorisasi tetap bisa mengirim pesan yang tidak diinginkan. Tanda tangan yang valid bisa milik domain yang berbeda dari yang ditampilkan kepada penerima. Setiap pemeriksaan menjawab pertanyaan berbeda tentang pesan tersebut.
Apa yang dibuktikan setiap pemeriksaan?
SPF memeriksa IP pengirim, DKIM memeriksa tanda tangan, dan DMARC menghubungkan hasil lolos ke domain From yang terlihat.
| Pemeriksaan | Identitas yang diperiksa | Yang ditetapkan saat lolos | Yang tidak ditetapkan |
|---|---|---|---|
| SPF | Domain envelope-from, biasanya digunakan untuk bounce | IP yang terhubung terotorisasi oleh kebijakan domain tersebut. | Domain From yang terlihat atau integritas pesan. |
| DKIM | Domain penandatangan dalam nilai d= tanda tangan | Tanda tangan terverifikasi terhadap kunci yang dipublikasikan dan konten yang ditandatangani. | Bahwa setiap bagian pesan ditandatangani atau bahwa penerima menginginkannya. |
| DMARC | Domain From yang terlihat | Setidaknya satu hasil SPF atau DKIM yang lolos selaras dengan domain tersebut. | Jaminan pengiriman atau penempatan di inbox. |
Bagaimana cara kerja SPF?
Penerima membandingkan IP server yang terhubung dengan kebijakan SPF yang dipublikasikan di DNS untuk domain envelope-from. Pemeriksaan ini bisa dilakukan sebelum menerima isi pesan, karena SPF tidak memeriksa konten.
- Anda mempublikasikan server atau layanan yang terotorisasi menggunakan domain tersebut.
- Penerima mencari kebijakan tersebut dan mengevaluasi aturannya terhadap IP yang terhubung.
- Penerima menggunakan hasilnya bersama kebijakan penerimaan dan penyaringannya sendiri.
Jika kotak surat alumni meneruskan pesan ke penyedia lain tanpa mengubah alamat envelope-from, IP penerus mungkin tidak memiliki otorisasi. Milis bisa menimbulkan masalah yang sama saat mengirim ulang pesan. Penerus bisa menggunakan Sender Rewriting Scheme (SRS), yang mengubah alamat envelope-from ke domain yang dapat diautentikasi.
Rekaman SPF menentukan pengirim yang terotorisasi. Kebijakan penyedia bertingkat dihitung terhadap batas pencarian DNS.
Bagaimana cara kerja DKIM?
Server pengirim Anda menandatangani konten pesan dengan kunci privat. Penerima menggunakan kunci publik terkait di DNS untuk memverifikasi tanda tangan tersebut.
Tanda tangan mengidentifikasi domain penandatangan dengan d= dan selektor kunci dengan s=. Selektor mengidentifikasi rekaman DNS mana yang berisi kunci publik. Penerima mencari kunci publik dan memverifikasi tanda tangan menggunakan domain dan selektor tersebut.
Penerusan saja tidak membatalkan DKIM, karena pemeriksaan ini tidak bergantung pada IP server penerus. Mengubah konten yang ditandatangani, seperti menambahkan footer milis, dapat membatalkan tanda tangan. Tanda tangan mengautentikasi konten yang dicakupnya; tanda tangan tidak mengenkripsi pesan.
Bagaimana DMARC menghubungkan identitas-identitas tersebut?
DMARC mengharuskan hasil SPF atau DKIM yang lolos dengan domain yang selaras dengan domain From yang terlihat. Salah satu hasil lolos yang selaras sudah cukup.
Misalnya, pesan yang menampilkan From: billing@example.com bisa lolos SPF untuk send.example.com dengan keselarasan longgar. Tanda tangan DKIM yang lolos dengan d=example.com juga selaras. Autentikasi untuk unrelated.example tidak selaras dengan example.com hanya karena lolos.
Anda mempublikasikan kebijakan DMARC untuk meminta penanganan pesan yang gagal dan laporan autentikasi. Penerima yang berpartisipasi menyediakan laporan; ketiadaan laporan tidak membuktikan bahwa tidak ada email yang menggunakan domain Anda.
Apa yang harus Anda konfigurasi untuk Bird?
Anda mempublikasikan DKIM, CNAME return-path, dan DMARC untuk domain pengiriman Anda. CNAME return-path mengarah ke infrastruktur bounce Bird, yang menyediakan otorisasi SPF tanpa rekaman apex SPF tambahan.
Salin rekaman dari dns_records. Periksa capabilities.sending.status untuk kesiapan pengiriman. Nilainya mengidentifikasi apa yang perlu Anda lakukan selanjutnya:
| Status | Arti dan tindakan |
|---|---|
pending | Verifikasi belum berjalan atau sedang berjalan; tunggu hasilnya. |
verified | Rekaman DNS kapabilitas ini sesuai dengan nilai yang diharapkan. |
warning | Rekaman yang sebelumnya terverifikasi tidak lagi sesuai; perbaiki sebelum masa tenggang berakhir. Pengiriman belum terpengaruh. |
failed | Nilai DNS salah; perbaiki. |
temporary_failure | Pencarian DNS gagal sementara; verifikasi dicoba ulang secara otomatis. |
not_configured | Kapabilitas ini belum dikonfigurasi untuk domain ini. |
Anda mempublikasikan rekaman autentikasi dan memverifikasi domain pengiriman Anda.
Pemeriksaan mana yang harus Anda gunakan?
Gunakan SPF dan DKIM bersama DMARC agar identitas yang terautentikasi terhubung ke domain yang dilihat penerima Anda.
- Otorisasi infrastruktur pengiriman domain envelope-from dengan SPF.
- Tandatangani pesan keluar dengan DKIM dan publikasikan kunci verifikasinya.
- Publikasikan DMARC, tinjau kegagalan autentikasi yang dilaporkan, dan perbaiki pengirim yang sah sebelum menerapkan karantina atau penolakan.