Mail Sunucusu için Gereken Tüm DNS Kayıtları

Bir mail sunucusu kurup çalıştırmak işin kolay kısmı; o sunucudan çıkan postanın karşı tarafın gelen kutusuna girmesi ise tamamen DNS meselesidir. Mail sunucusu DNS kayıtları eksik olduğunda sunucu mükemmel çalışıyor gibi görünür — loglar temiz, kuyruk boş, mesajlar "sent" durumunda — ama alıcı hiçbir şey görmez ya da her şey spam klasörüne düşer. Büyük sağlayıcılar artık bir postayı kabul etmeden önce gönderen alan adının kimliğini birden fazla kayıt üzerinden doğruluyor ve bu kayıtlardan birinin eksikliği tek başına teslimatı bitirebiliyor.

Bu rehberde bir mail sunucusunun ihtiyaç duyduğu tüm DNS kayıtlarını sırayla ele alacağım: teslimatı mümkün kılan temel kayıtlar (MX, A, PTR), kimlik doğrulama üçlüsü (SPF, DKIM, DMARC), taşıma güvenliği kayıtları (MTA-STS, TLS-RPT) ve kullanıcı deneyimini kolaylaştıran otomatik yapılandırma kayıtları. Her biri için doğru biçimi, sık yapılan hatayı ve doğrulama komutunu vereceğim. Sonunda da hepsini tek seferde kontrol edebileceğin bir doğrulama listesi bırakacağım, çünkü bu kayıtların hepsi ayrı ayrı doğru olsa bile birbirleriyle tutarsız olduklarında yine sorun çıkarırlar.

Kayıtların Tam Listesi ve Zorunluluk Durumu#

Önce haritayı görelim. Aşağıdaki tablo, bir mail sunucusunun ihtiyaç duyduğu tüm kayıtları ve her birinin ne kadar kritik olduğunu özetliyor:

"Fiilen zorunlu" ifadesini bilerek kullanıyorum: standart açısından SPF, DKIM ve DMARC isteğe bağlıdır, ama büyük posta sağlayıcıları bunları olmayan gönderenleri düzenli olarak reddediyor ya da spam'e yolluyor. Yani pratikte zorunludurlar.

Temel Kayıtlar: MX, A ve PTR#

Gelen posta tarafında ihtiyacın olan iki kayıt var: MX ve onun gösterdiği ismin A kaydı.

; Gelen posta hangi sunucuya teslim edilecek
firmaniz.com.        3600  IN  MX  10  mail.firmaniz.com.

; MX'in gösterdiği isim mutlaka A kaydına sahip olmalı
mail.firmaniz.com.   3600  IN  A     185.12.34.56
mail.firmaniz.com.   3600  IN  AAAA  2a01:4f8:1c1c::56

Buradaki değişmez kural şu: MX bir isim gösterir, asla IP göstermez, ve gösterdiği isim CNAME olamaz. MX kaydına doğrudan IP yazarsan kayıt geçersiz olur; hedef bir CNAME ise pek çok sunucu teslimatı reddeder. Öncelik değerlerinin nasıl çalıştığını ve birden fazla MX kurmanın sonuçlarını MX önceliği ve yedek MX yazısında ayrıntısıyla anlattım.

Giden posta tarafında ise PTR kaydı en kritik kalemdir ve tek başına en çok teslimat sorununa sebep olan eksikliktir. PTR, IP adresinden isme çeviri yapar ve alıcı sunucular bunu "bu IP gerçekten iddia ettiği sunucu mu" kontrolü için kullanır. PTR kaydını kendi DNS panelinden oluşturamazsın; ters bölge IP bloğunun sahibine, yani sunucu sağlayıcına aittir. Sağlayıcının panelinden ya da destek talebiyle ayarlatman gerekir.

# IP'nin PTR kaydını sorgula
dig +short -x 185.12.34.56
# mail.firmaniz.com.

# Ve o ismin geri dönüşte aynı IP'ye çıktığını doğrula (ileri-geri tutarlılık)
dig +short A mail.firmaniz.com
# 185.12.34.56

Bu iki sorgunun birbirini doğrulaması gerekir; buna ileri-geri DNS tutarlılığı denir. Ayrıca sunucunun SMTP oturumunda kendini tanıttığı HELO/EHLO adının da bu isimle aynı olması gerekir. Postfix'te bunu myhostname belirler:

# /etc/postfix/main.cf
myhostname = mail.firmaniz.com
mydomain = firmaniz.com
smtp_helo_name = mail.firmaniz.com

PTR, A kaydı ve HELO adının üçünün birbirini tutması, giden postanın büyük sağlayıcılar tarafından ciddiye alınmasının ön koşuludur.

SPF: Kim Senin Adına Gönderebilir#

SPF kaydı, alan adının adına posta gönderme yetkisi olan sunucuları listeleyen bir TXT kaydıdır. Alıcı sunucu, mesajın geldiği IP'nin bu listede olup olmadığını kontrol eder.

; Alan adının kökünde tek bir SPF kaydı
firmaniz.com.  3600  IN  TXT  "v=spf1 mx a:mail.firmaniz.com ip4:185.12.34.56 -all"

Mekanizmaları tek tek açayım: mx alan adının MX kayıtlarındaki sunucuları yetkilendirir, a: belirli bir ismin IP'sini, ip4:/ip6: doğrudan bir adresi, include: ise başka bir alan adının SPF politikasını devreye alır (bülten servisleri ya da bulut posta sağlayıcıları için kullanılır). Sondaki niteleyici ise politikanın sertliğini belirler:

Üç kritik kural var. Birincisi, bir alan adı için yalnızca tek bir SPF kaydı olabilir; iki ayrı TXT kaydı yazarsan doğrulama tamamen başarısız olur, hepsini tek satırda birleştirmen gerekir. İkincisi, SPF'in 10 DNS sorgusu sınırı vardır; include: ve a: gibi mekanizmalar sorgu üretir ve sınırı aşarsan kayıt "permerror" verip işe yaramaz hale gelir. Üçüncüsü, -all yazmadan önce gönderim yapan tüm kaynakları (web sunucusu, CRM, fatura sistemi, bülten servisi) listeye eklediğinden emin ol; unuttuğun bir kaynak sessizce reddedilmeye başlar.

DKIM: Mesajı İmzalamak#

DKIM, giden her mesaja kriptografik bir imza ekler ve doğrulama için gereken açık anahtarı DNS'te yayınlar. SPF'ten farkı şudur: SPF gönderen IP'yi doğrular, DKIM ise mesajın içeriğinin yolda değişmediğini ve gerçekten o alan adından çıktığını doğrular. Bu yüzden yönlendirilen (forward edilen) postalarda SPF bozulurken DKIM ayakta kalır.

Anahtar çiftini sunucuda üretirsin. OpenDKIM kullanıyorsan:

# 2048 bitlik anahtar çifti üret, seçici (selector) adı: mail2026
sudo opendkim-genkey -b 2048 -d firmaniz.com -s mail2026 -D /etc/opendkim/keys/

# Özel anahtarın yetkilerini daralt
sudo chown opendkim:opendkim /etc/opendkim/keys/mail2026.private
sudo chmod 600 /etc/opendkim/keys/mail2026.private

# DNS'e yazılacak açık anahtarı görüntüle
sudo cat /etc/opendkim/keys/mail2026.txt

Çıktıdaki değeri DNS'e şu biçimde eklersin — kaydın adı <seçici>._domainkey olmak zorundadır:

mail2026._domainkey.firmaniz.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; p=MIIBIjANBgkq"
  "hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." )

En sık yaşanan sorun burada çıkar: 2048 bitlik bir anahtarın açık kısmı 255 karakteri aşar ve DNS'te tek bir TXT dizesi bu sınırı geçemez. Bu yüzden değer yukarıdaki gibi tırnak içinde parçalara bölünür ve DNS sunucusu bunları birleştirir. Panel bu bölmeyi otomatik yapmıyorsa değeri elle bölmen gerekir; bu konunun ayrıntısı için DKIM TXT kaydı 255 karakter sınırı yazısına bak. İmza doğrulaması başarısız oluyorsa DKIM doğrulaması başarısız yazısı teşhis adımlarını içeriyor.

DMARC: Politikayı Belirlemek#

DMARC, "SPF ve DKIM kontrolleri başarısız olursa ne yapılsın" sorusuna cevap veren kayıttır. Ayrıca gönderdiği raporlarla alan adın adına kimlerin posta gönderdiğini görmeni sağlar; bu görünürlük, kaydın en değerli yanıdır.

; Başlangıç: sadece izle, hiçbir postayı engelleme
_dmarc.firmaniz.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100; adkim=r; aspf=r"

; Olgunlaşınca: şüphelileri karantinaya al
_dmarc.firmaniz.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

; Nihai hedef: sahte postaları tamamen reddet
_dmarc.firmaniz.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s"

Etiketleri açıklayayım: p= politikayı belirler (none, quarantine, reject), rua= toplu raporların gönderileceği adresi, pct= politikanın uygulanacağı mesaj yüzdesini, adkim/aspf ise hizalama sıkılığını (r gevşek, s sıkı) belirtir.

Doğru yaklaşım kademelidir ve acele etmemek gerekir: p=none ile başla, gelen raporları en az birkaç hafta oku, alan adın adına gönderim yapan tüm meşru kaynakları tespit et, hepsini SPF ve DKIM ile doğrulanır hale getir, sonra quarantinee, en sonunda rejecte geç. Doğrudan p=reject ile başlarsan farkında olmadığın bir gönderim kaynağının (muhasebe yazılımı, form bildirimi, eski bir sunucu) tüm postaları anında kaybolur. Raporları okumayı öğrenmek için DMARC raporu nasıl okunur yazısı iyi bir başlangıç.

MTA-STS, TLS-RPT ve Otomatik Yapılandırma#

Bu üçü "olmasa da olur" kategorisinde görünür ama ciddi bir kurumsal altyapıda hepsini kurmanı öneririm.

MTA-STS, gönderen sunuculara "bana posta teslim ederken mutlaka geçerli sertifikayla TLS kullan" der ve pasif dinleme ile STARTTLS düşürme saldırılarını engeller. İki parçadan oluşur: bir TXT kaydı ve HTTPS üzerinden yayınlanan bir politika dosyası.

_mta-sts.firmaniz.com.  3600  IN  TXT  "v=STSv1; id=20260825120000"

Politika dosyası tam olarak şu adreste, text/plain olarak sunulmalıdır: https://mta-sts.firmaniz.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mail.firmaniz.com
max_age: 604800

mode değerini önce testing yapıp TLS-RPT raporlarını izle, sorun görmüyorsan enforcea geçir. TXT kaydındaki id değerini politika dosyasını her değiştirdiğinde güncellemen gerekir, yoksa gönderen sunucular önbellekteki eski politikayı kullanmaya devam eder.

TLS-RPT ise TLS bağlantı sorunlarının sana raporlanmasını sağlar:

_smtp._tls.firmaniz.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

Otomatik yapılandırma kayıtları, kullanıcıların posta istemcisini kurarken sunucu adı ve port girmesini gereksiz kılar. SRV kayıtları standart yoldur:

; IMAP over SSL (993)
_imaps._tcp.firmaniz.com.  3600  IN  SRV  0 1 993 mail.firmaniz.com.
; Submission (587)
_submission._tcp.firmaniz.com.  3600  IN  SRV  0 1 587 mail.firmaniz.com.

Outlook istemcileri ayrıca autodiscover.firmaniz.com adına bir CNAME ya da A kaydı arar. İstemci kurulum adımlarını Outlook e-posta istemci kurulumu yazısında bulabilirsin.

Hepsini Tek Seferde Doğrulamak#

Kayıtları girdikten sonra hepsini birden kontrol eden küçük bir script işini çok kolaylaştırır:

#!/bin/bash
# mail-dns-check.sh - tüm posta kayıtlarını sırayla doğrula
D="firmaniz.com"
H="mail.firmaniz.com"
S="mail2026"      # DKIM seçicisi
IP="185.12.34.56"

echo "== MX ==";      dig +short MX "$D"
echo "== A ==";       dig +short A "$H"
echo "== PTR ==";     dig +short -x "$IP"
echo "== SPF ==";     dig +short TXT "$D"   | grep -i 'v=spf1'
echo "== DKIM ==";    dig +short TXT "$S._domainkey.$D" | head -c 120; echo
echo "== DMARC ==";   dig +short TXT "_dmarc.$D"
echo "== MTA-STS =="; dig +short TXT "_mta-sts.$D"
echo "== TLS-RPT =="; dig +short TXT "_smtp._tls.$D"

Çıktıyı okurken şu tutarlılıkları özellikle kontrol et: PTR'nin döndüğü isim ile myhostname aynı mı, SPF kaydı tek mi ve sunucunun IP'sini kapsıyor mu, DKIM seçicisi sunucudaki imzalama yapılandırmasıyla aynı mı. Bu üç tutarsızlık, kayıtların hepsi "var" göründüğü halde teslimatın çalışmamasının en sık sebebidir.

Sık Yapılan Hatalar#

En yaygın hata, birden fazla SPF kaydı tanımlamaktır. Yeni bir servis eklerken mevcut kaydı düzenlemek yerine ikinci bir TXT kaydı eklemek doğrulamayı tamamen bozar; sonuç "hiç SPF yok"tan bile kötüdür çünkü permerror üretir. Yeni kaynakları mevcut kaydın içine include: ya da ip4: olarak ekle.

İkinci hata, PTR kaydını atlamaktır. Kendi DNS panelinden yapamadığın için unutulması kolaydır ama büyük sağlayıcıların önemli bir kısmı PTR'siz IP'den gelen postayı doğrudan reddeder. Sunucuyu kiraladığın gün sağlayıcıdan talep et.

Üçüncü hata, DMARC'ı doğrudan p=reject ile başlatmaktır. Farkında olmadığın gönderim kaynakları vardır ve hepsi bir anda susar; üstelik bu sessizlik uzun süre fark edilmez. Dördüncü hata, DKIM anahtarını üretip sunucuda imzalamayı açtıktan sonra DNS kaydını eklemeyi ertelemektir — bu durumda imza var ama doğrulanamaz, ki doğrulanamayan bir imza hiç imza olmamasından daha kötüdür.

Beşinci hata, TTL değerlerini çok yüksek bırakıp sonra acele bir değişiklik yapmak zorunda kalmaktır. Posta kayıtlarında 3600 makul bir varsayılandır; planlı bir geçiş öncesinde 300e indir. Altıncı hata ise MTA-STS politikasını değiştirip TXT kaydındaki id değerini güncellememektir; politika dosyasını değiştirmen gönderen sunucular için hiçbir anlam ifade etmez. Son olarak, kayıtları girdikten sonra sadece bir kez test edip bir daha bakmamak da yaygındır — bu kayıtların doğruluğunu düzenli izlemek için mail sunucusu izleme yazısındaki yaklaşımı kullanabilirsin.

Sıkça Sorulan Sorular#

Mail sunucusu için hangi DNS kayıtları zorunlu#

Gelen posta için MX kaydı ve onun gösterdiği ismin A kaydı teknik olarak zorunludur. Giden posta için ise PTR, SPF, DKIM ve DMARC standart açısından isteğe bağlı görünse de pratikte zorunludur: büyük sağlayıcılar bu kayıtları eksik olan gönderenleri reddediyor ya da spam'e yolluyor. Yani gerçek bir kurulumda altısını da tamamlaman gerekir.

PTR kaydını kendim oluşturabilir miyim#

Hayır. PTR kaydı IP adresinin ters bölgesinde tutulur ve bu bölge IP bloğunun sahibine, yani sunucu sağlayıcına aittir. Kendi alan adı DNS panelinden ekleyemezsin. Sağlayıcının kontrol panelinde rDNS ayarı varsa oradan, yoksa bir destek talebiyle mail.firmaniz.com gibi bir isim tanımlatman gerekir. Bu ismin A kaydının da aynı IP'ye dönmesi şarttır.

SPF kaydını iki satır yazabilir miyim#

Hayır, bir alan adının kökünde yalnızca tek bir SPF kaydı olabilir. İki ayrı TXT kaydı tanımlarsan doğrulama permerror verir ve SPF hiç yokmuş gibi, hatta ondan daha kötü davranılır. Yeni bir gönderim kaynağı eklemen gerekiyorsa mevcut kaydın içine include: veya ip4: mekanizması olarak ekle ve toplam DNS sorgu sayısının onu aşmamasına dikkat et.

DKIM anahtarı kaç bit olmalı#

2048 bit yaygın ve önerilen seçimdir; 1024 bit hâlâ çalışır ama artık zayıf sayılır. 2048 bitlik anahtarın DNS kaydı 255 karakteri aşacağı için değeri tırnaklı parçalara bölmen gerekebilir. Anahtarı yılda bir kez yenilemek (yeni bir seçici adıyla) iyi bir alışkanlıktır; eski seçiciyi hemen silmeyip birkaç gün ikisini birlikte yayınla.

DMARC politikasını ne zaman reject yapmalıyım#

Ancak alan adın adına gönderim yapan tüm meşru kaynakları tespit edip hepsini SPF ve DKIM ile doğrulanır hale getirdikten sonra. Pratik yol şudur: p=none ile başla, raporları en az birkaç hafta oku, eksik kaynakları tamamla, sonra p=quarantinee geç, orada da sorun görmezsen p=rejecte çıkar. Bu süreç genellikle birkaç haftadan birkaç aya kadar sürer ve acele edilmemelidir.

DNS kayıtlarını değiştirdim ama teslimat düzelmedi, neden#

Muhtemelen TTL süresi dolmamıştır; kayıtların eski değerleri hâlâ çözümleyicilerin önbelleğindedir. dig ile kendi tarafından sorgulayıp yeni değerin döndüğünü doğrula, sonra TTL süresi kadar bekle. Değerler doğru dönüyorsa sorun DNS'te değil tutarlılıktadır: PTR ismi ile HELO adının aynı olduğunu, DKIM seçicisinin sunucudaki yapılandırmayla eşleştiğini ve SPF'in sunucunun gerçek çıkış IP'sini kapsadığını kontrol et.

Kapanış#

Posta altyapısında DNS, sunucunun kendisi kadar önemlidir ve genellikle sorunların kaynağıdır. Aklında kalması gereken dört alışkanlık: PTR, A kaydı ve HELO adının üçünün birbirini tutması giden postanın ön koşuludur; SPF kaydı tek olmalı ve on sorgu sınırını aşmamalıdır; DMARC'ı p=none ile başlatıp raporları okumadan sertleştirme; ve her değişiklikten sonra dig ile dışarıdan doğrula, panelde gördüğünle yetinme. Bu dördünü uygularsan teslimat sorunlarının büyük bölümü hiç ortaya çıkmaz.

Bu kayıtları kurmakla uğraşmak istemiyorsan Clou.TR tarafında işi devralabileceğimiz noktalar var. E-posta paketlerimizde MX, SPF ve DKIM kayıtları kurulumla birlikte hazır gelir; kendi sunucunu işletiyorsan VDS ve SMTP sunucu çözümlerimizde PTR kaydını destek üzerinden tanımlatabilirsin. DNS ve mail yapılandırmasını tamamen devretmek istersen sunucu yönetimi hizmetimize, alan adı yönetimi için de alan adı sayfamıza bakabilirsin.