E-postalarım spam'e düşüyor: SPF, DKIM ve DMARC nasıl kurulur?

Kısa cevap: Giden postanızın doğrulanması üç TXT kaydıyla sağlanır ve üçü farklı iş yapar. SPF, alan adınız adına hangi sunucuların posta gönderebileceğini listeler. DKIM her iletiye bir imza koyar; alıcı bu imzayı DNS'te duran genel anahtarla doğrular ve iletinin yolda değişmediğini görür. DMARC ise SPF ve DKIM sonucunu bir politikaya bağlar, hizalama ister ve size rapor gönderir. Doğru sıra: gönderen envanterini çıkar, tek bir SPF kaydı yaz, DKIM imzalamayı aç, DMARC'ı p=none ile kur, raporları oku, sonra kademe kademe reject yap.

Üç kayıt, üç ayrı iş

Üçü birlikte anılır ama aynı şeyi yapmazlar; birini kurup diğerlerini atlamak yarım bir kurulumdur. SPF bir TXT kaydıdır ve alan adınızın kök kaydına (@) yazılır. İçeriği basit bir izin listesidir: “bu alan adı adına posta gönderebilecek sunucular şunlardır.” Alıcı sunucu, iletiyi getiren sunucunun bu listede olup olmadığına bakar.

DKIM farklı bir mantıkla çalışır. Gönderen sunucu, çıkan her iletiye kriptografik bir imza ekler. Alıcı, o imzayı sizin DNS bölgenizde duran genel anahtarla doğrular. Bu sayede iki şey anlaşılır: ileti gerçekten sizin alan adınız adına imzalanmıştır ve içeriği yolda değiştirilmemiştir. DKIM kaydının adı her zaman <seçici>._domainkey.<alanadı> kalıbındadır; Google Workspace'in varsayılan seçicisi google olduğu için kayıt adı google._domainkey olur. Değer v=DKIM1; k=rsa; p=<anahtar> biçimindedir; anahtar uzunluğu için 2048 bit önerilir, sağlayıcı desteklemiyorsa 1024 bit kullanılır.

DMARC kendi başına bir doğrulama yapmaz; SPF ve DKIM'in sonucunu alır ve ona bir politika uygular. Kayıt _dmarc alt alan adında bir TXT kaydı olarak durur. Kullanılan etiketler şunlardır: v=DMARC1, politika için p=none, p=quarantine ya da p=reject; toplu raporlar için rua, ayrıntılı raporlar için ruf, politikanın hangi oranda uygulanacağı için pct, alt alan adları için sp, hizalama sıkılığı için adkim ve aspf.

Hizalama: SPF geçse bile DMARC başarısız olabilir

Kurulumun en çok şaşırtan noktası budur ve bilinmediği sürece raporlar anlaşılmaz kalır. DMARC yalnızca “SPF geçti mi” diye bakmaz; hangi alan adı için geçtiğine bakar. Kuralı şudur: SPF ya da DKIM'in doğruladığı alan adı, kullanıcının e-posta istemcisinde gördüğü From satırındaki alan adıyla aynı olmalıdır. Buna hizalama (alignment) deniyor.

Pratikte şöyle olur: bir bülten servisi ya da fatura yazılımı, kendi alan adı üzerinden teslim yapıp From satırına sizin adresinizi yazar. O servisin kendi SPF kaydı geçerlidir, teknik olarak SPF başarılı sayılır; ama doğrulanan alan adı sizin alan adınız olmadığı için DMARC açısından hizalama sağlanmaz ve DMARC başarısız olur. Çözüm, o servisi sizin alan adınız adına imzalayacak biçimde (kendi DKIM seçicisiyle) yapılandırmaktır. Bu yüzden DMARC'ı sıkılaştırmadan önce her gönderenin tek tek ele alınması gerekir.

Üç kaydın karşılaştırması

SPF kaydında iki kural sık ihlal edilir. Birincisi: bir alan adında yalnızca BİR SPF kaydı olur. İki ayrı SPF TXT kaydı gören alıcı sunucular politikayı geçerli saymaz; bütün izinler tek satırda include ifadeleriyle birleştirilir. İkincisi: SPF değerlendirmesinde 10 DNS araması sınırı vardır. Her include üst seviyede bir arama sayılır ama kendi içinde başka aramalar tetikleyebilir; örneğin include:_spf.google.com üstten 1 arama görünür, toplamda 4 arama harcar. Sınır aşılırsa kayıt geçersiz sayılır. Sondaki niteleyici de önemlidir: ~all softfail (listede olmayan gönderen şüpheli sayılır), -all hardfail (reddedilir), +all ise herkese izin verir ve asla kullanılmaz.

Adım adım: sıfırdan DMARC politikasına

Bu akışın tek amacı, kendi meşru postanızı bloke etmeden sıkılaşmaktır. Adımları atlamak, en çok ihtiyaç duyduğunuz e-postaların reddedilmesiyle sonuçlanır.

1. Gönderen envanterini çıkarın. Alan adınız adına posta gönderen her şeyi listeleyin: e-posta sağlayıcınız, sitenizin iletişim formu, fatura ya da CRM yazılımı, bülten servisi, randevu bildirimleri. Hepsinin SPF kaydında temsil edilmesi gerekir; envanter eksikse sonraki her adım yanlış kurulur.
2. Tek bir SPF kaydı yazın. Bütün izinleri kök alan adındaki tek TXT satırında birleştirin. Kayıttaki include sayısını 10 DNS araması sınırını gözeterek tutun ve sonuna önce ~all koyun.
3. DKIM anahtarını üretin, kaydı ekleyin, SONRA imzalamayı açın. Sağlayıcı panelinde anahtarı oluşturun, verilen TXT kaydını DNS'e yazın, kaydın yayıldığını doğrulayın ve ancak ondan sonra sağlayıcıda imzalamayı etkinleştirin. Sıra ters olursa imzalı giden posta doğrulanamaz.
4. DMARC'ı p=none ile kurun. _dmarc kaydını ekleyin ve rua etiketine raporların geleceği adresi yazın. Bu aşamada hiçbir posta engellenmez; yalnızca görünürlük kazanırsınız.
5. Raporları birkaç hafta okuyun. Gelen toplu raporlarda hangi kaynakların sizin adınıza posta gönderdiği ve hangilerinin doğrulamayı geçemediği görünür. Envanterde atladığınız göndereni bulacağınız yer burasıdır; genellikle bir muhasebe yazılımı ya da site formu çıkar.
6. p=quarantine aşamasına geçin. Raporlarda meşru gönderen kalmadığından emin olduğunuzda politikayı sıkılaştırın. pct etiketiyle politikayı trafiğin bir kısmına uygulayıp kademeli ilerleyebilirsiniz.
7. p=reject aşamasına geçin. Karantina aşamasında bir hafta boyunca meşru posta engellenmediyse politikayı reddetmeye alın. SPF kaydındaki ~all ifadesini de bu aşamada -all yapabilirsiniz. Raporları okumayı bırakmayın; yeni bir yazılım devreye girdiğinde envanter değişir.

Üç kaydın gerçek örnekleri

Aşağıdaki kutuda alan adı ornekfirma.com bir YER TUTUCUDUR; kendi alan adınızı ve sağlayıcınızın verdiği anahtarı yazmanız gerekir. Kayıtların biçimi gerçektir.

; SPF (tek kayıt, kök alan adında) — Google Workspace
@                 3600  TXT  "v=spf1 include:_spf.google.com ~all"
; SPF — Microsoft 365 kullanıyorsanız bunun yerine
@                 3600  TXT  "v=spf1 include:spf.protection.outlook.com -all"
; DKIM (seçici google, 2048 bit önerilir)
google._domainkey 3600  TXT  "v=DKIM1; k=rsa; p=(genel anahtar)"
; DMARC (ilk kurulumda p=none)
_dmarc            3600  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@ornekfirma.com"
; DMARC (olgunlaşmış politika)
_dmarc            3600  TXT  "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@ornekfirma.com"

Bir pratik not: DKIM değeri uzun bir metindir ve bazı DNS sağlayıcıları tek bir TXT kaydının uzunluğunu sınırlar. Panel değeri kabul etmiyorsa kaydın bölünmesi gerekebilir; sağlayıcınızın belgelerinde bunun nasıl yapıldığı yazar. Kaydın hangi satıra yazılacağını ve TXT kayıtlarının genel mantığını DNS kayıt türleri yazısında anlatıyoruz.

Yaygın hatalar

• Doğrudan p=reject ile başlamak. Envanteri çıkarmadan katı politika yazarsanız, önce kendi fatura bildirimleriniz ve site formunuzun e-postaları reddedilir. Dışarıdan bakınca sistem “sağlamlaşmış” görünür, oysa en çok ihtiyaç duyduğunuz iletiler kaybolmaya başlamıştır.
• İki ayrı SPF kaydı yazmak. Yeni bir servis eklerken ikinci bir TXT satırı açmak en yaygın hatadır. Alıcı sunucular bunu iki geçerli politika olarak görmez ve SPF doğrulamanız tamamen kaybolur.
• 10 DNS araması sınırını aşmak. Kayda altı yedi include eklediğinizde üstten her şey normal görünür, ama her biri içinde başka aramalar tetiklediği için sınır sessizce aşılır ve SPF geçersiz sayılır.
• DKIM kaydını ekleyip sağlayıcıda imzalamayı açmamak. DNS tarafı hazırdır, panelde kayıt görünür, ama giden iletiler imzalanmadığı için DKIM hiç devreye girmez. Panelde imzalama anahtarının durumu “etkin” olmalı.
• rua adresini hiç okumamak. Raporlar bir kutuya düşer ve kimse açmaz. O raporlar olmadan hangi gönderenin doğrulamayı geçemediğini bilmenin bir yolu yoktur; politika sonsuza kadar p=none olarak kalır.
• Site formunu envantere katmamak. İletişim formu kendi sunucusundan, gönderen olarak sizin alan adınızı yazarak posta atıyorsa ve SPF'te yer almıyorsa, müşterinizin doldurduğu form e-postası doğrulamayı geçemez. Bu da genellikle “form çalışmıyor” diye raporlanır.

Ne zaman uzmana bırakmalı

Tek bir posta sağlayıcısı kullanan ve başka hiçbir yerden e-posta göndermeyen bir işletme bu üç kaydı bir öğleden sonra kurabilir. İş, gönderen sayısı arttığında zorlaşır: bülten servisi, fatura yazılımı, randevu bildirimleri ve site formu aynı alan adını kullanıyorsa, hangisinin hizalamayı sağladığını ve hangisinin raporlarda başarısız göründüğünü tek tek ölçmek gerekir. Kayıtların mevcut hâlinde 10 arama sınırının aşılıp aşılmadığı da ancak ölçülerek anlaşılır.

Bu ölçümü teknik denetim çalışmasının bir parçası olarak yapıyoruz: gönderen envanteri çıkarılır, kayıtlar yeniden yazılır ve DMARC politikası raporlar okunarak kademe kademe sıkılaştırılır. Mevcut durumu konuşmak için iletişim sayfasından yazabilirsiniz.

Devamını okumak için

Kutuların ve portların kurulumu için başlangıç noktası kurumsal e-posta kurulumu. Hangi sağlayıcının hangi SPF ve DKIM değerlerini istediğini Google Workspace mi, Microsoft 365 mi yazısı yan yana koyuyor. Sağlayıcı değiştiriyorsanız arşivin taşınması için eski e-postaları yeni sunucuya taşıma, kayıtların kendisini tanımak için DNS kayıt türleri yazısına bakın. Tüm başlıklar blog sayfamızda, çalışma alanlarımız ana sayfamızda.