SMTP 550 hatası, e-postanın alıcıya teslim edilemediğini gösteren kalıcı bir hata kodudur. Genellikle geçersiz e-posta adresi, erişim engeli, spam filtreleri veya kimlik doğrulama sorunlarından kaynaklanır. Arama motorlarında veya popüler webmaster forumlarında “e-posta teslim edilemedi”, “outlook 550 5.7.1 hatası” veya “cPanel mail gitmiyor” gibi terimlerle yapılan aramaların sayısındaki muazzam artış, bu sorunun ne kadar yaygın olduğunu göstermektedir.
SMTP 550 Hatası Nedir?
SMTP – Simple Mail Transfer Protocol, internet üzerindeki e-posta iletişiminin temelini oluşturur. Cihazınızdan veya sunucunuzdan çıkan bir mesaj, SMTP aracılığıyla karşı sunucuya iletilir. Bu iletişim süreci, standartlaştırılmış yanıt kodlarıyla işler (RFC 5321).
SMTP 550 hata mesajları nasıl görünür?
- 550 Talep edilen işlem gerçekleştirilmedi: posta kutusu kullanılamıyor
- 550 Kullanıcı bilinmiyor
- 550 Posta kutusu bulunamadı
- 550 Röle izni verilmemektedir.
- 550 Alıcı adresi reddedildi: Yerel alıcı tablosunda kullanıcı bilinmiyor.
- 550 Politika kısıtlamaları nedeniyle reddedildi
- 550 Geçersiz adres
- 550 Kullanıcının sunucuda çok fazla mesajı var.
- 550 Bir veya daha fazla alıcı için kalıcı arıza
- 550 SPF kontrolü başarısız oldu
Modern sunucular, bu hataya sadece “550” demekle yetinmez. Gelişmiş Durum Kodları olan 5.X.X formatındaki alt kodları da loglara eklerler. Sorunun kaynağını (alıcıda mı, sizin sunucunuzda mı yoksa DNS yapılandırmanızda mı olduğunu) bu alt kodlar belirler.
Başlıca SMTP 550 Alt Kodları, Anlamları ve Stratejik Çözümleri
Aşağıdaki tabloda, log kayıtlarınızda en sık karşılaşacağınız 550 varyasyonlarını, bu hataların semantik anlamlarını ve web yöneticisi olarak atmanız gereken ilk adımları bir araya getirdik:
| Gelişmiş Hata Kodu | Sunucu Log Mesajı Örneği | Teknik Neden (Kök Analiz) | Uygulanması Gereken Çözüm |
|---|---|---|---|
| 550 5.1.1 | The email account that you tried to reach does not exist / User unknown | Alıcının e-posta adresi hedef sunucuda fiziksel olarak bulunmuyor. | Adres listenizi temizleyin. Bu adresleri veritabanından silin; aksi takdirde gönderici itibarınız düşer. |
| 550 5.7.1 | Unable to relay / Message rejected due to content restrictions / Spam Filtering | Sunucu, e-postanızı aktarmak için yetkiniz olmadığını belirtiyor veya içerik filtreleri mesajınızı spam olarak algıladı. | E-posta istemcinizde “Giden sunucum kimlik doğrulaması gerektiriyor” seçeneğini aktif edin. İçeriğinizdeki spammy kelimeleri temizleyin. |
| 550 5.7.26 | This mail has been blocked because the sender is unauthenticated | Gönderen alan adı, alıcı sunucunun beklediği kriptografik kimlik doğrulama standartlarını karşılamıyor. | Alan adınızın DNS bölgesine girerek geçerli TXT kayıtlarını oluşturun. |
| 550 5.4.1 | Recipient address rejected: Access denied | Alıcı sunucusu, dizin tabanlı kenar engelleme veya yönlendirme hatası sebebiyle e-postayı reddediyor. | Genellikle Microsoft Exchange altyapılarında görülür. Sorun büyük ihtimalle alıcının DNS veya etki alanı yönlendirmesindedir; alıcı kurumun BT ekibiyle görüşülmelidir. |
| 550 5.4.5 | Daily sending quota exceeded | E-posta gönderim limitini aştınız. | Sisteminizin gönderimlerini saatlere bölün veya limitleri daha yüksek kurumsal/toplu e-posta paketlerine geçiş yapın. |
| 550 5.2.1 | Mailbox cannot receive email / User’s mailbox is disabled | Alıcının posta kutusu dolu, dışarıdan mail alımına kapatılmış veya alan adınız alıcı tarafından kara listeye alınmış. | Alıcıya farklı bir kanaldan ulaşarak posta kutusunda yer açmasını veya sizin alan adınızı beyaz listeye almasını isteyin. |
💡 Eğer sunucunuzdan “550 Message headers fail syntax check” hatası alıyorsanız, sorununuz muhtemelen otomasyon yazılımlarınızın (PHP Mailer gibi) “To:”, “From:” veya “Subject:” başlıklarına RFC standartlarına uymayan, bozuk veya Türkçe (non-ASCII) karakterler eklemesinden kaynaklanmaktadır.
SMTP 550 Hatası Nasıl Düzeltilir? Detaylı Çözümler
SMTP 550 hatasının birçok olası nedeni vardır, bu nedenle her duruma uyan tek bir çözüm bulunmaz. İşte bazı nedenler için detaylı çözüm yolları:
1. Güvenlik Protokollerini Yapılandırma: SPF, DKIM ve DMARC
E-posta güvenliği ve teslimat başarısı için bu üç DNS kaydı kritik öneme sahiptir. 550 hatalarının önemli bir kısmı, bu kayıtların eksik veya hatalı olmasından kaynaklanır. Şimdi, her birinin ne olduğunu ve nasıl yapılandırılacağını detaylı inceleyelim.
# SPF Nedir ve Nasıl Eklenir?
SPF, basit tabirle sizin alan adınız adına dünyadaki hangi IP adreslerinin ve sunucuların e-posta gönderme yetkisine sahip olduğunu ilan ettiğiniz bir TXT kaydıdır.
Diyelim ki hem kendi sunucunuzdan hem de Google Workspace üzerinden e-posta gönderiyorsunuz. TXT kaydınız şu şekilde görünmelidir: v=spf1 ip4:192.168.1.50 include:_spf.google.com ~all
v=spf1: Kaydın bir SPF kaydı olduğunu belirtir.ip4:192.168.1.50: Kendi sunucunuzun IP adresi (örnektir, kendi IP’nizi yazmalısınız).include:_spf.google.com: Google sunucularına da yetki verdiğinizi gösterir.~all(Soft Fail) veya-all(Hard Fail): Listede olmayan bir IP’den mail gelirse ne yapılacağını söyler. Güvenlik için-allönerilse de, teslimat sorunlarını en aza indirmek için genellikle~allkullanılır.
⚠️ Uyarı: Bir alan adında yalnızca 1 adet SPF kaydı bulunabilir. Eğer birden fazla v=spf1 ile başlayan satır eklerseniz sunucu kafası karışır ve kaydı geçersiz sayar. Ayrıca, SPF sorgularında maksimum 10 yönlendirme sınırı vardır. Çok fazla include kullanmak (örneğin hem Mailchimp, hem Sendgrid, hem Google, hem Yandex vb.) bu limiti aşmanıza ve “PermError” almanıza yol açarak 550 hatasını tetikler.
# DKIM Kurulumu
DKIM, e-postalarınızın içeriğine ve başlıklarına kriptografik bir dijital imza ekler. Bu imza, mesajın yolda bir siber saldırgan tarafından değiştirilip değiştirilmediğini kanıtlar.
- Hosting panelinizden (cPanel > Email Deliverability veya Plesk > Mail Settings) DKIM oluştur seçeneğine tıklayın.
- Sunucunuz size özel bir gizli anahtar oluşturup kendi içinde saklayacak, size de DNS’e eklemeniz için bir genel anahtar verecektir.
- Genellikle
selector._domainkeyismiyle oluşturacağınız TXT kaydının içinev=DKIM1; k=rsa; p=MIIBIjANBgkqh...şeklinde başlayan uzun kodu yapıştırıp kaydedin. Yeni standartlara göre bu anahtarın en az 1024-bit, tercihen 2048-bit uzunluğunda olması güvenliğiniz için elzemdir.
# DMARC (Politika, Raporlama ve Uyum) Yapılandırması
DMARC, SPF ve DKIM’in patronudur. Karşı sunucuya “Eğer bir mesaj benim SPF veya DKIM testlerimden geçemezse ona ne yapmalısın?” talimatını verir.
DNS yönetiminize _dmarc adında bir TXT kaydı açıp şu değeri girmelisiniz: v=DMARC1; p=none; rua=mailto:admin@alanadiniz.com;
p=none: Başlangıç için en güvenli politikadır. Sadece izleme yapar, testten kalan mailleri reddetmez, size rapor gönderir.p=quarantine: Testi geçemeyen mailleri doğrudan alıcının spam klasörüne atar.p=reject: Testi geçemeyen mailleri “550 5.7.26” hatasıyla doğrudan reddeder.
Sisteminizin stabil çalıştığından emin olmadan asla p=reject moduna geçmeyin. Aksi halde meşru e-postalarınız (örneğin web sitenizin iletişim formundan veya CRM sisteminizden giden bildirimler) bile reddedilebilir. RUA etiketine yazdığınız e-posta adresine gelen karmaşık XML raporlarını anlamlandırmak için Analiz araçlarını kullanabilirsiniz. İşte tavsiye edebileceğimiz Test ve Monitoring araçları:
- MXToolbox– mxtoolbox.com üzerinde MX lookup, SMTP test, blacklist check, SPF/DKIM/DMARC validasyonu gibi onlarca aracı ücretsiz kullanın. E-posta altyapınızın sağlık raporu gibi.
- Mail-Tester- mail-tester.com adresine test e-postası gönderin. Spam skoru, DNS kayıtları, başlık analizi ve tavsiyeler içeren kapsamlı bir rapor alırsınız. 10/10 puan hedefleyin.
- Gmail Postmaster Tools– postmaster.google.com adresine domain’inizi ekleyin. Gmail’e günlük ne kadar e-posta gönderdiğinizi, spam oranınızı, IP reputasyonunuzu ve teslimat hatalarını izleyin.
- SendForensics / GlockApps– Inbox placement testleri yapın. E-postalarınızın farklı ISP’lerde (Gmail, Outlook, Yahoo vb.) inbox’a mı spam klasörüne mi düştüğünü görün. Ücretli ama deneme sürümleri var.
2. Sunucu ve İstemci Tarafı SMTP 550 Çözümleri
Eğer hatanız alan adı itibarı değil de donanımsal veya programsal yapılandırma eksikliklerinden kaynaklanıyorsa, aşağıdaki senaryolara odaklanmalısınız.
# Microsoft Outlook “550 5.7.1 Unable to relay” Hatası
Kullanıcıların e-posta programlarında en çok yaşadığı sorunlardan biridir. İstemci, giden posta sunucusuna (SMTP) bağlanıp e-posta göndermek istediğinde, sunucu bu bağlantının yetkili bir kullanıcıdan geldiğini doğrulamak zorundadır. Doğrulama yapılmazsa, sunucu sizin bir “Açık Röle” (Open Relay – spamlara alet olan sunucu) olmadığınızı kanıtlamanız için bağlantıyı reddeder.
Çözüm:
- Outlook’ta
Dosya > Hesap Ayarları > Sunucu Ayarlarıveya Denetim Masası üzerindenPosta (Microsoft Outlook)yolunu izleyin. - Sorunlu e-posta hesabını seçip “Diğer Ayarlar” butonuna tıklayın.
- Açılan pencerede “Giden Sunucusu (Outgoing Server)” sekmesine gidin.
- “Giden sunucum (SMTP) için kimlik doğrulaması gerekiyor” kutucuğunu işaretleyin.
- Altında bulunan “Gelen posta sunucumla aynı ayarları kullan” seçeneğinin işaretli olduğundan emin olup ayarları kaydedin. Artık sunucu sizi tanıyacak ve aktarıma izin verecektir.
# cPanel Altyapısında “550 No Such User Here” Yönlendirme Çözümü
cPanel / WHM kullanan Linux tabanlı sunucularda, bazen kullanıcı mevcut olmasına rağmen Verification failed for 550-No Such User Here 550 Sender verify failed gibi mantıksız bir hata alınabilir. Bu durum genellikle sunucunun yerel e-posta yönlendirme tablosundaki bir bozulmadan kaynaklanır.
Çözümü (Root Erişimi Gerektirir):
- Sunucunuza Putty veya benzeri bir programla SSH üzerinden bağlanın.
nano /etc/valiases/alanadiniz.comkomutuyla ilgili alan adının alias (takma ad) yapılandırma dosyasını açın.- Dosya içerisinde
*: :fail: No Such User Hereşeklinde bir satır görüyorsanız, bu satırı tamamen silin. CTRL+XardındanYtuşlarına basarak dosyayı kaydedip çıkın.- Değişikliklerin etkili olması için posta servisini yeniden başlatın:
/etc/init.d/exim restart. İşlem tamam!
# Microsoft Exchange S3140 Bloklanması ve Kara Liste Çözümü
Özellikle Office 365, Hotmail, Outlook.com adreslerine mail gönderirken dönen hatanın içinde şu ibare geçiyorsa durum ciddidir: ...Please contact your Internet service provider since part of their network is on our block list (S3140)...
Bu, sunucunuzun IP adresinin Microsoft’un Anti-Spam ağları tarafından kalıcı olarak kara listeye alındığını gösterir. Paylaşımlı bir hosting kullanıyorsanız, aynı IP adresini paylaştığınız başka bir web sitesinin yaptığı spam gönderimler sizin de yanmanıza neden olmuş olabilir.
Çözümü:
- Microsoft Destek Talep Formu (Office 365 Anti-Spam IP Delist Portal) adresine giriş yapın.
- Engellenen sunucu IP adresinizi ve iletişim bilgilerinizi eksiksiz doldurun.
- Microsoft’un otomatik sistemleri IP’nizi inceleyecek ve genellikle birkaç saat içinde “IP’niz koşullu olarak hafifletildi” (conditionally mitigated) şeklinde bir yanıt dönecektir.
- Ancak, sunucunuzdaki spam açığını (örneğin kırılmış bir WordPress eklentisi üzerinden atılan mailler) bulup kapatmazsanız, Microsoft IP’nizi tekrar ve daha kalıcı şekilde bloke eder.
# Postfix ve Exim Yapılandırması
Sunucunuzda Postfix veya Exim çalışıyorsa yapılandırma dosyalarını kontrol etmeniz gerekebilir:
| Postfix için Kontroller | Exim için Kontroller |
|---|---|
# Relay izinleri kontrolpostconf mynetworks # SMTP auth aktif mi? postconf smtpd_sasl_auth_enable # TLS ayarları postconf smtpd_tls_cert_file postconf smtpd_tls_key_file | # Exim versiyonu exim -bV# Kuyruk kontrolü exim -bp# Belirli bir mesajı test exim -d -bt kullanici@domain.com |
| Ana yapılandırma: /etc/postfix/main.cf dosyasını düzenleyin. Özellikle smtpd_recipient_restrictions satırı önemli. | Ana yapılandırma: /etc/exim.conf veya /etc/exim4/exim4.conf.template dosyasını inceleyin. acl_check_rcpt bölümü relay kontrollerini içerir. |
✅ Sahada karşılaştığımız gerçek bir senaryoyu sizlerle paylaşmak istiyoruz. Yakın zamanda, günlük binlerce iletişim formu yanıtı ve bilgilendirme maili gönderen bir müşterimizde (bir belediye yönetimiydi) tam da kritik bir kampanya döneminde ani bir kriz patlak verdi.
Sorun şuydu: Kullanıcılardan veya diğer kurumlardan gelen e-postaları sorunsuz bir şekilde alabiliyorduk. Ancak, onlara bir yanıt dönmeye çalıştığımızda loglarımız sürekli “550 5.7.26 Unauthenticated email” ve “550 5.7.1” hatalarıyla doluyordu. Karşı tarafın Exchange ve Microsoft 365 sunucuları bizim iletilerimizi kapıdan çeviriyordu. Müşteri panik halindeydi. İlk adım olarak DNSlytics ve MXToolbox gibi araçlarla sunucumuzun IP itibarını kontrol ettim. IP adresimizde herhangi bir kara liste (blacklist) kaydı görünmüyordu. Sorunun altyapısal bir engelleme değil, yeni nesil politika reddi olduğunu fark ettim. Sorunun kök nedeni, Google ve Microsoft’un yeni devreye aldığı ve e-posta başlıklarındaki “Kimden (From)” kısmında yer alan alan adının, gönderim yapan sunucu IP’si ile kriptografik olarak uyuşmasını zorunlu kılan kurallardı. Müşterinin SPF kaydı vardı, ancak DMARC politikası eksikti ve DKIM imzası bozulmuştu. Hızlıca DNS üzerinde yeni bir DKIM anahtarı ürettik, DMARC kaydını p=none seviyesinde yayına aldık. Yaklaşık 24 saatlik bir DNS propagasyon (yayılma) sürecinin ardından, dönen 550 hataları tamamen sıfırlandı. Bu deneyim bize şunu çok net gösterdi: Günümüzde e-posta teslim edilebilirliği, sadece bir sunucu kiralayıp mail hesabı açmakla bitmiyor; sürekli izlenmesi gereken, canlı ve güvenlik odaklı bir sistem yönetimi gerektiriyor.
Sıkça Sorulan Sorular
1) 550 5.1.1 hatası kendiliğinden düzelir mi, bu adrese tekrar mail atmalı mıyım?
Hayır, 550 5.1.1 (User unknown / Posta kutusu bulunamadı) hatası sunucu sistemlerinde “Kalıcı Hata” olarak sınıflandırılır. Bu, sorunun geçici bir ağ kesintisi olmadığı, belirttiğiniz adresin fiziksel olarak hedef sunucuda var olmadığı anlamına gelir. Adreste harf hatası yapılmış olabilir veya alıcı şirketten ayrılıp hesabı silinmiş olabilir. Bu adrese otomasyon üzerinden sürekli mail göndermeye devam ederseniz, sisteminiz sürekli “Sert Sekme” (Hard Bounce) alacak ve e-posta servis sağlayıcınız (Google, Outlook vb.) sizi spammer olarak mimleyecektir. Çözüm, bu adresi derhal gönderim listelerinizden çıkarmaktır.
2) SPF, DKIM ve DMARC kayıtlarını ekledim ama hala Gmail’den “550 5.7.26 Unauthenticated email” hatası alıyorum. Neden?
Kayıtları oluşturmak tek başına yetmeyebilir; “Hizalama” (Alignment) denen kavramı kaçırıyor olabilirsiniz. Örneğin, e-postanızı satis@sirketiniz.com adresinden gönderiyorsanız ancak arka planda mailleri ileten sunucu mailchimp.com ise ve SPF kaydınızda Mailchimp’e yetki vermediyseniz, Google bu uyuşmazlığı tespit eder ve maili reddeder. Ayrıca SPF kaydınızdaki DNS Lookup (yönlendirme sorgusu) limitinin 10’u aşmadığından emin olun. Çok fazla üçüncü parti servis eklerseniz SPF kaydınız “PermError” verir ve geçersiz sayılır.
3. DMARC politikamı güvenlik için hemen “p=reject” yapmalı mıyım?
Kesinlikle hayır. DMARC kurulumunda aceleci davranıp doğrudan p=reject politikasına geçmek felaketle sonuçlanabilir. Sitenizin iletişim formlarından, muhasebe yazılımlarından veya destek bilet sistemlerinden giden meşru e-postalarınızın DKIM veya SPF ayarlarında ufak bir pürüz varsa, bu mailler de kendi DMARC politikanız tarafından reddedilecektir. Sektörel en iyi uygulama her zaman p=none (sadece raporla) ile başlamaktır. Gelen DMARC RUA XML raporlarını birkaç ay izleyip tüm gönderim kaynaklarınızı doğruladıktan sonra p=quarantine (Spam klasörüne at) ve en son güvenli adım olarak p=reject seviyesine geçmelisiniz.
4. Günlük gönderim kotasını aştığımda çıkan 550 5.4.5 hatasını nasıl önleyebilirim?
Bu hata (Daily sending quota exceeded), sunucu sağlayıcınızın spam çıkışını önlemek için koyduğu saatlik/günlük gönderim kısıtlamalarına takıldığınızı gösterir. Paylaşımlı hostinglerde genellikle saatte 100-200 mail limiti vardır. Bu sorunu aşmak için bülten yazılımlarınızın ayarlarından e-postaları zamanlayarak gruplar halinde göndermeyi (throttling) seçebilirsiniz. Veya profesyonel e-posta pazarlaması yapıyorsanız, hostinginizin mail servisi yerine yüksek limitli, sadece mail gönderimi için optimize edilmiş üçüncü parti SMTP servislerine geçiş yapmanız en sağlıklı çözüm olacaktır.
Outlook’ta şirket hesabımla yurt dışındaki bir müşterime e-posta gönderemiyorum. ‘550 Requested action not taken: mailbox unavailable’ hatası alıyorum. Karşı tarafla konuştum, e-posta adresi doğru. Bu durumda problem bende mi onlarda mı?
Bu hata, genelde alıcı posta kutusunun ulaşılamaz olduğunu gösterir. Ancak bu, sadece alıcının hatası olmayabilir. İşte gözden geçirmeniz gerekenler:
–Alıcı adresinin yazımında boşluk, nokta, tire gibi karakter hataları var mı?
–Alıcı sunucusu, sizin alan adınızı güvenilir bulmuyor olabilir.
–Kimi zaman, gelen kutusu dolu olan hesaplara gönderim yapıldığında da bu hata alınır.
–E-posta içeriğinde spam çağrıştırabilecek kelimeler kullanmak da filtreye takılmanıza neden olabilir.
Yine de emin olmak için kendi domain’inizi test eden servisler (örneğin mail-tester.com) üzerinden SPF, DKIM gibi yapılandırmaları kontrol etmenizi öneririm.
CPanel üzerinden oluşturduğum e-posta adresi ile bazı domainlere mail gönderemiyorum, 550 hatası dönüyor. Ancak gelen kutusu çalışıyor. Bu gönderim engelinin nedeni nedir?
Bu genellikle outbound SMTP ayarlarıyla ilgilidir. Gönderim yapamamanız ama alımda sorun olmaması aşağıdaki nedenlere dayanabilir:
–Hosting sağlayıcınız outbound SMTP trafiğini kısıtlamış olabilir.
–Alan adınızın DNS kayıtları eksikse (SPF, DKIM), bazı sunucular sizi yetkisiz gönderici olarak görür.
–Sunucunuzun IP adresi kara listede olabilir.
–Mail header’ları yanlış yapılandırılmışsa, bazı sunucular bunu spam olarak algılar.
cPanel’deki Zone Editor ile DNS kayıtlarınızı gözden geçirip eksik olanları tamamlayabilirsiniz.
E-posta adresim üzerinden toplu mail gönderdiğimde 550 hatası çıkıyor ama tek tek gönderdiğimde sorun olmuyor. Toplu gönderimlerde bu hatayı nasıl önleyebilirim?
Toplu e-posta gönderimi sunucular için her zaman riskli bir işlemdir. Bu durumda 550 hatası şunları gösterebilir:
–Gönderim limiti aşılmış olabilir.
–E-posta içeriği spam’e yakın bulunmuş olabilir
–IP adresiniz çoklu alıcıya kısa sürede mesaj gönderdiği için filtrelenmiş olabilir.
Bu tür durumlar için mutlaka profesyonel bir e-posta gönderim servisi (Brevo, Mailchimp, Mailgun) kullanmalısınız. Böylece SPF, DKIM ve hız kontrolleri otomatik yapılır ve 550 hataları minimize edilir.
Merhaba, Outlook üzerinden mail gönderirken ‘550 5.7.1 Unable to relay’ hatası alıyorum. Sunucu ayarlarını defalarca kontrol ettim ama bir türlü çözemedim. Bu hata tam olarak ne anlama geliyor ve SMTP kimlik doğrulaması dışında başka neye dikkat etmem gerekiyor?
Merhaba, bu hata genellikle mail sunucusunun, sizin göndermeye çalıştığınız e-posta adresine iletiyi iletmeye yetkili olmadığını düşündüğünde ortaya çıkar. En yaygın neden, SMTP kimlik doğrulamasının aktif olmamasıdır. Ancak sadece bu da değil:
–SMTP portunun (genellikle 587 veya 465) doğru olduğundan emin olun.
–E-posta istemcinizde “Gönderen kimlik doğrulaması gerekiyor” seçeneği işaretli olmalı.
–Eğer bir mail sunucusuna bağlanıyorsanız, sunucu IP adresiniz whitelist’te olmayabilir.
–Ayrıca şirket içi mail güvenlik yazılımları veya firewall’lar, gönderimi engelliyor olabilir.
Ekstra olarak hosting panelinizdeki e-posta günlüklerini incelemek sorunun kaynağını daha iyi görmenizi sağlar. Yardımcı olması açısından hosting sağlayıcınıza da danışmanızı öneririm.
WordPress sitem üzerinden gelen iletişim formlarından bazıları ulaşmıyor ve sunucu loglarında 550 hatası görüyorum. Bu hata neden bazı maillere olurken diğerlerine olmuyor? Bu bir spam filtresiyle ilgili olabilir mi?
WordPress form eklentileri (örneğin Contact Form 7) bazen eksik yapılandırıldığında SMTP yerine PHP mail() fonksiyonunu kullanır. Bu, bazı sunucular tarafından spam olarak algılanabilir. Ayrıca; hdef adresin (örneğin Gmail) SPF, DKIM veya DMARC gibi e-posta güvenlik kayıtlarını kontrol etmesi sonucu e-posta reddedilebilir, alıcı sunucusu, IP adresinizi spam geçmişine sahip olarak görüyorsa 550 hatası dönebilir, gönderen adresiniz ile alan adınız uyuşmuyorsa da bu tip filtrelemelere takılır. Bu durumda WordPress sitenize SMTP eklentisi kurarak, doğrudan sunucudan değil, güvenli bir e-posta hesabı üzerinden gönderim yapmalısınız.
550 hatası alıyorum ama ilginç olan şu: Maili forward ettiğimde geçiyor, direkt yazarsam gitmiyor. Bu neden olur? Mail sunucuları forward işlemlerine daha mı toleranslı davranıyor?
Bu çok ilginç bir senaryo ama olası. Şöyle açıklayabiliriz:
Forward edilen e-postalar, teknik olarak orijinal göndericinin kimlik bilgilerini koruyarak iletilir. Yani sizin IP’niz ve gönderici bilgileriniz değil, önceki mailin metadata’sı kullanılır. Bu da, SPF ve DKIM doğrulamalarının bypass edilmesini sağlar.Bazı sunucular, forward edilmiş mailleri daha düşük riskli görür. Asıl sorunun sizin mail başlığınız ya da içeriğinizde olabileceğini gösterir.
Bu durumda mail başlıklarınızı, içerik formatını ve kimlik bilgilerinizi dikkatlice gözden geçirmenizi öneririm.
Yönlendirilmiş bir alan adım var ve o domain üzerinden gönderilen mailler 550 hatası veriyor. Ana domainde sorun yok. Bu durum yönlendirme kaynaklı olabilir mi?
Kesinlikle evet. Domain yönlendirmesi sadece web trafiğini etkilerken, e-posta yönlendirmeleri ayrı yapılandırma ister. Şunlara dikkat edin:
–Yönlendirilmiş domain için ayrıca SPF ve MX kayıtları tanımlanmalı.
–Gönderici e-posta adresi, yönlendirilen domain ile aynıysa ama kimlik doğrulama ana domain üzerinden yapılıyorsa, bu çakışma yaratabilir.
–Bazı e-posta sağlayıcıları, “Return-Path” ve “From” alanlarının farklı olmasını şüpheli bulabilir.
Çözüm olarak yönlendirilmiş domaini DNS üzerinde eksiksiz yapılandırmanız gerekiyor. Aksi halde 550 hatası kaçınılmaz olur.
Sunucumu yeni taşıdım, her şey düzgün gibi ama e-posta gönderimi sırasında 550 hataları alıyorum. DNS ayarlarını da güncelledim. Acaba propagation süreci buna sebep olabilir mi?
Evet, sunucu taşıma sonrası DNS kayıtlarının tamamen yayılması (DNS propagation) zaman alabilir. Bu süreçte: SPF, DKIM, MX kayıtları tam oturmamış olabilir. Alıcı sunucular, eski IP üzerinden gelen iletileri hâlâ işliyor olabilir. Reverse DNS (PTR kaydı) henüz güncellenmemişse, bu da kimlik doğrulamasında sıkıntı yaratabilir.
Genellikle bu süreç 24-48 saat arasında tamamlanır. Bu sürede mail gönderimi yerine webmail ya da alternatif SMTP kullanımı geçici çözüm olabilir.
550 hatasını çözebilmek için en kapsamlı log analizi nasıl yapılır? cPanel veya başka bir araç üzerinden bu hatanın tam olarak neden kaynaklandığını görmek mümkün mü?
Evet, cPanel üzerinden bu tür analizleri yapmak oldukça etkili bir yöntemdir. Şöyle ilerleyebilirsiniz:
/var/log/exim_mainlogdosyası en kapsamlı bilgiyi sunar.Bu loglar içinde “550” kodu geçen satırları filtreleyip, hangi alıcıya, hangi saat ve hangi IP ile gönderim yapıldığı bilgisine ulaşabilirsiniz.