Panduan Mengatasi Gagal Kirim Email ke Yahoo karena MTU/MSS

Jika server Anda berada di jaringan kami dan mengalami kendala mengirim email ke Yahoo, sementara

dewabiz
dewabiz
01 Oktober 2026 8 menit baca
Panduan Mengatasi Gagal Kirim Email ke Yahoo karena MTU/MSS

Jika server Anda berada di jaringan kami dan mengalami kendala mengirim email ke Yahoo, sementara pengiriman ke Gmail berjalan normal, salah satu penyebab yang perlu diperiksa adalah MTU/MSS pada jalur jaringan.

Masalah ini dapat terjadi ketika trafik menuju server Anda melewati tunnel yang hanya mampu meneruskan paket hingga ukuran tertentu. Dalam kasus yang dibahas pada panduan ini, jalur hanya mampu melewatkan paket hingga 1476 byte.

Akibatnya, koneksi TCP tertentu dapat mengalami masalah, terutama ketika server mulai melakukan negosiasi TLS.

Solusinya adalah melakukan TCP MSS clamping, misalnya dengan menetapkan MSS sebesar 1400 byte.

Gejala

Server kemungkinan mengalami masalah MTU/MSS apabila beberapa kondisi berikut muncul secara bersamaan:

  • Email ke yahoo.com, ymail.com, atau aol.com tertahan di mail queue.
  • Pengiriman email ke Gmail atau tujuan lain berjalan normal.
  • Mail server mencatat timeout ketika menghubungi MX Yahoo.
  • Contoh error pada log:
Timed out, status = ETIMEDOUT while connecting ...
to mta7.am0.yahoodns.net
  • Koneksi ke port SMTP 25 berhasil dan server Yahoo memberikan banner 220.
  • Koneksi kemudian macet ketika proses masuk ke STARTTLS.
  • Tidak terdapat pesan bounce atau penolakan SMTP dari Yahoo.
  • SPF, DKIM, dan reputasi IP terlihat normal.

Kondisi tersebut penting dibedakan dari masalah reputasi IP.

Jika Yahoo menolak email dengan kode SMTP seperti 421, 450, 451, atau 550, penyebabnya belum tentu MTU/MSS.

Masalah MTU/MSS juga tidak terbatas pada email. Koneksi HTTPS atau layanan TCP lainnya dapat mengalami gejala serupa apabila trafik balik melewati tunnel dengan MTU yang lebih kecil.

Cara Memastikan Masalah MTU/MSS

Ada dua pengujian sederhana yang dapat dilakukan langsung dari server Linux.

Tes 1 — Menguji Ukuran Paket

Jalankan sebagai root:

ping -c 2 -M do -s 1448 67.195.228.109
ping -c 2 -M do -s 1449 67.195.228.109

Parameter -M do meminta Linux mengirim paket tanpa melakukan fragmentasi.

Ukuran -s adalah ukuran payload ICMP. Karena IPv4 menggunakan header IP 20 byte dan ICMP 8 byte, total paket menjadi:

1448 + 20 + 8 = 1476 byte

Jika:

1448  → berhasil
1449  → gagal

maka terdapat indikasi kuat bahwa jalur tersebut hanya mampu meneruskan paket sampai sekitar 1476 byte tanpa fragmentasi.

Ini merupakan indikasi adanya masalah MTU pada jalur jaringan.

Catatan: hasil ping dapat dipengaruhi oleh firewall atau kebijakan ICMP di sisi tujuan. Karena itu, tes ping sebaiknya digunakan bersama pengujian TCP/TLS berikutnya.


Tes 2 — Menguji STARTTLS SMTP

Selanjutnya, lakukan pengujian langsung ke SMTP Yahoo:

timeout 25 openssl s_client \
  -starttls smtp \
  -connect 67.195.228.109:25 \
  -brief </dev/null

Jika koneksi berhenti atau timeout setelah proses SMTP/TLS dimulai, lanjutkan dengan pembanding ke Gmail:

timeout 25 openssl s_client \
  -starttls smtp \
  -connect gmail-smtp-in.l.google.com:25 \
  -brief </dev/null

Pada koneksi yang berhasil, Anda akan melihat informasi TLS, misalnya:

Protocol version: TLSv1.3

Jika koneksi ke Gmail berhasil tetapi koneksi ke tujuan Yahoo mengalami timeout, sementara tes ukuran paket juga menunjukkan batas sekitar 1476 byte, diagnosis MTU/MSS menjadi semakin kuat.

Jika kedua pengujian berjalan normal, kemungkinan penyebab masalah pengiriman email berada di area lain dan panduan ini mungkin tidak relevan.

Solusi: TCP MSS Clamping

Salah satu solusi praktis adalah membuat server mengiklankan MSS 1400 byte pada koneksi TCP.

Jalankan:

iptables -t mangle -A OUTPUT \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1400

Aturan tersebut memodifikasi MSS pada paket TCP SYN yang keluar dari server.

Tujuannya adalah memastikan koneksi TCP menggunakan ukuran segmentasi yang cukup kecil sehingga paket dapat melewati tunnel tanpa mengalami masalah fragmentasi atau packet drop akibat MTU.

Mengapa 1400?

Jika jalur memiliki MTU efektif sekitar 1476 byte, MSS TCP tidak boleh mendekati nilai tersebut karena masih terdapat header IP dan TCP.

Dengan MSS 1400:

MSS TCP       = 1400
TCP header    ≈ 20 byte
IP header     ≈ 20 byte
--------------------------------
Total         ≈ 1440 byte

Nilai tersebut memberikan margin terhadap MTU 1476 byte.

Apakah Koneksi yang Sedang Berjalan Terputus?

Tidak.

Aturan MSS hanya diterapkan pada koneksi TCP baru ketika paket SYN dibuat.

Koneksi TCP yang sudah berjalan tidak otomatis diputus oleh aturan tersebut.

Untuk memastikan aturan sudah aktif:

iptables -t mangle -S OUTPUT

Anda seharusnya melihat:

-A OUTPUT -p tcp -m tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --set-mss 1400

Membuat Konfigurasi Permanen

Aturan yang dibuat menggunakan iptables secara manual biasanya tidak bertahan setelah server reboot.

Cara membuatnya permanen tergantung sistem firewall yang digunakan.

Ubuntu/Debian dengan UFW

Backup terlebih dahulu:

cp /etc/ufw/before.rules /etc/ufw/before.rules.bak

Kemudian edit:

nano /etc/ufw/before.rules

Tambahkan bagian berikut sebelum *filter:

*mangle
:OUTPUT ACCEPT [0:0]
-A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400
COMMIT

Kemudian reload UFW:

ufw reload

Perhatian

Hindari menggunakan:

-F OUTPUT

secara sembarangan.

Perintah tersebut akan menghapus seluruh aturan pada chain OUTPUT di tabel mangle ketika chain tersebut dimuat ulang.

Jika server sudah memiliki aturan mangle lain, aturan tersebut dapat ikut terhapus.

Karena itu, lebih aman menggunakan:

-A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

tanpa -F OUTPUT, kecuali memang Anda memahami seluruh konfigurasi firewall server.

Debian/Ubuntu Tanpa UFW

Jika server tidak menggunakan UFW, salah satu cara yang umum adalah menggunakan iptables-persistent.

Install:

apt update
apt install iptables-persistent

Setelah aturan MSS dibuat:

iptables -t mangle -A OUTPUT \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1400

Simpan konfigurasi:

netfilter-persistent save

Kemudian periksa:

iptables -t mangle -S OUTPUT

Jika Tunnel Menggunakan IPv4-over-IPv6

Nilai MSS tidak selalu harus 1400.

Jika provider menginformasikan bahwa tunnel menggunakan IPv4-over-IPv6, overhead encapsulation dapat berbeda.

Dalam skenario tersebut, provider dapat merekomendasikan nilai MSS yang lebih kecil, misalnya:

1360

Contohnya:

iptables -t mangle -A OUTPUT \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1360

Sebaiknya nilai MSS disesuaikan dengan MTU aktual dan jenis tunnel yang digunakan.


Lebih Baik Memperbaiki MTU di Router

MSS clamping adalah workaround yang praktis, tetapi bukan berarti masalah MTU pada jaringan sudah diperbaiki.

Jika Anda mengelola router atau border network sendiri, solusi yang lebih terstruktur adalah melakukan MSS clamping di router.

Dengan demikian, seluruh server di belakang router dapat terlindungi tanpa perlu memasang aturan satu per satu.

Contohnya:

Internet
   │
   ▼
Border Router
   │
   │ MSS Clamp 1400
   ▼
Tunnel
   │
   ▼
Server Network
   │
   ├── Mail Server
   ├── Web Server
   ├── VPS
   └── Hosting Server

Pendekatan ini sangat berguna pada lingkungan hosting yang memiliki banyak server.

Namun, konfigurasi router harus disesuaikan dengan perangkat dan routing yang digunakan.


Verifikasi Setelah Perbaikan

Setelah MSS clamping diterapkan, lakukan beberapa pengujian.

1. Pastikan aturan aktif

iptables -t mangle -S OUTPUT

Pastikan terdapat:

TCPMSS --set-mss 1400

2. Ulangi pengujian SMTP TLS

timeout 25 openssl s_client \
  -starttls smtp \
  -connect 67.195.228.109:25 \
  -brief </dev/null

Jika berhasil, Anda seharusnya mendapatkan informasi TLS seperti:

Protocol version: TLSv1.3

3. Periksa mail queue

Untuk Postfix:

postqueue -p

Untuk Exim:

exim -bp

Perhatikan apakah email menuju Yahoo mulai berhasil dikirim.

Anda juga dapat memantau log mail server untuk melihat respons SMTP seperti:

250 OK

Mail server biasanya akan melakukan retry secara otomatis sehingga tidak selalu diperlukan pengiriman ulang manual.


Mengapa Tes Ping Masih Gagal Setelah Perbaikan?

Ini normal.

Setelah MSS clamping diterapkan, pengujian:

ping -c 2 -M do -s 1449 67.195.228.109

tetap dapat gagal.

Alasannya adalah MSS clamping tidak memperbaiki MTU jalur jaringan.

MSS clamping hanya memberi tahu endpoint TCP agar menggunakan segment TCP yang lebih kecil.

Dengan kata lain:

MTU tunnel tetap bermasalah
        ↓
TCP MSS dibuat lebih kecil
        ↓
TCP menggunakan paket lebih kecil
        ↓
Koneksi TCP dapat melewati tunnel

Sedangkan ICMP ping tidak menggunakan mekanisme MSS.

Cara Membatalkan Konfigurasi

Jika ingin menghapus aturan:

iptables -t mangle -D OUTPUT \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1400

Kemudian pastikan aturan sudah hilang:

iptables -t mangle -S OUTPUT

Jika konfigurasi dibuat melalui UFW, hapus konfigurasi MSS dari:

/etc/ufw/before.rules

Kemudian:

ufw reload

Jika menggunakan iptables-persistent, simpan kembali konfigurasi:

netfilter-persistent save

Hal yang Perlu Diperhatikan

TCP MSS clamping memiliki beberapa batasan.

1. Hanya berlaku untuk TCP

MSS merupakan bagian dari TCP sehingga aturan ini tidak memperbaiki masalah:

  • UDP
  • ICMP
  • WireGuard/UDP
  • DNS melalui UDP
  • aplikasi lain yang menggunakan UDP dengan paket besar

Jika UDP juga mengalami packet loss karena MTU, masalah harus diperbaiki pada konfigurasi MTU tunnel atau jaringan.

2. MSS bukan pengganti perbaikan MTU

Jika Anda memiliki akses ke perangkat tunnel/provider, perbaikan MTU secara langsung tetap menjadi solusi yang lebih fundamental.

3. Jangan langsung menyimpulkan masalah Yahoo

Yahoo hanya menjadi salah satu tujuan yang memperlihatkan gejala.

Jika Gmail berhasil tetapi Yahoo gagal, bukan berarti Yahoo yang bermasalah.

Periksa terlebih dahulu:

  • MTU
  • MSS
  • PMTUD
  • firewall
  • routing
  • tunnel
  • packet loss
  • TCP retransmission

4. Jangan mengubah MSS terlalu kecil tanpa alasan

MSS yang terlalu kecil dapat meningkatkan jumlah packet yang harus dikirim sehingga menambah overhead jaringan.

Gunakan nilai yang sesuai dengan MTU aktual.

Kesimpulan

Jika server pada jaringan 103.153.3.0/24 mengalami kegagalan koneksi SMTP ke Yahoo, terutama ketika koneksi berhenti saat STARTTLS, lakukan pemeriksaan MTU terlebih dahulu.

Indikasi yang kuat adalah:

Packet 1448 byte  → berhasil
Packet 1449 byte  → gagal

dan:

SMTP port 25      → terhubung
STARTTLS          → timeout

Dalam kondisi tersebut, TCP MSS clamping dapat menjadi solusi praktis:

iptables -t mangle -A OUTPUT \
  -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1400

Untuk lingkungan hosting dengan banyak server, konfigurasi MSS clamping di router/border network dapat lebih efektif karena seluruh server di belakang router dapat menggunakan MSS yang sesuai.

Namun, apabila memungkinkan, perbaikan MTU pada tunnel atau jalur jaringan tetap merupakan solusi utama. MSS clamping sebaiknya dipandang sebagai mekanisme untuk memastikan trafik TCP tetap dapat berjalan ketika MTU path yang lebih kecil memang tidak dapat segera diperbaiki.

Bagikan
dewabiz
Ditulis oleh

dewabiz

Tim DewaBiz menulis panduan seputar domain, hosting, VPS, dan infrastruktur server berdasarkan pengalaman melayani ribuan pelanggan di Indonesia sejak 2016.

Hubungi tim kami
Artikel Terkait

Baca Juga Artikel Lainnya

Topik lain yang mungkin menarik untuk Anda.

Siap Praktikkan di Server Anda Sendiri?

VPS Super Compute dengan CPU dedicated dan SSD NVMe Enterprise — aktivasi instan dan support 24/7 dari tim DewaBiz.