Komutları üretim sunucusunda çalıştırmadan önce yedek alın ve mümkünse bir test ortamında deneyin. Yönetim erişiminizi (SSH, panel) kaybetmemek için ayar değişikliklerinde açık bir ikinci oturum bulundurun.
Bu rehberde ne yapacağız?
Bayi hosting müşterilerinizin e-postalarının spam klasörüne düşmesi veya alıcılar tarafından reddedilmesi, çoğunlukla e-posta itibarı sorunlarından kaynaklanır. Bu rehberde SPF, DKIM ve DMARC kayıtlarını kontrol edecek, DMARC toplu (aggregate) raporlarını okumayı öğrenecek ve politikayı güvenli biçimde none, quarantine ve reject aşamalarıyla sıkılaştıracaksınız.
Rehber, bayi hosting sağlayıcılarına ve müşterilerinin alan adlarının e-posta teslimatından sorumlu sistem yöneticilerine hitap eder. İlk kurulum yaklaşık 30-45 dakika sürer; asıl değer, haftalar boyunca gelen raporların okunmasından gelir. Örneklerde example.com alan adı ve 203.0.113.10 test IP adresi kullanılmıştır.
Gereksinimler
- Müşteri alan adının DNS kayıtlarını değiştirebileceğiniz bir DNS paneli veya API erişimi
- Alan adının e-postasını gönderen sunucuların listesi (kendi sunucunuz, haber bülteni servisi, CRM vb.)
- DMARC raporlarını alacak, bayi bazında ayrılmış bir posta kutusu
- Komut satırında dig aracı (Debian/Ubuntu için dnsutils, RHEL tabanlı için bind-utils paketi)
Adım adım e-posta itibarı ve DMARC raporlarını okuma
1. Mevcut SPF, DKIM ve DMARC durumunu kontrol edin
Önce alan adının şu an hangi kayıtlara sahip olduğunu görün. Hiçbir değişiklik yapmadan önce bu çıktıyı kaydedin.
sudo apt install dnsutils # Debian / Ubuntu
sudo dnf install bind-utils # AlmaLinux / Rocky
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.comDKIM kaydında selector1 yerine sunucunuzun kullandığı gerçek selector adını yazın; bu ad posta başlığındaki DKIM-Signature satırında s= alanında görünür. Bir alan adında yalnızca bir SPF kaydı olmalıdır; birden fazla SPF TXT kaydı SPF değerlendirmesini geçersiz kılar.
2. SPF kaydını doğru kurun
SPF, alan adı adına hangi sunucuların posta gönderebileceğini bildirir. Yalnızca gerçekten gönderen sistemleri ekleyin. Örnek bir kayıt değeri aşağıdadır:
v=spf1 ip4:203.0.113.10 include:spf.gonderen-servis.example ~allBaşlangıçta ~all (yumuşak başarısızlık) kullanmak ve DMARC raporlarıyla doğruladıktan sonra -all değerine geçmek güvenli bir yaklaşımdır. SPF değerlendirmesinde en fazla 10 DNS sorgusu yapılabilir; çok fazla include eklemek bu sınırı aşabilir.
3. DKIM imzalamasını etkinleştirin
DKIM, giden postaları özel anahtarla imzalar ve alıcı, DNS'teki açık anahtarla doğrular. Posta sunucunuzda veya panelinizde alan adı için DKIM imzalamasını açın ve üretilen açık anahtarı selector adıyla birlikte DNS'e TXT kaydı olarak ekleyin. Anahtar uzunluğu için güncel öneri en az 2048 bittir; DNS sağlayıcınız uzun TXT değerlerini bölmeyi destekliyorsa bunu kullanın.
Doğrulamak için kendinize bir test postası gönderip alınan postanın başlıklarında Authentication-Results satırında dkim=pass ifadesini arayın.
4. DMARC kaydını izleme modunda ekleyin
DMARC, SPF ve DKIM sonuçlarını alan adı ile hizalar ve alıcıya başarısız postalara ne yapacağını söyler. İlk aşamada hiçbir postayı engellemeden yalnızca rapor toplayın.
_dmarc.example.com TXT v=DMARC1; p=none; rua=mailto:dmarc-raporlari@example.com; fo=1Burada p=none yalnızca izleme demektir, rua toplu raporların gönderileceği adrestir. Raporları başka bir alan adındaki adrese gönderiyorsanız, o alan adı tarafında yetkilendirme kaydı gerekebilir; bu ayrıntı için DMARC belirtimine bakın. Raporlar için ayrı bir posta kutusu açın; her gün onlarca küçük rapor gelebilir.
5. Toplu (aggregate) raporu okuyun
Raporlar genellikle .xml.gz veya .zip uzantılı ekler halinde gelir (.zip için zcat yerine unzip -p rapor.zip kullanın). İçinde, her gönderen IP adresi için kaç posta gönderildiği ve SPF ile DKIM sonuçları yer alır. Dosyayı açıp kaynak IP adreslerini ve sonuçları özetleyin:
zcat rapor.xml.gz | head -n 40
zcat rapor.xml.gz | grep -o '<source_ip>[^<]*' | sort | uniq -c | sort -nr
zcat rapor.xml.gz | grep -o '<dkim>[^<]*\|<spf>[^<]*' | sort | uniq -cRaporda bakacağınız başlıca alanlar şunlardır:
- source_ip: postayı gönderen IP adresi. Tanımadığınız bir IP varsa ya unutulmuş meşru bir servistir ya da sahtecilik girişimidir.
- count: o IP'den gelen posta sayısı.
- disposition: alıcının uyguladığı karar (none, quarantine, reject).
- dkim ve spf: kimlik doğrulama sonuçları (pass veya fail).
- header_from: görünen gönderen alan adı.
Meşru bir gönderici DKIM veya SPF'de fail alıyorsa onu SPF kaydına ekleyin veya DKIM imzalamasını o servis için yapılandırın. Tanımadığınız ve fail alan IP'ler ise sahtecilik denemesi olabilir; bu IP'ler politika sıkılaştırıldığında engellenecektir.
6. Politikayı kademeli sıkılaştırın
En az iki üç hafta temiz rapor gördükten sonra politikayı yükseltin. Doğrudan reject değerine atlamayın; unutulmuş bir meşru gönderici postalarının kaybolmasına yol açar.
# 1. aşama: izleme
v=DMARC1; p=none; rua=mailto:dmarc-raporlari@example.com
# 2. aşama: karantina, postaların küçük bir kısmına uygulanır
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-raporlari@example.com
# 3. aşama: tam karantina, ardından reddetme
v=DMARC1; p=quarantine; rua=mailto:dmarc-raporlari@example.com
v=DMARC1; p=reject; rua=mailto:dmarc-raporlari@example.comHer aşama arasında raporları yeniden inceleyin. Sorun çıkarsa bir önceki aşamaya dönmek tek bir DNS değişikliği kadar kolaydır.
7. Sunucu tarafı itibar kontrollerini tamamlayın
Alan adı kayıtları kadar gönderen IP adresinin itibarı da önemlidir. Ters DNS (PTR) kaydı posta sunucusunun adıyla eşleşmeli ve ileri DNS kaydı aynı IP'ye dönmelidir. Kontrol:
dig +short -x 203.0.113.10
dig +short A mail.example.comİki sorgu birbirini doğrulamalıdır. PTR kaydını genellikle IP bloğunu size veren sağlayıcı yönetir; değiştirmek için onunla iletişime geçin. Ayrıca IP adresinizin kamuya açık kara listelerde olup olmadığını düzenli sorgulayın.
Doğrulama
Kayıtların yayınlandığını ve geçerli olduğunu aşağıdaki komutlarla doğrulayın:
dig +short TXT _dmarc.example.com
dig +short TXT example.com | grep spf1Beklenen sonuç: DMARC sorgusunda v=DMARC1; p=... ile başlayan tek bir kayıt, SPF sorgusunda ise yalnızca bir adet v=spf1 kaydı görmenizdir. Ardından harici bir Gmail veya benzeri hesaba test postası gönderip ham başlıkta spf=pass, dkim=pass ve dmarc=pass ifadelerini arayın. Yaklaşık 24-48 saat içinde ilk toplu raporların gelmesini bekleyin.
Sık karşılaşılan sorunlar
- Belirti: DMARC raporu hiç gelmiyor. Çözüm: Kayıt adının tam olarak _dmarc olduğunu, rua adresinin yazımını ve ayrı alan adı kullanılıyorsa yetkilendirme kaydını kontrol edin; DNS yayılım süresini bekleyin.
- Belirti: Meşru postalar DMARC'ta fail alıyor. Çözüm: Göndericinin alan adı hizalamasına bakın; üçüncü taraf servis kendi alan adıyla imzalıyorsa kendi DKIM selector'ünü sizin alan adınıza tanımlayın.
- Belirti: SPF permerror sonucu görülüyor. Çözüm: Birden fazla SPF kaydı veya 10 sorgu sınırı aşılmış olabilir; kayıtları birleştirin, gereksiz include satırlarını kaldırın.
- Belirti: Postalar yalnızca bazı alıcılarda spam klasörüne düşüyor. Çözüm: PTR kaydı, IP itibarı ve gönderim hacmindeki ani artışları inceleyin.
Güvenlik ve bakım notları
- DMARC raporları gönderen IP adresleri ve posta hacimleri içerir; rapor kutusuna erişimi yetkili yöneticilerle sınırlayın.
- Her müşteri alan adı için ayrı rapor adresi kullanmak veya raporları etiketlemek, bayi bazında analiz yapmayı kolaylaştırır.
- Yeni bir servis (bülten aracı, CRM) kullanmaya başlayan müşteriden bunu önceden bildirmesini isteyin; SPF ve DKIM kaydı politika değişmeden eklenmelidir.
- DKIM anahtarlarını belirli aralıklarla (örneğin yılda bir) yenileyin ve eski selector'ü bir süre DNS'te tutun.
- Giden posta hacmi ve hesap başına saatlik gönderim limitleri itibarı koruyan en etkili sunucu tarafı önlemlerdendir.
- Politikayı reject yaptıktan sonra da raporları izlemeyi bırakmayın; yeni gönderici eklemeleri raporlarda ilk görünür.
Sık sorulan sorular
DMARC p=none yeterli mi?
p=none yalnızca izleme sağlar; sahte postaları engellemez. Raporlarla meşru göndericileri doğruladıktan sonra quarantine ve ardından reject aşamasına geçmek hem itibarınızı hem alıcılarınızı korumak için gereklidir.
DMARC raporlarını elle okumak zorunda mıyım?
Küçük ölçekte komut satırıyla özetlemek yeterlidir; çok sayıda alan adı yönetiyorsanız raporları ayrıştırıp görselleştiren bir araç kullanmak zaman kazandırır. Hangi yolu seçerseniz seçin, source_ip ve sonuç alanlarını anlamak temel beceridir.
Bayi müşterim DMARC'ı kendisi yönetebilir mi?
Evet, alan adının DNS yönetimi müşteride ise kayıtları o ekler. Sağlayıcı olarak ona şablon kayıtlar ve bu rehberdeki aşamalı geçiş planını sunmak, hataya bağlı teslimat sorunlarını azaltır.
İlgili sözlük terimleri
Bu kategorideki diğer rehberler
- Bayi hosting için müşteri yedekleme politikası ve geri yükleme süreciBayi hosting müşterileri için yedekleme politikasını yazın: sıklık, saklama süresi, restic ile otomatik yedek, veritabanı dökümü ve müşteri talebiyle güvenli geri yükleme sürecini uygulayın.
- Bayi hostingde abuse (kötüye kullanım) şikâyetlerini yönetme süreciBayi hostingde gelen abuse şikâyetlerini alma, sınıflandırma, kanıt toplama, müşteriye bildirme ve çözme sürecini; spam, phishing ve zararlı yazılım örnekleriyle adım adım uygulayın.
- Reseller hosting paket ve kaynak planlamaReseller hosting paketlerini aşırı satış riskini hesaplayarak planlayın: CPU, RAM, disk ve G/Ç limitlerini belirleyin, kaynak kullanımını izleyin ve eşik uyarıları kurun.
- Bayi müşterilerine yönelik güvenlik bilgilendirme şablonuBayi hosting müşterilerinize güvenlik uyarıları, olay bildirimi ve bakım duyurusu için kullanabileceğiniz hazır, sade Türkçe şablonlar ve iletişim ilkeleri.