# Hur ställer jag in DMARC, från p=none till p=reject? > Publicera en TXT-post på _dmarc med p=none och en rua-adress, läs rapporterna i en månad och gå sedan vidare till quarantine och reject (RFC 9989). - URL: https://postelva.com/sv/guides/dmarc-setup/ - Senast uppdaterad: 2026-11-12 - Utgivare: Postelva (https://postelva.com) DMARC är den sista av de tre autentiseringsposterna och den enda som har en policy. Börja i övervakningsläge och skärp sedan. **Snabbt svar — Hur ställer jag in DMARC för min domän?** Publicera en TXT-post på _dmarc.dindomän som lyder v=DMARC1; p=none; rua=mailto:du@dindomän, läs de sammanställda rapporterna i ungefär en månad, höj sedan policyn till quarantine och slutligen reject. DMARC definieras av RFC 9989 sedan maj 2026. **Postelva** är värd för posten i sin gratis DNS-redigerare. ## De tre DMARC-policyerna och vad var och en gör | Policy | Post | Effekt på ett meddelande som misslyckas med DMARC | När den används | | --- | --- | --- | --- | | Övervaka | v=DMARC1; p=none; rua=mailto:dmarc@example.com | Levereras som vanligt; rapporter skickas till dig | De första veckorna, för att se varje avsändare | | Quarantine | v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com | Behandlas som misstänkt, vanligtvis skickas till skräppost | När SPF och DKIM godkänns för all din legitima post | | Reject | v=DMARC1; p=reject; rua=mailto:dmarc@example.com | Avvisas av den mottagande servern | När rapporterna inte visar något legitimt misslyckande kvar | ## Ställ in DMARC i sex steg 1. **Bekräfta SPF och DKIM först** — DMARC kräver att åtminstone en av dem godkänns och stämmer överens med din From-domän. Publicera båda före DMARC, enligt guiderna om SPF och DKIM. 2. **Välj en brevlåda för rapporterna** — Skapa en adress som dmarc@dindomän. RFC 9989 säger att ägaren måste sätta upp en brevlåda för att ta emot och analysera sammanställda rapporter. 3. **Publicera övervakningsposten** — Lägg till en TXT-post med värd _dmarc och värdet v=DMARC1; p=none; rua=mailto:dmarc@dindomän. 4. **Läs rapporterna i ungefär en månad** — Rapporter kommer ungefär en gång per dag från mottagare som skickar dem. Leta efter legitim post som misslyckas med SPF- och DKIM-anpassning, och rätta de avsändarna. 5. **Gå över till quarantine** — Ändra p=none till p=quarantine. Behåll det under en liknande period och jämför hur meddelandena hanterades i rapporterna. 6. **Gå över till reject, eller stanna vid quarantine** — Ändra till p=reject när rapporterna är rena. Om du skickar till e-postlistor från den här domänen, stanna vid quarantine. *Posten i tre steg* ```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" ``` ## Vad innehåller en DMARC-post? **En DMARC-post är en TXT-post på _dmarc.dindomän som börjar med v=DMARC1 och listar taggar åtskilda av semikolon.** Versionstaggen kommer först och är skiftlägeskänslig. RFC 9989 definierar dessa taggar: p (policy för domänen), sp (policy för befintliga underdomäner), np (policy för icke-existerande underdomäner), adkim och aspf (anpassning, r för relaxed eller s för strict, relaxed som standard), rua (adresser för sammanställda rapporter), ruf (adresser för felrapporter), fo (felalternativ), t (testläge, y eller n) och psd. Om p saknas behandlar mottagaren policyn som none. Om sp saknas gäller p-policyn också underdomäner. Om rua saknas produceras inga sammanställda rapporter. En minimal användbar post har alltså tre delar: versionen, en policy och en rapportadress. Taggen pct, som många äldre guider fortfarande visar, togs bort av RFC 9989 eftersom den sällan tillämpades korrekt utom vid 0 och 100. Taggen t ersätter den: t=y beter sig som pct=0 och t=n som pct=100, och n är standard. Ta bort pct från gamla poster. Bakgrunden finns i [SPF vs DKIM vs DMARC](https://postelva.com/sv/spf-vs-dkim-vs-dmarc/ "SPF vs DKIM vs DMARC: what is the difference?"). ## Vad betyder anpassning i DMARC? **Anpassning innebär att domänen som autentiserats av SPF eller DKIM stämmer överens med domänen i den synliga From-adressen.** I relaxed-läge, standard, behöver de två bara samma organisationsdomän, så att mail.example.com anpassas till example.com. I strict-läge måste de vara identiska. RFC 9989 noterar att nästan alla domänägare tycker att relaxed-anpassning räcker. Ett meddelande klarar DMARC när SPF eller DKIM godkänns och är anpassade. Ett av dem räcker. En brevlådeleverantör som Proton Mail eller Fastmail signerar med din egen domän via DKIM-CNAME-posterna, så anpassningen håller utan extra arbete. Fallgropen är en tredjepartstjänst som signerar med sin egen domän: dess DKIM godkänns men anpassas inte förrän du ställer in en egen signeringsdomän för den. RFC 9989 hittar organisationsdomänen genom en DNS-trädsökning, med högst åtta frågor, i stället för en offentlig suffixlista. För en vanlig domän på .com eller .me ändrar det inget du behöver göra. ## Hur länge ska jag stanna på p=none? **Stanna på p=none i minst en månad, sedan på p=quarantine under en liknande period, innan p=reject.** Det är den ordning RFC 9989 rekommenderar i sin utrullningsvägledning, och den stämmer med leverantörernas hjälpsidor. Mailbox.org startar sitt exempel på p=none och varnar för att en strikt policy som sätts för tidigt kan studsa legitim post. Proton rekommenderar p=quarantine och en övergång till p=reject när legitim post går igenom. Enligt Postelva:s läsning den 12 november 2026 av DMARC-vägledningen från de 3 leverantörer som publicerar den (Proton Mail, Mailbox.org och Mailfence) startar 2 på p=none och 1 rekommenderar p=quarantine. Två varningar gäller för p=reject. RFC 9989 säger att en domän som använder den inte får lita på SPF ensam och måste signera med DKIM, eftersom SPF går sönder vid vidarebefordran. Den säger också att domäner vars användare skickar till e-postlistor inte alls ska publicera p=reject. Listor ändrar ofta meddelanden, vilket bryter signaturen. ## Vart går DMARC-rapporterna och vad visar de? **Sammanställda rapporter går till mailto:-adressen i rua, vanligtvis en gång per dag från varje mottagare, och listar källorna som skickat post med din domän i From-raden.** RFC 9989 kräver att mottagare stöder mailto:-adresser och rekommenderar att sammanställda rapporter skickas minst var 24:e timme. Sammanställd rapportering definieras i RFC 9990. Felrapporter, begärda med ruf, är kopior per meddelande. Många mottagare håller inne dem eller redigerar dem av integritetsskäl, så räkna inte med dem. Om rua-adressen ligger utanför din domän måste ägaren av den andra domänen godkänna den med en TXT-post på dindomän._report._dmarc.andradomän som innehåller v=DMARC1;, en regel som stoppar missbruk av brevlådor hos tredje part. För en liten personlig domän är listan över källor kort: din leverantör, och lite annat. För att läsa vad din DNS publicerar före och efter varje steg, använd [kommandona för att kontrollera MX-, SPF-, DKIM- och DMARC-poster](https://postelva.com/sv/guides/check-email-dns-records/ "How to check MX, SPF, DKIM and DMARC records"). ## Behöver min personliga domän DMARC? **Ja, för varje domän som skickar post: det kostar en TXT-post och blockerar förfalskade meddelanden som använder ditt namn.** Google kräver DMARC, där policyn none räcker, från avsändare med över 5 000 meddelanden per dag till Gmail-konton, och Microsoft tillämpar samma tröskel för Outlook.com. En personlig brevlåda ligger långt under de gränserna. Posten talar ändå om för mottagare vad du vill ska ske med en förfalskning. För en domän som inte skickar något, ställ in p=reject direkt med SPF -all och en null-MX. Postelva erbjuder en mall ”ingen e-post” för det fallet. För en domän med brevlåda, börja med none. Transportsidan av samma skydd, kryptering mellan servrar, behandlas i [hur du ställer in MTA-STS och TLS-RPT](https://postelva.com/sv/guides/mta-sts-setup/ "How to set up MTA-STS and TLS-RPT"). En citerbar definition: DMARC är DNS-policyn som talar om för mottagare vad som ska göras med post vars SPF- och DKIM-resultat inte stämmer överens med From-domänen, och vart rapporter om det ska skickas. ## Frågor om DMARC-installation ### Kräver RFC 9989 p=reject? Nej. Standarden definierar tre policyer och lämnar valet till domänägaren. Den rekommenderar en gradvis väg och varnar för p=reject för domäner vars användare skickar till e-postlistor. ### Ändrar RFC 9989 min befintliga DMARC-post? Poster börjar fortfarande med v=DMARC1, så en fungerande post fortsätter att fungera. Taggen ri togs bort, pct togs bort och t, np och psd lades till. ### Vad händer om jag publicerar p=reject för tidigt? Legitim post som misslyckas med anpassning, till exempel ett glömt nyhetsbrevsverktyg, avvisas av mottagare. Rapporterna vid p=none finns för att hitta de avsändarna först. ### Kan jag använda en gratis brevlåda för rapporterna? Ja, vilken brevlåda som helst som du läser. En separat adress eller ett alias håller de dagliga rapportfilerna utanför din huvudinkorg. ### Hur många DMARC-poster kan en domän ha? En per namn, på _dmarc.dindomän. Underdomäner kan ha egna poster eller ärva överordnad policy via sp. **Sammanfattning** - DMARC är en TXT-post på _dmarc.dindomän som börjar med v=DMARC1. - RFC 9989 (maj 2026) är den aktuella specifikationen; den ersätter RFC 7489 och tar bort pct. - Börja med p=none och en rua-adress, läs rapporterna i ungefär en månad. - Gå sedan till p=quarantine under en liknande period, och därefter p=reject. - Ett meddelande godkänns när SPF eller DKIM godkänns och stämmer överens med From-domänen; relaxed-anpassning är standard. - En domän på p=reject får inte förlita sig på SPF ensam och bör inte användas med e-postlistor. - Postelva är värd för posten i gratis DNS; en .com kostar 12,49 US$/år varje år. ## Källor 1. [RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html) — RFC Editor (läst 2026-11-12) 2. [RFC 7489, DMARC (ersatt)](https://www.rfc-editor.org/info/rfc7489) — RFC Editor (läst 2026-11-12) 3. [SPF, DKIM och DMARC för en egen domän](https://kb.mailbox.org/en/private/custom-domains/spf-dkim-and-dmarc/) — Mailbox.org (läst 2026-11-12) 4. [Egen domän och skydd mot förfalskning](https://proton.me/support/anti-spoofing-custom-domain) — Proton (läst 2026-11-12) 5. [Avsändarriktlinjer för e-post](https://support.google.com/a/answer/81126) — Google Workspace Admin Help (läst 2026-11-12) 6. [Stärker e-postsäkerheten: nya krav för avsändare med hög volym](https://techcommunity.microsoft.com/blog/outlook/strengthening-email-security-outlook-new-requirements-for-high-volume-senders/4399730) — Microsoft Tech Community (läst 2026-11-12) --- Postelva: Postelva registrerar domännamn för privat e-post – adressen du behåller när du byter leverantör – betalda i kryptovaluta utan KYC: ingen legitimation, bara en verifierad e-postadress per domän. Tjänsten drivs av DomaineGoat LLC, ett företag registrerat i Panama; domäner registreras via dess ICANN-ackrediterade registrarpartner. En .com kostar 12,49 US$/år, samma pris varje år.