Mailcow ile SPF, DKIM ve DMARC Ayarlarını Doğru Yapma Rehberi

Mailcow, kendi e-posta altyapısını yöneten kurumlar için güçlü ve esnek bir platformdur. Ancak iletilerin alıcı sunucular tarafından güvenilir kabul edilmesi yalnızca sunucunun çalışıyor olmasıyla sağlanmaz. SPF, DKIM ve DMARC kayıtlarının doğru kurgulanması; teslim edilebilirlik, alan adı itibarı ve sahtecilik önleme açısından kritik önemdedir. Bu üç mekanizma birlikte çalıştığında, gönderici kimliğinin doğrulanması kolaylaşır ve e-postaların spam klasörüne düşme riski azalır. Özellikle kurumsal yapılarda, teknik ayarların eksiksiz yapılması kadar düzenli kontrol edilmesi de gerekir.

Mailcow kullanan sistem yöneticileri için en yaygın hata, DNS kayıtlarını eklemekle sürecin tamamlandığını düşünmektir. Oysa kayıtların sözdizimi, gönderim yapan sistemlerin kapsamı, selector kullanımı, alt alan adları ve raporlama politikaları birlikte ele alınmalıdır. Aşağıda, SPF, DKIM ve DMARC ayarlarını Mailcow ortamında doğru şekilde yapılandırmak için uygulanabilir ve net bir rehber bulabilirsiniz.

SPF kaydını doğru planlama ve yayınlama

SPF, hangi sunucuların alan adınız adına e-posta göndermeye yetkili olduğunu tanımlayan DNS kaydıdır. Mailcow kurulu bir sunucudan doğrudan gönderim yapıyorsanız, SPF kaydınızda bu sunucunun IP adresi veya ilgili gönderim altyapısı açık biçimde yer almalıdır. En temel yaklaşım, alan adınızın DNS bölgesine bir TXT kaydı ekleyerek v=spf1 ile başlayan bir ifade tanımlamaktır. Burada amaç, yetkili kaynakları eksiksiz belirtmek ve yetkisiz kaynakları reddetmektir. Eksik veya fazla geniş tanımlanmış SPF kayıtları, hem teslim sorunlarına hem de güvenlik açıklarına yol açabilir.

Pratik bir örnek olarak, yalnızca Mailcow sunucunuz üzerinden gönderim yapıyorsanız kayıt yapısı çoğu durumda “v=spf1 mx -all” veya sunucu yapınıza göre “v=spf1 ip4:SERVER_IP -all” biçiminde hazırlanabilir. Eğer harici bir bülten servisi, ERP sistemi veya bulut tabanlı uygulama da aynı alan adıyla gönderim yapıyorsa, bunların SPF kapsamına dikkatle eklenmesi gerekir. SPF’te birden fazla include kullanmak mümkündür; ancak gereksiz eklemeler DNS sorgu sınırını zorlayabilir. Uygulamada şu kontroller faydalıdır:

• Alan adınız için yalnızca tek bir SPF TXT kaydı bulunduğunu doğrulayın.
• Gönderim yapan tüm sistemleri envanter halinde çıkarın.
• Önce yumuşak politika yerine net yapı kurun; belirsiz geçiş ayarlarını uzun süre bırakmayın.
• MX kaydı kullanıyorsanız, gerçekten Mailcow sunucusuna işaret ettiğinden emin olun.

Mailcow tarafında yapılan teknik değişikliklerden sonra test iletileri göndererek üst bilgileri kontrol etmek önemlidir. SPF pass sonucu almanız yeterli değildir; kullanılan Return-Path alanının da doğru alan adıyla ilişkili olması gerekir. Özellikle farklı uygulamalar SMTP kimlik bilgilerini kullansa bile kendi zarf gönderici adreslerini farklılaştırabilir. Bu nedenle SPF değerlendirmesi, sadece görünen From adresine bakılarak değil, sunucu başlıkları incelenerek teyit edilmelidir.

DKIM imzalama yapısını Mailcow üzerinde sağlıklı kurma

DKIM anahtar üretimi ve DNS selector mantığı

DKIM, iletinin belirli bölümlerini kriptografik olarak imzalayarak içerik bütünlüğünü ve alan adı ilişkisini doğrular. Mailcow yönetim paneli üzerinden alan adı bazında DKIM anahtarı üretilebilir ve sistem size eklemeniz gereken DNS kaydını sunar. Burada dikkat edilmesi gereken konu selector bilgisidir. Selector, aynı alan adı için birden fazla DKIM anahtarının yönetilebilmesini sağlar. Örneğin anahtar yenileme sırasında eski ve yeni selector bir süre birlikte kullanılabilir. DNS’e eklenen TXT kaydındaki public key değerinin eksiksiz ve satır bozulması olmadan yapıştırılması gerekir.

Kurumsal ortamlarda 2048 bit anahtar kullanımı tercih edilir. DNS sağlayıcınız uzun TXT kayıtlarını destekliyorsa bu yapı daha güvenli bir seçenek sunar. Anahtar üretildikten sonra yalnızca DNS kaydının eklenmesi değil, Mailcow’un ilgili alan adı için imzalama yaptığının da kontrol edilmesi gerekir. Test e-postalarında DKIM-Signature başlığının varlığı ve alıcı tarafta “dkim=pass” sonucu bu doğrulamayı sağlar.

Yaygın DKIM hataları ve önleme yöntemleri

DKIM tarafında en sık karşılaşılan sorunlardan biri, DNS kaydının yanlış host adına eklenmesidir. Kayıt doğrudan ana alana değil, selector._domainkey biçimindeki alt kayıt adına yazılmalıdır. Ayrıca bazı DNS panelleri tırnak işaretlerini otomatik eklerken bazıları eklemez; bu farklar nedeniyle kopyalama sırasında bozulma yaşanabilir. Mailcow üzerinde alan adı ekli olsa bile, dışarıdan geçen iletilerin bir relay veya güvenlik katmanı tarafından değiştirilmesi durumunda imza geçersiz hale gelebilir.

Bu nedenle konu satırına etiket ekleyen, dipnot enjekte eden veya iletinin gövdesini yeniden biçimlendiren ara sistemler varsa bunlar dikkatle incelenmelidir. İdeal yaklaşım, Mailcow’dan çıkan iletinin son aşamada imzalanması ve sonrasında içeriğe müdahale edilmemesidir. DKIM başarısız olduğunda yalnızca teslim problemi değil, DMARC uyumsuzluğu da ortaya çıkabilir. Bu yüzden DKIM’i bağımsız değil, bütün e-posta kimlik doğrulama zincirinin bir parçası olarak yönetmek gerekir.

DMARC politikası, hizalama ve operasyonel kontrol

DMARC, SPF ve DKIM sonuçlarını alan adı hizalamasıyla birlikte değerlendirerek alıcı sunucuya nasıl davranacağını söyler. Mailcow kullanan kurumlar için DMARC’ın asıl değeri, yalnızca sahteciliği azaltması değil, yanlış yapılandırmaları görünür hale getirmesidir. DNS’e eklenen DMARC kaydı _dmarc alt alanında TXT olarak tanımlanır. Başlangıçta “p=none” politikası ile rapor toplamak, mevcut gönderim kaynaklarını görmek için güvenli bir adımdır. Ancak bu geçiş durumunun kalıcı hale gelmesi önerilmez; sistem doğrulandıktan sonra politika daha sıkı hale getirilmelidir.

Hizalama konusu özellikle önemlidir. SPF pass olsa bile, doğrulanan alan adı görünen From alanıyla uyumlu değilse DMARC başarısız olabilir. Aynı şekilde DKIM imzası farklı bir alan adıyla atılmışsa sonuç yine olumsuz olacaktır. Bu nedenle Mailcow üzerinden gönderilen iletilerde From alanı, DKIM d= değeri ve SPF değerlendirmesinde kullanılan alan birbiriyle uyumlu olacak şekilde tasarlanmalıdır. Uygulamada izlenebilecek sıra şöyledir:

• Önce SPF ve DKIM sonuçlarının ayrı ayrı geçerli olduğunu doğrulayın.
• Ardından DMARC kaydını p=none ile yayınlayın ve raporları izleyin.
• Yetkisiz veya beklenmeyen kaynakları temizledikten sonra politikayı p=quarantine seviyesine çıkarın.
• Altyapı tamamen kontrol altına alındığında p=reject politikasını değerlendirin.

Raporlama adreslerinin aktif olarak izlenmesi de önemlidir. DMARC raporları çoğu zaman teknik ayrıntı içerir; ancak hangi IP’lerin alan adınızı kullanarak gönderim yaptığını tespit etmek için çok değerlidir. Yeni bir uygulama devreye alındığında, SMTP üzerinden gönderim yetkisi verilmeden önce SPF ve DKIM uyumu test edilmelidir. Böylece ileride yaşanacak teslim sorunları operasyonu etkilemeden önlenebilir. Sonuç olarak Mailcow üzerinde doğru SPF, DKIM ve DMARC yapılandırması; yalnızca teknik bir kurulum adımı değil, kurumsal e-posta güvenliğinin sürdürülebilir temelidir. Düzenli gözden geçirme, kayıtların sade tutulması ve test süreçlerinin standartlaştırılması, bu yapının uzun vadede sorunsuz işlemesini sağlar.