Reverse DNS (PTR Kaydı) ve Mail Deliverability: Pratik Rehber

Reverse DNS (PTR Kaydı) ve Mail Deliverability: Pratik Rehber

Mail sunucusu kurdunuz. Postfix ayağa kalktı, SPF ve DKIM ayarlandı, DMARC raporları akıyor. Test maili attınız — Gmail spam'a düştü. Header'ı açtınız: "PTR record does not match" satırını gördünüz. Tam burada işin asıl kısmı başlıyor: forward DNS dünyanın en kolay parçası, asıl mesele reverse DNS.

Bu rehber sıradan bir PTR tanım yazısı değil. Bir VDS sunucusunda Postfix kuran, kendi mail trafiğini gönderen, Gmail Postmaster Tools'tan "IP reputation: bad" görmüş bir sysadmin'in adım adım izlediği yolu anlatıyor: in-addr.arpa zone yapısı, RFC 2317 classless delegasyon, IPv6 ip6.arpa nibble formatı, FCrDNS doğrulaması, DNSBL kontrolleri, MTA-STS ve TLS-RPT eklenmesi.

Buyukweb perspektifi: Bursa Pendc Tier 3 veri merkezinde duran VDS müşterilerimizin PTR kayıtları bizim kontrolümüzdedir. Müşterimiz hostname'i seçer, biz arpa zonunda ayarlarız. Forward kayıt müşteride, reverse kayıt bizde — bu mimari dünyada standarttır. Mail trafiği yoğun bir VDS planlıyorsanız ya da deliverability sorunu yaşıyorsanız 0850 302 60 70 numaralı destek hattımızdan PTR talebinizi açabilirsiniz.

Forward DNS vs Reverse DNS: Neden İki Ayrı Sistem?

Forward DNS, "mail.example.com hangi IP'de?" sorusunun cevabını bulur. Reverse DNS, "195.85.100.52 hangi hostname'e ait?" sorusunun cevabını verir. İkisi farklı zonlarda saklanır, farklı kişiler tarafından yönetilir, farklı amaçlara hizmet eder.

Forward (A / AAAA):
mail.example.com   IN A    195.85.100.52
                              ↑
                  example.com sahibi yönetir

Reverse (PTR):
52.100.85.195.in-addr.arpa   IN PTR   mail.example.com.
                                          ↑
                IP bloğunun sahibi (ISP/hosting) yönetir

Forward DNS herkese açıktır — domain sahibi olarak siz hangi A, AAAA, MX, CNAME isterseniz koyabilirsiniz. Reverse DNS ise IP'yi tahsis eden kurumun yetkisi altındadır. RIPE NCC'den /24 IP bloğu alan bir hosting firması, o bloğun arpa zonunu RIPE üzerinden delege alır; ardından kendi nameserver'ında reverse zone yönetir.

Bu mimari, mail kötüye kullanımını önlemenin temel mekanizmasıdır: spam gönderen biri kendi A kaydını rastgele "mail.bigcorp.com" olarak ayarlayabilir, ama IP'nin PTR kaydını değiştiremez — çünkü o IP başkasına ait.

arpa Zone Yapısı: in-addr.arpa ve ip6.arpa

DNS hiyerarşisinde reverse sorgular özel bir top-level domain altında tutulur: arpa (Address and Routing Parameter Area). IPv4 için in-addr.arpa, IPv6 için ip6.arpa alt ağaçlarında.

IPv4 Ters Okuma Mantığı

IPv4 adresi 195.85.100.52'yi PTR sorgulamak için adres ters yazılır ve sonuna .in-addr.arpa eklenir:

195.85.100.52  →  52.100.85.195.in-addr.arpa

Neden ters? Çünkü DNS, en spesifik kısmı sağda tutar. Domain'de mail.example.com yazısının "com" hiyerarşinin tepesinde, "mail" en yaprakta. IP adreslerinde ise tam tersi: 195 hiyerarşinin tepesinde (büyük blok), 52 en yaprakta (host). İki sistemi uyumlu hale getirmek için IP rakamları ters yazılır.

DNS hiyerarşisi tepeden tabana:
.                              (root)
└─ in-addr.arpa
   └─ 195.in-addr.arpa         (RIPE NCC altındaki bloklar)
      └─ 85.195.in-addr.arpa   (ISP'ye delege)
         └─ 100.85.195.in-addr.arpa  (/24 bloğu — hosting firmasına delege)
            └─ 52.100.85.195.in-addr.arpa  (PTR kaydı)

IPv6 ip6.arpa Nibble Formatı

IPv6 adreslerinin 128 biti, 32 hexadecimal karakter olarak yazılır. PTR sorgusu için her karakter (nibble — 4 bit) tek tek ters çevrilir, aralara nokta konur, sonuna .ip6.arpa eklenir.

IPv6: 2a01:4f8:1c0c:abcd::1

Tam yazılım (32 nibble):
2a014f81c0cabcd0000000000000001

Ters çevrilmiş + nokta + ip6.arpa:
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.c.b.a.c.0.c.1.8.f.4.0.1.0.a.2.ip6.arpa

dig komutu bunu otomatik üretir:
dig -x 2a01:4f8:1c0c:abcd::1

VDS sunucunuzun IPv6 PTR kaydını ayarlarken biz size genellikle bir /64 segmenti delege ederiz. /64 IPv6 standart subnet boyutudur ve trilyon kere trilyon adres içerir — tek bir mail sunucusu için fazlasıyla yeterli.

PTR Kaydı Sorgulama: dig, nslookup, host

Linux'ta tipik araçlar:

# dig ile reverse sorgu (en yaygın)
dig -x 195.85.100.52

# Sadece cevap satırını al
dig -x 195.85.100.52 +short

# Manuel arpa zone sorgusu (dig ne yapıyor görmek için)
dig 52.100.85.195.in-addr.arpa PTR

# IPv6 reverse sorgu
dig -x 2a01:4f8:1c0c:abcd::1 +short

# host komutu — hızlı kontrol
host 195.85.100.52

# nslookup (Windows ve Linux'ta var)
nslookup 195.85.100.52

# Belirli bir DNS sunucusuna karşı sorgu
dig -x 195.85.100.52 @8.8.8.8

PowerShell'de:

Resolve-DnsName -Name 195.85.100.52 -Type PTR

Tipik çıktı:

52.100.85.195.in-addr.arpa. 3600 IN PTR mail.example.com.

PTR sonunda mutlaka nokta olur — bu kayıtın FQDN (Fully Qualified Domain Name) olduğunu gösterir, başka domain'in altında değildir.

ISP / Hosting Sağlayıcı Delegasyonu: Kim Yönetir?

PTR kaydını "kim ayarlar" sorusu IP bloğu sahipliğine bağlıdır.

Senaryo	PTR yetkisi	Buyukweb VDS müşterisi için süreç
Tüm /24 blok size tahsis edildi	Sizde	Bağımsız sysadmin'lersiniz; nadir
/29-/28 küçük blok size delege	Genelde sizde (RFC 2317 ile)	Kurumsal VDS / dedike senaryolarda mümkün
Tek IP, hosting firmasına ait	Hosting firmasında	Tipik VDS senaryosu — talep edersiniz, biz set ederiz
Cloud sağlayıcı	Genelde panelden self-serve	Buyukweb değil, farklı model

Buyukweb VDS Müşterisi İçin Pratik Süreç

1. cPanel veya Plesk üzerinde forward kaydı (mail.example.com → IP) önce siz yaparsınız.
2. 0850 302 60 70 destek hattını arar, ya da kontrol panelinden "PTR Kaydı Talebi" açarsınız.
3. Hostname (örn. mail.example.com) ve IP (örn. 195.85.100.52) bilgisini iletirsiniz.
4. Biz arpa zonunda PTR kaydını set ederiz, propagasyonu bekleriz (1-4 saat tipik).
5. dig -x IP +short ile size hostname dönüyorsa kayıt aktif demektir.

RFC 2317 Classless Delegasyon: /24'ten Küçük Bloklar

DNS sistemi başlangıçta IP delegasyonunu sınıf bazlı yapardı: /8, /16, /24. Sınıfsız (CIDR) IP tahsisi geldikten sonra /27, /29 gibi küçük blokları PTR olarak delege etmek bir sorun haline geldi — çünkü arpa zonunun yapısı octet sınırına göre kesilir.

RFC 2317 buna pratik bir çözüm getirir: CNAME zinciri ile /24'ün içindeki dilimleri farklı zonlara işaret edersiniz.

Senaryo: 195.85.100.0/24 bloğu hosting firmasında
         195.85.100.32/27 (32 IP) müşterimize delege

Hosting firmasının /24 zone'unda CNAME zinciri:
$ORIGIN 100.85.195.in-addr.arpa.
32     CNAME    32.32-63.100.85.195.in-addr.arpa.
33     CNAME    33.32-63.100.85.195.in-addr.arpa.
...
63     CNAME    63.32-63.100.85.195.in-addr.arpa.

Müşterinin yönettiği zone:
$ORIGIN 32-63.100.85.195.in-addr.arpa.
32     PTR    mail1.musteri.com.
33     PTR    mail2.musteri.com.

Bu yapı ileri seviye senaryolarda gerekir; tipik tek-IP'li VDS müşterilerinin uğraşmasına gerek yok. Kurumsal /28 veya /29 IP bloğu kiralamış müşterilerimiz isterse bu modeli kullanmak için bizimle koordineli çalışır.

Forward-Confirmed Reverse DNS (FCrDNS): Mail Sunucusu Şartı

PTR kaydı tek başına yeterli değil. Mail dünyasının fiili standardı FCrDNS olarak bilinen iki yönlü doğrulamadır:

1. Mail sunucusu IP'den PTR sorgu:
   195.85.100.52 → mail.example.com.

2. Dönen hostname için forward sorgu:
   mail.example.com → 195.85.100.52

Eğer 1. ve 2. adım aynı IP'yi gösteriyorsa: FCrDNS PASS
Aksi halde: FCrDNS FAIL → mail büyük olasılıkla spam'a gider

Postfix bu kontrolü doğal olarak yapar:

# /etc/postfix/main.cf
smtpd_client_restrictions =
    permit_mynetworks,
    reject_unknown_client_hostname,
    permit

reject_unknown_client_hostname direktifi tam olarak FCrDNS testini uygular. PTR yoksa veya tutmuyorsa bağlantıyı reddeder. Sıkı bir varsayılan, ama meşru mail sunucularıyla aranızda problem doğurabilir; çoğu kurum bu satırı reject_unknown_reverse_client_hostname olarak yumuşatır (sadece PTR yoksa reddet, FCrDNS mismatch'i sadece logla).

Mail Deliverability Ekosistemi: PTR + SPF + DKIM + DMARC + BIMI + ARC

PTR mail teslimatının giriş kapısıdır ama tek katmanı değildir. Modern mail filtreleri bir mesajı kabul etmeden önce şu sinyallerin tümüne bakar:

Katman	Ne yapar?	Sorun çıktığında ne olur?
PTR / FCrDNS	Gönderen IP'nin meşru olduğunu doğrular	Bağlantı reddedilir veya spam
SPF	Domain'den hangi IP'ler mail göndermeye yetkili?	Spam'a düşer veya quarantine
DKIM	Mail içeriğinin değişmediğini imza ile kanıtlar	DMARC pass ratio düşer
DMARC	SPF/DKIM başarısızsa ne yapılsın? Politika sahibi belirler	Reject veya quarantine
BIMI	Doğrulanmış marka logosunu gösterir	Sadece görsel; teslime değil ama açılma oranına etki
ARC	Forwarding zincirinde önceki kontrol sonuçlarını koru	Mailing list arası deliverability düşer
MX	Mail kabul edecek sunucuları belirtir	Mail bounce eder
TLS-RPT / MTA-STS	TLS şifreleme zorlaması ve raporlama	TLS downgrade saldırılarına açıklık

SPF (Sender Policy Framework)

Domain'in TXT kaydında hangi IP'lerin o domain adına mail gönderebileceğini ilan edersiniz:

example.com. IN TXT "v=spf1 ip4:195.85.100.52 ip4:195.85.100.0/24 mx ~all"

Anlamı:
- v=spf1                 SPF versiyon 1
- ip4:195.85.100.52      Tek IP yetkili
- ip4:195.85.100.0/24    Tüm /24 bloğu yetkili
- mx                     Domain'in MX kayıtlarındaki IP'ler de yetkili
- ~all                   Diğer her şey için softfail (yumuşak red)

-all (hardfail) daha sıkıdır ama hata yapma toleransınız sıfırdır; ~all (softfail) çoğu durumda doğru başlangıç.

DKIM (DomainKeys Identified Mail)

Mail sunucunuz çıkan her mesajı özel anahtarla imzalar; alıcı sunucu domain'in TXT kaydındaki public key ile doğrular.

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

Anahtar rotasyonu önemlidir — yılda en az bir kez yeni selector ile (s2025._domainkey gibi) yeni anahtar yayınlayın, eskisini bir süre paralel tutun, sonra kaldırın. Anahtar boyu 2048 bit standart.

DMARC (Domain-based Message Authentication)

SPF veya DKIM doğrulaması başarısız olduğunda alıcı sunucunun ne yapması gerektiğini söylersiniz.

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=s; aspf=s"

p=none           Sadece raporla, bir şey yapma (başlangıçta önerilen)
p=quarantine     Spam/junk klasörüne at
p=reject         Reddet (en sıkı, sonra geç)

rua= aggregate raporlar (XML, günlük özet)
ruf= forensic raporlar (her başarısız mesaj — gizlilik nedeniyle az sağlayıcı destekler)

DMARC yolculuğu pratik olarak şöyle ilerlemeli: Önce p=none ile rua raporları topla, mailing flow'unu analiz et, hangi IP'lerin sahte göndermeye çalıştığını ya da hangi ESP'nin SPF'de eksik olduğunu gör, eksikleri kapat, sonra p=quarantine (örnek %50 ile başla, sonra %100), en son p=reject katmanına geç. Aceleci geçişler meşru mailleri de patlatır.

BIMI (Brand Indicators for Message Identification)

DMARC'ı p=quarantine veya p=reject seviyesine getirdiyseniz, BIMI kaydı ekleyerek alıcı kutusunda marka logonuzun görünmesini sağlayabilirsiniz. Gmail, Yahoo ve Apple Mail destekliyor; Microsoft hâlâ test aşamasında. BIMI için ek olarak VMC (Verified Mark Certificate) zorunlu — bu sertifikayı bir CA'dan satın alırsınız, marka tescil belgeniz olması şart.

ARC (Authenticated Received Chain)

Mail forwarding zincirlerinde (mesela mailing list veya aliases üzerinden geçişlerde) SPF doğal olarak bozulur. ARC, her hop'un kendi kontrolünü kriptografik olarak saklamasını sağlayan başlık zinciridir; sonraki hop "önceki kontrol başarılıydı" sinyalini güvenle alır. Mailman 3, sieve forward ve modern büyük mail sağlayıcıları ARC ekler.

DNSBL/RBL Kontrolü: Kara Listeleri Düzenli Kontrol Edin

DNS-based Blackhole Lists, kötüye kullanım IP'lerini koleksiyon yapan bağımsız listelerdir. Mail sunucuları gelen mailin IP'sini bu listelerde sorgulayarak hızlı bir reputation skoru çıkarır.

Yaygın kullanılan listeler:

• Spamhaus — SBL (Spamhaus Block List), PBL (Policy Block List, dinamik IP'ler için), XBL (Exploits)
• SORBS — Spam and Open Relay Blocking System
• Barracuda Reputation Block List
• SpamCop
• CBL (Composite Blocking List) — Spamhaus XBL'in beslediği DNSBL

Kontrol Yöntemleri

# Manuel sorgu — Spamhaus için IP ters yazılır + zen.spamhaus.org
# 195.85.100.52 listede mi? sorgu adı: 52.100.85.195.zen.spamhaus.org
dig 52.100.85.195.zen.spamhaus.org +short

# Cevap NXDOMAIN ise temizsiniz
# Cevap 127.0.0.X bir IP ise listede — kod alt kategoriyi söyler

# Toplu kontrol için MXToolbox SuperTool kullanın
# https://mxtoolbox.com/blacklists.aspx

Listeden Çıkma (Delisting) Süreci

Listeye düştüğünüzü fark ettiyseniz:

1. Sebebi bul — sunucudan spam mi gitti? Compromise edilmiş bir hesap var mı? Mail logunda olağandışı pattern ara.
2. Sebebi düzelt — açık hesabı kapat, parolayı değiştir, sıkı SPF + DKIM + DMARC çalıştır.
3. Listenin kendi delisting formuna başvur — Spamhaus'ta otomatik bir form var; 24 saat sonra çoğu zaman kaldırılır. SORBS ve Barracuda için manuel form ve bekleme süresi uzun olabilir.
4. Bir kez daha listeye düşmemek için — Postfix smtp_destination_concurrency_limit ile dakikadaki bağlantı sayısını sınırla, anormal trafiği logla.

Aynı IP yıl içinde 3-4 kez listeye düşüyorsa altta yapısal problem var: muhtemelen kullanıcı hesaplarınızdan biri sürekli compromise oluyor. Kök sebebi bulun.

Postmaster Tools: Reputation Görmek İçin Doğru Pencereler

DNSBL listelerinin söylemediği daha derin bilgi alıcı taraf "postmaster" araçlarıdır. Üç tanesi pratik açıdan kritik:

Google Postmaster Tools

Eğer Gmail'e mail gönderiyorsanız (B2C iş yapıyorsanız büyük ihtimalle gönderiyorsunuz), postmaster.google.com adresinde domain'inizi doğrulayın. Tek koşul: domain'inizden Gmail'e günlük yüzlerce mesaj akmalı, yoksa veri görmezsiniz.

Görebileceğiniz metrikler:

• IP reputation (high/medium/low/bad) — gönderen IP'nizin Google gözündeki güvenilirlik seviyesi
• Domain reputation — domain'in genel güvenilirliği
• Spam rate — kullanıcıların sizi spam olarak işaretleme oranı (en kritik metrik)
• Authentication results — SPF / DKIM / DMARC pass yüzdeleri
• Delivery errors — bounce oranları
• TLS encryption rate — şifrelenmemiş mail oranı

Spam rate %0.1'in (binde bir) altında kalmalı; %0.3'ün üzerine çıkarsa Google Inbox yerine Spam'a düşürmeye başlar.

Microsoft SNDS (Smart Network Data Services)

Hotmail, Outlook.com ve Microsoft 365'e mail gönderiyorsanız sendersupport.olc.protection.outlook.com üzerinde SNDS'e başvurun. IP bazlı bir tool: "green / yellow / red" reputation gösterir, complaint rate verir.

Microsoft ayrıca "JMRP (Junk Mail Reporting Program)" üzerinden kullanıcıların "Junk" işaretlediği maillerin geri bildirimini günlük dosya olarak gönderir — abuse hesabınıza akar, otomasyonla işleyebilirsiniz.

Mail-Tester ve MXToolbox

Tek bir mailin nasıl göründüğünü hızlıca test etmek için:

• Mail-Tester (mail-tester.com) — size unique bir adres verir, oraya bir test maili gönderirsiniz, /10 üzerinden puan ve detaylı rapor (SPF, DKIM, DMARC, content score, blacklist hit) çıkarır. 8.5/10 üzeri hedef.
• MXToolbox SuperTool — DNS, MX, SPF, DKIM, DMARC, blacklist, PTR, TLS, MTA-STS, TLS-RPT — tek arayüzde toplu kontrol. Ücretsiz tier yeterli; pro tier sürekli izleme ekler.

TLS-RPT ve MTA-STS: Modern Mail Güvenliği

PTR + SPF + DKIM + DMARC dörtlüsü "yetkilendirme" sorunu çözer; MTA-STS ve TLS-RPT "şifreleme zorlaması" katmanını ekler.

MTA-STS (RFC 8461)

Mail trafiğinin TLS ile şifrelenmesi tarihsel olarak "opportunistic" idi: sunucular STARTTLS deniyordu, başarısız olursa düz metin (cleartext) ile devam ediyordu. MTA-STS bunu "enforce" eder.

# DNS kaydı
_mta-sts.example.com. IN TXT "v=STSv1; id=20260510120000;"

# Politika dosyası: HTTPS endpoint
https://mta-sts.example.com/.well-known/mta-sts.txt

İçerik:
version: STSv1
mode: enforce
mx: mail.example.com
mx: *.mail.example.com
max_age: 604800

mode: enforce sayesinde gönderen sunucu TLS doğrulaması başarısızsa mail'i göndermez (hata raporu üretir). Önce mode: testing ile başlayın, raporları izleyin, sonra enforce'a geçin.

TLS-RPT (RFC 8460)

TLS hatalarını / başarılarını raporlanması için kullanılır. Domain'inize _smtp._tls TXT kaydı koyarsanız, gönderen taraf hangi maillerin TLS ile gittiğini, hangilerinde sorun çıktığını günlük raporla size bildirir.

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Sender Score ve ESP Karar Matrisi

"Validity Sender Score" (eski Return Path) IP bazlı 0-100 reputation skoru verir. Skoru senderscore.org adresinden ücretsiz öğrenebilirsiniz. 80 üzeri iyi, 50 altı ciddi sorun.

Kendi MX vs Üçüncü Taraf SMTP Relay Kararı

Senaryo	Önerilen yaklaşım
Kurumsal mail (employees)	Buyukweb cPanel mail veya VDS Postfix — basit, KVKK Türkiye lokasyonu
Düşük hacim transactional (gün başına 1k-5k)	VDS Postfix, kendi PTR ve DKIM ayarlarınızla yeterli
Yüksek hacim transactional (gün başına 50k+)	SMTP relay servisi (jenerik, üçüncü taraf — KVKK ek değerlendirme)
Pazarlama/bülten	Üçüncü taraf ESP (analytics, unsubscribe yönetimi, deliverability uzmanlığı için)
Karışık (kurumsal + transactional)	Kurumsal cPanel mail, transactional için ayrı VDS

Kararda sadece teknik değil, KVKK boyutu da var: Türkiye'deki kişisel veriyi yurtdışı işleyiciye aktarıyorsanız "yurt dışına veri aktarımı" prosedürü çalışır — açık rıza, taahhütname, KVKK kurul izni gibi. Bu yüzden müşterilerimizin çoğu kurumsal mail için cPanel veya VDS Postfix tercih ediyor.

Sorun Giderme: Tipik PTR / Mail Deliverability Senaryoları

Senaryo 1: "Gmail'e gönderilen tüm maillerim spam'a düşüyor"

# 1. PTR kontrol
dig -x MAIL_IP +short
# Boşsa → Buyukweb destek hattını ara, PTR talep et

# 2. FCrDNS kontrol
PTR=\$(dig -x MAIL_IP +short | sed 's/\.\$//')
dig \$PTR A +short
# IP geri dönmüyorsa → Forward kaydını düzelt

# 3. Blacklist kontrol
dig 52.100.85.195.zen.spamhaus.org +short

# 4. SPF / DKIM / DMARC tarama
# https://www.mail-tester.com/ ile test maili

Senaryo 2: "PTR kaydı koyduk ama hâlâ FCrDNS fail"

Bu klasik tuzak: PTR'da yazan hostname'in A kaydı yok ya da farklı IP'ye gidiyor.

# PTR diyor ki:
dig -x 195.85.100.52 +short
# mail.example.com.

# Forward sorgu
dig mail.example.com A +short
# Eğer 195.85.100.52 gelmiyor veya hiç A kaydı yoksa → FCrDNS fail

# Düzeltme: cPanel Zone Editor'da A kaydı ekle
mail.example.com. IN A 195.85.100.52

Senaryo 3: "EHLO/HELO hostname uyuşmazlığı"

Postfix'in kendini tanıttığı isim PTR ile tutarlı olmalı:

# /etc/postfix/main.cf
myhostname = mail.example.com
smtpd_helo_required = yes

Mail header'ında Received: from x.example.com (mail.example.com [195.85.100.52]) görüyorsanız hostname uyumlu. from unknown görüyorsanız PTR yok demektir.

Sık Sorulan Sorular

"Tek IP'mde birden fazla domain çalıştırıyorum, PTR'a hangi hostname yazmalıyım?"

Tek IP için tek PTR kaydı olur — DNS bunu birden fazla hostname'e ayarlamayı standart olarak desteklemez (multiple PTR teknik olarak mümkün ama mail filtreleri bunu sevmez). En pratik yaklaşım: Mail sunucusunun kullandığı "birincil" hostname'i PTR'a koyun (örn. mail.example.com), Postfix myhostname parametresini de bu isme ayarlayın. Diğer domain'ler aynı sunucudan mail gönderse de SPF + DKIM domain bazlı olduğu için sorun çıkmaz.

"VDS aldım, kendi PTR'ımı self-serve değiştirebilir miyim?"

Buyukweb'in tipik VDS planlarında PTR yönetimi destek talebi üzerinden yapılır. Bunun teknik sebebi, /24 bloklarımızın arpa zonlarının bizde olması ve müşteri başına self-serve panel açmanın güvenlik açısından daha karmaşık olmasıdır. 0850 302 60 70 numarasından arar veya kontrol panelinden ticket açarsanız hostname güncellemeleri tipik olarak aynı gün içinde yapılır.

"IPv6 PTR'ım yok, sadece IPv4'e koymak yetiyor mu?"

IPv6 üzerinden mail göndermiyorsanız (smtp_address_preference = ipv4 Postfix ayarı veya MX kayıtlarınızda sadece A var, AAAA yok) IPv4 PTR yeterli. Ama Gmail giderek IPv6'yı tercih ediyor; IPv6 PTR yoksa IPv6 üzerinden gelen bağlantı doğrudan reddediliyor. Modern bir setup için her iki PTR'ı da ayarlayın.

"DMARC p=reject yaptım, meşru kullanıcılarımdan da maillerim gitmiyor — ne yaptım?"

Bu klasik yanlış adımlama. DMARC reject direkt en sıkı politikadır. Önce p=none ile aggregate (rua) raporları toplamanız, en az 4-8 hafta gözlem yapıp tüm meşru gönderenlerinizi (CRM, helpdesk, transactional ESP, mailing list) SPF ve DKIM'de kapsamanız gerekir. Sonra p=quarantine ile pct=10, ardından pct=50, sonra pct=100 — ancak ondan sonra p=reject. Acele eden kuruluşlar ya bilinmeyen meşru gönderenlerinin maillerini patlatır ya da B2B partnerleri arasında karışıklık çıkarır.

"DNSBL'ye düştüm, ama hiç spam göndermedim, neden?"

İki tipik sebep var: Birincisi, IP yeniden kullanım. Buyukweb müşterilerinde nadir ama dünyada IPs eski sahibi spam göndermişse "PBL" (Spamhaus Policy Block List) sizi de listede tutuyor olabilir — talebimizle çıkartırız. İkincisi, sunucunuzdaki bir hesap compromise oldu: zayıf parolalı bir cPanel hesabı, ya da WordPress'te Form To Mail eklentisi açık SMTP relay olarak kötüye kullanıldı. /var/log/exim_mainlog veya /var/log/maillog dosyalarını grep'leyerek kaynağı bulun.

Sonuç ve Sonraki Adımlar

PTR kaydı, mail deliverability'nin görünmez ama temel taşıdır. Forward DNS kadar dikkat ister; ayarsız bir PTR, en iyi SPF + DKIM + DMARC kombinasyonunuzu bile spam'a düşürebilir. VDS sunucusu üzerinde mail trafiği planlıyorsanız sırayı şöyle kurun:

1. Forward (A / AAAA) — mail.example.com için cPanel Zone Editor üzerinden A ve mümkünse AAAA kaydı ekleyin.
2. PTR (reverse) — Buyukweb destek hattından ya da panelden talep açın. Hostname olarak yukarıdaki forward isminin aynısını verin.
3. FCrDNS doğrulama — dig -x IP ve sonra dig hostname ile iki yönü de teyit edin.
4. SPF + DKIM + DMARC — Sırayla ve gözlem süreleriyle ekleyin. DMARC için p=none ile başlayın.
5. Postmaster Tools kayıt — Google Postmaster ve Microsoft SNDS'te domain ve IP'lerinizi kaydedin.
6. Mail-Tester ile periyodik test — Aylık 8.5/10+ skor hedefleyin.
7. TLS-RPT + MTA-STS — Modern güvenlik katmanı olarak ekleyin (önce testing, sonra enforce).

---

İlgili Büyükweb Hizmetleri

• cPanel Web Hosting — Zone Editor + entegre mail (SPF/DKIM/DMARC otomatik)
• VDS Sunucu — Postfix + Dovecot kendi mail sunucu kurulumu, PTR talep süreci
• Paket Karşılaştırma — Mail trafiği yoğunluğuna göre paket seçimi
• DNS Kayıtları Rehberi — A, MX, TXT, PTR genel kavramsal hub
• SPF, DKIM, DMARC Rehberi — Mail kimlik doğrulama derinlemesine

Reverse DNS, mail deliverability ve VDS PTR yönetimi konusunda destek için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz.