DMARC RFC uitgelegd: Een kernstandaard voor moderne e-mailverificatie
door
Laatst bijgewerkt: 6 leestijd: 6 minuten
Belangrijkste Conclusies
- DMARC wordt beschreven in RFC 7489 (een Informational RFC), waarbij de IETF DMARCbis draft bedoeld is om deze te vervangen als een formele Standards Track RFC.
- Het gebruikt de resultaten van SPF en DKIM om de authenticiteit van berichten te verifiëren.
- Domeineigenaren publiceren DMARC-beleid in DNS om de afhandeling van mislukte verificatie te regelen.
- DMARC ondersteunt rapportage, waardoor domeineigenaren inzicht krijgen in e-mailverkeer.
- DMARC beperkt direct domain spoofing en veel phishingpogingen die daarop vertrouwen, maar houdt look-alike domeinen of misbruik van displaynamen niet tegen.
- Toepassing van DMARC versterkt de merkreputatie en e-mail deliverability.
DMARC (Domain-based Message Authentication Reporting and Conformance) is een e-mailauthenticatieprotocol dat is gespecificeerd in RFC 7489 (Informational); de opvolger, de IETF DMARCbis draft, actualiseert en verduidelijkt het protocol en is bedoeld om RFC 7489 te vervangen.
DMARC bouwt voort op SPF (Sender Policy Framework) en DKIM (DomainKeys Identified Mail) om e-maildomeinen te beschermen tegen spoofing, phishing en onbevoegd gebruik. Door een DMARC-beleid in DNS te publiceren, instrueren domeineigenaren ontvangende mailservers hoe om te gaan met berichten die de verificatiecontroles niet doorstaan. Deze technische basis maakt DMARC tot een hoeksteen van moderne e-mailbeveiliging en vertrouwen.
Wat is de DMARC RFC?
IETF publiceerde DMARC als RFC 7489 (Informatief) in maart 2015. Het definieert hoe domeineigenaars DNS-beleid kunnen publiceren om ontvangers te vertellen wat ze moeten doen als een bericht de DMARC-evaluatie niet doorstaat.
Het protocol werd oorspronkelijk ontwikkeld door een industrieconsortium met Google, Microsoft, Yahoo, PayPal en anderen, onder de vlag van DMARC.org. Hun doel was om e-mailfraude te verminderen door het creëren van een gemeenschappelijke manier om authenticatie op domeinniveau te signaleren en af te dwingen; dit werk werd later ingediend bij de IETFdie het als RFC 7489 publiceerde. Hoewel RFC 7489 een Informational RFC is in plaats van een Standards Track document, is het de de facto referentie geworden voor het implementeren van DMARC.
Wat houdt RFC 7489 in?
RFC 7489 definieert het volledige raamwerk voor DMARC. Hoewel het document zelf technisch is, zijn de primaire doelen eenvoudig:
Zorg voor een beleidsmechanisme
Met DMARC kunnen domeineigenaren duidelijke beleidsregels publiceren die ontvangers vertellen wat ze moeten doen met e-mails die niet door de verificatiecontroles komen.
Profiteer van uitgebreide rapportage
DMARC is ook een rapportageprotocol. Dit betekent dat domeineigenaren gegevens kunnen krijgen over welke e-mails door de authenticatie komen en welke niet. Dit helpt hen onderscheid te maken tussen legitieme e-mails en schadelijke e-mails.
E-mailfraude verminderen
DMARC controleert of het RFC5322.From domein overeenkomt met identifiers die zijn geverifieerd via SPF of DKIM. Dit beperkt directe domein-spoofing; het voorkomt geen look-alike domeinen of display-name misleiding en kan worden beïnvloed door indirecte mailstromen.
Voortbouwen op bestaande standaarden
DMARC gebruikt de resultaten van SPF en/of DKIM en voegt daar identifier alignment, beleid (p=) en rapportage (rua/ruf) aan toe.
Technische uitsplitsing van vereisten
DMARC evalueert de afstemming en past beleid toe. Cruciaal is dat het een belangrijke nieuwe vereiste toevoegt: afstemming van identificatoren.
Hoe DMARC SPF- en DKIM-resultaten gebruikt
DMARC controleert niet alleen of SPF of DKIM slaagt, maar vereist ook dat de identifier overeenkomt met het RFC5322.From domein.
SPF Uitlijning
DMARC gebruikt het SPF-geauthenticeerde RFC5321.MailFrom (of HELO) domein en vereist dat het overeenkomt met het RFC5322.From domein. Het moet ten minste een organisatorische overeenkomst zijn in de ontspannen modus (aspf=r, standaard) of een exacte overeenkomst in de strikte modus (aspf=s).
DKIM uitlijning
DMARC gebruikt het DKIM d= domein en vereist dat het overeenkomt met het RFC5322.From domein. Het moet ten minste een organisatorische overeenkomst zijn in de ontspannen modus (adkim=r, standaard) of een exacte overeenkomst in de strikte modus (adkim=s).
Deze afstemmingseis is de superkracht van DMARC. De verificatieresultaten worden direct gekoppeld aan het zichtbare domein van het merk, waardoor een maas in de wet wordt gedicht waarvan aanvallers eerder misbruik maakten.
Beleidsmodi (p=)
Het DMARC-record specificeert een van de drie beleidsregels die ontvangers moeten volgen wanneer een e-mail de DMARC-controles niet doorstaat:
- p=geen: alleen monitoren; rapporten opvragen.
- p=quarantaine: signaal dat falende mail verdacht is (typische afhandeling: spam/junk).
- p=reject: een sterk signaal dat falende mail moet worden geweigerd. Hoewel de RFC lokale uitzonderingen op het beleid toestaat (bijv. voor bekende goede afzenders), houden grote providers zich meestal strikt aan dit beleid voor niet-geauthenticeerde spoofpogingen.
Rapportagefuncties (RUA en RUF)
DMARC biedt nuttige feedback via twee soorten rapporten:
Geaggregeerde rapporten (RUA)
RUA-rapporten zijn machineleesbare XML-samenvattingen (meestal dagelijks) van DMARC-resultaten. Ze bevatten gegevens zoals het verzendende IP-adres, SPF/DKIM-resultaten, uitlijningsgegevens en het aantal berichten. Deze ruwe XML-bestanden zijn echter niet gemakkelijk door mensen te lezen en zijn moeilijk handmatig te analyseren zonder gespecialiseerde tools. De PowerDMARC DMARC-rapportenanalyser automatiseert dit proces en zet complexe gegevens om in intuïtieve grafieken en diagrammen.
Berichtspecifieke storingsrapporten (RUF, vaak "forensisch" genoemd)
Deze zijn optioneel en worden zelden verzonden vanwege de privacy. Veel ontvangers verwijderen ze of schakelen ze uit. DMARCbis documenteert deze zorgen en verwijst naar een afzonderlijk ontwerp voor foutrapportage, waarin RUF-rapporten steeds meer worden afgeschaft.
DMARCbis en komende wijzigingen
Technologiestandaarden veranderen snel en DMARC is daarop geen uitzondering. DMARCbis is de komende bijgewerkte specificatie voor het DMARC protocol, geformaliseerd door de IETF. Het is geïnspireerd door de lessen van de afgelopen jaren en heeft als doel DMARC van een "Informational" RFC te brengen naar een formele "Proposed Standard".
Zie het niet als een revolutie of het opgeven van DMARC, maar als een evolutie. De belangrijkste veranderingen en verduidelijkingen in DMARC zijn onder andere:
p=quarantainegedrag
DMARCbis verduidelijkt de semantiek van quarantaine en richtlijnen voor ontvangers, maar laat ontvangers nog steeds vrij.
Nieuwe voorwaarden en herstructurering
Hoewel gebaseerd op de oorspronkelijke RFC 7489, is DMARCbis geherstructureerd en nu gemakkelijker te lezen voor de gemiddelde gebruiker.
De specificatie is nu opgesplitst in drie afzonderlijke documenten (RFC's). Deze omvatten:
- De hoofddocument
- De geaggregeerde rapportage specificatie
- De storingsmelding specificatie
Sommige termen en zinnen zijn ook gewijzigd voor meer duidelijkheid, bijvoorbeeld:
- "Rapportontvanger" in plaats van "rapportconsument".
- "Beleid voor beoordeling domeineigenaar" in plaats van "DMARC-beleid".
- "Handhaving" voor p=quarantaine en p=afwijzen
- "Monitoring" modus voor p=none
Rapportageproblemen
Doorsturen kan SPF verbreken, terwijl mailinglijsten vaak DKIM verbreken. DMARCbis raadt nu af om een p=reject beleid te gebruiken als mailinglijsten veel voorkomende ontvangers zijn.
De regels voor geaggregeerde rapportering worden ook strengeren het XML-rapportformaat is aangepast aan de nieuwe tags.
RUF ontmoedigen
DMARCbis ontmoedigt het gebruik van RUF-rapporten vanwege privacyproblemen en verwijst naar faalrapporten in een afzonderlijk ontwerp.
DNS Boomwandeling
De oorspronkelijke methode voor het bepalen van het Organisatorische Domein was sterk afhankelijk van de Openbare Suffix Lijst (PSL), die onvolledig kon zijn. DMARCbis specificeert formeel een flexibeler en betrouwbaarder "DNS Tree Walk"-algoritme voor het ontdekken van het toepasselijke DMARC-beleid.
Nieuwe vs. Verwijderde DMARC Record Tags
Sommige DMARC tags zoals "pct," "rf," en "ri" worden volledig verwijderd. In plaats daarvan worden nieuwe DMARC record tags toegevoegd, zoals "np", "psd" en "t".
Belang voor organisaties
Inzicht in de DMARC RFC kan organisaties op verschillende manieren helpen:
Verbeterde naleving
Google, Yahoo, Microsoft en Apple Mail vereisen nu bulkverzenders om een DMARC-record te publiceren, samen met andere controles (SPF/DKIM, uitlijning, lage spampercentages, etc.). Niet-naleving kan ernstige gevolgen hebben voor de bezorgbaarheid van e-mail.
Misconfiguraties vermijden
Een verkeerd begrip van de belangrijkste RFC-concepten, vooral uitlijning, kan leiden tot het blokkeren van legitieme e-mails. Kennis van RFC 7489 kan u helpen problemen op te lossen en uw beleid vanaf het begin correct te configureren.
Om fouten te voorkomen, kun je ook een DMARC Record Generator gebruiken om een geldig beleid te maken. Als je al een record hebt en het alleen nog maar hoeft te controleren, kun je PowerDMARC's DMARC Record Checker gebruiken om te controleren of het correct is gepubliceerd voordat u overgaat op een handhavingsbeleid.
Veel veiligheidsvoordelen
Een goed afgedwongen DMARC-beleid met p=reject is een van de meest effectieve verdedigingen tegen direct domain spoofing, een belangrijke oorzaak van Business Email Compromise en veel phishing-aanvallen. Door DMARC te implementeren, kunt u uw werknemers, klanten en merkreputatie beschermen tegen een breed scala aan op e-mail gebaseerde fraude.
Samenvattend
DMARC RFC biedt een sterk fundamenteel kader voor het beschermen van domeinen tegen e-mailfraude. Het schetst duidelijke, heldere standaarden en richtlijnen voor het instellen en handhaven van DMARC. Als je de regels in de DMARC RFC nauwgezet volgt, kan dit de beveiliging van e-mail verbeteren, de merkreputatie beschermen en de deliverability verbeteren.
Nog beter is dat het implementeren en effectief beheren van DMARC geen handmatig proces hoeft te zijn. Het PowerDMARC-platform vereenvoudigt het hele traject, van snelle installatie tot grondige controle en handhaving.
Neem contact op met de PowerDMARC team vandaag nog en laat de experts uw e-mailbeveiliging deskundig verzorgen!
Veelgestelde Vragen
Wanneer werd RFC 7489 gepubliceerd?
RFC 7489 werd gepubliceerd in maart 2015.
Wie kan DMARC gebruiken?
Elke organisatie of persoon die e-mail verstuurt vanaf een domein kan en zou DMARC moeten gebruiken. Er zijn geen licentiekosten of beperkingen, waardoor het een toegankelijke standaard is voor iedereen om hun domein te beschermen tegen spoofing.
Waarom vereisen grote e-mailproviders DMARC voor bulkverzenders?
De gemiddelde gebruiker kan meestal niet zien of een bericht of e-mail echt of nep is. Postbusaanbieders moeten dus voorzichtig zijn met welke e-mails ze in de primaire inbox laten belanden. DMARC helpt dit probleem aan te pakken. Het stelt verzenders, ontvangers en postbusproviders in staat om samen te werken tegen e-mailfraude. Vanaf februari 2024 eisen Google/Yahoo SPF- of DKIM-authenticatie, DMARC met p=none of sterker, een laag aantal spamklachten en RFC5322.From-afstemming.
Zijn er tools die het instellen en afdwingen van DMARC vergemakkelijken?
PowerDMARC biedt veel van dergelijke tools en services, waaronder DMARC generator, checker, gehoste services en meer!
Shift Lead, Infrastructuur- en e-mailbeveiligingsdeskundige bij PowerDMARC
Ayan Bhuiya heeft meer dan 13 jaar ervaring in cyberbeveiliging en is gespecialiseerd in infrastructuur, bedrijfscontinuïteit, risicomanagement en e-mailbeveiliging. Momenteel is hij Shift Lead bij PowerDMARC. Hij heeft een Postgraduate Diploma in Netwerken en Beveiliging en heeft een bewezen staat van dienst in het leiden van strategische beveiligingsinitiatieven om bedreigingen te beperken en de veerkracht van het bedrijf te garanderen.
Laatste berichten van Ayan Bhuiya (Bekijk alle berichten)
