Cel mai corect mod de a face acest lucru în zilele noastre este să creați un cont pe serviciul de corespondență adecvat, care este complet configurat pentru a servi exemplu.com
. (Desigur, acesta ar putea fi propriul tău server, asta nu contează.) Apoi, pe gazda ta nulă, configurați serverul de e-mail doar ca o gazdă inteligentă, cu autentificare SASL.
Deși este perfect posibil să configurați Postfix astfel (există o mulțime de manuale, inclusiv al lui Postfix), cred că Postfix este exagerat pentru o astfel de utilizare. Luați în considerare utilizarea nullmailer
, care este potrivit exact pentru sistemele care nu fac nimic cu e-mailul, cu excepția unor notificări de sistem.
Dacă acest lucru nu este posibil, configurați DNS astfel:
exemplu.com
Înregistrarea MX indică serviciul său de corespondență adecvat. Nu are nimic de-a face cu subdomeniile.
nullhost.example.com. MX 10 .
, adică arată spre nicăieri. Aceasta este o indicație explicită pentru care nu intenționați să primiți niciun mesaj [email protected]
. Acest lucru nu este necesar dacă protejați serviciul smtpd al gazdei nul de conexiuni externe (firewall tcp/25
, ascultă localhost:25
numai etc.); cu toate acestea, explicit este întotdeauna mai bine decât implicit.
- această gazdă nulă va trimite e-mail care setează
exemplu.com
ca domeniu de expeditor, deci e-mailul trebuie să respecte setările DMARC pentru acel domeniu. În caz contrar, receptorii care se comportă corect își vor renunța e-mailurile.
Acest ultim punct, DMARC, ar putea complica lucrurile considerabil. Dacă este setat în siguranță, înseamnă că înregistrarea arată ca _dmarc.example.com. TXT "v=DMARC1; p=resping; pct=100; ..."
, va trebui să configurați semnarea SPF și DKIM pe gazda nulă. SPF este ușor, trebuie doar să adăugați „a:nullhost.example.com” în înregistrarea SPF TXT. DKIM este o provocare, va trebui să creați o pereche de chei DKIM suplimentară, să alegeți un selector (nullhost
probabil va face), instalați perechea publică în DNS ca nullhost._domainkey.example.com. TXT „... date cheie...”
. Apoi configurați singning cu cheia privată corespunzătoare direct pe gazda nulă (și utilizați selectorul ales), aș folosi opendkim pentru asta. Am menționat că folosirea smart host este metoda preferată?
Și întrebările tale.
- Nu ești serverul (ai spus că acest sistem nu ar trebui să primească niciun e-mail). Deci nu aveți nevoie de niciun certificat TLS Server. Puteți configura lucrurile folosind certificatul client TLS, astfel încât atunci când vă conectați la gazda inteligentă sau la alte servere prin TLS, îl veți putea prezenta. Dar de ce ai vrea să faci asta?
- Recordul „apex”.
@ MX
, a.k.a. exemplu.com. MX
, trebuie direcționat către example.com mail eXchanger (sistemul care primește e-mail pentru [email protected]
). Nu are nimic de-a face cu e-mailul pentru niciun subdomeniu. Fiecare subdomeniu este un domeniu de e-mail în sine.
- Modul în care configurați rescrierea adreselor depinde de dvs. Singurul lucru pe care lumea exterioară îl vede este rezultatul final. Deci, de ce să te deranjezi să o faci în doi pași?