EN
← Bloga dönRehberler

MX, SPF, DKIM ve DMARC Nedir? Dördü Birlikte Nasıl Çalışır?

MX kaydı, SPF, DKIM ve DMARC birlikte nasıl çalışır, en sık yapılan hatalar nelerdir ve DMARC, meşru e-postaları kaybetmeden güvenle nasıl devreye alınır?

Yayınlanma: · 6 dk okuma

Alan adınızın e-postasının nasıl teslim edileceğini ve alıcıların bu e-postanın gerçekten sizden geldiğine inanıp inanmayacağını dört DNS kaydı türü belirler. Genellikle tek tek anlatılırlar; bu da en önemli noktayı gizler: her biri, diğerlerinin açık bıraktığı bir boşluğu kapatır.

Bu rehberde dördünü de, gerçek zone'larda en sık rastlanan hataları ve meşru e-postalarınızı riske atmayan bir devreye alma sırasını anlatıyoruz.

Kısaca

  • MX, alan adınıza gelen e-postanın nereye teslim edileceğini söyler.
  • SPF, zarf gönderen adresinde alan adınızı kullanarak hangi sunucuların e-posta gönderebileceğini söyler.
  • DKIM, iletinin bir alan adı tarafından yetkilendirildiğini ve yolda değiştirilmediğini kanıtlayan kriptografik bir imza ekler.
  • DMARC, SPF ve DKIM'i insanların gerçekten gördüğü From adresine bağlar, ikisi de başarısız olduğunda alıcıya ne yapacağını söyler ve size rapor gönderir.

MX almakla, diğer üçü göndermekle ilgilidir.

MX: e-posta nereye gider?

$ dig +short MX example.com
10 mx1.mail.example.net.
20 mx2.mail.example.net.

Gönderen sunucular önce öncelik numarası en küçük olanı dener, başarısız olursa büyük numaralara geçer. Eşit numaralar yükü paylaşır.

Önemli kurallar:

  • Hedef, A ya da AAAA kaydı olan bir ana bilgisayar adı olmalıdır. IP adresi de CNAME de olamaz.
  • Hiç MX kaydı yoksa gönderenler alan adının kendi A/AAAA kaydına teslim etmeyi dener. Bu neredeyse hiçbir zaman istediğiniz şey değildir.
  • Hiç e-posta almaması gereken bir alan adı null MX yayınlayabilir: 0 . (öncelik sıfır, hedef tek bir nokta). Gönderenler böylece günlerce yeniden denemek yerine hemen hata verir.

SPF: kimler gönderebilir?

SPF, alan adındaki tek bir TXT kaydıdır:

example.com.  TXT  "v=spf1 include:_spf.mail.example.net ip4:192.0.2.10 -all"

Alıcı sunucu alan adını zarf gönderenden (görünen From başlığından değil, Return-Path'ten) alır, o alan adının SPF kaydını çeker ve bağlanan IP adresinin eşleşip eşleşmediğine bakar. Sondaki all, geri kalan herkese ne olacağını belirler: -all başarısız, ~all yumuşak başarısız (softfail), ?all ise "görüşüm yok" demektir.

Yapısından gelen iki sınırı vardır:

  1. SPF, alıcının hiç görmediği bir alan adını kontrol eder. Tek başına, görünen From adresinizin taklit edilmesini engellemez.
  2. SPF yönlendirmede (forwarding) bozulur. İleti yönlendirildiğinde son alıcıya yönlendiren sunucunun IP adresi bağlanır ve o adres sizin kaydınızda yoktur.

DKIM: iletiyle birlikte yolculuk eden imza

DKIM'de gönderen sunucu, seçili başlıkları ve gövdeyi özel bir anahtarla imzalar ve iletiye bir DKIM-Signature başlığı ekler. Açık anahtar DNS'te durur:

s2026._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

Buradaki s2026, seçicidir (selector). Gönderen sistemin keyfî olarak belirlediği bir etikettir ve imza başlığında, imzalayan alan adı d=example.com ile birlikte s=s2026 olarak görünür. Bir alan adının istediği kadar seçicisi olabilir: her gönderim servisi için bir tane, her anahtar değişiminde bir tane daha.

Bunun, insanların sık takıldığı bir sonucu var: bir alan adının "DKIM kaydı" diye sorgulayabileceğiniz tek bir kayıt yoktur. DNS, _domainkey altındaki adları listelemenin bir yolunu sunmaz. Seçiciyi bilmeniz gerekir; bunun güvenilir yolu da o alan adından gerçekten gönderilmiş bir e-postanın başlıklarını açmaktır.

DKIM düz yönlendirmeden sağ çıkar, çünkü imza iletiyle birlikte gider. Aradaki bir sistem imzalı içeriği değiştirdiğinde bozulur; alt bilgi ya da konu etiketi ekleyen birçok e-posta listesinin yaptığı tam da budur.

DMARC: hizalama, politika ve raporlar

DMARC, _dmarc adındaki bir TXT kaydıdır:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-raporlari@example.com"

Üç şey ekler.

Hizalama (alignment). Bir ileti şu iki koşuldan biri sağlandığında DMARC'tan geçer: SPF geçer ve zarf alan adı From alan adıyla hizalıdır, ya da DKIM geçer ve d= alan adı From alan adıyla hizalıdır. Hizalı tek bir geçiş yeterlidir. Varsayılan hizalama gevşektir; yani mail.example.com, example.com ile hizalı sayılır.

Politika. p=none alıcıdan hiçbir işlem yapmamasını, p=quarantine başarısız iletileri şüpheli saymasını (genellikle spam klasörü), p=reject ise iletiyi reddetmesini ister. sp= alt alan adları için ayrı bir politika belirler.

Raporlama. Alıcılar rua adresine günlük toplu XML raporları gönderir: hangi IP'ler sizin adınıza e-posta göndermiş, kaç ileti, SPF ve DKIM geçmiş ve hizalanmış mı. Unuttuğunuz gönderim kaynaklarını bu raporlar sayesinde bulursunuz.

Bir iletinin "SPF'ten geçtiği" halde DMARC'tan kalabilmesinin nedeni hizalamadır. Kendi geri dönüş (bounce) alan adını kullanan bir bülten platformu SPF'ten kendi alan adı için geçer; bu da sizinkiyle hizalı değildir. Çözüm genellikle o platformda özel bir return-path tanımlamak ya da, daha iyisi, kendi alan adınızla DKIM imzalamayı açmaktır.

En sık gördüğümüz hatalar

Birden fazla SPF kaydı

example.com.  TXT  "v=spf1 include:_spf.mail.example.net ~all"
example.com.  TXT  "v=spf1 include:spf.crm.example.org ~all"

v=spf1 ile başlayan iki kayıt kalıcı hatadır (permerror). SPF her ileti için başarısız olur. Genellikle yeni bir servisin kurulum kılavuzu harfiyen uygulandığında ortaya çıkar. İki include'u tek kayıtta birleştirin.

10 sorgu sınırı

Alıcı, SPF'i değerlendirirken en fazla on DNS sorgusu yapabilir. include, a, mx, exists, redirect ve ptr mekanizmalarının her biri sayılır ve include'lar iç içe geçer: tek bir servisin include'u kendi başına üç dört sorguya mal olabilir. ip4, ip6 ve all sorgu harcamaz. Onu aşarsanız sonuç yine permerror olur.

Tercih sırasına göre çözümler: artık kullanmadığınız servisleri kayıttan çıkarın; toplu gönderimleri kendi SPF kaydı olan bir alt alan adına taşıyın; destekleyen servislerde hizalı DKIM'e güvenip include'larını kaldırın. Servis IP'lerini kaydınıza kopyalayan "SPF flattening" yöntemlerine temkinli yaklaşın. Servis IP aralıklarını değiştirdiğinde haberiniz olmadan eskir.

+all

v=spf1 +all internetteki bütün sunucuları yetkilendirir. Hiç kayıt olmamasından daha kötüdür, çünkü sahte e-postanın meşru olduğunu bizzat beyan eder. ?all da pek farklı sayılmaz.

ptr mekanizması

Yavaş, güvenilmez ve SPF standardının kendisi tarafından önerilmiyor. Kaldırın.

Sonsuza kadar p=none

p=none bir izleme modudur. Rapor verir, koruma vermez: herkes From satırına alan adınızı yazmaya devam edebilir ve alıcılar bunu zaten nasıl teslim edeceklerse öyle teslim eder. Pek çok alan adı, toplu gönderici şartlarını kâğıt üzerinde karşılamak için p=none yayınlıyor ve orada kalıyor. Raporlar haftalardır temizse beklemenin bir gerekçesi yoktur.

E-posta göndermeyen alan adlarını unutmak

Park edilmiş ya da yalnızca web sitesi için kullanılan alan adları, tam da kimse bakmadığı için taklit edilir. Bunları kilitleyin:

example.org.         TXT  "v=spf1 -all"
_dmarc.example.org.  TXT  "v=DMARC1; p=reject"
example.org.         MX   0 .

DMARC güvenle nasıl devreye alınır?

  1. Gönderim kaynaklarınızın dökümünü çıkarın. Kurumsal e-posta sağlayıcısı, web sitesi ve uygulama e-postaları, CRM, bülten aracı, faturalama, destek sistemi, izleme uyarıları. Bozulanlar hep unutulanlardır.
  2. SPF'i düzeltin. Tek kayıt, on sorgunun altında, sonu ~all ya da -all.
  3. DKIM'i her yerde açın. Her serviste d= alanında kendi alan adınızla imzalamayı etkinleştirin. En önemli adım budur; çünkü yönlendirmelerde DMARC'ın geçmeye devam etmesini sağlayan DKIM'dir.
  4. rua adresiyle birlikte p=none yayınlayın. Bir posta kutusu ya da rapor işleyen bir servis kullanın; ham XML'i elle okumak keyifli değildir.
  5. İki ila dört hafta raporları okuyun. Hizalamadan kalan meşru kaynakları arayın. Her birini kaynağında düzeltin.
  6. p=quarantine'e geçin. Hacminiz büyükse pct= ile kademeli ilerleyin; örneğin 10, sonra 50, sonra 100. Raporları okumayı sürdürün.
  7. p=reject'e geçin. Alt alan adlarının ayrı bir sp= politikasına ihtiyacı olup olmadığına ayrıca karar verin.
  8. İzlemeye devam edin. Yeni araçlar, DNS'ten sorumlu kişiye haber verilmeden kullanılmaya başlanır. Bunu raporlardan öğrenirsiniz.

Düzeltemeyeceğiniz küçük bir başarısızlık payı kalacaktır; çoğu e-posta listelerinden ve alışılmadık yönlendiricilerden gelir. Birçok alıcı bunları ARC ya da kendi sezgisel kurallarıyla ele alır. Bu, dikkatli ilerlemek için bir nedendir, p=none'da kalmak için değil.

Kayıtların yapamayacağı şeyler

Doğru MX, SPF, DKIM ve DMARC kayıtları, alıcıların e-postanın alan adınız tarafından yetkilendirildiğini doğrulayabilmesi demektir. E-postanızın gelen kutusuna düşeceği anlamına gelmez. E-posta sağlayıcıları alan adınızın ve gönderim IP'lerinizin itibarına, şikâyet oranlarına, liste kalitesine, içeriğe ve alıcıların e-postalarınızla nasıl etkileşime girdiğine de bakar. Bunların hiçbiri DNS'te durmaz.

Kimlik doğrulama giriş biletidir. Büyük sağlayıcılar artık toplu göndericilerden bunu şart koşuyor; yoksa başka hiçbir şeye bakılmadan filtrelenirsiniz. Varsa, gerçekte nasıl gönderim yaptığınıza göre değerlendirilirsiniz.

DNS kontrolü e-postanın akmakta olduğunu da kanıtlayamaz. Yayınladığınız politikanın tutarlı olduğunu gösterebilir; zone üzerinden kontrol ettiğiniz kısım da budur.

OrbitProbe ile kontrol edin

OrbitProbe MX kaydı sorgulama aracı bir alan adının MX, SPF ve DMARC kayıtlarını okur ve yukarıda anlatılan sorunları işaretler: birden fazla SPF kaydı, fazla sorgu, +all, eksik DMARC kaydı ya da p=none'da takılıp kalmış bir politika. DKIM için seçicinizi gönderilmiş bir e-postanın başlıklarında bulun ve secici._domainkey.alanadiniz adını TXT olarak sorgulayın. Bu kayıtların ne zaman değiştiğini bilmek isterseniz, çalışma alanındaki DNS değişiklik izlemesi geçmişi tutar.