SPF, DMARC, dan DKIM: panduan autentikasi email lengkap

Domain Anda lolos setiap pemindaian keamanan. Sertifikat SSL Anda valid, header Anda ketat, milik Anda CSP terkunci. Kemudian email phishing masuk ke kotak masuk pelanggan, dari domain Anda, dengan nama perusahaan Anda di kolom "Dari". Emailnya palsu, tapi kerusakannya nyata.

Hal ini terjadi karena email dirancang pada tahun 1982 tanpa verifikasi pengirim bawaan. Siapapun dapat menyetel alamat "Dari" apa pun di email, dan tanpa data SPF, DMARC, dan DKIM di email Anda domain, server penerima tidak memiliki cara untuk menangkap pemalsuan. Lebih dari 90% serangan phishing menggunakan spoofing domain, dan otentikasi email yang salah dikonfigurasi adalah pintu terbuka.

Panduan ini mencakup fungsi masing-masing catatan, cara kerja sama, dan cara mengaudit ketiganya di domain mana pun dengan satu skrip menggunakan API keamanan DNS botoi.

Cara kerja otentikasi email

Tiga catatan DNS berfungsi sebagai lapisan pertahanan. Masing-masing memecahkan masalah yang berbeda:

1. SPF jawaban: "Apakah server ini diperbolehkan mengirim email untuk domain ini?"
2. DKIM jawaban: "Apakah pesan ini diubah setelah meninggalkan server pengirim?"
3. DMARC jawaban: “Apa yang harus saya lakukan jika SPF atau DKIM gagal, dan kemana saya harus mengirimkan laporan?”

Ketika seseorang mengirim email yang mengaku berasal dari you@example.com, penerima server memeriksa catatan ini secara berurutan. Jika SPF dan DKIM keduanya gagal, dan DMARC mengatakan p=reject, pesan akan dihapus sebelum mencapai kotak masuk. Tanpa semua ketiga, ada celah yang dieksploitasi oleh penyerang.

SPF: siapa yang dapat mengirim atas nama Anda

SPF (Sender Policy Framework) adalah data TXT DNS di root domain Anda. Ini mencantumkan setiap Alamat IP dan server email yang diberi wewenang untuk mengirim email untuk domain Anda. Ketika server penerima mendapat email dari example.com, ia memeriksa catatan SPF untuk melihat apakah pengirimannya server ada dalam daftar yang disetujui.

Periksa data SPF domain mana pun dengan satu panggilan API:

curl -s -X POST https://api.botoi.com/v1/dns-security/spf-check \\
  -H "Content-Type: application/json" \\
  -d '{"domain": "example.com"}'

Tanggapan:

{
  "success": true,
  "data": {
    "domain": "example.com",
    "has_spf": true,
    "record": "v=spf1 include:_spf.google.com ~all",
    "mechanisms": ["include:_spf.google.com", "~all"],
    "all_policy": "~all",
    "includes": ["_spf.google.com"],
    "valid": true
  }
}

Bidang utama yang harus diperiksa:

• has_spf: Apakah data TXT dimulai dengan v=spf1 ada? Jika salah, server mana pun dapat memalsukan email dari domain Anda.
• valid: Apakah catatan diurai tanpa kesalahan? Catatan SPF dipecahkan secara diam-diam ketika mereka melebihi 10 batas pencarian DNS.
• all_policy: Mekanisme tambahan yang menentukan apa yang terjadi pada pengirim yang tidak terdaftar. -all (gagal keras) menolaknya. ~all (kegagalan lunak) menandai mereka mencurigakan. +all memungkinkan semua orang, yang menggagalkan seluruh tujuan.

Batas 10 pencarian

Data SPF mengizinkan maksimal 10 pencarian DNS. Setiap include:, a:, mx:, Dan redirect: mekanisme dihitung sebagai satu pencarian. Termasuk bersarang menghitung juga. Setelah Anda menambahkan Google Workspace, alat pemasaran Anda, layanan email transaksional Anda, dan CRM, Anda mencapai batas ini dengan cepat.

Bila Anda melebihi 10 pencarian, seluruh data SPF menjadi tidak valid. API-nya valid lapangan menangkap ini. Perbaiki dengan meratakan penyertaan bersarang ke dalam rentang IP atau menggabungkannya penyedia.

DMARC: apa yang harus dilakukan ketika pemeriksaan gagal

DMARC (Otentikasi, Pelaporan, dan Kesesuaian Pesan Berbasis Domain) menghubungkan SPF dan DKIM bersama-sama. Itu tinggal di _dmarc.example.com sebagai catatan TXT dan memberitahu penerimaan server dua hal: apa yang harus dilakukan dengan pesan yang gagal otentikasi, dan ke mana harus mengirim laporan tentang kegagalan tersebut.

Periksa data DMARC Anda:

curl -s -X POST https://api.botoi.com/v1/dns-security/dmarc-check \\
  -H "Content-Type: application/json" \\
  -d '{"domain": "example.com"}'

Tanggapan:

{
  "success": true,
  "data": {
    "domain": "example.com",
    "has_dmarc": true,
    "record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100",
    "policy": "reject",
    "subdomain_policy": null,
    "reporting": {
      "rua": ["mailto:dmarc@example.com"],
      "ruf": []
    },
    "pct": 100,
    "alignment": {
      "dkim": "r",
      "spf": "r"
    }
  }
}

kebijakan DMARC

Itu policy bidang menentukan apa yang terjadi pada pesan yang gagal:

• none: Jangan mengambil tindakan apa pun. Hanya memantau. Anda mendapatkan laporan tetapi tetap menerima email palsu mencapai kotak masuk.
• quarantine: Memindahkan pesan yang gagal ke spam. Penerima masih dapat menemukannya jika mereka melihat.
• reject: Hilangkan seluruh pesan yang gagal. Perlindungan terkuat, tapi kesalahan konfigurasi berarti kehilangan email yang sah.

Strategi peluncuran DMARC yang aman

Langsung ke p=reject berisiko. Ikuti jalan ini:

1. Mulailah dengan p=none; rua=mailto:dmarc@example.com untuk mengumpulkan laporan selama 2-4 minggu
2. Tinjau laporan. Identifikasi pengirim sah yang gagal melakukan autentikasi. Perbaiki penyertaan SPF dan kunci DKIM.
3. Pindah ke p=quarantine; pct=10 untuk mengkarantina 10% pesan yang gagal
4. Meningkatkan pct menjadi 25, 50, lalu 100 selama beberapa minggu berikutnya setelah Anda mengonfirmasi bahwa tidak ada email sah yang terpengaruh
5. Beralih ke p=reject; pct=100 setelah Anda yakin dengan pengaturan Anda

Itu pct bidang respons API menunjukkan posisi Anda dalam peluncuran ini. Sebuah domain di pct=100 dengan policy=reject memiliki perlindungan penuh.

DKIM: tanda tangan kriptografi di setiap email

DKIM (DomainKeys Identified Mail) menambahkan tanda tangan kriptografi ke header masing-masing pesan keluar. Server pengirim menandatangani pesan dengan kunci pribadi; server penerima memverifikasinya terhadap kunci publik yang dipublikasikan di DNS Anda. Jika pesan diubah dalam perjalanan (header diubah, isi diubah, diteruskan melalui milis yang menulis ulang konten), the tanda tangan gagal.

Catatan DKIM ada di [selector]._domainkey.example.com. Pemilihnya adalah label penyedia email Anda menetapkan, misalnya google untuk Google Workspace atau selector1 untuk Microsoft 365.

Periksa data DKIM:

curl -s -X POST https://api.botoi.com/v1/dns-security/dkim-check \\
  -H "Content-Type: application/json" \\
  -d '{"domain": "example.com", "selector": "google"}'

Tanggapan:

{
  "success": true,
  "data": {
    "domain": "example.com",
    "selector": "google",
    "has_dkim": true,
    "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkq...",
    "key_type": "rsa",
    "public_key_length": 2048
  }
}

Bidang utama:

• has_dkim: Apakah kunci publik dipublikasikan untuk pemilih ini? Jika salah, DKIM verifikasi gagal untuk semua pesan yang ditandatangani dengan pemilih ini.
• public_key_length: NIST merekomendasikan minimal 2048 bit. Kunci di bawah 1024 bit cukup lemah untuk difaktorkan.
• key_type: RSA adalah standarnya. Ed25519 lebih cepat dan menggunakan tombol yang lebih pendek namun memiliki dukungan penyedia email yang terbatas.

DKIM dan penerusan email

Inilah sebabnya DKIM penting bahkan ketika SPF dikonfigurasi. Ketika seseorang meneruskan email Anda, IP server penerusan tidak ada dalam data SPF Anda, sehingga SPF gagal. Tapi tanda tangan DKIM bertahan jika diteruskan (selama kontennya tidak diubah). DMARC lolos jika salah satu SPF atau DKIM selaras, sehingga DKIM adalah jaring pengaman Anda untuk pesan yang diteruskan.

Bagaimana ketiganya bekerja sama

Ancaman	SPF	DKIM	DMARC
Email palsu dari server tidak sah	Mendeteksi	Mendeteksi (tidak ada tanda tangan yang valid)	Menegakkan kebijakan
Isi pesan dirusak saat transit	Tidak mendeteksi	Mendeteksi	Menegakkan kebijakan
Email yang diteruskan dari pengirim yang sah	Gagal (IP server berbeda)	Pass (tanda tangan utuh)	Lulus jika DKIM sejajar
Pemalsuan subdomain (pengguna@fake.example.com)	Tidak ada perlindungan	Tidak ada perlindungan	Blokir melalui sp=reject
Visibilitas ke dalam kegagalan otentikasi	Tidak ada	Tidak ada	Mengirimkan laporan agregat

Tidak ada satu catatan pun yang memberikan liputan penuh. SPF tanpa DMARC berarti kegagalan tidak diterapkan. DKIM tanpa SPF berarti siapa pun yang memiliki kunci valid dapat mengirim dari domain Anda. DMARC tanpa keduanya SPF dan DKIM tidak punya alasan untuk menentangnya.

Audit domain Anda dalam 30 detik

Skrip shell ini memeriksa ketiga catatan dan mencetak ringkasan lulus/gagal. Itu menggunakan botoi API keamanan DNS; tidak diperlukan kunci API hingga 5 permintaan per menit.

#!/bin/bash
# Audit SPF, DMARC, and DKIM for a domain in 30 seconds
DOMAIN=\${1:-"example.com"}
DKIM_SELECTOR=\${2:-"google"}
API="https://api.botoi.com/v1/dns-security"
PASS=0
FAIL=0

echo "Auditing email authentication for \$DOMAIN"
echo "==========================================="

# SPF check
SPF=\$(curl -s -X POST "\$API/spf-check" \\
  -H "Content-Type: application/json" \\
  -d "{\\"domain\\": \\"\$DOMAIN\\"}")

HAS_SPF=\$(echo "\$SPF" | jq -r '.data.has_spf')
SPF_VALID=\$(echo "\$SPF" | jq -r '.data.valid')
SPF_RECORD=\$(echo "\$SPF" | jq -r '.data.record // "not found"')
ALL_POLICY=\$(echo "\$SPF" | jq -r '.data.all_policy // "none"')

if [ "\$HAS_SPF" = "true" ] && [ "\$SPF_VALID" = "true" ]; then
  echo "[PASS] SPF: \$SPF_RECORD"
  PASS=\$((PASS + 1))
else
  echo "[FAIL] SPF: \$SPF_RECORD"
  FAIL=\$((FAIL + 1))
fi

if [ "\$ALL_POLICY" = "+all" ]; then
  echo "  WARNING: +all allows any server to send as your domain"
fi

# DMARC check
DMARC=\$(curl -s -X POST "\$API/dmarc-check" \\
  -H "Content-Type: application/json" \\
  -d "{\\"domain\\": \\"\$DOMAIN\\"}")

HAS_DMARC=\$(echo "\$DMARC" | jq -r '.data.has_dmarc')
POLICY=\$(echo "\$DMARC" | jq -r '.data.policy // "not set"')
PCT=\$(echo "\$DMARC" | jq -r '.data.pct // 0')

if [ "\$HAS_DMARC" = "true" ]; then
  echo "[PASS] DMARC: policy=\$POLICY pct=\$PCT%"
  PASS=\$((PASS + 1))
else
  echo "[FAIL] DMARC: no record found"
  FAIL=\$((FAIL + 1))
fi

if [ "\$POLICY" = "none" ]; then
  echo "  WARNING: policy=none only monitors, does not enforce"
fi

# DKIM check
DKIM=\$(curl -s -X POST "\$API/dkim-check" \\
  -H "Content-Type: application/json" \\
  -d "{\\"domain\\": \\"\$DOMAIN\\", \\"selector\\": \\"\$DKIM_SELECTOR\\"}")

HAS_DKIM=\$(echo "\$DKIM" | jq -r '.data.has_dkim')
KEY_TYPE=\$(echo "\$DKIM" | jq -r '.data.key_type // "unknown"')
KEY_LEN=\$(echo "\$DKIM" | jq -r '.data.public_key_length // 0')

if [ "\$HAS_DKIM" = "true" ]; then
  echo "[PASS] DKIM: selector=\$DKIM_SELECTOR key_type=\$KEY_TYPE key_length=\$KEY_LEN"
  PASS=\$((PASS + 1))
else
  echo "[FAIL] DKIM: no record for selector '\$DKIM_SELECTOR'"
  FAIL=\$((FAIL + 1))
fi

if [ "\$HAS_DKIM" = "true" ] && [ "\$KEY_LEN" -lt 2048 ] 2>/dev/null; then
  echo "  WARNING: DKIM key is \$KEY_LEN bits (2048 recommended)"
fi

# Summary
echo ""
echo "Results: \$PASS passed, \$FAIL failed"
[ "\$FAIL" -eq 0 ] && echo "All checks passed." || exit 1

Jalankan:

bash audit.sh example.com google

Argumen pertama adalah domain Anda; yang kedua adalah pemilih DKIM Anda. Script membuat 3 API panggilan (dalam batas tingkat gratis), memeriksa setiap catatan, menandai peringatan untuk konfigurasi yang lemah, dan keluar dengan kode bukan nol jika ada pemeriksaan yang gagal. Masukkan ke dalam tugas cron atau pipeline CI untuk pemantauan berkelanjutan.

Jika Anda lebih suka JavaScript, berikut audit yang sama dengan fungsi async:

async function auditEmailAuth(domain, dkimSelector = "google") {
  const api = "https://api.botoi.com/v1/dns-security";
  const headers = { "Content-Type": "application/json" };

  const [spf, dmarc, dkim] = await Promise.all([
    fetch(\`\${api}/spf-check\`, {
      method: "POST",
      headers,
      body: JSON.stringify({ domain }),
    }).then((r) => r.json()),

    fetch(\`\${api}/dmarc-check\`, {
      method: "POST",
      headers,
      body: JSON.stringify({ domain }),
    }).then((r) => r.json()),

    fetch(\`\${api}/dkim-check\`, {
      method: "POST",
      headers,
      body: JSON.stringify({ domain, selector: dkimSelector }),
    }).then((r) => r.json()),
  ]);

  return {
    domain,
    spf: {
      exists: spf.data.has_spf,
      valid: spf.data.valid,
      record: spf.data.record,
      allPolicy: spf.data.all_policy,
    },
    dmarc: {
      exists: dmarc.data.has_dmarc,
      policy: dmarc.data.policy,
      pct: dmarc.data.pct,
      reporting: dmarc.data.reporting?.rua || [],
    },
    dkim: {
      exists: dkim.data.has_dkim,
      selector: dkimSelector,
      keyType: dkim.data.key_type,
      keyLength: dkim.data.public_key_length,
    },
  };
}

// Usage
const report = await auditEmailAuth("example.com", "google");
console.log(JSON.stringify(report, null, 2));

Konfigurasi penyedia umum

Setiap penyedia email memiliki SPF masing-masing, termasuk domain dan pemilih DKIM. Berikut adalah nilai-nilainya untuk penyedia paling umum:

Penyedia	SPF termasuk	Pemilih DKIM
Google Ruang Kerja	include:_spf.google.com	google
Microsoft 365	include:spf.protection.outlook.com	selector1, selector2
Amazon SES	include:amazonses.com	Berbasis UUID (periksa konsol SES)
KirimGrid	include:sendgrid.net	s1, s2
Cap pos	include:spf.mtasv.net	Per-domain (periksa pengaturan DNS Cap Pos)
Simpanse Surat / Mandrill	include:servers.mcsv.net	k1

Jika Anda menggunakan beberapa penyedia, data SPF Anda menyertakan semuanya dalam satu entri TXT. Misalnya: v=spf1 include:_spf.google.com include:sendgrid.net ~all. Tonton batas 10 pencarian saat Anda menambahkan penyedia.

Poin-poin penting

• SPF mengontrol server mana yang dapat mengirim email untuk domain Anda. Periksa dengan itu /v1/dns-security/spf-check titik akhir. Perhatikan batas 10 pencarian dan menghindari +all.
• DMARC mendefinisikan apa yang terjadi ketika SPF atau DKIM gagal. Luncurkan secara bertahap dari p=none ke p=reject menggunakan pct bidang. Selalu atur sebuah rua alamat untuk menerima laporan.
• DKIM membuktikan integritas pesan dengan tanda tangan kriptografi. Gunakan 2048-bit kunci minimum dan verifikasi pemilih Anda dipublikasikan /v1/dns-security/dkim-check.
• Ketiga rekaman tersebut bekerja bersama-sama. SPF saja tidak menghentikan spoofing email yang diteruskan. DKIM saja tidak memberi tahu penerima apa yang harus dilakukan jika gagal. DMARC tanpa SPF dan DKIM tidak ada yang bisa ditegakkan.
• Otomatiskan pemeriksaan Anda. Jalankan skrip audit sesuai jadwal atau di CI untuk mengetahui penyimpangan DNS, penyedia migrasi, dan penghapusan catatan yang tidak disengaja sebelum mempengaruhi kemampuan pengiriman.