Förstå DMARC-poster och deras struktur
En DMARC-post (Domain-based Message Authentication, Reporting, and Conformance) är en textsträng som publiceras i domänens DNS för att skydda mot e-postförfalskning. Genom att analysera en DMARC-post kan en domänadministratör kontrollera hur mottagande e-postservrar ska hantera meddelanden som misslyckas med SPF- (Sender Policy Framework) eller DKIM-autentisering (DomainKeys Identified Mail).
För att en DMARC-post ska tolkas korrekt av mottagande system måste den följa strikta syntaxregler. Det första och viktigaste kravet är att posten börjar med den skiftlägeskänsliga identifieraren v=DMARC1. Denna identifierare måste alltid vara den absolut första termen i posten. Om detta villkor inte uppfylls kommer mottagande e-postservrar att ignorera hela posten.
Analys av DMARC-policyer: p, sp och np
Kärnan i en DMARC-post är dess policyinställningar, vilka bestämmer hur mottagaren ska agera vid autentiseringsfel. Det finns tre olika policytaggar som styr olika delar av domänstrukturen:
- Domänpolicy (p): Denna tagg anger policyn för huvuddomänen. Om ingen
p-tagg finns i posten, faller domänpolicyn automatiskt tillbaka tillnone. En policy inställd påp=noneinnebär att mottagaren endast övervakar felaktiga e-postmeddelanden och skickar rapporter, men den ber inte mottagande servrar att sätta meddelanden i karantän eller avvisa dem. - Underdomänpolicy (sp): Denna tagg anger policyn för domänens underdomäner.
- Policy för icke-existerande underdomäner (np): Denna tagg styr policyn specifikt för underdomäner som inte existerar i DNS.
När en specifik tagg saknas i DMARC-posten tillämpas en fallbackslinga för underdomäner. Policyn faller då tillbaka från np till sp, och slutligen till huvudpolicyn p.
Under testfaser kan taggen t=y användas. Denna inställning sänker tillfälligt policynivån under testningen: en quarantine-policy sänks till none, och en reject-policy sänks till quarantine.
Identifierarjustering och rapportering
DMARC kräver att identifierarna för SPF och DKIM är justerade (alignment) med domänen i e-postmeddelandets "From"-huvud. Verktyget analyserar dessa inställningar för att säkerställa att justeringen är korrekt konfigurerad.
Rapportering är en central del av DMARC-ramverket och delas upp i två huvudtyper:
- Mottagare för aggregerade rapporter (rua): Anger de e-postadresser dit dagliga sammanställningar av sändningsdata ska skickas. Om ingen giltig
rua-adress anges i posten kommer inga aggregerade rapporter att begäras. - Mottagare för felrapporter (ruf): Anger adresser för detaljerade rapporter om specifika meddelanden som misslyckats med autentiseringen.
Om felrapporteringsinställningen fo används i posten, men det saknas en giltig ruf-adress för felrapporter, kommer fo-taggen att ignoreras helt. Dessutom är suffixet !size på rapport-URI:er numera föråldrat och bör ignoreras av moderna mottagarsystem.
Historiska taggar och äldre specifikationer
I takt med att DMARC-standarden har utvecklats från RFC 7489 till RFC 9989 har vissa taggar och funktioner blivit föråldrade eller ändrat status.
Ett exempel på detta är procenttaggen pct. Värden för pct betraktas numera som historiska och begränsar endast policytäckningen för mottagare som fortfarande följer den äldre DMARC-specifikationen. Moderna mottagarsystem som följer den aktuella standarden kan ignorera historiska taggar. Verktyget identifierar dessa historiska termer för att hjälpa administratörer att hålla sina poster uppdaterade enligt de senaste standarderna.
Vanliga syntaxfel och valideringsregler
När en DMARC-post skapas är det lätt att introducera små syntaxfel som gör att posten inte fungerar. Verktyget kontrollerar posten mot följande regler och genererar specifika felmeddelanden vid avvikelser:
- Format: Posten måste bestå av namn-värdepar separerade med semikolon. Om en term är felaktigt utformad visas felmeddelandet
name=value ✕ (‹position›). - Dubbletter: En tagg får inte förekomma mer än en gång. Om en dubblett upptäcks visas
×2: ‹tag› (‹position›). - Tomma värden: Varje tagg måste ha ett tillhörande värde. Om ett värde saknas visas
‹tag›=∅ (‹position›). - Ogiltiga värden: Om en tagg har ett felaktigt värde visas
‹tag›=‹detail› ✕ (‹position›). För felaktiga rapportadresser visasURI ✕: ‹tag› (‹position›). - Okända taggar: Taggar som inte är registrerade kommer att ignoreras av mottagare och flaggas med
Okänd: ‹tag› (‹position›).
Om du klistrar in en post som innehåller citerade DNS TXT-delar kommer verktyget att sammanfoga dessa automatiskt före analysen påbörjas.
Integritet och lokal databehandling
När du använder detta verktyg för att kontrollera din DMARC-post sker all bearbetning och analys lokalt direkt i din webbläsare. Din DMARC-post laddas inte upp till någon extern server och sparas inte. Ingen data skrivs till webbläsarens lagring, och inga externa nätverksanrop görs i samband med att analysen körs.
Vanliga frågor
Syntax- och policyanmärkningar: p / sp / np?
Om ingen p-tagg anges faller policyn tillbaka till none. Om du använder t=y under testning sänks quarantine till none och reject till quarantine. Om specifika policytaggar saknas för underdomäner faller mottagarens hantering tillbaka i ordningen np till sp och slutligen till huvuddomänens policy p.
RFC 9989: pct / rf / ri?
Enligt den uppdaterade standarden RFC 9989 klassificeras äldre taggar som pct, rf och ri som historiska (historic). Nya eller uppdaterade taggar som np, psd och t är aktiva (active) under den nuvarande specifikationen.
Bevisar ett felfritt resultat att min DMARC-konfiguration fungerar?
Nej. Sidan kontrollerar endast texten du klistrar in. Den frågar inte DNS, expanderar inte leverantörsposter, testar inte en avsändar-IP och bekräftar inte svaret från en mottagande e-postserver. Du måste fortfarande publicera posten i din DNS för att den ska bli aktiv.
Vad händer om min DMARC-post är för lång?
Verktyget har en storleksgräns på under 20 000 tecken. Om du klistrar in en post som överskrider denna gräns kommer verktyget att visa felmeddelandet: "Posten är ovanligt stor. Håll den under 20 000 tecken.".