cPanel ve VPS’te SPF, DKIM ve DMARC Kurulumu

SPF, DKIM ve DMARC Neden Önemli?

Örneğin, web sitesi ve sipariş formları çalışan bir işletmenin e‑postaları alıcılara ulaşmayabilir veya spam klasörüne düşebilir. SPF, DKIM ve DMARC yapılandırması bu durumda kontrol edilmesi gereken başlıca noktalardandır; ancak doğru doğrulama tek başına gelen kutusuna teslimatı garanti etmez.

Büyük sağlayıcıların doğrulama gereksinimleri gönderim türüne göre değişir. Örneğin Gmail, tüm gönderenlerden SPF veya DKIM; toplu gönderenlerden ise SPF, DKIM ve DMARC ister. MX kaydı almak için yönlendirme sağlar, gönderimi doğrulamaz. SPF gönderici IP’sini yetkilendirir, DKIM dijital imzayı doğrulatır, DMARC ise görünür gönderen alan adıyla hizalamayı ve başarısızlık politikasını tanımlar.

Bu güncellenmiş rehber, cPanel’in Email Deliverability arayüzünü ve panel kullanmadan Postfix üzerinde DKIM imzalamayı ele alır. paylaşımlı hosting hizmetinde görünen özellikler, sürüme ve sağlayıcının verdiği yetkilere bağlıdır. Önce gerçek göndericileri ve yetkili DNS’i belirleyecek, sonra kayıtları ve alıcı tarafındaki doğrulama sonuçlarını kontrol edeceğiz. VPS bölümü, mevcut ve güvenli bir posta sistemine eklenen imzalama iskeletidir.

SPF, DKIM, DMARC ve rDNS ile e-posta teslim edilebilirliğini artırma rehberi daha geniş teslimat sorunlarını ele alır. Buradaki SPF, DKIM ve DMARC adımlarını uygularken mevcut kayıtları ve sunucu yapılandırmasını yedekleyin. VPS üzerinde tam bir posta sistemi; erişim kontrolü, SMTP kimlik doğrulaması, TLS, kuyruk ve güncelleme yönetimi de gerektirir. Yalnızca bu üç DNS kaydını eklemek bütün kurulumu tamamlamaz.

SPF, DKIM ve DMARC Temelleri

SPF nedir, nasıl çalışır?

SPF (Sender Policy Framework), alan adınız adına hangi sunucuların e‑posta göndermeye yetkili olduğunu DNS üzerinden ilan etmenizi sağlayan bir mekanizmadır. Alıcı sunucu, bağlantıyı kuran IP’nin SMTP zarfındaki MAIL FROM alan adı için yetkili olup olmadığını denetler; boş MAIL FROM durumunda HELO kimliği kullanılır. Bu kontrol, kullanıcının gördüğü From: başlığını doğrudan doğrulamaz.

SPF kaydı, değerlendirilen alan adının DNS’inde tek bir SPF TXT kaydı olarak tutulur. Aşağıdaki şablondaki example.com ve 203.0.113.10 örnektir; gerçek alan adınız ve çıkış IP’nizle değiştirin. a ve mx mekanizmalarını yalnızca bunların yetkilendirdiği sunucular gerçekten posta gönderiyorsa kullanın:

example.com.  3600  IN  TXT  "v=spf1 a mx ip4:203.0.113.10 -all"

• v=spf1: SPF sürümü
• a: Alan adınızın A/AAAA kayıtlarıyla eşleşen gönderici IP’leri yetkilidir
• mx: MX kayıtlarının gösterdiği sunucu adlarının A/AAAA adresleriyle eşleşen gönderici IP’leri yetkilidir
• ip4:…: Ek olarak bu IPv4 adresi yetkilidir
• -all: Bunun dışındaki tüm IP’ler yetkisizdir (fail)

SPF sonucu, değerlendirilen zarf veya HELO alan adı için gönderim yetkisini gösterir; görünür From: başlığını veya mesaj içeriğini doğrulamaz. DKIM farklı bir kimliği ve imza kapsamını doğrular. DMARC’ın SPF değerlendirmesi MAIL FROM kimliğine dayanır; ayrı bir HELO SPF başarısı yeterli değildir. DMARC’ın geçmesi için MAIL FROM alan adıyla başarılı SPF veya imzalayan alan adıyla başarılı DKIM sonuçlarından en az biri görünür From: alan adıyla hizalanmalıdır. Bir mekanizmanın başarısız olması, diğeri başarılı ve hizalıysa DMARC’ı otomatik olarak başarısız yapmaz.

DKIM nedir, nasıl çalışır?

DKIM (DomainKeys Identified Mail), gönderdiğiniz maillerin gövdesini ve seçili başlıklarını kapsayan bir dijital imza oluşturur ve bunu DKIM-Signature başlığına ekler. Bu imza, sunucunuzdaki özel anahtarla oluşturulur. Alıcı sunucu ise alan adınızın DNS’inde yayınladığınız genel anahtarı kullanarak bu imzanın geçerli olup olmadığını kontrol eder.

Basitçe:

• Sunucunuz, gövdeyi seçilen kanonikleştirme kurallarına göre işler ve özetini (hash) hesaplar.
• Seçili başlıklar ile bu gövde özetini içeren DKIM-Signature alanını özel anahtarınız ile imzalar.
• İmza, mail başlıklarına DKIM-Signature: satırı olarak eklenir.
• Alıcı, DNS’te selector._domainkey.example.com altında yayınladığınız genel anahtarı bulur ve imzayı doğrular.

Başarılı doğrulama, imzalayan alan adının mesaj için sorumluluk üstlendiğini ve imza kapsamındaki içeriğin kanonikleştirme kuralları çerçevesinde korunduğunu gösterir. Gönderen kişinin kimliğini, içeriğin güvenliğini veya görünür From: alan adıyla eşleşmeyi tek başına kanıtlamaz.

DMARC nedir, neden kritik?

DMARC (Domain-based Message Authentication, Reporting and Conformance), SPF ve DKIM sonuçlarını görünür From: alan adıyla hizalama açısından değerlendiren, raporlama ve başarısızlık halinde istenen alıcı politikasını tanımlayan standarttır. Alıcı, nihai teslimat kararında kendi filtrelerini de kullanır.

DMARC ile:

• DMARC başarısız olduğunda alıcıdan istediğiniz işlemi belirtirsiniz (none, quarantine, reject). DMARC’ın geçmesi için SPF veya DKIM’den en az birinin başarılı olması ve doğruladığı alan adının görünür From: alan adıyla hizalanması yeterlidir.
• Alignment (hizalama) kuralları ile, kullanılan alan adının From: başlığıyla ne kadar örtüşmesi gerektiğini tanımlarsınız.
• RUA/RUF adresleriyle toplu ve başarısızlığa ilişkin ayrıntılı DMARC raporları talep edersiniz; her alıcı rapor göndermez. RUF raporları kişisel veri ve mesaj içeriği açığa çıkarabilir; rutin izleme için toplu raporlar tercih edilir.

Meşru gönderim kaynakları doğrulandıktan sonra kullanılabilecek bir karantina politikası örneği aşağıdadır. İlk kurulumda, ilerideki izleme örneğindeki gibi p=none ile başlayın. example.com yerine kendi alan adınızı, rapor adresi yerine yönettiğiniz posta kutusunu kullanın:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

DMARC’ı daha ileri seviyede kullanmak, BIMI gibi marka gösterimlerine girmek isterseniz, Gelişmiş DMARC ve BIMI rehberimizde raporların nasıl analiz edileceğini ve politika sıkılaştırmayı detaylı anlattık.

E‑Posta Doğrulamasına Geçmeden Önce Hazırlıklar

SPF, DKIM ve DMARC ayarlarına girmeden önce, altyapınızda bazı temel noktaların net olması gerekiyor:

• Alan adınızın DNS yönetimine erişebiliyor musunuz? (yetkili DNS kayıtlarını barındıran sağlayıcının paneli)
• MX kayıtlarınız doğru mu? Mailleri hangi sunucu alıyor?
• Mail gönderilen IP’lerin listesi net mi? (cPanel hosting IP’si, VPS IP’si, üçüncü parti servisler vb.)
• Reverse DNS (PTR) kaydınız mail için kullandığınız IP’de doğru tanımlı mı?

DNS tarafına hâkim değilseniz, önce DNS kayıtları A’dan Z’ye rehberimizi okumanızı öneririm. Oradaki temel bilgiler, SPF/DKIM/DMARC kurarken hangi kaydı, hangi isimle ve hangi içerikle girdiğinizi zihninizde daha net oturtacaktır.

cPanel Üzerinde SPF, DKIM ve DMARC Kurulumu

Güncel cPanel belgelerindeki yol Email Deliverability → Manage şeklindedir. Arayüz sağlayıcı tarafından etkinleştirilmiş olmalıdır; eski Authentication ekranındaki “Enable” düğmesini bütün sürümlerde var saymayın. Ekrandaki DNS doğrulaması, her uygulamanın gerçekten DKIM imzalı posta gönderdiğini kanıtlamaz. Harici posta hizmeti kullanıyorsanız o hizmetin gönderim kimlikleri ve DKIM yönergeleri esas alınır.

1) cPanel’de SPF Önerisini İnceleme ve Yayımlama

cPanel sürümüne göre menü isimleri küçük farklılıklar gösterebilir. Değişiklikten önce mevcut SPF politikanızı ve tüm gönderim kaynaklarını kaydedin. DNS harici bir sağlayıcıdaysa SPF kaydını da yetkili DNS panelinde yayımlamanız gerekir:

1. cPanel’de Email Deliverability bölümünü açıp ilgili domain için Manage seçin.
2. Suggested “SPF” (TXT) Record alanındaki ad ve değeri mevcut politika ve gönderici envanteriyle karşılaştırın; gerekiyorsa Customize ile öneriyi düzenleyin.
3. Sunucu yetkili DNS’i yönetiyorsa Repair, önerileri inceleyip onayladığınızda geçersiz kayıtları onarır; yalnızca öneri gösteren bir düğme değildir.
4. Sunucu DNS’i yönetmiyorsa Repair kullanılamaz. Öneriyi yetkili DNS sağlayıcısında yayımlayın; yerel cPanel bölgesine yazmak dış DNS’i güncellemez.

Örnek bir SPF şablonu aşağıdadır. IP_ADRESINIZ yer tutucusunu gerçek gönderim IPv4 adresinizle değiştirin; a ve mx yetkilerinin gönderim kaynaklarınıza uygunluğunu kontrol edin:

v=spf1 +a +mx +ip4:IP_ADRESINIZ ~all

Buradaki ~all, önceki mekanizmalar eşleşmediğinde softfail verir; başarılı SPF doğrulaması değildir. Tek başına ret gerekçesi yapılmaması önerilir. Tüm meşru gönderim kaynaklarını doğruladıktan sonra -all kullanmayı değerlendirebilirsiniz; bu değişiklik DMARC politikasından ayrıdır.

Eğer alan adınız adına başka servisler de mail gönderiyorsa (örneğin bir e‑posta pazarlama platformu veya fatura sistemi), servislerin yönergelerine göre hangi zarf alan adı için SPF gerektiğini belirleyin. Her servis kök alan adınıza include eklenmesini gerektirmez. Gereken yetkileri aynı alan adındaki mevcut SPF politikasına, son all mekanizmasından önce ekleyin; ikinci bir SPF kaydı oluşturmayın. SPF değerlendirmesinde DNS sorgusu gerektiren mekanizma ve değiştiriciler için toplam 10 sınırı vardır; iç içe include/redirect değerlendirmeleri de bu sınıra dahildir. ip4, ip6 ve all bu sayıya dahil değildir. Çok parçalı SPF kayıtlarını optimize etmek için SPF flattening stratejilerini anlattığımız yazıya göz atabilirsiniz.

2) DKIM Anahtarı, DNS Kaydı ve İmzalama Kontrolü

Email Deliverability → Manage → DKIM bölümünü açın. Eksik bir anahtar için Generate Local DKIM Key seçeneği bulunabilir; geçerli bir anahtarı sebepsiz yeniden üretmeyin. Önerilen Name ve Value alanlarını kopyalayarak yayımlanacak genel anahtarı alın. View the Private Key ile görülen özel anahtar DNS’e yazılmaz ve paylaşılmaz.

• Sunucudaki anahtar ile yetkili DNS’teki DKIM kaydının eşleştiğini doğrulayın; mevcut geçerli selector’ı yanlışlıkla değiştirmeyin.
• Yerel DNS kurulumu ile dış DNS yayınını ayırın. Genel anahtarın DNS’te bulunması tek başına uygulamanın imzalama yolunu etkinleştirmez.
• Gerçek gönderim yolundan test mesajı gönderin. İmza yoksa hosting yöneticisi domainin DKIM etkinliğini ve kullanılan Exim/PHP/SMTP yolunu incelemelidir; gelen posta için DKIM doğrulama ayarı, giden posta imzalama ayarı değildir.

cPanel’in önerdiği default._domainkey.example.com adı bir örnektir; kendi ekranınızdaki tam Name ve Value değerini kullanın. Harici DNS’te kayıt sunucudaki anahtarla uyuşmuyorsa cPanel, başarısız imzayı önlemek için giden postayı imzalamayabilir. DNS’i düzeltip yeniden kontrol edin. Kaydın uzun değeri tek TXT kaydında birden fazla karakter dizisine bölünebilir; bütün parçalar eksiksiz kalmalıdır.

3) cPanel’de DMARC kaydı ekleme

Güncel Email Deliverability arayüzünde Suggested DMARC (TXT) Record bölümü de vardır; yetkili DNS bu sunucudaysa Install the Suggested Record kullanılabilir. Önerilen değeri önce okuyun ve mevcut politikayı koruyun. Rapor adresi gibi özel değerler için Zone Editor veya yetkili dış DNS panelinde mevcut TXT kaydını düzenleyin. Aynı adda ikinci bir DMARC politikası oluşturmayın.

1. DNS cPanel tarafından yetkili olarak yönetiliyorsa Zone Editor → Manage yolunu açın.
2. Mevcut _dmarc TXT kaydını arayın; varsa düzenleyin, yoksa Add Record ile TXT kaydı ekleyin.
3. Kayıt adının son durumda tam olarak _dmarc.example.com olacağını doğrulayın. Panelin domain ekleme davranışına göre adı girin; domaini iki kez eklemeyin.

Yeni bir politikada meşru göndericileri tanımak için aşağıdaki izleme örneği kullanılabilir. example.com ve rapor adresini kendinize uyarlayın. p=none yalnızca DMARC’a dayanarak karantina veya ret istemez; alıcıların diğer spam kontrollerini kapatmaz.

Ad (Name): _dmarc
Tür (Type): TXT
TTL: 3600
Kayıt (Record): "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

• p=none: DMARC politikası nedeniyle karantina/ret talep edilmez; teslimat yine alıcı politikasına bağlıdır.
• rua: Toplu raporların gönderilmesi istenen adrestir. Her alıcı rapor göndermez; sabit bir başlangıç zamanı yoktur.
• Harici rapor adresi: Aynı organizasyon alan adının dışına rapor istiyorsanız rapor alıcısının DNS yetkilendirmesi gerekir. Ayrıntılı ruf/fo raporları ayrı ve isteğe bağlıdır; kişisel veri içerebildikleri için başlangıç örneğine eklenmemiştir.

Politikayı, süre dolduğu için değil meşru kaynaklar ve yönlendirme senaryoları doğrulandığı için değerlendirin. Güncel DMARC standardı RFC 9989, yüzde tabanlı pct etiketini kaldırmıştır. Genel kullanıcıların posta listelerine yazabildiği domainlerde p=reject önerilmez. Böyle bir domain yine de reject’i değerlendiriyorsa en az bir ay none, ardından en az aynı süre quarantine raporlarını karşılaştırması önerilir.

• p=quarantine: DMARC’ı geçemeyen mesajlar için karantina işlemi talep eder; yalnızca “şüpheli içerik” sınıflandırması değildir.
• p=reject: DMARC’ı geçemeyen mesajlar için ret talep eder; her domainin zorunlu son aşaması değildir. Bu politikayı kullanan gönderenler geçerli DKIM imzası uygulamalı ve yalnızca SPF’e güvenmemelidir.

Bu sıkılaştırma sürecini ve RUA/RUF raporlarını okuma tarafını detaylı öğrenmek için yine gelişmiş DMARC ve BIMI rehberimize bakabilirsiniz.

4) cPanel’de test ve doğrulama

Ayarlardan sonra mutlaka test edin:

• Webmail, uygulama ve kullanılan harici göndericilerden, izinli test adreslerine ayrı mesajlar gönderin.
• Alıcı sağlayıcının eklediği güvenilir Authentication-Results: bölümünde SPF, DKIM ve DMARC sonuçlarına bakın; rastgele eklenmiş bir başlık kanıt değildir.
• Received-SPF: pass veya dkim=pass sonucunun hangi alan adına ait olduğunu, görünür From: ile hizalanmasını ve dmarc=pass sonucunu birlikte inceleyin. DKIM-Signature başlığının varlığı tek başına başarılı doğrulama değildir.

Başarısızlıkta önce doğru yetkili DNS’in doğru kaydı verdiğini kontrol edin; ardından alıcının hata nedenini ve signer’ın kullandığı d=/s= değerlerini inceleyin. Önceki yanıtlar TTL boyunca önbellekte kalabilir; 5–30 dakika gibi evrensel bir yayılma süresi yoktur. Bir TXT kaydının birden fazla tırnaklı parçaya bölünmesi normal olabilir; asıl sorun eksik parçalar, iki ayrı politika veya yanlış kayıt adıdır.

VPS Üzerinde SPF, DKIM ve DMARC Kurulumu (Panelsiz Senaryo)

Aşağıdaki örnek, Debian 12 üzerinde mevcut Postfix ve OpenDKIM 2.11 düzenine uyarlanacak bir imzalama iskeletidir. Güvenilir yerel uygulama gönderimi esas alınır; tam bir internet posta kutusu, Dovecot veya açık SMTP submission kurulumu değildir. Kullanıcı ve SMTP erişimini ayrıca sınırlandırın. cPanel’in yönettiği Exim dosyalarına bu Postfix örneğini uygulamayın; dağıtım paketleri ve servis başlatma seçenekleri etkin ayarları değiştirebilir.

VPS’te eksiksiz bir e‑posta sistemi kurmak için Postfix, Dovecot, spam filtresi ve IP ısınması gibi konulara da girmeniz gerekiyorsa, Postfix + Dovecot + rspamd ile VPS üzerinde e‑posta sunucusu kurulum rehberimizi mutlaka okuyun.

1) DNS tarafında temel SPF kaydını oluşturma

SPF kaydını, SMTP zarfında kullandığınız alan adının yetkili DNS’inde düzenleyin. Yalnızca tek bir IPv4 çıkışı yetkilendirilecekse aşağıdaki örnekte gereksiz a ve mx yetkileri bulunmaz. 203.0.113.10 dokümantasyon adresidir; gerçek çıkış IP’nizle değiştirin. IPv6 veya başka göndericiler varsa onların yetkisini de gerçek gönderim kimliğine göre ekleyin:

Ad (Name): @  (panelde alan adı kökünü temsil ediyorsa)
Tür (Type): TXT
Kayıt (Record): "v=spf1 ip4:203.0.113.10 -all"

Burada:

• a ve mx bu dar örnekte kullanılmaz; ihtiyaç varsa A/AAAA ve MX hedef adreslerinin hangilerini yetkilendirdiğini anlayarak ekleyin.
• ip4:203.0.113.10 belirtilen IPv4 adresini yetkilendirir; gerçek gönderim adresiyle değiştirilmelidir.
• -all diğer adresler için SPF fail üretir; alıcının mesajı kesin reddetmesini tek başına emretmez.

Bir web sunucusunun A kaydı veya gelen posta için MX kaydı, o sunucunun dışarı e-posta göndermesi gerektiğini göstermez. Dar IP yetkisi yeterliyse a/mx eklemeyin. Harici SMTP relay kullanıldığında SPF’i gerçek zarf alan adı ve relay’in belgelerine göre kurun; uygulama sunucusunun IP’sini otomatik olarak yetkilendirmeyin.

2) VPS’te DKIM için OpenDKIM kurulumunun iskeleti

Önce mevcut yapılandırmayı ve anahtarları yedekleyin. Aşağıdaki example.com ve default selector’ı örnektir; etkin bir selector’ın anahtarını üzerine yazarak değiştirmeyin. Paket kurulumu ve dosya değişiklikleri yönetici yetkisi gerektirir. Mevcut Milter veya OpenDKIM Domain/KeyFile/Selector ayarları varsa bunları aşağıdaki KeyTable/SigningTable modeliyle çakışmayacak şekilde uyarlayın:

1. Debian 12 paket listesini güncelleyip paket kurulum planını inceleyin:

   apt-get update &&
   apt-get install opendkim opendkim-tools

2. Yeni selector için anahtar üretin. Aynı selector’ın dosyaları varsa bu adımı uygulamayın:

   mkdir -p /etc/opendkim/keys/example.com
   opendkim-genkey -b 2048 -s default -d example.com -D /etc/opendkim/keys/example.com
   chown opendkim:opendkim /etc/opendkim/keys/example.com/default.private
   chmod 600 /etc/opendkim/keys/example.com/default.private

3. /etc/opendkim/KeyTable içinde anahtar adını, imza alan adını, selector’ı ve dosyayı eşleyin:

   default._domainkey.example.com example.com:default:/etc/opendkim/keys/example.com/default.private

4. /etc/opendkim/SigningTable dosyasına imzalanacak alanı ekleyin:

   *@example.com default._domainkey.example.com

5. /etc/opendkim/TrustedHosts için bu yerel gönderim örneğinde yalnızca loopback kaynaklarını tanımlayın; herkese açık ağları güvenilir ilan etmeyin:

   127.0.0.1
   ::1
   localhost

6. /etc/opendkim.conf içindeki mevcut ayarları bu modele uyarlayın. Paket/servis komut satırının Socket veya kullanıcı ayarını geçersiz kılmadığını kontrol edin:

   Syslog          yes
   UMask           0077
   UserID          opendkim:opendkim
   Mode            sv
   Canonicalization        relaxed/simple
   SubDomains      no
   AutoRestart     yes
   AutoRestartRate 10/1M
   KeyTable        /etc/opendkim/KeyTable
   SigningTable    refile:/etc/opendkim/SigningTable
   ExternalIgnoreList      /etc/opendkim/TrustedHosts
   InternalHosts   /etc/opendkim/TrustedHosts
   Socket          inet:8891@[127.0.0.1]

7. /etc/postfix/main.cf içinde mevcut Milter zincirini koruyarak OpenDKIM’i bağlayın. Bu örnekte signer hatasında geçici hata üretilir; accept seçimi imzasız gönderime izin verebilir:

   milter_default_action = tempfail
   milter_protocol = 6
   smtpd_milters = inet:127.0.0.1:8891
   non_smtpd_milters = inet:127.0.0.1:8891

8. Açık anahtar DNS’te yayımlandıktan sonra OpenDKIM yapılandırmasını ayrıştırma kontrolünden geçirin. postfix check dosya/dizin sahipliği ve izinlerini denetler, eksik dizinleri oluşturabilir; kapsamlı sözdizimi veya teslimat testi değildir. Kontroller başarılıysa servisleri yeniden başlatıp gerçek mesajları doğrulayın:

   opendkim -n -x /etc/opendkim.conf &&
   postfix check &&
   systemctl restart opendkim &&
   systemctl restart postfix

Bu iskeletin çalışması; anahtar dosyasına erişim, signer’ın gerçekten dinlediği soket, Milter zinciri ve gönderim kaynağına bağlıdır. Güvenilir yerel süreçler bu alan adıyla imzalı posta üretebileceğinden sunucu kullanıcılarını sınırlandırın. Uzak SMTP istemcileri için kimlik doğrulama ve imzalama yetkisi ayrıca tasarlanır. Aşağıdaki DNS yayını tamamlandıktan sonra hem yerel uygulama yolunu hem kullanılan SMTP yolunu alıcıda test edin.

3) DKIM genel anahtarını DNS’e ekleme

Anahtar üretimi, seçilen dizinde default.private ve default.txt dosyaları oluşturur. DNS için yalnızca default.txt içindeki genel anahtar kullanılır; private dosyası sunucuda kalır. Aşağıdaki kısaltılmış p= değeri geçerli bir anahtar değildir ve doğrudan yayımlanmamalıdır:

default._domainkey IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFA..." ) ; ----- DKIM key default for example.com

DNS panelinizde yeni bir TXT kaydı ekleyin:

• Ad: default._domainkey veya panelin beklediği tam ad. Son kayıt adı default._domainkey.example.com olmalıdır.
• Tür: TXT; bütün anahtar parçaları tek kaynak kaydına aittir.
• Değer: "v=DKIM1; k=rsa; p=..." örneğinin yerine oluşturulan dosyanın bütün TXT metnini kullanın; üç noktayı kopyalamayın.

Zone-file biçimindeki bir TXT kaydı birden çok tırnaklı parçadan oluşabilir. Bu parçaların tamamı ek boşluk katılmadan birleşir; yalnızca ilk parçayı kopyalamak anahtarı keser. DNS paneline ad, IN TXT, parantezler veya kapanıştan sonraki açıklama yorumu değil, panelin istediği TXT değeri girilir. Değer içindeki noktalı virgüller DKIM etiket ayırıcılarıdır ve korunmalıdır.

4) DMARC kaydını DNS’te eklemek

DMARC politikası DNS’te yayımlanır; değerlendirme alıcıda yapılır, raporları işlemek ise ayrı bir görevdir. cPanel’deki örnekle aynı şekilde önce mevcut kaydı arayın ve tek politikayı düzenleyin. İzleme örneği:

Ad (Name): _dmarc
Tür (Type): TXT
Kayıt (Record): "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Rapor adresinin gerçekten rapor kabul ettiğini doğrulayın. RUA verileri her mesajı veya her alıcıyı kapsamaz; sunucu loglarıyla birlikte meşru kaynakları ve hizalama sorunlarını inceleyin. Farklı bir organizasyon alan adındaki rapor kutusu kullanılıyorsa o tarafın dış raporlama DNS yetkilendirmesi de gerekir. Bu verilerle şunları araştırabilirsiniz:

• Yanlış yapılandırılmış script veya uygulamaları
• Yetkisiz IP’lerden yapılan denemeleri
• Alan adınızı taklit eden phishing saldırılarını

Raporlar tek başına saldırıyı temizlemez; yapılandırma hatası ile kötüye kullanım farklı müdahale ister. Politika değişikliğini yalnızca yeterli kapsama sahip gözlemden sonra değerlendirin. Genel amaçlı ve posta listelerine mesaj gönderen kullanıcıları olan bir domain için reject varsayılan hedef değildir; geçerli DKIM ve yönlendirme davranışı özellikle önemlidir.

5) Reverse DNS (PTR) ve hostname kontrolü

PTR, SPF/DKIM/DMARC’tan ayrı bir gönderim koşuludur. Örneğin Gmail, göndericiler için geçerli ileri ve ters DNS ile TLS ister. Kontrol, web sunucusunun varsayılan IP’sinde değil, mesajın gerçekten çıktığı IPv4 veya IPv6 adresinde yapılmalıdır.

• Gerçek çıkış IP’sinin PTR kaydı mail.example.com gibi posta sunucusu adına dönmelidir.
• Bu adın A veya AAAA kaydı kullanılan adres ailesinde aynı çıkış IP’sine dönmelidir.
• Postfix’in giden HELO/EHLO adı genellikle myhostname üzerinden gelir; özel smtp_helo_name ayarı veya relay kullanımı varsa gerçek gönderim yolunu inceleyin.

PTR kaydı, IP’nin ters DNS yetkisini yöneten kuruluş tarafından değiştirilir; sıradan domain TXT paneline PTR eklemek yeterli olmaz. Sağlayıcıdan ilgili IP için düzenleme yolunu doğrulayın. IPv6 ile e-posta teslimi rehberimiz, kullanılan IPv6 çıkışının ayrı PTR, HELO ve SPF kontrolünü ele alır.

6) Log ve test tarafı

VPS üzerinde sorun ayıklarken en büyük yardımcınız log dosyalarıdır:

• Syslog yapılandırmasına bağlı yaygın dosyalar: Debian/Ubuntu’da /var/log/mail.log, RHEL ailesinde /var/log/maillog.
• Bu dosyalar yoksa servis günlüğünü ve etkin logging yapılandırmasını inceleyin; bütün dağıtımlar aynı dosyayı oluşturmaz.

OpenDKIM’de anahtar/soket ve imzalama hatalarını, Postfix’te kuyruk kimliği ve karşı sunucunun yanıtını birlikte izleyin. status=sent, bir sonraki sunucunun mesajı kabul ettiğini gösterebilir; alıcının gelen kutusuna yerleştiğini kanıtlamaz. Testte:

• Kontrol ettiğiniz test adreslerine her gerçek gönderim yolundan mesaj iletin.
• Alıcının güvenilir doğrulama sonuçlarında spf=pass, dkim=pass ve dmarc=pass değerleriyle bunların alan adı hizalamasını inceleyin.
• Toplu raporları, gecikmeleri, bounce nedenlerini ve meşru yönlendirmeleri izleyin; bir başarılı test bütün gönderenleri temsil etmez.

Yaygın Hatalar, İnce Noktalar ve İyi Uygulamalar

E-posta yönlendirme SPF/DMARC’ı neden bozar?

En klasik sorunlardan biri şudur: Alan adınız için SPF/DMARC kurarsınız, kendi gönderdiğiniz maillerde sorun yoktur; ama bir kullanıcı, adresini başka bir posta kutusuna forward ediyordur ve o adrese giden mailler SPF/DMARC hatasıyla reddedilir.

Yönlendirme, özgün zarf gönderenini koruyup farklı bir IP’den çıkarsa SPF başarısız olabilir. İçerik ve imzalı başlıklar korunursa hizalı DKIM sayesinde DMARC yine geçebilir. SRS zarf gönderenini değiştirir; özgün görünür From: hizalamasını tek başına düzeltmez. ARC ara sunucuların doğrulama değerlendirmelerini taşır, fakat alıcının bu zincire güvenmesini veya postayı kabul etmesini garanti etmez. Ayrıntılar için e-posta yönlendirmede SPF/DMARC neden kırılıyor rehberimizi inceleyin.

SPF lookup sınırına takılmak

SPF’te DNS erişimi gerektiren include, a, mx, ptr, exists ve redirect terimleri, iç içe değerlendirmeler dahil toplam 10 sınırına tabidir. Bu, bütün DNS paketlerinin basit sayımı değildir; ip4, ip6 ve all bu sınıra girmez. Sınır aşımı permerror üretir; sonuç ne normal fail ne de kaydın hiç bulunmamasıyla aynıdır.

Bu noktada yapmanız gerekenler:

• Artık göndermeyen servisleri ve gereksiz yetkileri envanterle karşılaştırarak kaldırın.
• Aktif servislerin gerçek zarf domainleri için hangi include: girdilerinin gerekli olduğunu doğrulayın.
• Flattening uygulanacaksa sağlayıcının IP değişimlerini izleyen güncelleme ve test sürecini kurun; bir defalık IP kopyası kalıcı çözüm değildir.

Bu konuyu pratik örneklerle SPF flattening yazımızda detaylı ele aldık.

DMARC Politikasını IP İtibarından Ayırmak

Yeni IP’nin itibarı ile DMARC hizalaması farklı konulardır. IP değişikliği SPF yetkisi ve PTR güncellemesi gerektirebilir, fakat yalnızca IP yeni diye DMARC politikasını gevşetmek gerekmez. Asıl risk, meşru kaynakları ve dolaylı gönderim yollarını incelemeden sert politika yayımlamaktır. Geçerli DKIM imzası, forwarding sırasında SPF’in bozulabildiği durumlarda özellikle değerlidir.

İyi pratik şudur:

1. Her meşru gönderici için SPF/DKIM yapılandırmasını ve görünür From: hizalamasını doğrulayın.
2. Yeni veya değişen politikada rapor kapsamını ve kullanıcıların posta listesi/yönlendirme kullanımını değerlendirin.
3. İtibar, şikâyet oranı ve blok listesi sorunlarını DMARC’tan ayrı takip edin; IP ısınması bir kimlik doğrulama mekanizması değildir.
4. Politikayı uygun kullanım modeline göre seçin. Reject kullanan domainler geçerli DKIM uygulamalıdır; genel amaçlı posta listesi kullanıcıları olan domainlerde reject önerilmez.

IP ısınması ve kara listelerden çıkma süreçleri için e-posta itibarını kurtarma rehberimizde gerçekçi bir yol haritası paylaştık.

SPF, DKIM, DMARC ve rDNS’i birlikte düşünmek

Alıcı gereksinimleri aynı değildir: Gmail’in tüm gönderenler için SPF veya DKIM şartı, toplu göndericiler için SPF+DKIM+DMARC şartından farklıdır. İzinli test ve işletim kontrolünde aşağıdaki başlıkları ayrı değerlendirin:

• SPF: Gerçek zarf kimliğini ve çıkışları yetkilendirmeli; ikinci politika veya lookup hatası bulunmamalı.
• DKIM: Gerçek gönderim yollarında doğru d=/s= ve DNS anahtarıyla geçerli imza üretmeli.
• DMARC: En az bir başarılı, hizalı sonuçla geçmeli; politika ve rapor adresi bilinçli seçilmeli.
• rDNS/TLS: Gerçek çıkış IP’sinin ileri/ters DNS’i ve posta taşıma güvenliği ayrıca doğrulanmalı.

Bunları uçtan uca görmek isterseniz, SPF, DKIM, DMARC ve rDNS ile teslim edilebilirliği yükseltme makalemizde farklı senaryolar üzerinden geçtik.

Paylaşımlı E-Posta, SMTP Relay veya VPS Seçimi

E-posta doğrulama tarafı netleştikten sonra, sıra şu soruya geliyor: “Bu sistemi nerede çalıştırayım?”

• Düşük hacimli kurumsal posta: Yönetilen posta veya uygun hosting e-posta hizmetinin kota, gönderim sınırı ve doğrulama desteğini kontrol edin.
• Yüksek hacimli uygulama postası: Bir SMTP relay/işlemsel e-posta hizmeti, doğrudan VPS çıkışından daha uygun olabilir; maliyet, veri işleme ve gönderen kimliği desteğini karşılaştırın.
• Özel MTA gereksinimi: VPS veya dedicated sunucu esneklik sağlar, ancak güvenlik, kuyruk, yedekleme ve itibar sorumluluğunu da getirir. Daha büyük donanım tek başına teslimat veya kesintisizlik sağlamaz.

VPS tarafında kaynak planlaması, IP seçimi ve güvenlik ayarlarıyla ilgili daha geniş bir bakış açısı için VPS hosting nedir ve avantajları ile VPS sunucu güvenliği rehberlerimize göz atabilirsiniz.

Özet ve Sonraki Adımlar

Özel alan adınızla kurumsal e‑posta kullanmak, artık sadece MX kaydı eklemekten ibaret değil. Sağlam bir e‑posta kimlik doğrulaması için:

• SPF: Zarf/HELO kimliği için gönderici IP yetkisini ilan eder.
• DKIM: Seçili başlıklar ve gövdeyi imzalar; signer ile DNS genel anahtarı eşleşmelidir.
• DMARC: Görünür From: ile hizalanan başarılı SPF veya DKIM sonucunu değerlendirir; başarısızlık politikasını ve rapor isteğini bildirir.

cPanel arayüzü kayıt yönetimini kolaylaştırır; dış DNS yayını ve gerçek imzalama ayrıca doğrulanır. VPS örneğinde ise Milter, anahtar erişimi ve güvenilir gönderim yolu birlikte çalışmalıdır. Doğru kimlik doğrulama taklidi değerlendirmeye yardımcı olur, fakat içerik güvenliği, kullanıcı kimliği veya gelen kutusuna teslimat garantisi değildir.

Sonraki adım olarak şunları yapmanızı öneririm:

1. Mevcut kayıtları, gönderim yollarını ve yetkili DNS’i kaydedin.
2. Eksikleri giderirken geçerli anahtarları, diğer göndericileri ve mevcut Milter zincirini koruyun.
3. İzinli test mesajlarında alıcının doğrulama sonuçlarını ve alan adı hizalamasını kontrol edin.
4. Rapor kapsamı ve kullanıcıların dolaylı gönderim ihtiyacına göre politikayı değerlendirin; yüzdeyle veya yalnızca takvimle otomatik sıkılaştırmayın.

Sunucu veya IP geçişinde eski DNS yanıtları, kuyruktaki postalar ve önceki DKIM selector’ları da dikkate alınmalıdır. E-posta altyapısını taşırken kesinti yaşamamak rehberimiz bunun planlanmasına yardımcı olur; başlıktaki kesintisizlik hedefi bir garanti değildir. Hosting, VPS veya dedicated sunucu seçerken gerçek posta hizmetinin kapsamını, sorumlularını ve doğrulama desteğini ayrıca netleştirin.