Zimbra’da Domain Ekleme ve Mail Routing Yapılandırması

Zimbra kurulumunu bitirip ilk kez admin paneline girdiğinizde, sizi bekleyen en kritik adımlardan biri domain yapılandırmasıdır. Yanlış yapılandırılmış bir domain, mail akışını tamamen bozabilir; sahte bounce mesajları, kayıp mailler ve kullanıcı şikayetleri kaçınılmaz olur. Bu yazıda, Zimbra’da domain ekleme sürecini ve mail routing yapılandırmasını hem arayüz hem de komut satırı üzerinden ele alacağız. Gerçek dünya senaryolarıyla desteklenmiş, “bu hatayı ben de yaşadım” cinsinden pratik bilgiler bulacaksınız.

Zimbra Domain Mimarisini Anlamak

Zimbra’da “domain” kavramı, e-posta adreslerinin @ işaretinden sonraki kısmını ifade eder. Tek bir Zimbra sunucusunda onlarca farklı domain barındırabilirsiniz; bu yapıya multi-tenant denir. Her domain kendi kullanıcılarına, kotalarına, politikalarına ve posta yönlendirme kurallarına sahip olabilir.

Zimbra’nın mail routing mekanizması birkaç katmandan oluşur:

• MTA katmanı: Postfix tabanlıdır, gelen ve giden mailler burada işlenir
• LMTP katmanı: Postfix’ten mailstore’a teslimat bu protokol üzerinden yapılır
• Proxy katmanı: Nginx tabanlı proxy, istemci bağlantılarını yönetir

Bu katmanları kafanızda oturtmadan domain ekleme yapmak, ilerleyen süreçte neden bazı şeylerin çalışmadığını anlamamanıza yol açar. Özellikle routing sorunlarında hangi katmanda sorun olduğunu bilmek, debug sürecini yarı yarıya kısaltır.

Admin Paneli Üzerinden Domain Ekleme

Zimbra Admin Console’a giriş yapın. Genellikle https://sunucuadiniz:7071 adresinden erişilir. Sol menüde Configure > Domains yolunu izleyin.

“New Domain” butonuna tıkladığınızda karşınıza bir sihirbaz çıkar. Burada dikkat etmeniz gereken noktalar:

• Domain Name: Tam domain adını girin, alt domain dahil. Örneğin sirket.com.tr şeklinde.
• Default Class of Service (CoS): Yeni kullanıcıların varsayılan kotasını ve özelliklerini belirler. Önceden bir CoS oluşturmuşsanız seçin, yoksa default’u bırakın.
• Zimlets: Domain bazlı zimlet kısıtlamaları burada yapılır.

Sihirbazı tamamladıktan sonra domain listesinde yeni domain’i göreceksiniz. Ama bu kadarı yeterli değil; birkaç adım daha var.

Komut Satırından Domain Ekleme

Arayüz bazen yanıltıcı olabilir, özellikle birden fazla domain ekleyeceğiniz toplu işlemlerde komut satırı çok daha verimli. Zimbra’da tüm yönetim işlemleri zmprov aracıyla yapılır.

Önce zimbra kullanıcısına geçiş yapın:

su - zimbra

Yeni bir domain eklemek için:

zmprov createDomain yenidomain.com.tr

Domain’in oluştuğunu doğrulamak için:

zmprov getDomain yenidomain.com.tr

Bu komut, domain hakkında onlarca satır bilgi döker. İlk kurulumda bunların büyük çoğunluğu default değerlerde gelir. Dikkat etmeniz gereken birkaç parametre var:

zimbraDomainStatus: active olmalı. maintenance veya suspended ise mail kabul edilmez. zimbraMailCatchAllAddress: Tanımsız kullanıcılara gelen mailleri yakalamak için kullanılır. zimbraVirtualHostname: Web arayüzü için virtual host tanımı.

Birden fazla domain ekleyecekseniz döngüyle yapabilirsiniz:

for domain in domain1.com domain2.com.tr domain3.net; do
    zmprov createDomain $domain
    echo "$domain eklendi"
done

DNS Yapılandırması: Gözden Kaçmaması Gerekenler

Domain’i Zimbra’ya eklemek yeterli değil. DNS tarafında da doğru kayıtlar olmazsa mailler ne gelir ne gider. Birçok sysadmin bu adımı aceleye getirir ve sonra saatlerce debug yapar.

Minimum olarak şu DNS kayıtları olmalı:

• MX kaydı: yenidomain.com.tr için MX kaydı, Zimbra sunucunuzun IP’sine işaret etmeli
• A kaydı: mail.yenidomain.com.tr gibi bir hostname, sunucu IP’sine çözümlenmeli
• SPF kaydı: v=spf1 mx a ip4:SUNUCU_IP ~all şeklinde TXT kaydı
• PTR kaydı: Sunucunun IP’si için ters DNS kaydı, ISP veya hosting sağlayıcınızdan talep edilmeli

SPF kaydını ekledikten sonra doğrulamak için:

dig TXT yenidomain.com.tr +short

MX kaydını kontrol etmek için:

dig MX yenidomain.com.tr

DNS propagasyonunun tamamlanması bazen 24-48 saat sürebilir, bunu müşterinize veya yöneticinize önceden bildirin. TTL değerini düşürmeniz propagasyonu hızlandırır ama bunu DNS değişikliğinden en az birkaç saat önce yapmanız gerekir.

Mail Routing Yapılandırması

Zimbra’da mail routing’in birkaç farklı senaryosu var. Bunları ayrı ayrı ele alalım.

Senaryo 1: Tüm Mailler Doğrudan Zimbra’ya Geliyor

En basit senaryo bu. MX kaydı Zimbra’yı gösteriyor, Zimbra da maili doğrudan mailbox’a teslim ediyor. Ekstra yapılandırma gerekmez. Ama yine de Postfix yapılandırmasının doğru olduğunu kontrol edin:

postconf -n | grep mydestination
postconf -n | grep relay

mydestination parametresinde localhost dışında bir şey görüyorsanız dikkatli olun. Zimbra kendi domain yönetimini Postfix’e bırakmaz, bu yüzden buraya domain adı eklemek sorun çıkarabilir.

Senaryo 2: Relay Host Üzerinden Giden Mail

Birçok kurumda, outbound mailler doğrudan gönderilmez; bir smart host veya relay üzerinden geçer. Özellikle ISP’lerin port 25’i bloke ettiği durumlarda veya merkezi bir spam filtresi kullanılıyorsa bu senaryo geçerlidir.

Relay host tanımlamak için:

zmprov ms `zmhostname` zimbraSmtpHostname relay.sirketiniz.com
zmprov ms `zmhostname` zimbraSmtpPort 25

Eğer relay’e kimlik doğrulama gerekiyorsa Postfix tarafında da yapılandırma gerekir:

vi /opt/zimbra/conf/postfix_header_checks

Relay kimlik bilgileri için sasl_passwd dosyasını düzenlemeniz ve postmap ile derleméniz gerekir. Bu dosyayı doğrudan düzenlemeyin; Zimbra her restart’ta üzerine yazabilir. Bunun yerine localconfig kullanın:

zmlocalconfig -e postfix_relayhost="[relay.sirketiniz.com]:587"

Senaryo 3: Harici Domain için Mail Forward

Bazen bir domain’in maillerini Zimbra’da değil, başka bir mail sunucusunda tutmak istersiniz ama MX yine de Zimbra’yı gösteriyor. Bu durumda Zimbra’nın gelen maili alıp başka bir sunucuya forward etmesi gerekir.

Bu senaryo genellikle geçiş dönemlerinde (migration) veya hybrid yapılarda karşıma çıktı. Örneğin eski Exchange sunucusunu hemen kapatamıyorsunuz, ama MX’i çevirmek durumundasınız.

Domain bazında relay tanımlamak için:

zmprov modifyDomain eskidomain.com.tr zimbraMailTransport smtp:[exchange.eskidomain.com.tr]:25

Bu komut, eskidomain.com.tr için gelen her maili, Zimbra üzerinde işlemeden doğrudan belirtilen Exchange sunucusuna yönlendirir.

Yapılandırmayı doğrulamak için:

zmprov getDomain eskidomain.com.tr | grep zimbraMailTransport

Senaryo 4: Catch-All Adresi Tanımlama

Domain’de olmayan bir kullanıcıya mail geldiğinde, normalde Zimbra bir “User does not exist” hatası döner ve mail bounce eder. Bazen bu istenmez; tüm bilinmeyen adreslere gelen mailler belirli bir posta kutusuna düşmeli.

Catch-all tanımlamak için önce hedef posta kutusunun var olduğundan emin olun, sonra:

zmprov modifyDomain yenidomain.com.tr zimbraMailCatchAllAddress [email protected]
zmprov modifyDomain yenidomain.com.tr zimbraMailCatchAllForwardingAddress [email protected]

Catch-all kullanırken dikkatli olun. Spam bombasına maruz kalabilirsiniz. Özellikle domain’iniz eskiyse, yüzlerce rastgele adrese gelen spam mailler info kutusunu dolduracaktır. Bu yüzden catch-all yerine alias kullanmayı tercih edin.

Alias Domain Yapılandırması

Bir domain’in başka bir domain’in alias’ı olmasını isteyebilirsiniz. Örneğin sirket.com ve sirket.com.tr adresleriniz var; her iki adrese gelen mailler aynı kullanıcıya ulaşmalı.

zmprov createAliasDomain sirket.com sirket.com.tr

Bu komut sirket.com‘u sirket.com.tr‘nin alias’ı olarak tanımlar. [email protected]‘a gelen mail, [email protected]‘ye düşer.

Alias domain tanımlandıktan sonra DNS’te de MX kaydını eklemeyi unutmayın. Yoksa alias domain için mail gelmez.

Mevcut alias domainleri listelemek için:

zmprov getAllDomains | xargs -I{} zmprov getDomain {} | grep -E "zimbraIsAliasDomain|zimbraDomainName"

Bu biraz ham bir çıktı verir ama iş görür.

Mail Queue Yönetimi ve Routing Doğrulama

Domain ekledikten ve routing’i yapılandırdıktan sonra, her şeyin çalışıp çalışmadığını test etmek kritik. Sadece “test maili attım geldi” deyip geçmeyin; queue’ya bakın, log’ları inceleyin.

Mail queue durumunu görmek için:

mailq | head -50

ya da daha detaylı:

/opt/zimbra/common/sbin/postqueue -p

Queue’da takılı mailler varsa nedenini görmek için:

/opt/zimbra/common/sbin/postqueue -p | grep -A 3 "^[A-F0-9]"

Belirli bir domain için mail akışını test etmek isterseniz, Zimbra içinden sendmail komutunu kullanabilirsiniz:

echo "Test mail body" | /opt/zimbra/common/sbin/sendmail -v [email protected]

Mail log’larını takip etmek için:

tail -f /var/log/zimbra.log | grep "yenidomain.com.tr"

Eğer mail teslim ediliyorsa log’da “status=sent” veya “status=deliverable” görürsünüz. “status=bounced” veya “status=deferred” görüyorsanız sorun var demektir.

Postfix Transport Map ile Gelişmiş Routing

Bazı senaryolarda, Zimbra arayüzünün sunduğu seçenekler yeterli gelmeyebilir. Postfix transport map kullanarak çok daha granüler routing yapabilirsiniz. Ama dikkat: Zimbra’nın yönettiği Postfix yapılandırmasını doğrudan düzenlemek, güncellemeler veya zcs-watchdog tarafından üzerine yazılabilir.

Bu yüzden özel transport kurallarını Zimbra’nın localconfig mekanizması üzerinden eklemeniz daha güvenli. Alternatif olarak, /opt/zimbra/conf/ altındaki transport dosyasını kullanabilirsiniz:

vi /opt/zimbra/conf/transport

Dosyaya ekleyeceğiniz format:

ozel-domain.com    smtp:[192.168.1.100]:25
diger-domain.net   smtp:[mail.diger-domain.net]:587

Dosyayı kaydettikten sonra map dosyasını oluşturun:

postmap /opt/zimbra/conf/transport

Postfix’e bu dosyayı kullanmasını söylemek için:

zmlocalconfig -e postfix_transport_maps="hash:/opt/zimbra/conf/transport"
postfix reload

Sonrasında değişikliklerin Postfix’e yansıdığını doğrulayın:

postconf transport_maps

Yaygın Sorunlar ve Çözümleri

Gerçek hayatta karşılaşılan ve zaman alan sorunların başında domain eklendikten sonra mail kabul edilmemesi gelir.

Sorun: Yeni domain’e mail gönderince “User does not exist” hatası alıyorsunuz ama kullanıcı var.

Bu durumda önce domain’in aktif olup olmadığını kontrol edin:

zmprov getDomain yenidomain.com.tr | grep zimbraDomainStatus

active değilse:

zmprov modifyDomain yenidomain.com.tr zimbraDomainStatus active

Sorun: Routing doğru ama mailler queue’da bekliyor, gönderilmiyor.

Queue’daki mesaj için detaylı hata görmek:

/opt/zimbra/common/sbin/postcat -q QUEUE_ID

QUEUE_ID’yi mailq çıktısından alırsınız. Genellikle TLS hatası, bağlantı reddi veya DNS çözümleme sorunu çıkar.

Sorun: Giden mailler spam olarak işaretleniyor.

Bu çoğunlukla DKIM yapılandırmasının eksik olduğu anlamına gelir. Domain ekledikten sonra DKIM key oluşturmayı unutanların sıkça karşılaştığı bir durum. Her domain için ayrıca DKIM yapılandırması gerekir:

zmdhputil genkeypair -a rsa -b 1024

Daha modern bir yaklaşım için 2048 bit kullanın:

zmprov generateDomainDKIMPublicKey yenidomain.com.tr

Oluşan public key’i DNS’te TXT kaydı olarak ekleyin. Zimbra size hazır DNS kaydını verir.

Domain Silme ve Temizlik

Bir domain’i sistemden kaldırmadan önce, o domain’e ait tüm hesapları silmeniz gerekir. Hesaplar varken domain silemezsiniz.

Domain altındaki hesapları listelemek:

zmprov -l getAllAccounts yenidomain.com.tr

Tüm hesapları silmek için:

zmprov -l getAllAccounts yenidomain.com.tr | while read account; do
    zmprov deleteAccount $account
    echo "$account silindi"
done

Sonra domain’i silin:

zmprov deleteDomain yenidomain.com.tr

Silme işleminden sonra Zimbra’yı yeniden başlatmanıza gerek yok ama cache’in temizlenmesi için bir süre bekleyin ya da:

zmprov flushCache domain

Sonuç

Zimbra’da domain ekleme ve mail routing yapılandırması, ilk bakışta basit görünen ama katmanları olan bir konu. DNS yapılandırması, Postfix routing, Zimbra domain özellikleri ve DKIM gibi bileşenlerin hepsinin uyumlu çalışması gerekiyor. Bir adımı atlamak, saatler süren debug seanslarına neden olabilir.

En güvenli yaklaşım şu: Domain eklemeden önce bir checklist hazırlayın. DNS kayıtları hazır mı, MX propagasyonu tamamlandı mı, DKIM key oluşturulacak mı, catch-all gerekli mi, routing özel mi yoksa standart mı? Bu soruların cevaplarını önceden netleştirirseniz, işlem çok daha pürüzsüz ilerler.

Komut satırı araçlarına alışın. zmprov, postconf, postqueue ve mailq günlük dostlarınız olmalı. Arayüz güzel görünür ama gerçek kontrolü komut satırı verir. Özellikle toplu işlemlerde ve otomasyon senaryolarında bunlar olmadan verimli çalışmak neredeyse imkansız.

Son olarak, yaptığınız her değişikliği belgeleyin. Hangi domain ne zaman eklendi, hangi routing kuralı neden yapılandırıldı, hangi özel Postfix parametresi neden değiştirildi. Bu belgeler, altı ay sonra gelen “neden bu böyle” sorusuna cevap verecek tek şey olacak.