Rehber 18 Haziran 2026 · 7 dakika okuma

DNSSEC ile E-posta Deliverability: Spam Riskini Azaltan Kontrol Listesi

DNSSEC tek başına spamı bitirmez. Bu kontrol listesiyle DNSSEC + SPF/DKIM/DMARC doğrulamalarını adım adım test edip teslim edilebilirliği artırın.

E-posta teslim edilebilirliği (deliverability), sadece e-posta içeriğine bağlı değildir; gönderdiğiniz alan adının (domain) kimlik doğrulama zinciri de sonuçları belirler. Yanlış veya eksik DNS doğrulamaları, alıcı sunucuların mesajı şüpheli görmesine ve spam klasörüne düşmesine yol açabilir. Bu rehberde, DNSSEC (Domain Name System Security Extensions) üzerinden alan adı güvenini artırırken, e-posta doğrulama mekanizmelerini de birlikte ele alacağınız uygulanabilir bir kontrol listesi bulacaksınız. Amaç: spam riskini azaltmak ve sorun oluştuğunda hızlı teşhis edebilmektir.

1) İlk hedefi netleştirin: DNSSEC neyi sağlar, neyi tek başına çözmez?

DNSSEC ile alan adınızın DNS kayıtları (A/AAAA/CNAME/MX/TXT vb.) kriptografik olarak doğrulanır. Bu, saldırganın DNS spoofing (DNS sahtekârlığı) yaparak MX veya doğrulama kayıtlarınızı değiştirmesini zorlaştırır. Ancak e-posta teslimi için alıcılar asıl olarak şunlara bakar:

  • SPF (Sender Policy Framework): Gönderen IP’nin yetkili olup olmadığı
  • DKIM (DomainKeys Identified Mail): Mesajın kriptografik imzasının doğrulanması
  • DMARC (Domain-based Message Authentication, Reporting & Conformance): SPF/DKIM uyumunu ve politika uygulamasını

Net sonuç: DNSSEC, kimlik doğrulama kayıtlarınızın bütünlüğünü artırır. Ama SPF/DKIM/DMARC yanlışsa, alıcılar yine teslim edilmeme/şüphe sinyali üretebilir. Bu yüzden kontrol listesini “DNSSEC + e-posta doğrulaması” birlikte düşünerek uygulayın.

Hızlı hedef ölçümü

Aşağıdaki ölçümlerin her birini bir hedef olarak belirleyin: - SPF/DKIM/DMARC sonuçları pass olmalı. - DMARC raporlarında “alignment” sorunları azalmış olmalı. - Teslim edilebilirlikte (özellikle yeni domain / IP ısınması sonrası) spam klasörü oranı düşmelidir.

2) DNSSEC hazırlık: zinciri doğru kurun (parent/child zinciri dahil)

DNSSEC kurulumu “tek tuş” değildir; domain zinciri boyunca güven oluşturmanız gerekir. Birçok sorun, DS anahtarının (Delegation Signer) üst seviyede (parent) doğru olmamasından veya algoritma/anahtar sürelerinin yanlış yapılandırılmasından çıkar.

Uygulanabilir kontrol listesi

  • [ ] Domain kayıt kuruluşunda DNSSEC özelliği varsa etkinleştirin.
  • [ ] DNS sağlayıcınız (authoritative DNS) DNSSEC imzalama (signing) yapıyor mu kontrol edin.
  • [ ] Üst seviye zincirinde DS kaydı var mı doğrulayın.
  • [ ] DNSKEY/DS TTL değerleri mantıklı mı (çok düşük TTL, yönetim yükünü artırır; aşırı yüksek TTL teşhis süresini uzatır).
  • [ ] İmzalama algoritması ve anahtar boyutları güncel mi (ör. RSA/SHA256 veya ECDSA/algoritma uyumları).
  • [ ] Zone yeniden imzalama (key rollover) planı var mı (manuel yönetiyorsanız periyodik kontrol edin).

İpucu: Operasyonel riskleri azaltın

DNSSEC etkinleştirmeden önce yaşayan servislerinizin DNS kayıtlarını “bilinen iyi” durum olarak saklayın: - MX kayıtları - SPF/DKIM/DMARC TXT kayıtları - RBL/blacklist ile ilgili TXT varsa (genelde daha nadir)

Böylece, DNSSEC aktivasyonu sonrası beklenmedik bir doğrulama hatasında geri dönüş yapmanız kolaylaşır.

3) E-posta kimlik doğrulamasını DNSSEC ile uyumlu hale getirin (SPF/DKIM/DMARC)

DNSSEC yalnızca “oradaki kayıtların doğrulanmasını” güçlendirir. E-posta tarafında kayıtlarınız doğru değilse sonuç değişmez. Bu adımda SPF, DKIM, DMARC kayıtlarını DNSSEC ile aynı anda ele alacağınız bir kontrol listesi veriyorum.

SPF kontrol listesi (TXT)

  • [ ] SPF kayıt adı doğru: @ (veya alt domain)
  • [ ] SPF’de yalnızca yetkili göndericilerin yer aldığından emin olun (mail sunucusu IP blokları / include mekanizmaları).
  • [ ] -all, ~all veya benzeri bitiş politikası var mı.
  • [ ] Toplam SPF uzama/limit aşımı yok mu (DNS TXT uzunluğu ve mekanizma sayısı limitleri).
  • [ ] Alternatif gönderim yolları için (ör. geçici SMTP relay) ayrı include veya yeni policy mekanizması doğru mu?

DKIM kontrol listesi (TXT)

  • [ ] DKIM selector’ınız tutarlı (ör. default, selector1 vb.)
  • [ ] DKIM public key TXT kaydı doğru ve güncel
  • [ ] DKIM imzası gerçekten gönderilen mesajlara ekleniyor mu (sadece DNS kaydı yetmez)
  • [ ] “From” alanı ile imza alanı (d=) arasında uyum (alignment) DMARC açısından önemli

DMARC kontrol listesi (TXT)

  • [ ] DMARC kaydı mevcut: _dmarc alt domaininde
  • [ ] v=DMARC1 doğru
  • [ ] p= politikası (none/quarantine/reject) gerçek hedefe uygun
  • [ ] rua/ruf (rapor hedefleri) çalışıyor ve doğru email adreslerine geliyor
  • [ ] sp= alt domain politikası tanımlıysa tutarlı
  • [ ] pct= ile kademeli geçiş yapıyorsanız yüzdeler yönetiliyor

DNSSEC ile birlikte değerlendirme

Şu yaklaşımı izleyin: - DNSSEC etkin olduğunda SPF/DKIM/DMARC TXT kayıtlarının doğrulanabilirliği artar. - Ama alıcılar yine SPF/DKIM/DMARC sonuçlarını hesaplar. Yanlış kayıtlar “başarısız doğrulama” üretmeye devam eder.

4) Dağıtım (deliverability) odaklı test: doğrulamalarınız gerçekten geçiyor mu?

Kontrol listesi kadar önemli olan şey, her değişiklikten sonra doğrulamayı ölçmektir. Aşağıdaki adımlar “kanıt” toplamanıza yardım eder.

Doğrulama testleri (her kayıt değişiminden sonra)

  • [ ] SPF sonucu: Gönderdiğiniz test postasında alıcı tarafında veya test aracı çıktısında pass görülüyor mu.
  • [ ] DKIM sonucu: Mesajın DKIM imzası doğrulanıyor mu ve “aligned” durumu sağlanıyor mu.
  • [ ] DMARC sonucu: Politika uygulaması ve alignment doğru mu.
  • [ ] Raporlar (DMARC aggregate) gelmeye başladı mı?
  • [ ] SPAM klasörü/kuarantina sinyali azaldı mı?

Teslim edilebilirlikte kritik not: “pass” tek başına yeterli değildir

Bazı alıcılar içerik/itibar sinyallerini de kullanır. Yine de SPF/DKIM/DMARC “fail” iken içerik iyi olsa bile spam riski artar. Bu yüzden önce doğrulamaları “pass” seviyesine getirin.

DNSSEC testleri

DNSSEC doğrulamasını ölçmek için domaininizin DNSSEC durumunu kontrol edin: - [ ] DNSSEC zinciri doğrulanıyor mu - [ ] İmzalanmış zone için geçerli imzalar var mı - [ ] Resolver (alıcı tarafı) DNSSEC doğrulaması yapabiliyor mu

5) Değişiklik yönetimi: TTL, key rollover ve e-posta kesintisi olmadan geçiş

DNSSEC ve e-posta doğrulaması kayıtlarında yapılan değişiklikler bazen gecikmeli görünür. Bu nedenle TTL yönetimi kritik olur.

TTL kontrol listesi

  • [ ] DNSSEC aktivasyonundan önce MX/SPF/DKIM/DMARC TXT kayıtlarının TTL değerlerini kısa bir aralığa almak için plan yapın.
  • [ ] TTL düşürdükten sonra yeni değerlerin yayılmasını bekleyin.
  • [ ] E-posta doğrulaması “beklemede/kararsız” görünüyorsa önce TTL’in yayılımını tamamlayın.

Anahtar döndürme (key rollover) planı

DNSSEC için “otomatik imzalama” varsa sağlayıcı yönetir. Yine de şu kontrolleri yapın: - [ ] Roll dönemlerinde e-posta doğrulama kayıtlarını etkileyebilecek manuel müdahale var mı - [ ] DKIM key rollover ile DNSSEC key rollover aynı takvime denk geliyor mu (operasyonel karmaşıklığı azaltın)

Sürekli izleme

  • [ ] DMARC raporlarında anomali artıyor mu (ör. ani alignment düşüşleri)
  • [ ] SPF/DKIM fail oranlarında artış var mı
  • [ ] Yeni gönderim IP/relay eklendiğinde SPF/DKIM güncellendi mi

6) Sorun giderme matrisi: Hangi arızada hangi adımı uygulayın?

Aşağıdaki tablo, en sık karşılaşılan durumlarda hızlı hareket etmeniz için hazırlanmıştır.

Belirti Olası neden Öncelikli kontrol Hızlı düzeltme
DKIM pass görünüyor ama DMARC fail alignment problemi (From/D d= uyuşmuyor) DMARC “alignment” sonuçları DKIM d= alanını/From alanını uyumlu hale getirin
SPF fail SPF kayıt hatası veya yanlış IP SPF TXT ve gönderim IP’si SPF’de yetkili kaynakları doğru güncelleyin
DMARC quaratine/reject artıyor politika agresif ve pct yüksek DMARC p= ve pct= Kademeli geçişe alın (pct düşürün), önce pass doğrulayın
DNSSEC sonrası doğrulama düşüşü DS kaydı/zone imzası zinciri hatası DNSSEC doğrulama testi DS/anahtar uyumunu sağlayın, imzalama tutarlılığını kontrol edin
Raporlar gelmiyor rua adresi veya DMARC ayarı yanlış _dmarc TXT içeriği rua/ruf ve gönderim izinlerini düzeltin

Mini teşhis prosedürü (değişiklik sonrası)

  1. SPF/DKIM/DMARC sonucunu ilk testte okuyun.
  2. SPF/DKIM fail varsa önce bu kayıtları düzeltin; DNSSEC’i sonradan “tek başına sebep” varsaymayın.
  3. SPF/DKIM/DMARC pass ama DMARC raporları yoksa DMARC ayarlarını ve rapor adreslerini kontrol edin.
  4. DNSSEC sonrası “zincir doğrulama” hataları görüyorsanız DS/anahtar yönetimini ele alın.

DNSSEC ve e-posta deliverability için nihai kontrol listesi (kopyala-uygula)

  • [ ] DNSSEC etkin ve zincir doğrulanıyor (parent/child DS uyumu)
  • [ ] MX kayıtları doğru
  • [ ] SPF kaydı: doğru alan, doğru yetkiler, geçerli politika
  • [ ] DKIM: doğru selector, doğru public key ve imzanın gerçekten eklendiği doğrulandı
  • [ ] DMARC: _dmarc kaydı mevcut, alignment hedeflendi, raporlar doğru adrese gidiyor
  • [ ] TTL planı yapıldı (değişiklikten sonra yayılım bekleniyor)
  • [ ] Test postaları ile SPF/DKIM/DMARC sonuçları “pass” doğrulandı
  • [ ] DMARC raporlarında beklenen trendler görülüyor (fail ve alignment düşüşleri izleniyor)
  • [ ] Key rollover dönemlerinde operasyonel müdahale çakışması azaltıldı

Sonuç: En hızlı kazanım için sırayı koruyun

DNSSEC’i “e-posta spamını tek hamlede bitiren” bir özellik gibi değil, doğrulama kayıtlarınızın bütünlüğünü güçlendiren bir katman olarak ele alın. Uygulanacak en verimli sıra: (1) DNSSEC zincirini doğru kurun, (2) SPF/DKIM/DMARC kayıtlarını teslim edilebilirlik hedefleriyle uyumlu hale getirin, (3) değişiklikten sonra test ederek sonuçları ölçün ve (4) DMARC raporlarını takip edin. Bu kontrol listesini domain ve posta altyapınızda tek tek uygulayın; sorun yaşadığınızda tablo üzerinden kök nedeni hızlıca daraltın.

Etiketler: #dnssec #eposta #deliverability #spf #dkim #dmarc #hosting

Hosting karşılaştırması yapmaya hazır mısın?

100+ firmanın fiyatlarını tek tıkla karşılaştır, en uygun paketi bul.

Hosting Karşılaştır →

İlgili Yazılar

0 ürün seçildi
NetKıyas AI
Hosting danışmanınız
Merhaba! Ben NetKıyas yapay zekâ asistanı. Hosting, VDS, VPS veya sunucu seçiminde size yardımcı olabilirim. Ne arıyorsunuz?