SMTP menjawab persoalan transport: server mana yang menerima sebuah pesan dan meneruskannya menuju tujuan? SMTP sendiri tidak membuktikan bahwa alamat yang tampil pada header From: memang dimiliki oleh sistem yang membuka koneksi SMTP.

Perbedaan ini menjelaskan situasi yang sering membingungkan. Mail client dapat terhubung ke layanan SMTP eksternal, berhasil melakukan autentikasi, lalu menyerahkan pesan yang valid secara sintaksis dengan From: user@gmail.com. Login SMTP membuktikan bahwa client diizinkan memakai layanan tersebut. Login itu tidak memberikan kewenangan atas domain gmail.com kepada layanan SMTP.

Sistem email modern memisahkan transport pesan, identitas penulis yang terlihat, dan autentikasi domain. SPF, DKIM, dan DMARC menghubungkan lapisan-lapisan tersebut agar server penerima dapat menentukan apakah identitas pengirim memang berwenang.

SMTP memiliki envelope dan message

Transaksi SMTP membawa envelope yang membungkus message:

MAIL FROM:<bounce@example.com>
RCPT TO:<recipient@example.net>

From: Alice <alice@example.com>
To: recipient@example.net
Subject: Example

MAIL FROM merupakan bagian dari SMTP envelope. Nilai ini digunakan untuk status pengiriman dan lazim disebut envelope sender atau return path. Sementara itu, field From: merupakan bagian dari format message RFC 5322 dan menunjukkan penulis yang ditampilkan kepada penerima.

Kedua alamat tersebut secara sah dapat berbeda. Mailing list, platform transactional email, sistem forwarding, dan infrastruktur pemrosesan bounce sering membutuhkan pemisahan itu.

Pemisahan tersebut juga berarti bahwa mengganti From: bukan bukti identitas. Client dapat membuat header berisi hampir semua mailbox yang valid secara sintaksis. Otorisasi diperiksa melalui mekanisme lain.

SMTP authentication mengautentikasi akun ke relay

Submission server umumnya meminta kredensial sebelum menerima email:

client
  |
  | SMTP AUTH + TLS
  v
submission server
  |
  | SMTP relay
  v
recipient MX

SMTP AUTH yang berhasil berarti submission server menerima kredensial berdasarkan kebijakannya sendiri. Kebijakan layanan dapat membatasi alamat From: yang boleh dipakai akun tersebut, tetapi pembatasan itu merupakan fitur layanan, bukan sifat umum SMTP.

Karena itu, username SMTP dan alamat pengirim yang terlihat tidak boleh dianggap sebagai identitas yang sama.

Provider seperti Resend dapat memberi izin kepada pelanggan untuk mengirim atas nama domain yang sudah diverifikasi. Kewenangan tersebut tidak otomatis mencakup domain lain seperti gmail.com, karena pelanggan tidak dapat memublikasikan record autentikasi yang diperlukan pada domain milik Google.

SPF mengautentikasi domain envelope

SPF memublikasikan kebijakan DNS yang menjelaskan sistem mana yang boleh mengirim email untuk sebuah domain. Dalam pemrosesan SMTP normal, SPF diperiksa terhadap domain yang terkait dengan envelope sender, bukan sekadar header From: yang terlihat.

Alurnya dapat disederhanakan menjadi:

MAIL FROM:<bounce@mailer.example.com>
              |
              v
      SPF policy for mailer.example.com
              |
              v
       sending IP authorized?

SPF yang lulus tidak otomatis membuktikan bahwa domain penulis lain yang terlihat juga berwenang.

Sebagai contoh, layanan pihak ketiga dapat lulus SPF menggunakan bounce domain miliknya sendiri sementara message menampilkan domain berbeda pada From:. Salah satu fungsi DMARC adalah mewajibkan hubungan yang bermakna antara domain yang berhasil diautentikasi dan domain penulis yang terlihat.

DKIM mengautentikasi domain penanda tangan

DKIM menambahkan signature kriptografis pada header tertentu dan isi message. DKIM signature menyatakan signing domain melalui parameter d=:

DKIM-Signature: ...; d=example.com; s=selector1; ...

Server penerima mengambil public key dari DNS lalu memverifikasi signature. Signature yang valid menunjukkan bahwa pemegang private key terkait menandatangani message untuk domain DKIM tersebut dan bagian message yang ditandatangani tetap lolos verifikasi.

Mail provider dapat menandatangani email untuk verified domain milik pelanggan karena pelanggan mendelegasikan record DNS DKIM yang diperlukan. Provider tidak dapat secara mandiri membuat identitas DKIM gmail.com yang aligned karena namespace DNS tersebut dikendalikan Google.

DMARC menghubungkan autentikasi dengan domain From yang terlihat

DMARC memeriksa domain pada field RFC 5322 From: lalu menentukan apakah domain tersebut aligned dengan domain SPF atau DKIM yang sudah terautentikasi.

Secara konseptual:

                    visible From domain
                           example.com
                               |
                  +------------+------------+
                  |                         |
                  v                         v
        SPF-authenticated domain   DKIM signing domain
                  |                         |
                  +------------+------------+
                               |
                         DMARC alignment

Lulus SPF di suatu titik pada jalur pengiriman belum cukup jika identitas SPF tidak terkait dengan domain From: yang terlihat. Demikian pula, DKIM signature yang valid dari domain provider lain tidak dengan sendirinya membentuk alignment dengan domain penulis.

Untuk email langsung ke akun Gmail pribadi, panduan pengirim Google mewajibkan organizational domain pada header From: yang terlihat agar aligned dengan organizational domain SPF atau DKIM bagi bulk sender. Google juga secara eksplisit memperingatkan pengirim agar tidak meniru header From: Gmail.

SMTP eksternal tidak memperoleh kewenangan atas gmail.com

Misalkan client menyerahkan message berikut melalui provider SMTP eksternal:

SMTP server: smtp.provider.example
Authenticated account: customer-account
From: Person <person@gmail.com>
To: recipient@example.net

Provider eksternal tersebut mungkin mampu mengangkut message tanpa masalah. Persoalan identitas muncul pada tahap berikutnya.

Provider biasanya dapat mengautentikasi domain yang dikendalikannya atau domain pelanggan yang sudah didelegasikan kepadanya. Provider tidak dapat menambahkan dirinya sendiri ke kebijakan SPF gmail.com, memublikasikan DKIM public key di DNS milik Google, atau mengubah kebijakan DMARC Google.

Akibatnya, message dapat valid sebagai email SMTP secara sintaksis tetapi tetap gagal memenuhi autentikasi atau alignment yang diharapkan untuk identitas Gmail yang terlihat.

Ini adalah batas kewenangan DNS, bukan keterbatasan Linux mail client, Thunderbird, swaks, atau tool SMTP tertentu.

Custom domain mengubah batas kewenangan

Kondisinya berbeda untuk domain yang Anda kendalikan:

From: alerts@example.com
SMTP provider: external service

example.com DNS
  |
  +-- SPF authorization
  +-- DKIM public key
  +-- DMARC policy

Pemilik domain dapat mengotorisasi provider melalui record DNS yang diminta provider tersebut. Layanan kemudian dapat mengirim email dengan authentication identity yang aligned dengan example.com.

Ini merupakan arsitektur normal untuk layanan transactional email. Aplikasi tidak perlu menjalankan mail transfer agent yang menghadap internet sendiri, tetapi pemilik domain tetap memegang kendali atas layanan mana yang boleh mewakili domain tersebut.

Gmail sebagai client berbeda dari Gmail sebagai identitas

Web interface Gmail atau desktop mail client berada pada application layer. SMTP merupakan mekanisme transport. Alamat pada From: adalah identitas yang disajikan di dalam message.

Ketiga peran tersebut perlu dipisahkan:

mail client / UI
      |
      v
SMTP submission service
      |
      v
SPF / DKIM authentication
      |
      v
DMARC alignment with From:
      |
      v
receiving mail system

Menulis email melalui Gmail tidak otomatis mengizinkan setiap provider SMTP eksternal untuk mewakili gmail.com. Sebaliknya, memakai provider SMTP eksternal merupakan pola normal jika pengirim yang terlihat menggunakan domain yang sudah dikonfigurasi untuk mengotorisasi provider tersebut.

Pengujian dari Linux memperlihatkan setiap lapisan

Tool seperti swaks berguna karena memperlihatkan transaksi SMTP tanpa menyembunyikannya di balik full mail client:

swaks \
  --server smtp.example.com \
  --port 587 \
  --tls \
  --auth LOGIN \
  --auth-user user@example.com \
  --auth-password 'APP_PASSWORD' \
  --from sender@example.com \
  --to recipient@example.net

Perintah tersebut dapat memastikan bahwa negosiasi TLS, SMTP authentication, pengiriman envelope, dan penerimaan oleh relay berjalan. Namun, perintah itu sendiri tidak membuktikan bahwa SPF, DKIM, dan DMARC akan lulus di sisi penerima.

Bukti tersebut tersedia setelah pengiriman melalui authentication result yang ditambahkan infrastruktur penerima, biasanya berupa Authentication-Results: dengan hasil SPF, DKIM, dan DMARC.

Keberhasilan transport dan keberhasilan identitas adalah dua hasil berbeda

Respons 250 OK setelah message diserahkan berarti server menerima tanggung jawab atas message pada tahap SMTP tersebut. Respons itu bukan sertifikat universal bahwa identitas pengirim yang terlihat autentik atau bahwa setiap server berikutnya akan menerima message.

Model yang lebih tepat memisahkan dua pertanyaan:

Can this SMTP server transport the message?
                |
                v
        SMTP acceptance

Is the visible From domain authorized?
                |
                v
      SPF / DKIM / DMARC

Untuk alamat pada domain yang Anda kendalikan, provider SMTP eksternal dapat diberi kewenangan melalui DNS dan menghasilkan autentikasi yang aligned. Untuk identitas @gmail.com, kewenangan tersebut tetap berada pada infrastruktur domain Google. Mengganti SMTP relay tidak memindahkan kendali atas sender domain.

SMTP Email SPF DKIM DMARC