DMARC-foutmeldingen (RUF): wat ze zijn, hoe ze werken en hoe je ze veilig kunt inschakelen

Een DMARC-record is een belangrijke stap om uw domein te beschermen tegen spoofing, phishing en ongeoorloofd e-mailgebruik. De echte operationele waarde komt echter voort uit de rapporten die aangeven of legitieme afzenders de e-mailverificatie en waar er fouten optreden.

Veel bedrijfsteams vertrouwen op geaggregeerde DMARC-rapporten om de algehele status van hun domein te bewaken, maar die overzichten bieden mogelijk onvoldoende details voor incidentafhandeling, nalevingsonderzoeken of het oplossen van complexe problemen met externe afzenders. DMARC-foutmeldingen (RUF) voegen context op berichtniveau toe, waardoor beveiligings- en IT-teams de oorzaak van authenticatiefouten sneller kunnen achterhalen. 

In deze handleiding wordt uitgelegd wat RUF-rapporten zijn, hoe ze verschillen van geaggregeerde gegevens en hoe u ze effectief kunt gebruiken.

Wat is een DMARC-foutmelding?

Een DMARC-foutmelding (ook wel foutmelding of RUF-rapport genoemd) is een gedetailleerde, vrijwel realtime melding die door ontvangende e-mailservers wordt verzonden wanneer een bericht de DMARC-authenticatie niet doorstaat. Deze melding bevat diagnostische gegevens op berichtniveau, waaronder authenticatieresultaten, de afzender en de berichtheaders, zodat domeineigenaren mogelijke spoofingpogingen kunnen onderzoeken en problemen met e-mailauthenticatie kunnen oplossen.

Terminologische opmerking: De termen “DMARC-foutmelding”, “DMARC-foutmelding” en “RUF-rapport” verwijzen allemaal naar hetzelfde rapporttype. Het onderliggende formaat is AFRF (Authentication Failure Reporting Format), gedefinieerd in RFC 6591, een DMARC-specifieke uitbreiding van ARF (Abuse Reporting Format, RFC 5965). Deze termen worden in de branche vaak door elkaar gebruikt.

• Wie genereert deze rapporten? Ontvangende mailservers, internetproviders, e-mailgateways van bedrijven en beveiligingsapparatuur, maar alleen wanneer deze RUF ondersteunen en een authenticatiefout detecteren. Domeineigenaren vragen rapporten aan via de ruf=-tag, maar ontvangers beslissen op basis van hun eigen privacybeleid en configuratie of ze deze versturen.
• Waar wordt het naartoe gestuurd? Het wordt verzonden naar het e-mailadres dat is opgegeven in de ruf=-tag van uw DMARC DNS-record.
• Welk formaat wordt er gebruikt? In tegenstelling tot geaggregeerde rapporten, die als XML-bestanden worden geleverd, maken RUF-rapporten gebruik van AFRF (Authentication Failure Reporting Format) om gedetailleerde gegevens over authenticatiefouten te verstrekken in een voor mensen beter leesbare structuur.

Welke informatie staat er in DMARC-foutrapporten?

Omdat RUF DMARC-rapporten zijn bedoeld voor diepgaande probleemoplossing, bevatten ze specifieke metagegevens over het mislukte bericht die u niet in geaggregeerde rapporten zult aantreffen. Een typisch RUF-rapport bevat:

• IP-adres van de afzender: het exacte IP-adres dat heeft geprobeerd het bericht te verzenden
• 'From'- en 'Return-Path'-adressen: de 'From'-header en de afzender van de envelop
• Onderwerp: het daadwerkelijke onderwerp van de mislukte e-mail
• Resultaten van de authenticatie: specifieke details over waarom SPF of DKIM mislukt is en of DMARC-afstemming is gerealiseerd
• E-mailheaders: de volledige feedback-headers van het bericht
• Ontvangsttijd: het tijdstempel waarop het bericht bij de ontvangende server is aangekomen
• Toegepast DMARC-beleid: het beleid dat op het bericht is toegepast, of dit nu 'geen', 'quarantaine' of 'afwijzen' is
• Resultaat van de bezorging: of het bericht is afgeleverd, in quarantaine is geplaatst of is geweigerd
• Persoonlijk identificeerbare informatie (PII): aangezien deze rapporten onderwerpen en e-mailadressen van ontvangers kunnen bevatten, bevatten ze vaak PII

Opmerking over privacy

Omdat er persoonlijk identificeerbare informatie (PII) in is opgenomen, hebben veel grote e-mailproviders ervoor gekozen geen RUF-rapporten te versturen om de privacy van gebruikers te beschermen. PowerDMARC biedt hiervoor een oplossing door ondersteuning te bieden voor PGP-versleuteling voor RUF-rapporten, zodat gevoelige gegevens versleuteld blijven en alleen voor u toegankelijk zijn. Sommige ontvangers die wel RUF-rapporten versturen, verwijderen eerst gevoelige delen uit de tekst of de onderwerpregel. Daarom komen sommige foutmeldingen leeg aan of bevatten ze [REDACTED]-teksten.

Voorbeeld van een DMARC-foutmelding: hoe je de verschillende velden kunt interpreteren

Om te begrijpen wat er achter de schermen gebeurt, kun je de ruwe gegevens bekijken. Wanneer een e-mail mislukt, genereert de ontvanger een rapport in AFRF-formaat. Hieronder volgt een representatief voorbeeld waarbij gebruik wordt gemaakt van gereserveerde domeinen en IP-bereiken volgens RFC 5737.

Interpretatie per veld

Praktische tip

Ga bij het beoordelen van een RUF-rapport de volgende vier vragen achtereenvolgens door. Staat het bron-IP-adres op uw lijst met goedgekeurde afzenders? Is SPF of DKIM mislukt, of beide? Komt het veld ‘Original-Mail-From’ overeen met uw domein? Lijkt dit op een randgeval van doorsturen of op doorsturen via een mailinglijst? Als u deze vragen niet met zekerheid kunt beantwoorden, stuur het rapport dan door naar uw beveiligingsteam voor nader onderzoek.

Hoe de record er in je DNS uitziet

Om deze rapporten te ontvangen, moet uw DMARC-record de tag `ruf=` bevatten. Een illustratief voorbeeld:

Als je rapporten naar een ander domein dan je eigen domein verstuurt, moet het doeldomein een DNS-record publiceren waarmee het wordt gemachtigd om namens jou rapporten te ontvangen. Uitleg bij de tags:

• v=DMARC1: de standaardversietag die het DMARC-protocol identificeert
• p=none: monitoringmodus; berichten worden niet geweigerd of in quarantaine geplaatst, en ontvangers worden gevraagd om authenticatieresultaten te rapporteren
• rua=: de bestemming voor dagelijkse geaggregeerde rapporten met een overzicht van alle authenticatieactiviteiten
• ruf=: de bestemming voor storingsmeldingen; stuur deze door naar een beveiligd, speciaal daarvoor bestemd verwerkingsplatform in plaats van naar een algemene inbox
• fo=1: geeft ontvangers de opdracht een rapport te genereren als SPF of DKIM faalt

DMARC-geaggregeerd rapport versus foutrapport: RUA versus RUF

Beide rapporttypes worden binnen hetzelfde DMARC-record geconfigureerd, maar dienen verschillende doelen. RUA biedt domeinbreed inzicht over een langere periode; RUF biedt details op berichtniveau voor specifieke fouten. Voor een uitgebreidere vergelijking, zie deze vergelijking van RUA- en RUF-rapporten.

Hoe u DMARC-foutrapporten in uw DNS-record kunt inschakelen

Om RUF in te schakelen, moet u uw bestaande DMARC TXT-record in DNS bijwerken. Volg deze stappen.

1. Ga naar de website van uw DNS-provider. Log in op de DNS-beheerconsole voor uw domein.
2. Zoek uw DMARC TXT-record op. Zoek het TXT-record dat is gepubliceerd op _dmarc.uwdomein.com.
3. Voeg de RUF-bestemming toe. Voeg een ruf=mailto:-adres toe waarnaar ondersteunde foutmeldingen moeten worden verzonden.
4. Configureer opties voor storingen. Voeg de fo=-tag toe om te definiëren wanneer rapporten moeten worden gegenereerd; dit wordt in de volgende paragraaf behandeld.
5. Zorg voor een veilige verwerking. Stuur rapporten door naar een beveiligd platform zoals PowerDMARC in plaats van naar een algemene inbox.
6. Sla op en wacht tot de wijzigingen zijn doorgevoerd. Het kan tot 48 uur duren voordat DNS-wijzigingen wereldwijd zijn doorgevoerd.

Het verzenden van RUF-rapporten naar een standaardinbox zorgt voor ruis en verhoogt het risico op blootstelling van gegevens. Een rapportageplatform centraliseert DMARC-gegevens, zet ruwe authenticatiegegevens om in overzichtelijke dashboards en koppelt fouten aan de resultaten van de SPF-, DKIM- en DMARC-controle, zodat teams problemen sneller kunnen opsporen.

DMARC voor Tag uitgelegd: wanneer er foutmeldingen worden geactiveerd

De fo-tag is een onderdeel van het DMARC-record dat de ontvangende server aangeeft wanneer er een foutmelding moet worden gegenereerd.

De meeste beveiligingsprofessionals gebruiken fo=1 omdat dit het meeste inzicht biedt in mislukte authenticatiepogingen. Dat gezegd hebbende, moet fo=1 worden doorgestuurd naar een speciaal, beveiligd verwerkingsplatform in plaats van naar de inbox van een medewerker. Het aantal rapporten dat hierdoor wordt gegenereerd, kan zonder automatisering onbeheersbaar worden, en het verzenden ervan naar een onbeveiligde inbox vergroot het risico op blootstelling van gevoelige berichtgegevens. A DKIM-fout kan met name een stortvloed aan rapporten veroorzaken die beter kunnen worden geïsoleerd van een gedeelde mailbox.

Waarom je mogelijk geen DMARC-foutmeldingen ontvangt

Als u RUF hebt ingeschakeld maar uw rapportagebestemming leeg is, hoeft dit niet per se te duiden op een configuratiefout. Er zijn verschillende veelvoorkomende oorzaken waardoor er geen rapporten worden ontvangen.

Daarom rapporteert RUA RUA-rapporten worden beschouwd als de toonaangevende bron voor het monitoren van de algehele gezondheid van het domein, terwijl RUF-rapporten dienen als aanvullend onderzoeksinstrument voor specifieke storingsscenario's.

Zorgen over privacy en veiligheid

Aangezien RUF-rapporten onderwerpregels, ontvangersadressen, kopteksten en soms ook de inhoud van berichten kunnen bevatten, moeten ze zorgvuldig worden behandeld in het kader van privacyregelgeving zoals de AVG en CCPA. Voor organisaties in gereguleerde sectoren zoals de financiële sector, de gezondheidszorg, het onderwijs, de detailhandel en de overheid moeten foutgegevens worden verwerkt via beveiligde systemen met toegangsbeheer die voldoen aan de privacy- en nalevingsverplichtingen.

Voor organisaties die moeten voldoen aan de eisen van Google, Microsoft, PCI DSS, de AVG of overheidsvoorschriften inzake e-mailverificatie, zijn veilige rapportagestromen van groot belang. RUF-gegevens kunnen onderzoeken ondersteunen, maar een totaaloverzicht van DMARC, de voortgang van de handhaving en het beheer van geverifieerde afzenders blijven essentieel voor het op lange termijn voldoen aan de voorschriften.

Beste praktijken

• Gebruik een speciaal, beveiligd rapportageplatform.
• PGP-versleuteling inschakelen: een 'bring-your-own-key'-model houdt in dat alleen geautoriseerde gebruikers met de privésleutel de inhoud van gevoelige storingsrapporten kunnen bekijken.
• Beperk de toegang tot storingsgegevens op basis van rol en operationele behoefte.
• Stel beleidsregels vast voor het bewaren van opgeslagen RUF-gegevens, in overeenstemming met de geldende privacyregelgeving.
• Voer een juridische beoordeling uit voordat u RUF inschakelt in rechtsgebieden met strenge voorschriften inzake gegevensbescherming.

Hoe u RUF-rapporten kunt gebruiken om spoofing op te sporen en storingen te verhelpen

Zodra u foutgegevens ontvangt, moet u elk rapport beschouwen als een aanwijzing voor nader onderzoek en niet als een definitief oordeel. Toets de bevindingen aan de hand van goedgekeurde verzenderslijsten, geaggregeerde DMARC-trends, logbestanden van de e-mailgateway en informatie over cyberdreigingen, voordat u beslissingen neemt over corrigerende maatregelen. Vijf scenario’s dekken het grootste deel van wat er uit foutgegevens naar voren komt.

Het opsporen van domein-spoofing

Als in een storingsrapport een onbekend bron-IP-adres wordt gesignaleerd waarbij uw domein in het ‘From’-adres van de header wordt gebruikt, beschouw dit dan als een aanwijzing die nader onderzoek vereist. Controleer het bronadres eerst aan de hand van goedgekeurde verzenderslijsten, algemene trends, gateway-logs en dreigingsinformatie. Als wordt bevestigd dat het om een ongeautoriseerd adres gaat, kan het IP-adres aan blokkeerlijsten worden toegevoegd en kan uw Security Operations Center hiervan op de hoogte worden gesteld.

Het verhelpen van legitieme storingen

Soms mislukt de verzending van legitieme e-mails doordat een externe afzender niet correct is gekoppeld, een DKIM-selector verkeerd is geconfigureerd of het SPF-record van het domein te complex is geworden. Een rapportageplatform helpt teams om deze storingen in hun context te identificeren en het SPF-beheer te vereenvoudigen met gehoste SPF en geautomatiseerde vereenvoudiging, waardoor het risico op bezorgingsproblemen afneemt naarmate er nieuwe SaaS-tools worden toegevoegd.

Storingen in verband met het doorsturen opsporen

Het doorsturen van e-mail leidt vaak tot een SPF-fout, omdat het IP-adres van de doorstuurserver niet in het SPF-record van de oorspronkelijke afzender staat vermeld. Als een RUF-rapport fouten aangeeft afkomstig van een erkende doorstuurservice of een mailinglijst-relay, is de oorzaak waarschijnlijk een SPF-fout en niet zozeer een poging tot spoofing. Controleer in dergelijke gevallen of DKIM nog steeds wordt geaccepteerd, aangezien DKIM-handtekeningen doorgaans het doorsturen overleven, en of aan het DMARC-beleid kan worden voldaan door uitsluitend DKIM-alignment toe te passen.

Schaduw-IT en ongeautoriseerde afzenders opsporen

RUF-rapporten kunnen afzenders aan het licht brengen die niet door IT-teams zijn geautoriseerd of waarvan zij niet op de hoogte zijn, zoals een marketingteam dat een nieuwe automatiseringstool heeft aangesloten zonder het SPF-record bij te werken. Als uit een foutmelding blijkt dat er een fout is opgetreden vanaf een IP-adres dat behoort tot een recent geïmplementeerd SaaS-platform, gaat het hier om een configuratiefout en niet om een aanval. Voeg de dienst toe aan uw lijst met geautoriseerde afzenders en werk uw DMARC-record dienovereenkomstig bij.

Onderzoeksworkflow

1. Bepaal het bron-IP-adres in het RUF-rapport.
2. Controleer de autorisatie: hoort dit IP-adres bij een tool of dienst die uw organisatie gebruikt?
3. Controleer of alles correct is ingesteld: bekijk de SPF- en DKIM-resultaten in het veld „Authentication-Results“.
4. Controleer of er sprake is van doorsturen of gebruik van een mailinglijst: ga na of de SPF-fout het gevolg is van een tussenliggend relais.
5. Risico classificeren: geautoriseerde afzender met een configuratiefout, ongeautoriseerde afzender, doorstuurbericht of schaduw-IT-bron.
6. Oplossing: als de autorisatie is goedgekeurd maar de controle mislukt, corrigeer dan de SPF- of DKIM-instellingen. Als de autorisatie is afgewezen, pas dan je DMARC-beleid toe met p=quarantine of p=reject om de bescherming af te dwingen.
7. Controleer aan de hand van geaggregeerde rapporten: ga na of de corrigerende maatregelen effectief zijn door de daaropvolgende RUA-rapporten te bekijken.

Wanneer het de moeite waard is om RUF in te schakelen, en wanneer je het beter kunt overslaan

RUF is niet voor elk domein standaard ingeschakeld. Of het zijn nut bewijst, hangt af van wie de rapporten gaat lezen en waarvoor ze bedoeld zijn. Er zijn drie situaties waarin het de moeite waard is, en twee waarin het juist niet aan te raden is.

• Schakel deze functie in als je over een beveiligingsteam beschikt dat op basis van de gegevens actie kan ondernemen. SOC-analisten en incidentresponders gebruiken de details op berichtniveau om bevestigde spoofing te onderzoeken; dit is de belangrijkste toepassing van het rapport.
• Schakel deze functie in tijdens het oplossen van problemen. Wanneer een externe afzender herhaaldelijk fouten vertoont en de geaggregeerde gegevens niet specifiek genoeg zijn, versnelt het bekijken van de foutdetails over het exacte IP-adres en het afstemmingsresultaat de diagnose.
• Schakel deze functie in binnen gereguleerde omgevingen waar al veilige verwerking is geïmplementeerd. Als u al gebruikmaakt van versleutelde rapportage met toegangscontrole, brengt de extra diepgang van het onderzoek nauwelijks extra risico's met zich mee.
• Overweeg dit nog eens als de rapporten in een gedeelde inbox terecht zouden komen. Zonder versleuteling en toegangscontroles leidt het ontvangen van rapporten die PII bevatten tot compliance-risico's die zwaarder wegen dan de voordelen.
• Denk er nog eens over na als niemand verantwoordelijk is voor de output. Een hoog fo=1-volume zonder analist die het beoordeelt, wordt ruis, en de geaggregeerde rapporten dekken de monitoring van de domeingezondheid al.

Voor de meeste teams is de standaardaanpak ‘aggregate-first’. Voer RUA uit om de status van het domein en de voortgang van de handhaving te controleren, en schakel vervolgens bewust RUF in wanneer een onderzoek of een hardnekkige storing bij een afzender een diepgaande analyse op berichtniveau vereist, waarbij de gegevens worden doorgestuurd naar een platform dat is ontworpen om met dergelijke gevoelige informatie om te gaan.

Beperkingen van DMARC-foutrapporten

Het is net zo belangrijk om te begrijpen wat RUF-rapporten niet kunnen, als te weten wat ze wel kunnen. Beschouw foutmeldingen als een aanvullend onderzoeksinstrument en niet als de belangrijkste basis voor beslissingen in het kader van het DMARC-programma.

• Beperkte ondersteuning door providers: grote e-mailproviders, waaronder Gmail en Microsoft 365, sturen over het algemeen geen RUF-rapporten vanwege privacyoverwegingen, waardoor de dekking van storingen inherent onvolledig is
• Verwerkte gegevens: ontvangers die wel rapporten versturen, kunnen de onderwerpregels, de inhoud van de berichten of de adressen van de ontvangers redigeren voordat ze worden verzonden
• Valse positieven door doorsturen: mailinglijst-relays en doorstuurservices veroorzaken vaak SPF-fouten die lijken op authenticatiefouten, maar geen pogingen tot spoofing zijn
• Rapportvolume en ruis: bij fo=1 kunnen afzenders met een hoog volume een onbeheersbaar aantal meldingen ontvangen, waarvan vele eerder het verwachte doorstuurgedrag weerspiegelen dan echte bedreigingen
• Geen vervanging voor RUA: geaggregeerde rapporten blijven de toonaangevende bron voor de authenticatiestatus van het hele domein, dus RUF moet de lopende RUA-monitoring aanvullen in plaats van vervangen
• Risico op blootstelling van persoonsgegevens: zonder versleuteling en toegangscontroles kan het ontvangen van RUF-rapporten op zich al leiden tot nalevingsverplichtingen op grond van de AVG, de CCPA en soortgelijke regelgevingen

Hoe MSP’s DMARC-foutrapporten kunnen gebruiken voor verschillende domeinen van klanten

Voor MSP’s en MSSP’s zijn storingsrapporten waardevol wanneer een klant melding maakt van ontbrekende berichten, vermoedelijke spoofing of onverklaarbare authenticatiefouten. Onbewerkte RUF-rapporten zijn echter moeilijk op grote schaal te beheren. Ze kunnen gevoelige klantgegevens bevatten, tegelijkertijd vanuit meerdere domeinen binnenkomen en moeten worden gecorreleerd met andere authenticatiesignalen om bruikbaar te zijn.

• Inzicht in meerdere domeinen: het samenvoegen van rapporten uit tientallen of honderden klantdomeinen zonder een gecentraliseerd platform vergt aanzienlijke handmatige inspanning
• Omgang met gevoelige gegevens: RUF-rapporten van klantdomeinen kunnen persoonsgegevens van eindklanten bevatten, waardoor de MSP aan bepaalde nalevingsverplichtingen moet voldoen
• Beheer van het aantal rapporten: klantdomeinen met een hoog volume kunnen grote aantallen storingsrapporten genereren die de workflows van technici overbelasten
• Toegang op basis van rol: technici mogen alleen rapporten zien voor de klantdomeinen die aan hen zijn toegewezen

Een gecentraliseerd platform zoals PowerDMARC voor MSP's en MSSP's helpt serviceproviders om RUF-gegevens veilig te verwerken, klantdomeinen te scheiden, de tijd voor handmatig onderzoek te verkorten en technici snel inzicht te geven in welke afzender, welk IP-adres of welk authenticatiemechanisme een storing heeft veroorzaakt, zonder gevoelige gegevens onnodig bloot te geven.

Hoe PowerDMARC helpt bij DMARC-foutmeldingen

PowerDMARC verwerkt DMARC-foutgegevens op een veilige manier en zet ruwe authenticatiefouten om in bruikbare inzichten. In plaats van gevoelige RUF-rapporten naar een standaard inbox te sturen, bekijken teams de rapporten in een gecentraliseerd dashboard, beveiligen ze gevoelige gegevens met PGP-versleuteling en brengen ze fouten in verband met de resultaten van de SPF-, DKIM- en DMARC-afstemming.

• Duidelijk inzicht: identificeer defecte verzendbronnen, authenticatieresultaten en verdachte IP-adressen sneller in al uw domeinen
• Veilige verwerking: PGP-versleuteling met een 'bring-your-own-key'-model beperkt de blootstelling van gevoelige storingsgegevens, zodat zelfs PowerDMARC de versleutelde inhoud niet kan lezen
• Gecentraliseerd beheer: bewaak DMARC, SPF, DKIM, BIMI, MTA-STS en TLS-RPT vanaf één platform zonder van tool te wisselen of onbewerkte XML te parseren
• Snellere oplossing: los problemen met legitieme afzenders en spoofingpogingen op zonder AFRF-rapporten handmatig te moeten analyseren, dankzij gehoste SPF en geautomatiseerde flattening om bezorgingsfouten te verminderen naarmate er nieuwe SaaS-tools worden toegevoegd
• Voorbereiding op naleving: audittrajecten, op rollen gebaseerde toegangscontroles en ondersteuning voor Google, Microsoft, PCI DSS, AVG en overheidsvoorschriften voor afzenders

Veelgestelde Vragen

Wat is een DMARC-foutmelding precies?

Een bijna realtime foutmelding die wordt gegenereerd wanneer een afzonderlijke e-mail niet voldoet aan de authenticatiecontroles die zijn gedefinieerd in uw DMARC-beleid en foutopties. Deze melding bevat details op berichtniveau, in tegenstelling tot geaggregeerde rapporten, die een overzicht geven van de activiteit van alle berichten over een periode van 24 uur.

Waarin verschilt RUF van RUA?

RUA biedt dagelijks een domeinbreed overzicht in XML dat alle berichten omvat. RUF werkt bijna in realtime voor afzonderlijke mislukte berichten in AFRF-formaat (RFC 6591, een uitbreiding van ARF in RFC 5965), bevat berichtspecifieke details en kan PII bevatten. RUA doet dat niet.

Hoe schakel ik deze rapporten in?

Voeg ruf=mailto:[email protected] toe aan je DMARC TXT-record op _dmarc.jouwdomein.com. Voeg fo=1 toe om een rapport te ontvangen wanneer SPF of DKIM faalt. Stuur rapporten door naar een beveiligd platform in plaats van naar een standaard inbox.

Ik heb RUF geïnstalleerd, maar er gebeurt helemaal niets. Werkt het niet?

Niet per se. Veel providers versturen om privacyredenen geen RUF, en er wordt geen rapport gegenereerd wanneer berichten worden doorgestuurd. Als er geaggregeerde RUA-rapporten binnenkomen, is uw registratie waarschijnlijk correct. Raadpleeg de tabel met oplossingen voor andere mogelijke oorzaken.

Sturen alle e-mailproviders DMARC-foutrapporten?

Nee. Gmail en Microsoft 365 doen dit over het algemeen niet, met een beroep op de privacy van gebruikers. De dekking is beperkt tot ontvangers die RUF-ondersteuning hebben geïmplementeerd, doorgaans bepaalde e-mailgateways van bedrijven, internetproviders en onafhankelijke e-mailservers. Dit is een belangrijke beperking.

Is het veilig om DMARC-foutmeldingen te ontvangen?

Ze kunnen persoonsgegevens bevatten, zoals onderwerpregels, e-mailadressen van ontvangers en headers. Als deze berichten zonder de nodige controles worden ontvangen, kan dit leiden tot verplichtingen op grond van de AVG en de CCPA. Het is het veiligst om ze door te sturen naar een beveiligd platform met PGP-versleuteling, op rollen gebaseerde toegang en vastgestelde bewaartermijnen.

Wat doet de `fo`-tag?

Het staat voor „Failure Options“ en bepaalt wanneer ontvangers een rapport genereren. Bij fo=0 (standaard) moeten zowel SPF als DKIM mislukken. Bij fo=1 wordt bij beide mislukkingen een rapport verzonden. fo=d wordt alleen geactiveerd bij een DKIM-fout; fo=s alleen bij een SPF-fout.

• Over
• Laatste berichten

Milena Baghdasaryan

Content-specialist bij PowerDMARC

Milena is een ervaren schrijfster en content creator met meer dan 7 jaar ervaring in het creëren van boeiende content over IT, cyberbeveiliging, virtuele evenementen en meer. Ze heeft bewezen werk van hoge kwaliteit af te leveren voor internationale tijdschriften en is afgestudeerd aan prestigieuze instellingen zoals New York University Abu Dhabi, UWC China en het Europacollege.

Laatste berichten van Milena Baghdasaryan (Bekijk alle berichten)

• Dynamische SPF versus automatische SPF versus gehoste SPF: welke oplossing zorgt er nu echt voor dat je SPF-record correct is? - 25 augustus 2026
• 'Beantwoorden' versus 'Allen beantwoorden': omgangsvormen en veiligheidsrisico’s - 14 augustus 2026
• DMARC-foutmeldingen (RUF): wat ze zijn, hoe ze werken en hoe je ze veilig kunt inschakelen - 11 augustus 2026