DKIM: cum semnați emailurile corect și de ce trebuie să rotiți cheile la 6-12 luni

Pe scurt

DKIM (DomainKeys Identified Mail, RFC 6376) adaugă o semnătură criptografică pe fiecare email plecat, semnată cu o cheie privată deținută de MTA-ul vostru. Cheia publică e publicată în DNS sub un selector. Receiverul (Gmail, Outlook365) verifică semnătura și — dacă e validă și corespunde domeniului din From: — confirmă că emailul nu a fost modificat în tranzit și că vine de la o entitate autorizată.

În 2026, DKIM este o cerință de facto: Gmail și Yahoo impun din februarie 2024 ca toți expeditorii bulk (>5000 mesaje/zi către conturile lor) să aibă SPF + DKIM + DMARC funcțional — în caz contrar emailurile sunt respinse sau pun în spam. Pentru orice firmă cu newsletter, facturi automate sau notificări transactionale, DKIM corect e diferența între deliverability 95%+ și 60%.

Aspectul des ignorat: cheia DKIM nu e un set-and-forget. La fel ca orice cheie criptografică, trebuie rotită periodic. O cheie compromisă (server hackuit, backup expus, fost angajat cu acces) permite atacatorului să semneze emailuri legitime în numele vostru pentru luni de zile, până observați.

Atacuri concrete pe care le previne

Scenariu 1 — Tampering de conținut în tranzit

Atacator on-path (rețea ISP, datacentru) interceptează email cu factură atașată în PDF. Modifică IBAN-ul în PDF înainte ca emailul să ajungă la client. Fără DKIM, modificarea e nedetectabilă. Cu DKIM (semnătură pe Subject:, From:, Date: și hash al body-ului), orice modificare invalidează semnătura — receiver-ul respinge sau marchează ca suspect.

Scenariu 2 — Replay cu conținut alterat (DKIM key compromise)

Cheie DKIM 1024-bit a unei companii a fost spartă în 2012 (caz public Zachary Harris). Atacatorul a trimis email semnat valid către Google, pretinzând că e CEO-ul companiei. Cheile 1024-bit RSA sunt tehnic spargibile cu resurse cloud moderate (~75.000 USD în 2025) — minim 2048-bit este obligatoriu.

Scenariu 3 — Fost angajat cu acces la cheia privată

DevOps-ul concediat în 2024 a copiat /etc/postfix/dkim/private.key înainte să plece. Timp de 8 luni, până când noua echipă a rotit cheia (după acest articol), fostul angajat ar fi putut semna emailuri valide pentru orice destinatar — pretinzând că e CEO-ul, contabilitatea, etc. Rotația obligatorie la 6-12 luni limitează această fereastră.

Impact business

Aspect	Cheie 1024-bit, fără rotație	Cheie 2048-bit + rotație 6 luni
Cost compromise key (2026)	~75.000 USD (factorizare)	>10^60 ani (computațional infeasible)
Fereastră compromise post-leak	infinit	max 6 luni
Deliverability Gmail/Yahoo bulk	rejected (din 2024)	accepted
Audit DORA / NIS2	finding	acoperit
Cost rotație periodică	—	~1h/operație, 2x/an

Implementare — ghid pas-cu-pas

Pas 1 — Generați cheie DKIM 2048-bit (sau Ed25519)

Pentru OpenDKIM / Postfix:

# RSA 2048-bit (universal compatibil)
opendkim-genkey -b 2048 -d firma.ro -s 2026a -v

# Sau Ed25519 (modern, rapid, suportat din 2024 majoritar)
opendkim-genkey -t ed25519 -d firma.ro -s 2026a-ed -v

Output: două fișiere — 2026a.private (păstrați doar pe MTA, mod 0600, root) și 2026a.txt (TXT record DNS).

Nu folosiți 1024-bit. RFC 8301 marchează explicit 1024 ca slab. Pentru retro-compatibilitate cu MTA-uri vechi care nu suportă Ed25519, publicați ambii selectori (RSA 2048 + Ed25519) — receiver-ul alege.

Pas 2 — Publicați cheia publică în DNS

2026a._domainkey.firma.ro.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCA..."

Atenție la lungimea recordului TXT — peste 255 caractere trebuie spart pe segmente; majoritatea provider-ilor DNS gestionează automat dacă îl introduceți într-o singură linie în UI.

Verificare:

dig +short TXT 2026a._domainkey.firma.ro
opendkim-testkey -d firma.ro -s 2026a -k /etc/opendkim/keys/firma.ro/2026a.private -vvv

Pas 3 — Configurați MTA să semneze cu noul selector

Postfix + OpenDKIM (/etc/opendkim/key.table):

2026a._domainkey.firma.ro firma.ro:2026a:/etc/opendkim/keys/firma.ro/2026a.private

Reload OpenDKIM. Trimiteți email test către check-auth@verifier.port25.com — răspunsul automat confirmă semnătura validă.

Pas 4 — Procedura de rotație (la 6-12 luni)

Rotația se face fără downtime prin selector overlap:

1. T-30 zile: generați selector nou (2026b), publicați TXT-ul, dar nu activați semnarea încă.
2. T-0: switch MTA să semneze cu 2026b. Lăsați 2026a în DNS.
3. T+7 zile: dacă nu sunt probleme, ștergeți 2026a din DNS (revoke implicit).
4. T+8 zile: ștergeți cheia privată 2026a.private de pe MTA + backup-uri.

Nu ștergeți niciodată cheia veche imediat după rotație — emailurile semnate înainte de switch sunt încă în tranzit; receiverii pot încerca verificarea ulterioară.

Pas 5 — Automatizare + monitoring

Adăugați alertă (cron sau Zabbix) care vă atenționează la 5.5 luni de la generare:

# Verificați data creării cheii și avertizați la 5.5 luni
find /etc/opendkim/keys/ -name "*.private" -mtime +165 -exec echo "ROTIRE NECESARĂ: {}" \;

Logați semnăturile DKIM emise (Postfix header_checks sau Graylog) — la audit, demonstrează că semnarea a fost activă continuu.

Confuzii frecvente

“Selectorul implicit default e suficient.” — Periculos. La rotație nu puteți face overlap; sunteți forțați să acceptați downtime sau să folosiți doar 1 cheie permanent (anti-pattern). Folosiți selectori dataframe-style: 2026a, 2026b, etc.

“Ed25519 nu e suportat universal.” — Era adevărat în 2018. Din 2024, Gmail, Outlook365, Yahoo, ProtonMail toate verifică Ed25519. Rămân doar câteva MTA-uri legacy on-prem care nu — pentru ele păstrați RSA paralel.

“DKIM împiedică forwarding-ul.” — Parțial adevărat. Forwarding cu modificare (mailing list care adaugă footer) sparge semnătura. Soluție: ARC (Authenticated Received Chain, RFC 8617) sau republic-DKIM la mailing list. Forwarding curat (server-side, fără rewrite) păstrează semnătura intactă.

“Cheia privată în Git e ok dacă repo e privat.” — Categoric nu. Compromise repo Git = compromise cheie pentru luni. Cheia privată trăiește doar pe MTA, generată cu umask 077, fără backup necriptat.

Verificați acum

ARTEMIS verifică automat: prezența DKIM, dimensiunea cheii (avertizare <2048-bit), aliniere cu DMARC, expirare detectabilă, și 30+ alte verificări email-security.

---

🔗 Soluții complementare CAI Technology

• ARTEMIS — Scanare tehnică DKIM (toți selectorii observabili) + dimensiune cheie + alignment + integrare cu DMARC.
• Lexnomia — Evaluare compliance auditor-grade pentru NIS2 / GDPR / DORA cu rapoarte oficiale.
• BeLegal cu SandboxAI — Verificare gratuită compliance 5 minute.
• Auditope — Audit holistic web (SEO + AI search + GDPR + securitate).
• AriaUnited — Consultanță fonduri europene pentru proiecte de hardening criptografic.

---

Întrebări? tehnic@caitech.ro