Muntar un servidor de correu amb Postfix i DKIM a Debian 12

Aixecar un servidor de correu que funcioni no és difícil. Aconseguir que els correus arribin a destí sense acabar en spam, ho és una mica més. Muntar Postfix a Debian 12, configurar-ho bé i afegir DKIM pot semblar rutinari, però hi ha prou decisions subtils i errors tontos com perquè valgui la pena repassar això amb perspectiva pràctica.

No comencis sense tenir clar el domini i el DNS sota control

El primer que comprovo abans d’instal·lar res és si tinc control complet del DNS del domini. No accés limitat a un panell amb registres capats: control real. Si no pots afegir registres TXT lliurement o configurar registres de tipus CAA, el millor és deixar-ho estar aquí.

DKIM, SPF, DMARC i fins i tot el baner de l’EHLO necessiten control total del DNS per a què el servidor tingui una mínima reputació. Pots tenir el millor Postfix del món, però si no pots signar el correu i publicar-lo correctament, no passaràs el filtre de spam de Gmail.

En aquest punt també reviso si hi ha altres serveis enviant correu amb el mateix domini (per exemple, un CRM o una newsletter externa). Perquè si algú ha ficat un SPF amb -all que no inclou aquest servidor, o un DKIM selector compartit mal configurat, l’ arrossegaràs tu quan comencin els rebuigs.

La instal·lació base

No vaig a enrotllar-me amb l’apt install postfix. Només una cosa: si tries “lloc d’Internet” durant el dpkg-reconfigure, vas bé. Però després revisa-ho tot. Perquè la configuració per defecte està pensada per a un servidor que es creu el centre de l’univers. I tu no vols això. Tu vols que enviï correus només per al teu domini, i que no es posi a acceptar coses per a localhost.localdomain ni per example.com perquè algú es va deixar això en un config vell.

Coses que reviso immediatament en /etc/postfix/main.cf:

myhostname = mail.elmeudomini.com

mydomain = elmeudomini.com

myorigin = $mydomain

mydestination = $myhostname, localhost.$mydomain, localhost

inet_interfaces = all

inet_protocols = all

I això és clau:

smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Si t’oblides d’aquesta última línia, el teu servidor es torna un relay obert. I creu-me, te’n assabentaràs perquè d’un dia per l’altre estaràs repartint amor i pastilles blaves a mig internet i Spamhaus et posarà a la llista negra com si haguessis cremat una església.

El hostname importa més del que sembla

Un error recurrent és deixar el hostname per defecte del VPS o el que ve del proveïdor. Encara que el correu tingui From: usuari@elmeudomini.com, si l’EHLO respon com a srv123456.nube-barata.net, això es registra als headers i pot afectar la puntuació.

Sempre configuro el hostname amb quelcom coherent, com mail.elmeudomini.com, i faig que resolgui a la IP pública des de la qual s’enviarà el correu. El mateix per al PTR. Si no pots posar el revers de la IP, i aquesta IP no té historial previ acceptable, cal plantejar-se fer servir un relé sortint.

Això no s’arregla amb SPF ni amb DKIM. El PTR continua sent un dels filtres més primitius però efectius que fan servir alguns destinataris, i si no quadra amb el hostname, el marquen com a sospitós.

Postfix: compte amb la configuració per defecte

La temptació quan configures Postfix és seguir el patró mínim viable: myhostname, mydestination, relayhost, etc. Però si has d’ enviar directament a Internet, cal tenir una mica més de cura amb paràmetres com:

• smtpd_helo_required = yes
• disable_vrfy_command = yes
• smtpd_tls_security_level = may (o encrypt, si pots forçar STARTTLS)
• smtp_tls_loglevel = 1 (per tenir visibilitat)

No tots aquests afecten l’enviament directament, però contribueixen a que el servidor es comporti com s’espera. M’ha tocat analitzar casos on un servidor estava perfectament muntat però no responia com s’esperava a l’HELO, i això era suficient per a què alguns filtres el descartessin.

També reviso sempre si Postfix està escoltant en IPv6. Hi ha llocs on això ajuda a la reputació (alguns filtres ho tenen en compte), però si la teva configuració IPv6 no és estable, és millor no anunciar-ho.

OpenDKIM: quan ho configures bé però no signa res

Un dels problemes més frustrants és quan tens OpenDKIM instal·lat, tot sembla correcte, però els missatges surten sense firma DKIM.

Les dues causes més comunes que m’he trobat són:

1. El socket d’OpenDKIM no és accessible per Postfix.
   Per defecte, OpenDKIM crea un socket en /var/run/opendkim/opendkim.sock, però Postfix (chroot mitjançant) no pot accedir ací. Solució: moure el socket a /var/spool/postfix/opendkim/opendkim.sock, assegurar-se que existeix el directori, i ajustar permisos. El grup de Postfix ha de tenir accés al socket, i moltes vegades això implica afegir postfix al grup d’opendkim.
2. No hi ha coincidència entre el domini del remitent i el selector configurat.
   Si signes només amb elmeudomini.com, però el remitent és noreply@subdomini. elmeudomini..com, i no has configurat SubDomains yes, se’n va sense signar. Aquest tipus de coses no es veuen en els logs de Postfix, cal mirar el log d’OpenDKIM directament.

Per a diagnosticar ràpid si els correus s’estan signant, el primer que miro és el header DKIM-Signature:. Si no apareix, no cal mirar més. Si apareix però dona error en verificar, el problema està gairebé sempre en el DNS o en els paràmetres de canonicalització.

SPF i DMARC

Configurar SPF sembla fàcil: un registre TXT i ja. Però la gent el configura amb -all sense entendre el que implica. Jo prefereixo ~all  a no ser que l’entorn estigui molt ben controlat. Perquè si en dos mesos algú afegeix un nou sistema que envia correus i s’oblida d’ajustar SPF, comencen els rebuigs silenciosos.

Amb DMARC, el mateix. Es posa un registre bàsic:

_dmarc.elmeudomini.com. TXT “v=DMARC1; p=none; rua=mailto:dmarc@elmeudomini.com”

Però ningú es mira els informes. I quan finalment algú els obre, és un XML il·legible.

El que faig és redirigir aquests informes a una direcció gestionada per un parser automàtic (com Postmark, DMARCian o algun de similar). No és qüestió de gastar en eines cares, però sí que algú estigui mirant si hi ha fonts de correu no autoritzades. No fer-ho és com tenir càmeres de seguretat sense pantalla.

Mail-tester i proves reals

Abans d’obrir el port 25 al món, provo sempre amb mail-tester.com o envia un correu a Gmail i reviso els headers.

No tant per la nota, sinó per la secció “Authentication-Results”. Aquí veig si SPF, DKIM i DMARC estan passant, i sobretot si les firmes DKIM són vàlides.

Si hi ha algun “neutral” o “none” on hi hauria d’haver un “pass”, ja sé que alguna cosa no quadra. De vegades és qüestió de noms, de vegades de canonicalització, o simplement de caché de DNS al destí.

Una altra prova útil és enviar des del compte configurat en el servidor a comptes Outlook, Yahoo, Gmail i ProtonMail. Cadascú tracta la reputació de forma diferent, i el mateix missatge pot acabar en inbox o en spam segons detalls mínims.

Quan no muntar el teu propi servidor

Hi ha vegades en què l’esforç no compensa. Si el domini és nou, no hi ha historial, i el volum de correu és baix, cal valorar fer servir un relé extern com Mailgun o Amazon SES. No perquè Postfix no funcioni, sinó perquè la reputació IP és difícil de construir des de zero.

He vist dominis nous amb tots els registres perfectes, i tot i així, Gmail els fica en spam. Per què? Perquè no hi ha trànsit previ, no hi ha engagement, i la IP des de la qual s’envia és compartida amb altres dominis que sí que tenen historial, però dolent.

Si el servidor ha d’ enviar poques notificacions o correus transaccionals, delegar l’ enviament és més pragmàtic que barallar-se amb polítiques d’ entrega.

Coses que ja haurien d’estar automatitzades i no ho estan

Finalment, hi ha coses que encara requereixen intervenció manual i que acaben generant errors tontos:

1. La renovació de claus DKIM. Molts deixen la mateixa clau RSA durant anys. Si vols rotar-la, has de canviar selector i registres, i això gairebé mai s’automatitza.
2. La comprovació de llistes negres. És fàcil que la IP caigui en alguna RBL sense que t’assabentis. Jo tinc un petit script que revisa la IP contra algunes llistes públiques i m’avisa si apareix.
3. El manteniment del servidor DNS. Si fas servir BIND o similar en local, qualsevol error a la zona pot trencar el correu sense que Postfix s’assabenti. Tenir checks periòdics amb named-checkzone i dig programats no és excessiu.

Has de muntar Postfix amb DKIM a Debian 12? No hi ha res estrany ni nou, però continua sent un procés que es trenca per detalls mínims. La diferència està en els ajustos que no es veuen: com es resol el nom del servidor, com s’accedeix al socket, què headers s’exposen, o si el correu dona la impressió de venir d’una font legítima.

No és tant qüestió de seguir passes, sinó d’anticipar-se als errors i tallar-los de socarrel.