SMTP Hata Kodları ve Bounce Mesajları Rehberi

E-posta altyapısını yöneten herkes, bir noktada 4xx veya 5xx ile başlayan SMTP hata kodlarıyla karşılaşıyor. Çoğu zaman müşteri tarafında görülen tek şey basit bir şikâyet: Gönderdiğim e-posta geri dönüyor. Ancak perde arkasında, SMTP sunucularının konuştuğu oldukça net bir dil var ve bu dilin kelimeleri bu hata kodları ile bounce (geri dönüş) mesajları. Bu dili okuyabildiğiniz anda, e-posta teslim sorunlarını tahmin ettiğinizden çok daha hızlı çözmeye başlıyorsunuz. Bu yazıda, DCHost tarafında her gün sahada karşılaştığımız somut örneklerden yola çıkarak SMTP hata kodlarını nasıl yorumlayacağınızı, bounce mesajını satır satır nasıl okuyacağınızı ve hangi durumda hangi teknik adımları atmanız gerektiğini detaylı ama sade bir dille anlatacağız. Amacımız, elinize bir bounce düştüğünde paniğe kapılmadan, kodu gördüğünüz anda sorunun büyük resimini görebilmeniz ve doğru düzeltmeyi uygulayabilmeniz.

SMTP hata kodları neden kritik?

SMTP hata kodları, e-posta teslim zincirinde nerede, neden ve hangi ciddiyette bir problem olduğunu size doğrudan anlatan işaretlerdir. Sunucular arası iletişim sırasında her kritik adım bir kod ile cevaplanır ve bu kodu doğru okursanız:

• Adres hatası mı, içerik filtresi mi, kota veya boyut sorunu mu olduğunu anında ayırt edersiniz.
• Geçici (soft bounce) mi, kalıcı (hard bounce) mı olduğunu görüp, tekrar denemenin anlamlı olup olmadığını bilirsiniz.
• Sorunun sizde mi, alıcı tarafta mı, yoksa aradaki ağ ve DNS katmanlarında mı olduğunu netleştirirsiniz.
• IP itibarınız, SPF/DKIM/DMARC konfigürasyonunuz veya kara liste sorunlarınız hakkında doğrudan sinyal alırsınız.

Özellikle kendi e-posta sunucusunu yönetenler için, örneğin DCHost üzerinde VPS veya dedicated sunucu kullanan işletmelerde, SMTP hata kodlarını doğru yorumlayabilmek operasyonel desteğin yarısından fazlasını çözer. SPF, DKIM, DMARC ve rDNS ayarları ile e-posta teslim edilebilirliğini nasıl güçlendirebileceğinizi detaylı olarak anlattığımız rehberi bu yazıyla birlikte okursanız, teşhis ve çözüm süreciniz çok daha sağlam bir temele oturur.

SMTP ve bounce mesajı temelleri

Önce kavramları netleştirelim. SMTP, e-postanın gönderici MTA (Mail Transfer Agent) ile alıcı MTA arasında nasıl taşınacağını tanımlayan protokoldür. Gönderim sırasında şu adımlar kabaca gerçekleşir:

• Gönderici sunucu, alıcı domain için MX kaydını DNS üzerinden çözer.
• Bu MX kayıtlarında tanımlı SMTP sunucusuna bağlanır.
• HELO/EHLO, MAIL FROM, RCPT TO ve DATA komutları sırasıyla çalışır.
• Her kritik adımda karşı sunucu bir durum kodu döner.

Hata iki şekilde karşınıza çıkar:

Anlık SMTP hatası (synchronous)

Gönderici MTA, bağlantı sırasında karşı sunucudan doğrudan bir 4xx veya 5xx kodu alır. Bu durumda genellikle kullanıcı tarafına anında hata yansır veya kuyrukta tekrar deneme politikası devreye girer. Loglarda doğrudan SMTP oturumu içinde bu kodu görürsünüz.

Sonradan gelen bounce (asynchronous)

Bazen alıcı sunucu ilk etapta kabul eder, ancak daha sonra içerik filtresi, virüs taraması veya alıcı posta kutusu kotası gibi nedenlerle mesajı reddeder. Bu durumda alıcı sunucu, kaynak sunucuya geri bir teslim edilemedi bildirim (Delivery Status Notification) yani bounce e-postası gönderir. Kullanıcı genellikle posta kutusunda postmaster veya mailer-daemon benzeri bir göndericiden gelen geri dönüş mesajı görür.

Her iki durumda da, asıl ipucunuz SMTP durum kodu ve genişletilmiş hata açıklamasıdır. Bu nedenle gelen her bounce mesajını dikkatlice saklamak ve içindeki ham hata satırlarını incelemek çok kritik.

4xx geçici SMTP hata kodları (soft bounce)

4 ile başlayan tüm SMTP hata kodları, teorik olarak geçici bir soruna işaret eder. Bu nedenle soft bounce olarak adlandırılırlar. Gönderici MTA genellikle belirli bir süre boyunca mesajı kuyrukta tutar ve tekrar göndermeyi dener. Bu hataları görürseniz, mesajın mutlaka kaybolduğu anlamına gelmez; ama sebebi doğru anladığınızdan emin olmanız gerekir.

421 Service not available

Örnek mesaj satırı:

421 4.3.2 Service not available, closing transmission channel

Anlamı:

• Alıcı SMTP sunucusu şu anda yeni bağlantı kabul edemiyor.
• Yük altındadır, bakımda olabilir veya bağlantı limiti dolmuştur.

Neler yapmalısınız:

• Kendi MTA loglarınızda aynı anda tüm hedeflere mi, yoksa sadece belirli bir domaine mi 421 hatası aldığınızı kontrol edin.
• Sadece tek domain etkileniyorsa, büyük olasılıkla alıcı taraf kapasite veya oran sınırlaması (rate limit) uyguluyordur.
• Kısa süre bekleyip tekrar denenmesine izin verin; arka arkaya ve yüksek hacimli gönderimleri yavaşlatın.

450 Requested mail action not taken: mailbox unavailable

Örnek:

450 4.2.0 Mailbox temporarily unavailable

Bu kod genelde:

• Alıcı posta kutusunun geçici olarak kilitli olduğu,
• Disk kotası sınırına çok yaklaşıldığı,
• Virüs taraması sırasında geçici blokaj uygulandığı

gibi durumlarda görülür.

Yapılacaklar:

• Aynı alıcıya farklı zamanlarda gönderilen e-postalarda da 450 görüyorsanız, alıcı taraf posta kutusu veya depolama sorunu ihtimalini iletin.
• Kendi sunucunuzda ise, disk ve quota değerlerini, özellikle paylaşımlı hosting ortamında cPanel veya Plesk üzerinden kontrol edin.

451 Requested action aborted: local error in processing

Örnek:

451 4.3.0 Temporary server error. Please try again later

Genellikle alıcı sunucudaki dahili bir hataya işaret eder:

• Virüs tarayıcı, spam filtresi veya harici bir API modülünün çökmesi,
• Veritabanı bağlantı hataları,
• DNS sorgularında geçici sorunlar.

Kendi e-posta sunucunuzu yönetiyorsanız:

• Sunucu yükünü ve sistem loglarını inceleyin.
• DNS tarafında genel bir sorun olup olmadığını kontrol edin; DNS tarafında sorun yaşandığında sitelerinizin de etkilenebileceğini unutmayın. Bu konuyu derinlemesine ele aldığımız DNS hata teşhis rehberine de göz atabilirsiniz.

452 Insufficient system storage

Örnek:

452 4.3.1 Insufficient system storage

Mesaj çok net: Alıcı veya gönderen tarafta disk alanı kritik seviyeye gelmiş. Bu durumda:

• VPS, dedicated veya colocation sunucunuzda df ve izleme araçlarıyla disk kullanımını kontrol edin.
• Log dosyalarının şişmesi, yedeklerin yanlış dizinde tutulması gibi klasik sorunlara bakın.
• Disk alanı sorunu sık tekrar ediyorsa, kaynak planlama tarafında adım atmanız gerektiğini gösteren sinyallerden biridir; bu konuda doğru VPS boyutlandırma ve depolama planlaması rehberimiz işinize yarayacaktır.

5xx kalıcı SMTP hata kodları (hard bounce)

5 ile başlayan hata kodları, kalıcı sorun anlamına gelir ve hard bounce olarak sınıflanır. Bu tür bir hata aldığınızda, aynı içeriği, aynı alıcıya tekrar tekrar göndermek genellikle hiçbir şeyi değiştirmez; önce sorunu düzeltmeniz gerekir.

500, 501, 503: Sözdizimi ve protokol hataları

Bunlar genellikle:

• SMTP komutlarının yanlış kullanılması,
• Hatalı HELO/EHLO formatı,
• Eksik veya yanlış MAIL FROM ve RCPT TO sözdizimi

gibi teknik sebeplerle çıkar. Kendi MTA’nızı kurduysanız veya uygulama içinden doğrudan SMTP konuşması yapıyorsanız daha sık görürsünüz.

Örneğin:

501 5.5.4 Invalid domain name in HELO

Bu durumda:

• Sunucunuzun host adının (hostname) tam nitelikli alan adı (FQDN) olduğundan emin olun.
• Reverse DNS (PTR) kaydınızı bu FQDN ile uyumlu olacak şekilde ayarlayın.
• DCHost üzerinde kendi VPS veya dedicated sunucunuz varsa, PTR kaydı ve hostname konusunu doğru kurgulamak için destek ekibimizden yardım isteyebilirsiniz.

550 Requested action not taken: mailbox unavailable

En sık gördüğümüz hata kodlarından biri:

550 5.1.1 User unknown
550 5.1.1 Recipient address rejected: User does not exist

Anlamı net: Alıcı e-posta adresi yok veya yanlış yazılmış. Özellikle toplu gönderim yapanlarda eski, bozuk, yazım hatalı listeler yüzünden bu hata oranı çok yükselir.

Yapılacaklar:

• Liste hijyeni yapın; uzun süredir hiç açılmamış veya sürekli 5.1.1 dönen adresleri temizleyin.
• Çift opt-in (double opt-in) ve e-posta doğrulama süreçleri kurun.
• Hard bounce oranı yüksek listeleri, IP itibarınızı bozmadan kademeli olarak temizleyin. Bu konuda pratik ipuçları için e-posta itibarını kurtarma rehberimize göz atabilirsiniz.

550 5.7.1: Permission denied veya spam şüphesi

Bu hata genelde şöyle görünür:

550 5.7.1 Message rejected due to spam or policy reasons
550 5.7.1 Relaying denied

Alıcı taraf, gelen mesajı politikaları gereği reddediyor. Muhtemel sebepler:

• Gönderici IP kara listede (RBL listeleri).
• SPF, DKIM veya DMARC kayıtlarınız hatalı veya hiç yok.
• Gönderdiğiniz içerik, spam filtrelerinin hassas olduğu kalıplarla dolu.
• Relay yapılandırmanız yanlış ve sunucunuzun izinsiz açık gönderim (open relay) gibi görünmesine yol açıyor.

Bu durumda:

• Önce SPF, DKIM ve DMARC kayıtlarınızı kontrol edin; ayrıntılı ayar ve örnekler için teslim edilebilirlik makalesini kullanın.
• Gönderici IP’niz herhangi bir RBL’de listeli mi, kontrol edin ve gerekiyorsa delist başvurusu yapın.
• Sunucunuzdan yetkisiz toplu çıkışlar var mı, logları inceleyin; hacklenmiş web formları veya zayıf şifreli posta kutuları sık görülen nedenlerdir.

552 Message size exceeds fixed maximum message size

Örnek:

552 5.3.4 Message size exceeds fixed maximum message size

Mesaj boyutu, gönderen veya alıcı taraftaki limitleri aşıyorsa bu hata gelir. Özellikle büyük ek dosyalar, HTML içinde gömülü görseller veya inline resimlerle şişen bildirim e-postaları bu hataya yol açar.

Çözüm önerileri:

• Uygulamanızda maksimum ek boyutunu mantıklı bir seviyede sınırlayın.
• Gereksiz görselleri ve ağır imzaları sadeleştirin.
• Büyük dosyalar için, dosyayı bir nesne depolama (S3 uyumlu) çözümüne yükleyip, e-postada sadece indirme bağlantısı paylaşmayı tercih edin.

554 Transaction failed veya permanent problem

554 genelde en can sıkıcı olanlardan; çünkü çok genel bir kod ve çoğu zaman asıl sebep, genişletilmiş açıklamada saklıdır:

554 5.7.1 Service unavailable; Client host blocked
554 5.2.0 Message content rejected

Burada:

• İçerik filtresi (spam, virüs, zararlı link) tarafından reddedilme,
• IP itibarına bağlı tam blok,
• Belirli bir ülke, ASN veya IP aralık politikasına takılma

söz konusu olabilir. Bu durumda bounce içindeki ek hata açıklamasını, alıcı MTA’nın adını ve varsa referans linkleri dikkatlice incelemeniz gerekir.

Genişletilmiş SMTP durum kodları (x.y.z) nasıl okunur?

Klasik 3 haneli kodlara ek olarak, RFC 3463 ile tanımlanan genişletilmiş durum kodları vardır. Örneğin:

550 5.1.1 User unknown
451 4.4.1 Timeout while waiting for reply from host

Burada ikinci kısım olan x.y.z çok değerli bilgiler taşır.

• İlk rakam (4 veya 5): Geçici mi kalıcı mı hata olduğunu gösterir.
• İkinci rakam (0-7): Hatanın ana kategorisini belirtir.
• Üçüncü rakam (0-9): Alt detay kodudur.

Sık görülen kategorilerden bazıları:

• 5.1.x: Adresleme hataları (var olmayan kullanıcı, hatalı domain vb.).
• 5.2.x: Posta kutusu sorunları (kota dolu, posta kutusu devre dışı).
• 5.3.x: Sistem durum problemleri (disk alanı, yapılandırma hataları).
• 5.4.x: Ağ ve yönlendirme sorunları (DNS veya routing hataları).
• 5.7.x: Güvenlik, politika ve yetkilendirme hataları (spam, relay denied, kimlik doğrulama sorunları).

Örneğin 5.7.1 gördüğünüzde, direkt olarak güvenlik veya politika kaynaklı bir reddedilme ile uğraştığınızı bilirsiniz. 4.4.1 ise genellikle zaman aşımı ve ağ sorunlarına, DNS veya alıcı sunucu yanıt vermemesine işaret eder.

Bir bounce mesajını satır satır okumak

Elinize gelen klasik bir bounce mesajı genelde şu bileşenlerden oluşur:

• Konu satırı (Delivery Status Notification, Undelivered Mail Returned to Sender vb.).
• Özet açıklama (kısa insan okunabilir metin).
• Diagnostik kod ve uzak sunucu cevabı.
• Orijinal iletinin başlıkları ve bazen tamamı.

Basitleştirilmiş bir örnek üzerinde gidelim:

Mail delivery failed: returning message to sender

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its recipients. This is a permanent error.

<[email protected]>: host mx.example.com[203.0.113.10] said:
    550 5.1.1 <[email protected]>: Recipient address rejected: User unknown

Reporting-MTA: dns; mail.sizin-domaininiz.com
Action: failed
Final-Recipient: rfc822; [email protected]
Status: 5.1.1
Remote-MTA: dns; mx.example.com
Diagnostic-Code: smtp; 550 5.1.1 Recipient address rejected: User unknown

Burada dikkat etmeniz gereken kritik satırlar:

• host mx.example.com satırı: Hangi alıcı sunucunun bu hatayı ürettiğini gösterir.
• 550 5.1.1: Hatanın türünü (kalıcı ve adres hatası) net şekilde belirtir.
• Diagnostic-Code: smtp; ile başlayan satır: MTA’nın kaydettiği ham SMTP cevabıdır; genellikle en güvenilir kaynaktır.
• Status: 5.1.1: Genişletilmiş kodu, yani kategoriyi doğrular.

Bu bilgileri bir araya getirerek şu sonuca varırsınız: Hata alıcı taraf sunucuda oluşmuş, kalıcı ve sebebi olmayan kullanıcı. Yapılacak en mantıklı şey, bu adresi listeden çıkarmaktır; DNS, IP veya içerik bazlı bir sorunu takip etmek yerine yanlış adrese e-posta göndermemeye odaklanmalısınız.

Sık görülen senaryolar ve pratik çözüm reçeteleri

Senaryo 1: Toplu kampanyada yüksek 550 5.1.1 oranı

Durum: E-ticaret kampanyası gönderiyorsunuz, kısa sürede çok sayıda 550 5.1.1 User unknown hatası gelmeye başlıyor.

Yorum:

• Liste hijyeni yapılmamış; eski, sahte veya yanlış yazılmış adresler çok.
• Hard bounce oranınız yükseldikçe, IP itibarınız da bozulmaya başlar.

Çözüm:

• Kampanya sonrası tüm bounce kayıtlarını toplayıp, özellikle 5.1.1 dönen adresleri kalıcı olarak kara listeye alın.
• Abonelik formlarınıza e-posta doğrulama ve çift opt-in süreci ekleyin.
• Yeni IP veya yeni domain ile göndermeye başladıysanız, güvenli IP ısıtma politikaları uygulayın; bu konuda IP ısıtma ve itibar rehberimiz size yol gösterecektir.

Senaryo 2: Birçok farklı domaine karşı 550 5.7.1 veya 554 blokları

Durum: Farklı alıcı sağlayıcılara gönderdiğiniz mesajlar, benzer hatalarla geri dönüyor:

550 5.7.1 Message rejected as spam
554 5.7.1 Service unavailable; Client host blocked

Yorum:

• Bu artık tek bir alıcı taraf politikasından çok, genel bir itibar veya kimlik doğrulama sorunu işareti.

Adım adım yapılacaklar:

• SPF kaydınızı, gerçek gönderici IP veya sunucu havuzunu kapsayacak şekilde güncelleyin. Çok fazla include kullanıyorsanız, DNS lookup limitine takılmamak için SPF flattening tekniklerini inceleyin.
• DKIM imzalamanın düzgün çalıştığını test edin; yanlış hizalanmış From alanları sık görünmeyen ama etkili bir sorundur.
• DMARC politikanız çok agresif ise (örneğin doğrudan reject), raporları inceleyene kadar kademeli bir yol (none → quarantine → reject) izleyin.
• Kara liste durumlarınızı ve Postmaster araçlarını kullanarak geri bildirim döngülerini kontrol edin.

Senaryo 3: 451 4.7.1 veya 421 ile greylisting ve oran sınırlamaları

Örnek hata:

451 4.7.1 Try again later
421 4.7.0 Temporary rate limit exceeded

Birçok alıcı MTA, greylisting veya oran sınırlama kullanır. İlk denemede mesajı reddeder, birkaç dakika sonra tekrar dener ve bu sefer kabul eder. Amacı basit spam botlarını yavaşlatmaktır.

Almanız gereken önlemler:

• Kendi MTA’nızın yeniden deneme (retry) politikasının makul olduğundan emin olun; çok kısa sürede vazgeçmesin.
• Toplu gönderimlerde aniden binlerce mesajı tek bir domaine yüklemek yerine, gönderimi zamana yayacak bir kuyruk mantığı kullanın.
• DCHost üzerinde kurulu Postfix veya Exim sunucularınızda, concurrency ve rate limit ayarlarını alıcı taraf davranışlarına göre ayarlayın.

Senaryo 4: 552 boyut limitine takılan önemli belgeler

Durum: Müşterilerinize PDF sözleşme veya büyük raporlar gönderiyorsunuz ve sık sık 552 5.3.4 Message size exceeds hatasıyla karşılaşıyorsunuz.

Önerilen yaklaşım:

• Önce kendi MTA’nızdaki maksimum mesaj boyutu limitini (örneğin Postfix’te message_size_limit) ihtiyaçlarınızı karşılayacak seviyede ayarlayın; ancak bunu sınırsız yapmak yerine gerçekçi bir değer seçin.
• Alıcı tarafın limitlerini kontrol etme şansınız yok, bu nedenle kritik dosyalar için kalıcı bir paylaşım alanı (örneğin nesne depolama) kullanıp, e-posta içinde sadece güvenli bir indirme bağlantısı paylaşmak daha dayanıklı bir modeldir.

SMTP, DNS ve güvenlik katmanı: Kodlar bize neleri fısıldıyor?

SMTP hata kodlarını asla tek başına düşünmemek gerekir; arkasında genelde DNS, IP adresleme ve güvenlik politikaları vardır. Özellikle:

• 4.4.x ve 5.4.x kodları: Çoğu zaman DNS çözümleme, MX kaydı veya bağlantı zaman aşımı problemlerine işaret eder.
• 5.7.x kodları: SPF, DKIM, DMARC uyumsuzlukları, IP kara listeleri ve TLS politikaları ile doğrudan bağlantılıdır.
• 4.7.x kodları: Greylisting, oran sınırlama, geçici güvenlik politikası uygulamaları ile ilgilidir.

E-posta tesliminin IP adresleri ve özellikle IPv6 ile ilişkisini derinlemesine ele aldığımız IPv6 ile e-posta teslimi rehberimizde, PTR, HELO, SPF ve RBL ayarlarını saha tecrübesiyle anlattık. SMTP hata kodlarını okurken bu altyapısal konuları da mutlaka gözünüzün önünde tutmalısınız; aksi takdirde semptomu görür, sebebi kaçırırsınız.

DCHost altyapısında SMTP hata kodlarını yönetmek

DCHost olarak hem paylaşımlı hosting hem VPS, dedicated ve colocation altyapılarında çok farklı ölçeklerde e-posta trafiği görüyoruz. Sahada edindiğimiz en önemli deneyimlerden bazıları:

• İyi log tutmayan bir MTA, en ufak sorunda saatlerinizi boşa harcatır. Bu nedenle, özellikle kendi VPS’inizde Postfix veya Exim kuruyorsanız, detaylı loglamayı ve merkezi log toplamayı ilk günden kurgulamanızı öneriyoruz.
• Yedekli MX yapıları, tek bir sunucu hatasında tüm e-posta trafiğinizin durmasını engeller. Bu yapıyı nasıl kuracağınızı adım adım anlattığımız e-posta altyapısında yedeklilik rehberi ile SMTP hata kodlarının bir kısmını daha oluşmadan engellemiş olursunuz.
• Kendi e-posta sunucunuzu DCHost VPS üzerinde kurmak istiyorsanız, Postfix + Dovecot + rspamd ile adım adım kurulum rehberimizde hem teslim edilebilirlik hem de IP ısıtma tarafında uygulanabilir ayarlar paylaştık.
• Gelişmiş güvenlik katmanı olarak MTA-STS, TLS-RPT ve DANE gibi protokoller devreye girdiğinde, 5.7.x serisi güvenlik hatalarını azaltmak ve TLS uyumsuzluklarını çözmek çok daha kolaylaşıyor. Bu konuyu SMTP güvenliği rehberimizde detaylandırdık.

Adım adım SMTP hata teşhis kontrol listesi

Elinizde bir bounce mesajı veya loglardan kopyaladığınız bir hata satırı olduğunda, pratik bir kontrol listesi üzerinden gitmek işi çok kolaylaştırır.

1. Kodu ve genişletilmiş statüyü not alın

Önce 3 haneli ana kodu (örneğin 550) ve varsa genişletilmiş durum kodunu (örneğin 5.1.1) bir kenara yazın. 4xx mi 5xx mi olduğuna bakarak soft mı hard bounce mu olduğunu belirleyin.

2. Diagnostic-Code ve Remote-MTA satırlarını okuyun

Bounce mesajı içindeki Diagnostic-Code satırı ve Remote-MTA bilgisi, hatanın alıcı tarafta mı, gönderen tarafta mı veya aradaki ağ katmanında mı oluştuğunu anlamanızı sağlar. Uzak sunucunun verdiği kendi açıklaması genelde insana en yakın bilgi kaynağıdır.

3. Adres mi, içerik mi, altyapı mı?

Kodu şu üç kategoriye ayırın:

• Adresleme: 5.1.x ve 5.2.x (adres yok, posta kutusu devre dışı, kota dolu).
• İçerik ve politika: 5.7.x, 554 content rejected, spam veya virüs uyarıları.
• Altyapı: 4.3.x, 4.4.x, 5.3.x, 5.4.x (disk, DNS, ağ, konfigürasyon).

Bu ayrım, hangi ekip veya uzmanlıkla devam etmeniz gerektiğini de belirler.

4. SPF/DKIM/DMARC ve rDNS’i doğrulayın

Güvenlik ve itibar odaklı hatalarda, ilk bakılacak yer DNS kayıtlarıdır. Alan adınızın SPF, DKIM, DMARC ve PTR kayıtlarının düzgün kurulu olması, hem 5.7.x hatalarını hem de kara liste riskini ciddi biçimde azaltır. Ayrıntılı kurulum ve test adımları için ilgili yazımızı tekrar hatırlatalım.

5. Kuyruk, rate limit ve greylisting davranışlarını inceleyin

4xx hatalarında mesajların kuyrukta ne kadar beklediğini, yeniden deneme aralıklarını ve aynı alıcı domaine yönelik eşzamanlı bağlantı sayısını kontrol edin. Gerekiyorsa, MTA konfigürasyonunuzda bu parametreleri hedef ortamların davranışına göre optimize edin.

6. Loglarınızı ve metriklerinizi merkeze alın

Tek tek bounce mesajlarıyla uğraşmak yerine, MTA loglarınızı merkezi bir yerde toplayarak hangi kodların en çok tekrarlandığını görmeniz, iyileştirme sürecini çok hızlandırır. Örneğin:

• Hangi domainlerde en çok 5.1.1 veya 5.7.1 görünüyor?
• Hangi saat aralıklarında 4.4.1 timeout hataları artıyor?
• Belirli bir kampanya sonrası mı 554 spam hataları yükselmiş?

Bu tür gözlemlere göre aksiyon almak, rastgele ayar değiştirmekten çok daha etkili olacaktır.

Sonuç: SMTP hata kodlarını okuyan, e-posta altyapısını yönetir

SMTP hata kodları ve bounce mesajları, ilk bakışta karmaşık ve teknik görünebilir; ama aslında her biri altyapınızın size gönderdiği son derece net bir geri bildirimdir. 4xx ile başlayan geçici hataların, yeniden deneme ve kapasite yönetimi ile; 5xx ile başlayan kalıcı hataların ise çoğunlukla doğru adresleme, sağlıklı kayıtlar (SPF, DKIM, DMARC, PTR) ve temiz IP itibarına bağlı olduğunu gördüğünüzde, teşhis süreciniz neredeyse otomatikleşir. DCHost olarak kendi altyapımızda da aynı yaklaşımı benimsiyoruz: Her bounce’u bir hata değil, sistemi iyileştirecek bir sinyal olarak görüyoruz.

Eğer siz de e-posta trafiğinizi kendi VPS, dedicated veya colocation sunucunuz üzerinden yönetiyorsanız ve SMTP hata kodları ile boğuşuyorsanız, altyapınızı birlikte gözden geçirebilir, DNS ve MTA yapılandırmanızı bu yazıda anlattığımız prensiplere göre revize edebiliriz. Daha esnek ve kontrol edilebilir bir mimariye geçmek istiyorsanız, DCHost’un yönetilen ve yönetilmeyen sunucu çözümlerini inceleyebilir, e-posta teslim edilebilirliğini işinizin kritik bir parçası haline getirebilirsiniz. Unutmayın: SMTP hata kodlarını ne kadar iyi okursanız, kullanıcılarınıza ve müşterilerinize o kadar güvenilir bir e-posta deneyimi sunarsınız.