# Vad är DMARC? Justering, policy, RFC 9989 och utrullning URL: https://notificationharbor.com/sv/journal/vad-ar-dmarc Type: blog Locale: sv Published: 2026-09-29 Updated: 2026-09-29 --- > DMARC säger till mottagare vad de ska göra när e-post misslyckas i justering. Så här fungerar posten, policyerna och rapporterna : plus vad som ändrades 2026. Vad är DMARC? Det är en DNS-post som säger till mottagande e-postservrar vad de ska göra när ett meddelande gör anspråk på din domän i From-headern men misslyckas autentisering, och var rapporter om det ska skickas. DMARC autentiserar ingenting i sig själv. Det kontrollerar att SPF eller DKIM passerade och att domänen de validerade överensstämmer med domänen läsaren ser. Den överensstämmelsen kallas justering, och det är den delen de flesta team får fel på. Ett meddelande kan passa SPF, passa DKIM, och fortfarande misslyckas DMARC. Den här situationen är mer vanlig än många tror. ## DMARC är ett policylager ovanpå SPF och DKIM SPF listar vilka IP-adresser som får skicka för en domän. DKIM signerar meddelandet så en mottagare kan verifiera att det inte ändrades och att signeringdomänen godkände det. Ingen av dem tittar på From-adressen en människa läser. DMARC fyller det gapet. Det ställer en fråga: överensstämmer domänen i synlig From-header med domänen som passerade SPF eller DKIM? Om ja, passerar meddelandet. Om nej, tillämpar mottagaren din policy. ![Ingenjör granskar DNS-poster i en terminal på en bärbar dator vid ett skrivbord](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f76a50-inline1.webp) Posten finns på `_dmarc.dindomän.se` som en TXT-post. En minimal, giltig sådan ser ut så här: `_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rapporter@example.com"`Tre taggar gör det verkliga arbetet. `p` är policyn, `rua` är var aggregeringsrapporter går, och `adkim` / `aspf` ställer hur strikt justering är. Allt annat är frivilligt. ## Justering är där bra inställningar misslyckas SPF autentiserar kuvertavsändaren, Return-Path-domänen. DKIM autentiserar domänen i `d=`-taggen för signaturen. DMARC behöver åtminstone en av dessa för att matcha From-domänen, antingen exakt (strikt) eller på organisationsdomännivå (avslappnad, standard). Här är misslyckandet vi ser oftast i spår. Ett team skickar genom en tredjepartsleverantör, leverantören signerar med sin egen domän (`d=leverantör-e-post.se`) och använder sin egen bouncdomän. SPF passerar, DKIM passerar, och DMARC misslyckas eftersom ingen domän matchar `example.com`. Fixen är en anpassad skickningsdomän: en DKIM-nyckel publicerad under din domän, och helst en anpassad return-path på en underdomän. Varje seriös leverantör stöder det. Få aktiverar det som standard. ## De tre policyerna: none, quarantine, reject `p`-taggen har tre värden, och de är inte en stege du klättrar på ett schema. - **`p=none`**: mottagaren levererar normalt och skickar rapporter till dig. Använd den första 2 till 4 veckorna medan du inventerar avsändare. - **`p=quarantine`**: mottagaren dirigerar misslyckanden till skräp eller junk. Använd den när rapporter visar alla legitima källor justerade. - **`p=reject`**: mottagaren vägrar misslyckanden i SMTP-stadiet. Använd den när quarantine har körts rent under en full sändningscykel. `p=none` är övervakning, inte skydd. En domän som sitter på `none` i två år har ett checkboxmärke för efterlevnad och ingen spoofingförsvar. Hoppa över frestelsen att lämna den där eftersom "ingenting bröts". `p=reject` är destinationen för varje domän som bara skickar e-post du kontrollerar. Domäner med tung e-postlisttrafik eller äldre vidarebefordrare behöver mer försiktighet, eftersom vidarebefordran ofta bryter SPF och kan bryta DKIM om mellanstationen redigerar kroppen. ## Varför Gmails och Yahoos regler gjorde detta brådskande Sen februari 2024 kräver [Googles avsändarvägledning](https://support.google.com/mail/answer/81126?hl=en) att alla som skickar mer än 5000 meddelanden per dag till Gmail-konton publicerar en DMARC-post, med SPF och DKIM på plats. Policyn kan vara `none`. Google ber också massavsändare att hålla den användarrapporterad skräpfrekvensen i Postmaster Tools under 0,30%, och rekommenderar att stanna under 0,10%. [Yahoos avsändarhub](https://senders.yahooinc.com/best-practices/) säger samma kärnkrav: en publicerad DMARC-policy på åtminstone `p=none`, med From-domänen justerad till antingen SPF- eller DKIM-domänen. Avslappnad justering är acceptabel. Lägg märke till vad som är och inte är i dessa regler. Kravet är en publicerad post och passering i justering, inte tillämpning. Det är en botten. Det är inte en målsnöre. ![Sänkt tullbarriär på en containeryard vid hamn i skymningen](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/4a2947-inline3.webp) ## Aggregeringsrapporter är produkten, policyn är växeln `rua`-adressen tar emot dagliga XML-rapporter från varje mottagare som respekterar DMARC. Varje rapport listar källIP-adresser, meddelandeantal, SPF- och DKIM-resultat, och om justering höll. Så här hittar du den glömd avsändaren: det gamla CRM-exporten, faktureringsverktyget en kontraktor kopplade upp 2022, marknadsföringsformuläret på en underdomän ingen äger. Rå XML är oläsligt vid volym. Dirigera `rua` till en brevlåda en parser kan smälta, eller till en värdbaserad DMARC-rapporttjänst, och titta på data grupperad efter källa. Vad du vill se är varje legitim källa visar 100% justerad, och allt annat är klart okänt. En praktisk utrullning löper i denna ordning: - Publicera `p=none` med en `rua`-adress. - Samla två till fyra veckors rapporter. Bygg avsändarinventeringen. - Fixa varje legitim ojusterad källa med en anpassad DKIM-domän eller return-path. - Gå till `p=quarantine`. Håll utkik efter supportbiljetter om saknad e-post. - Gå till `p=reject` när quarantine visar inga legitima misslyckanden. Skicka varje steg separat. Att ändra policyn och lägga till en ny skickningsleverantör samma vecka gör någon regression omöjlig att tilldela. ## DMARCbis ändrar taggarna, inte din post År 2026 publicerade IETF RFC 9989, RFC 9990 och RFC 9991, som föråldrar RFC 7489. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989) är kärn-DMARC-specifikationen. Aggregeringsrapportering och misslyckanderapportering gick till sina egna dokument. De praktiska ändringarna för en postägare är små: - `pct`, `rf` och `ri` är borttagna. - `t` (testningsläge) ersätter `pct` som en allt-eller-inget-växel: `t=y` rapporterar utan att tillämpa. - `np` ställer en policy för icke-existerande underdomäner, vilket blockerar spoofing av adresser som `abc123.example.com`. - `psd` markerar offentliga suffixdomäner, och en DNS-trädpromenad ersätter den gamla Public Suffix List-sökningen. Existerande `v=DMARC1`-poster förblir giltiga. Ingenting bryter om du inte ändrar något idag. Leverantörstödet för de nya taggarna kommer att rulla ut ojämnt, så en ny tagg som verkar göra ingenting brukar innebära att mottagaren inte har implementerat den ännu. Taggen `np` är värd att anta tidigt. Om du ställer `np=reject` medan `p` fortfarande är `none` stänger du misslyckandebanan för falsk-underdomän utan att låsa in resten av e-posten i tillämpning. ## Underdomäner, och varför standardarvet är En DMARC-post på organisationsdomänen gäller även underdomäner, såvida du inte åsidosätter den med `sp`. Det arvet är användbart och även en fälla. Om marknadsföring skickar från `news.example.com` genom en separat leverantör, ärver den överordnad policy. Flytta föräldern till `p=reject` innan den leverantören har justerad DKIM och nyhetsbrevet går på golvet. Publicera en separat `_dmarc.news.example.com`-post när en underdomän har sin egen avsändarflotta och sin egen utrullningshastighet. En renare arkitektur separerar strömmar efter underdomän från början. Transaktionell e-post på en, livscykelsamtal på en annan, mänsklig e-post på roten. Var och en får sin egen DKIM-nycklar, sitt eget rykte och sin egen DMARC-post. ## Läs Authentication-Results-headern innan du gissar När ett meddelande misslyckas, registrerar mottagarservern varför. I Gmail exponerar "Visa original" `Authentication-Results`-headern, och den säger dig mer än någon instrumentpanel. `Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounce.leverantör-e-post.se; dkim=pass header.d=leverantör-e-post.se; dmarc=fail (p=NONE) header.from=example.com`Läs den från vänster till höger. SPF passerade för `bounce.leverantör-e-post.se`. DKIM passerade för `leverantör-e-post.se`. DMARC misslyckades eftersom From-headern säger `example.com` och ingen passerad domän matchar det. `(p=NONE)`-noten visar policyn mottagaren såg. Vid `none` levererades detta meddelande ändå. Vid `reject` skulle det ha studsade med ett 5.7.x-fel, och avsändaren hade fått reda på det från en kund. Två checks fångar de flesta av dessa fall. Bekräfta `header.d`-värdet i DKIM-resultatet är din domän. Bekräfta sedan att `smtp.mailfrom`-domänen är din domän eller en underdomän till den. ## SPF har en söklimitering som DMARC exponerar SPF tillåter tio DNS-sökningar per utvärdering. Varje `include:` för en leverantör använder några av dem, och kapslade includes använder mer. Över tio och SPF returnerar ett permanent fel, vilket räknas som ett misslyckande. Team med fem eller sex skickningsverktyg träffar detta utan att märka det, eftersom SPF-misslyckanden var osynliga innan DMARC-rapportering. När `rua`-rapporter kommer in är mönstret tydligt: en källa plötsligt misslyckas SPF över alla mottagare på dagen någon lade till en annan `include:`. Det här är en anledning till att förlita sig på DKIM-justering som den primära vägen. DKIM överlever mest vidarebefordran, har ingen söklimitering, och är bunden till meddelandet snarare än den anslutande IP-adressen. Håll SPF giltigt, men bygg inte din DMARC-passage på det ensamt. ## Vad DMARC inte gör DMARC förhindrar exakt-domän-spoofing. Det stoppar inte lookalike-domäner (`examp1e.com`), det dömer inte innehåll, och det fixar inte ett dåligt avsändarrykte. En perfekt justerad domän som skickar till köpta listor hamnar fortfarande i skräp. Det ersätter inte heller övervakning. Justering kan brytas tyst: en DNS-ändring tar bort en DKIM-väljare, en leverantör roterar nycklar, ett nytt verktyg börjar skicka utan din vetskap. Rapporter är hur du tar reda på det innan dina användare gör det. Behandla DMARC-posten som vilken annan produktionskonfiguration som helst. Den hör hemma i versionsöversikt, ändringar går genom granskning, och `rua`-brevlådan behöver en ägare. ![Kräm kuvert som förseglas med ett rött vaxstämpel](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f3aca9-inline2.webp) ## Innan du publicerar posten Gå igenom detta en gång. Det tar under en timme för en enda domän. - Lista varje system som skickar e-post som din domän: produkt, fakturering, supportdesk, CRM, marknadsföring, kalenderinbjudningar. - Bekräfta att varje signerar DKIM med din domän, inte leverantörens. - Ställ in en anpassad return-path där leverantören tillåter det. - Välj en `rua`-destination någon kommer att läsa. - Börja med `p=none`, och sätt datumet du planerar att granska det i kalendern. - Kontrollera skräpfrekvensen i Google Postmaster Tools varje vecka under utrullningen. ## Vart du går härifrån Om du aldrig har tittat på dina rapporter, publicera `p=none` med en `rua`-adress idag och läs vad som kommer tillbaka om två veckor. Den första rapporten namnger nästan alltid åtminstone en avsändare ingen mindes. Nästa konkreta steg är att besluta vilka av dem du håller och implementera ändringar. ## FAQ ### Är DMARC obligatoriskt? För massavsändare, effektivt ja. Google kräver en DMARC-post för avsändare av mer än 5000 meddelanden per dag till Gmail, och Yahoo kräver en giltig policy på åtminstone p=none. Tillämpning krävs inte, men posten och justeringen är det. ### Vad betyder p=none i DMARC? Det betyder övervakning endast. Mottagare levererar misslyckad e-post normalt och skickar rapporter till dig. Det uppfyller minimum för Gmail och Yahoo men ger inget skydd mot spoofing. ### Kan ett e-postmeddelande passa SPF och DKIM och fortfarande misslyckas DMARC? Ja. DMARC kräver att domänen validerad av SPF eller DKIM överensstämmer med From-header-domänen. E-post som skickas genom en leverantör som signerar med sin egen domän passerar båda kontrollerna och misslyckas fortfarande justering. ### Hur länge ska jag stanna på p=none? Normalt två till fyra veckor av aggregeringsrapporter, tillräckligt länge för att se varje legitim avsändare inklusive lågtillgängliga. Fortsätt när varje legitim källa visar som justerad. ### Påverkar DMARC leveransvillkoren? Indirekt. En publicerad, justerad post är ett baslinjekrav på Gmail och Yahoo, och misslyckad justering kan trycka e-post till skräp eller utlösa avslag under en tillämpad policy. Det fixar inte dåligt avsändarrykte eller höga klagfrekvenser. ### Vad ändrades med DMARCbis och RFC 9989? RFC 9989 föråldrar RFC 7489. Det tar bort pct, rf och ri, lägger till t, np och psd, och ersätter Public Suffix List-sökningar med en DNS-trädpromenad. Befintliga v=DMARC1-poster förblir giltiga.