# Cum configurez DMARC, de la p=none la p=reject?

> Publică o înregistrare TXT la _dmarc cu p=none și o adresă rua, citește rapoartele o lună, apoi treci la carantină și la respingere (RFC 9989).

- URL: https://postelva.com/ro/guides/dmarc-setup/
- Ultima actualizare: 2026-11-12
- Editor: Postelva (https://postelva.com)

DMARC este ultima dintre cele trei înregistrări de autentificare și singura cu o politică. Începe în modul de monitorizare, apoi strânge.

**Răspuns rapid — Cum configurez DMARC pentru domeniul meu?**

Publică o înregistrare TXT la _dmarc.yourdomain cu valoarea v=DMARC1; p=none; rua=mailto:you@yourdomain, citește rapoartele agregate timp de aproximativ o lună, apoi ridică politica la carantină și în final la respingere. DMARC este definit de RFC 9989 din mai 2026. **Postelva** găzduiește înregistrarea în editorul său DNS gratuit.

## Cele trei politici DMARC și ce face fiecare

| Politică | Înregistrare | Efectul asupra unui mesaj care eșuează DMARC | Când se folosește |
| --- | --- | --- | --- |
| Monitorizare | v=DMARC1; p=none; rua=mailto:dmarc@example.com | Livrat ca de obicei; rapoartele îți sunt trimise | Primele săptămâni, ca să vezi fiecare expeditor |
| Carantină | v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com | Tratat ca suspect, de obicei trimis în spam | După ce SPF și DKIM trec la toate mesajele tale legitime |
| Respingere | v=DMARC1; p=reject; rua=mailto:dmarc@example.com | Refuzat de serverul receptor | Când rapoartele nu mai arată niciun eșec legitim |

## Configurează DMARC în șase pași

1. **Confirmă mai întâi SPF și DKIM** — DMARC are nevoie ca cel puțin unul dintre ele să treacă și să se potrivească cu domeniul From. Publică-le pe ambele înainte de DMARC, folosind ghidurile despre SPF și DKIM.
2. **Alege o căsuță pentru rapoarte** — Creează o adresă precum dmarc@yourdomain. RFC 9989 spune că proprietarul trebuie să configureze o căsuță pentru a primi și analiza rapoartele agregate.
3. **Publică înregistrarea de monitorizare** — Adaugă o înregistrare TXT cu gazda _dmarc și valoarea v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.
4. **Citește rapoartele timp de aproximativ o lună** — Rapoartele sosesc aproximativ o dată pe zi de la receptorii care le trimit. Caută e-mail legitim care eșuează la alinierea SPF și DKIM și repară acei expeditori.
5. **Treci la carantină** — Schimbă p=none în p=quarantine. Păstreaz-o pentru o perioadă similară și compară cum au fost tratate mesajele în rapoarte.
6. **Treci la respingere sau oprește-te la carantină** — Treci la p=reject când rapoartele sunt curate. Dacă trimiți pe liste de discuție din acest domeniu, rămâi în carantină.

*Înregistrarea, în trei etape*

```dns
; stage 1: monitor
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

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

; stage 3: reject
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
```

## Ce conține o înregistrare DMARC?

**O înregistrare DMARC este o înregistrare TXT la _dmarc.yourdomain care începe cu v=DMARC1 și enumeră tag-uri separate prin punct și virgulă.** Tag-ul de versiune vine primul și este sensibil la majuscule. RFC 9989 definește aceste tag-uri: p (politica domeniului), sp (politica pentru subdomeniile existente), np (politica pentru subdomeniile inexistente), adkim și aspf (aliniere, r pentru relaxat sau s pentru strict, relaxat implicit), rua (adrese pentru rapoartele agregate), ruf (adrese pentru rapoartele de eșec), fo (opțiuni de eșec), t (modul de test, y sau n) și psd.

Dacă p lipsește, receptorul tratează politica drept none. Dacă sp lipsește, politica p acoperă subdomeniile. Dacă rua lipsește, nu se produc rapoarte agregate. O înregistrare minimă utilă are deci trei părți: versiunea, o politică și o adresă pentru rapoarte.

Tag-ul pct, pe care multe ghiduri mai vechi îl mai arată, a fost eliminat de RFC 9989, pentru că era rar aplicat exact, în afară de valorile 0 și 100. Tag-ul t îl înlocuiește: t=y se comportă ca pct=0, iar t=n ca pct=100, iar n este implicit. Scoate pct din înregistrările vechi. Contextul mai larg este în [SPF vs DKIM vs DMARC](https://postelva.com/ro/spf-vs-dkim-vs-dmarc/ "SPF vs DKIM vs DMARC: what is the difference?").

## Ce înseamnă aliniere în DMARC?

**Alinierea înseamnă că domeniul autentificat prin SPF sau DKIM se potrivește cu domeniul din adresa From vizibilă.** În modul relaxat, implicit, cele două trebuie doar să aibă același domeniu organizațional, deci mail.example.com se aliniază cu example.com. În modul strict trebuie să fie identice. RFC 9989 notează că aproape toți proprietarii de domenii consideră suficientă alinierea relaxată.

Un mesaj trece DMARC când SPF sau DKIM trece și este aliniat. Oricare dintre ele este suficientă. Un furnizor de căsuță precum Proton Mail sau Fastmail semnează cu domeniul tău prin înregistrările CNAME DKIM, deci alinierea se ține fără muncă suplimentară. Capcana este un serviciu terț care semnează cu propriul domeniu: DKIM-ul său trece, dar nu se aliniază până când nu configurezi un domeniu de semnare propriu pentru el.

RFC 9989 găsește domeniul organizațional prin parcurgerea arborelui DNS, cu cel mult opt interogări, în loc de o listă de sufixe publice. Pentru un domeniu obișnuit de .com sau .me, asta nu schimbă nimic pe care trebuie să-l faci.

## Cât timp ar trebui să rămân la p=none?

**Rămâi la p=none cel puțin o lună, apoi la p=quarantine pentru o perioadă similară, înainte de p=reject.** Aceasta este ordinea pe care RFC 9989 o recomandă în ghidul de implementare și care se potrivește cu paginile de ajutor ale furnizorilor. Mailbox.org își pornește înregistrarea de exemplu de la p=none și avertizează că o politică strictă setată prea devreme poate respinge e-mailul legitim. Proton recomandă p=quarantine și trecerea la p=reject odată ce e-mailul legitim trece.

Conform citirii Postelva din 12 noiembrie 2026 a ghidului DMARC al celor 3 furnizori care îl publică (Proton Mail, Mailbox.org și Mailfence), 2 încep de la p=none, iar 1 recomandă p=quarantine.

Două avertismente se aplică lui p=reject. RFC 9989 spune că un domeniu care îl folosește nu trebuie să se bazeze doar pe SPF și trebuie să semneze cu DKIM, deoarece SPF se rupe la redirecționare. De asemenea, spune că domeniile ai căror utilizatori postează pe liste de discuții nu ar trebui să publice deloc p=reject. Listele modifică adesea mesajele, ceea ce rupe semnătura.

## Unde ajung rapoartele DMARC și ce arată?

**Rapoartele agregate ajung la adresa mailto: din rua, de obicei o dată pe zi de la fiecare receptor, și enumeră sursele care au trimis e-mail cu domeniul tău în linia From.** RFC 9989 cere receptorilor să accepte adrese mailto: și recomandă trimiterea rapoartelor agregate cel puțin la fiecare 24 de ore. Raportarea agregată este definită în RFC 9990.

Rapoartele de eșec, cerute cu ruf, sunt copii pe mesaj. Mulți receptori le rețin sau le redactează din motive de confidențialitate, deci nu conta pe ele. Dacă adresa rua se află în afara domeniului tău, proprietarul celuilalt domeniu trebuie să o autorizeze printr-o înregistrare TXT la yourdomain._report._dmarc.otherdomain care conține v=DMARC1;, o regulă care oprește abuzul căsuțelor terților. Pentru un domeniu personal mic, lista surselor este scurtă: furnizorul tău și aproape nimic altceva.

Ca să citești ce publică DNS-ul înainte și după fiecare etapă, folosește [comenzile pentru verificarea înregistrărilor MX, SPF, DKIM și DMARC](https://postelva.com/ro/guides/check-email-dns-records/ "How to check MX, SPF, DKIM and DMARC records").

## Are nevoie domeniul meu personal de DMARC?

**Da, pentru orice domeniu care trimite e-mail: costă o singură înregistrare TXT și blochează mesajele falsificate care folosesc numele tău.** Google cere DMARC, cu o politică none fiind suficientă, de la expeditorii care depășesc 5.000 de mesaje pe zi către conturile Gmail, iar Microsoft aplică același prag pentru Outlook.com. O căsuță personală se află mult sub aceste limite. Înregistrarea tot le spune receptorilor ce vrei să se întâmple cu un fals.

Pentru un domeniu care nu trimite nimic, setează imediat p=reject cu SPF -all și un MX nul. Postelva oferă un șablon „fără e-mail” pentru acest caz. Pentru un domeniu cu căsuță, începe cu none. Partea de transport a aceleiași protecții, criptarea între servere, este tratată în [cum configurezi MTA-STS și TLS-RPT](https://postelva.com/ro/guides/mta-sts-setup/ "How to set up MTA-STS and TLS-RPT").

O definiție care poate fi citată: DMARC este politica DNS care le spune receptorilor ce să facă cu mesajele ale căror rezultate SPF și DKIM nu se aliniază cu domeniul From și unde să trimită rapoarte despre ele.

## Întrebări despre configurarea DMARC

### Cere RFC 9989 p=reject?

Nu. Standardul definește trei politici și lasă alegerea proprietarului domeniului. Recomandă o cale graduală și avertizează împotriva p=reject pentru domeniile ai căror utilizatori postează pe liste de discuții.

### Schimbă RFC 9989 înregistrarea mea DMARC existentă?

Înregistrările încep în continuare cu v=DMARC1, deci o înregistrare care funcționa continuă să funcționeze. Tag-ul ri a fost eliminat, pct a fost scos, iar t, np și psd au fost adăugate.

### Ce se întâmplă dacă public p=reject prea devreme?

E-mailul legitim care eșuează la aliniere, cum ar fi un instrument de newsletter uitat, este refuzat de receptori. Rapoartele de la p=none există tocmai ca să găsească mai întâi acei expeditori.

### Pot folosi o căsuță gratuită pentru rapoarte?

Da, orice căsuță pe care o citești. O adresă separată sau un alias ține fișierele zilnice de rapoarte departe de căsuța principală.

### Câte înregistrări DMARC poate avea un domeniu?

Una per nume, la _dmarc.yourdomain. Subdomeniile pot avea propria înregistrare sau pot moșteni politica părintelui prin sp.

**Pe scurt**

- DMARC este o înregistrare TXT la _dmarc.yourdomain care începe cu v=DMARC1.
- RFC 9989 (mai 2026) este specificația actuală; înlocuiește RFC 7489 și elimină pct.
- Începe cu p=none și cu o adresă rua, citește rapoartele aproximativ o lună.
- Apoi p=quarantine pentru o perioadă similară, apoi p=reject.
- Un mesaj trece când SPF sau DKIM trece și se aliniază cu domeniul From; alinierea relaxată este implicită.
- Un domeniu cu p=reject nu trebuie să se bazeze doar pe SPF și nu ar trebui folosit cu liste de discuții.
- Postelva găzduiește înregistrarea în DNS gratuit; un .com costă 12,49 USD/an pe an.

## Surse

1. [RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html) — RFC Editor (citite 2026-11-12)
2. [RFC 7489, DMARC (depășit)](https://www.rfc-editor.org/info/rfc7489) — RFC Editor (citite 2026-11-12)
3. [SPF, DKIM și DMARC pentru un domeniu personalizat](https://kb.mailbox.org/en/private/custom-domains/spf-dkim-and-dmarc/) — Mailbox.org (citite 2026-11-12)
4. [Domeniu personalizat și anti-spoofing](https://proton.me/support/anti-spoofing-custom-domain) — Proton (citite 2026-11-12)
5. [Ghiduri pentru expeditorii de e-mail](https://support.google.com/a/answer/81126) — Google Workspace Admin Help (citite 2026-11-12)
6. [Consolidarea securității e-mailului: noi cerințe pentru expeditorii cu volum mare](https://techcommunity.microsoft.com/blog/outlook/strengthening-email-security-outlook-new-requirements-for-high-volume-senders/4399730) — Microsoft Tech Community (citite 2026-11-12)

---

Postelva: Postelva înregistrează nume de domenii pentru e-mail privat — adresa pe care o păstrezi când schimbi furnizorul — plătite în criptomonede, fără KYC: fără act de identitate, doar un singur e-mail verificat per domeniu. Este administrat de DomaineGoat LLC, o companie înregistrată în Panama; domeniile sunt înregistrate prin partenerul nostru registrator acreditat ICANN. Un .com costă 12,49 USD/an, același preț în fiecare an.