E-posta DNS Kayıtları: MX, SPF, DKIM ve DMARC Ne İşe Yarar?

Sesli Dinle — Makale

E-posta için yayımlanan dört DNS kaydı aynı işi yapmaz. MX (Mail Exchanger) gelen mesajın hedefini belirler. SPF (Sender Policy Framework) gönderim kaynağını yetkilendirir. DKIM (DomainKeys Identified Mail) mesajı alan adına bağlı imzayla doğrular. DMARC (Domain-Based Message Authentication, Reporting, and Conformance) ise SPF veya DKIM ile doğrulanan alan adının görünür gönderen alan adıyla uyumunu denetler.

MX e-posta alımıyla, diğer üç mekanizma gönderen alan adının kullanımıyla ilgilidir. Hiçbiri tek başına mesajı şifrelemez, gönderen kişinin kimliğini kanıtlamaz veya gelen kutusuna teslim garantisi vermez. Alıcı sistemler kimlik doğrulamanın yanında itibar, içerik, hacim ve yerel güvenlik politikasını da değerlendirir.

DMARC standardı Mayıs 2026’da yenilendi. Çekirdek mekanizma RFC 9989, toplu raporlama RFC 9990 ve mesaj bazlı başarısızlık raporları RFC 9991 ile tanımlanıyor; bu üç belge eski RFC 7489’un yerini aldı. Bu nedenle eski yapılandırma örneklerindeki bazı etiketler artık güncel kabul edilmez.

MX, SPF, DKIM ve DMARC Aynı Şeyi Yapmaz

• MX, alıcı alan adına gelen mesajın hangi posta sunucusuna gönderileceğini bildirir.
• SPF, bağlantıyı kuran IP adresinin zarf gönderen alanı adına yetkili olup olmadığını değerlendirir.
• DKIM, seçilmiş başlıkların ve gövdenin imzalandıktan sonra korunup korunmadığını ve imzayı hangi alanın attığını denetler.
• DMARC, başarılı SPF veya DKIM kimliğinin kullanıcıya gösterilen From başlığındaki alan adıyla uyumunu denetler; alan sahibinin politika ve raporlama isteğini yayımlar.

Zarf göndereni, posta sunucularının mesaj aktarırken kullandığı ve teslim hatalarının bildirileceği MAIL FROM adresidir. Kullanıcının gördüğü From başlığındaki adres farklı olabilir.

SPF ile DKIM birbirinin alternatifi değildir. Yönlendirme SPF sonucunu bozabilir; içerik veya başlık değişikliği DKIM imzasını geçersiz kılabilir. Her ikisini de doğru kurmak, DMARC’ın en az bir hizalı sonuçla geçebilme olasılığını artırır.

Kayıtların DNS’te Bulunduğu Yerler

TXT genel amaçlı bir DNS kayıt türüdür; alan adındaki her TXT kaydı SPF, DKIM veya DMARC değildir. Kayıt adı, sürüm etiketi ve içerik birlikte değerlendirilmelidir. Aynı mekanizmayı yanlış adda yayımlamak, metin DNS’te görünse bile doğrulama sağlamaz.

MX Kaydı Alıcı Sunucuyu Nasıl Seçer?

SMTP göndereni, alıcı alan adının MX kayıtlarını sorgular. Daha düşük sayısal tercih değeri önce denenir. Aynı değere sahip birden fazla kullanılabilir hedef varsa gönderen bunlar arasında seçim yapabilir; yalnız kayıt sayısını artırmak, hedefler aynı arızaya bağlıysa gerçek yedeklilik sağlamaz.

MX hedefi doğrudan IP adresi değil, tam bir sunucu adı olmalıdır. Bu adın A (IPv4) veya AAAA (IPv6) kaydı bulunmalıdır; MX hedefinin CNAME kaydına çözülmesi standartla uyumlu değildir. Kayıt var fakat hedeflerin hiçbiri kullanılabilir değilse gönderen bunu hata olarak ele alır.

Hiç MX yoksa SMTP, alan adının A veya AAAA kaydını örtük MX gibi deneyebilir. Bu eski geri dönüşe güvenmek yerine posta kabul eden alanlarda açık MX yayımlayın. Posta kabul etmeyen bir alan için MX 0 . biçimindeki Null MX (boş MX) kaydı, bu alanın e-posta almadığını kesin olarak bildirir.

SPF Gerçekte Hangi Gönderen Kimliğini Denetler?

SPF, bağlantıyı kuran IP adresinin MAIL FROM adresindeki alan adı adına posta göndermeye yetkili olup olmadığını, o alanın SPF politikasıyla denetler. SMTP oturumunun başlangıcında sunucunun kendisini tanıttığı HELO/EHLO alan adı da SPF ile değerlendirilebilir. Kullanıcının posta uygulamasında gördüğü From başlığını doğrudan doğrulamaz. DMARC’ın SPF yoluyla geçebilmesi için başarılı SPF alanının görünür From başlığındaki alan adıyla ayrıca hizalanması gerekir.

Aynı alan adı için tek bir v=spf1 politikası yayımlayın. include, a, mx, ptr, exists ve redirect gibi DNS sorgusu üreten terimlerin toplam değerlendirme sınırı 10’dur; sınır aşılırsa kalıcı politika hatası olan permerror oluşur. ip4, ip6 ve all bu 10 terimlik sınıra dahil değildir. Bu sınır, ağda gönderilen DNS paketlerinin toplam sayısını değil, değerlendirme sırasında DNS araması gerektiren SPF terimlerini sayar. Çok sayıda üçüncü taraf hizmeti eklerken yalnız metin uzunluğunu değil gerçek sorgu zincirini ölçün. NXDOMAIN (alan adı bulunamadı) yanıtı alınan veya NOERROR (hatasız yanıt) koduyla birlikte yanıt bölümü boş olan DNS aramaları için önerilen ayrı üst sınır ikidir; bunun aşılması da permerror üretebilir.

-all eşleşmeyen kaynak için fail, ~all ise softfail sonucu üretir; alıcı tarafın mesajı nasıl işleyeceğini tek başına belirlemez. Yönlendirme hizmeti bağlantı IP adresini değiştirdiğinden meşru mesaj SPF’yi kaybedebilir. SRS (Sender Rewriting Scheme) bu sorunu bazı yönlendirme akışlarında azaltabilir.

DKIM İmzası ve Anahtar Yaşam Döngüsü

Gönderim sistemi, DKIM özel anahtarıyla seçilmiş başlıkları ve gövdeyi imzalar. Alıcı; imzadaki d= alanı ile s= seçicisini kullanarak açık anahtarı DNS’ten alır. İmzalama ve doğrulama öncesinde metnin nasıl hazırlanacağını belirleyen simple ve relaxed seçenekleri, boşluk veya satır biçimi değişikliklerine gösterilen toleransı düzenler. İmzanın kapsamadığı alanlardaki değişiklikler veya bu hazırlık sırasında yok sayılan biçim farkları imzayı bozmayabilir; denetlenen veriyi değiştiren müdahaleler ise doğrulamayı geçersiz kılar.

Seçici, aynı alan için birden fazla anahtarın birlikte yayımlanmasına ve kesintisiz anahtar değişimine olanak verir. Yeni açık anahtarı önce yayımlayın, DNS yayılımını doğrulayın, sonra yeni özel anahtarla imzalamaya başlayın; eski anahtarı mesajların aktarım ve doğrulama süresi geçmeden kaldırmayın. Özel anahtarı DNS’e veya ortak dosya alanına koymayın.

RFC 8301’e göre RSA imzaları SHA-256 ile üretilmeli; rsa-sha1 kullanılmamalıdır. RSA anahtarı en az 1024 bit olmalı, en az 2048 bit tercih edilmelidir. DNS sağlayıcısının uzun TXT değerlerini doğru bölüp birleştirdiğini ve alıcıların seçiciyi tek geçerli anahtar kaydı olarak gördüğünü denetleyin.

DMARC Hizalaması ve 2026 Standart Değişikliği

Geçerli DMARC politikası ilgili adda tek TXT kaydı olarak yayımlanmalıdır. v=DMARC1 ilk etiket olmalı ve büyük-küçük harf biçimi korunmalıdır; aynı adda birden fazla DMARC politika kaydı varsa o addaki politika kayıtları dikkate alınmaz ve RFC 9989’a göre üst alanlarda politika araması gerekebilir.

DMARC, görünür From başlığındaki adresin alan adını yazar alanı olarak kabul eder. Mesaj; SPF başarılı ve zarf gönderen alanı hizalıysa veya DKIM başarılı ve d= imza alanı hizalıysa DMARC’ı geçer. İkisinin birden geçmesi zorunlu değildir; ancak alan sahibi güvenilir gönderim için her iki hizalı kimliği de üretmelidir.

Gevşek hizalamada kimlikler aynı kuruluş alanına bağlı olabilir; katı hizalamada alan adları birebir aynı olmalıdır. aspf ve adkim etiketleri SPF ve DKIM hizalamasını gevşek veya katı seçer. Alt alan yetkileri dikkatle yönetilmelidir; gevşek hizalama, kontrolü devredilmiş bir alt alanın üst alanla hizalanmasına izin verebilir.

Yazar alanında doğrudan DMARC kaydı yoksa RFC 9989, uygulanacak politika ve kuruluş alanını bulmak için DNS ağacında sınırlı bir üst arama tanımlar. Gönderim yapan önemli alt alanlarda açık DMARC kaydı yayımlamak, politika keşfini ve hizalama sınırını daha belirgin kılar.

p=none politika tercihi belirtmeden izleme sağlar; p=quarantine başarısız mesajlar için karantina, p=reject ise ret isteği yayımlar. sp mevcut alt alanların, np etiketi var olmayan alt alanların politikasını belirleyebilir. RFC 9989, eski pct etiketini kullanımdan kaldırılmış sayar ve test için t=y seçeneğini tanımlar. t=y, ret isteğini karantina; karantina isteğini politika tercihi yokmuş gibi uygulama yönünde sinyal verir ve raporlamayı durdurmaz. Yeni etiketleri kullanmadan önce alıcı ekosisteminin destek düzeyini değerlendirin.

rua toplu rapor hedefini, ruf mesaj bazlı başarısızlık raporu hedefini belirtir. Toplu raporlar kaynak ve hizalama görünürlüğü sağlar. Rapor hedefi başka bir kuruluş alanındaysa alıcılar dış hedef yetkilendirmesini DNS üzerinden doğrular. Başarısızlık raporları başlık veya içerik taşıyabileceğinden PII (Personally Identifiable Information) ve ticari veri açığa çıkarabilir; kapsamı, alıcıyı, saklama süresini ve güvenli aktarımı dikkatle yönetin.

Dört Kayıt Bir Mesajda Nasıl Birlikte Çalışır?

1. Gönderici, alıcı alanın MX kayıtlarından hedef posta sunucusunu seçer.
2. Alıcı, bağlantı IP adresini zarf gönderen veya HELO/EHLO alanındaki SPF politikasıyla değerlendirir.
3. Mesaj DKIM imzası taşıyorsa alıcı seçici kaydındaki açık anahtarla imzayı doğrular.
4. Alıcı, DMARC için başarılı SPF veya DKIM kimliğinin görünür From başlığındaki alan adıyla hizalı olup olmadığını denetler.
5. DMARC başarısızsa alıcı yayımlanan politika isteğini, kendi yerel güvenlik ve teslimat kararıyla birlikte değerlendirir.

Örneğin SPF geçebilir ancak zarf gönderen alanı görünür From başlığındaki alan adıyla hizalanmadığı için DMARC başarısız olabilir. DKIM kaydı DNS’te bulunabilir fakat gönderim sistemi mesajı imzalamıyorsa başarılı bir DKIM doğrulaması elde edilemez. Bu nedenle yalnız DNS kayıtlarını değil gerçek mesaj başlıklarındaki doğrulama sonuçlarını da inceleyin.

Güvendiğiniz alıcı sistemin eklediği Authentication-Results ve varsa Received-SPF başlıkları doğrulamada kullanılan kimlikleri ve sonuçları gösterir. DKIM-Signature başlığını ise mesajı imzalayan gönderim sistemi ekler; bu başlık imza verisini ve hangi anahtarın kullanılacağını belirtir, tek başına başarılı doğrulama kanıtı değildir. Gönderenin eklediği sahte sonuç başlıklarına güvenmeyin; doğrulama sonucunu kendi alıcı sisteminizin ürettiği veya güvenilir kabul ettiği başlıklardan alın.

E-posta Doğrulamasını Kurma ve DMARC Politikasını Sıkılaştırma

1. Kurumsal posta, destek sistemi, bülten, fatura, bulut hizmeti ve alt alanlar dahil bütün gerçek gönderim kaynaklarını envanterleyin.
2. Gelen posta hedeflerini ve posta kabul etmeyen alanları MX veya boş MX ile açıkça tanımlayın.
3. Her zarf gönderen alanında tek SPF politikası oluşturun; DNS araması gerektiren terimlerin toplamının 10 sınırını aşmadığını denetleyin.
4. Her gönderim hizmetine ayrı DKIM seçicisi verin; anahtarları güvenli saklayıp yenileme planı oluşturun.
5. SPF ve DKIM alanlarını görünür From başlığındaki alan adıyla hizalayın.
6. DMARC’ı önce p=none ve denetimli rua hedefiyle yayımlayıp toplu raporları analiz edin.
7. Yetkisiz veya unutulmuş kaynakları giderdikten sonra karantina ve ret politikasına kontrollü geçin; alt alan politikasını ayrıca doğrulayın.

Kayıt değişikliğinden önce DNS kayıtlarının TTL’sini, geri dönüş değerlerini ve sorumlu kişiyi belirleyin. Geçişi yalnız kayıt sorgusuyla değil, farklı gönderim kaynaklarından gerçek test mesajları ve alıcı başlıklarıyla doğrulayın.

E-posta Teslimatı ve Kimlik Doğrulama Hatalarını Araştırma

E-posta Kimlik Doğrulaması Neyi Garanti Etmez?

MX, SPF, DKIM ve DMARC mesaj aktarımını şifrelemez; bağlantı güvenliği ayrı mekanizmalarla sağlanır. Başarılı DKIM sonucu mesajın zararsız olduğunu, başarılı SPF sonucu görünen gönderen adresinin doğru olduğunu, başarılı DMARC sonucu da gönderen kişinin gerçek kimliğini kanıtlamaz. Benzer görünümlü başka bir alan adıyla yapılan oltalama, görüntülenen adın kötüye kullanılması ve ele geçirilmiş meşru hesaplar ayrıca ele alınmalıdır.