Cara Mengatasi Error Gmail 550 5.7.26 Unauthenticated

Email reset password, invoice, atau notifikasi form kontak sudah Anda kirim, lalu beberapa detik kemudian muncul bounce: 550 5.7.26 This mail is unauthenticated. Atau versi lainnya: 550-5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy. Artinya jelas: Gmail menolak email tersebut mentah-mentah. Bukan masuk folder spam, tapi benar-benar tidak sampai.

Kabar baiknya, error ini hampir selalu berakar pada DNS dan konfigurasi server pengirim, bukan isi email. Jadi bisa diperbaiki secara sistematis. Di artikel ini kita bahas arti error-nya, cara melacak bagian mana yang rusak, dan record DNS apa saja yang perlu Anda pasang.

Apa arti error 550 5.7.26?

Kode 5.7.26 dipakai Gmail ketika email tidak bisa diautentikasi. Dokumentasi resmi Google mencantumkan beberapa varian pesan, dan redaksinya pun berubah dari waktu ke waktu, tapi semuanya bermuara pada tiga mekanisme:

• SPF (RFC 7208): memeriksa apakah IP server yang mengirim email memang diizinkan oleh domain pada envelope sender (MAIL FROM atau Return-Path).
• DKIM (RFC 6376): memverifikasi tanda tangan kriptografis di header email dengan public key yang dipublikasikan di DNS.
• DMARC (RFC 7489): menyatukan keduanya. DMARC lolos hanya jika SPF atau DKIM lolos dan domain yang terautentikasi selaras (aligned) dengan domain di header From:. Kebijakan DMARC (p=none, quarantine, atau reject) menentukan apa yang dilakukan penerima saat gagal.

Pemetaan varian pesan ke penyebabnya kira-kira seperti ini:

• "This mail is unauthenticated" / "the sender is unauthenticated": SPF maupun DKIM sama-sama tidak lolos. Pedoman pengirim Google mewajibkan semua pengirim memakai minimal SPF atau DKIM, sedangkan pengirim massal (sekitar 5.000 email atau lebih per hari ke akun Gmail) wajib memakai keduanya plus DMARC.
• "Unauthenticated email from domain is not accepted due to domain's DMARC policy": DMARC gagal dan domain From memasang kebijakan ketat seperti p=reject. Bisa jadi SPF atau DKIM sebenarnya lolos, tapi untuk domain yang tidak selaras dengan alamat From.
• Varian SPF hard fail: record SPF domain pengirim diakhiri -all, sementara IP pengirim tidak terdaftar.

Kalau yang muncul 421 4.7.26 atau 451 4.7.26, itu versi sementaranya: Gmail membatasi laju (rate limit) email yang tidak terautentikasi atau mengalami gangguan DNS sementara. Cara memperbaikinya sama, hanya saja belum berubah menjadi penolakan permanen.

Diagnosis langkah demi langkah

1. Baca isi bounce secara lengkap

Jangan cuma membaca baris pertama. Buka laporan gagal kirim (NDR) dan cari respons SMTP lengkap dari server Gmail. Di situ biasanya disebutkan domain mana yang gagal, dan sering kali bukan domain yang Anda kira. Catat tiga hal:

• Domain di header From: (yang dilihat penerima).
• Domain envelope sender / Return-Path (tujuan bounce).
• Server atau layanan yang benar-benar menyerahkan email ke Gmail (lihat header Received: atau "Reporting-MTA").

2. Periksa SPF

Cek record SPF untuk domain envelope sender lewat SPF Checker, atau langsung dari terminal:

dig +short TXT example.com | grep spf1

Yang perlu diperhatikan:

• Tidak ada record sama sekali. SPF jelas tidak mungkin lolos.
• Ada lebih dari satu record v=spf1. Menurut RFC 7208 ini dianggap error permanen, sehingga SPF praktis gagal. Kasus ini sangat sering terjadi: layanan baru menyuruh "tambahkan record SPF", lalu Anda membuat record baru alih-alih mengedit yang lama.
• Layanan pengirim tidak tercantum. Aplikasi mengirim lewat ESP, tapi record SPF hanya memuat server hosting.
• Terlalu banyak DNS lookup. Evaluasi SPF dibatasi maksimal 10 mekanisme yang memicu query DNS (include, a, mx, exists, redirect, dan sejenisnya). Lewat dari itu hasilnya error permanen.

3. Periksa DKIM

Key DKIM berada di selector._domainkey.example.com. Selector bisa Anda temukan di header DKIM-Signature: email yang terkirim (tag s=) atau di dashboard penyedia email. Masukkan domain dan selector ke DKIM Checker, atau jalankan:

dig +short TXT google._domainkey.example.com

Penyebab umum kegagalan: email tidak ditandatangani sama sekali, key belum dipublikasikan, key terpotong saat ditempel ke panel DNS, atau email ditandatangani dengan domain milik penyedia (misalnya d=sendgrid.net), bukan domain Anda. Kasus terakhir ini lolos DKIM, tapi tidak selaras untuk DMARC.

4. Periksa DMARC

Record DMARC berada di _dmarc.example.com. DMARC Checker akan menguraikan kebijakan, mode alignment, dan alamat laporan. Jika bounce menyebut "domain's DMARC policy", perhatikan nilai p=. Kebijakan p=reject hanya menjalankan tugasnya; yang perlu dicari adalah kenapa email sah Anda gagal alignment.

5. Cek keselarasan (alignment) dengan domain From

Langkah ini sering dilewati, padahal di sinilah masalahnya paling sering bersembunyi. DMARC mensyaratkan domain yang lolos SPF atau DKIM cocok dengan domain From::

• SPF alignment: domain Return-Path dibandingkan dengan domain From.
• DKIM alignment: domain d= pada tanda tangan dibandingkan dengan domain From.

Secara default DMARC memakai mode relaxed, jadi mail.example.com dianggap selaras dengan example.com. Mode strict (aspf=s atau adkim=s) menuntut kecocokan persis. Contoh kegagalan klasik: From Anda noreply@example.com, Return-Path bounces@esp-provider.net, dan DKIM bertanda d=esp-provider.net. SPF dan DKIM sama-sama lolos, tapi untuk domain yang salah, sehingga DMARC gagal.

6. Kenali layanan pengirimnya

• Email shared hosting (cPanel, fungsi mail() PHP): IP server sering belum masuk SPF, dan DKIM kadang belum aktif atau menandatangani dengan hostname server. Cek menu Email Deliverability atau sejenisnya di panel hosting.
• ESP transaksional (SendGrid, Mailgun, Amazon SES, Postmark, Brevo, dan lainnya): Anda perlu menyelesaikan langkah "domain authentication" yang memberi record CNAME atau TXT untuk DKIM, dan sering juga subdomain Return-Path khusus. Sebelum itu selesai, email ditandatangani dengan domain mereka dan tidak akan selaras.
• Google Workspace: SPF wajib memuat include:_spf.google.com, dan DKIM harus dibuat di Admin console lalu diaktifkan secara manual setelah record dipublikasikan. Memasang record TXT saja belum membuat Gmail mulai menandatangani email.

Cara memperbaikinya

Gabungkan SPF menjadi satu record

Kalau Anda mengirim dari Google Workspace sekaligus ESP transaksional, jangan buat dua record. Gabungkan menjadi satu:

; Salah: dua record SPF terpisah
example.com.  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  TXT  "v=spf1 include:sendgrid.net ~all"

; Benar: satu record gabungan
example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Gunakan nilai include persis sesuai dokumentasi penyedia. Jika mendekati batas 10 lookup, buang dulu include layanan yang tidak terpakai sebelum mencoba "SPF flattening", yang menulis IP statis dan bisa basi.

Aktifkan DKIM lewat penyedia email

Key DKIM tidak perlu Anda buat manual; penyedia yang membuatkannya:

• Google Workspace: Admin console, lalu Apps, Google Workspace, Gmail, Authenticate email. Buat key (2048-bit jika DNS Anda mendukung), pasang record TXT di selector yang ditampilkan (default-nya google._domainkey), tunggu propagasi DNS, lalu klik Start authentication.
• ESP: ikuti wizard domain authentication. Umumnya Anda akan mendapat record CNAME seperti di bawah, yang mengarah ke key yang dirotasi oleh penyedia:

s1._domainkey.example.com.  CNAME  s1.domainkey.u1234.wl.sendgrid.net.

(Hostname di atas hanya ilustrasi. Salin nilai persisnya dari dashboard Anda sendiri.)

• Shared hosting: aktifkan DKIM di menu deliverability, lalu jika DNS Anda dikelola di tempat lain (misalnya Cloudflare), salin record TXT yang dihasilkan ke sana.

Pasang record DMARC awal

Kalau belum punya DMARC, mulai dari mode pemantauan agar Anda bisa melihat siapa saja yang mengirim atas nama domain Anda tanpa memblokir apa pun:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Record ini bisa dibuat dengan DMARC Generator. Setelah laporan agregat menunjukkan semua sumber sah sudah lolos dan selaras, naikkan ke p=quarantine, lalu p=reject. Jika saat ini Anda sudah memakai p=reject dan email sah ikut terpental, Anda bisa turunkan sementara ke p=none atau p=quarantine selama memperbaiki alignment. Anggap itu solusi darurat, bukan perbaikan akhir.

Catatan soal forwarding dan mailing list

Sebagian bounce 5.7.26 bukan murni kesalahan konfigurasi Anda. Saat email di-forward (misalnya alias kampus yang meneruskan ke Gmail), IP server penerus tidak ada di SPF Anda, sehingga SPF gagal. DKIM biasanya tetap utuh selama isi email tidak diubah. Inilah alasan kuat untuk selalu memakai DKIM, bukan hanya SPF.

Mailing list lebih rumit karena sering menambahkan tag di subjek atau footer, yang merusak tanda tangan DKIM. Software mailing list modern mengatasinya dengan menulis ulang header From ke domain list atau menambahkan header ARC (Authenticated Received Chain). Kalau email Anda hanya terpental saat lewat list atau forwarder tertentu, perbaikannya ada di sisi pengelola layanan tersebut.

Verifikasi setelah perbaikan

Perubahan DNS butuh waktu untuk menyebar tergantung nilai TTL. Tunggu sebentar, lalu cek ulang dengan SPF, DKIM, dan DMARC Checker. Setelah itu kirim email uji ke akun Gmail milik Anda, buka emailnya, klik menu titik tiga, dan pilih Show original (Tampilkan versi asli). Di bagian atas, Gmail menampilkan ringkasan seperti ini:

SPF:   PASS with IP 203.0.113.10
DKIM:  'PASS' with domain example.com
DMARC: 'PASS'

Ketiganya harus PASS, dan domain DKIM harus domain Anda (atau subdomainnya), bukan domain penyedia. Ulangi pengujian untuk setiap sistem yang mengirim atas nama domain Anda: aplikasi, tool newsletter, help desk, hingga software invoice.

Checklist singkat

1. Baca bounce lengkap; catat domain From, domain Return-Path, dan server pengirim.
2. Pastikan hanya ada satu record SPF dan semua layanan pengirim tercantum.
3. Jaga SPF di bawah 10 DNS lookup.
4. Aktifkan DKIM dengan domain sendiri di setiap penyedia.
5. Pasang DMARC, mulai dari p=none plus alamat laporan.
6. Pastikan SPF atau DKIM selaras dengan domain From.
7. Kirim email uji ke Gmail dan pastikan SPF, DKIM, DMARC berstatus PASS di "Show original".
8. Perketat kebijakan DMARC bertahap setelah laporan bersih.

FAQ

Apakah wajib memakai SPF dan DKIM sekaligus?

Syarat minimum Google untuk semua pengirim adalah SPF atau DKIM, sedangkan pengirim massal wajib keduanya plus DMARC. Praktisnya, pasang keduanya. DKIM tetap bertahan saat email di-forward, sementara SPF tidak, dan dua mekanisme yang selaras memberi DMARC dua peluang untuk lolos.

SPF dan DKIM sudah PASS, kenapa DMARC masih gagal?

Hampir pasti masalah alignment. SPF dan DKIM lolos untuk domain penyedia email, bukan domain di header From Anda. Selesaikan custom domain authentication di penyedia agar DKIM ditandatangani dengan d=domainanda.com, atau atur Return-Path khusus di domain Anda.

Lebih baik pakai ~all atau -all?

Keduanya bisa dipakai selama DMARC sudah terpasang, karena keputusan akhirnya ada di DMARC. Banyak admin memilih ~all (softfail) agar email yang di-forward tidak langsung ditolak hanya karena SPF, lalu mengandalkan DMARC untuk penegakan. Gunakan -all hanya jika Anda yakin semua pengirim sah sudah tercantum.

Berapa lama sampai bounce berhenti?

Tergantung TTL DNS dan seberapa cepat penyedia mendeteksi record baru. Begitu checker menampilkan record yang benar dan email uji menunjukkan PASS di "Show original", email baru seharusnya diterima. Email yang sudah terpental perlu dikirim ulang.

Bisakah diperbaiki dari sisi penerima?

Umumnya tidak. Penolakan terjadi saat percakapan SMTP, sebelum email masuk ke inbox siapa pun, jadi filter atau daftar kontak pengguna Gmail tidak bisa membatalkannya. Pemilik domain pengirim yang harus memperbaiki autentikasinya. Jika Anda penerima, teruskan teks bounce ke tim IT pengirim.