Audit keamanan email domain Anda di setiap push dengan GitHub Actions

Seseorang di tim Anda memperbarui data DNS. Entri TXT dihapus selama migrasi penyedia. Data SPF Anda secara diam-diam melebihi batas 10 pencarian. Email mulai masuk ke spam. Tidak ada pemberitahuan selama dua minggu hingga pelanggan menyebutkan bahwa mereka tidak pernah menerima faktur Anda.

Catatan keamanan email berbasis DNS (SPF, DMARC, DKIM) adalah jenis infrastruktur yang berfungsi dengan sempurna sampai tidak. Ketika rusak, mode kegagalan tidak bersuara: tidak ada kesalahan, tidak ada peringatan, email hilang ke folder spam.

Panduan ini menyiapkan Tindakan GitHub yang memvalidasi ketiga catatan pada setiap push. Jika setiap catatan hilang atau salah dikonfigurasi, alur kerja gagal dan memberi tahu Anda apa yang rusak.

Apa yang dilakukan alur kerja

Pada setiap dorongan ke main, tindakannya:

1. Memanggil botoi /v1/dns-security/spf-check titik akhir untuk memvalidasi data SPF Anda
2. Panggilan /v1/dns-security/dmarc-check untuk memvalidasi kebijakan DMARC Anda
3. Panggilan /v1/dns-security/dkim-check untuk memverifikasi kunci DKIM Anda diterbitkan
4. Keluar dengan kode bukan nol jika ada pemeriksaan yang gagal, sehingga memblokir penggabungan

Alur kerja Tindakan GitHub

Membuat .github/workflows/dns-security.yml di repositori Anda:

Mengganti yourdomain.com dengan domain Anda dan google dengan pemilih DKIM penyedia email Anda. Alur kerja berjalan pada setiap dorongan ke main, pada jadwal harian, dan dapat dipicu secara manual dari tab Tindakan.

Apa yang divalidasi oleh setiap pemeriksaan

SPF (Kerangka Kebijakan Pengirim)

SPF menyatakan server email mana yang berwenang mengirim email untuk domain Anda. APInya mengembalikan catatan mentah, daftar mekanisme yang diurai, dan apakah catatan tersebut valid.

Bidang utama yang harus diperhatikan:

• has_spf: Apakah ada data TXT yang dimulai dengan v=spf1? Jika salah, server mana pun dapat mengklaim mengirim email dari domain Anda.
• valid: Apakah catatan diurai dengan benar? Rekor SPF dipecahkan ketika mereka melebihi 10 batas pencarian DNS atau mengandung kesalahan sintaksis.
• all_policy: Mekanisme tambahan. -all (gagal keras) adalah pengaturan terkuat. ~all (kegagalan lunak) menandai email yang tidak sah sebagai mencurigakan. +all menggagalkan tujuan SPF sepenuhnya.

Contoh respons API untuk data SPF yang sehat:

DMARC (Otentikasi, Pelaporan, dan Kesesuaian Pesan Berbasis Domain)

DMARC memberi tahu server penerima apa yang harus dilakukan ketika pemeriksaan SPF atau DKIM gagal. Tanpa itu, bahkan catatan SPF dan DKIM yang valid tidak mencegah spoofing.

Bidang utama yang harus diperhatikan:

• policy: Apa yang terjadi pada pesan yang gagal. reject tetes mereka, quarantine mengirimnya ke spam, none tidak mengambil tindakan (hanya pemantauan).
• pct: Persentase pesan yang terkena kebijakan tersebut. Mulailah dari yang rendah nomor selama peluncuran, lalu pindah ke 100.
• reporting.rua: Tempat laporan agregat dikirim. Tanpa ini, kamu tidak memiliki visibilitas terhadap kegagalan autentikasi.

Contoh respons API untuk data DMARC:

DKIM (Surat Teridentifikasi DomainKeys)

DKIM menambahkan tanda tangan kriptografi ke pesan keluar. Server penerima memverifikasi tanda tangan terhadap kunci publik yang dipublikasikan di DNS Anda. Jika kuncinya hilang atau diputar tanpa memperbarui DNS, verifikasi tanda tangan gagal.

Bidang utama yang harus diperhatikan:

• has_dkim: Apakah kunci DKIM dipublikasikan untuk pemilih tertentu? Setiap email penyedia menggunakan nama pemilih yang berbeda.
• public_key_length: NIST merekomendasikan minimum 2048 bit. Kuncinya lebih pendek dari 1024 bit dianggap lemah.
• key_type: Kebanyakan kunci menggunakan RSA. Kunci Ed25519 lebih kecil dan lebih cepat memiliki dukungan terbatas di seluruh penyedia email.

Contoh respons API untuk pemeriksaan DKIM:

Pemilih DKIM umum menurut penyedia

Penyedia email	Pemilih DKIM
Google Ruang Kerja	google
Microsoft 365	selector1, selector2
Amazon SES	Berbasis UUID (periksa dashboard SES Anda)
Simpanse Surat / Mandrill	k1
KirimGrid	s1, s2
Cap pos	Dihasilkan per domain (periksa pengaturan DNS)

Memperluas alur kerja

Beberapa domain

Jika Anda mengelola beberapa domain, gunakan strategi matriks untuk memeriksa masing-masing domain. Tambahkan botoi Kunci API sebagai rahasia GitHub untuk menghindari mencapai batas tarif tingkat gratis.

Pemberitahuan kendur jika terjadi kegagalan

Tambahkan langkah notifikasi yang diaktifkan ketika pemeriksaan apa pun gagal. Ini menggunakan Aksi Slack GitHub resmi:

Monorepo setup

Dalam monorepo, Anda mungkin tidak ingin pemeriksaan DNS berjalan pada setiap push to every paket. Cakupan pemicu perubahan pada file terkait infrastruktur:

Pemicu terjadwal masih berjalan setiap hari terlepas dari filter jalurnya, sehingga Anda menangkap DNS perubahan yang dilakukan di luar repositori.

Menggunakan kunci API untuk batas tarif yang lebih tinggi

Jika Anda memeriksa beberapa domain atau sering menjalankan alur kerja, tambahkan kunci API botoi Anda sebagai rahasia Tindakan GitHub:

1. Buka Pengaturan repo Anda > Rahasia dan variabel > Tindakan
2. Tambahkan rahasia bernama BOTOI_API_KEY
3. Tambahkan header auth ke setiap perintah curl:

Apa yang harus dilakukan jika pemeriksaan gagal

• Catatan SPF tidak ada: Tambahkan data TXT ke DNS domain Anda. Mulailah dengan v=spf1 include:_spf.google.com ~all (ganti include dengan milik Anda domain SPF penyedia email).
• Data SPF tidak valid: Anda mungkin mencapai batas 10 pencarian DNS. Gunakan sebuah Alat perata SPF untuk menggantikan include: mekanisme dengan alamat IP, atau konsolidasi penyedia.
• Data DMARC tidak ada: Tambahkan data TXT di _dmarc.yourdomain.com. Mulailah dengan v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com untuk memantau sebelum menegakkan.
• Kebijakan DMARC adalah "tidak ada": Ini baik-baik saja selama peluncuran. Setelah Anda mengonfirmasi email sah lolos SPF dan DKIM, pindah ke p=quarantine kemudian p=reject.
• Catatan DKIM tidak ada: Pastikan Anda memiliki pemilih yang benar untuk Anda penyedia email (lihat tabel di atas). Kuncinya harus dipublikasikan sebagai data TXT di [selector]._domainkey.yourdomain.com.
• Kunci DKIM terlalu pendek: Putar kunci DKIM Anda ke 2048 bit melalui Anda panel admin penyedia email, lalu perbarui data TXT DNS.