Wat is SMTP TLS-rapportage (TLS-RPT)?
door
Laatst bijgewerkt: 11 leestijd: 11 minuten
Omdat organisaties steeds meer vertrouwen op e-mail als primair communicatiemiddel, kan het belang van het versterken van deze kanalen tegen potentiële bedreigingen niet genoeg worden benadrukt. Transport Layer Security(TLS) zorgt voor de vertrouwelijkheid en integriteit van gegevens die over netwerken worden verzonden.
SMTP TLS Reporting (TLS-RPT) is een cruciaal protocol dat naast MTA-STS werkt om ervoor te zorgen dat uw e-mails veilig worden afgeleverd. Door gedetailleerde feedback te geven over problemen met de e-mailaflevering, helpt TLS-RPT domeineigenaars de integriteit en vertrouwelijkheid van hun communicatie te behouden. In deze uitgebreide handleiding onderzoeken we wat SMTP TLS Reporting is, hoe het werkt en waarom het essentieel is voor uw e-mailbeveiligingsstrategie."
Verschillende protocollen helpen bij het versleutelen van SMTP-berichtkanalen om te voorkomen dat cyberaanvallers e-mailcommunicatie kunnen onderscheppen. Hieronder vallen STARTTLS, DANE en MTA-STS. Wanneer versleutelingspogingen mislukken bij het gebruik van deze protocollen, kan het echter gebeuren dat je e-mail niet wordt afgeleverd. TLS-RPT (zoals beschreven onder RFC 8460) biedt een feedbackmechanisme om deze mislukte afleverpogingen te rapporteren.
We raden ten zeerste aan om TLS-RPT te gebruiken in combinatie met de MTA-STS protocol. Laten we eens begrijpen hoe deze protocollen samenwerken om de e-mailbeveiliging.
Belangrijkste Conclusies
- De beveiliging van e-mail kan aanzienlijk worden verbeterd door protocollen als TLS-RPT en MTA-STS te implementeren.
- TLS-RPT biedt essentiële feedback over problemen met e-mailaflevering in verband met TLS-encryptie, zodat domeineigenaren hun e-mailkanalen effectief kunnen bewaken.
- STARTTLS-, DANE- en MTA-STS-protocollen werken samen om veilige e-mailcommunicatie te garanderen, waardoor het risico op cyberaanvallen afneemt.
- Het instellen van een TLS-RPT record bestaat uit het publiceren van een TXT record in je DNS instellingen op een specifiek subdomein.
- Het herkennen en aanpakken van TLS-coderingsfouten is essentieel voor het behouden van de bezorgbaarheid en beveiliging van e-mail.
Wat is TLS-RPT?
TLS-RPT (Transport Layer Security Reporting) is een standaard voor het rapporteren van problemen bij de aflevering van e-mails als een e-mail niet is versleuteld met TLS. Het belang ervan voor e-mailverificatie gaat hand in hand met de reden voor het inschakelen van TLS-encryptie voor e-mails.
TLS-encryptie zorgt ervoor dat elke e-mail die naar u wordt verzonden, veilig wordt afgeleverd. Als de verbinding niet veilig is, worden e-mails vaak niet afgeleverd. TLS-RPT maakt het mogelijk voor domeineigenaren om e-mailaflevering en verbindingsfouten te controleren. De rapporten kunnen informatie bevatten over:
- Problemen met MTA-STS beleidsafhandeling
- Reden en type van mislukte levering
- IP-adres van verzendende en ontvangende e-mail transfer agents
- Totaal aantal succesvolle en mislukte TLS-verbindingssessies
Dit biedt inzicht in je e-mailkanalen en de mogelijkheid om deliverabilityproblemen sneller aan te pakken.
Vereenvoudig SMTP TLS rapportage met PowerDMARC!
Hoe werkt TLS-rapportage?
In SMTP e-mailcommunicatie is TLS-encryptie "opportunistisch". Dit betekent dat als er niet over een versleuteld kanaal kan worden onderhandeld, de e-mail nog steeds in een onversleuteld (platte tekst) formaat wordt verzonden. In feite ondersteunden SMTP e-mailprotocollen bijna 4 decennia geleden geen TLS-encryptie. Het moest later worden toegevoegd in de vorm van het STARTTLS commando.
Het commando STARTTLS wordt alleen gegeven in SMTP communicatie als beide zijden TLS encryptie ondersteunen. Anders wordt de e-mail nog steeds in platte tekst verzonden.
Om af te komen van opportunistische versleuteling in SMTP is MTA-STS geïntroduceerd (RFC 8461). Het MTA-STS protocol zorgt ervoor dat e-mails worden versleuteld voordat ze worden afgeleverd. Je e-mailserver of Mail Transfer Agent (MTA) onderhandelt met de ontvangende server om te zien of deze het STARTTLS commando ondersteunt. Als dat het geval is, wordt de e-mail versleuteld met TLS en afgeleverd. Anders mislukt de aflevering.
Stap voor stap uitleg over hoe TLS-RPT werkt
1. Het TLS-handshake-proces begrijpen
Transport Layer Security handshake (TLS handshake) is het proces van het opzetten van een beveiligde verbinding tussen twee communicerende Mail Transfer Agents (MTA's). Dit proces omvat de volgende stappen:
- De e-mail versturende MTA stuurt een "Client Hello" bericht naar de ontvangende MTA. Dit bericht bevat nuttige parameters zoals TLS-versies en cipher suites.
- De e-mail ontvangende MTA ontvangt dit bericht en antwoordt met een "Server Hello" bericht. Dit bevat de geselecteerde TLS-versie en cipher suite.
- Na het initiëren van de TLS handdruk, stuurt de ontvangende MTA zijn SSL/TLS certificaat dat is uitgegeven door een vertrouwde CA (Certificate Authority). Dit certificaat bevat de openbare sleutel.
- Beide communicerende MTA's wisselen veilig hun cryptografische sleutels uit en zetten een TLS-versleutelde verbinding op. Dit zorgt voor een veilige e-mailcommunicatie tussen beide partijen.
2. Mislukte TLS-handdrukscenario's
TLS-handshakes kunnen om verschillende redenen mislukken:
- Certificeringsfouten: Verlopen certificaten of certificaten uitgegeven door niet-vertrouwde certificeringsinstanties kunnen leiden tot mislukte TLS-handshake.
- Versie incongruenties: Als er een mismatch is tussen de TLS-versies die worden ondersteund door de verzendende en ontvangende MTA's, kan dit leiden tot een mislukte handshake.
- STARTTLS mislukkingen: Als het STARTTLS commando niet correct is geïmplementeerd, kan het opnieuw leiden tot een TLS encryptie mislukking.
- MTA-STS afdwingen: Als de e-mailontvanger zijn MTA-STS-beleidsmodus heeft ingesteld op "afdwingen", kan een mislukte TLS-handdruk leiden tot afwijzing van het bericht.
3. Rapportage en levering
Wanneer er fouten optreden in TLS-codering, genereert de verzendende server een TLS-RPT-rapport en stuurt dit naar de domeineigenaar voor verdere evaluatie en probleemoplossing.
Inhoud van het verslag
Details verzendende server: IP-adres en domeinnaam van de afzender.
Details ontvangende server: Het domein van de ontvanger en informatie over de e-mailserver.
Fout beschrijving: Type en details van de fout (bijv. certificaatfout, protocolafwijking).
Tijd van falen: Tijdstempel waarop het probleem zich voordeed.
Beleidsmodus: Of het domein in de modus "testen" of "afdwingen" staat.
Rapportage levering
Deze TLS-rapporten worden in JSON-indeling verzonden naar het e-mailadres dat is opgegeven in het TLS-RPT DNS TXT-record van de domeineigenaar.
Rol van opportunistische versleuteling in SMTP
SMTP gebruikt traditioneel opportunistische encryptie. Dit betekent dat het TLS probeert te gebruiken, maar terugvalt naar onversleutelde aflevering als de ontvangende MTA TLS niet ondersteunt.
Maar opportunistische versleuteling heeft één grote beperking. Bij dit type versleuteling dat geen mandaat stelt, kunnen e-mails in platte tekst of cleartext (in een onversleuteld formaat) worden verzonden als TLS-versleuteling mislukt. Zulke onversleutelde berichten zijn kwetsbaar voor onderschepping.
Hoe MTA-STS en TLS-RPT samenwerken
Mail Transfer Agent Strict Transport Security (MTA-STS) en TLS-RPT zijn complementaire protocollen in het e-mailverificatie ecosysteem. Terwijl MTA-STS ervoor zorgt dat de verzendende MTA TLS moet gebruiken voor aflevering en e-mails moet weigeren als de versleuteling mislukt,
TLS-RPT stelt domeineigenaren in staat om mislukte TLS-handshakes te controleren en problemen op te lossen. Wanneer ze samen worden geïmplementeerd, kunnen ze het onderscheppen van berichten tijdens het transport voorkomen en problemen met de bezorgbaarheid van e-mail tot een minimum beperken.
Relatie tussen DANE en TLS-RPT
DNS-gebaseerde Authenticatie van Named Entities (DANE) is een protocol waarmee domeineigenaars TLS-certificaten kunnen opgeven die via DNSSEC zijn geverifieerd om man-in-the-middle-aanvallen te voorkomen. Terwijl TLS-RPT TLS-fouten controleert, zorgt DANE ervoor dat alleen vertrouwde certificaten worden gebruikt. Hierdoor voorkomt DANE actief dat aanvallers TLS downgrade en certificate spoofing aanvallen uitvoeren, waardoor de integriteit van e-mailcommunicatie behouden blijft.
Waarom hebt je een SMTP TLS-rapportage nodig?
Domeineigenaren moeten op de hoogte blijven van problemen met e-mailaflevering als gevolg van storingen in TLS-codering voor e-mails die zijn verzonden vanaf een domein met MTA-STS. TLS-rapportage maakt dit mogelijk door deze informatie te verstrekken.
- Beveiliging e-mail: De risico's van onversleutelde e-mailcommunicatie benadrukken (bijv. onderschepping, man-in-the-middle-aanvallen).
- Naleving: Vermeld hoe TLS-RPT organisaties helpt te voldoen aan wettelijke vereisten voor gegevensbescherming.
- Leverbaarheid: Uitleggen hoe TLS-RPT de bezorgbaarheid van e-mail verbetert door encryptieproblemen te identificeren en op te lossen.
Stappen om TLS-RPT in te stellen
U kunt TLS-rapportage voor uw domein inschakelen door een TXT-record voor TLS-RPT aan te maken en dit in uw DNS te publiceren. Dit record moet gepubliceerd worden op het subdomein smtp.tls.uwdomein.com
Stap 1: Een TLS-RPT record genereren (met behulp van een TLS-RPT recordgenerator)
U kunt aanmelden gratis aanmelden bij PowerDMARC en onze TLS-RPT recordgenerator gebruiken om je record te maken.
Stap 2: Voer je e-mailadres voor rapportage in
Voer een e-mailadres in waarop u uw SMTP TLS-rapporten wilt ontvangen.
Stap 3: publiceer het TLS Record op uw DNS
U kunt contact opnemen met uw domeinregistrar om een nieuw TXT-record aan te maken voor TLS-RPT. Als u uw eigen DNS beheert, bewerkt u uw DNS-instellingen om het record op te nemen.
Syntaxis en voorbeeld van TLS-RPT-record
Syntax: v=TLSRPTv1; rua=mailto:[email protected];
Laten we de 2 componenten van de geleverde TLS-record uitsplitsen:
- v=TLSRPTv1: Deze tag specificeert de versie van het TLS-RPT protocol dat wordt gebruikt. In dit geval, "TLSRPTv1 de eerste versie van het protocol aan.
- rua=mailto:[email protected]: rua staat voor "Reporting URI(s) for Aggregate Data". Deze tag specificeert waar de mailserver van de ontvanger de geaggregeerde TLS-rapporten naartoe moet sturen.
Je kunt meer dan één bestemming configureren voor het ontvangen van je rapporten. Voor meerdere bestemmingen, scheid je elke invoer met een komma (,). Je kunt "mailto:" gebruiken om een e-mailadres op te geven voor deze stap, of de MTA instrueren om rapporten via POST naar eindpunt-URL's te sturen door "https:" te gebruiken in het rua= veld. Als je "https:" zorg er dan voor dat het veld de URL definieert naar een webserver met HTTPS en een geldig certificaat. Zowel "mailto:" als "https:" kunnen ook worden gebruikt in één record, gescheiden door een komma.
Voorbeeld: v=TLSRPTv1; rua=mailto:[email protected],https://tlsreport.example.com;
Opmerking: In de praktijk zou je "uwdomein.nl" vervangen door de domeinnaam waarop u deze rapporten wilt ontvangen.
TLS-RPT JSON-rapporten begrijpen
Structuur van een TLS-RPT JSON-rapport
TLS-rapporten worden in JSON-formaat verstuurd. Hieronder staat een voorbeeld van hoe een JSON TLS-rapport eruit zou kunnen zien:
{
"organization-name": "Organization Inc.",
“date-range”: {
"start-datetime": “2020-10-22T00:00:00Z”,
"eind-datum-tijd": “2020-10-22T23:59:59Z”
},
"contact-info": "[email protected]",
"report-id": “2020-10-22T00:00:00Z_domain.com”,
"Beleid": [
{
“policy”: {
"beleidstype": "sts",
"policy-string": [
"versie: STSv1",
"modus: testen",
"mx: mx.domain.com",
"mx: mx2.domain.com",
"mx: mx3.domain.com",
"max_age: 604800"
],
"policy-domain": "domain.com".
},
“summary”: {
"totaal-succesvolle-sessie-telling": 15,
"Totaal aantal mislukte sessies": 0
}
Belangrijke velden en hun betekenis
Hier is de uitsplitsing van de belangrijkste velden in dit JSON TLS-rapport:
| Velden | Beschrijving |
|---|---|
| organisatie | De domeinorganisatie die eigenaar is van het TLS-RPT record. |
| Het e-mailadres waar samengevoegde rapporten naartoe worden gestuurd. | |
| begindatum | De begindatum van de rapportageperiode. |
| end_date | De einddatum van de rapportageperiode. |
| beleid | Een matrix van beleidsobjecten die de beleidsregels beschrijven die tijdens de rapportageperiode zijn toegepast. |
| beleid | Bevat informatie over het toegepaste beleid. |
| beleidstype | Specificeert het type beleid |
| beleidsring | Specificeert de beleidsstring geassocieerd met het beleid |
| stand | Specificeert de MTA-STS beleidsmodus (Afdwingen/Testen) |
| samenvatting | Bevat samenvattende informatie over de sessies die geprobeerd zijn. |
| totaal_geslaagde_sessie_aantal | De totale telling van succesvol opgezette TLS-sessies. |
| totaal_storing_sessie_aantal | De totale telling van mislukte TLS-sessies. |
| storing_gegevens | Een array van objecten die details geven over specifieke fouten. |
| reden | Een tekenreeks die de reden van de mislukking aangeeft (bijv. "certificate_expired"). |
| tel | Het aantal sessies dat mislukte om een specifieke reden. |
TLS-RPT JSON-rapportindeling en gegevensinterpretatie
Metagegevens rapport
{
"organization-name": "Verzendende MTA Organisatie",
“date-range”: {
"start-datetime": “2025-02-25T00:00:00Z”,
"eind-datum-tijd": “2025-02-25T23:59:59Z”
},
"rapport-id": “unique-report-id-12345”
}
Dit gedeelte van uw JSON-rapport bevat basisinformatie zoals de naam van de organisatie van de afzender van de e-mail, de begindatum en -tijd, de einddatum en -tijd en de unieke ID voor het gegenereerde TLS-rapport.
Beleidsdetails
“policy”: {
"beleidstype": "sts",
"policy-string": "mode: enforce; mx: mail.example.com; max_age: 604800;"
}
Dit gedeelte beschrijft de MTA-STS beleidsmodus die geïmplementeerd is, in dit geval is dat de modus Enforce, maar het kan ook ingesteld worden op de modus Testing.
Details
"failure-details": [
{
"resultaat-type": "certificate-expired",
"sending-mta": "smtp.example.org",
"receiving-mta": "mail.example.com",
"Faalreden": "TLS-handshake mislukt vanwege verlopen certificaat".
}
]
Dit gedeelte is het meest cruciale deel van uw TLS-rapport, waarin de beweegredenen voor encryptie en mogelijke mislukkingen bij de aflevering gedetailleerd worden weergegeven. In dit geval geeft het voorbeeld aan dat een verlopen certificaat de oorzaak is van de mislukte TLS-handdruk. Dit speelt een belangrijke rol bij foutdetectie tijdens mislukte TLS-handshakes en bevordert snelle probleemoplossing voor veilige TLS-communicatie.
Fouten in TLS-codering Redenen en probleemoplossing
Er kunnen verschillende redenen zijn voor mislukte TLS-versleuteling. Naast een gebrek aan ondersteuning voor encryptie aan beide kanten, kunnen meer sinistere redenen zoals een SMTP downgrade aanval leiden tot het mislukken van een TLS-verbinding. Maar domeineigenaren willen graag op de hoogte zijn van de mislukte levering. TLS-rapportage (TLS-RPT) is een protocol dat u op de hoogte stelt. Bij mislukte aflevering ontvangt u uw TLS-rapport in een JSON-bestandsindeling op het e-mailadres dat is gedefinieerd in uw TLS-RPT record. Hieronder staan enkele veelvoorkomende redenen voor mislukte codering en tips voor het oplossen van problemen:
1. Certificaatkwesties
certificaat_verlopen
Het certificaat van de externe server is verlopen. Dit maakt het onbetrouwbaar voor encryptie. In dit geval moet je het certificaat vernieuwen.
certificaat_niet_geldig
Het certificaat van de externe server is nog niet geldig. Dit kan komen door een onjuiste servertijd of voortijdig gebruik van het certificaat. In dit geval kunt u het beste contact opnemen met uw certificaatleverancier.
certificaat_herroepen
Het certificaat van de externe server is ingetrokken door de certificeringsinstantie vanwege veiligheidsredenen. In dit geval kunt u het beste contact opnemen met uw certificaatleverancier.
geen_geldige_handtekening
De certificaatketen van de externe server wordt niet vertrouwd door de mailserver of client van de afzender, wat wijst op een potentieel veiligheidsrisico. In dit geval kunt u het beste contact opnemen met uw certificaatleverancier.
niet-ondersteund_certificaat
Het certificaat van de server op afstand gebruikt versleutelingsalgoritmen of sleutellengtes die niet worden ondersteund door de mailserver van de verzender, waardoor er geen veilige verbinding mogelijk is. In dit geval kunt u het beste contact opnemen met uw certificaatleverancier.
2. Hostnaam en identiteit komen niet overeen
hostnaam_incongruentie
De hostnaam in het certificaat van de server komt niet overeen met de hostnaam van de server waarmee de mailserver van de afzender verbinding probeert te maken. Dit wijst op een mogelijke man-in-the-middle aanval of een configuratieprobleem.
Je kunt de MX records in je MTA-STS beleidsbestand controleren om er zeker van te zijn dat ze overeenkomen met het MX record voor het domein.
3. Handdruk en protocolkwesties
handdruk_fout
Er heeft zich een probleem voorgedaan tijdens de eerste TLS-handshake tussen de mailserver van de verzender en de mailserver van de ontvanger, waardoor het beveiligde kanaal niet tot stand kon worden gebracht. Controleer nogmaals of de SMTP STARTTLS-verbinding tot stand is gebracht. Er kunnen verschillende redenen zijn die bijdragen aan mislukte codering, zoals gebrek aan ondersteuning voor STARTTLS of een TLS downgrade aanval.
4. MTA-STS beleidskwesties
mta_sts_policy_not_found
Deze fout treedt op wanneer de mailserver van de verzender geen MTA-STS-beleid kan vinden voor het domein van de ontvanger. Controleer je MTA-STS beleidsbestand. Je moet je MTA-STS record controleren om er zeker van te zijn dat het correct is gepubliceerd.
mta_sts_policy_invalid
Deze fout treedt op wanneer het MTA-STS beleid gevonden in DNS voor het domein van de ontvanger ongeldig is, fouten bevat of niet voldoet aan de MTA-STS specificatie. Controleer je MTA-STS beleidsbestand. Geef een geschikte MTA-STS beleidsmodus op. Dit kan zijn Geen, Afdwingen of Testen. Hiermee worden verzendservers geïnstrueerd over hoe om te gaan met e-mails die een mislukte validatie van het MTA-STS-beleid ondergaan.
mta_sts_policy_fetch_error
Deze fout treedt op wanneer de mailserver van de verzender een foutmelding krijgt bij het ophalen van het MTA-STS-beleid uit de DNS-records van het domein van de ontvanger. Je moet de MTA-STS records in je DNS valideren om er zeker van te zijn dat de record syntax correct is.
mta_sts_verbinding_storing
Deze fout treedt op wanneer de mailserver van de verzender een beveiligde verbinding probeert op te zetten met MTA-STS, maar faalt om redenen zoals niet-vertrouwde certificaten, niet-ondersteunde cipher suites of andere TLS-problemen. U moet de geldigheid van uw certificaat controleren en ervoor zorgen dat het certificaat up-to-date is met de nieuwste TLS-standaard.
mta_sts_invalid_hostname
Deze fout treedt op wanneer de hostnaam van de mailserver van de ontvanger, zoals gespecificeerd in het MTA-STS beleid, niet overeenkomt met de werkelijke hostnaam van de server. Je moet de MX records in je MTA-STS beleidsbestand controleren om er zeker van te zijn dat ze overeenkomen met het MX record voor het domein.
Beste praktijken voor de implementatie van TLS-RPT
TLS-rapporten regelmatig controleren
TLS-rapporten moeten regelmatig worden gecontroleerd om ervoor te zorgen dat u geen niet-bezorgde berichten mist. U kunt dit doen door uw mailbox handmatig te controleren op JSON-rapporten of door een rapportanalysetool te gebruiken zoals PowerTLS-RPT.
Zorg ervoor dat het MTA-STS-beleid juist is geconfigureerd
Voor een goede implementatie van TLS-RPT moet je MTA-STS beleid goed geconfigureerd zijn, zonder syntaxfouten. U kunt uw record controleren met onze MTA-STS controleur voor deze stap.
Encryptiestoringen direct aanpakken
Zodra u in uw TLS-rapport encryptiefouten ontdekt, is het belangrijk om snel actie te ondernemen om problemen met de e-mail deliverability in de toekomst te voorkomen.
Gebruik veilige TLS-protocolversies
Het gebruik van alleen de laatste en ondersteunde TLS-protocolversies is essentieel om ongewenste versleutelingsfouten te voorkomen.
Vereenvoudigde SMTP TLS-rapportage met PowerDMARC
De SMTP TLS-rapportage van PowerDMARC is gericht op het verbeteren van uw beveiliging terwijl uw leven eenvoudiger wordt met een gehoste service.
Vertaalde TLS-rapporten
Uw complexe TLS-RPT JSON-rapporten worden omgezet in vereenvoudigde informatie die u in enkele seconden kunt doorbladeren of in detail kunt lezen.
Problemen met automatisch detecteren
Het PowerDMARC-platform lokaliseert en belicht het probleem waarmee je te maken hebt, zodat je het kunt oplossen zonder tijd te verspillen.
Er is niet één ding dat ik goed vind aan het PowerDMARC platform, ze hebben een eenvoudig te gebruiken en te begrijpen lay-out met wat ik zou noemen volledige functies die gehoste DMARC controle mogelijk maken, SPF-afvlakkingDe mogelijkheid om SPF gemakkelijk uit te breiden om de specifieke kenmerken van het record te inspecteren en zelfs volledige ondersteuning voor MTA-STS en TLS-RPT!
Dylan B (bedrijfseigenaar)
Veelgestelde vragen over beveiliging van transportlagen
- Waar staat TLS voor?
TLS staat voor Transport Layer Security.
- Wie geeft TLS-certificaten uit?
Certificaatautoriteiten (CA's) kunnen TLS-certificaten uitgeven. Het proces voor de uitgifte van het certificaat omvat de verificatie van de identiteit van de certificaathouder. Na succesvolle identificatie wordt het certificaat uitgegeven.
- Waarom heb ik een TLS-certificaat nodig?
TLS-certificaten spelen een cruciale rol bij het beveiligen van communicatie via het internet. Ze helpen bij het versleutelen van gevoelige informatie die wordt uitgewisseld tussen communicerende webservers. Enkele van de meest gebruikte toepassingen zijn het beveiligen van e-mailcommunicatie en HTTPS.
- Wat is de huidige TLS-standaard?
TLS 1.3 is de nieuwste versie van Transport Layer Security. TLS-RPT kan geïmplementeerd worden met elke versie van TLS. Dit kunnen oudere versies van het protocol zijn of toekomstige versies. De versie wordt meestal bepaald door criteria zoals de mogelijkheden van de communicerende servers.
Aanvullende bronnen
Expert domein- en e-mailbeveiliging bij PowerDMARC
Yunes is teamleider Operations bij PowerDMARC en heeft expertise in e-mailauthenticatie en -beveiliging. Hij is een door Microsoft gecertificeerde Azure Administrator Associate en beschikt over certificeringen zoals CompTIA A+ en vele andere.
Laatste berichten van Yunes Tarada (Bekijk alle berichten)
