Så tolkar du DMARC-rapporter med dmarcian och MXToolbox

Att skicka riktad B2B-mail utan att veta om den egna domänen faktiskt autentiseras korrekt är att flyga blint - en trasig DKIM-nyckel eller en glömd underdomän kan tysta ner leveransen utan att någon märker det förrän svarsfrekvensen sjunker. Den här artikeln går igenom hur man använder dmarcian som dmarc report analyzer för löpande övervakning och MXToolbox för snabba stickprov, så att DMARC-policyn kan skärpas utan att blockera egen legitim trafik.

Varför DMARC-rapporter känns oläsliga

När en domän publicerar en DMARC-post börjar mottagande mailservrar - Gmail, Outlook, svenska leverantörer som Telia och Loopia - skicka tillbaka aggregerade rapporter i XML-format, en fil per dag och mottagande system. En B2B-avsändare med några hundra mottagare per dag kan få tiotals sådana filer varje vecka, och rådatan är i praktiken oläsbar utan ett verktyg som tolkar den.

Problemet är särskilt tydligt för säljorganisationer som kör riktad cold email: skickar man från flera underdomäner (sälj, produktnotiser, marknadsföring) och genom flera system (egen SMTP, CRM-integration, transaktionsmail), blir bilden av vem som faktiskt skickar i företagets namn snabbt komplicerad. Utan aggregering vet man inte om en avvikelse beror på en glömd tjänst eller på faktisk spoofing.

Det är här dmarcian och MXToolbox kompletterar varandra: det ena är byggt för kontinuerlig dmarc reporting över tid, det andra för snabba stickprovskontroller vid enskilda ändringar.

dmarcian: rapportanalys och DKIM inspector

dmarcian tar emot DMARC-rapporterna direkt - man pekar RUA-adressen i DNS-posten mot dmarcian - och bygger en instrumentpanel som visar alignment per källa över tid istället för enskilda XML-filer. Som dmarc report analyzer ligger styrkan i trenderna: en enstaka avvikelse en dag är sällan värd att agera på, men en källa som konsekvent failar SPF eller DKIM vecka efter vecka är antingen en glömd tredjepartstjänst eller något som förtjänar närmare granskning.

För avsändare med flera adresser (info@, sdr-team@, notiser@) är funktionen att gruppera per underdomän central - man ser snabbt om det är produktnotiserna eller säljteamets utskick som drar ner siffrorna.

dmarcians dkim inspector är ett separat men besläktat verktyg: det validerar att en specifik DKIM-selector och nyckel faktiskt är korrekt publicerad och signerar mail som väntat, innan man skickar ett enda riktigt mail. Det är praktiskt vid byte av e-postleverantör - man kan göra en dmarcian check av nyckeln innan trafiken flyttas, istället för att upptäcka felet först i produktion.

• Lägg till domänen i dmarcian och uppdatera RUA-taggen i DNS
• Vänta 48-72 timmar på det första dataunderlaget
• Gå igenom källor som failar och matcha mot kända avsändartjänster
• Kör dkim inspector varje gång en ny avsändartjänst eller ett subdomän-alias läggs till

MXToolbox: snabb dmarc lookup och kompletterande kontroller

MXToolbox fyller en annan roll: ett gratis, snabbt uppslag utan konto. Med en dmarc lookup mxtoolbox-sökning ser man omedelbart om DMARC-posten över huvud taget existerar, är syntaktiskt korrekt och vilken policy - none, quarantine eller reject - som är aktiv. Bra som första koll innan man ens sätter upp löpande övervakning.

SuperTool i MXToolbox kombinerar SPF-, DKIM- och DMARC-kontroll i en enda sökning, vilket gör den lämplig för en snabb dmarcian check-liknande diagnos när man inte har tillgång till det egna kontot - till exempel när en kollega frågar 'är vår domän skyddad?' och svaret behövs inom fem minuter.

Skillnaden i praktiken: MXToolbox visar ett ögonblick, dmarcian visar en trend. Använd MXToolbox för dmarc testing direkt efter varje DNS-ändring, och dmarcian för den kontinuerliga bilden över veckor.

Från p=none till trygg policy - realistisk tidslinje

Att gå från en oövervakad domän till full kontroll tar sällan en dag. En rimlig tidslinje för en B2B-avsändare som börjar med p=none och läser sina rapporter i dmarcian varje vecka ser ofta ut ungefär så här.

Vanliga misstag

De första veckorna handlar mest om att identifiera och åtgärda legitima källor som inte är korrekt autentiserade - ofta en glömd notistjänst eller ett säljverktyg som skickar via ett annat SMTP-relä. Att skynda till p=reject innan alignment ligger stabilt över 95 % riskerar att blockera egen trafik, vilket för en cold email-verksamhet betyder missade svar och studsande kundmail.

• Sätta p=reject direkt utan att först köra p=none och läsa rapporterna i minst två-tre veckor
• Glömma att SPF och DKIM måste vara i alignment med From-domänen, inte bara giltiga var för sig
• Inte inkludera alla underdomäner som skickar mail i DMARC-strategin
• Byta DKIM-nyckel hos leverantören utan att kontrollera med dkim inspector först
• Ignorera de forensiska RUF-rapporterna, som ofta visar detaljer om enskilda avvisade mail

Checklista - så gör LDM det

LDM konfigurerar DMARC i monitorläge för varje ny avsändardomän innan en enda cold email-kampanj skickas, kopplar RUA-adressen till dmarcian och kör en MXToolbox-kontroll varje gång en ny underdomän eller avsändaradress läggs till. Målet är att policyn skärps stegvis - aldrig i ett hopp - så att svarsfrekvensen i pågående kampanjer aldrig påverkas negativt av en autentiseringsändring.

• Publicera DMARC med p=none och RUA pekande mot dmarcian innan första kampanjen
• Läs rapporterna varje vecka under uppstartsfasen
• Kör dmarcians dkim inspector vid varje ny avsändartjänst
• Verifiera med en dmarc lookup mxtoolbox-sökning direkt efter varje DNS-ändring
• Höj till quarantine, sedan reject, först när alignment legat stabilt över 95 %

Vanliga frågor