PHP, milyonlarca web sitesinin ve web uygulamasının temelinde çalışan en yaygın sunucu tarafı programlama dillerinden biri. Ancak PHP’nin kendi altyapısında ortaya çıkan kritik bir güvenlik açığı, yalnızca tek bir web sitesini değil, aynı sunucu üzerinde çalışan birden fazla uygulamayı da riske atabiliyor. Ekim 2026’da gündeme gelen CVE-2026-109618 ve CVE-2026-109619 numaralı açıklar, bu riskin ne kadar ciddi olabileceğini bir kez daha gösteriyor.

Araştırmacılar tarafından php2shell adıyla anılan güvenlik açıklarının, uzaktan kod çalıştırma (RCE) saldırılarına imkân verebileceği bildirildi. PHP güvenlik ekibi, iki açığı da CVSS v4.0 ölçeğinde 9,2 puanla kritik seviyede değerlendirdi. Resmî duyuruda, etkilenen ve düzeltilen sürümlerin güvenlik güncellemesiyle birlikte açıklanacağı belirtildi.

Bu yazıda PHP2Shell olarak anılan açıkların ne anlama geldiğini, PHP kullanan sunucuların neden risk altında olabileceğini ve sistem yöneticilerinin güvenliklerini artırmak için neler yapabileceğini ele alıyoruz.

PHP2Shell güvenlik açığı nedir?

PHP2Shell, CVE-2026-109618 ve CVE-2026-109619 numaralı iki kritik güvenlik açığı için araştırmacılar arasında kullanılan isimdir. Bu isim, PHP çalışan bir sunucuda uzaktan komut çalıştırılabilmesi ihtimaline işaret ediyor.

Uzaktan kod çalıştırma, bir saldırganın hedef sistemde fiziksel erişim sağlamadan veya sunucuya doğrudan giriş yapmadan kod çalıştırabilmesine olanak tanıyan güvenlik açıklarını ifade eder. Açığın koşullarına bağlı olarak saldırgan; dosya oluşturma, sistem bilgilerini toplama, zararlı yazılım indirme veya sunucu üzerindeki diğer kaynaklara erişmeye çalışma gibi eylemlerde bulunabilir.

Ancak burada önemli bir ayrım var: PHP2Shell açıklarının ayrıntılı teknik çalışma biçimi, ilk duyurular sırasında henüz yayımlanmamıştı. Bu nedenle hangi bileşenin etkilendiği, saldırının hangi koşullarda mümkün olduğu ve belirli bir yapılandırmanın gerekip gerekmediği konusunda kesin konuşmak mümkün değil. Açıkların RCE riski taşıdığına ilişkin bilgiler, teknik ayrıntılar yayımlanmadan önceki araştırmacı değerlendirmelerine dayanıyor.

PHP kullanan hangi sistemler risk altında olabilir?

PHP yalnızca özel olarak PHP ile geliştirilmiş web sitelerinde kullanılmıyor. İçerik yönetim sistemleri, e-ticaret platformları, sunucu yönetim panelleri ve bazı ticari yazılımlar da PHP çalıştırabiliyor.

Bu nedenle olası risk değerlendirmesi yapılırken yalnızca ana web sitesinin kullandığı PHP sürümüne bakmak yeterli olmayabilir.

Özellikle aşağıdaki sistemlerin kontrol edilmesi gerekiyor:

• WordPress: PHP tabanlı web siteleri ve bunların kullandığı sunucu ortamları.
• Drupal ve Joomla: PHP ile çalışan içerik yönetim sistemleri.
• Magento: PHP tabanlı e-ticaret altyapıları.
• cPanel ve Plesk: Web barındırma ve sunucu yönetimi için kullanılan kontrol panelleri.
• Özel web uygulamaları: Şirket içinde geliştirilen veya üçüncü taraflardan temin edilen PHP yazılımları.
• PHP içeren Windows yazılımları: Kendi içinde php.exe veya php-cgi.exe gibi bileşenler barındıran uygulamalar.

Burada dikkat edilmesi gereken nokta, bir yazılımın bu listede yer almasının tek başına savunmasız olduğu anlamına gelmemesidir. Gerçek risk; kullanılan PHP sürümüne, yazılımın çalışma biçimine ve açığın teknik koşullarına bağlıdır.

PHP sürümü nasıl kontrol edilir?

Bir sunucuda hangi PHP sürümünün çalıştığını belirlemek, güvenlik güncellemesi hazırlığının ilk adımlarından biridir.

SSH üzerinden erişilen Linux sunucularda aşağıdaki komut kullanılabilir:

php -v

Bu komut, komut satırında kullanılan PHP sürümünü gösterir. Ancak bazı sunucularda komut satırı PHP’si ile web uygulamalarını çalıştıran PHP sürümü farklı olabilir.

Örneğin web sitesi PHP-FPM üzerinden çalışırken terminalde görülen sürüm başka bir kuruluma ait olabilir. Bu nedenle yalnızca php -v çıktısına güvenmek yerine PHP-FPM servislerini, web sunucusu yapılandırmasını ve kullanılan paketleri de incelemek gerekir.

PHP’nin CGI modunda çalıştığı Windows sistemlerde ise uygulamanın kullandığı php-cgi.exe dosyasının sürümü ayrıca kontrol edilmelidir.

Sunucuda birden fazla PHP sürümü kuruluysa hepsinin envantere alınması önemlidir. Ayrıca barındırma panelinin kendi PHP kurulumları veya uygulamayla birlikte gelen bağımlılıklar da gözden geçirilmelidir.

PHP2Shell açıkları nasıl istismar edilebilir?

Bir güvenlik açığının istismar edilmesi, saldırganın hedef sistemde beklenmeyen bir davranış oluşturmasını ve bu davranıştan yararlanmasını içerir. RCE açıklarında amaç, hedef sunucunun saldırgan tarafından belirlenen kodları çalıştırmasını sağlamaktır.

PHP2Shell için ilk duyurular sırasında yayımlanmış doğrulanmış teknik ayrıntılar bulunmadığından, açığın hangi istek veya parametre üzerinden tetiklendiğini açıklamak mümkün değildi. Bu nedenle belirli bir URL’nin, kod parçasının veya yapılandırmanın bu açığı kesin olarak tetiklediğini iddia etmek doğru olmaz.

Bununla birlikte, PHP tabanlı sunucularda RCE saldırılarının ardından görülebilen bazı davranışlar güvenlik ekipleri için yararlı göstergeler olabilir.

Örneğin normalde web isteğini işlemekle görevli bir PHP sürecinin beklenmedik biçimde komut kabuğu, betik yorumlayıcısı veya dosya indirme aracı başlatması incelenmelidir.

Linux sistemlerde sh, bash, curl, wget, python ve perl; Windows sistemlerde ise cmd.exe, powershell.exe ve certutil.exe gibi süreçlerin PHP çalışanlarından başlatılması şüpheli olabilir. Ancak bu araçların her kullanımının zararlı olmadığı unutulmamalıdır. Meşru yönetim işlemleri de benzer süreçler oluşturabilir.

Bu nedenle süreç adı tek başına yeterli değildir. Komut satırı, işlemi başlatan üst süreç, çalışma zamanı ve sunucunun normal davranışı birlikte değerlendirilmelidir.

PHP güvenlik açığı nasıl kapatılır?

PHP2Shell gibi kritik açıklar karşısında en etkili yöntem, ilgili PHP sürümü için yayımlanan güvenlik düzeltmesini uygulamaktır. Ancak güncellemenin doğru yapılabilmesi için önce sunucunun hangi sürümü kullandığının ve bu sürümün resmî düzeltme alıp almadığının belirlenmesi gerekir.

1. Resmî güvenlik duyurusunu kontrol edin

Güncel bilgiler için PHP’nin resmî güvenlik duyuruları takip edilmelidir:

PHP resmî güvenlik duyurusu

Güncelleme yayımlandığında etkilenen sürümler, düzeltilmiş sürümler ve teknik açıklamalar bu duyuru üzerinden kontrol edilmelidir. PHP paketlerini işletim sistemi deposundan veya bir barındırma sağlayıcısından alan kullanıcılar, ilgili sağlayıcının güncellemesini de incelemelidir.

2. Güncellemeden önce yedek alın

Özellikle üretim ortamlarında PHP sürümünü değiştirmeden önce web dosyalarının, veritabanlarının ve önemli yapılandırma dosyalarının yedeği alınmalıdır.

Güncellemenin test ortamında denenmesi, kullanılan eklentilerin ve uygulamaların yeni sürümle uyumluluğunun kontrol edilmesi önerilir. Bununla birlikte kritik bir güvenlik açığı söz konusu olduğunda test süreci, gerekli güvenlik önlemlerini gereksiz yere geciktirmemelidir.

3. Destek dışı PHP sürümlerini yükseltin

Eski PHP sürümleri, güvenlik güncellemesi alamadıkları için daha büyük bir risk oluşturabilir. PHP’nin destek dışı bir sürümünü kullanan sistem yöneticileri, yalnızca tek bir açık için geçici çözüm aramak yerine desteklenen bir sürüme geçiş planlamalıdır.

Sürüm yükseltmesi hemen yapılamıyorsa sistemin internete açık olup olmadığı değerlendirilmelidir. Gerekli olmayan erişimler kapatılabilir, uygulama VPN arkasına alınabilir veya uygun bir web uygulaması güvenlik duvarıyla korunabilir. Bunlar riski azaltmaya yardımcı olsa da güvenlik yamasının yerini tutmaz.

4. Şüpheli süreçleri ve dosyaları inceleyin

Sunucuda beklenmedik süreç hareketleri görülürse yalnızca ilgili işlemi sonlandırmakla yetinilmemelidir. Web sunucusu ve PHP günlükleri korunmalı; web kök dizinindeki yeni dosyalar, olası webshell’ler, bilinmeyen kullanıcı hesapları ve zamanlanmış görevler incelenmelidir.

Bir ihlalden şüpheleniliyorsa sunucunun ağ erişimini kontrollü biçimde kısıtlamak ve olay müdahalesi sürecini başlatmak daha doğru olacaktır. Günlüklerin korunması, saldırının nasıl gerçekleştiğini anlamak ve tekrarını önlemek açısından önemlidir.

PHP2Shell saldırıları başladı mı?

İlk duyuruların yayımlandığı sırada Huntress, izlediği sistemlerde bu iki güvenlik açığının gerçek saldırılarda kullanıldığına ilişkin bir bulgu görmediğini bildirmişti. Ayrıca açıklar için doğrulanmış bir PoC yayımlanmış değildi.

Bununla birlikte, kamuya açıklanmamış güvenlik açıklarına ilişkin teknik bilgilerin sızması, saldırganların araştırmalarını hızlandırabilir. Düzeltmeler yayımlandıktan sonra saldırganların güncellemeleri inceleyerek savunmasız sistemleri belirlemeye çalışması, güvenlik alanında bilinen bir risktir.

Bu yüzden saldırıların henüz doğrulanmamış olması, sistemlerin güvenli olduğu anlamına gelmez. Özellikle internete açık sunucuların güncel tutulması ve olağan dışı süreç hareketlerinin izlenmesi gerekir.

Sonuç: PHP sunucularını güncel tutmak kritik önem taşıyor

PHP2Shell adıyla gündeme gelen CVE-2026-109618 ve CVE-2026-109619 açıkları, yaygın kullanılan bir yazılımın temel katmanında ortaya çıkan güvenlik sorunlarının ne kadar geniş bir etki alanına sahip olabileceğini gösteriyor.

Sistem yöneticileri için ilk adım, tüm PHP kurulumlarını belirlemek ve resmî güvenlik güncellemelerini takip etmek. Bunun yanında destek dışı sürümlerin internete açık olup olmadığını kontrol etmek, süreç hareketlerini izlemek ve olası bir ihlalde kullanılmak üzere günlükleri korumak da önem taşıyor.

En doğru yaklaşım, doğrulanmamış istismar yöntemlerine dayanarak tahminde bulunmak yerine resmî teknik açıklamaları izlemek ve etkilenen sürümler için yayımlanan düzeltmeleri gecikmeden uygulamaktır.

The post PHP2Shell Alarmı: Kritik Güvenlik Açıkları Sunucuları Tehdit Ediyor appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

Bu takvim doğrultusunda 10 Şubat 2027 ve sonrasında üretilen ya da yenilenen her sertifika 64 günlük geçerlilik süresine sahip olacak. Sistemdeki son 90 günlük sertifikaların ise 11 Mayıs 2027 tarihinde geçerliliğini yitirmesi öngörülüyor. Let’s Encrypt bu geçiş sürecinde hâlihazırda aktif olan geçerli sertifikaları iptal etmeyeceğini bildirdi.

Otomasyonların ve ACME istemcilerinin test edilebilmesi amacıyla, 14 Ekim 2026 tarihinden itibaren test ortamında 64 günlük sertifika üretimi başlatıldı. Canlı ortama geçiş öncesinde test ortamında kontrollerin yapılması tavsiye ediliyor.

Yetkilendirme Sürelerinde Değişiklik ve CAA Rechecking

Güncelleme yalnızca sertifika süresini kapsamıyor doğrulama verisinin yeniden kullanım süresi üzerinde de önemli değişikliklere gidiliyor:

• Mevcut 30 günlük yetkilendirme yeniden kullanım süresi 10 güne düşürülecek.
• 2028 yılı itibarıyla bu süre 7 saate kadar indirilecek.

Bu adımın temel amacı, 2029 yılında yürürlüğe girecek maksimum doğrulama yeniden kullanım süresi kısıtlamalarına şimdiden uyum sağlamak. Aynı zamanda doğrulama verisi 7 saatten eski olduğunda sürecin bir bölümünün tekrarlanmasını gerektiren “CAA rechecking” mekanizmasına duyulan ihtiyacı ortadan kaldırmak. ACME istemciniz özellikle yetkilendirme verisinin yeniden kullanımına bağımlı olacak şekilde yapılandırılmadıysa, bu tarafta herhangi bir manuel değişiklik yapmanız gerekmeyecektir.

Güvenlik Gerekçesi ve Teknik Standartlar

Sertifika ömürlerinin kısaltılması, özel anahtar sızıntısı ve hatalı sertifika üretimi risk pencerelerini küresel çapta daraltmayı amaçlıyor. 64 günlük bu geçiş periyodu, 2028 yılında varsayılan sürenin 45 güne düşürülmesi planlanan nihai standarda da zemin hazırlıyor.

Operasyonel açıdan kritik teknik detaylar:

• Rate Limits: Bu güncellemeden kesinlikle etkilenmeyecektir.
• Uç Noktalar ve Zincirler: ACME API uç noktalarında ya da kök/ara sertifika zincirlerinde herhangi bir değişiklik olmayacaktır.

Ücretsiz SSL Sertifikası kullanmak için web hosting paketlerimizi inceleyebilirsiniz.

Müşterilerimiz İçin Süreç Nasıl İşleyecek?

Bu teknik güncellemenin operasyonel yansıması, kullandığınız hosting ve sunucu ortamına göre farklılık göstermektedir:

Hosting Müşterilerimiz

Paylaşımlı hosting, WordPress ve bayi hesaplarındaki tüm SSL operasyonları arka planda merkezi otomasyon sistemlerimiz tarafından yürütülmektedir. Sertifika yaşam döngüsü doğrudan kontrol panellerimiz aracılığıyla yönetildiği için hosting müşterilerimizin herhangi bir işlem yapmasına veya endişelenmesine gerek yoktur. Sertifikalarınız, süre bitiminden önce otomatik olarak 64 günlük yeni periyotlarla kesintisiz şekilde yenilenmeye devam edecektir.

Sunucu Müşterilerimiz

Sunucunuzda cPanel, Plesk, DirectAdmin gibi modern bir hosting yönetim paneli kullanıyorsanız, herhangi bir işlem yapmanıza gerek yoktur. Bu panellerin yerleşik SSL eklentileri güncel ACME protokollerine tam uyumludur ve sertifikaların bitiş zamanlarını dinamik olarak takip ederek yenileme işlemlerini arka planda otomatik olarak tamamlar. Özel/Panelsiz sunucu kullanıyorsanız aşağıdaki kontrolleri sağlamanızı tavsiye ederiz:

1. ACME Renewal Info Desteği: İstemciniz ARI protokolünü destekliyorsa ek bir konfigürasyona gerek kalmaz; Let’s Encrypt, sertifikanın tam olarak ne zaman yenilenmesi gerektiğini istemcinize dinamik olarak iletir. İstemcinizin dokümantasyonundan ARI desteğini teyit edebilirsiniz.
2. Sabit Kodlanmış Yenileme Eşikleri: Yenileme betiklerinizde veya cron görevlerinizde bitişe kalan gün sayısı 83, 80 veya 60 gibi sabit değerlerle tanımlandıysa, bu kontroller 64 günlük sertifikalarda mantıksal hatalara yol açacaktır. Yenileme kurallarınızı sabit gün sayısı yerine sertifika ömrünün yaklaşık 2/3’ünde (ortalama 40-42. gün) tetiklenecek dinamik bir yapıya çekin.
3. Servis Reload ve Hata Bildirimleri: Sertifikalar daha sık aralıklarla yenileneceği için, yenileme işlemi sonrasında web sunucusu servislerinin reload süreçlerinin sorunsuz çalıştığından emin olun ve olası yenileme aksaklıklarına karşı hata bildirim mekanizmalarını aktif tutun.

Sonuç olarak Let’s Encrypt’in bu adımı, web ekosisteminde güvenliği artırmanın yanı sıra altyapılarda tam otomasyonun önemini bir kez daha ortaya koyuyor. Barındırma hizmeti alan kullanıcılarımız bu süreci hiçbir kesinti yaşamadan tamamen şeffaf biçimde atlatırken, sunucu yöneten müşterilerimizin kontrollerini şimdiden tamamlaması 2027 geçişini sorunsuz kılacaktır. Bu konu hakkında soru/sorunlarınız için teknik destek ekibimizle dilediğiniz zaman iletişime geçebilirsiniz.

The post Let’s Encrypt’ten Güncelleme: Ücretsiz SSL Sertifika Süreleri 64 Güne Düşüyor! appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

Bu durum beraberinde farklı bir soruyu getiriyor: Veri merkezlerini neden Dünya’da tutmak zorundayız?

Google bu soruya oldukça sıra dışı bir cevap arıyor. Şirketin Suncatcher adını verdiği proje, yapay zekâ için kullanılan bilgi işlem altyapısının uzaya taşınmasının mümkün olup olmadığını araştırıyor.

Fikir ilk bakışta bilim kurgu gibi görünse de Google bu konuda yalnızca teorik çalışmalar yapmakla yetinmiyor. Şirket, uzay ortamında yapay zekâ işlemcilerinin kullanılmasını gerçek uydu sistemleri üzerinden test etmeye başladı.

Uzay neden veri merkezleri için ilgi çekici?

Aslında Suncatcher’ın temelindeki fikir oldukça basit: Güneş enerjisi.

Dünya üzerindeki güneş panellerinin önemli bir dezavantajı var. Güneş battığında elektrik üretimi azalıyor veya tamamen duruyor. Bulutlar ve diğer hava koşulları da üretimi etkileyebiliyor.

Uzayda ise durum oldukça farklı. Yörüngede bulunan güneş panelleri, uygun koşullarda Dünya’daki gece-gündüz döngüsünden çok daha az etkilenerek güneş ışığından yararlanabiliyor.

Bu özellik, özellikle yapay zekâ veri merkezleri açısından oldukça önemli olabilir. Çünkü yapay zekâ modellerini çalıştıran işlemciler ciddi miktarda elektrik tüketiyor.

Teorik olarak düşünüldüğünde, sürekli güneş enerjisine erişebilen bir uydu filosu yapay zekâ hesaplamaları için oldukça ilginç bir enerji kaynağı oluşturabilir.

Fakat burada büyük bir sorun var: Bu sistemi uzaya göndermek ne kadar pahalı olacak?

Asıl mesele teknoloji değil, maliyet olabilir

Uzayda veri merkezi kurma fikrinin önündeki en büyük engellerden biri fırlatma maliyetleri.

Google’ın yaptığı değerlendirmeler, kilogram başına fırlatma maliyetinin yaklaşık 200 dolar seviyelerine düşmesi halinde uzaydaki bilgi işlem altyapısının enerji açısından daha anlamlı hale gelebileceğini gösteriyor.

Bugünkü uzay taşımacılığı teknolojisiyle bu hedefe ulaşmak kolay değil.

Bunun gerçekleşebilmesi için çok daha fazla fırlatma yapılması ve roketlerin yüzlerce kez kullanılabilmesi gerekiyor. Başka bir ifadeyle Suncatcher’ın geleceği yalnızca Google’ın geliştirdiği teknolojilere bağlı değil. Uzay taşımacılığının da ciddi şekilde ucuzlaması gerekiyor.

Roketlerin yeniden kullanılabilir hale gelmesi bu nedenle Suncatcher gibi projeler açısından düşündüğümüzden çok daha önemli olabilir.

Peki uzaydaki uydular tek bir bilgisayar gibi çalışabilir mi?

Burada iş biraz daha karmaşık hale geliyor.

Yapay zekâ sistemlerinde tek başına güçlü bir işlemci yeterli değil. Çok sayıda işlem biriminin aynı anda çalışması ve aralarında büyük miktarda veri aktarılması gerekiyor.

Dünya’daki veri merkezlerinde bu problem, işlemcileri ve sunucuları birbirine çok yakın yerleştirerek çözülüyor. Kablolar ve yüksek hızlı ağ sistemleri sayesinde işlem birimleri arasında son derece hızlı iletişim kurulabiliyor.

Uzayda ise sunucuları yan yana dizmek mümkün değil.

Suncatcher benzeri bir sistemde çok sayıda uydunun birlikte çalışması gerekebilir. Bu uyduların birbirlerine yüksek hızlı bağlantılarla bağlanması ve mümkün olduğunca uyumlu şekilde hareket etmesi gerekecek.

Dolayısıyla geleceğin uzay veri merkezleri, bugün kullandığımız klasik uydu sistemlerinden oldukça farklı olabilir.

Belki de tek bir dev uydu yerine, birbirleriyle sürekli iletişim halinde olan çok sayıda küçük bilgisayar uydusundan oluşan bir yapı göreceğiz.

Isıyı uzayda nasıl uzaklaştıracaksınız?

Uzayda veri merkezi kurma fikrinin en ilginç problemlerinden biri de soğutma.

Dünya’daki veri merkezlerinde işlemcilerin oluşturduğu ısıyı uzaklaştırmak için hava soğutma veya sıvı soğutma gibi yöntemler kullanılabiliyor.

Ancak uzayda çevrede dolaşan hava bulunmuyor.

Bu nedenle yüksek performanslı yapay zekâ işlemcilerinin ürettiği ısının uzaya aktarılması gerekiyor. Bunun için büyük radyatörler ve özel termal sistemler kullanılabilir.

Bu da uzay veri merkezlerinin tasarımını doğrudan etkiliyor. İşlemciler, güç kaynakları ve soğutma sistemleri birbirinden bağımsız olarak tasarlanamayacak.

Yani Google’ın karşısındaki problem sadece “TPU’yu uzaya gönderelim” değil. Asıl mesele, bütün bu parçaların birlikte çalışabileceği yeni bir sistem oluşturmak.

Dünya ile iletişim nasıl sağlanacak?

Bir başka önemli konu ise veri transferi.

Uzayda çalışan bir yapay zekâ veri merkezinin Dünya’daki sistemlerle sürekli iletişim kurması gerekecek. Üstelik aktarılacak veri miktarı geleneksel uydulardakinden çok daha fazla olabilir.

Bu noktada lazer tabanlı optik iletişim teknolojileri önem kazanıyor.

Lazerler çok yüksek veri hızlarına ulaşabiliyor. Ancak uzaydan Dünya’ya lazer bağlantısı kurmak sanıldığı kadar kolay değil. Atmosferdeki türbülans lazer ışınının yönünü etkileyebiliyor. Uydu hareket halindeyken bağlantının çok hassas şekilde hedeflenmesi gerekiyor.

Dolayısıyla Suncatcher’ın başarılı olması için yalnızca işlemcilerin değil, iletişim altyapısının da ciddi şekilde geliştirilmesi gerekiyor.

Google’ın TPU işlemcileri neden önemli?

Suncatcher’ın ilk aşamalarında dikkat çeken noktalardan biri Google’ın kendi yapay zekâ işlemcilerini kullanması.

Tensor Processing Unit olarak bilinen TPU’lar, Google’ın yapay zekâ ve makine öğrenimi iş yükleri için geliştirdiği özel işlemciler.

Uzaya gönderilecek bir TPU’nun yalnızca hesaplama performansı önemli değil. Fırlatma sırasında oluşan titreşimlere, ivmelenmeye ve uzaydaki zorlu çevre koşullarına da dayanabilmesi gerekiyor.

Bu nedenle ilk testlerin amacı doğrudan uzayda devasa bir yapay zekâ sistemi çalıştırmak değil. Öncelikle bu donanımların uzay koşullarında güvenilir biçimde çalışıp çalışamayacağı araştırılıyor.

Suncatcher gerçekten veri merkezlerini uzaya taşıyabilir mi?

Bugünden bakıldığında uzayda devasa yapay zekâ veri merkezlerinin kurulması hâlâ uzak bir hedef.

Fırlatma maliyetleri, uydu tasarımı, işlemcilerin dayanıklılığı, soğutma, veri iletişimi ve yörüngedeki koordinasyon gibi birçok problemin çözülmesi gerekiyor.

Ancak uzay teknolojilerinin gelişme hızını da göz ardı etmemek gerekiyor.

Eğer gelecekte roket fırlatma maliyetleri ciddi şekilde düşerse, uydular daha kolay üretilebilir hale gelirse ve yüksek hızlı lazer iletişimi yaygınlaşırsa Suncatcher bugün olduğundan çok daha gerçekçi bir fikir haline gelebilir.

Üstelik yapay zekâ sektörünün enerji ihtiyacı artmaya devam ettiği sürece teknoloji şirketleri alternatif çözümler aramaya devam edecek.

Belki birkaç yıl sonra değil, ancak daha uzun vadede veri merkezlerini yalnızca şehirlerin dışında veya büyük enerji santrallerinin yanında görmek yerine Dünya’nın yörüngesinde de görmeye başlayabiliriz.

Google Suncatcher’ın asıl önemi de burada yatıyor: Proje bugün uzaya dev bir veri merkezi kurmuyor olabilir, ancak geleceğin bilgi işlem altyapısının Dünya’nın sınırlarının dışına çıkıp çıkamayacağını araştırıyor.

The post Google Suncatcher ile Veri Merkezleri Uzaya Taşınabilir mi? appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

1. DNS Kayıtlarının Yapılandırılması

E-posta hizmetinizin aktif ve sorunsuz şekilde çalışabilmesi için ödemenize istinaden kayıtlı e-posta adresinize bilgilendirme e-postası gönderilecektir bu e-posta içerisinde yer alan bilgileri alan adınızın DNS yönetim panelinden tamamlamanız gerekir. Alan adınız veya hosting hizmetiniz İnetmar bünyesinde kayıtlıysa bu işlemler tarafımızca tanımlanır. Farklı bir alan adı kayıt firması kullanıyorsanız aşağıdaki kayıtları DNS yönetim panelinize manuel olarak eklemelisiniz:

• A Kaydı:  mail.alanadiniz.com kaydını tarafınıza iletilen IP adresine (örneğin 92.42.33.1) yönlendirin.
• MX Kayıtları: Gelen e-postaların yönlendirileceği sunucular için öncelik değerleriyle birlikte mx01.inetmar.net (Öncelik: 0) ve mx02.inetmar.net (Öncelik: 10) kayıtlarını girin.
• SPF Kaydı (TXT): E-postalarınızın spam kutusuna düşmesini önlemek için v=spf1 include:_spf.inetmar.net -all değerini TXT olarak ekleyin.
• DMARC Kaydı (TXT): Alan adınızın izinsiz kullanımını raporlamak amacıyla _dmarc alt alan adı için DMARC politikanızı tanımlayın. (örneğin v=DMARC1; p=none; rua=mailto:dmarc@inetmarblog.com; sp=none; adkim=r; aspf=r)
• SRV Kayıtları: Outlook ve mobil istemcilerin hesabı otomatik yapılandırabilmesi için e-posta içeriğindeki _autodiscover, _imaps ve _submission servis kayıtlarını ekleyin.

Not: DNS değişikliklerinin bölgesel olarak çözümlenmesi 15 dakika ile 24 saat arasında sürebilir. Testlerinizi gerçekleştirmeden önce yayılma sürecini beklemeniz önerilir.

2. Kurumsal E-Posta Arayüzüne İlk Giriş

DNS kayıtlarının yönlenmesinin ardından web tarayıcınızdan webmail adresinize giderek kurumsal e-posta hesabınıza ilk girişi yapabilirsiniz:

1. E-posta adresiniz ve parolanız ile oturum açın.
2. İlk oturumda karşınıza gelecek olan Konum Ayarları penceresinden saat diliminizi (örneğin (UTC+03:00) İstanbul) seçin.
3. Tercihinize bağlı olarak olası şifre unutma durumlarında hesabınızı güvende tutmak için Kurtarma E-Posta Adresi belirleyip Tamam butonuyla işlemi tamamlayın.

3. Yönetici Paneline Geçiş

Webmail’e giriş yaptıktan sonra gelen kutusu ve temel e-posta işlevlerini görebilirsiniz. Yeni kullanıcılar açmak veya alan adı bazlı yapılandırmalar yapmak için yönetici hesabınızla üst menüdeki “Daha” sekmesine tıklayın ve açılan menüden “Etki Alanı Ayarları” seçeneğini seçin.

4. Yeni E-Posta Hesabı Açma ve Kota Belirleme

Etki Alanı Ayarları kısmına erişim sağladıktan sonra yeni e-posta hesaplarını birkaç adımda aktif hale getirebilirsiniz:

1. Etki Alanı Ayarları ekranında sol menüde yer alan Hesaplar sekmesine gelin.
2. Üst paneldeki Yeni butonuna tıklayın.
3. Kullanıcı adını (örneğin muhasebe) girin ve parola gereksinimlerine uygun güçlü bir şifre belirleyip Kaydet butonuna basın.
4. Hesap oluştuktan sonra hesap listesinden ilgili kullanıcının ayarlarına girerek Posta Kutusu Boyut Sınırı MB alanından kullanıcıya özel ihtiyacınıza göre kota tanımlayın.

5. Posta Kutusu Taşıma

Eski sunucunuzda yer alan e-postaları manuel yedek alıp yüklemekle uğraşmadan, Xmail’in dahili senkronizasyon aracı ile doğrudan içeri aktarabilirsiniz:

1. Üst ana menüden Ayarlar sekmesine tıklayın.
2. Sol taraftaki menü listesinden Bağlantı seçeneğine gidin.
3. Ekranın sağında yer alan Posta Kutusu Taşıma alanındaki Taşı bağlantısına tıklayın.
4. Açılan pencerede tür olarak önceki hizmetinize göre tercihinizi yapıp eski sunucu adresinizi, portunu, e-posta adresinizi ve eski sunucudaki şifresini yazın.
5. Başla butonuna tıklayarak aktarımı başlatın. Eski mailleriniz arka planda kesintisiz olarak yeni kutunuza aktarılacaktır.

6. Mail Yönlendirme İşlemleri

Mevcut bir e-posta hesabına gelen iletilerin farklı bir adrese otomatik olarak yönlendirilmesini sağlayabilirsiniz:

1. Etki Alanı Ayarları ekranında sol menüden Hesaplar sekmesine tıklayın.
2. İşlem yapmak istediğiniz hesabı (örneğin muhasebe) seçin.
3. Sağ tarafta bulunan İletme panelindeki Otomatik Yönlendirmeyi Etkinleştir anahtarını aktif konuma getirin.
4. İletme Adresi alanına e-postaların aktarılacağı hedef adresi (örneğin yonlendirilecek@eposta.com) yazın.
5. İhtiyacınıza göre “İletildiğinde orijinal alıcıları koru” veya “Yönlendirildiğinde iletileri sil” seçeneklerini belirleyin.
6. Değişiklikleri uygulamak için üst menüdeki Kaydet butonuna tıklayın.

7. Kullanıcı Parolası Değiştirme

Kullanıcıların parolalarını yönetici paneli üzerinden hızlı ve güvenli bir şekilde güncelleyebilirsiniz:

1. Etki Alanı Ayarları > Hesaplar sekmesinden şifresini güncellemek istediğiniz kullanıcının üzerine tıklayın.
2. Üst paneldeki “Kaydet”, “İptal” ve “Sil” butonlarının yanında bulunan üç nokta (⋮) menü butonuna tıklayın.
3. Açılan açılır menüden Parolayı Değiştir seçeneğini seçin.
4. Açılan pencerede yeni güçlü parolayı belirleyip kaydedin.

The post İnetmar Kurumsal E-Posta Rehberi appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

1. Gerekli program

SQL Server Management Studio (SSMS) — Microsoft’un ücretsiz veritabanı yönetim aracı.

İndirme: Microsoft’un resmi sitesinden “SQL Server Management Studio download” araması ile ulaşabilirsiniz.

2. Bağlantı bilgileri

Bu bilgiler Plesk panelinizde Veritabanları bölümünde yer alır:

3. Bağlanma adımları

SSMS’i açtığınızda gelen Bağlan penceresinde:

1. Sunucu Adı alanına sunucu adresini yazın
2. Kimlik Doğrulaması olarak “SQL Server Kimlik Doğrulaması” seçin
3. Kullanıcı adı ve parolanızı girin
4. Veritabanı Adı alanına veritabanınızın adını yazın
5. Sunucu Sertifikasına Güven kutusunu işaretleyin
6. Bağlan butonuna basın

Önemli: Veritabanı Adı alanı

Bu alan boş bırakılmamalıdır. Güvenlik yapılandırmamız gereği, sunucudaki veritabanı listesi kullanıcılara kapalıdır — böylece hiçbir müşteri diğer müşterilerin veritabanlarını göremez. Veritabanı adını yazarak bağlandığınızda kendi veritabanınıza sorunsuz erişirsiniz.

Bu alan pencerede görünmüyorsa Seçenekler >> butonuna basarak genişletin.

Sertifika uyarısı alırsanız

“The certificate chain was issued by an authority that is not trusted” hatası alırsanız, Sunucu Sertifikasına Güven kutusunu işaretlemeyi atlamışsınız demektir. Kutuyu işaretleyip tekrar deneyin.

4. Çalışma yöntemi

Bağlandıktan sonra sol taraftaki Nesne Gezgini ağacında veritabanınız listelenmez. Bu normaldir ve yukarıda açıklanan güvenlik yapılandırmasından kaynaklanır.

İşlemlerinizi sorgu penceresi üzerinden yaparsınız:

• Üst menüden Yeni Sorgu (New Query) butonuna basın
• Sorgunuzu yazın
• F5 tuşu veya Yürüt (Execute) butonu ile çalıştırın

5. Temel sorgular

Hangi veritabanına bağlıyım?

Veritabanı adınızı döndürmelidir. Farklı bir şey dönerse bağlantıda veritabanı adını yazmayı atlamışsınız demektir.

SELECT DB_NAME();

Tablolarımı listele

SELECT TABLE_NAME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE = 'BASE TABLE'
ORDER BY TABLE_NAME;

Bir tablonun sütunlarını gör

SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH, IS_NULLABLE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'tablo_adiniz'
ORDER BY ORDINAL_POSITION;

Tablo içeriğini görüntüle

TOP 100 ilk 100 satırı getirir. Büyük tablolarda tamamını çekmek yerine bunu kullanmanız önerilir.

SELECT TOP 100 * FROM tablo_adiniz;

Kayıt sayısını öğren

SELECT COUNT(*) FROM tablo_adiniz;

Tüm tabloların kayıt sayılarını topluca gör

SELECT t.name AS tablo, SUM(p.rows) AS kayit_sayisi
FROM sys.tables t
JOIN sys.partitions p ON t.object_id = p.object_id
WHERE p.index_id IN (0, 1)
GROUP BY t.name
ORDER BY t.name;

Veritabanı boyutunu öğren

SELECT
name AS dosya,
size * 8 / 1024 AS boyut_mb
FROM sys.database_files;

Görünümleri (View) listele

SELECT TABLE_NAME
FROM INFORMATION_SCHEMA.VIEWS
ORDER BY TABLE_NAME;

Saklı yordamları (Stored Procedure) listele

SELECT name
FROM sys.procedures
ORDER BY name;

6. Tablo oluşturma ve düzenleme

Yeni tablo oluştur

CREATE TABLE musteriler (
id INT IDENTITY(1,1) PRIMARY KEY,
ad NVARCHAR(100) NOT NULL,
eposta NVARCHAR(150),
kayit_tarihi DATETIME DEFAULT GETDATE()
);

Sütun ekle

ALTER TABLE musteriler ADD telefon NVARCHAR(20);

Sütun sil

ALTER TABLE musteriler DROP COLUMN telefon;

Tablo sil

DROP TABLE musteriler;

Bu işlem geri alınamaz. Silmeden önce verilerinizi yedeklediğinizden emin olun.

7. Yedekleme

Veritabanınızın yedeğini Plesk paneli üzerinden alabilirsiniz: Veritabanları bölümünde ilgili veritabanının yanındaki dışa aktarma seçeneğini kullanın.

SSMS üzerinden komutla yedek alma yetkisi güvenlik gereği kısıtlıdır.

Verilerinizi SQL betiği olarak almak isterseniz sorgu sonuçlarını kopyalayabilir veya SSMS’in Sonuçları Dosyaya Kaydet özelliğini kullanabilirsiniz.

8. Sık karşılaşılan durumlar

9. Uygulama bağlantı dizesi

Web uygulamanızdan bağlanmak için kullanacağınız bağlantı dizesi örnekleri:

.NET / ASP.NET

Server=<sunucu_adresi>;Database=<veritabani_adi>;User Id=<kullanici>;Password=<parola>;TrustServerCertificate=True;

PHP (PDO)

$dsn = "sqlsrv:Server=<sunucu_adresi>;Database=<veritabani_adi>;TrustServerCertificate=True";
$pdo = new PDO($dsn, "<kullanici>", "<parola>");

Classic ASP (ADO)

Provider=SQLOLEDB;Data Source=<sunucu_adresi>;Initial Catalog=<veritabani_adi>;User Id=<kullanici>;Password=<parola>;

Bağlantı dizesinde veritabanı adını belirttiğiniz için uygulamalarınız bu kısıtlamadan etkilenmez.

10. Destek

Bağlantı veya yetki konusunda sorun yaşarsanız destek talebi açabilirsiniz. Talebinizde şunları belirtmeniz çözümü hızlandırır:

• Veritabanı adı
• Kullanıcı adı
• Aldığınız hata mesajının tam metni
• Hangi adımda hata aldığınız

The post MSSQL Veritabanı Bağlantı Ve Yönetim Rehberi appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

Kesintinin Kapsamı ve İlk Belirtiler

Kullanıcıların sosyal medya ve kesinti izleme platformu Downdetector üzerinden yaptığı yoğun şikayetlerin ardından Microsoft durumu ilk olarak yönetim merkezinde EX1464935 koduyla incelemeye aldı. Ancak incelemeler derinleştikçe problemin yalnızca Exchange Online ile sınırlı kalmadığı anlaşıldı. Şirket kapsamı genişleterek vakayı MO1465074 kodu altında kritik bir “hizmet kesintisi” olarak yeniden sınıflandırdı.

Etkilenen platformlar arasında iş dünyasının en kritik araçları yer aldı:

• Exchange Online / Outlook
• Microsoft Teams
• OneDrive for Business ve SharePoint Online
• Microsoft Purview
• Microsoft Defender XDR

Kullanıcılar Ne Tür Sorunlarla Karşılaştı?

Özellikle Exchange Online altyapısında hissedilen ve doğrudan iş akışlarını durma noktasına getiren başlıca problemler şunlar oldu:

• E-posta gönderim ve alımlarında ciddi gecikmeler ya da tamamen başarısız olan iletiler,
• Gelen kutusu içi aramalarda sonuçların gelmemesi veya eksik listelenmesi,
• Hizmetlere erişirken karşılaşılan kimlik doğrulama (oturum açma) hataları,
• Exchange yönetim merkezinde işlem yapılamaması ve yönetimsel kısıtlar,
• Posta kutusu senkronizasyonunda ve mesaj akış işleyişinde kesintili çalışma.

Sorunun Kaynağı Neydi?

Microsoft mühendisleri tarafından yapılan teknik incelemelerde, hatanın kimlik doğrulama ve protokol bağlantılarıyla ilişkili ortak bir sistemik modelden kaynaklandığı tespit edildi. Şirketten yapılan resmi açıklamada sorunun temel nedeninin Exchange Online altyapısındaki birden fazla dahili hizmet tarafından kullanılan temel kimlik doğrulama yapılandırmasındaki bir aksaklık olduğu belirtildi.

İyileştirme Süreci ve Son Durum

Kesintinin ilk sinyallerinin alınmasının ardından telemetri verilerini izleyen Microsoft aşamalı düzeltmeler uygulayarak sistemi toparlamaya başladı:

• 1 Eylül: İlk bildirimden yaklaşık 22 saat sonra yayımlanan güncellemelerde telemetrinin pozitif eğilime girdiği, ardından Exchange Online e-posta akışının ve arama işlevlerinin normale döndüğü aktarıldı.
• 2 Eylül: Şirket sistem düzeltmelerinin altyapıya yayılması sürecinde çok küçük bir kullanıcı kitlesinde geçici aksaklıklar görülebileceğini, ancak hizmet erişilebilirliğinin %99’un üzerine çıktığını ve kullanıcıların büyük çoğunluğu için krizin aşıldığını duyurdu.

İş Sürekliliği İçin Güvenilir Alternatifler Şart

Son dönemde benzer altyapı sorunlarıyla gündeme gelen Microsoft, bu son kesintiyle birlikte kurumsal bulut mimarisinde kimlik doğrulama bileşenlerinin ne derece kritik olduğunu bir kez daha gözler önüne serdi. İletişimin kesintisiz sürmesi gereken iş dünyasında, tek bir sağlayıcıya bağlı kalmak operasyonel riskleri de beraberinde getiriyor.

Küresel kesintilerden etkilenmeden iş süreçlerinizi kesintisiz yürütmek istiyorsanız, güçlü bir Microsoft 365 alternatifi arayışında olabilirsiniz. İnetmar ailesi olarak sektördeki 20 yıllık tecrübemizle işletmenize özel, yüksek erişilebilirlikli ve kesintisiz kurumsal e-posta çözümleri sunuyoruz. Üstelik hiçbir veri kaybı ve iş kesintisi yaşamadan geçiş yapabilmeniz için ücretsiz mail taşıma desteğimizle her adımda yanınızdayız.

The post Microsoft 365’te Küresel Kesinti! Kimlik Doğrulama Sorunları ve Kritik Servis Hataları Yaşandı! appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

Yandex’in işletmelere kendi alan adlarıyla e-posta hizmeti sunan ücretsiz planını sonlandırması, e-posta altyapısını Yandex üzerinden kullanan birçok işletmeyi yeni bir çözüm arayışına yöneltti.

Özellikle @sirketadi.com gibi kendi alan adıyla kurumsal e-posta kullanan işletmeler için bu değişiklik, yalnızca yeni bir ücretlendirme anlamına gelmiyor. E-posta hesaplarının, eski mesajların, DNS kayıtlarının ve kullanıcı bilgilerinin yeni bir altyapıya doğru şekilde taşınması da büyük önem taşıyor.

Peki Yandex’in ücretsiz kurumsal e-posta hizmetinde ne değişti? İşletmeler mevcut e-posta hesaplarını kullanmaya devam edebilecek mi? Yandex Mail yerine hangi alternatifler değerlendirilebilir?

Yandex Mail ücretsiz planı neden gündemde?

Yandex, uzun süredir işletmelerin kendi alan adları üzerinden e-posta hesapları oluşturmasına olanak sağlayan çözümler sunuyordu.

Bu hizmet sayesinde işletmeler, kendi alan adları üzerinden;

• info@sirketadi.com
• destek@sirketadi.com
• satis@sirketadi.com
• muhasebe@sirketadi.com

gibi profesyonel e-posta adresleri oluşturabiliyordu.

Ücretsiz planın özellikle küçük işletmeler ve yeni kurulan şirketler tarafından tercih edilmesinin en önemli nedenlerinden biri ise herhangi bir aylık kullanıcı maliyeti olmadan kurumsal alan adıyla e-posta kullanılabilmesiydi.

Ancak Yandex, 20 Mayıs 2026 itibarıyla Yandex 360 for Business’ın ücretsiz sürümünü sonlandırdı.

Bu değişiklikle birlikte ücretsiz sürüm üzerinden hizmet alan işletmelerin ücretli bir plana geçmesi veya alternatif bir e-posta altyapısına yönelmesi gerekiyor.

Yandex ücretsiz kurumsal e-posta hizmeti kaldırıldı mı?

Evet. Burada önemli olan nokta, Yandex’in tüm e-posta hizmetinin kapanmış olmaması.

Değişiklik özellikle işletmelerin kendi alan adlarıyla kullandığı ücretsiz Yandex 360 for Business sürümüyle ilgili.

Ücretsiz sürümden ücretli plana geçmeyen kullanıcılar için hesapların kullanımında çeşitli kısıtlamalar uygulanabiliyor. Bu nedenle işletmelerin mevcut e-posta altyapılarını ve önemli yazışmalarını kontrol ederek geçiş planını mümkün olduğunca erken oluşturması önem taşıyor.

Başka bir ifadeyle:

Yandex Mail kapanmadı ancak ücretsiz kurumsal e-posta seçeneği sona erdi.

Bu ayrım özellikle Yandex’i yıllardır kendi alan adıyla kullanan işletmeler açısından önemli.

Yandex Mail kullanan işletmeler ne yapmalı?

Yandex üzerinde kurumsal e-posta kullanan bir işletmeyseniz önünüzde temel olarak iki seçenek bulunuyor.

1. Yandex’in ücretli planına geçmek

İşletmeler Yandex 360’ın ücretli paketlerini değerlendirerek mevcut altyapılarını Yandex üzerinde kullanmaya devam edebilir.

Bu seçenek, mevcut sistemden ayrılmak istemeyen ve Yandex ekosistemini kullanmaya devam etmek isteyen işletmeler için değerlendirilebilir.

Ancak kullanıcı sayısı arttıkça aylık e-posta maliyetleri de işletmeler için önemli bir gider kalemine dönüşebilir.

2. Alternatif bir kurumsal e-posta hizmetine geçmek

Diğer seçenek ise mevcut e-posta hesaplarını farklı bir sağlayıcıya taşımak.

Özellikle yalnızca e-posta hizmetine ihtiyaç duyan işletmeler için kurumsal e-posta konusunda uzmanlaşmış alternatif sağlayıcılar değerlendirilebilir.

Burada en önemli konu ise sadece yeni bir e-posta hesabı açmak değil, mevcut e-posta verilerini güvenli şekilde taşımaktır.

E-posta sağlayıcısı değiştirirken nelere dikkat edilmeli?

Yandex’ten başka bir e-posta sağlayıcısına geçiş yapmayı düşünüyorsanız yalnızca fiyat karşılaştırması yapmak yeterli olmayacaktır.

Yeni e-posta hizmeti seçerken aşağıdaki kriterlere dikkat edilmesi gerekir.

Alan adı desteği

Kurumsal e-posta için en önemli konulardan biri kendi alan adınızı kullanabilmenizdir.

Örneğin işletmenizin alan adı sirketadi.com ise e-posta adresinizin de:

info@sirketadi.com

şeklinde olması profesyonel iletişim açısından önemlidir.

E-posta taşıma desteği

Yıllardır kullanılan bir e-posta hesabında binlerce mesaj, klasör ve ek dosya bulunabilir.

Bu nedenle yeni sağlayıcının mevcut e-postaların taşınması konusunda destek sunması büyük avantaj sağlar.

Geçiş sırasında;

• Gelen kutusu
• Gönderilmişler
• Taslaklar
• Özel klasörler
• E-posta ekleri
• Kullanıcı hesapları

gibi verilerin mümkün olduğunca eksiksiz aktarılması gerekir.

Antispam ve antivirüs koruması

Kurumsal e-posta hesapları her gün çok sayıda spam ve zararlı içerikli e-posta ile karşılaşabilir.

Bu nedenle yeni e-posta altyapısında güçlü antispam ve antivirüs filtrelerinin bulunması gerekir.

SPF, DKIM ve DMARC desteği

E-posta güvenliği açısından SPF, DKIM ve DMARC kayıtları artık kurumsal e-posta altyapısının önemli parçaları arasında yer alıyor.

Bu teknolojiler, alan adınız kullanılarak gönderilen sahte e-postaların önüne geçilmesine ve e-postaların teslim edilebilirliğinin iyileştirilmesine yardımcı olur.

Özellikle müşterileriyle yoğun e-posta trafiği gerçekleştiren işletmeler için doğru DNS ve e-posta güvenlik yapılandırması kritik önem taşır.

Teknik destek

E-posta sisteminde yaşanan bir problem doğrudan işletmenin iletişimini etkileyebilir.

Bu nedenle yalnızca fiyat avantajına değil, ihtiyaç halinde ulaşılabilecek teknik desteğe de dikkat edilmelidir.

Yandex’ten e-posta taşımak zor mu?

E-posta taşıma işlemi, kullanılan hesap sayısına ve mevcut altyapıya bağlı olarak değişiklik gösterir.

Bir veya birkaç e-posta hesabı olan küçük işletmeler için süreç daha kolay olabilirken, onlarca kullanıcıya sahip şirketlerde geçişin planlı yapılması gerekir.

Özellikle DNS kayıtlarının değiştirilmesi, MX kayıtlarının yeni sunucuya yönlendirilmesi, SPF/DKIM/DMARC yapılandırmasının yapılması ve eski e-postaların yeni sisteme aktarılması profesyonel şekilde gerçekleştirilmelidir.

Geçiş sırasında DNS kayıtlarının yanlış yapılandırılması, e-postaların alınamamasına veya gönderilen e-postaların karşı tarafa ulaşmamasına neden olabilir.

Bu nedenle işletmelerin geçiş işlemini aceleyle yapmak yerine kontrollü bir geçiş planı oluşturması önemlidir.

İnetmar Kurumsal E-Posta ile profesyonel e-posta altyapısı

Yandex’in ücretsiz kurumsal e-posta hizmetindeki değişiklik sonrasında alternatif arayan işletmeler için İnetmar Kurumsal E-Posta hizmeti değerlendirilebilir.

İnetmar’ın kurumsal e-posta altyapısı, işletmelerin kendi alan adları üzerinden profesyonel e-posta hesapları kullanmasına olanak sağlıyor.

Hizmet kapsamında;

• 100 GB’a kadar e-posta depolama
• Antispam koruması
• Antivirüs koruması
• SPF desteği
• DKIM desteği
• DMARC desteği
• Mobil ve masaüstü cihazlardan erişim
• Ücretsiz kurulum desteği
• Mevcut e-postaların taşınması
• 7/24 teknik destek
• %99,9 uptime

gibi özellikler sunuluyor.

Bu sayede işletmeler yalnızca yeni e-posta hesapları oluşturmakla kalmayıp mevcut e-posta altyapılarını da profesyonel bir sisteme taşıyabiliyor.

Yandex Mail’den İnetmar’a geçiş yapılabilir mi?

Evet. Yandex üzerinde bulunan mevcut kurumsal e-posta hesaplarının farklı bir e-posta altyapısına taşınması mümkündür.

Ancak geçişin sağlıklı şekilde yapılabilmesi için öncelikle mevcut e-posta hesaplarının ve alan adı DNS kayıtlarının incelenmesi gerekir.

Ardından yeni e-posta hesapları oluşturularak mevcut mesajların yeni sunucuya aktarılması ve gerekli DNS kayıtlarının güncellenmesi sağlanabilir.

Özellikle işletmenin e-posta iletişiminin kesintiye uğramaması için geçiş işleminin planlı şekilde gerçekleştirilmesi önemlidir.

İnetmar, Yandex’ten geçiş yapmak isteyen işletmelere ücretsiz kurulum ve e-posta taşıma desteği sunarak bu sürecin daha kolay yönetilmesine yardımcı oluyor.

Kurumsal e-posta için ücretsiz hizmetlere güvenmek ne kadar doğru?

Ücretsiz e-posta hizmetleri başlangıç aşamasındaki işletmeler için cazip olabilir.

Ancak işletmenin tüm müşteri iletişimi, teklifleri, siparişleri, faturaları ve önemli yazışmaları e-posta üzerinden gerçekleştirilmeye başladığında e-posta altyapısının önemi de artar.

Bir işletme için e-posta yalnızca mesaj gönderip almaktan ibaret değildir.

E-posta sisteminin;

• Güvenilir olması
• Spam filtrelemesi
• Yüksek erişilebilirlik sunması
• Alan adı ile çalışması
• Güvenlik standartlarını desteklemesi
• Teknik destek sağlaması
• Veri taşıma ve yedekleme seçeneklerine sahip olması

iş süreçlerinin kesintisiz devam etmesi açısından önemlidir.

Yandex’in ücretsiz kurumsal e-posta planında yaptığı değişiklik de işletmelere, kritik iş süreçlerinde kullanılan ücretsiz servislerin uzun vadeli maliyet ve sürdürülebilirlik açısından yeniden değerlendirilmesi gerektiğini gösteriyor.

Sonuç: Yandex Mail kullanıcıları için yeni dönem

Yandex’in ücretsiz kurumsal e-posta seçeneğini sonlandırması, özellikle kendi alan adıyla Yandex Mail kullanan küçük ve orta ölçekli işletmeler için yeni bir karar süreci başlatmış durumda.

İşletmeler mevcut sistemlerini ücretli Yandex planlarına taşıyabilir veya farklı bir kurumsal e-posta sağlayıcısını tercih edebilir.

Alternatif bir sağlayıcıya geçiş yapılacaksa yalnızca aylık fiyatı değil; e-posta taşıma desteği, depolama alanı, spam ve antivirüs koruması, SPF/DKIM/DMARC desteği, teknik destek ve hizmet sürekliliği gibi kriterleri de değerlendirmek gerekiyor.

Kendi alan adınızla profesyonel bir e-posta altyapısına geçmek ve Yandex’teki mevcut e-postalarınızı güvenli şekilde taşımak istiyorsanız, İnetmar Kurumsal E-Posta hizmetini inceleyebilirsiniz.

👉 İnetmar Kurumsal E-Posta: https://www.inetmar.com/kurumsal-e-posta/

Profesyonel e-posta altyapısı, güvenlik özellikleri ve taşıma desteği hakkında detaylı bilgi almak için İnetmar’ın kurumsal e-posta hizmetini inceleyebilirsiniz.

Sıkça Sorulan Sorular

Yandex Mail tamamen kapandı mı?

Hayır. Yandex Mail tamamen kapanmadı. Sonlandırılan hizmet, işletmelerin kendi alan adlarıyla kullanabildiği ücretsiz Yandex 360 for Business sürümüdür.

Yandex’in ücretsiz kurumsal e-posta hizmeti ne zaman sona erdi?

Yandex’in Türkiye destek sayfasına göre ücretsiz Yandex 360 for Business sürümü 20 Mayıs 2026 itibarıyla sona erdi.

Yandex Mail yerine ne kullanılabilir?

İşletmeler Yandex’in ücretli paketlerine geçebilir veya kendi alan adlarını destekleyen alternatif kurumsal e-posta sağlayıcılarını tercih edebilir.

Yandex’teki eski e-postalar başka sunucuya taşınabilir mi?

Evet. Uygun bir taşıma yöntemi kullanılarak mevcut e-posta mesajları ve klasörler yeni e-posta altyapısına aktarılabilir.

İnetmar Yandex’ten e-posta taşıyor mu?

Evet. İnetmar Kurumsal E-Posta hizmeti kapsamında mevcut e-postaların taşınması konusunda destek sunulmaktadır.

Kurumsal e-posta için neden kendi alan adımı kullanmalıyım?

Kendi alan adınızla oluşturulan e-posta adresleri işletmenizin daha profesyonel görünmesini sağlar ve marka kimliğinizin e-posta iletişiminde korunmasına yardımcı olur.

The post Yandex Mail Ücretsiz Dönemi Sona Erdi: İşletmeler Kurumsal E-Posta İçin Ne Yapmalı? appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

Dünyanın En Büyük GPU Ağı Cursor’ın Hizmetinde

Bu büyük satın almanın en dikkat çekici yanlarından biri, sağladığı donanım ve altyapı entegrasyonu. Anlaşma sayesinde Cursor, SpaceX’in elinde bulundurduğu devasa yapay zeka ve GPU ekosistemine tam erişim hakkı kazanıyor. Bu benzersiz donanım gücünün, Cursor’ın yeni nesil yapay zeka modellerini çok daha hızlı eğitmesine ve kullanıcılara maliyet açısından daha verimli çözümler sunmasına olanak tanıması bekleniyor.

Yapay zeka modellemelerinde ve veri işleme süreçlerinde güçlü bir sunucu altyapısına sahip olmak, tıpkı bu dev teknoloji şirketlerinin vizyonunda olduğu gibi kritik bir rol oynamaktadır. Siz de projelerinizi kesintisiz ve yüksek performansla hayata geçirmek isterseniz profesyonel AI Sunucu hizmetlerimizi inceleyebilirsiniz.

xAI Artık SpaceXAI: Grok 4.5 ve Grok 4.6 Sahneye Çıkıyor

Satın alma süreci, Elon Musk’ın yapay zeka girişimi xAI’ın SpaceX ile birleşerek “SpaceXAI” adını almasının hemen ardından gerçekleşti. Yeni çatı şirket SpaceXAI ile Cursor’ın ortaklaşa geliştirdiği ilk büyük yapıtaşı olan Grok 4.5 de bu süreçte duyuruldu. Bilgi odaklı analizler, otonom yapay zeka ajanları ve ileri düzey kodlama konularında üstün performans sergileyen model, önceki sürümlere kıyasla operasyonel maliyetleri ciddi oranda düşürmeyi başarıyor.

Grok 4.5’in hemen ardından tanıtılan Grok 4.6 ise çıtayı bir adım daha yukarı taşıyor. Sadece standart kod üretimiyle sınırlı kalmayan bu yeni model; web geliştirme, genel amaçlı yazılım mühendisliği ve bilgisayar destekli tasarım (CAD) gibi gerçek dünyanın karmaşık dinamiklerini çözümlemeye odaklanan, çok yönlü bir asistan olarak teknoloji dünyasındaki yerini alıyor.

The post SpaceX Cursor’u Satın Aldı! appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

Açığın en önemli özelliği, belirli WordPress sürümlerinde saldırganların herhangi bir kullanıcı hesabına ihtiyaç duymadan uzaktan kod çalıştırabilmesine (RCE) kadar ilerleyebilen bir saldırı zincirinin oluşturulabilmesi.

Üstelik söz konusu açık üçüncü parti bir eklentiden veya temadan kaynaklanmıyor. Doğrudan WordPress Core içerisinde yer alan iki farklı güvenlik açığının birlikte kullanılmasından oluşuyor.

Bu nedenle WordPress kullanan tüm site sahiplerinin sürümlerini kontrol etmesi ve gerekli güncellemeleri vakit kaybetmeden yapması önem taşıyor.

wp2shell Nedir?

wp2shell, iki farklı WordPress Core güvenlik açığının birlikte kullanılabildiği bir saldırı zincirini ifade ediyor:

• CVE-2026-63030: WordPress REST API içerisindeki batch endpoint ile ilgili bir route confusion güvenlik açığı
• CVE-2026-60137: WP_Query içerisindeki author__not_in parametresini etkileyen SQL Injection açığı

Bu açıkların birlikte kullanılması, saldırganların herhangi bir kullanıcı hesabına sahip olmadan WordPress sitelerine yönelik saldırılar gerçekleştirmesine ve saldırıyı daha ileri taşıyarak uzaktan kod çalıştırmasına olanak sağlayabiliyor.

Bu nedenle wp2shell, yalnızca bir WordPress eklentisinin güncellenmesiyle çözülebilecek sıradan bir güvenlik problemi değil, WordPress Core seviyesinde ele alınması gereken kritik bir güvenlik sorunu.

Saldırı Nasıl Gerçekleşebiliyor?

Saldırının teknik ayrıntılarına girmeden genel olarak süreç şu şekilde ilerliyor:

1. Saldırgan WordPress’in REST API’sine özel hazırlanmış bir istek gönderiyor.
2. REST API’deki güvenlik açığından yararlanılıyor.
3. SQL Injection açığı kullanılarak sistem üzerinde yetki elde edilmeye çalışılıyor.
4. Saldırgan yönetici seviyesine ulaşırsa WordPress üzerinden zararlı kod veya arka kapı yerleştirebiliyor.
5. Son aşamada site üzerinde yetkisiz işlemler gerçekleştirebiliyor.

Bu nedenle saldırganın ilk aşamada WordPress kullanıcı adı veya şifresini bilmesi gerekmeyebiliyor.

Hangi WordPress Sürümleri Risk Altında?

WordPress tarafından yayınlanan güvenlik güncellemeleriyle sorun giderildi.

Riskli sürümler:

• WordPress 6.9.0 – 6.9.4
• WordPress 7.0.0 – 7.0.1
• WordPress 6.8.0 – 6.8.5 sürümleri ise ilgili SQL Injection açığından etkileniyor.

Güvenli sürümler:

• WordPress 6.9.5
• WordPress 7.0.2
• WordPress 6.8.6

WordPress, açığın ciddiyeti nedeniyle etkilenen sürümlerde otomatik güvenlik güncellemelerini de devreye aldı.

Ancak sitenizin otomatik olarak güncellendiğini varsaymak yerine WordPress sürümünüzü kendiniz kontrol etmeniz önemlidir.

Mümkünse eski bir sürümde kalmak yerine WordPress’in desteklenen en güncel sürümünü kullanmanız önerilir.

WordPress Sitenizi Nasıl Koruyabilirsiniz?

1. WordPress’i Güncelleyin

İlk ve en önemli adım WordPress Core’u güncellemektir.

WordPress yönetim panelinizde:

Başlangıç → Güncellemeler

bölümünü kontrol ederek sitenizin güncel olup olmadığını görebilirsiniz.

2. Eklenti ve Temalarınızı Güncel Tutun

WordPress Core kadar eklenti ve temaların da güncel olması önemlidir. Kullanmadığınız veya uzun süredir güncellenmeyen eklentileri ve temaları kaldırmanız sitenizin genel saldırı yüzeyini azaltacaktır.

3. Yönetici Hesaplarınızı Kontrol Edin

WordPress panelinizde Kullanıcılar bölümünü kontrol edin. Tanımadığınız bir yönetici hesabı görürseniz hesabı hemen silin çünkü bilinmeyen bir yönetici hesabı, sitenizin daha önce ele geçirilmiş olduğuna dair önemli bir işaret olabilir.

4. Şüpheli Dosya ve Değişikliklere Dikkat Edin

Sitenizde aniden ortaya çıkan:

• Tanımadığınız PHP dosyaları
• Bilginiz dışında eklenen eklentiler
• Beklenmeyen yönlendirmeler
• Spam içerikler
• Değiştirilmiş tema veya site dosyaları

gibi durumlar fark ederseniz sitenizin güvenlik kontrolünden geçirilmesi gerekir.

5. Parolalarınızı Güçlü Tutun

WordPress yönetici hesabınızda güçlü ve benzersiz bir parola kullanın. Aynı parolayı WordPress, cPanel, FTP veya başka servislerde kullanmayın. Mümkün olan durumlarda iki aşamalı doğrulamayı (2FA) etkinleştirmeniz de hesabınızın güvenliğini önemli ölçüde artıracaktır.

Siteniz Daha Önce Saldırıya Uğramış Olabilir mi?

Burada önemli bir noktaya dikkat etmek gerekiyor:

WordPress’i bugün güncellemek, sitenizin daha önce saldırıya uğramadığını garanti etmez.

Eğer siteniz uzun süre boyunca savunmasız bir WordPress sürümü kullandıysa, saldırganlar güncellemeden önce sisteme erişmiş olabilir.

Bu nedenle güncelleme sonrasında da sitenizde;

• Bilinmeyen yönetici hesapları,
• Şüpheli eklentiler,
• Tanımadığınız dosyalar,
• Beklenmeyen yönlendirmeler,
• Spam içerikler,
• Anormal site davranışları

olup olmadığını kontrol etmek önemlidir.

Şüpheli bir durum fark ederseniz sitenizi temiz bir yedeğe döndürmek veya profesyonel bir güvenlik kontrolü yaptırmak gerekebilir.

WordPress Hosting Seçiminiz de Güvenlik Kadar Önemli

WordPress güvenliği yalnızca sitenin kendi ayarlarından ibaret değildir. Sitenin barındırıldığı sunucunun güvenlik altyapısı da oldukça önemlidir. 20 yılı aşkın sektör tecrübesine sahip İnetmar ailesi olarak WordPress siteleriniz için performans ve güvenliği birlikte hedefleyen hosting altyapıları sunuyoruz. Özellikle WordPress kullanıcıları için hazırladığımız Imunify360 destekli WordPress Hosting hizmetlerimiz ile sitelerinizi yalnızca barındırmakla kalmayıp, sunucu seviyesinde gelişmiş güvenlik katmanlarından da yararlanmanızı hedefliyoruz. WordPress siteniz için güvenli ve profesyonel bir hosting altyapısı arıyorsanız WordPress Hosting paketlerimizi tercih edebilirsiniz.

wp2shell, WordPress Core seviyesinde ortaya çıkan ve belirli sürümlerde saldırganların kimlik doğrulaması olmadan sistemlere erişmesine kadar ilerleyebilen kritik bir güvenlik açığıdır.

Bu nedenle WordPress kullanıcılarının:

Güncellemesi → Kontrol etmesi → Güvenli bir hosting altyapısı kullanması

büyük önem taşıyor.

Özellikle WordPress siteniz eski bir sürüm kullanıyorsa güncellemeyi ertelemeyin.

Unutmayın:

Güncel WordPress + güncel eklenti ve temalar + güçlü parolalar + güvenli hosting altyapısı = daha güvenli bir web sitesi

Sitenizin güvenliği konusunda herhangi bir şüpheniz varsa profesyonel destek almaktan çekinmeyin.

The post wp2shell (CVE-2026-63030): WordPress’i Sarsan Kritik RCE Zafiyeti ve Korunma Yolları! appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.

Veri size ait değilse, işiniz de tam olarak size ait değildir. Kendi VDS altyapınız üzerinde bir mail sunucusu kurmak; bağımsızlıktır, güvenliktir ve uzun vadede devasa bir maliyet avantajıdır.

Fakat e-posta mimarisi, internetin en eski, kuralcı ve karmaşık sistemlerinden biridir. Bu yazımızda “şu kodu yaz geç” demek yerine sektörü domine eden en modern araçlarla, hata payı bırakmayan bir mühendislik yaklaşımıyla ilerliyoruz. Karmaşık IPv6 protokollerini bir kenara bırakıp, saf IPv4 gücüyle, sorunsuz teslimat oranlarına (10/10) ulaşacağınız o muazzam sistemi kurmaya başlıyoruz.

Altyapı ve DNS

İlk olarak mail sunucusu kurarken başarının %50’si sunucu konfigürasyonunda, geri kalan %50’si ise ağ altyapınızın temizliğindedir. Blacklist’e girmemiş, port kısıtlaması olmayan ve IP itibarı yüksek bir sunucu şarttır. E-posta trafiğinizin belkemiğini oluşturacak, %100 NVMe SSD performansına ve kusursuz ağ izolasyonuna sahip VDS paketlerimizi inceleyerek projenize sağlam bir temel atabilirsiniz.

DNS Kayıtları

Sunucuya SSH ile girmeden önce DNS yöneticiniz üzerinden kayıtları açın.

• A Kaydı: mail.siteniz.com -> VDS_IP_Adresi
• MX Kaydı: siteniz.com -> mail.siteniz.com (Öncelik: 10)

PTR (Reverse DNS) Kaydı Neden Hayatidir?

Normal DNS (A kaydı), “Bu alan adı hangi IP’ye gidiyor?” sorusunu cevaplar. PTR kaydı ise karşı tarafın size sorduğu şu sorunun cevabıdır: “Bu IP adresi kime ait?” Eğer Gmail IP’nizi sorguladığında boş bir cevap görürse, mailinizi direkt reddeder. inetmar.com müşteri panelinizde bulunan **Hizmetlerim > IP Adreslerim** bölümünden IP adresinizin PTR kaydını mail.siteniz.com olarak mutlaka güncelleyin.

Ana Bileşenlerin Kurulumu ve İzolasyon

Sunucumuza root olarak bağlanıyoruz. Ubuntu 24.04 LTS üzerinde sistemimizi güncelleyip Postfix ve Dovecot yazılımlarımızı kuruyoruz.

Bu kurulumda e-posta imzalama ve spam filtreleme işlemleri için eski nesil yazılımlar yerine modern, C++ tabanlı ve düşük kaynak tüketimi sunan Rspamd ve Redis kullanacağız:

apt update && apt upgrade -y
apt install postfix postfix-pcre dovecot-imapd dovecot-lmtpd redis-server rspamd certbot nginx -y

(Postfix kurulum ekranı geldiğinde “Internet Site” seçeneğiyle ilerleyin ve Sistem Mail Adı olarak siteniz.com girin.)

Sistem Kullanıcılarını Ayırmak

Mail kullanıcıları ile sunucu kullanıcılarını aynı tutmak güvensiz bir yöntemdir. Bunun için tüm mailleri diskte tutacak yetkisiz tek bir sanal kullanıcı (vmail) oluşturuyoruz:

useradd -m -s /usr/sbin/nologin -G mail vmail
mkdir -p /home/vmail/Mail/Inbox
chown -R vmail:vmail /home/vmail/Mail

Postfix (MTA) ve Dovecot (MDA) Entegrasyonu

Postfix

/etc/postfix/main.cf dosyasını yapılandırıyoruz. Amacımız IPv4 kullanımını zorunlu kılmak, dışarıdan gelen SMTP yetkilendirmelerini Dovecot’a devretmek ve şifresiz veri akışını yasaklamak. Ayrıca Postfix’i yeni nesil filtremiz Rspamd’ye bağlıyoruz.

inet_protocols = ipv4
# Şifreler ağda düz metin dolaşmasın, TLS zorunlu olsun:
smtpd_tls_auth_only = yes

# Yetkilendirmeyi Dovecot yapsın:
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes

# Hangi e-posta adresi hangi kullanıcıya ait haritası:
virtual_alias_maps = hash:/etc/postfix/virtual

# Rspamd (DKIM ve Anti-Spam) Entegrasyonu:
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:11332
non_smtpd_milters = inet:localhost:11332

E-posta adreslerimizi /etc/postfix/virtual dosyasına tanımlıyoruz:

admin@siteniz.com   vmail
info@siteniz.com    vmail

Sisteme bu dosyayı okutmak için hash’liyoruz: postmap /etc/postfix/virtual

Dovecot

Maillerin webmail’den okunabilmesi için Dovecot’u yapılandırıyoruz. /etc/dovecot/dovecot.conf dosyasını açın:

ssl = required
# Şifrelerin tutulacağı özel dosya:
passdb {
  driver = passwd-file
  args = scheme=CRYPT /etc/dovecot/users
}
userdb {
  driver = passwd-file
  args = /etc/dovecot/users
}
# Postfix'in Dovecot üzerinden doğrulama yapabilmesi için güvenli soket:
service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

/etc/dovecot/users dosyasını oluşturun. Şifrelerinizi Linux üzerinde doveadm pw -s CRYPT komutuyla şifreleyerek bu dosyaya admin@siteniz.com:{CRYPT}$2y$... formatında ekleyin. Dosya izinlerini chmod 644 /etc/dovecot/users olarak ayarlayın.

SPF, Rspamd ile DKIM, DMARC

Maillerinizin doğrudan spame düşmemesi için bu kayıtları kusursuz yapılandırmalısınız.

1. SPF (Sender Policy Framework): DNS ayarlarınız üzerinden TXT kaydı ekleyin:
v=spf1 mx a:mail.siteniz.com ip4:VDS_IPv4_Adresiniz -all

2. DKIM İmzalama:
Sunucumuzda alan adımız için DKIM anahtarımızı üretiyoruz:

mkdir -p /var/lib/rspamd/dkim/
rspamadm dkim_keygen -b 2048 -s mail -k /var/lib/rspamd/dkim/mail.private > /var/lib/rspamd/dkim/mail.txt
chown -R _rspamd:_rspamd /var/lib/rspamd/dkim/
chmod 600 /var/lib/rspamd/dkim/mail.private

Rspamd’ye bu anahtarı kullanmasını söylüyoruz. /etc/rspamd/local.d/dkim_signing.conf dosyasını oluşturup içine şunu yazın:

allow_username_mismatch = true;
domain {
    siteniz.com {
        path = "/var/lib/rspamd/dkim/mail.private";
        selector = "mail";
    }
}

Ardından servisi yeniden başlatın: systemctl restart rspamd.
Oluşturulan /var/lib/rspamd/dkim/mail.txt dosyasını açın. İçindeki uzun metni yani anahtarı DNS ayarlarınızın bulunduğu panelde mail._domainkey adıyla TXT kaydı olarak ekleyin.

3. DMARC:
DNS ayarlarınıza TXT kaydı olarak _dmarc adıyla şunu ekleyin:
v=DMARC1; p=quarantine; rua=mailto:admin@siteniz.com; fo=1

Roundcube & Docker

Güvenlik açıklarını ana sisteme sıçratmamak için Webmail arayüzümüzü Docker ile kuruyoruz. Bir dizin açın ve docker-compose.yml dosyası oluşturun:

services:
  roundcube:
    image: roundcube/roundcubemail:latest-apache
    ports:
      - "127.0.0.1:8080:80"
    environment:
      - ROUNDCUBEMAIL_DEFAULT_HOST=tls://VDS_IPv4_Adresiniz
      - ROUNDCUBEMAIL_SMTP_SERVER=tls://VDS_IPv4_Adresiniz

docker compose up -d ile arayüzü ayağa kaldırın.

Nginx ve SSL Entegrasyonu

Roundcube şu an sadece 8080 portunda çalışıyor. Let’s Encrypt ile ücretsiz SSL alıyoruz: certbot certonly --standalone -d mail.siteniz.com

Nginx /etc/nginx/sites-available/mail.siteniz.com dosyasını ayarlayarak 443 (HTTPS) üzerinden gelen trafiği güvenli şekilde Docker’a proxy’liyoruz:

server {
    listen 443 ssl;
    server_name mail.siteniz.com;
    ssl_certificate /etc/letsencrypt/live/mail.siteniz.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mail.siteniz.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Aktifleştirip systemctl reload nginx komutunu verdiğinizde webmail arayüzünüz yayındadır!

UFW, Fail2ban ve SRS

Nasıl ki kritik bir Sanal POS entegrasyonu için sunucunuzda IP izinlerini ince ince ayarlayıp, PowerShell üzerinden bağlantının sağlıklı kurulduğunu milimetrik olarak teyit ediyorsanız; mail sunucusunda da açtığınız her portun tam olarak ne işe yaradığını aynı ciddiyetle bilmelisiniz.

Sadece gerekli olan IPv4 portlarını açıyoruz:

ufw allow 22/tcp
ufw allow 25/tcp
ufw allow 143/tcp
ufw allow 443/tcp
ufw allow 465/tcp
ufw allow 587/tcp
ufw allow 993/tcp
ufw enable

Brute-Force Koruması: systemctl enable --now fail2ban ile servisi etkinleştirin. Gerekirse şifre deneme yanılma yapan botları engellemek için postfix filtrelerini aktif edebilirsiniz.

Forwarding ve SRS

info@siteniz.com adresine gelen mailleri kişisel Gmail’inize yönlendirirseniz, orijinal göndericinin SPF kaydı sizin sunucu IP’nizle eşleşmeyeceği için Gmail maili anında reddeder.

Bunu SRS (Sender Rewriting Scheme) ile çözüyoruz.
apt install postsrsd -y komutuyla paketi kurun. Postfix main.cf dosyasına şu bloğu ekleyin:

# SRS - Forward edilen mailler için Envelope Rewrite
sender_canonical_maps = tcp:127.0.0.1:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:127.0.0.1:10002
recipient_canonical_classes = envelope_recipient,header_recipient

Bu ayar sayesinde yönlendirilen mailin “Gönderen” (Envelope Sender) bilgisi sizin alan adınıza çevrilir, kendi SPF’inizden geçer ve Gmail’in Inbox’ına sorunsuz düşer. Postfix’i yeniden başlatın (systemctl reload postfix).

Uçtan Uca Webmail Testi ve Troubleshooting

Sistemi kurduk, servisler yeşil yanıyor. Şimdi doğrulama vakti.

Webmail Arayüzüne Giriş

Tarayıcınızı açın ve https://mail.siteniz.com adresine gidin.

• Kullanıcı Adı: admin@siteniz.com (Domain ile birlikte tam e-posta adresini yazmalısınız).
• Parola: Belirlediğiniz parola ile giriş yapın.

İlk Maili Gönderme ve Gmail’de Analiz

Sol üstten “Oluştur” butonuna tıklayın. Kişisel Gmail adresinize bir test maili gönderin.
Mail Gmail kutunuza düştüğünde, maili açın, sağ üstteki üç noktaya tıklayıp “Aslını Göster” (Show Original) seçeneğine tıklayın.

İşte tüm o emeğin karşılığını burada, Rspamd’nin kusursuz imzalarıyla göreceğiz:

• SPF: PASS (IP adresiniz siteniz.com adına başarıyla yetkilendirildi)
• DKIM: PASS (Rspamd imzanız doğrulandı)
• DMARC: PASS (Kurallarınız başarıyla işletildi)

İçeriye Mail Alma ve Nihai Skor

Kişisel Gmail hesabınızdan, kendi sunucunuzdaki admin@siteniz.com adresinize mail göndererek içeriye alımı test edin.
Sonrasında hatalarımızı görmek için https://mail-tester.com adresine gidin. Verilen geçici adrese Roundcube üzerinden mail gönderin.

Adımları eksiksiz uyguladıysanız, temiz bir IP altyapısı üzerinde o muazzam 10/10 skorunu göreceksiniz!

Kendi mail sunucunuzu kurmak bir vizyon meselesidir. Rspamd gibi yeni nesil araçları kullanarak sistemi modern mimariye uygun şekilde inşa etmek, size ömür boyu sürecek bir dijital özgürlük, yüksek performans ve eşsiz bir gizlilik sunar.

Doğru konfigüre edilmiş bir sistem ve güçlü bir VDS altyapısı birleştiğinde, iletişiminiz üzerinde %100 kontrol sahibi olduğunuz, güvenilir ve stabil bir yapıya kavuşursunuz. Kurumsal iletişiminizin kalbini oluşturacak, ağ kısıtlamalarından uzak, performanslı VDS Sunucu çözümlerimizi inceleyerek bu dijital bağımsızlık yolculuğunda en sağlam adımı atabilirsiniz.

The post Mail Sunucusu Nasıl Kurulur? Mail Sunucusu Kurma appeared first on inetmar Hosting & Teknoloji Blog Haber Sayfası.