Wanneer legitieme e-mail niet door DMARC komt, is de oorzaak vrijwel altijd een van een paar voorspelbare dingen: een ontbrekend of verkeerd uitgelijnd SPF- of DKIM-resultaat, forwarding die SPF breekt, of een externe afzender die nooit is geauthenticeerd voor je domein. De oplossing is zelden je beleid versoepelen. Het is de bron vinden en correct authenticeren.
Hoe weet ik wat er faalt?
Begin met je rapporten, want die vertellen je precies welke bron faalt en waarom. Je geaggregeerde rapporten splitsen e-mail uit per verzendend IP en tonen de SPF- en DKIM-resultaten plus alignment voor elke bron. Een bron die pass toont voor de ruwe controle maar fail na alignment is het meest voorkomende patroon, en het wijst direct naar het probleem. Als je ze nog niet gemakkelijk kunt lezen, loopt how to read a DMARC report de velden met je door.
Zodra je kunt zien welke bron faalt, is het vrijwel altijd een van de onderstaande oorzaken.
Oorzaak 1: een alignment-verschil
Dit is de grote. SPF of DKIM slaagt, maar voor een domein dat niet overeenkomt met je zichtbare From-adres, dus DMARC telt het als een fout. Het betekent meestal dat een verzenddienst authenticeert met zijn eigen domein in plaats van het jouwe.
De oplossing is de dienst in alignment brengen. Voor SPF betekent dat verzenden met een Return-Path (bounce-domein) op je eigen domein. Voor DKIM betekent het ondertekenen met een sleutel die op je domein is gepubliceerd, zodat het ondertekeningsdomein overeenkomt met je From. De meeste e-mailplatforms ondersteunen een aangepast domein precies hiervoor: je publiceert een of twee CNAME-records en de alignment valt op zijn plek. Het concept wordt uitgelegd in how DMARC works.
Oorzaak 2: forwarding
Forwarding breekt SPF ongemerkt. Wanneer een bericht wordt doorgestuurd, stuurt de doorstuurserver het verder, en die server staat niet in je SPF-record, dus de SPF-controle faalt op de eindbestemming. Je kunt weinig doen aan de doorstuurregels van anderen.
Het goede nieuws is dat DKIM forwarding meestal overleeft, omdat de handtekening meereist met het bericht. Dit is precies waarom DMARC slaagt op SPF of DKIM: zolang je DKIM goed is ingesteld en uitgelijnd, komt doorgestuurde e-mail nog steeds door DMARC, ook als SPF wegvalt. De praktische oplossing voor forwarding-fouten is zorgen dat DKIM correct is ingesteld en uitgelijnd, en je dan niet meer druk maken over de SPF-kolom voor doorgestuurde e-mail.
Oorzaak 3: een externe afzender die je vergeten bent
Vrijwel elke organisatie verstuurt via meer diensten dan ze zich herinnert: een CRM, een helpdesk, een facturatietool, een marketingplatform, een enquêtedienst. Elke dienst moet geauthenticeerd zijn voor je domein, anders faalt de e-mail op DMARC. Nieuwe bronnen die in je rapporten verschijnen, zijn meestal een van deze.
Werk ze een voor een af. Volg voor elke legitieme dienst de instructies om SPF en DKIM in te stellen op je domein (de formulering is vaak "authenticate your domain" of "use a custom sending domain"). Controleer vervolgens in je volgende rapporten of de bron is omgeslagen naar geslaagd en uitgelijnd. Houd een lopende lijst bij, want dit is het deel dat verschuift als teams nieuwe tools in gebruik nemen.
Oorzaak 4: SPF te breed, of over de lookup-limiet
Twee SPF-specifieke valkuilen. Als je SPF-record voorbij 10 DNS-lookups is gegroeid (een harde limiet in de specificatie), kan het volledig falen en anders correcte e-mail meenemen. En een te ruim record kan e-mail doorlaten die je niet wilde autoriseren. Controleer je SPF-record, consolideer include:-vermeldingen als je de limiet nadert, en verwijder diensten die je niet meer gebruikt.
Wat je niet moet doen
Los fouten niet op door je beleid terug te zetten naar p=none en het zo te laten. Daarmee stoppen de rapporten met lastigvallen, maar het beschermt ook niemand meer, waardoor het spoofingprobleem dat je aan het oplossen was weer wagenwijd openstaat. Behandel een fout als een signaal om een bron te authenticeren, niet als reden om terug te krabbelen. De legitieme manier om af te zwakken is p= een trede terugzetten en de rapporten blijven lezen, wat what is a DMARC policy behandelt.
Alles samenvoegen
Lees het rapport, vind de falende bron, bepaal of het legitiem is, en authenticeer het of herken het als spoofing die je nu blokkeert. Werk de lijst af totdat elke echte afzender slaagt en uitgelijnd is, en je beleid veilig op reject kan staan. Als je nog bezig bent met instellen, behandelt how to set up DMARC de basis, en de authentication guide van Bird bevat de domeinspecifieke records. De meeste fouten zien er alarmerend uit, maar blijken een alignment-fix van vijf minuten zodra je weet welke bron je moet aanpakken.