E-posta Hata Kodları: SMTP'de 4xx ve 5xx için Tam Kılavuz

Gönderim kuyruğu günlüğünü açtınız ve takılı kalmış bir mesajın karşısında status=deferred yazıyor, kodu ise 451 4.3.0. Gerçek soru şu: bu mesajı yeniden mi göndereyim yoksa bırakayım mı? Cevap, kodun ilk rakamında. Bu rakamı yanlış okuduğunuz sürece her adımınız şansa bağlıdır.

E-posta hata kodu, karşı sunucunun SMTP komutuna yanıt olarak döndürdüğü üç haneli bir sayıdır. İlk rakam yanıt sınıfını belirler, hatanın şiddetini değil. 4xx "şu an yapamıyorum, sonra tekrar dene" demektir ve 5xx "asla kabul etmem" demektir. Bu fark, tüm operasyonel karar alma sürecinizi oluşturur.

Her şeyi belirleyen 4xx ve 5xx farkı

4xx hatası geçicidir. Gönderim kuyruğu (queue) mesajı tutar ve kendi zamanlamasına göre yeniden dener; Postfix'te bu aralık varsayılan olarak queue_run_delay ve maximal_queue_lifetime parametreleriyle kontrol edilir. Kuyruk ömrünün varsayılan değeri 5 gündür. Sorun o zamana kadar çözülmezse, mesaj bounced durumuyla geri döner ve gönderen bir geri dönüş mektubu alır.

5xx hatası kalıcıdır. Hedef sunucu kesin olarak reddetmiştir ve yeniden denemenin hiçbir faydası yoktur. Mesaj hemen bounce olur. Kendi günlüğünüzde 5xx görüp mesajı elle kuyruğa yeniden gönderiyorsanız, sadece zaman kaybediyorsunuz.

Pratik bir not: 4xx kodu her zaman "sorun bizde değil" anlamına gelmez. Kendi sunucunuz 421 ile yanıt veriyorsa, sorun kendi altyapınızın içindedir.

Yaygın 4xx kodları ve doğru adım

452 kodu, düşündüğünüzden daha fazla sizi ilgilendirir. Hedef sunucu yeterli alanı olmadığını söylediğinde, ya alıcının posta kutusu doludur ya da sizin sunucunuzun kotası sınıra dayanmıştır. Kendi mesajlarınız takılıysa, E-posta kotası yönetimi; posta kutusu dolduğunda ne yapmalıyız? tam da bu senaryoyu açıyor.

421 kodunu ciddiye alın. Sunucunuz toplu gönderim yükü altında gelen bağlantıları 421 ile kapatıyorsa, geçerli göndericiler de geri çevrilir. Burada hız sınırı (rate limit) IP ve alan adına göre ayarlanmalıdır, herkes için sabit bir sayı değil.

5xx kodları ve artık geri gelmeyenler

Tüm destek taleplerinde en sık görülen kod 550'dir. Ancak 550 tek bir hata değildir; bir ailedir. Koddan sonraki metin, bunlardan hangisi olduğunu belirler:

• 550 5.1.1 — Hedef posta kutusu mevcut değil. Adresi yanlış yazdınız veya hesap silinmiş.
• 550 5.7.1 — Politika (policy) nedeniyle reddedildi. Genellikle IP'niz kara listededir veya SPF/DKIM doğru ayarlanmamıştır.
• 550 5.7.26 — Sahibi olmadığınız bir alan adından geçerli kimlik doğrulama olmadan gönderim.
• 551 — Kullanıcı taşınmış; yeni adres yanıt metninde gelir.
• 552 — Mesaj izin verilen boyut sınırından büyük.
• 553 — Gönderen veya alıcı adresi sözdizimsel olarak geçersiz.
• 554 — İşlem reddedildi; çoğunlukla şüpheli içerik veya alan adı itibarı nedeniyle.

5.1.1 ile 5.7.1 arasındaki farkı hafife almayın. Birincisi adresi düzeltin ve bitti demektir. İkincisi alan adınızda veya IP'nizde yapısal bir sorun olduğu anlamına gelir ve çözülene kadar hangi adresi gönderirseniz gönderin reddedilir.

550 5.7.1'i neden beklenenden fazla görüyorsunuz

Çünkü alan adı kimlik doğrulama kayıtları eksiktir. Alan adınızın SPF'si, gönderim yaptığınız sunucunun IP'sini kapsamıyorsa, alıcının reddetme hakkı vardır. Doğru bir kayıt şu şekildedir:

v=spf1 ip4:203.0.113.45 include:_spf.servernet.cloud -all

Sondaki -all işareti "diğer tüm göndericileri reddet" demektir. Bazıları daha yumuşak olan ~all koyar, ancak yalnızca tek bir sunucudan gönderim yapan bir alan adı için -all daha doğru seçimdir. Alan adınızın kayıtlarının şu an ne olduğunu bilmiyorsanız, önce MX kaydı kontrolü ve TXT kayıtlarını yapın ki başlangıç noktası netleşsin.

Burada hata yapıyorlar

Destek taleplerinde gördüğüm en yaygın hata şudur: kullanıcı bir 550 alır, "hedef sunucuda sorun var" varsayar ve mesajı on kez daha kuyruğa geri gönderir. Sonuç ne olur? Kuyruk dolar, sunucu başarısız denemelerin yüksek hızı nedeniyle kendisi kara listeye girer ve artık normal e-postalar da spam'e düşer. Belirtisi de açıktır: birkaç gün sonra dahili mektuplar bile gecikmeli ulaşır ve postqueue -p yüzlerce takılı mesaj gösterir.

İkinci hata ise tam tersi: 450 görüp mesajı hemen kuyruktan silmek. 450 geçicidir ve kuyruk kendi işini yapar. Elle silmek yalnızca mesajın bounce kaydedilmeden kaybolmasına neden olur ve gönderen bunu asla anlamaz.

Gerçekten yardımcı olan araçlar

Postfix'te kuyruk durumunu görmek için:

postqueue -p
postqueue -j | jq '.queue_name, .recipients[].delay_reason'

JSON çıktısı jq ile filtrelenir ve her alıcının gecikme nedenini ayrı ayrı gösterir. Bu, ham günlüğü okumaktan çok daha hızlıdır.

Bağlantıyı elle test etmek ve hedef sunucunun yanıtını görmek için:

swaks --to user@example.com --server mx.example.com --from you@yourdomain.com

swaks kurulu değilse, openssl s_client -connect mx.example.com:25 -starttls smtp ile de elle EHLO çekip yanıtları görebilirsiniz. Bu test, hatanın sizin tarafınızdan mı yoksa hedef taraftan mı olduğunu gösterir.

IP itibarını ve kara listeleri kontrol etmek için birçok çevrimiçi araç vardır, ancak her şeyden önce sunucunuzun IP'sinin alan adının SPF'sinde olduğundan emin olun. Sipariş onayı veya parola sıfırlama gibi işlemsel e-postaları paylaşımlı hosting'den gönderiyorsanız, bu uzun vadede işe yaramaz; İşlemsel e-posta; neden hosting'den göndermeyelim ve doğru alternatif nedir? nedenini ve uygun alternatifin ne olduğunu açıklıyor.

Almanız gereken bir karar

5xx hatası aldığınızda iki yolunuz vardır: adresi düzeltip yeniden gönderin ya da tüm alan adını kimlik doğrulama açısından gözden geçirin. Benim tercihim koda bağlıdır. 5.1.1 ise, yalnızca adresi düzeltin. 5.7.x ise, SPF ve DKIM ve DMARC'ı doğru yapana kadar yeniden göndermek zaman kaybıdır.

Bu gözden geçirmenin maliyetini de söyleyeyim: p=reject politikasıyla doğru DMARC ayarlamak, raporları incelediğiniz sürece ilk birkaç gün bazı geçerli e-postaların reddedilmesine neden olabilir. E-posta hacminiz yüksekse, p=none ile başlayın ve bir hafta sonra raporları gördükten sonra daha katı hale getirin.

Posta kutularının günlük yönetimi ve hangi hesapların dolduğunu kontrol etmek için, Webmail ile çalışma ve e-posta yönetimi için özellikleri hakkında tam kılavuz iyi bir başlangıç noktasıdır. Taşınmayı düşünüyorsanız da, IMAP ile e-posta taşıma; veri kaybetmeden tam kılavuz adımları kapsıyor.

Kendi altyapınız üzerinde çalışıyorsanız ve kuyruk ile günlükler üzerinde tam kontrole sahip olmak istiyorsanız, Postfix'e ve komut satırı araçlarına tam erişimi olan bir Linux hosting bu işi kolaylaştırır.

Sık sorulan sorular

E-postada 450 ve 550 kodu arasındaki fark nedir?

450 kodu geçicidir ve hedef sunucu sonra tekrar dene diyor; gönderim kuyruğu bunu kendisi yapar. 550 kodu kalıcıdır ve mesaj hemen geri döner. 450 alıyorsanız bekleyin, 550 alıyorsanız nedeni çözmeniz gerekir.

550 5.7.1 hatası ne anlama gelir ve nasıl çözülür?

Hedef sunucunun mesajınızı yanlış adres nedeniyle değil, güvenlik politikası nedeniyle reddettiği anlamına gelir. Yaygın neden, gönderen IP'nin alan adının SPF kaydında olmaması, DKIM'ın ayarlanmamış olması veya IP'nin kara listede olmasıdır. Önce alan adı kayıtlarını kontrol edin, sonra kara listeden çıkarma talebinde bulunun.

E-postalar neden 452 koduyla geri dönüyor?

452 kodu yeterli alan olmadığı veya mesaj sayısının izin verilen sınırı aştığı anlamına gelir. Alıcı tek bir kişiyse, posta kutusu dolmuştur. Tüm alıcılar bu kodu alıyorsa, muhtemelen kendi sunucunuzun kotası veya gönderim hızı yüksektir.

Kuyrukta takılı mesajları elle silmeli miyim?

Yalnızca hatanın kalıcı (5xx) olduğundan ve mesajın artık bir değeri olmadığından eminseniz. 4xx hataları için elle silmek, mesajın bounce kaydedilmeden kaybolmasına neden olur. Kuyruğun maximal_queue_lifetime'a göre kendisi karar vermesine izin verin.

Bir dahaki sefere bir hata kodu gördüğünüzde, yalnızca ilk rakama bakın. 4 ise, elinizi tutun. 5 ise, nedeni arayın. Sadece bu tek alışkanlık, e-posta destek taleplerinin çoğunu ortadan kaldırır.