Op het moment dat phishing-pogingen op een historisch hoogtepunt zijn is er een groeiend bewustzijn van hoe DMARC kan helpen om domeinen te beschermen en e-mail betrouwbaarder te maken. Het is geen geheim dat het uitvoeren van DMARC een complex en intimiderend proces kan zijn. DMARC-projectteams betreden vaak onbekend terrein en maken fouten bij het inzetten van het DNS-gebaseerde protocol. Onze ondersteunings- en implementatie hebben een aantal veelvoorkomende fouten verzameld waar u op moet letten om uw DMARC-project soepeler en succesvoller te laten verlopen.

De 5 meest gemaakte DMARC-fouten

1. DMARC document niet gevonden
Het publiceren van een DMARC-record met een beleid ingesteld om de e-mailstroom niet te verstoren is de eerste stap van de implementatie. Door geen DMARC-record te laten publiceren, blijft u niet alleen in onwetendheid over hoe uw domein buiten uw eigen bewaakte infrastructuur wordt gebruikt, maar maakt u ook geen gebruik van de domeinbescherming die DMARC biedt. Om een DMARC-record te publiceren kunt u hier aan de slag.

2. Beleidshandhaving op actief domein zonder monitoring
Als u alleen een DMARC-record met beleidshandhaving hebt maar geen rapportage om het domein te monitoren (bijv. v=DMARC1; p=reject) mist u de zichtbaarheid die nodig is om uw domeinbescherming te handhaven. Monitoring is de sleutel tot het begrijpen van wie en wat er namens u e-mails stuurt.

3. Specificeren van tags die impliciet zijn
Bijvoorbeeld PCT = 100 is hetzelfde als het niet plaatsen van het paar tag/waarde. Hetzelfde geldt voor rf = afrf, aspf = r, adkim = r. Het toevoegen van deze tags en waarden maakt het record ingewikkelder en neemt meer ruimte in beslag omdat het TXT-record langer wordt.

4. Rapporten naar een ander domein sturen
Rapporten verzenden naar een bestemming met een ander domein in de RUA- en RUF-tags zonder een externe domeinverificatie- record kan leiden tot een beveiligingsrisico. Met name Google controleert niet op deze vereiste, dus u krijgt nog steeds rapporten. Maar andere DMARC Reporters volgen de specificatie-eis om geen rapporten te verzenden naar bestemmingen waarbij het domein in de RUA- en RUF-tags verschillend zijn, tenzij het domein in die tags expliciet het externe domeinverificatierecord in DNS publiceert. Dit record vertelt de wereld dat het goed is om te verzenden DMARC rapporteert over andere domeinen aan hen. Dit is een noodzakelijke beveiligingsbeperking om DDoS-aanvallen te voorkomen en het is waarschijnlijk dat Google in de toekomst op deze vereiste zal controleren.

5. DMARC-syntaxis ongeldig
Hier zijn enkele punten waarmee u rekening moet houden bij het aanmaken van DNS-records:

  • Vergeet niet om een ​​puntkomma tussen tag / waarde-paren te plaatsen.
  • Gebruik de p=none en niet p = monitor. p = monitor was een vroege pre-publicatie DMARC-beleid dat werd vervangen door p=none, het monitoringbeleid.
  • Specificeer de mailto: voor het rapporteringsadres van de inzending.
  • De hostnaam van het DNS TXT-record moet zijn: _dmarc
  • Plaats de p= tag na v=DMARC1 ; het is op die positie vereist.
  • Verwijder aanhalingstekens rond een TXT-record in DNS, hoewel sommige DNS-providers aanhalingstekens accepteren.

dmarcian streeft ernaar om e-mail veiliger te maken door de kennis en het bewustzijn over DMARC te vergroten. Als u hulp nodig heeft bij uw DMARC-project, laat het ons weten als u hulp nodig heeft bij uw DMARC-project. Als u nog niet met uw DMARC-project bent begonnen, kunt u zich hier aanmelden voor een gratis proefabonnement .

Wilt u het gesprek voortzetten? Ga naar het dmarcian- forum