Så gör du en DMARC lookup och läser resultatet rätt

Innan en säljorganisation skickar riktad B2B-mejl bör någon faktiskt ha kontrollerat att DMARC-posten existerar och säger vad man tror den säger. En dmarc lookup tar två minuter men missas ändå ofta — resultatet blir mejl som hamnar i skräppost trots att SPF och DKIM är korrekt konfigurerade. Den här artikeln går igenom hur du gör en dmarc record lookup, läser varje tagg och undviker de fel som stör leveranser.

Varför DMARC-kontroll hör hemma i den löpande övervakningen

DMARC (Domain-based Message Authentication, Reporting and Conformance) talar om för mottagande mejlservrar vad de ska göra med mejl som inte klarar SPF eller DKIM, och till vem de ska rapportera resultatet. För en agentur eller ett bolag som kör riktad B2B-utskick mot specifika kontaktpersoner är detta inte en engångsuppgift vid domänuppsättning — det är en post som kan ändras av misstag, glömmas bort vid domänbyte, eller tystna för att en IT-leverantör städade DNS-zonen.

En dmarc record lookup är den snabbaste kontrollen för att se att posten fortfarande finns, pekar rätt och inte motsäger sig själv. I en cold email-kontext, där varje avsändardomän redan bär ett skört rykte, är det billigare att upptäcka ett trasigt DMARC-record på en minut än att upptäcka det via sjunkande open rate två veckor senare.

Steg för steg: hur du gör en DMARC lookup

Det enklaste sättet är kommandoraden, om du har tillgång till en terminal. Kör dig-kommandot mot underdomänen _dmarc, inte mot huvuddomänen — DMARC-posten ligger alltid där.

Föredrar du ett gratis webbverktyg finns flera dmarc lookup tool-tjänster (till exempel MXToolbox eller dmarcian) där du bara skriver in domänen och får ett tolkat svar direkt, utan att behöva förstå rå DNS-syntax. Det är praktiskt för en säljchef eller marknadsansvarig som vill kontrollera själv utan att invänta IT.

• dig TXT _dmarc.dindomän.se +short — visar rå DNS-post
• nslookup -type=TXT _dmarc.dindomän.se — alternativ på Windows
• Webbaserat dmarc lookup tool — klistra in domän, få tolkad rapport
• Kontrollera även undomäner som används för utskick, t.ex. mail.dindomän.se

Att läsa DMARC-recordet: taggarna som spelar roll

En typisk post ser ut som: v=DMARC1; p=quarantine; rua=mailto:dmarc@dindomän.se; pct=100; adkim=s; aspf=r. Varje del betyder något konkret, och att bara se att en post finns räcker inte — man måste läsa vad den faktiskt säger.

v=DMARC1 identifierar versionen och måste alltid stå först. p= är policyn: none betyder att mottagaren bara rapporterar men inte blockerar, quarantine skickar misslyckade mejl till skräppost, och reject nekar dem helt. rua= är adressen dit aggregerade rapporter skickas — utan den flyger data om spoofingförsök förbi utan att någon ser dem. pct= styr hur stor andel av mejlen policyn tillämpas på, användbart vid gradvis utrullning.

• v=DMARC1 — måste finnas, alltid först i posten
• p= — policy: none, quarantine eller reject
• rua= — mottagaradress för sammanställda dagliga rapporter
• ruf= — mottagaradress för detaljerade forensiska rapporter (mindre använt idag)
• pct= — procentandel mejl som policyn tillämpas på
• adkim= / aspf= — strikt (s) eller relaxed (r) matchning mot DKIM och SPF

Vilken policy passar en B2B-avsändardomän i olika faser

Val av policy bör följa hur mogen övervakningen är, inte bara kopieras från en guide. En ny domän som just börjat skicka riktad B2B-mejl bör starta på p=none för att samla data utan risk att blockera legitima mejl på grund av en felkonfigurerad SPF-post man ännu inte hittat.

Efter några veckors rena rapporter, utan spoofingförsök eller egna leveransproblem, går de flesta bolag vidare till quarantine med pct=25 eller pct=50 för att testa gradvis innan man går till full policy. Reject är slutmålet för domäner som enbart används för utskick och aldrig för persontrafik, men bör införas stegvis.

Vanliga fel som en dmarc record check avslöjar

De flesta problem som en dmarc lookup fångar handlar om struktur, inte innehåll. En dubblerad DMARC-post — två TXT-poster på samma _dmarc-underdomän — gör att mottagare inte vet vilken som gäller och ofta ignorerar båda, vilket i praktiken innebär ingen DMARC-skydd alls.

Ett annat vanligt fel är rua-adressen som pekar på en brevlåda ingen längre läser, ofta kvar sedan en tidigare anställd satte upp posten. Rapporterna kommer in men ingen ser dem, vilket gör att spoofingförsök mot varumärket kan pågå i månader utan att upptäckas.

• Två DMARC-poster på samma underdomän — mottagare struntar i båda
• rua= till en övergiven brevlåda — rapporter samlas men läses aldrig
• p=reject satt för tidigt, innan SPF/DKIM är verifierat stabilt över alla avsändare
• DMARC-post saknas helt på en parkerad domän som ändå kan spoofas
• Syntaxfel, t.ex. saknat semikolon, gör att hela posten ignoreras av vissa mottagare

Hur LDM hanterar DMARC-övervakning i löpande kampanjer

I LDM ingår DMARC-kontroll i den återkommande hälsokontrollen av avsändardomäner, inte bara vid uppstart av en kampanj. Varje domän som används för riktad B2B-utskick kontrolleras löpande mot SPF, DKIM och DMARC, och avvikelser flaggas innan de hinner påverka leveransgraden till mottagare som Gmail, Outlook eller svenska företagsdomäner på Microsoft 365.

Målet är aldrig att kringgå spamfilter — det är att en legitim säljorganisation som skickar personliga, lågvolyms mejl till namngivna kontaktpersoner ska se ut precis som det den är: en verifierad avsändare med korrekt DNS-hygien, inte en anonym massutskickare.

Vanliga frågor