DNS’inizi tahmin etmeyi bırakın: geliştirici dostu bir MX, SPF, DKIM ve DMARC turu

E-posta DNS kayıtları bugün neden önemli

E-posta kimlik doğrulaması eskiden isteğe bağlıydı. 2026’da artık temel gereklilik. Gmail ve Outlook, toplu göndericiler için SPF ve DKIM’i zorunlu tutuyor; DMARC ise işlem e-postası gönderen her alan adı için hızla zorunlu hale geliyor. DNS kayıtlarınız yanlışsa e-postalarınız ulaşmaz—geri dönüş yok, uyarı yok, yalnızca sessizlik.

Sorun şu ki bu kayıtlar araçlar gibi değil, RFC’ler gibi belgeleniyor. Çoğu geliştirici, e-posta sağlayıcısının kurulum rehberinden örnekleri kopyalayıp yapıştırır ve en iyisini umar. Bu, sorun gidermeniz, ikinci bir gönderim hizmeti eklemeniz veya bir müşteriye iletişim formu e-postalarının neden spam’e düştüğünü açıklamanız gerekene kadar işe yarar.

Bu rehber, MX, SPF, DKIM ve DMARC’ı gerçek hayatta karşılaşacağınız sırayla ele alır; doğru yapılandırmak için yeterli ayrıntıyı ve bozulduklarında hata ayıklamak için yeterli bağlamı sağlar.

MX kayıtları: gelen e-postanın gittiği yer

MX kayıtları, internet’e alan adınız için hangi posta sunucularının e-posta kabul ettiğini söyler. Bu dört kaydın en basitidir, ama yanlış yapılandırılması da en kolay olanlardan biridir.

Bir MX kaydının iki parçası vardır: bir öncelik numarası ve bir ana makine adı. Daha düşük öncelik numaraları önce denenir. Google Workspace kullanıyorsanız MX kayıtlarınız şöyle görünebilir:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Sondaki noktalar önemlidir—ana makine adının tam nitelikli olduğunu belirtirler. Çoğu DNS sağlayıcısı bunları otomatik ekler, ancak hepsi değil.

Yaygın hatalar: MX kayıtlarını bir ana makine adı yerine A kaydına yönlendirmek, tüm öncelikleri aynı sayıya ayarlamak (bu, yedeklere sahip olmanın amacını boşa çıkarır) veya sağlayıcı değiştirirken eski MX kayıtlarını kaldırmayı unutmak. Eski MX kayıtları orada zararsızca durmaz—posta döngülerine veya teslimatın iki gelen kutusu arasında bölünmesine neden olabilir.

Kendi iletişim formunuzu çalıştırıyorsanız ve üçüncü taraf hizmetlere güvenmeden spam’den kaçınmak istiyorsanız, formların nasıl spam vektörlerine dönüştüğünü anlamak yararlı bir başlangıç noktasıdır.

SPF: sizin adınıza hangi sunucuların göndermesine izin var

SPF (Sender Policy Framework), alan adınız adına e-posta göndermeye yetkili IP adreslerini ve alan adlarını listeleyen bir TXT kaydıdır. Çoğu posta sunucusunun sizden geldiğini iddia eden bir ileti aldığında yaptığı ilk kontroldür.

Temel bir SPF kaydı şöyle görünür:

v=spf1 include:_spf.google.com ~all

Parçalara ayırırsak:

• v=spf1 SPF sürümünü bildirir
• include:_spf.google.com Google’ın SPF kaydına yetki devreder
• ~all yumuşak başarısızlıktır—listelenmemiş kaynaklardan gelen postayı reddedin, ama çok katı olmayın

Belirli adresleri izin listesine almak için ip4: veya ip6: kullanabilir ya da alan adınızın A ve MX kayıtlarına başvurmak için a ve mx kullanabilirsiniz. Sondaki all mekanizması, listelemediğiniz kaynaklardan gelen postaya ne olacağını kontrol eder: -all sert başarısızlıktır (reddet), ~all yumuşak başarısızlıktır (şüpheli olarak işaretle), ?all nötrdür (görüş yok) ve +all herkese açıktır (bunu kullanmayın).

SPF’in iki keskin kenarı vardır. Birincisi, e-posta yönlendirildiğinde bozulur; çünkü yönlendiren sunucu SPF kaydınızda değildir. İkincisi, SPF kayıtlarında on DNS sorguluk bir arama sınırı vardır. Çok fazla üçüncü taraf hizmeti dahil ederseniz sınırı aşarsınız ve SPF çalışmayı durdurur. Çözüm, SPF kaydınızı düzleştirmektir—include: yönergelerini gerçek IP aralıklarıyla değiştirin—ancak sağlayıcılar IP’lerini değiştirdiğinde bu bakım gerektirir.

DKIM: gönderen kimliğinin kriptografik kanıtı

DKIM (DomainKeys Identified Mail), giden e-postanıza dijital imza ekler. Alıcı sunucu, imzayı DNS’inizde yayımlanan bir açık anahtara karşı kontrol eder. İmza geçerliyse ve iletiyle oynanmamışsa DKIM başarılı olur.

SPF’in aksine DKIM yönlendirmeden sağ çıkar, çünkü imza iletiyle birlikte taşınır. Ayrıca daha esnektir—farklı gönderim hizmetleri için, her biri kendi seçicisine sahip birden fazla DKIM anahtarınız olabilir.

Bir DKIM DNS kaydı şöyle görünür:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Seçici (bu örnekte default) keyfidir—e-posta sağlayıcınız onu seçer. p= değeri, genellikle uzun bir base64 kodlu dize olan açık anahtardır. E-posta sağlayıcınız özel anahtarı oluşturur ve giden iletileri imzalamak için kullanır.

DKIM kurulumu neredeyse her zaman e-posta sağlayıcınız tarafından yönetilir. Sizin işiniz, size verdikleri TXT kaydını kopyalayıp DNS’inize yapıştırmaktır. Zor kısım, bazı DNS sağlayıcılarının uzun TXT kayıtlarını iyi işlememesidir—ya kısaltırlar ya da değeri birden fazla tırnaklı dizeye bölmenizi isterler.

DKIM’in çalıştığını doğrulamak için bir Gmail adresine test e-postası gönderin ve başlıkları kontrol edin. Authentication-Results başlığında dkim=pass ifadesini arayın.

DMARC: politika uygulama ve raporlama

DMARC (Domain-based Message Authentication, Reporting and Conformance), SPF ve DKIM’i birbirine bağlar ve kimlik doğrulama başarısız olduğunda alıcı sunuculara ne yapacaklarını söyler. Ayrıca raporlamayı etkinleştirir; böylece alan adınızla kimlerin e-posta gönderdiğini—hem meşru hem de sahte—görebilirsiniz.

Minimal bir DMARC kaydı şöyle görünür:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none yalnızca izle anlamına gelir—başarısız iletileri reddetmeyin veya karantinaya almayın
• rua=mailto:[email protected] toplu raporların nereye gönderileceğini belirtir

SPF ve DKIM’in çalıştığından emin olduğunuzda politikayı p=quarantine (başarısızları spam’e gönder) veya p=reject (doğrudan geri çevir) olarak sıkılaştırabilirsiniz. Ayrıca sp= ile alt alan adı politikası belirleyebilir ve pct= ile politikanın uygulanacağı ileti yüzdesini tanımlayabilirsiniz.

DMARC raporları, büyük alıcılar tarafından günlük gönderilen XML dosyalarıdır. Ayrıntılıdırlar ve ham halleriyle okumaları zordur, ancak hangi iletilerin kimlik doğrulamadan geçtiğini veya kaldığını ve nedenini tam olarak söylerler. Meşru postanın reddedildiğini görüyorsanız raporlar hangi SPF veya DKIM kontrolünün başarısız olduğunu gösterir.

Bir püf noktası: DMARC hizalama gerektirir. SPF için Return-Path başlığındaki alan adının From başlığındaki alan adıyla eşleşmesi (veya onun bir alt alan adı olması) gerekir. DKIM için DKIM imzasındaki d= alan adının From alan adıyla eşleşmesi gerekir. Üçüncü taraf bir gönderim hizmeti kullanıyorsanız, onların kendi alan adlarıyla değil sizin alan adınızla özel dönüş yollarını veya DKIM imzalamayı desteklemesi gerekir.

Mevcut kurulumunuzu nasıl denetlersiniz

Çoğu DNS sorunu, bir probleme yol açana kadar görünmezdir. Bir şey bozulmadan önce kayıtlarınızı kontrol etmenin yolu şöyle:

1. MX kayıtlarınızı sorgulayın: dig MX example.com posta sunucusu ana makine adlarınızı ve önceliklerinizi döndürmelidir. Bunların e-posta sağlayıcınızın belgeleriyle eşleştiğini doğrulayın.

1. SPF söz dizimini kontrol edin: dig TXT example.com çalıştırın ve v=spf1 kaydını arayın. Söz dizimi hatalarını ve arama sınırı ihlallerini yakalamak için bir SPF doğrulayıcıdan geçirin.

1. DKIM anahtarlarını doğrulayın: Bir test e-postası gönderin ve DKIM-Signature başlığını inceleyin. Seçiciyi ve alan adını çıkarın, ardından açık anahtarın var olduğunu doğrulamak için dig TXT selector._domainkey.example.com sorgusunu çalıştırın.

1. DMARC politikasını doğrulayın: dig TXT _dmarc.example.com DMARC kaydınızı döndürmelidir. rua= değerinin gerçekten izlediğiniz bir adrese işaret ettiğinden emin olun.

1. Uçtan uca test edin: mail-tester.com gibi bir hizmet kullanın veya bir Gmail adresine gönderip tam başlıkları kontrol edin. Authentication-Results başlığında spf=pass, dkim=pass ve dmarc=pass ifadelerini arayın.

E-postaların neden ulaşmadığını ayıklıyorsanız, başlıklar en iyi aracınızdır. Çoğu posta istemcisi ham başlıkları görüntülemenize izin verir—Gmail’de iletiyi açın, üç noktaya tıklayın ve 'Show original' seçeneğini seçin. Authentication-Results başlığı size tam olarak hangi kontrolün neden başarısız olduğunu söyleyecektir.

Alt alan adı politikaları ne zaman kullanılmalı

Birden fazla alt alan adından e-posta gönderiyorsanız—örneğin pazarlama için newsletter.example.com, işlem postaları için app.example.com—alt alan adı bazında DMARC politikaları belirleyebilirsiniz. Bu, ana alan adınızda daha gevşek bir politika tutarken kontrol ettiğiniz alt alan adlarında katı politikalar uygulamanıza olanak tanır.

Bunun karşılığı karmaşıklıktır. Her alt alan adının kendi SPF, DKIM ve DMARC kayıtlarına ihtiyacı vardır; ayrıca hangi gönderim hizmetlerinin hangi alt alan adları için yetkilendirildiğini takip etmeniz gerekir. Çoğu küçük ekip için tek, iyi yapılandırılmış bir alan adı daha basittir ve aynı derecede güvenlidir.

Kimlik doğrulama bozulduğunda ne yapılmalı

En yaygın hata biçimi, DNS’i güncellemeden yeni bir gönderim hizmeti eklemektir. Yeni bir işlem e-postası sağlayıcısı kullanmaya başlarsanız, onların SPF include değerini veya IP aralığını eklemeniz, alan adınızla DKIM imzalamayı yapılandırmanız ve DMARC hizalamasını doğrulamanız gerekir.

İkinci en yaygın sorun yönlendirmedir. Kullanıcılar e-postanızı başka bir adrese yönlendirirse SPF başarısız olur; çünkü yönlendiren sunucu SPF kaydınızda değildir. DKIM genellikle yönlendirmeden sağ çıkar; bu nedenle DKIM başarılı olduğu ve DMARC politikanız kısmi hizalamaya izin verdiği sürece ileti yine teslim edilmelidir. Yönlendirilen postanın reddedildiğini görüyorsanız DMARC politikanızı kontrol edin—katı hizalama ile p=reject yönlendirmeyi bozacaktır.

Üçüncü sorun DNS yayılımıdır. DNS kayıtlarındaki değişikliklerin yayılması saatler sürebilir ve farklı posta sunucuları kayıtları farklı sürelerde önbelleğe alır. Bir kaydı yeni güncellediyseniz ve çalışmıyorsa birkaç saat bekleyip yeniden test edin. Yayılımı whatsmydns.net gibi bir araçla kontrol edebilirsiniz.

Temel çıkarımlar

• MX kayıtları gelen postayı yönlendirir; SPF, DKIM ve DMARC giden postanın kimliğini doğrular. Farklı sorunları çözerler ve dördüne de ihtiyacınız vardır.
• SPF yönlendirmede bozulur ve on aramalık bir sınırı vardır. DKIM yönlendirmeden sağ çıkar ancak hizmet başına yapılandırma gerektirir. DMARC bunları birbirine bağlar ve raporlamayı etkinleştirir.
• DMARC’ta p=none ile başlayın, raporları birkaç hafta izleyin, ardından meşru postanın geçtiğinden emin olduğunuzda p=quarantine veya p=reject değerine sıkılaştırın.
• DNS hataları sessizdir. Yapılandırmanızı gerçek e-postayla test edin ve SPF, DKIM ve DMARC’ın geçtiğini doğrulamak için başlıkları inceleyin.
• Yeni bir gönderim hizmeti ekledikten sonra kimlik doğrulama bozulursa SPF include değerlerini, DKIM seçicilerini ve DMARC hizalamasını kontrol edin. Başlıklar hangi kontrolün başarısız olduğunu söyleyecektir.

FAQ

Q: Birden fazla SPF kaydım olabilir mi?

A: Hayır. Birden fazla SPF kaydı, hepsinin yok sayılmasına neden olur. Birden fazla hizmeti yetkilendirmeniz gerekiyorsa tek bir SPF kaydı içinde include: yönergeleri kullanın veya IP aralıklarını doğrudan listeleyin. On arama sınırına dikkat edin.

Q: Günde yalnızca birkaç e-posta gönderiyorsam DMARC’a ihtiyacım var mı?

A: Evet. DMARC hacimle ilgili değildir—kim olduğunuzu söylediğiniz kişi olduğunuzu kanıtlamakla ilgilidir. Küçük alan adları bile DMARC’tan fayda görür; çünkü sahteciliği önler ve teslimat sorunlarına görünürlük sağlar. p=none ve bir raporlama adresiyle başlayın.

Q: DKIM ve SPF ikisi de başarısız olursa ama e-posta meşru görünüyorsa ne olur?

A: DMARC politikanıza bağlıdır. p=none ise posta bir uyarıyla teslim edilir. p=quarantine ise spam’e gider. p=reject ise geri çevrilir. Bu yüzden katı bir politika uygulamadan önce DMARC raporlarını izlemeniz gerekir—hakkında bilginiz olmayan meşru göndericileriniz olabilir.

Q: Aynı DKIM anahtarını birden fazla alan adı için kullanabilir miyim?

A: Teknik olarak evet, ama yapmayın. Her alan adının kendi DKIM anahtar çifti olmalıdır. Anahtarları paylaşmak rotasyonu zorlaştırır ve bir özel anahtar ele geçirilirse etki alanını genişletir.

Q: DKIM anahtarlarını ne sıklıkla döndürmeliyim?

A: Evrensel bir kural yoktur, ancak çoğu alan adı için yılda bir kez makuldür. Bir anahtarın ele geçirilmiş olabileceğinden şüpheleniyorsanız hemen döndürün. Yeni özel anahtarla imzalamaya başlamadan önce yeni açık anahtarı DNS’te yayımladığınızdan emin olun ve gecikmiş postaları karşılamak için rotasyondan sonra eski anahtarı birkaç gün daha DNS’te bırakın.

<!-- tool-cta:start -->

💡 Bunu deneyin: MX, SPF ve DMARC kayıtlarının pratikte nasıl bir araya geldiğini görmek için herhangi bir alan adının yayımlanmış politikasını DMARC Lookup ile inceleyin.

<!-- tool-cta:end -->

Kaynaklar

• RFC 7208: Sender Policy Framework (SPF) — Söz dizimi kuralları ve on arama sınırı dahil SPF belirtimi.
• RFC 6376: DomainKeys Identified Mail (DKIM) — İmza üretimi ve doğrulamayı kapsayan DKIM belirtimi.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Politika söz dizimi ve toplu raporlama biçimi dahil DMARC belirtimi.
• Google Workspace: Prevent spoofing and spam — Google Workspace alan adları için SPF, DKIM ve DMARC yapılandırmasına dair pratik rehberlik.