SPF, DKIM ve DMARC nedir? DNS kayıtları için pratik rehber
Üç kayıt aynı işi yapmadığı için yalnızca birinin yeşil görünmesi bütün sistemi doğrulamaz. En yararlı başlangıç, şirketiniz adına hangi sistemlerin e-posta gönderdiğini listelemek ve her birini test mesajının başlıklarıyla kontrol etmektir. Özellikle web sitesi, CRM ve e-fatura hizmeti bu listede unutulmamalıdır.
SPF gönderim sunucusunun yetkisini, DKIM mesajın alan adına bağlı imzasını kontrol eder. DMARC, görünen gönderen alan adının başarılı SPF veya DKIM kimliğiyle uyumunu değerlendirir ve başarısız mesajlar için alan adı sahibinin politikasını bildirir. Bu kontroller teslimat kararının parçalarıdır; gelen kutusu garantisi vermez.
Bu rehber kimler için? DNS yöneten ajanslar, IT ekipleri ve e-posta teslimatını inceleyen şirketler
Üç yöntemin görevi ve sınırı
SPF, mesajı taşıyan sunucuyla gönderim sırasında kullanılan zarf alan adı arasındaki yetkiyi sınar. Bu alan adı, kullanıcının ekranda gördüğü Kimden adresiyle her zaman aynı değildir. DKIM, seçilmiş başlıklar ve mesaj gövdesi üzerine alan adına bağlı bir imza ekler; alıcı bunun açık anahtarını DNS üzerinden bulur. DMARC bu kimlikleri görünen gönderenle ilişkilendirir.
Bu teknikler bir mesajın ticari doğruluğunu veya içindeki bağlantının güvenliğini onaylamaz. Alan adı hesabı ele geçirilmiş bir gönderici de doğrulamadan geçebilir. Bu nedenle teslimat sorununu incelerken kimlik doğrulama, gönderen itibarı ve insan değerlendirmesi birlikte düşünülmelidir. Alıcı hizmetler kendi politikalarını da uygulayabilir.
| Yöntem | Kontrol ettiği konu | Yönetimde kritik nokta |
|---|---|---|
| SPF | Yetkili gönderim kaynakları | Bir alan adı için tek SPF politikası |
| DKIM | Alan adına bağlı mesaj imzası | Doğru selector ve açık anahtar |
| DMARC | Görünen gönderen ile doğrulama uyumu | Gerçek göndericileri inceleyerek politika seçimi |
Önce tüm göndericileri listeleyin
Şirket çalışanlarının kullandığı e-posta hizmeti çoğu zaman tek gönderici değildir. Teklif yazılımı, web formu, müşteri destek sistemi ve fatura uygulaması da şirket alan adıyla mesaj gönderebilir. Hangi sistemin hangi adresi kullandığını, DNS için ne önerdiğini ve değişikliği kimin yönettiğini bir tabloda toplayın.
Her hizmet için kısa bir test gönderin ve son alıcıdaki başlıkları inceleyin. Bir hizmetin kendi alan adıyla imzalama yapması ile şirketinizin alan adıyla imzalama yapması farklı sonuçlar doğurabilir. Teknik sorumlunun kontrol edeceği bilgi, yalnızca hizmet ekranında görünen başarı işareti değildir; test mesajının son alıcıda aldığı doğrulama sonucudur. Kullanılmayan eski hizmetleri de kayıt envanterinde belirtin.
İş yazışmaları → TekPosta → kişi adresleri Web formu → site uygulaması → form bildirim adresi Fatura yazılımı → ilgili sağlayıcı → muhasebe adresi Her satır için DNS sorumlusu ve test tarihi ekleyin. Bu liste örnektir; yalnızca gerçekten kullandığınız hizmetleri yetkilendirin.
SPF: yeni kayıt eklemek yerine mevcut politikayı inceleyin
DNS bölgesinde v=spf1 ile başlayan mevcut TXT kaydını bulun. TekPosta bilgilerini eklerken ikinci bir SPF kaydı oluşturmayın; gereken kaynaklar tek politikada değerlendirilmelidir. Birden fazla SPF kaydı veya aşırı DNS sorgusu doğrulama hatasına yol açabilir. Yeni sağlayıcının önerisini, mevcut gönderici envanteriyle birlikte ele alın.
TekPosta panelindeki SPF önerisi, platform üzerinden yapılan gönderimleri tarif eder. Başka bir gönderici kullanan şirketin politikası ayrıca düzenlenebilir. Karmaşık include zincirleri, redirect ve önceki sağlayıcının kaynakları varsa kaydı teknik sorumluya kontrol ettirin. Gereksiz yetkilendirmeleri bırakmak yönetimi zorlaştırır; çalışan bir kaynağı silmek de gerçek iş mesajlarını etkileyebilir. İki durum için de test gerekir.
DKIM: selector adı ve açık anahtar eşleşmeli
DKIM kaydının adı genellikle bir selector ile _domainkey alanının birleşimidir. TekPosta alan adı detayındaki tam adı ve açık anahtarı kullanın. Bir alan adı için farklı selector adları bulunabilir; eski bir anahtarın varlığı yeni imzanın doğrulandığını göstermeyebilir. Hangi selector ile imza atıldığı test mesajının başlığından anlaşılır.
DNS arayüzü uzun TXT değerini parçalara bölüyorsa bunların aynı kayıt içinde doğru birleştiğini denetleyin. Kopyalama sırasında eklenen satır sonu, eksik karakter veya kayıt adına iki kez eklenen alan adı hata üretebilir. Anahtarın yalnızca kamuya açık bölümünü DNS üzerinde yayımlayın. Paneldeki değeri elle kısaltmayın veya başka alan adının kaydıyla değiştirmeyin.
DMARC: gözlemden yaptırıma kontrollü geçin
Yeni bir kurulumda p=none ile gözlem yapmak, mevcut göndericileri ve uyumsuz mesajları incelemek için kullanılabilir. Bu politika başarısız mesajların reddini talep etmez. Rapor adresinin gerçekten çalıştığını ve gelen raporların değerlendirildiğini kontrol edin. Sadece kayıt oluşturmak, şirketin bütün göndericilerinin hazır olduğunu göstermez.
İş akışları doğrulanınca quarantine veya reject politikasına geçiş planlanabilir. Güncel DMARC standardı Mayıs 2026 tarihli RFC 9989 ile tanımlanır; eski pct etiketi bu standardın dışında kalmıştır. İnternetten bulunan bir yüzde ayarını koruma garantisi olarak kullanmayın. İleri yönlendirmeler, liste yazılımları ve farklı sağlayıcılar nedeniyle gerçek mesajları incelemek, sert politikayı rastgele açmaktan daha güvenilir bir işletme yaklaşımıdır.
Ad: _dmarc.ornek.com Tür: TXT Değer: v=DMARC1; p=none; rua=mailto:dmarc@ornek.com Bu örnek yalnızca yapıyı açıklar. Rapor adresinizi hazırlayın, kendi alan adınıza uyarlayın ve panel önerisini teknik sorumlunuzla değerlendirin.
DNS kontrolünün ardından gerçek mesajı doğrulayın
DNS kaydı görünür olsa bile gönderici yazılım doğru kimliği kullanmıyor olabilir. Bu nedenle çalışan kutusu, web formu ve diğer yetkili uygulamalar için ayrı test mesajları gönderin. Son alıcıdaki Authentication-Results alanını, güvenilir alıcı sunucunun eklediği başlık içinde inceleyin. Mesaj içindeki rastgele bir metin veya gönderenin eklediği başlık başarı kanıtı değildir.
Sonucu bir değişiklik kaydına yazın: hangi kaynak, hangi adres, hangi tarih ve hangi doğrulama sonucu. Bir hata bulunduğunda bütün DNS bölgesini sıfırlamak yerine ilgili katmanı düzeltin. DNS yayımlanmadı mı, selector yanlış mı, gönderici başka alan adı mı kullanıyor? Bu ayrım destek ekibinin çalışmasını hızlandırır ve düzgün çalışan diğer iş akışlarının bozulmasını önler.
Sık sorulan sorular
SPF başarılıysa DMARC da başarılı olur mu?
Her zaman değil. Başarılı SPF kimliğiyle görünen gönderen alan adının uyumu da gerekir. Uyumlu ve başarılı DKIM, DMARC değerlendirmesinde diğer başarı yolu olabilir.
p=none alan adımı taklit eden tüm mesajları engeller mi?
Hayır. Gözlem politikasında başarısız mesajların reddi talep edilmez. Raporların incelenmesi ve meşru göndericilerin hazırlanması gerekir.
SPF ve DKIM bütün mesajları gelen kutusuna taşır mı?
Hayır. Kimlik doğrulama önemli bir kontroldür, ancak alıcı hizmetin itibara, içeriğe ve kullanıcı geri bildirimlerine ilişkin değerlendirmeleri de vardır.
Kaynaklar ve doğrulama
Teknik adımları uygularken aşağıdaki kaynakları ve kullandığınız sağlayıcının güncel ayarlarını birlikte kontrol edin. Örnek kayıtlar kendi domaininiz için panelde üretilen değerlerin yerine geçmez.
Şirketinizin e-postasını kendi domaininizde yönetin
TekPosta'da domain, DNS doğrulama, mail adresleri, uygulama şifreleri ve taşıma adımlarını aynı panelden takip edebilirsiniz. Ekibinizin ihtiyacına uygun planı inceleyin veya geçiş planınızı bizimle paylaşın.