Alan Adı ile Profesyonel E-posta: SPF, DKIM ve DMARC Ayarları

Alan adınızla profesyonel e-posta göndermek, hem marka algınız hem de teslim edilebilirlik (deliverability) açısından kritik. Ancak sadece MX kaydını doğru ayarlamak, artık tek başına yeterli değil. Son birkaç yılda hem kurumsal projelerde hem de küçük girişimlerde gördüğüm en büyük problem, SPF, DKIM ve DMARC ayarları yapılmadığı için e-postaların spam klasörüne düşmesi ya da hiç teslim edilmemesi oldu. Özellikle teklif, fatura ve sözleşme gibi kritik maillerin kaybolması; sadece teknik bir detay değil, doğrudan gelir ve itibar kaybı anlamına geliyor.

Daha önce alan adınızla e-posta kurulumuna genel bakış sunduğum alan adınızla profesyonel e-posta kurulumu rehberinde MX ve temel DNS ayarlarına odaklanmıştım. Bu yazıda ise bir seviye daha derine inip, SPF, DKIM ve DMARC üçlüsünü uçtan uca, adım adım ve gerçek senaryolar üzerinden anlatacağım. Hedefim; okurken hem mantığını kavramanız hem de yazıyı bitirdiğinizde DNS panelinize girip bu ayarları çekinmeden uygulayabilecek seviyeye gelmeniz.

Neden SPF, DKIM ve DMARC Zorunlu Hale Geldi?

E-posta, hala iş dünyasının bel kemiği. Ama aynı zamanda phishing (oltalama) ve spam saldırılarının da en çok kullanıldığı kanal. Büyük e-posta sağlayıcıları (Gmail, Outlook, kurumsal mail gateway’leri vb.) bu yüzden her gelen e-postaya güvenmiyor; önce kaynağını, imzasını ve politikalarını kontrol ediyor.

Bu noktada üç temel mekanizma devreye giriyor:

SPF: Bu alan adı adına hangi sunucuların e-posta göndermeye yetkili olduğunu tanımlar.
DKIM: Gönderilen e-postayı dijital olarak imzalar; içerik yolda değiştirilmiş mi, gerçekten o alan adından mı gelmiş, bunu kanıtlar.
DMARC: SPF ve DKIM sonuçlarına bakarak, alıcı sunucuya bu alan adı için nasıl davranması gerektiğini söyler (raporla, karantinaya al, tamamen reddet gibi).

Yani üçü birlikte, alan adınızı sahteciliğe karşı koruyan bir güvenlik katmanı oluşturuyor. DNS tarafına ilginiz varsa, bu kayıtların aslında TXT kayıtları olarak tutulduğunu, detaylı DNS mantığını ise DNS kayıtları nedir rehberinde daha geniş açıdan ele almıştım.

SPF Kaydı Nedir, Nasıl Çalışır?

SPF (Sender Policy Framework), özetle şunu yapar: Bir alan adı için, hangi IP adreslerinin veya hangi sunucuların e-posta göndermeye yetkili olduğunu dünyaya ilan eder. Bunu, DNS üzerinde bir TXT kaydı olarak yayınlayarak gerçekleştirirsiniz.

Bir alıcı sunucu, sizden gelen e-postayı aldığında, gönderen alan adının SPF kaydına bakar. Eğer e-postayı gönderen IP, SPF kaydındaki listeye uyuyorsa, SPF kontrolü geçer. Uymuyorsa, SPF başarısız olur ve bu mail büyük ihtimalle spam puanı yer.

SPF kaydı temel yapı

Basit bir SPF kaydı şu şekilde görünür:

v=spf1 a mx include:mailservisiniz.com ~all

Bunu parçalara bölersek:

v=spf1: Versiyon bilgisi. Her SPF kaydı bununla başlar.
a: Alan adınızın A kaydındaki IP, mail göndermeye yetkilidir.
mx: Alan adınızın MX kayıtlarındaki sunucular mail gönderebilir.
include:…: Harici bir e-posta servisini (örneğin kullandığınız bir e-posta sağlayıcısını veya e-posta pazarlama sistemini) yetkilendirir.
~all: Bu kayıtlar dışındaki her şey için “soft fail” uygula (yani şüphe et ama direkt çöpe atma).

Daha sıkı bir politika isterseniz -all kullanırsınız; bu da “bu listedekiler dışında kimse gönderemez, geleni reddet” anlamına gelir.

SPF kaydını adım adım ekleme

Genelde SPF kaydını eklemek için şu adımları izliyorum:

Mevcut durumu çıkarın: Hangi sistemlerden mail gönderiyorsunuz? Örnek: kendi mail sunucunuz, CRM sistemi, e-posta pazarlama servisi, helpdesk yazılımınız.
DNS yönetim paneline girin: Alan adınızı nerede yönetiyorsanız (örn. DCHost DNS paneli ya da alan adı sağlayıcınızın paneli), DNS yönetim bölümüne geçin.
TXT kaydı oluşturun: Yeni bir TXT kaydı ekleyin. Host/Ad kısmına genellikle boş bırakılır veya @ yazılır (alan adının kökünü temsil eder).
Değer kısmını doldurun: Örneğin sadece kendi sunucunuz ve MX’iniz mail gönderecekse: v=spf1 a mx -all
Kaydı kaydedin ve DNS yayılımını bekleyin: Genellikle birkaç dakikada aktif olur, ama 24 saate kadar sürebilir.

Daha karmaşık SPF senaryolarında, özellikle çok sayıda harici servis kullanıyorsanız, SPF’in 10 DNS lookup sınırı olduğunu unutmayın. Fazla include kullanmak, SPF kaydınızın çalışmamasına neden olabilir. Bu gibi durumlarda kayıtları sadeleştirmek veya servisleri konsolide etmek iyi bir strateji.

DKIM İmzaları: Gönderdiğiniz E-postanın Dijital Mührü

DKIM (DomainKeys Identified Mail), e-postalarınıza kriptografik bir imza ekler. Amaç şu: Alıcı taraf, gelen e-postanın gerçekten sizin alan adınızdan gönderildiğini ve içerik yolda değiştirilmemiş olduğunu doğrulayabilsin.

DKIM, iki parçadan oluşur:

Mail sunucunuzda tutulan gizli anahtar (private key)
DNS üzerinde TXT kaydı olarak yayınladığınız açık anahtar (public key)

Mail sunucunuz, her gönderdiği e-postanın belirli bölümlerini gizli anahtar ile imzalar. Alıcı sunucu ise DNS’ten açık anahtarı çeker ve imzayı doğrular. Açık anahtarınızı kaldırırsanız ya da değiştirirseniz, eski imzalar artık doğrulanamaz.

DKIM selector nedir?

DKIM kayıtlarında sıkça gördüğünüz selector, aynı alan adı için birden fazla DKIM anahtarı kullanabilmenizi sağlar. Örneğin:

Mail sunucunuz için: selector1._domainkey.ornekdomain.com
Pazarlama aracı için: marketing._domainkey.ornekdomain.com

Her bir selector, farklı bir açık anahtar barındırır. Bu sayede, bir servisle çalışmayı bıraktığınızda sadece o servisle ilişkili selector kaydını silebilir veya döndürebilirsiniz.

DKIM DNS kaydı nasıl eklenir?

DKIM adımları genelde şöyle ilerliyor:

Anahtarı oluşturun: Çoğu e-posta servisi veya kontrol paneli (örn. kendi mail sunucunuz, paneliniz veya kullandığınız SaaS e-posta hizmeti) sizin için DKIM anahtarı üretir ve size bir DNS kaydı metni verir.
Selector’ı not alın: Size genellikle ‘default’, ‘s1’ veya benzeri bir selector adı verilir. Bu, TXT kaydının host kısmında kullanacağınız değerdir.
DNS’e TXT kaydı ekleyin: Host/Ad alanına örneğin default._domainkey yazın (panel otomatik olarak alan adını sona ekler). Değer kısmına ise size verilen uzun DKIM anahtar metnini girin.
Kaydedin ve doğrulayın: Birçok servis kendi panelinde “DKIM doğrula” butonu sunar. Yoksa harici DKIM checker araçlarıyla kontrol edebilirsiniz.

Burada en sık gördüğüm hata, verilen DKIM metninin satır sonlarıyla birlikte yanlış kopyalanması veya tırnak işaretlerinin hatalı eklenmesi. DNS paneliniz izin veriyorsa, metni tek satır halinde yapıştırmanız çoğu zaman en güvenli yoldur.

DMARC Politikası ile Alan Adınızı Kötüye Kullanıma Karşı Korumak

DMARC (Domain-based Message Authentication, Reporting and Conformance), SPF ve DKIM sonuçlarına göre alıcı sunuculara ne yapmaları gerektiğini söyleyen bir politika çerçevesidir. Aynı zamanda size rapor göndererek, alan adınız adına kimlerin mail gönderdiğini görmenizi sağlar.

DMARC da bir TXT kaydı olarak yayınlanır ve genellikle şu host adıyla kullanılır:

_dmarc.ornekdomain.com

Basit bir DMARC kaydı örneği:

v=DMARC1; p=none; rua=mailto:dmarc-rapor@ornekdomain.com; ruf=mailto:dmarc-adli@ornekdomain.com; fo=1

v=DMARC1: Versiyon bilgisi.
p=: Politika (none, quarantine, reject).
rua=: Toplu (aggregate) raporların gönderileceği e-posta adresi.
ruf=: Ayrıntılı (forensic) raporların gönderileceği adres (her alıcı desteklemeyebilir).
fo=: Hata raporlama seçenekleri.

DMARC politikaları: none, quarantine, reject

DMARC’ın kalbi p= ile belirlediğiniz politikadır:

p=none: Aslında hiçbir şeyi engelleme, sadece rapor gönder. İlk başlangıç için ideal; yanlış yapılandırmaları görmenizi sağlar.
p=quarantine: DMARC kontrolünü geçemeyen mailleri spam/junk klasörüne at.
p=reject: DMARC kontrolünü geçemeyen mailleri tamamen reddet, kullanıcıya hiç gösterme.

Ben genelde projelerde şu yolu izliyorum:

Önce SPF ve DKIM’i düzgünce kuruyorum.
DMARC’ı p=none ile ekleyip, en az 1-2 hafta raporları izliyorum.
Yanlış yapılandırmalar düzeldikten sonra p=quarantine seviyesine çıkıyorum.
Her şey stabil olduğunda ve sahte trafik azaldığında p=reject ile alan adını tam korumaya alıyorum.

DMARC raporlarını okumak

DMARC raporları genelde XML formatında gelir ve ilk başta göz korkutucu olabilir. Bu raporlar, alan adınız adına kimlerin mail gönderdiğini, hangi IP’lerden geldiğini ve SPF/DKIM sonuçlarını listeler. Raporları doğrudan okumak yerine; çıktıları anlamlandıran basit analiz araçlarından faydalanabilirsiniz.

Bu raporlar sayesinde, örneğin şirketinizde kimsenin kullanmadığı halde belirli bir IP’den düzenli mail çıkışı varsa, bunu çok hızlı bir şekilde fark eder ve aksiyon alırsınız. Güvenlik tarafına ilginiz varsa, bu noktayı veri merkezlerinde siber saldırılara karşı alınması gereken önlemler ile birlikte düşünmek faydalı olur.

Farklı Senaryolar: Kendi Sunucun, Harici Servisler ve Hibrit Kurulumlar

SPF, DKIM ve DMARC teoride net, ama pratikte iş karışabiliyor. Özellikle birden fazla kaynaktan mail gönderiyorsanız. Sık gördüğüm üç senaryoya bakalım:

1. Sadece kendi mail sunucunuz var

Bu en basit senaryo. Örneğin alan adınız ve mail sunucunuz aynı Hosting firmasında (DCHost gibi) ve tüm mailleri oradan gönderiyorsunuz.

SPF: v=spf1 a mx -all genelde yeterli.
DKIM: Sunucunuzda DKIM anahtarı üretip, tek bir selector ile DNS’e ekliyorsunuz.
DMARC: Önce p=none, sonra aşamalı olarak quarantine ve reject.

2. Kendi sunucunuz + e-posta pazarlama servisi

Burada SPF tarafında include kullanmanız gerekiyor. Örneğin:

v=spf1 a mx include:emailservisiniz.com -all

Aynı şekilde, pazarlama servisiniz de sizden genelde bir DKIM kaydı ister. Böylece o servis üzerinden giden mailler de alan adınızla imzalanır. Bu tür karmaşık DNS senaryolarına alışkın değilseniz, DNS kayıtları A’dan Z’ye yönetim rehberi kafanızdaki birçok soru işaretini temizleyecektir.

3. Sadece harici kurumsal e-posta servisi kullanıyorsunuz

Eğer tüm e-postalarınızı tek bir harici e-posta sağlayıcısı üzerinden gönderiyorsanız, işiniz görece daha kolay. Sağlayıcınız genelde size şu üç bilgiyi verir:

SPF için bir include:… satırı
Bir veya daha fazla DKIM selector ve anahtar metni
Opsiyonel DMARC örnek kaydı

Bu durumda DNS yönetiminizi nerede yaparsanız yapın (DCHost veya Alan Adı Kayıt firmanız), tek yapmanız gereken bu kayıtları doğru şekilde kopyalayıp eklemek. Yine de DMARC politikasını ilk etapta none ile başlatmak, yapılabilecek küçük hataların etkisini minimuma indirir.

Yaygın Hatalar ve Test Araçları

Hem kendi projelerimde hem de danışmanlık verdiğim firmalarda en çok gördüğüm hatalar genelde aynı:

Birden fazla SPF kaydı eklemek: SPF, alan adı başına sadece bir TXT kaydı olarak tanımlanmalıdır. Birden fazla SPF kaydı, tamamının geçersiz sayılmasına yol açar.
10 lookup sınırını aşmak: Çok fazla include kullanırsanız SPF kaydınız çalışmayı durdurabilir.
Yanlış host adıyla DMARC eklemek: DMARC kaydının host kısmı mutlaka _dmarc olmalıdır.
DKIM anahtarının eksik/bozuk yapıştırılması: Satır sonu, tırnak veya boşluk hataları sık görülür.
DMARC’ı direkt reject ile başlatmak: Yanlış yapılandırılmış bir sistemde bu, bir anda tüm maillerinizin reddedilmesine neden olabilir.

Kurulumdan sonra mutlaka test etmenizi öneririm. Genelde şu adımı uyguluyorum:

Kendime veya farklı sağlayıcılardaki (Gmail, Outlook vb.) adreslere deneme mailleri gönderiyorum.
Ham mesaj (show original / message source) içinden SPF, DKIM ve DMARC sonuçlarına bakıyorum.
Harici SPF/DKIM/DMARC test araçlarıyla DNS kayıtlarını doğruluyorum.

Unutmayın, e-posta güvenliği başlı başına bir alan. Aynı hassasiyeti web tarafında da göstermek için, SSL/HTTPS yapılandırmasını da doğru yapmak lazım. Bu konuda kararsızsanız, ücretsiz Let’s Encrypt mi, ücretli SSL mi karşılaştırmasını okumanızı öneririm.

Sonuç ve Sonraki Adımlar

Özetle SPF, DKIM ve DMARC; alan adınızla gönderdiğiniz her e-postanın kimlik kartı, imzası ve güvenlik politikası gibi düşünebileceğiniz üç temel yapı taşı. SPF ile hangi sunucuların sizin adınıza konuşabileceğini belirliyorsunuz, DKIM ile gönderdiğiniz mesajları kriptografik olarak imzalıyorsunuz, DMARC ile de bu iki mekanizmanın sonucuna göre alıcı sunuculara net talimatlar veriyorsunuz.

Yeni bir projeye başladığımda, alan adı tescili ve hosting seçimi kadar, bu üçlünün kurulumunu da temel mimari tasarımın parçası olarak görüyorum. İster Paylaşımlı hosting, ister VPS, ister özel bir sunucu kullanın; e-posta altyapınızın sağlıklı çalışması için DNS tarafında bu kayıtları doğru kurgulamak şart. Sunucu tarafında daha derine inmek isterseniz, doğru sunucu mimarisini seçme rehberine de göz atabilirsiniz.

Buradan sonra atabileceğiniz adımlar net:

DNS panelinize girip mevcut SPF, DKIM ve DMARC kayıtlarınızı kontrol edin.
Eksik olanları ekleyin, hatalı olanları düzeltin.
DMARC’ı önce none ile başlatın, raporları izleyin, ardından kademeli olarak sıkılaştırın.

Eğer DCHost gibi DNS yönetimini sadeleştiren bir altyapı kullanıyorsanız, bu süreci birkaç saat içinde tamamlamak mümkün. Doğru kurgulanmış bir e-posta altyapısı; hem teslim edilebilirlik oranınızı hem de marka itibarınızı gözle görülür şekilde artıracak. Bugün birkaç saatinizi ayırıp bu ayarları yapmanız, uzun vadede size yüzlerce saatlik kriz yönetimi ve kayıp fırsat maliyetinden fazlasını kazandıracak.