DMARC is een standaard e-mail authenticatie protocol dat, wanneer geconfigureerd bovenop bestaande SPF en DKIM records, u helpt bij het bevestigen of één van beide of beide authenticatie controles zijn mislukt. Stel dat iemand een e-mail verstuurt namens uw bedrijf en deze DMARC faalt, dan kunt u een autoritatieve actie ondernemen. DMARC is ontworpen om spam en phishing tegen te gaan door bedrijven te helpen met e-mailbeveiliging. Een van de hoofddoelen is bedrijven te helpen hun merken te beschermen en hun reputatie hoog te houden. DMARC beschermt e-mails in transit en helpt spoofing- en phishingaanvallen te voorkomen door berichten te weigeren die niet aan bepaalde normen voldoen. Mailservers kunnen ook berichten rapporteren die zij van andere mailservers ontvangen om de afzender te helpen eventuele problemen op te lossen.

De bescherming van uw e-mails is belangrijk om uw klanten te beschermen tegen cybercriminelen die hun persoonlijke gegevens zouden kunnen stelen. In deze blogpost leggen we uit wat het belang is van DMARC en wat u kunt doen om het correct te implementeren voor uw domein.

Waarom zou je DMARC gebruiken?

Als u nog niet zeker bent of u DMARC moet gebruiken, laten we dan een paar voordelen op een rijtje zetten:

  • DMARC gaat over e-mail beveiliging en deliverability. Het biedt robuuste verificatierapportage, minimaliseert phishing en vermindert false positives.
  • Verhoog deliverability en verminder bouncing
  • Ontvang uitgebreide rapporten over de authenticatie van berichten
  • Het DMARC-protocol helpt spammers te identificeren en voorkomt dat nepberichten in inboxen terechtkomen
  • DMARC helpt de kans te verkleinen dat uw e-mails als spam worden aangemerkt of gemarkeerd
  • Geeft u een betere zichtbaarheid en autoriteit over uw domeinen en e-mailkanalen

Wie kan DMARC gebruiken?

DMARC wordt ondersteund door Microsoft Office 365, Google Workspace en andere populaire cloud-gebaseerde oplossingen. DMARC is sinds 2010 een onderdeel van het e-mailverificatieproces. Het doel ervan was het voor cybercriminelen moeilijker te maken om spamberichten vanaf een geldig adres te verzenden en zo de epidemie van phishing-aanvallen te helpen bestrijden. Domeineigenaren van kleine bedrijven, maar ook ondernemingen, worden door deskundigen uit de sector aangemoedigd een DMARC-record aan te maken om instructies te geven over de manier waarop hun e-maildomein moet worden beschermd. Dit helpt op zijn beurt de reputatie en identiteit van hun merk te beschermen. 

Hoe maak je een DMARC record aan voor je domein? 

De stappen om uw domein te configureren met e-mailverificatieprotocollen zijn als volgt: 

  • Maak een SPF record aan en controleer het met een SPF checker om er zeker van te zijn dat het record functioneel is en geen mogelijke syntactische fouten bevat
  • Schakel DKIM verificatie in voor uw domein
  • Stel tot slot uw domein in met DMARC en schakel DMARC-rapportage in door onze DMARC rapport analyzer gratis

DMARC heeft de laatste jaren niet alleen aan belang gewonnen, maar sommige bedrijven streven ernaar het verplicht te maken voor hun werknemers om het verlies van gevoelige gegevens en bronnen te voorkomen. Het is dus tijd dat u de verschillende voordelen in overweging neemt en overstapt op een veiligere e-mailervaring met DMARC. 

DMARC records zijn een samenstel van verschillende mechanismen of DMARC tags die specifieke instructies doorgeven aan e-mail ontvangende servers tijdens de overdracht van e-mail. Elk van deze DMARC tags bevat een waarde die wordt gedefinieerd door de domeineigenaar. Vandaag gaan we bespreken wat DMARC tags zijn en waar elk van hen voor staat. 

Hier zijn alle beschikbare DMARC tags die een domein eigenaar kan specificeren in zijn DMARC record:

DMARC label Type Standaardwaarde Wat betekent het?
v verplicht De v-tag staat voor de DMARC-protocolversie en heeft altijd de waarde v=DMARC1 
pct optionele 100 Deze tag geeft het percentage van e-mails weer waarop de beleidsmodus van toepassing is. Lees meer over DMARC pct tag
p verplicht Deze tag adresseert de DMARC policy mode. Je kunt kiezen uit reject, quarantine, en none. Leer meer over wat is DMARC beleid om duidelijkheid te krijgen over welke mode te selecteren voor uw domein.
sp optionele De beleidsmodus geconfigureerd voor uw hoofddomein(en) Door het subdomeinbeleid te specificeren, wordt de sp tag geconfigureerd om een beleidsmodus voor uw subdomeinen te definiëren. Leer meer over DMARC sp tag om te begrijpen wanneer u deze moet configureren. 
rua Facultatief maar aanbevolen De rua tag is een optionele DMARC tag die het emailadres of de webserver specificeert waar rapporterende organisaties hun DMARC geaggregeerde rua-gegevens

Voorbeeld: rua=mailto:[email protected];

ruf Facultatief maar aanbevolen Op dezelfde manier specificeert het ruf-mechanisme het adres waarnaar de DMARC forensisch ruf rapport moet worden verzonden. Momenteel stuurt niet elke rapporterende organisatie forensische gegevens. 

Voorbeeld: ruf=mailto:[email protected]

voor optionele 0 De fo tag is bedoeld voor de beschikbare failure/forensic rapportage opties waar domeineigenaren uit kunnen kiezen. Als u ruf niet heeft ingeschakeld voor uw domein, kunt u dit negeren. 

De beschikbare opties om uit te kiezen zijn: 

0: er wordt een DMARC failure/forensic report naar u gestuurd als uw e-mail zowel SPF als DKIM alignment faalt

1: er wordt een DMARC failure/forensic report naar u gestuurd wanneer uw e-mail SPF of DKIM alignment faalt

d: er wordt een DKIM foutmelding verstuurd als de DKIM handtekening van de e-mail niet gevalideerd kan worden, ongeacht de uitlijning

s: een SPF failure rapport wordt verstuurd als de e-mail niet door de SPF evaluatie komt, ongeacht de uitlijning.

aspf optionele Deze DMARC tag staat voor de SPF afstemmingsmodus. De waarde kan strict(s) of relaxed(r) zijn.
adkim optionele Op dezelfde manier staat de adkim DMARC tag voor de DKIM afstemmingsmodus, waarvan de waarde ofwel strict(s) of relaxed(r) kan zijn 
rf optionele afrf De DMARC rf tag specificeert de verschillende formaten voor forensische rapportering.
ri optionele 86400 De ri tag adresseert het tijdsinterval in seconden tussen twee opeenvolgende geaggregeerde rapporten die door de rapporterende organisatie naar de domeineigenaar worden gestuurd.

Om direct een record voor DMARC aan te maken, gebruik onze gratis DMARC generator tool. Als u een bestaande record heeft, controleer dan de geldigheid door een DMARC opzoeking.

Meld u vandaag nog aan voor een gratis DMARC proef om deskundig advies te krijgen over hoe u uw domein kunt beschermen tegen spoofers.

Als u als domeineigenaar wilt specificeren wat er moet gebeuren met een e-mail die de authenticatie niet doorstaat, kunnen DMARC records u daarbij helpen. Een bedrijf kan een tekstrecord in de DNS publiceren en aangeven wat er moet gebeuren met e-mails die niet voldoen aan de bronvermelding door te bepalen of de e-mail moet worden afgeleverd, in quarantaine moet worden geplaatst of zelfs helemaal moet worden geweigerd. De DMARC pct tag maakt deel uit van dit record en vertelt een e-mailontvanger welk percentage van berichten onder dit beleid zal worden beïnvloed.

Wat betekent pct in DMARC?

Een TXT record voor elk email authenticatie protocol bevat een hoop mechanismen of tags die instructies geven aan de email ontvangende servers. In een DMARC record is pct een acroniem voor percentage, dat wordt gebruikt om aan te geven op hoeveel procent van de e-mails het DMARC beleid, gedefinieerd door de domeineigenaar, wordt toegepast.

Waarom heb je de DMARC pct tag nodig?

De pct tag is een vaak over het hoofd geziene, maar niettemin effectieve manier om het DMARC beleid van je domein op te zetten en te testen. Een DMARC record met een percentage tag ziet er ongeveer als volgt uit: 

v=DMARC1; p=afwijzing; pct=100; rua=mailto:[email protected];

In het DMARC DNS record hierboven getoond, is het percentage van e-mails waarvoor het DMARC afkeurbeleid van toepassing is 100%. 

De tijd die nodig is voor een domein om van helemaal geen DMARC te gebruiken, naar het gebruik van de meest restrictieve instellingen is een ramp-up periode. Dit is bedoeld om domeinen de tijd te geven om zich comfortabel te voelen met hun nieuwe instellingen. Voor sommige bedrijven kan dit een paar maanden duren. Het is mogelijk voor domeinen om een onmiddellijke upgrade te doen, maar dit is ongebruikelijk vanwege het risico op meer fouten of klachten. De pct tag is ontworpen als een manier om geleidelijk DMARC beleid op te leggen om de uitrolperiode voor online bedrijven te verkorten. De bedoeling is om het eerst in te zetten voor een kleinere batch e-mails voordat het volledig wordt ingezet op de hele mailstroom zoals in het geval hieronder: 

v=DMARC1; p=afwijzing; pct=50; rua=mailto:[email protected];

In dit DMARC DNS record is het afkeurbeleid voor DMARC van toepassing op slechts 50% van de e-mails, terwijl de andere helft van het volume onderworpen is aan een quarantaine beleid voor DMARC, wat het op één na strengste beleid in de rij is. 

Wat zal er gebeuren als je geen pct tag in je DMARC record opneemt?

Bij het aanmaken van een DMARC-record met behulp van een DMARC record generatorzou je ervoor kunnen kiezen om geen pct tag te definiëren en dat criterium leeg te laten. In dit geval is de standaard instelling voor pct ingesteld op 100, wat betekent dat je gedefinieerde policy van toepassing zal zijn op al je emails. Als u dus een beleid wilt definiëren voor al uw e-mailberichten, is het eenvoudiger om het pct-criterium leeg te laten, zoals in dit voorbeeld:

v=DMARC1; p=quarantaine; rua=mailto:[email protected];

Waarschuwing: Als u een afgedwongen beleid voor DMARC wilt, publiceer dan geen record met pct=0

De logica hierachter is simpel: als u een afkeur- of quarantainebeleid in uw record wilt definiëren, wilt u in principe dat het beleid wordt toegepast op uw uitgaande emails. Door je pct op 0 te zetten, doe je je moeite teniet aangezien je policy nu op nul e-mails van toepassing is. Dit is hetzelfde als je policy op p=none zetten. 

Note: Om uw domein te beschermen tegen spoofing-aanvallen en om te voorkomen dat aanvallers zich voordoen als uw domein, zou het ideale beleid moeten zijn DMARC op p=afwijzen; pct=100;

Stap veilig over op DMARC-handhaving door uw DMARC-reis te beginnen met PowerDMARC. Neem een gratis DMARC proef vandaag nog!

Het "sp" attribuut is een afkorting voor "subdomain policy" en is momenteel geen veel gebruikt attribuut. Het staat een domein toe om te specificeren dat een ander DMARC record gebruikt moet worden voor subdomeinen van het gespecificeerde DNS domein. Om het eenvoudig te houden, raden we aan om het 'sp' attribuut weg te laten uit het organisatiedomein zelf. Dit zal leiden tot een fallback default policy die spoofing op subdomeinen voorkomt. Het is belangrijk om te onthouden dat het gedrag van subdomeinen altijd bepaald wordt door het overkoepelende organisatorische beleid. 

Subdomeinen erven het beleid van het hoofddomein tenzij expliciet overruled door een subdomein beleidsrecord. Het 'sp' attribuut kan deze overerving opheffen. Als een subdomein een expliciet DMARC record heeft, zal dit record voorrang hebben op de DMARC policy voor het hoofddomein, zelfs als het subdomein de standaard instelling van p=none gebruikt. Bijvoorbeeld, als een DMARC policy gedefinieerd is voor prioriteit 'all', zal het 'sp' element DMARC verwerking beïnvloeden op subdomeinen die niet onder een specifieke policy vallen.

Waarom heb je de DMARC sp tag nodig?

Als u uw DMARC record heeft als: 

v=DMARC1; p=afwijzen; sp=none; rua=mailto:[email protected];

In dit geval is uw hoofddomein weliswaar beschermd tegen spoofing-aanvallen, maar zijn uw subdomeinen, zelfs als u ze niet gebruikt om informatie uit te wisselen, toch kwetsbaar voor impersonatie-aanvallen.

Als u uw DMARC record heeft als: 

v=DMARC1; p=none; sp=reject; rua=mailto:[email protected];

In dit geval verplicht u zich niet tot een afkeurbeleid op het hoofddomein dat u gebruikt om uw e-mails te verzenden, maar zijn uw inactieve subdomeinen nog steeds beschermd tegen impersonatie. 

Als u wilt dat uw domein- en subdomeinbeleid hetzelfde is, kunt u het sp tag criterium leeg of uitgeschakeld laten bij het maken van een record, en uw subdomeinen zouden automatisch het beleid erven dat op het hoofddomein wordt toegepast. 

In het geval dat u gebruik maakt van onze DMARC record generator tool gebruikt om een DMARC record voor uw domein aan te maken, moet u handmatig de subdomein beleid knop aanzetten en uw gewenste beleid definiëren, zoals hieronder getoond:

 

Na het aanmaken van uw DMARC record is het belangrijk om de geldigheid van uw record te controleren met onze DMARC record opzoekingstool om er zeker van te zijn dat uw record foutloos en geldig is.

Begin uw DMARC-reis met PowerDMARC om de e-mailbeveiliging van uw domein te maximaliseren. Neem uw gratis DMARC proefversie vandaag nog!

Gezien de bedreigingen die online op de loer liggen, moeten bedrijven hun legitimiteit aantonen door gebruik te maken van sterke authenticatiemethoden. Een veelgebruikte methode is DomainKeys Identified Mail (DKIM), een e-mail authenticatietechnologie die gebruik maakt van encryptiesleutels om het domein van de afzender te verifiëren. DKIM is samen met SPF en DMARC is de e-mailbeveiliging van organisaties wereldwijd drastisch verbeterd.

Lees meer over wat is DKIM.

Bij het configureren van DKIM voor uw emails is het bepalen van de DKIM key lengte één van de belangrijkste beslissingen die u moet nemen. In dit artikel nemen wij met u door wat de aanbevolen sleutellengte is voor een betere bescherming en hoe u uw sleutels kunt upgraden in Exchange Online Powershell.

Het belang van het opwaarderen van uw DKIM sleutel lengte

De keuze voor 1024 bit of 2048 bit is een belangrijke beslissing die gemaakt moet worden bij het kiezen van uw DKIM sleutel. PKI (public key infrastructure) maakt al jaren gebruik van 1024 bit DKIM sleutels voor hun beveiliging. Echter, omdat de technologie steeds complexer wordt, zijn hackers hard op zoek naar nieuwe methoden om de beveiliging te ondermijnen. Daarom zijn sleutellengtes steeds belangrijker geworden.

Hackers vinden steeds betere manieren om DKIM sleutels te kraken. De lengte van de sleutel is direct gecorreleerd met hoe moeilijk het is om de authenticatie te breken. Het gebruik van een 2048 bit sleutel biedt een betere bescherming en betere beveiliging tegen huidige en toekomstige aanvallen, wat het belang van het upgraden van uw bitness onderstreept.

Handmatig uw DKIM sleutels upgraden in Exchange Online Powershell

  • Begin met een verbinding met Microsoft Office 365 PowerShell als admin (Zorg ervoor dat uw Powershell-account is geconfigureerd om ondertekende Powershell-scripts uit te voeren)
  • Als DKIM is voorgeconfigureerd, kunt u de sleutels upgraden naar 2048 bits door het volgende commando uit Powershell uit te voeren: 

Rotate-DkimSigningConfig -KeySize 2048 -Identity {Guid van de bestaande Signing Config}

  • Als u DKIM nog niet eerder hebt geïmplementeerd, voert u het volgende commando uit op Powershell: 

New-DkimSigningConfig -DomainName <Domain for which config is to be created> -KeySize 2048 -Enabled $true

  • Voer tot slot het volgende commando uit om te controleren of DKIM met succes is geconfigureerd met een opgewaardeerde bitwaarde van 2048 bits:

Get-DkimSigningConfig -Identity <Domain for which the configuration was set> | Format-List

Note: Zorg ervoor dat u verbonden bent met Powershell tijdens het voltooien van de procedure. Het kan tot 72 uur duren voordat de wijzigingen zijn doorgevoerd.

DKIM is niet voldoende om uw domein te beschermen tegen spoofing en BEC. Verbeter de e-mailbeveiliging van uw domein door configuratie van DMARC voor office 365.

De langverwachte uitrol is eindelijk hier! Microsoft stuurt DMARC RUA aggregate reports naar hun gebruikers en de kans is groot dat je het nog niet gemerkt hebt. Microsoft DMARC aggregate reports worden verstuurd vanaf het volgende email adres: [email protected]. Het ruwe Microsoft DMARC aggregate bestand wordt verstuurd in standaard XML formaat. Microsoft heeft eindelijk DMARC rapportering omarmd, wat in essentie betekent dat nu Hotmail, Outlook, Live, en msn.com gebruikers zullen kunnen genieten van de verschillende voordelen van Microsoft DMARC aggregate data.

Verwerking van Microsoft DMARC geaggregeerde gegevens

PowerDMARC report analyzer parseert de Microsoft DMARC aggregate data in een georganiseerd formaat dat u zou helpen bij het efficiënter verwerken ervan.  

Om gebruikers te helpen profiteren van de voordelen van geaggregeerde rapportgegevens die door Microsoft worden verzonden, is PowerDMARC's DMARC-rapportanalysator vooraf geconfigureerd om hun rapporten rechtstreeks op het platform te ontvangen. Gebruikers hoeven alleen maar hun domeinen toe te voegen aan het PowerDMARC platform en het DMARC DNS record te configureren, terwijl wij de rapporten op een eenvoudige en begrijpelijke manier verwerken en presenteren. Hier vindt u:

  • DMARC-aggregaatgegevens van Hotmail-, Outlook-, Live- en msn.com-adressen van ontvangers, ontleed uit het ruwe XML-bestandsformaat in eenvoudige en leesbare informatie, georganiseerd in tabellen
  • PowerDMARC is vooraf geconfigureerd om RFC-schendingen te omzeilen, zodat wij uw DMARC-gegevens die door Microsoft-servers worden verzonden, kunnen ontvangen en parseren zonder dat u zich daar zorgen over hoeft te maken
  • Registreer meerdere domeinen, bewaak uw e-mailkanalen en voer DNS-wijzigingen direct vanaf het dashboard door met de actieknoppen aan uw vingertoppen
  • Filter resultaten in verschillende categorieën zoals per resultaat, per verstuurbron, per organisatie, per land, geolocatie, en gedetailleerde statistieken of zoekresultaten per domein op de zoekbalk
  • Krijg meer inzicht in de prestaties van uw e-mails en detecteer snel pogingen tot domain spoofing, impersonatie of nep-e-mails die met uw zakelijke Microsoft-domeinen worden verzonden. U kunt ook alle SPF- en DKIM-fouten van uw verzendbronnen analyseren.

Hierboven ziet u een screenshot van onze DMARC geaggregeerde rapporten per organisatie met DMARC RUA gegevens verzonden door Microsoft.

Problemen die u zou kunnen tegenkomen wanneer u zelf Microsoft DMARC Aggregate Reports verwerkt

Microsoft DMARC Aggregate E-mails zijn niet RFC-Compliant

Het voornaamste probleem dat gebruikers ondervinden met deze door Microsoft verzonden e-mails met rapporten, is dat zij niet voldoen aan de RFC-specificaties voor internet-e-mails. Terwijl RFC 5322 hoofdstuk 2.1.1 duidelijk stelt dat een regel van karakters niet langer mag zijn dan 78 karakters, zijn de BASE64 bijlage gegevens in deze Microsoft DMARC geaggregeerde emails een ononderbroken regel zonder de juiste regeleindes die de 78 karakter limiet overschrijdt. De resulterende RFC overtreding is de reden waarom de meeste van deze e-mails in het weigeringslogboek van de gebruiker terecht komen in plaats van in zijn inbox. 

Ruwe XML-bestanden zijn moeilijk te lezen

Net als de DMARC-gegevens die door alle rapporterende organisaties worden verzonden, is het ruwe RUA-bestand in extensible markup language (XML) dat moeilijk te lezen en te begrijpen is.

Vereisten voor het ontvangen van Microsoft DMARC RUA

Om geaggregeerde rapporten voor uw domeinen op outlook.com te ontvangen, moet u ervoor zorgen dat u een geldig PowerDMARC-record op uw DNS hebt gepubliceerd, samen met een gedefinieerd DMARC-beleid. Rapportageorganisaties zullen dan geaggregeerde rapportgegevens naar uw gespecificeerde webserver of e-mailadres sturen. Dit zal u helpen zichtbaarheid en DMARC compliance te krijgen op uw derde partij e-mail leveranciers waar u anders geen controle over heeft. 

Bescherm uw domeinen op Microsoft Office365 en anderen door vandaag nog te beginnen met uw e-mailverificatie. Doe mee met een gratis DMARC proefversie of plan een DMARC demoen ontdek de voordelen van het implementeren van een robuuste e-mailbeveiliging in uw organisatie!