Bir e-postayı gerçekten sizin gönderdiğinizden alıcının sunucusu nasıl emin olur? Bu sorunun arkasında SPF, DKIM ve DMARC adlı üç protokol yatar. Her biri farklı bir güvenlik katmanını üstlenir: biri gönderen sunucunun izinli olup olmadığını denetler, diğeri mesajın yolculuk sırasında değiştirilmediğini kanıtlar, üçüncüsüyse bu iki denetimin nasıl değerlendirileceğini belirleyen bir politika oluşturur. Bu üçlüyü doğru yapılandırmak, e-postalarınızın alıcının gelen kutusuna ulaşmasını sağlar; yanlış yapılandırmaysa sizi spam klasörüne sürekler. Bu yazıda her protokolün ne yaptığını, birbirleriyle nasıl etkileşime girdiğini ve alan adınız için hangi adımları atmanız gerektiğini adım adım ele alıyoruz.

E-posta Doğrulama Neden Gereklidir?

E-posta protokolü SMTP, 1982 yılında tasarlandığında kimlik doğrulama gibi bir mekanizma içermiyordu. Herhangi biri, istediği alan adını "From" kısmına yazarak e-posta gönderebilirdi. Bu güvenlik açığı, oltalama saldırılarını ve marka taklidini endüstri düzeyinde bir soruna dönüştürdü. Google'ın 2024 verilerine göre, Gmail'e gelen e-postaların yaklaşık %15'i kimlik doğrulama kontrollerinden geçemiyor ve doğrudan spam klasörüne yönlendiriliyor. Bu veri, doğrulamanın artık isteğe bağlı bir tercih değil, temel bir zorunluluk olduğunu gösteriyor.

Uzman bakış açısıyla, e-posta doğrulamanın asıl değeri yalnızca güvenlik değildir. Doğrulama protokolleri olmayan bir alan adından gönderilen mesajlar, büyük sağlayıcılarda teslim oranlarını dramatik şekilde düşürür. Gmail ve Yahoo'nun 2024'te uygulamaya aldığı zorunlu doğrulama politikası, SPF veya DKIM kaydı bulunmayan göndericilerin mesajlarını reddetmeye başladı. Bir e-ticaret sitesi sahibiyseniz ve bildirim e-postalarınız teslim edilmiyorsa, sorunun kökü büyük olasılıkla eksik doğrulama yapılandırmasındadır.

SPF: Gönderen Sunucunun Yetkisini Doğrulama

SPF (Sender Policy Framework), alan adınız adına e-posta göndermeye yetkili sunucuları tanımlayan bir DNS TXT kaydıdır. Bu kayıt, "bu alan adından gelen e-postalar yalnızca şu IP adreslerinden veya sunuculardan gelebilir" demenin standart yoludur. Alıcının sunucusu, gelen mesajın geldiği IP adresini SPF kaydındaki izinli listesiyle karşılaştırır ve eşleşiyorsa mesajı "geçti" olarak işaretler.

Örneğin, bir şirket hem kendi sunucusundan hem de Mailchimp'ten e-posta gönderiyorsa, SPF kaydında her iki kaynağın IP adreslerinin veya yetki mekanizmalarının tanımlanması gerekir. SPF kaydınızdaki bir eksiklik, pazarlama e-postalarınızın spam olarak işaretlenmesine neden olabilirken, fazla geniş bir kayıt (örneğin v=spf1 +all kullanımı) tüm alan adınızı taklit saldırılara açık hale getirir.

SPF'in kritik bir sınırlaması vardır: yalnızca "Return-Path" adresindeki alan adını kontrol eder, "From" başlığındaki adresi değil. Bu nedenle, çoğu pazarlama platformu Return-Path'i kendi alan adına yönlendirir. SPF tek başına yeterli değildir; bu protokolü DKIM ile desteklemek gerekir. Bir SPF kaydı oluştururken 10 DNS.lookup sınırını aşmamaya dikkat edin; aşırı iç içe geçmiş include yönlendirmeleri SPF doğrulamasının başarısız olmasına yol açar.

DKIM: Dijital İmza ile Mesaj Bütünlüğünü Koruma

DKIM (DomainKeys Identified Mail), gönderen sunucunun mesaja özel bir şifreleme imzası eklediği ve alıcının sunucunun bu imzayı DNS'deki ortak anahtarla doğruladığı bir mekanizmadır. SPF'ten farklı olarak DKIM, mesajın kendisini korur: başlık bilgileri ve gövde, yolculuk sırasında değiştirilmemişse imza geçerli sayılır. Bu, mesajın gerçekten o sunucudan çıktığını ve içeriğinin bozulmadığını kanıtlar.

Teknik olarak, gönderen sunucusu mesajın belirli başlıklarını ve gövde hash'ini RSA veya Ed25519 algoritmasıyla imzalar. Bu imza, DKIM-Signature başlığına eklenir. Alıcının sunucusu, imzadaki d= etiketindeki alan adından DNS'e giderek ortak anahtarı çeker ve imzayı doğrular. Bir mesaj iletildiğinde (forwarding), SPF genellikle başarısız olur çünkü farklı bir sunucudan gelir; ancak DKIM imzası içerik değişmediği sürece geçerliliğini korur. Bu özellik, DKIM'i iletme senaryolarında SPF'ten daha dayanıklı kılar.

Pratik bir uyarı: DKIM anahtar uzunluğunu 1024 bit yerine 2048 bit olarak ayarlayın. 1024 bit anahtarlar günümüz hesaplama gücüyle kırılabilir durumdadır. Ancak bazı DNS sağlayıcıları 2048 bit anahtarları TXT kaydına sığdırmakta sorun yaşayabilir; bu durumda sağlayıcınızla iletişime geçmeniz gerekir. Ayrıca t=y etiketini test aşamasında kullanıp, doğrulama tamamlandığında kaldırmanız yaygın bir pratik yöntemdir.

DMARC: Politika Katmanı ve Raporlama Mekanizması

DMARC (Domain-based Message Authentication, Reporting, and Conformance), SPF ve DKIM'in üzerine oturan bir politika ve raporlama çerçevesidir. SPF ve DKIM tek başına ne yapılacağını söylemez; DMARC ise alıcının sunucusuna şu talimatı verir: "Eğer SPF veya DKIM başarısız olursa, mesajı reddet veya karantinaya al." Bu politika, p=none, p=quarantine veya p=reject olmak üzere üç düzeyde tanımlanır.

DMARC'in en güçlü yönü raporlama mekanizmasıdır. Alıcı sunucular, DMARC kaydınızdaki rua ve ruf adreslerine günlük özet ve hata raporları gönderir. Bu raporlar sayesinde alan adınızdan kimlerin e-posta gönderdiğini, hangi mesajların doğrulamadan geçemediğini ve olası taklit girişimlerini görebilirsiniz. Örneğin, bir şirket DMARC'i p=none ile devreye aldığında, birkaç haftalık raporlama döneminde beklenmedik bir üçüncü tarafın alan adını kullandığını keşfedebilir.

DMARC'de dikkat edilmesi gereken kritik bir detay, hizalama (alignment) kavramıdır. DMARC, SPF veya DKIM'in başarılı olmasını yeterli görmez; başarılı olan protokolün alan adının "From" başlığındaki alan adıyla hizalı olmasını ister. adkim=s ile katı hizalama veya adkim=r ile rahat hizalama seçebilirsiniz. Bir hata yaparsanız—örneğin hemen p=reject uygularsanız—meşru e-postalarınız da reddedilebilir. Bu nedenle önce p=none ile başlayıp raporları analiz ederek kademeli geçiş yapmak standart bir güvenlik uygulamasıdır.

Üç Protokolü Birlikte Doğru Yapılandırma

SPF, DKIM ve DMARC birbirinin alternatifi değil, tamamlayıcısıdır. SPF gönderen sunucuyu doğrular, DKIM mesaj bütünlüğünü korur, DMARC ise bu ikisinin sonuçlarına göre aksiyon belirler. Üç protokolü birlikte kullanmak, savunma derinliği (defense in depth) prensibine dayanır: biri başarısız olsa bile diğeri koruma sağlar. Örneğin SPF başarısız olduğunda DKIM hâlâ geçerliyse ve hizalama sağlanıyorsa DMARC doğrulaması başarılı sayılır.

Gerçek dünya senaryosu olarak, bir şirketin pazarlama ekibi SendGrid, destek ekibi Zendesk ve şirket içi iletişim kendi Exchange sunucusu üzerinden e-posta gönderiyorsa, her bir kaynak için SPF include eklemeniz, DKIM imzalarını ayrı ayrı yapılandırmanız ve DMARC raporlarını düzenli izlemeniz gerekir. SPF kaydındaki include sayısının 10'u aşmaması kuralı burada devreye girer; fazla kaynak kullanıyorsanız, birden fazla alt alan adı (subdomain) oluşturarak yükü dağıtabilirsiniz.

Son adım olarak, DMARC'i p=reject düzeyine taşıdığınızda, alan adınızın kimliğini tam olarak koruma altına almış olursunuz. Ancak bu noktaya ulaşmadan önce en az 4–8 hafta boyunca p=none ile rapor toplamanız ve tüm meşru gönderim kaynaklarınızı tespit etmeniz gerekir. Bu süreç sabır gerektirir, ancak atlandığında şirket içi bildirimlerin bile reddedildiği bir kaosa dönüşebilir. Düzenli DMARC raporlarını izlemek için Postmark'ın DMARC Digestes veya dmarcian gibi araçlarını kullanabilirsiniz.

Sonuç

E-posta doğrulama, modern dijital iletişimin vazgeçilmez bir altyapı katmanıdır. SPF gönderen sunucunun yetkisini tanımlar, DKIM mesajın bütünlüğünü kriptografik olarak kanıtlar ve DMARC bu iki mekanizmayı bir politika çerçevesinde birleştirerek hem yönlendirme hem raporlama sağlar. Bu üç protokolü ayrı ayrı ele almak yerine bir bütün olarak yapılandırmak, hem teslim oranlarınızı hem de alan adınızın itibarını korumanın en etkili yoludur. Henüz bir DMARC kaydı oluşturmadıysanız, bugün p=none ile başlayın ve raporlarınızı inceleyin. Alan adınızın kimliğini korumak için atmanız gereken ilk adım, mevcut durumunuzu görmekten geçer.