DMARCTechnische Ondersteuning

De 5 meest gemaakte fouten bij de implementatie van DMARC

By september 25, 2020december 17th, 2020No Comments

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 instellen 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 support- en implementatieteams 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-record 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. Ga hier aan de slag om een DMARC-record te publiceren.

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-rapportgenerators 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 domeinverificatie-record in het DNS publiceert.

Dit record geeft aan dat het oké is om DMARC-rapporten over andere domeinen naar hen te sturen. Dit is een noodzakelijke veiligheidsbeperking om DDoS-aanvallen te voorkomen, en het is waarschijnlijk dat Google in de toekomst op deze eis zal controleren.

5. DMARC-syntaxis is ongeldig

Hier zijn enkele punten waarmee u rekening moet houden bij het aanmaken van DNS-records:

  • Vergeet niet 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 het 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, neem contact met ons op. Als u nog niet met uw DMARC-project bent begonnen, kunt u zich hier aanmelden voor een gratis proefabonnement.