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 opmerkingen

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!

15 dagen op proef Boek een demo

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 u 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.
e-mail	Het e-mailadres waar samengevoegde rapporten naartoe worden gestuurd.
begindatum	De begindatum van de rapportageperiode.
einddatum	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.

Yunes Tarada

Expert domein- en e-mailbeveiliging bij PowerDMARC

Yunes is een Operations Team Lead bij PowerDMARC met expertkennis in e-mailverificatie en -beveiliging. Yunes is een Microsoft-gecertificeerde Azure Administrator Associate met certificeringen in CompTIA A+ en nog veel meer.

Laatste berichten van Yunes Tarada (Bekijk alle berichten)

SPF Neutraal Mechanisme uitgelegd: Wanneer en hoe te gebruiken - 23 juni 2025
DKIM domein uitlijning mislukt - RFC 5322 oplossingen - 5 juni 2025
DMARCbis uitgelegd - wat verandert er en hoe bereid je je voor? - 19 mei 2025

Wat is SMTP TLS-rapportage (TLS-RPT)?