Google Safe Browsing ve E‑Posta Kara Listelerinden Çıkmak: İtibar Temizleme Rehberi

Neden Google Safe Browsing ve E‑Posta Kara Listeleri Bu Kadar Kritik?

Bir anda sitenize giren kullanıcıların tarayıcıda kırmızı bir uyarı ekranı görmesi veya gönderdiğiniz kurumsal e‑postaların topluca spam klasörüne gitmeye başlaması, sadece teknik bir sorun değildir; doğrudan gelir, marka güveni ve SEO kaybı anlamına gelir. DCHost tarafında hem hacklenmiş siteler hem de kara listeye girmiş IP’ler ile sık sık karşılaşıyoruz. Çoğu vakada sorun, önlenebilir birkaç güvenlik açığının ve eksik izleme mekanizmalarının birleşiminden kaynaklanıyor.

Bu rehberde hem Google Safe Browsing uyarısını kaldırmak hem de e‑posta kara listelerinden çıkmak için uyguladığımız gerçekçi ve adım adım bir yol haritasını paylaşacağız. Amacımız, “şu formu doldurun, bekleyin” demekten çok, önce sorunun kaynağını netleştirmek, sonra da hem site hem IP itibarınızı kalıcı olarak toparlayacak bir strateji kurmanıza yardımcı olmak.

Eğer siteniz PHP tabanlı ise hacklenmiş PHP sitelerini temizleme rehberimiz ve WordPress kullanıyorsanız sürekli hacklenen WordPress siteleri için hazırladığımız yazı bu rehberle birlikte okununca hem teknik hem operasyonel olarak çok daha sağlam bir tablo elde edersiniz.

Google Safe Browsing Nedir ve Sitenizi Nasıl Etkiler?

Google Safe Browsing, Chrome başta olmak üzere birçok tarayıcı ve servis tarafından kullanılan, kullanıcıları zararlı içerikten korumayı amaçlayan bir güvenlik altyapısıdır. Sistem, belirli URL’leri ve alan adlarını aşağıdaki risk kategorilerine göre işaretler:

• Zararlı yazılım (malware) barındıran siteler
• Kimlik avı (phishing) amacıyla kullanılan sahte siteler
• İstenmeyen yazılım (unwanted software) dağıtan sayfalar
• Komut dosyası enjekte edilmiş, hacklenmiş siteler

Siteniz bu listeye girdiğinde:

• Ziyaretçiler tarayıcıda kırmızı bir uyarı sayfası görür.
• Organik trafik ciddi oranda düşer; kullanıcılar geri döner.
• SEO tarafında güven sinyalleri zayıflar, sıralamalarınız etkilenebilir.
• E‑posta linkleriniz de güvenli görülmeyebilir; bazı istemciler bu URL’leri engelleyebilir.

Dolayısıyla hedef sadece “uyarıyı sildirmek” değil, aynı zamanda siteyi gerçekten temizlemek ve benzer bir olayı tekrar yaşamamak için güvenlik mimarisini güncellemek olmalıdır. Bu noktada HTTP güvenlik başlıkları rehberimizden yararlanarak tarayıcı tarafı korumayı da güçlendirmek önemli bir adım olur.

Google Safe Browsing’e Neden Takılırsınız? En Yaygın Senaryolar

DCHost’ta incelediğimiz vakalarda, Safe Browsing uyarısına yol açan tipik nedenler şöyle:

• Hacklenmiş WordPress / PHP uygulamaları: Tema veya eklenti zafiyetiyle içeri enjekte edilen zararlı JavaScript, iframe veya backdoor dosyalar.
• Phishing sayfaları: /login, /verify gibi klasörlere gizlenmiş banka, kargo veya e‑posta servislerini taklit eden formlar.
• Malware dağıtımı: İndirme linkleriyle zararlı .exe, .apk, .js dosyaları sunulması.
• Boşta bırakılmış subdomain’ler: Test veya unutulmuş alt alan adlarında çalışan eski, zayıf uygulamalar.
• 3. taraf script’ler: Reklam veya istatistik amaçlı eklenen harici script’lerin ele geçirilmesi.

Özellikle ajans ve kurumsal yapılarda, tek hosting hesabında birden fazla site barındırıldığında, hacklenen tek bir proje bile aynı kullanıcı haklarına sahip diğer projeleri domino etkisiyle riske atabiliyor. Bu nedenle, ayrı cPanel hesabı mı addon domain mi? sorusunu güvenlik açısından da ciddi biçimde ele almak gerekiyor.

Google Safe Browsing Uyarısını Nasıl Teşhis Edersiniz?

1. Google Search Console Güvenlik Raporu

İlk bakmanız gereken yer Google Search Console > Güvenlik ve Manuel İşlemler > Güvenlik Sorunları ekranıdır. Burada:

• “Siteniz zararlı yazılım barındırıyor”,
• “Siteniz kimlik avı içeriyor” gibi net bir açıklama,
• Örnek URL listeleri,
• Google’ın tespit ettiği enfekte kaynaklar

görürsünüz. Bu liste, temizlik sürecinde hangi dosya veya sayfalara odaklanmanız gerektiği konusunda çok değerli bir başlangıç noktasıdır.

2. Safe Browsing Şeffaflık Raporu ile URL Kontrolü

Google’ın Safe Browsing şeffaflık sayfasından alan adınızı kontrol ederek:

• Alan adınız genel olarak işaretlenmiş mi,
• Belirli alt yol veya subdomain’ler mi problemli,
• Uyarı son görülme zamanı

gibi bilgilere ulaşabilirsiniz. Özellikle aynı alan adı üzerinde çok sayıda subdomain kullanıyorsanız (örneğin mağaza, panel, blog gibi), problemin tam hangi alt alan adından kaynaklandığını görmeniz önemlidir.

Hacklenmiş Siteyi Temizleme: Güvenli ve Tekrar Edilebilir Süreç

Safe Browsing’den çıkmanın tek yolu sitenin gerçekten temiz olduğuna ve güvenlik açığının kapandığına Google’ı ikna etmektir. Bunun için DCHost’ta uyguladığımız tipik temizlik sürecini sadeleştirilmiş şekilde paylaşalım.

1. Ziyaretçi Güvenliğini Sağlayın ve Durumu Dondurun

• Öncelikle, eğer mümkünse siteyi bakım moduna alın veya en azından sorunlu alt alan adlarını geçici olarak devre dışı bırakın.
• Sunucuya tam erişiminizi (FTP/SFTP, SSH, panel) kontrol edin; yetkisiz hesap olup olmadığını gözden geçirin.
• Mevcut durumun bir anlık tam yedeğini alın. Bu yedek, hem adli analiz hem de yanlışlıkla sildiğiniz bir şeyi geri almak için hayat kurtarır.

Bakım moduna geçerken, SEO kaybı olmadan maintenance page yayınlama rehberimizde anlattığımız yönlendirme ve HTTP kodlarına da dikkat etmenizi öneririz.

2. Zararlı Dosyaları ve Backdoor’ları Tespit Edin

Bu adım, temelli çözüm için en kritik kısımdır. Özellikle PHP tabanlı sitelerde:

• Normalde olmaması gereken .php dosyaları (örneğin uploads klasörü içinde),
• Garbled (okunması zor, base64_encode, eval, gzinflate vb. içeren) kod parçaları,
• Çok uzun tek satırlık PHP dosyaları,
• Son değişiklik tarihi çok yeni olan çekirdek dosyalar

backdoor işareti olabilir. Hacked PHP sitelerini temizleme rehberimizde bu tespiti komut satırı ve çeşitli tarama araçlarıyla nasıl sistematik hale getirebileceğinizi detaylı anlattık; burada prensip odaklı ilerleyelim:

• Dosya bütünlük kontrolü: CMS çekirdek dosyalarını orijinal sürümle karşılaştırın.
• Değişiklik tarihi analizi: Belirli bir tarihten sonra topluca değişen dosyaları listeleyin.
• Şüpheli fonksiyon taraması: eval, base64_decode, shell_exec, system vb. içeren dosyaları tarayın.

3. Çekirdek, Tema ve Eklentileri Temiz Kaynakla Yeniden Kurun

Hacklenmiş dosyaları tek tek “temizlemeye” çalışmak çoğu zaman hatalıdır. Onun yerine:

• CMS çekirdeğini (WordPress, Joomla, vb.) orijinal paketlerden yeniden yükleyin.
• Tema ve eklentileri resmi kaynaklarından indirip güncel sürümlerle değiştirin.
• Kullanmadığınız eklenti ve temaları tamamen kaldırın.

WordPress kullanıyorsanız, sürekli hacklenen WordPress siteleri için hazırladığımız rehberde bu adımları WordPress ekosistemine özel örneklerle detaylandırıyoruz.

4. Veritabanını Kontrol Edin

Saldırganlar sadece dosyalara değil, veritabanına da zararlı içerik enjekte edebilir. Özellikle:

• wp_posts veya benzeri içerik tablolarında gizlenmiş script etiketleri,
• Seçenek / ayar tablolarında (wp_options vb.) şüpheli URL’ler veya script’ler,
• Yönlendirme yapan eklenti tablolarında beklenmedik hedef URL’ler

tarama kapsamına alınmalıdır. Burada hem SQL aramaları hem de yönetim paneli üzerinden içerik taraması birlikte kullanılmalıdır.

5. Tüm Erişim Bilgilerini ve Anahtarları Yenileyin

• Hosting paneli, FTP/SFTP, SSH kullanıcı parolalarını değiştirin.
• Veritabanı kullanıcı parolalarını güncelleyin ve konfigürasyon dosyalarında bu bilgileri yenileyin.
• CMS admin hesaplarını gözden geçirip kullanılmayanları kapatın, zayıf şifreleri güçlendirin.
• API anahtarları (ödeme, SMS, 3. taraf servisler) sızma ihtimaline karşı yenilenmelidir.

6. Sunucu ve Uygulama Güvenliğini Sertleştirin

Site temizlendikten sonra, tekrar aynı sorunu yaşamamak için sunucu ve uygulama seviyesinde ek önlemler almak gerekiyor:

• Güvenlik başlıkları: HSTS, CSP, X‑Frame‑Options gibi başlıkları HTTP güvenlik başlıkları rehberimizde anlattığımız şekilde uygulayın.
• WAF kullanımı: Panel tarafında ModSecurity gibi bir WAF etkinse doğru kural setlerini uygulayın; Cloudflare kullanıyorsanız Cloudflare güvenlik ayarları rehberimizdeki WAF, rate limit ve bot koruma önerilerini dikkate alın.
• Güncelleme politikası: Çekirdek, eklenti ve temalar için düzenli güncelleme rutini oluşturun.
• Yedekleme: 3‑2‑1 prensibine uygun otomatik yedekleme ve geri yükleme testleri uygulayın.

Google Safe Browsing’den Çıkış: İnceleme Talebi Nasıl Verilir?

Sitenin gerçekten temiz olduğundan emin olduktan sonra, sıra Google’a güvenlik probleminin giderildiğini anlatmaya geliyor.

1. Kalan İzleri ve Harici Referansları Kontrol Edin

• Search Console’daki güvenlik sorunları sayfasında listelenen tüm URL’leri tek tek kontrol edin.
• Site haritanızı (sitemap.xml) ve robots.txt dosyanızı gözden geçirin; zararlı URL’ler hala indexleniyor mu?
• Önbellek (cache) eklentilerini, CDN ve tarayıcı önbelleğini temizleyin.

2. Google Search Console Üzerinden İnceleme Talebi Gönderin

Güvenlik Sorunları ekranında, problemi düzelttiğinizi belirten bir inceleme talebi formu doldurmanız gerekir. Bu metinde:

• Sorunun kaynağını (örneğin zafiyetli eklenti, zayıf şifre, eski CMS sürümü) açıkça belirtin.
• Hangi adımları attığınızı (dosya temizliği, yeniden kurulum, şifre değişimi, WAF etkinleştirme gibi) net bir şekilde listeleyin.
• Gelecekte benzer bir sorunun yaşanmaması için aldığınız önlemleri (güncelleme politikası, izleme, yedekleme vb.) açıklayın.

Genellikle birkaç saat ile birkaç gün arasında sonuç alırsınız. Eğer yeniden reddedilirse, Search Console çoğu zaman hala problemli gördüğü URL’leri daha detaylı listeler; bu durumda temizlik sürecini bir kez daha gözden geçirmeniz gerekir.

E‑Posta Kara Listeleri (RBL/DNSBL) Nedir?

Bir diğer kritik itibar bileşeni de e‑posta IP / alan adı itibarıdır. E‑posta sunucunuzdan gönderilen iletiler, çeşitli RBL/DNSBL kara listeleri tarafından takip edilir. Bu listeler, IP adreslerini ve zaman zaman alan adlarını aşağıdakilere göre işaretler:

• Spam şikayet oranları
• Spam tuzaklarına (spam trap) düşen e‑postalar
• Virüslü veya zararlı içerik taşıyan iletiler
• Açık relay veya hatalı yapılandırılmış SMTP sunucuları

Eğer IP’niz veya alan adınız bu listelerden birine girerse:

• Bazı alıcı sunucular e‑postalarınızı doğrudan reddeder (550, 554 vb. hatalar).
• Bir kısmı spam klasörüne sürükler.
• Transactional (şifre sıfırlama, sipariş onayı vb.) e‑postalar teslim edilemez.

Bu süreci doğru yönetmek için öncelikle e‑posta hata kodlarını ve bounce mesajlarını doğru okuyabilmek, ardından SPF, DKIM ve DMARC doğrulamasını sağlam temellere oturtmak gerekir.

IP/E‑Posta İtibarı Neden Bozulur? Gerçekçi Vaka Örnekleri

DCHost’ta gördüğümüz en yaygın senaryoları özetleyelim:

• Hacklenmiş site üzerinden spam: Form script’leri veya zafiyetli PHP dosyaları kullanılarak binlerce spam e‑posta gönderilmesi.
• Ele geçirilmiş e‑posta hesabı: Zayıf şifresi brute force ile kırılmış bir kullanıcı hesabından toplu spam gönderimi.
• Yanlış kurgulanmış pazarlama kampanyaları: Onaysız liste kullanımı, çift opt‑in olmadan büyük hacimli mailing.
• Hatalı SPF/DKIM/DMARC: Yanlış DNS kayıtları nedeniyle meşru e‑postaların bile “sahte” görünüp işaretlenmesi.
• Paylaşımlı IP riski: Aynı IP’yi kullanan başka bir sitenin veya hesabın spam göndermesi.

IP itibarı bozulduğunda, konuyu sadece “delisting isteği” ile çözmeye çalışmak yerine, önce neden kara listeye girdiğinizi netleştirmeniz gerekir. Aksi halde kısa süre içinde tekrar kara listeye girmeniz çok olasıdır.

IP’niz Kara Listeye Girdiyse: Adım Adım Kurtarma Planı

1. Şikayet ve Hata Kodlarını Analiz Edin

Önce ne kadar ve nerede problem yaşadığınızı anlamalısınız:

• Mail log’larında 550 / 554 / 421 gibi hata kodlarını inceleyin.
• Alıcı sunuculardan gelen bounce mesajlarındaki “blocked, blacklisted, listed in” ifadelerini not alın.
• Hangi sağlayıcıların (kurumsal, ISP, vb.) sizi reddettiğini çıkarın.

2. Hangi Kara Listelerde Olduğunuzu Tespit Edin

Farklı RBL/DNSBL kontrol araçlarını veya komut satırı sorgularını kullanarak IP’nizi tarayın. Çıkan sonuçları sınıflandırın:

• Büyük etki alan kara listeler: Çok sayıda alıcı tarafından kullanılan listeler.
• Daha sınırlı etkiye sahip listeler: Belirli bölgeler veya spesifik sağlayıcılar.

Her kara listenin delisting süreci ve kriterleri farklıdır; bu nedenle liste başına ayrı aksiyon planı çıkarmalısınız.

3. Spam Kaynağını Kapatın

Delisting talebi göndermeden önce spam kaynağının yüzde yüz kapandığından emin olmalısınız:

• Hacklenmiş web sitesi veya form üzerinden gönderim varsa, yukarıda anlattığımız site temizleme adımlarını uygulayın.
• Ele geçirilmiş e‑posta hesaplarını tespit etmek için son dönemde aşırı e‑posta gönderen kullanıcıları ve login IP’lerini analiz edin.
• Riskli hesapları kilitleyin, güçlü parolalar ve mümkünse 2FA zorunluluğu getirin.
• SMTP rate limit (dakikadaki/saateki maksimum e‑posta sayısı) sınırlarını gerçekçi seviyelere çekin.

Paylaşımlı hosting kullanıyorsanız, aynı IP üzerinde diğer sitelerin durumunu hosting sağlayıcınızla birlikte kontrol etmek önemlidir. DCHost olarak böyle durumlarda IP özelinde daha detaylı log analizi ve gerekiyorsa izole IP tahsisi ile süreci yönetiyoruz.

4. SPF, DKIM ve DMARC’ı Doğru Kurgulayın

Teknik doğrulamalar doğru yapılmadan delisting talebine odaklanmak, sorunun yarısını çözmek anlamına gelir. Önce:

• SPF: Alan adınız adına e‑posta göndermeye yetkili IP ve servisleri net şekilde tanımlayın, gereksiz include’ları kaldırın.
• DKIM: Gönderici sunucunuzun her domain için imza oluşturduğundan emin olun.
• DMARC: Başlangıçta p=none ile rapor toplayarak trafiğinizi anlayın, sonra kademeli olarak karantina / reddetme politikalarına geçin.

Bu yapı için temelden başlıyorsanız, küçük işletmeler için SPF, DKIM ve DMARC ayarlarına yönelik rehberimizi adım adım uygulayabilirsiniz.

5. Delisting (Kara Listeden Çıkış) Başvurularını Yapın

Her kara liste için genellikle bir “removal” veya “delist” formu bulunur. Bu formlarda aşağıdaki noktaları net olarak belirtmek gerekir:

• Sorunun kaynağı (hacklenmiş site, ele geçirilmiş hesap, hatalı kampanya vb.).
• Spam kaynağını nasıl tespit ettiğiniz (log analizi, güvenlik taraması vb.).
• Hangi önlemleri aldığınız (güvenlik güncellemeleri, şifre değişiklikleri, rate limit, doğrulama kayıtları vb.).
• Gelecekte tekrar etmeyeceğini gösteren politika değişiklikleri (opt‑in süreçleri, kampanya frekansı, izleme vb.).

Bu süreçleri uçtan uca görmek için, IP itibarına odaklı hazırladığımız e‑posta itibarını kurtarma rehberimizi mutlaka okumanızı öneririz; orada postmaster araçları ve özel IP ısıtma adımlarını detaylandırıyoruz.

6. Güvenli IP Isıtma ve Kademeli Gönderim

IP’niz yeni temizlenmişse veya yeni bir dedicated IP’ye geçmişseniz, bir anda yüksek hacimli e‑posta göndermek itibarınızı tekrar riske sokar. Güvenli bir ısıtma planı için:

• İlk günlerde en etkileşimli alıcılarınıza (sık açan, tıklayan) düşük hacimli gönderimler yapın.
• Geri dönüş oranlarını (açılma, tıklanma, spam şikayeti) izleyerek hacmi kademeli artırın.
• Gelen şikayet ve bounce oranları yükselirse, hacmi tekrar düşürün ve liste kalitesini gözden geçirin.

Bu konuda da hem teoriyi hem pratiği bir araya getiren dedicated IP ısıtma ve e‑posta itibarı yönetimi rehberimizi referans alabilirsiniz.

Kalıcı Çözüm İçin Güvenlik ve İzleme Stratejisi

Google Safe Browsing uyarısından çıkmak ve e‑posta kara listelerinden kurtulmak, aslında daha büyük bir yapbozun iki parçası. Kalıcı çözüm için hem web uygulaması güvenliği hem de e‑posta altyapısı için aşağıdaki başlıkları bir standarda oturtmanız gerekir.

1. Uygulama ve Sunucu Güvenliği

• CMS, eklenti ve temalar için güncelleme politikası oluşturun (örneğin haftalık kontrol).
• Yönetim panellerine IP kısıtlama, 2FA ve güçlü parola politikası uygulayın.
• VPS veya dedicated sunucularda sshd_config sertleştirmesi, firewall, fail2ban gibi temel önlemleri hayata geçirin.
• Dosya izinlerini (644/755) ve sahiplikleri düzenli olarak kontrol edin.

2. İzleme ve Alarm Mekanizmaları

• Sunucu loglarını merkezi olarak toplayın; olağan dışı trafik ve hata paternlerini raporlayın.
• Uptime ve yanıt sürelerini izleyin; anomali durumunda bildirim alın.
• SMTP loglarında ani hacim artışı, belirli alıcılara yığılan hata kodları gibi sinyallere alarm tanımlayın.

3. DCHost Olarak Nasıl Destek Oluyoruz?

DCHost altyapısında, site ve IP itibarınızı korumaya yardımcı olmak için:

• Paylaşımlı hosting, VPS ve dedicated sunucu çözümlerinde izole kaynak kullanımı ve doğru yapılandırılmış varsayılan güvenlik ayarları sunuyoruz.
• Gerektiğinde ayrı IP adresleri ve SMTP ayarlarıyla e‑posta itibarınızı segmentlere ayırmanızı sağlıyoruz.
• Hacklenmiş site vakalarında, yedeklerden geri dönüş, temiz taşıma ve güvenli yeniden kurulum süreçlerinde teknik ekibimizle yanınızda oluyoruz.
• İhtiyaç duyan müşterilerimiz için güvenlik sertleştirme (hardening), izleme ve yedekleme stratejilerini birlikte tasarlıyoruz.

Özet ve Yol Haritası: Sadece Uyarıyı Silmek Değil, İtibarı Geri Kazanmak

Google Safe Browsing uyarısı ve e‑posta kara listeleri, çoğu işletme için ilk karşılaşıldığında panik sebebi oluyor. Ancak doğru bakış açısıyla bu uyarıları, altyapınızı ve süreçlerinizi güçlendirmek için bir “uyandırma çağrısı” olarak da görebilirsiniz. Bu rehberde anlattığımız adımların ortak noktası şu:

• Önce durumu doğru teşhis etmek (Search Console, log analizi, RBL kontrolleri).
• Sonra gerçek nedeni ortadan kaldırmak (hack temizliği, hesap güvenliği, doğrulama kayıtları, rate limit).
• Ardından doğru ve dürüst bir delisting başvurusu ile inceleme istemek.
• En sonunda da tekrar etmeyecek bir güvenlik ve izleme mimarisi kurmak.

Eğer şu anda Safe Browsing uyarısı alıyorsanız, IP’niz kara listedeyse veya hem site hem e‑posta tarafında itibarınızı yeniden inşa etmeniz gerekiyorsa, DCHost ekibi olarak altyapınızı ve mevcut durumunuzu birlikte değerlendirip uygulanabilir bir aksiyon planı çıkarmaya hazırız. Hem bu rehberdeki adımları hem de bağlantı verdiğimiz detaylı yazıları uygulayarak, birkaç adımda değil ama planlı bir süreçle, dijital itibarınızı yeniden güvenli ve sürdürülebilir bir seviyeye taşıyabilirsiniz.