Cara Kerja Email: Panduan Teknis Lengkap tentang Protokol, Langkah-langkah, dan Arsitektur

Email tetap menjadi tulang punggung komunikasi digital bagi bisnis maupun individu, namun mekanisme dasarnya kurang dipahami oleh sebagian besar penggunanya. Pada intinya, pengiriman email adalah proses relay multi-tahap yang diatur oleh rangkaian protokol yang tepat — SMTP untuk transmisi, DNS MX records untuk routing, dan IMAP atau POP3 untuk pengambilan — masing-masing dieksekusi secara berurutan untuk memindahkan pesan dari klien pengirim ke kotak masuk penerima dalam hitungan detik.

Memahami arsitektur ini bukan sekadar akademis. Administrator sistem, pengembang, dan siapa pun yang mengelola lingkungan mail harus memahami bagaimana komponen-komponen ini berinteraksi untuk mendiagnosis kegagalan pengiriman, memperkuat postur keamanan, mengonfigurasi server dengan benar, dan menghindari folder spam. Panduan ini mencakup gambaran teknis lengkap, termasuk kasus-kasus khusus dan mode kegagalan yang secara konsisten dihilangkan oleh artikel-artikel pengantar.

Komponen Utama Infrastruktur Email

Sebelum menelusuri siklus hidup sebuah email, penting untuk mengidentifikasi sistem-sistem diskrit yang terlibat. Masing-masing memainkan peran yang tidak dapat dinegosiasikan, dan kesalahan konfigurasi pada salah satunya dapat secara diam-diam merusak pengiriman.

Klien Email (MUA — Mail User Agent)

Mail User Agent (MUA) adalah antarmuka yang digunakan pengguna untuk menulis, mengirim, dan membaca email. Contohnya termasuk Microsoft Outlook, Apple Mail, Mozilla Thunderbird, dan klien berbasis browser seperti antarmuka web Gmail. MUA tidak mengirimkan email langsung ke penerima. Tugasnya adalah menyerahkan pesan ke Mail Submission Agent (MSA), yang biasanya berjalan di port 587 dengan autentikasi, yang kemudian meneruskannya ke server SMTP keluar.

Kesalahpahaman arsitektur yang umum adalah memperlakukan MUA dan server SMTP sebagai satu unit. Keduanya tidak sama. MUA adalah klien; infrastruktur SMTP adalah lapisan transport.

Mail Server (MTA — Mail Transfer Agent)

Mail Transfer Agent (MTA) adalah perangkat lunak server yang bertanggung jawab untuk merelay email antar sistem. Postfix, Exim, Sendmail, dan Microsoft Exchange adalah MTA yang paling banyak digunakan. MTA dapat bertindak sebagai pengirim maupun penerima, tergantung arah transaksi. MTA-lah yang melakukan pencarian DNS, membangun koneksi SMTP ke server jarak jauh, dan mengantrekan pesan untuk dicoba ulang ketika pengiriman gagal.

Mail Delivery Agent (MDA)

Sering diabaikan dalam penjelasan yang disederhanakan, Mail Delivery Agent (MDA) adalah komponen yang mengambil pesan yang diterima oleh MTA penerima dan menempatkannya ke dalam kotak surat pengguna yang tepat di disk. Dovecot dan Courier adalah MDA yang umum. MDA memberlakukan kuota kotak surat, menerapkan aturan pemfilteran sisi server (skrip Sieve), dan menulis pesan ke format penyimpanan yang sesuai (Maildir atau mbox).

DNS dan MX Records

Domain Name System adalah tulang punggung routing email. Tanpa MX (Mail Exchange) record yang valid, tidak ada server eksternal yang dapat menemukan tempat pengiriman mail untuk domain tertentu. MX records membawa nilai prioritas — angka yang lebih rendah menunjukkan prioritas yang lebih tinggi — memungkinkan administrator untuk mengonfigurasi server mail utama dan cadangan. MTA pengirim melakukan kueri MX records, kemudian me-resolve hostname yang dihasilkan ke alamat IP melalui A atau AAAA record sebelum memulai koneksi.

Proses Pengiriman Email: Langkah demi Langkah

Langkah 1: Komposisi dan Pengiriman Pesan

Pengguna menulis pesan di MUA mereka, menentukan alamat penerima, baris subjek, konten isi, dan lampiran apa pun. Lampiran dan konten HTML dikodekan menggunakan MIME (Multipurpose Internet Mail Extensions), yang membungkus data biner dalam format yang dikodekan base64 yang aman untuk transmisi melalui SMTP berbasis teks. Pesan dengan lampiran PDF, misalnya, dibagi menjadi beberapa bagian MIME: satu untuk isi teks dan satu untuk biner yang dikodekan.

Ketika pengguna mengklik “Kirim,” MUA membuka koneksi terautentikasi dan terenkripsi ke server mail keluar — biasanya di port 587 (STARTTLS) atau port 465 (SMTPS). Autentikasi melalui SASL (Simple Authentication and Security Layer) mencegah penyalahgunaan relay yang tidak sah.

Langkah 2: Handshake SMTP dan Transfer Pesan

MTA pengirim memulai sesi SMTP dengan handshake formal:

1. Klien mengirim `EHLO` (Extended HELO), mengidentifikasi dirinya berdasarkan hostname.
2. Server merespons dengan kemampuannya (misalnya, STARTTLS, AUTH, batas SIZE).
3. Klien mengeluarkan `MAIL FROM:<sender@domain.com>` untuk mendeklarasikan pengirim amplop.
4. Klien mengeluarkan `RCPT TO:<recipient@domain.com>` untuk mendeklarasikan penerima.
5. Klien mengirim `DATA`, diikuti oleh header dan isi pesan lengkap.
6. Sesi ditutup dengan `QUIT`.

Dialog SMTP ini sama baik koneksi antara klien dan server pengirimannya, maupun antara dua MTA yang merelay mail melalui internet.

Langkah 3: Resolusi DNS dan Pencarian MX

Sebelum MTA pengirim dapat terhubung ke server penerima, ia harus me-resolve tujuan. Prosesnya mengikuti urutan yang ketat:

1. Kueri DNS untuk MX records dari domain penerima (misalnya, `example.com`).
2. Menerima satu atau lebih MX records, masing-masing dengan hostname dan nilai prioritas.
3. Me-resolve hostname MX ke alamat IP melalui A record (IPv4) atau AAAA record (IPv6).
4. Mencoba koneksi ke host MX dengan prioritas tertinggi (angka terendah) terlebih dahulu.

Kasus khusus kritis: Jika tidak ada MX record untuk suatu domain, RFC 5321 menetapkan bahwa MTA pengirim harus beralih ke A record domain tersebut dan mencoba pengiriman langsung. Perilaku ini sering dieksploitasi dalam domain yang salah dikonfigurasi dan dapat menyebabkan jalur pengiriman yang tidak terduga. Selain itu, jika MX record menunjuk ke CNAME, ini melanggar RFC 2181 dan dapat menyebabkan kegagalan pengiriman dengan MTA yang ketat.

Langkah 4: Relay SMTP Server-ke-Server

Setelah alamat IP di-resolve, MTA pengirim membangun koneksi TCP di port 25 ke MTA penerima. Port 25 dicadangkan untuk komunikasi server-ke-server dan biasanya diblokir oleh ISP untuk koneksi residensial guna mencegah spam yang berasal dari rentang IP konsumen.

Dalam lingkungan enterprise dan cloud, email dapat melewati beberapa hop relay sebelum mencapai tujuannya. Setiap relay menambahkan header `Received:` ke pesan, menciptakan jejak audit yang dapat dilacak. Memeriksa header ini adalah metode utama untuk mendiagnosis keterlambatan pengiriman dan mengidentifikasi di mana pesan ditahan atau ditolak.

Enkripsi oportunistik STARTTLS dinegosiasikan pada tahap ini jika kedua server mendukungnya. Jika server penerima tidak mengiklankan STARTTLS, sebagian besar MTA akan beralih ke transmisi tidak terenkripsi daripada gagal pengiriman — kelemahan keamanan yang diketahui yang dirancang untuk diatasi oleh MTA-STS (Mail Transfer Agent Strict Transport Security) dengan memberlakukan koneksi terenkripsi.

Langkah 5: Penerimaan, Pemfilteran, dan Evaluasi Spam

Ketika MTA penerima menerima pesan, ia tidak langsung menempatkannya di kotak masuk pengguna. Serangkaian pemeriksaan terjadi:

• SPF (Sender Policy Framework): Server penerima melakukan kueri DNS domain pengirim untuk TXT record yang mencantumkan alamat IP pengiriman yang diotorisasi. Jika IP pengirim tidak terdaftar, pemeriksaan SPF gagal.
• DKIM (DomainKeys Identified Mail): Server pengirim menandatangani header pesan dan isi secara kriptografis dengan kunci privat. Server penerima mengambil kunci publik yang sesuai dari DNS dan memverifikasi tanda tangan. Tanda tangan DKIM yang valid membuktikan pesan tidak diubah dalam perjalanan.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Menghubungkan SPF dan DKIM bersama-sama. Pemilik domain menerbitkan kebijakan DMARC yang menentukan apa yang harus dilakukan dengan pesan yang gagal autentikasi — `none` (hanya pantau), `quarantine` (kirim ke spam), atau `reject` (buang pesan). DMARC juga memungkinkan pelaporan agregat dan forensik.

Setelah pemeriksaan autentikasi, pesan melewati mesin pemfilteran konten dan penilaian spam (SpamAssassin, Rspamd, atau sistem proprietary). Skor ditetapkan berdasarkan anomali header, pencarian daftar hitam (RBL/DNSBL), pola konten, dan reputasi pengirim. Pesan yang melebihi ambang batas diarahkan ke folder sampah atau ditolak sepenuhnya.

Langkah 6: Penyimpanan dan Pengambilan Kotak Surat

Pesan yang lolos semua filter diserahkan ke MDA, yang menulisnya ke kotak surat pengguna. Dua format penyimpanan yang dominan adalah:

• Maildir: Setiap pesan disimpan sebagai file individual dalam struktur direktori. Lebih disukai karena ketahanannya — pesan yang rusak tidak mempengaruhi yang lain.
• mbox: Semua pesan dalam folder digabungkan menjadi satu file. Lebih sederhana tetapi rentan terhadap kerusakan dan masalah penguncian di bawah akses bersamaan.

Klien email penerima kemudian mengambil pesan menggunakan IMAP atau POP3.

Langkah 7: Pengambilan Klien melalui IMAP atau POP3

Tahap akhir pengiriman adalah klien yang menarik pesan dari server kotak surat. Pilihan protokol memiliki implikasi operasional yang signifikan.

Perbandingan Protokol IMAP vs. POP3 vs. SMTP

IMAP adalah pilihan yang tepat untuk hampir semua penerapan modern. Ini menyimpan pesan di server, menyinkronkan status baca/belum dibaca, struktur folder, dan tanda di setiap perangkat yang terhubung secara real time. Menghapus pesan di ponsel langsung tercermin di klien desktop.

POP3 mengunduh pesan ke perangkat lokal dan, secara default, menghapusnya dari server. Ini masuk akal di era akses perangkat tunggal dan penyimpanan server yang terbatas, tetapi menciptakan masalah serius di lingkungan multi-perangkat dan menghilangkan cadangan sisi server. POP3 harus dianggap sebagai protokol lama untuk penerapan baru.

Arsitektur Keamanan Email: SPF, DKIM, dan DMARC secara Mendalam

Ketiga mekanisme ini membentuk tumpukan autentikasi berlapis. Menerapkan hanya satu atau dua di antaranya meninggalkan celah yang dapat dieksploitasi.

SPF — Otorisasi Tingkat Amplop

SPF memvalidasi pengirim amplop (alamat `MAIL FROM` yang digunakan dalam dialog SMTP, bukan header `From:` yang terlihat oleh pengguna). Record SPF yang khas terlihat seperti:

“`

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all

“`

`~all` softfail memungkinkan pesan dari IP yang tidak terdaftar untuk diterima tetapi ditandai. `-all` hardfail menginstruksikan server penerima untuk menolaknya sepenuhnya. SPF saja tidak melindungi header `From:` yang terlihat, yang sebenarnya dilihat pengguna — inilah mengapa DMARC diperlukan.

DKIM — Integritas Pesan Kriptografis

DKIM menandatangani sekumpulan header yang ditentukan (biasanya `From`, `To`, `Subject`, `Date`) dan hash dari isi pesan. Tanda tangan disematkan dalam header `DKIM-Signature:`. Selektor dan domain dalam header tersebut menunjuk ke TXT record DNS yang berisi kunci publik. Jika pesan dimodifikasi setelah penandatanganan — bahkan satu karakter dalam isi — verifikasi tanda tangan gagal.

Catatan operasional penting: Perangkat lunak mailing list dan beberapa konfigurasi penerusan memodifikasi konten pesan (menambahkan footer, menulis ulang header), yang merusak tanda tangan DKIM. Ini adalah interaksi yang diketahui antara DKIM dan manajer mailing list yang memerlukan konfigurasi yang cermat.

DMARC — Penegakan Kebijakan dan Keselarasan

DMARC memperkenalkan konsep keselarasan pengidentifikasi: domain dalam header `From:` harus selaras dengan domain yang diautentikasi SPF atau domain penandatanganan DKIM. Ini menutup celah yang ditinggalkan SPF saja. Kebijakan `reject` adalah konfigurasi terkuat:

“`

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:forensic@example.com; adkim=s; aspf=s

“`

`adkim=s` dan `aspf=s` memberlakukan keselarasan ketat, memerlukan kecocokan domain yang tepat daripada pencocokan domain organisasi.

Topik Lanjutan: MTA-STS, DANE, dan ARC

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS memungkinkan domain untuk menerbitkan kebijakan melalui HTTPS yang menyatakan bahwa koneksi masuk harus menggunakan TLS dan menentukan sertifikat mana yang dapat diterima. Tidak seperti STARTTLS, yang bersifat oportunistik dan dapat dilucuti oleh penyerang man-in-the-middle, MTA-STS memberlakukan enkripsi. MTA pengirim yang mendukung MTA-STS menyimpan kebijakan dalam cache dan menolak untuk mengirim ke server yang tidak dapat memenuhinya.

DANE (DNS-Based Authentication of Named Entities)

DANE menggunakan TLSA records yang ditandatangani DNSSEC untuk mengikat sertifikat TLS tertentu atau kunci publik ke hostname server mail. Ini menghilangkan ketergantungan pada model kepercayaan Certificate Authority komersial untuk autentikasi server. Adopsi DANE berkembang di sektor pemerintah dan keuangan Eropa tetapi tetap terbatas dalam penerapan arus utama karena prasyarat DNSSEC pada domain pengirim dan penerima.

ARC (Authenticated Received Chain)

ARC dikembangkan untuk memecahkan masalah penerusan yang merusak DMARC. Ketika pesan diteruskan melalui perantara (seperti mailing list atau alias email), keselarasan SPF dan DKIM asli mungkin rusak. ARC mempertahankan rantai header `Received:` yang diautentikasi, memungkinkan server penerima akhir untuk mengevaluasi status autentikasi di setiap hop dan membuat keputusan pengiriman yang lebih tepat.

Kegagalan Pengiriman Email yang Umum dan Diagnosis

Memahami arsitektur membuat pemecahan masalah menjadi sistematis daripada spekulatif.

Gejala: Email terpental dengan “550 5.7.1 Message rejected”

• Penyebab: SPF hardfail, penolakan DMARC, atau pemblokiran IP.
• Diagnosis: Periksa pesan pentalan untuk alasan penolakan spesifik. Jalankan `dig TXT yourdomain.com` untuk memeriksa SPF. Kueri MX Toolbox atau sejenisnya untuk status daftar hitam.

Gejala: Email terkirim ke folder spam

• Penyebab: SPF softfail, DKIM hilang, reputasi pengirim rendah, atau pemicu konten.
• Diagnosis: Periksa header `X-Spam-Status` dalam pesan yang diterima. Verifikasi penandatanganan DKIM aktif. Periksa bahwa PTR (reverse DNS) record untuk IP pengirim cocok dengan hostname SMTP EHLO.

Gejala: Email tertunda dengan “451 Temporary failure”

• Penyebab: Server penerima sementara tidak tersedia atau membatasi kecepatan pengirim.
• Diagnosis: MTA pengirim akan mengantrekan dan mencoba ulang secara otomatis sesuai jadwal percobaan ulangnya. Periksa log MTA untuk antrian percobaan ulang. Kesalahan 451 yang persisten dari penyedia besar sering mengindikasikan masalah reputasi IP.

Gejala: Tanda tangan DKIM gagal meskipun record DNS benar

• Penyebab: Pesan dimodifikasi dalam perjalanan (footer mailing list ditambahkan, header ditulis ulang oleh relay).
• Diagnosis: Gunakan alat verifikasi DKIM pada sumber pesan mentah. Periksa apakah tag `h=` dalam header DKIM-Signature menyertakan header yang dimodifikasi.

Arsitektur Email untuk Lingkungan Hosted

Bagi bisnis dan pengembang yang menerapkan infrastruktur mail mereka sendiri, lingkungan hosting secara langsung mempengaruhi kemampuan pengiriman dan keamanan. Lingkungan VPS Hosting memberikan kontrol penuh atas konfigurasi MTA, PTR records, dan reputasi IP — faktor-faktor yang tidak dapat disediakan oleh lingkungan shared. Menjalankan Postfix atau Exim di VPS memungkinkan penyetelan tepat batas kecepatan, kebijakan TLS, dan mekanisme autentikasi.

Organisasi yang memerlukan email transaksional volume tinggi atau isolasi lengkap dari penyewa tetangga mendapat manfaat dari Dedicated Servers, di mana IP pengirim ditetapkan secara eksklusif dan tidak dibagikan dengan pelanggan lain. Reputasi IP di dedicated server sepenuhnya dalam kendali operator.

Untuk operasi yang lebih kecil yang tidak memerlukan MTA yang dikelola sendiri, Email Hosting menyediakan lingkungan mail yang sepenuhnya dikelola dengan SPF, DKIM, dan DMARC yang telah dikonfigurasi sebelumnya, menghilangkan beban operasional pemeliharaan perangkat lunak server mail.

Mengamankan koneksi webmail dan klien mail memerlukan sertifikat TLS yang valid. Sertifikat yang ditandatangani sendiri menghasilkan peringatan klien dan dapat menyebabkan kegagalan autentikasi dalam konfigurasi MUA yang ketat. Menerapkan SSL Certificates tepercaya pada hostname server mail (misalnya, `mail.yourdomain.com`) adalah dasar yang tidak dapat dinegosiasikan untuk lingkungan mail produksi mana pun.

Konfigurasi domain sama-sama mendasar. MX records, SPF TXT records, DKIM TXT records, dan DMARC TXT records semuanya berada di DNS. Manajemen DNS yang akurat dan andal melalui penyedia Domain Registration dengan editor DNS yang tangguh sangat penting untuk mempertahankan routing mail yang benar dan record autentikasi.

Analisis Header Email: Membaca Jejak Audit

Setiap email membawa sekumpulan header yang mendokumentasikan perjalanan lengkapnya. Ini ditambahkan dalam urutan kronologis terbalik — header `Received:` paling atas adalah hop terbaru. Rantai header yang khas terlihat seperti:

“`

Received: from mail.example.com (mail.example.com [203.0.113.10])

by mx.google.com with ESMTPS id …

for <recipient@gmail.com>; Mon, 10 Jun 2024 09:15:32 -0700

Received: from [192.168.1.5] (dynamic-pool.isp.net [98.76.54.32])

by mail.example.com with ESMTPSA id …

for <recipient@gmail.com>; Mon, 10 Jun 2024 09:15:29 -0700

“`

Header utama untuk diagnostik:

• `Return-Path:` — Alamat pengirim amplop yang digunakan untuk notifikasi pentalan. Harus selaras dengan SPF.
• `Authentication-Results:` — Ditambahkan oleh server penerima, mendokumentasikan hasil pemeriksaan SPF, DKIM, dan DMARC.
• `X-Originating-IP:` — Sering ditambahkan oleh layanan webmail untuk mencatat alamat IP klien.
• `Message-ID:` — Pengidentifikasi unik global yang ditetapkan oleh MTA asal. Digunakan untuk mengkorelasikan entri log di seluruh server.
• `MIME-Version:` dan `Content-Type:` — Mendefinisikan struktur MIME dari isi pesan.

Matriks Keputusan Teknis dan Poin-poin Utama

Gunakan daftar periksa ini saat mengonfigurasi atau mengaudit lingkungan mail:

DNS dan Routing

• MX records diterbitkan dengan nilai prioritas yang benar dan menunjuk ke hostname yang valid, bukan CNAME
• A/AAAA records untuk hostname MX di-resolve dengan benar
• PTR (reverse DNS) record untuk IP pengirim cocok dengan hostname SMTP EHLO

Tumpukan Autentikasi

• SPF TXT record diterbitkan dengan `-all` atau `~all` dan mencakup semua sumber pengiriman yang sah
• Kunci DKIM minimal 2048-bit; selektor diterbitkan di DNS dan penandatanganan aktif di MTA
• Kebijakan DMARC diterbitkan dengan minimal `p=quarantine`; pelaporan agregat (`rua`) dikonfigurasi
• Mode keselarasan DMARC diatur ke `s` (ketat) untuk domain keamanan tinggi

Keamanan Transport

• STARTTLS diaktifkan pada semua koneksi SMTP masuk dan keluar
• Kebijakan MTA-STS diterbitkan jika penegakan TLS yang ketat diperlukan
• Sertifikat TLS yang valid dan ditandatangani CA dipasang pada hostname server mail

Konfigurasi Penerimaan

• IMAP digunakan daripada POP3 untuk semua penerapan multi-perangkat
• IMAP melalui SSL/TLS di port 993 diberlakukan; port plaintext 143 dinonaktifkan atau dibatasi
• Pemfilteran spam sisi server (Rspamd atau SpamAssassin) dikonfigurasi dengan ruleset terkini

Pemantauan Operasional

• Laporan agregat DMARC ditinjau secara berkala untuk mendeteksi pengirim yang tidak sah
• Antrian MTA dipantau untuk pesan yang ditangguhkan yang mengindikasikan masalah pengiriman
• IP pengirim diperiksa terhadap RBL utama (Spamhaus ZEN, Barracuda, SORBS) secara terjadwal

FAQ

Apa perbedaan antara SMTP port 25, 465, dan 587?

Port 25 digunakan secara eksklusif untuk relay MTA server-ke-server dan diblokir oleh sebagian besar ISP untuk pengguna akhir. Port 587 adalah port pengiriman yang ditunjuk untuk koneksi klien-ke-server yang diautentikasi dan menggunakan STARTTLS untuk negosiasi enkripsi. Port 465 adalah port SMTPS lama yang membungkus seluruh sesi SMTP dalam SSL/TLS dari awal; sempat tidak digunakan tetapi kini secara resmi ditetapkan kembali untuk pengiriman terautentikasi dengan TLS implisit berdasarkan RFC 8314.

Mengapa email saya lolos SPF tetapi tetap gagal DMARC?

DMARC memerlukan keselarasan pengidentifikasi antara domain yang diautentikasi dan domain header `From:`. SPF mengautentikasi pengirim amplop (`MAIL FROM`), yang dapat berbeda dari header `From:` yang terlihat. Jika domain-domain tersebut tidak selaras (di bawah mode keselarasan yang dikonfigurasi), DMARC gagal meskipun SPF lolos. Solusinya adalah memastikan domain header `From:` cocok dengan domain yang diautentikasi SPF, atau mengonfigurasi penandatanganan DKIM dengan domain `From:` sehingga keselarasan DKIM memenuhi DMARC sebagai gantinya.

Apa yang menyebabkan tanda tangan DKIM yang valid gagal verifikasi di server penerima?

Penyebab paling umum adalah: isi pesan atau header yang ditandatangani dimodifikasi dalam perjalanan (footer mailing list, penulisan ulang header oleh relay); TXT record DNS untuk selektor DKIM dihapus atau diubah setelah penandatanganan; atau kunci publik di DNS tidak cocok dengan kunci privat yang digunakan untuk menandatangani pesan. Selalu verifikasi menggunakan sumber pesan mentah, bukan salinan yang diteruskan.

Apa perbedaan praktis antara IMAP dan POP3 untuk lingkungan bisnis?

IMAP menyinkronkan status kotak surat penuh — tanda baca/belum dibaca, struktur folder, item terkirim, draf — di setiap perangkat secara real time, dengan pesan yang tetap di server. POP3 mengunduh pesan ke satu perangkat dan menghapusnya dari server secara default, sehingga tidak mungkin mengakses pesan tersebut dari perangkat kedua. Untuk bisnis mana pun dengan karyawan yang mengakses email di lebih dari satu perangkat, POP3 menciptakan silo data dan menghilangkan retensi pesan sisi server. IMAP adalah satu-satunya pilihan yang tepat.

Bagaimana cara mendiagnosis mengapa email yang sah terkirim ke folder spam?

Ambil sumber pesan mentah dari folder spam dan periksa header `Authentication-Results:` untuk memeriksa hasil SPF, DKIM, dan DMARC. Cari header `X-Spam-Status:` atau `X-Spam-Score:` yang ditambahkan oleh filter server penerima untuk mengidentifikasi aturan mana yang terpicu. Verifikasi bahwa IP pengirim memiliki PTR record yang cocok, tidak terdaftar di RBL mana pun, dan bahwa domain pengirim memiliki tumpukan autentikasi yang lengkap. Tanda tangan DKIM yang hilang atau gagal dikombinasikan dengan hasil SPF netral adalah penyebab paling umum mail yang sah dinilai sebagai spam.