Mail subdomaini için ayrı güvenlik kayıtları gerekir mi?

Mail trafiğini ana alan adından ayrı bir subdomain üzerinden yönetmek, özellikle kurumsal e-posta altyapılarında sık görülen bir tercihtir. Ancak “mail.example.com” gibi bir subdomain kullanıldığında DNS tarafındaki güvenlik kayıtlarının nasıl ele alınacağı çoğu zaman karışır. Yanlış veya eksik yapılandırma; iletilerin spam klasörüne düşmesine, kimlik doğrulama hatalarına ve alan adının itibar kaybetmesine neden olabilir.

Mail subdomaini ayrı bir kimlik gibi değerlendirilir mi?

DNS açısından her subdomain kendi kayıtlarına sahip olabilir. Bu nedenle mail subdomaini, teknik olarak ana alan adından bağımsız bazı doğrulama kayıtları gerektirebilir. Burada belirleyici nokta, e-postanın hangi alan adıyla gönderildiği ve alıcı sunucuların hangi kayıtlara bakacağıdır.

Örneğin kullanıcılarınız hosting altyapınız üzerinden “[email protected]” adresiyle e-posta gönderiyorsa, SPF, DKIM ve DMARC kontrolleri çoğunlukla “example.com” alan adı üzerinden değerlendirilir. Ancak gönderim “[email protected]” şeklindeyse veya DKIM imzasında subdomain kullanılıyorsa, mail subdomaini için ayrı kayıtlar gerekir.

Hangi güvenlik kayıtları kontrol edilmelidir?

E-posta güvenliği yalnızca bir MX kaydı eklemekten ibaret değildir. Teslim edilebilirlik ve alan adı itibarı için SPF, DKIM, DMARC ve gerekiyorsa TLS ile ilgili kayıtların doğru kurgulanması gerekir.

SPF kaydı

SPF, hangi sunucuların ilgili alan adı adına e-posta gönderebileceğini belirtir. Ana alan adınız için SPF kaydı varsa, bu kayıt otomatik olarak tüm subdomainleri kapsamaz. “mail.example.com” adına gönderim yapılıyorsa, bu subdomain için ayrıca SPF TXT kaydı tanımlanmalıdır.

En sık yapılan hata, birden fazla SPF kaydı oluşturmaktır. Bir alan adı veya subdomain için yalnızca tek SPF TXT kaydı bulunmalıdır. Birden fazla servis kullanılıyorsa bunlar aynı kayıt içinde “include” yapılarıyla birleştirilmelidir.

DKIM kaydı

DKIM, gönderilen e-postanın değiştirilmediğini ve yetkili bir sistemden çıktığını doğrular. DKIM kayıtları genellikle “selector._domainkey.example.com” biçimindedir. Eğer e-posta servisiniz DKIM imzasını mail subdomaini altında üretiyorsa, kayıt da “selector._domainkey.mail.example.com” şeklinde tanımlanmalıdır.

Burada dikkat edilmesi gereken nokta, panelde verilen DKIM kaydını ezbere ana alan adına eklememektir. Servisin belirttiği tam DNS adı kontrol edilmeli, özellikle selector ve subdomain bölümü eksiksiz girilmelidir.

DMARC kaydı

DMARC, SPF ve DKIM sonuçlarına göre alıcı sunucuya nasıl davranması gerektiğini söyler. Ana alan adındaki DMARC politikası, varsayılan olarak subdomainleri de etkileyebilir; ancak “sp” etiketiyle subdomain politikası ayrıca belirlenebilir. Daha kontrollü bir yapı isteniyorsa mail subdomaini için “_dmarc.mail.example.com” altında ayrı DMARC kaydı tanımlanabilir.

Kurumsal yapılarda önerilen yaklaşım, önce “p=none” ile raporlama toplamak, ardından hatalar giderildikten sonra “quarantine” veya “reject” politikasına geçmektir. Bu geçiş acele yapılırsa meşru e-postaların reddedilmesi gibi ciddi operasyonel sorunlar yaşanabilir.

MX kaydı ile güvenlik kayıtları karıştırılmamalı

MX kaydı, e-postanın hangi sunucuya teslim edileceğini gösterir. SPF, DKIM ve DMARC ise gönderici doğrulaması ve güvenlik politikasıyla ilgilidir. Bir mail subdomaininin MX kaydının olması, güvenli şekilde e-posta gönderebildiği anlamına gelmez.

Özellikle hosting paneli üzerinden otomatik DNS oluşturulduğunda, MX kaydı eklenmiş olsa bile SPF veya DKIM kayıtları eksik kalabilir. Panelde “mail hizmeti aktif” görünmesi, tüm doğrulama kayıtlarının doğru çalıştığını garanti etmez.

Ayrı kayıt gerekip gerekmediği nasıl anlaşılır?

Karar verirken şu pratik kontrol listesi kullanılabilir:

• E-posta adresleri “@mail.example.com” ile bitiyorsa subdomain için ayrı kayıt gerekir.
• Gönderim sunucusu HELO/EHLO olarak “mail.example.com” kullanıyorsa SPF uyumu kontrol edilmelidir.
• DKIM imzasında “d=mail.example.com” görünüyorsa DKIM kaydı subdomain altında olmalıdır.
• DMARC raporlarında subdomain kaynaklı hata varsa ayrı politika tanımlamak gerekebilir.
• Yalnızca gelen posta için “mail.example.com” MX hedefi kullanılıyorsa, gönderim kimliği ayrıca incelenmelidir.

Bu kontroller, DNS kayıtlarını gereksiz yere çoğaltmadan doğru noktaya müdahale etmeyi sağlar. Gereksiz TXT kayıtları eklemek bazen çözüm üretmek yerine doğrulama zincirini daha karmaşık hale getirir.

Sunucu ve DNS tarafında sık yapılan hatalar

Birçok teslimat problemi, kayıtların yanlış değerde değil yanlış yerde oluşturulmasından kaynaklanır. DNS panelinde “mail” adına kayıt girerken bazı paneller tam alan adını otomatik tamamlar. Bu durumda “mail.example.com” yazmak, farkında olmadan “mail.example.com.example.com” gibi hatalı bir kayıt oluşturabilir.

Bir diğer hata, TTL süresini dikkate almadan test yapmaktır. DNS değişiklikleri her yerde aynı anda görünmez. Kayıt güncellendikten sonra kısa süre içinde yapılan testler eski bilgiyi döndürebilir. Bu nedenle değişiklik sonrası yayılım süresi hesaba katılmalıdır.

Paylaşımlı sunucu kullanan yapılarda ise e-posta gönderim IP’si değişebilir. SPF kaydında IP adresi elle yazıldıysa, servis sağlayıcının önerdiği “include” değeri tercih edilmelidir. Böylece altyapı değişiklikleri olduğunda kayıt daha sürdürülebilir kalır.

Kurumsal kullanım için önerilen yaklaşım

Mail subdomaini aktif kullanılıyorsa kayıtlar dokümante edilmeli, hangi servisin hangi DNS kaydına ihtiyaç duyduğu net şekilde tutulmalıdır. SPF tekilleştirilmeli, DKIM selector değerleri servis bazında ayrılmalı ve DMARC raporları düzenli izlenmelidir.

Yeni bir e-posta servisi devreye alınmadan önce test kullanıcılarıyla sınırlı gönderim yapmak iyi bir yöntemdir. Böylece spam puanı, kimlik doğrulama sonucu ve alıcı tarafındaki hata mesajları operasyonu etkilemeden incelenebilir. Özellikle farklı pazarlama, CRM ve destek sistemleri aynı alan adı adına gönderim yapıyorsa bu kontrol kritik hale gelir.

Mail subdomaini için ayrı güvenlik kayıtlarının gerekip gerekmediği, alan adının nasıl kullanıldığına bağlıdır. Gönderim kimliği subdomain üzerinden kuruluyorsa ayrı SPF, DKIM ve gerekirse DMARC kaydı tanımlanmalıdır; yalnızca yönlendirme veya gelen posta amacıyla kullanılıyorsa kayıt ihtiyacı daha sınırlı olabilir. En sağlıklı yapı, DNS kayıtlarını varsayımla değil gerçek gönderim akışına göre düzenlemektir.