Üç kaydın görevi: kısaca
E-posta protokolü ilk tasarlandığında gönderenin kimliğini doğrulayan bir mekanizma içermiyordu; herkes herhangi bir adres adına e-posta gönderebiliyordu. SPF, DKIM ve DMARC bu açığı DNS üzerinden kapatmak için geliştirildi ve birbirini tamamlar:
| Kayıt | Sorduğu soru | Nerede durur? |
|---|---|---|
| SPF | Bu sunucu, bu alan adı adına e-posta göndermeye yetkili mi? | Alan adında TXT kaydı |
| DKIM | Bu ileti yolda değiştirilmeden, alan adının anahtarıyla mı imzalandı? | seçici._domainkey altında TXT kaydı |
| DMARC | SPF veya DKIM, görünen gönderen adresiyle uyumlu mu ve değilse ne yapılmalı? | _dmarc altında TXT kaydı |
Büyük e-posta sağlayıcıları son yıllarda, özellikle yüksek hacimli gönderenler için bu kayıtları fiilen zorunlu hale getirdi. Şartların ayrıntısı ve eşikleri değişebildiği için Gmail ve Yahoo gibi sağlayıcıların gönderen yönergelerini güncel haliyle kontrol edin. Ama hacminiz düşük olsa bile üç kaydı da kurmak, iletilerinizin güvenilir görünmesinin temel koşuludur.
Başlamadan önce: alan adınız adına kim e-posta gönderiyor?
En sık yapılan hata, yalnızca ana e-posta hizmetini düşünüp diğer gönderenleri unutmaktır. Kayıtları yazmadan önce bir liste çıkarın:
- Kurumsal e-posta hizmetiniz veya kendi posta sunucunuz.
- Web sunucunuz: iletişim formu, şifre sıfırlama, sipariş bildirimleri.
- Bülten ve pazarlama e-postası hizmetleri.
- Destek, faturalama veya CRM yazılımları.
Web sitesinin e-postalarını doğrudan sunucudan göndermek yerine kimlik doğrulamalı bir SMTP hizmeti üzerinden göndermek, teslim edilebilirliği genellikle belirgin şekilde iyileştirir. Sunucunuzdan doğrudan gönderecekseniz PTR kaydı ve IP itibarı gibi ek konular devreye girer; bunlara aşağıda değiniyoruz.
SPF kaydı nasıl yazılır?
SPF, alan adının kökünde (ya da gönderimde kullanılan alt alan adında) v=spf1 ile başlayan tek bir TXT kaydıdır. Örnek bir kayıt şöyle görünebilir:
v=spf1 ip4:203.0.113.10 include:_spf.eposta-saglayiciniz.example ~all
- ip4 / ip6: doğrudan izin verilen sunucu adresleri. Buradaki 203.0.113.10 yalnızca belgelerde kullanılan örnek bir adrestir.
- include: bir hizmetin kendi SPF listesini dahil eder. Hizmetin hangi değeri istediğini kendi belgelerinden alın.
- ~all / -all: listede olmayan sunucular için sonuç. ~all "yumuşak başarısız", -all "başarısız" anlamına gelir. DMARC kullanıyorsanız asıl kararı DMARC politikası verdiği için pek çok yönetici ~all ile başlar.
Dikkat edilecek iki kural vardır. Birincisi, bir alan adında yalnızca tek bir SPF kaydı olmalıdır; yeni bir hizmet eklerken ikinci bir kayıt açmak yerine mevcut kayda ekleme yapın. İki ayrı SPF kaydı, doğrulamanın hata vermesine yol açar. İkincisi, SPF değerlendirmesi sırasında yapılan DNS sorgusu sayısı 10 ile sınırlıdır; her include, a ve mx ifadesi bu sınırdan yer. Çok sayıda hizmet kullanıyorsanız bu sınırı aşmak kolaydır ve sonuç yine hata olur.
SPF'in görünür "Kimden" adresini değil, iletinin zarf göndericisini (Return-Path) kontrol ettiğini de unutmayın. Bu ayrıntı, DMARC hizalamasında önem kazanır.
DKIM imzasını etkinleştirmek
DKIM'de gönderen sunucu her iletiyi özel bir anahtarla imzalar; alıcı sunucu da imzayı DNS'te yayımlanan açık anahtarla doğrular. Kurulum genellikle şöyle ilerler:
- E-posta hizmetinizin veya panelinizin DKIM bölümünden anahtar oluşturun. Mümkünse 2048 bit anahtar seçin.
- Size verilen seçici (selector) adını ve değeri not edin. Kayıt seçici._domainkey.ornek.com adına TXT olarak eklenir; bazı hizmetler TXT yerine kendi alan adlarına işaret eden CNAME kayıtları ister.
- Kaydı DNS'e ekledikten sonra hizmet panelinden doğrulamayı başlatın ve imzalamayı etkinleştirin.
Her gönderen hizmet kendi seçicisini kullanabilir; bu sayede birden fazla DKIM kaydı birbirine karışmadan aynı alan adında bulunabilir. Uzun anahtar değerleri bazı DNS panellerinde birden fazla parçaya bölünmüş şekilde girilir; değeri kopyalarken boşluk veya tırnak işareti eklenmediğinden emin olun. Panel değiştirdiğinizde ya da e-posta hizmetini taşıdığınızda yeni anahtarı yayımlamadan eskisini silmeyin.
DMARC: politikayı kademeli sıkılaştırmak
DMARC, SPF ve DKIM sonuçlarını görünür gönderen adresiyle ilişkilendirir. Bir iletinin DMARC'tan geçmesi için SPF veya DKIM'den en az birinin hem başarılı olması hem de "Kimden" alanındaki alan adıyla hizalı olması gerekir. Kayıt _dmarc.ornek.com adına TXT olarak eklenir. Başlangıç için örnek:
v=DMARC1; p=none; rua=mailto:dmarc-rapor@ornek.com
Bu kayıt hiçbir iletiyi engellemez, yalnızca alıcı sağlayıcılardan toplu raporlar ister. Raporlar XML formatında gelir ve alan adınız adına hangi sunucuların e-posta gönderdiğini gösterir; okumak için rapor çözümleme araçlarından yararlanabilirsiniz. Önerilen yol şudur:
- p=none ile başlayın ve birkaç hafta raporları izleyin. Listede unuttuğunuz meşru gönderenleri bulup SPF ve DKIM ayarlarını tamamlayın.
- Meşru gönderenlerin tamamı geçtiğinde p=quarantine politikasına geçin. Gerekirse pct etiketiyle önce iletilerin bir kısmına uygulayın.
- Sorun görmezseniz p=reject ile alan adınızı taklit eden iletilerin reddedilmesini sağlayın.
Doğrudan p=reject ile başlamak, unutulmuş bir faturalama sisteminin ya da iletişim formunun e-postalarının sessizce kaybolmasına yol açabilir.
Hizalama ve alt alan adları
Hizalama varsayılan olarak "esnek" (relaxed) moddadır: zarf göndericisi veya DKIM imzasındaki alan adı, görünen adresle aynı ana alan adını paylaşıyorsa yeterlidir. Örneğin bulten.ornek.com adına imzalanan bir ileti, ornek.com görünen adresiyle hizalı sayılır. adkim ve aspf etiketleriyle katı moda geçebilirsiniz, ama çoğu site için esnek mod yeterlidir. Alt alan adlarına farklı bir politika uygulamak istiyorsanız sp etiketini kullanın. Bülten gibi yüksek hacimli gönderimleri ayrı bir alt alan adından yapmak, olası bir itibar sorununun ana alan adınızın işlem e-postalarını etkilemesini de sınırlar.
Kendi sunucunuzdan gönderiyorsanız: PTR ve HELO
E-postayı doğrudan kendi VPS'inizden gönderiyorsanız alıcı sunucular IP adresinizin ters DNS kaydına da bakar. PTR kaydı, sunucunun tam ana makine adını (örneğin mail.ornek.com) göstermeli; bu ad da A kaydıyla aynı IP'ye çözümlenmelidir. Posta sunucusunun kendini tanıttığı HELO/EHLO adı da bununla uyumlu olmalıdır. PTR kaydı sunucu sağlayıcınızın panelinden veya destek talebiyle ayarlanır.
Ayrıca bazı sağlayıcılar yeni sunucularda giden 25 numaralı portu varsayılan olarak kapalı tutar ve IP adresinizin daha önce kötüye kullanılmış olması kara listelerde görünmesine yol açabilir. Gönderime başlamadan önce IP adresini bilinen kara liste sorgulama araçlarında kontrol edin. Sunucu tarafındaki diğer ayarlar için VPS güvenlik ayarları rehberine bakabilirsiniz.
Kontrol ve hata ayıklama
- Kayıtları dig TXT ornek.com +short ve dig TXT _dmarc.ornek.com +short ile kontrol edin.
- Kendinize, örneğin bir Gmail adresine, test iletisi gönderin ve iletinin özgün kaynağını görüntüleyin. SPF, DKIM ve DMARC satırlarının her biri için "PASS" görmelisiniz.
- DKIM "fail" veriyorsa kaydın eksik kopyalanıp kopyalanmadığına, seçici adının doğru olup olmadığına bakın.
- SPF "permerror" veriyorsa iki ayrı SPF kaydı veya 10 sorgu sınırının aşılması en olası sebeptir.
Bir değişiklikten sonra sonucu hemen göremiyorsanız telaşlanmayın: TXT kayıtları da TTL süresi boyunca önbellekte kalır. Değişikliği yetkili nameserver'a doğrudan sorgu atarak doğrulayın, ardından test iletisini birkaç saat sonra tekrarlayın. DMARC raporları da genellikle günlük olarak gönderildiği için ilk raporun gelmesi bir gün kadar sürebilir.
E-posta göndermediğiniz alan adlarını da koruyun: v=spf1 -all SPF kaydı ve p=reject DMARC politikası, bu alan adlarının sahte gönderimlerde kullanılmasını zorlaştırır.
DNS kayıtlarının genel yönetimi için domain ve DNS yönetimi sayfamıza, panel değiştirirken e-posta ayarlarının nasıl etkilendiğini görmek için panel karşılaştırması rehberine göz atın. DNS sağlayıcısını değiştirecekseniz, bu kayıtları yeni bölgeye eksiksiz taşımayı nameserver ve domain transferi rehberinde anlattık. Teslim sorunlarınızı test sonuçlarıyla birlikte Sunucu/Hosting Bilgi Alışverişi bölümünde paylaşabilirsiniz.
Forumdaki ilgili bölümler
- Sunucu/Hosting Bilgi AlışverişiE-posta teslim ve DNS kayıt sorunları.
- Linux SunucularPosta sunucusu kurulumu ve yapılandırması.
- Domain GenelAlan adı ve DNS kayıtlarıyla ilgili sorular.
Sık sorulan sorular
SPF, DKIM ve DMARC'ın üçü de gerekli mi?
Evet, birbirlerini tamamlarlar. SPF yetkili sunucuları, DKIM iletinin bütünlüğünü doğrular; DMARC ise bu sonuçları görünen gönderen adresiyle ilişkilendirip ne yapılacağını belirler.
Birden fazla SPF kaydı ekleyebilir miyim?
Hayır. Bir alan adında yalnızca bir SPF kaydı bulunmalıdır. Yeni bir gönderen hizmeti eklerken mevcut kayda include veya ip4 ifadesi ekleyin.
DMARC'ta hemen p=reject kullanmalı mıyım?
Önerilmez. Önce p=none ile raporları izleyip tüm meşru gönderenleri doğrulayın, ardından quarantine ve reject politikalarına kademeli geçin.
E-postalarım hâlâ spama düşüyor, kayıtlar doğruysa sebep ne olabilir?
IP veya alan adı itibarı, eksik PTR kaydı, içerik, alıcıların iletileri spam olarak işaretlemesi ve listeden çıkma bağlantısının olmaması gibi etkenler de rol oynar. Kayıtlar gerekli ama tek başına yeterli değildir.
E-posta göndermeyen alan adları için ne yapmalıyım?
v=spf1 -all SPF kaydı ve p=reject DMARC politikası tanımlayın. Böylece alan adınızın sahte gönderimlerde kullanılması zorlaşır.