A DMARC -post är en DNS TXT post publicerad på tillämpligt _dmarc namn. Den anger domänägarens policy och kan begära autentiseringsfeedback. Att skapa en kräver en avsedd policy, en fungerande DNS publiceringsväg och ett sätt att verifiera vad som händer med riktig post.
Denna guide följer installationen från förberedelse till acceptans. Den använder en ny övervakad distribution som exempel. Om domänen redan har en starkare godkänd policy, granska den befintliga statusen innan du gör ändringar. Exemplet är en undervisningspost, inte en instruktion för att ersätta varje domäns konfiguration.
Fastställ hur domänen används
Innan du godkänner en policy, fråga om domänen skickar e-post till anställda, applikationsmeddelanden, kampanjer eller ingen legitim e-post alls. Inkludera utkontrakterade tjänster och periodiska flöden. En domäns syfte avgör vad teamet behöver upptäcka och testa.
Den första användbara leveransen är en ägare och en tjänstelista, inte en verkställighetsprocent. Om företaget redan använder en restriktiv policy, fråga vilka bevis som motiverar att ändra den. Ett exempel på nybörjarövervakning bör inte automatiskt ersätta en manöverkontroll.
Tilldela någon att ta emot och granska rapporter. En konfiguration som begär feedback som ingen samlar in lämnar företaget utan bevisen som implementeringen var avsedd att skapa.
Kontrollera sändningsidentiteter och DNS åtkomst
Protokollreferenser: RFC 9989 §4.4.1, RFC 9989 §4.4.2, RFC 9989 §5.3.5, RFC 9989 §8. Operationella checklistor och beslut nedan är redaktionell vägledning.
Identifiera den synliga sändningsdomänen, dess auktoritativa DNS leverantör, personen som har rätt att redigera zonen och den godkända återställningsprocessen. Spara den aktuella rekorduppsättningen.
För varje legitim sändningsväg, upprätta den SPF-utvärderade kuvertidentiteten och DKIM undertecknande identitet. DMARC behöver en passning anpassad SPF eller DKIM sökväg. Fullständigt deltagande kräver både anpassad SPF och DKIM under RFC 9989 §8, även om en passerande justerad väg kan uppfylla regeln på meddelandenivå.
Använd Microsoft 365 eller Google Workspace instruktioner när det är de faktiska sändningstjänsterna. Inkludera alla program som använder en annan leverantör.
Bygg det avsedda rekordet
Protokollreferenser: RFC 9989 §4.5, RFC 9989 §4.7, RFC 9990 §4. Operationella checklistor och beslut nedan är redaktionell vägledning.
För en domän som börjar en övervakad distribution är följande en illustrativ startpost:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comPublicera det värdet som en TXT post på _dmarc.example.com. I en DNS redigerare som accepterar relativa namn för example.com zon får ägaren anges som _dmarc. Andra redaktörer förväntar sig ett fullständigt namn. Verifiera leverantörens ingångsmodell istället för att anta att ett formulär fungerar överallt.
- Del: v=DMARC1; Betydelse i detta exempel: DMARC versionsmarkören; det hör först till
- Del: p=none; Innebörd i detta exempel: Ingen domänägares hanteringspreferens för DMARC fel
- Del: rua=mailto:...; Betydelse i detta exempel: En begäran om samlade rapporter till den godkända destinationen
Exemplet använder en rapportadress för samma domän och förutsätter att insamlingen där fungerar. Ersätt den med den faktiska godkända destinationen. En destination utanför den relevanta domänrelationen kan kräva en separat behörighetspost som kontrolleras av den mottagande domänen.
Kopiera inte example.com till ett produktionsrekord. Lägg inte till en andra DMARC -policypost när en redan finns. Granska och uppdatera den befintliga rekorduppsättningen.
Verifiera det auktoritativa DNS svaret
Protokollreferenser: RFC 9989 §4.5, RFC 9989 §4.10.1, RFC 2308 §5, RFC 8767 §4. Operationella checklistor och beslut nedan är redaktionell vägledning.
Kommandosyntax och alternativ följer ISC:s grävreferens. Den direkta frågan inaktiverar rekursion; inspektera flaggan för auktoritativa svar och fullständig svarskontext.
Börja med det exakta ägarens namn:
dig _dmarc.example.com . TXT +noall +kommentarer +svar +behörighetIdentifiera de delegerade auktoritativa servrarna för zonen och fråga sedan en relevant myndighet direkt. Använd till exempel den faktiska auktoritativa servern i stället för den illustrativa nedan:
dig @ ns1.example.net . _dmarc.example.com . TXT +norecurse +noall +kommentarer +svar +behörighetKontrollera namn, posttyp, fullständigt värde och postuppsättningsgränser. En TXT post kan innehålla flera teckensträngar; som skiljer sig från flera separata kandidatpolicyposter. Jämför rekursiva svar efter att ha bekräftat auktoritet, samtidigt som du tar hänsyn till positiv och negativ cachelagring.
Om det förväntade svaret saknas, följ saknade registerdiagnos. Undvik att upprepade gånger lägga till samma policy på olika kontrollpaneler.
Testa riktiga meddelanden genom viktiga vägar
Protokollreferenser: RFC 9989 §5.3.5, RFC 8601 §7.1. Operationella checklistor och beslut nedan är redaktionell vägledning.
Skicka ett kontrollerat meddelande till en separat mottagare och bevara originalet där. Inspektera det mottagande systemets betrodda resultat, den synliga From-domänen, SPF identiteten och varje relevant DKIM signatur.
Utgå från en tillämplig giltig policy och genomförda autentiseringskontroller. Detta syntetiska exempel visar varför en framgångsrik postkontroll inte är tillräcklig:
- Observation: DMARC TXT post; Resultat: Finns vid det avsedda namnet
- Observation: SPF ; Resultat: Passera för en icke-relaterad leverantörsdomän
- Observation: DKIM ; Resultat: Ingen justerad passerande signatur
- Observation: DMARC -passeringsväg; Resultat: Ej fastställt
Reparera den sändningskonfiguration som stöds i stället för att behandla DNS närvaro som en framgång. Upprepa testet efter korrigering och behåll både förändringen och det observerade resultatet. De inriktningsguide förklarar identitetsjämförelsen.
Bekräfta att rapporter når insamlingssystemet
Protokollreferenser: RFC 9989 §5.3.8, RFC 9990 §3.1. Operationella checklistor och beslut nedan är redaktionell vägledning.
Kontrollera att insamlingsdestinationen tar emot post och att rapporter kan behandlas. Observera representativ trafik till rapporterande mottagare och behåll rapportörens identitet och rapporteringsperioder.
Begärda rapporter garanteras inte från alla mottagare, och de representerar inte alla meddelanden som organisationen skickat. Saknad feedback kan återspegla deltagande, trafik, destination, filtrering eller bearbetningsproblem. Undersök dessa stadier istället för att förklara domänen tyst.
Ställ in acceptanskriterierna
Kräv bevis för konfiguration, autentisering av kritiska meddelanden, insamling och ägande. Granska indirekt post och olösta undantag innan du ändrar den begärda policyn.
Fånga en exakt ändring, dess godkännare, tidigare tillstånd och verifieringsresultatet. Definiera när den tidigare godkända konfigurationen ska återställas om legitim kommunikation avbryts. En rollback bör bevara undersökningsspåret.
För en första utplacering är övervakning en bevisinsamlingsfas. Det är inte en automatisk kalendernedräkning att avvisa. Använd övervakningsbeslutsguide för att definiera de resultat som behövs för nästa politiska beslut.
Den praktiska takeawayen
Behandla DNS posten, autentiseringstester och rapporteringsväg som en implementering. När dessa kontroller är klara, behåll konfigurationen, ägare och olösta undantag. Alla senare verkställighetsbeslut bör följa domänens faktiska användning och bevis.
Tillämpa bevisen utan att överdriva det
Behåll de rekursiva och auktoritativa svaren separat. Ett tomt svar kräver status och auktoritetskontext; det är inte automatiskt frånvaro. TTL-förfallodatum är inte en global deadline för återkallelse eftersom kvalificerande tjänsteföråldrade beteenden kan behålla data bortom färskhet. Kommandona är unexekverade undervisningsexempel; rapportinsamling och meddelandetester förblir acceptansarbete för operatören.