MTA-STS en TLS-RPT instellen: e-mailonderschepping voorkomen

Miljarden e-mails worden dagelijks via het internet verstuurd, en een aanzienlijk deel daarvan wordt nog steeds zonder versleuteling verzonden. Alleen al door die omvang is e-mail een van de meest aantrekkelijke doelwitten voor onderschepping, waarbij berichten tijdens het transport kunnen worden gelezen of gewijzigd zonder dat de afzender of ontvanger dit merkt.

De zwakte zit hem in de manier waarop e-mail wordt afgeleverd. SMTP maakt gebruik van opportunistische versleuteling, waardoor aanvallers het STARTTLS-commando kunnen verwijderen of manipuleren en een verbinding kunnen dwingen terug te vallen op leesbare tekst. Deze SMTP-downgrade-aanvallen openen de deur voor man-in-the-middle-onderschepping, waardoor aanvallers het verkeer kunnen monitoren, gevoelige inhoud kunnen vastleggen of berichten kunnen omleiden via servers die zij beheren.

Neem contact met ons op Een demo boeken

Inhoudsopgave

    1. Mail Transfer Agent-Strict Transport Security (MTA-STS)
    2. Encryptie garanderen met MTA-STS
    3. De anatomie van een MITM-aanval
    4. Het MTA-STS beleidsbestand
    5. Hoe het MTA-STS-beleidsbestand publiceren
    6. MTA-STS DNS-bestand
    7. MTA-STS configureren voor uw domein
    8. CUitdagingen bij de handmatige implementatie van MTA-STS
    9. Hoe u uw MTA-STS-configuratie kunt testen en valideren
    10. Gehoste MTA-STS-services van PowerDMARC
    11. SMTP TLS-rapportage (TLS-RPT)
    12. E-mailverkeer beveiligen met MTA-STS
    13. Veelgestelde Vragen

Mail Transfer Agent-Strict Transport Security (MTA-STS) dicht deze kloof door versleutelde TLS-verbindingen tussen verzendende en ontvangende mailservers verplicht te stellen en levering te weigeren wanneer er geen beveiligd kanaal kan worden opgezet. In plaats van te hopen dat versleuteling wordt gebruikt, dwingt MTA-STS dit af, waardoor het essentieel is voor organisaties die MTA-STS willen opzetten als onderdeel van hun e-mailbeveiligingsstrategie.

encryptie tls

Mail Transfer Agent-Strict Transport Security (MTA-STS)

MTA-STS is, zoals de naam al doet vermoeden, een protocol dat versleuteld transport van berichten tussen twee SMTP-mailservers mogelijk maakt. MTA-STS geeft aan verzendende servers door dat e-mails alleen via een TLS-versleutelde verbinding mogen worden verzonden en helemaal niet mogen worden afgeleverd als er geen beveiligde verbinding tot stand is gebracht via het STARTTLS-commando. Door de beveiliging van e-mails tijdens het transport te verbeteren, helpt MTA-STS bij het beperken van Man-In-The-Middle-aanvallen (MITM), zoals SMTP-downgrade-aanvallen en DNS-spoofing-aanvallen.

Lees Meer

Encryptie garanderen met MTA-STS

E-mail wordt tussen servers verzonden met behulp van SMTP, een protocol dat versleuteling ondersteunt, maar dit niet standaard vereist. Hierdoor ontstaat een opening waardoor berichten nog steeds zonder bescherming kunnen worden verzonden. MTA-STS dicht die kloof door versleutelde verzending verplicht te stellen in plaats van optioneel.

Om te begrijpen hoe versleuteling werkt tijdens het verzenden van e-mails, kunt u zich een mailserver voorstellen die een bericht verstuurt naar [email protected]. De verzendende Mail Transfer Agent (MTA) voert eerst een DNS-query uit om de MX-records voor powerdmarc.com op te halen, waarmee wordt vastgesteld welke mailservers verantwoordelijk zijn voor het ontvangen van het bericht. De verzendende MTA maakt vervolgens verbinding met een van die servers en controleert met behulp van het STARTTLS-commando of deze TLS-encryptie ondersteunt. Als TLS beschikbaar is, wordt de e-mail via een versleutelde verbinding verzonden. Als dat niet het geval is, slaagt de verzendende server er niet in om een beveiligde verbinding tot stand te brengen en kan deze, zonder dwang, terugvallen op het verzenden van het bericht in platte tekst.

MTA-STS verandert dit leveringsgedrag door strikte beveiligingsvereisten af te dwingen tijdens server-naar-servercommunicatie:

MTA-STS instrueert verzendende mailservers om berichten alleen via een TLS-gecodeerde verbinding te bezorgen. Als er geen codering tot stand kan worden gebracht, wordt het bericht helemaal niet bezorgd. Dit voorkomt dat er stilzwijgend wordt teruggevallen op platte tekst, waardoor onderschepping mogelijk wordt.

De ontvangende mailserver moet een geldig TLS-certificaat overleggen en de domeinnaam op dat certificaat moet overeenkomen met het domein dat is gedefinieerd in het MTA-STS-beleid. Dit zorgt ervoor dat de verzendende server communiceert met de juiste bestemming en niet met een host die zich voordoet als een andere.

MTA-STS-beleidsregels worden via HTTPS opgehaald van een beveiligde webserver. Door het beleid via een versleuteld en geauthenticeerd kanaal op te halen, wordt voorkomen dat aanvallers beleidsinstructies tijdens het transport kunnen wijzigen of vervalsen.

Door versleuteling af te dwingen en zowel certificaten als beleidsinstructies te valideren, blokkeert MTA-STS SMTP-downgrade-aanvallen die gebaseerd zijn op het verwijderen of wijzigen van het STARTTLS-commando. Verzendende servers accepteren geen onveilige fallbacks meer wanneer er een veilige verbinding zou moeten bestaan.

gehoste mta sts diensten
gehost MTA STS

MTA-STS wordt geïmplementeerd door een DNS-record te publiceren dat verzendende mailservers opdracht geeft om een beleidsbestand op te halen van een aangewezen subdomein. Het beleidsbestand is toegankelijk via HTTPS, wordt gevalideerd met behulp van TLS-certificaten en bevat de goedgekeurde hostnamen van de mailservers van de ontvanger. Het protocol geeft verzendende SMTP-servers de opdracht om een versleutelde verbinding te vereisen en te controleren of het domein dat op het TLS-certificaat staat vermeld, overeenkomt met het domein dat in het beleidsbestand is gedefinieerd. Als MTA-STS wordt afgedwongen, wordt het bericht helemaal niet afgeleverd als er geen versleuteld kanaal kan worden overeengekomen.

De anatomie van een MITM-aanval

In wezen vindt een MITM-aanval plaats wanneer een aanvaller het STARTTLS-commando vervangt of verwijdert om de beveiligde verbinding terug te draaien naar een onbeveiligde verbinding, zonder TLS-encryptie. Dit wordt een downgrade aanval genoemd. Na het succesvol uitvoeren van een downgrade-aanval, kan de aanvaller ongehinderd toegang krijgen tot de e-mailinhoud en deze bekijken.

Een MITM-aanvaller kan ook de MX-records in het antwoord op de DNS-query vervangen door een mailserver waartoe hij toegang heeft en waarover hij de controle heeft. De mail transfer agent levert in dat geval de e-mail af op de server van de aanvaller, waardoor hij toegang heeft tot de inhoud van de e-mail en ermee kan knoeien. De e-mail kan vervolgens worden doorgestuurd naar de server van de beoogde ontvanger, zonder dat dit wordt ontdekt. Dit staat bekend als een DNS spoofing aanval.

SMTP downgrade aanval

Waarschuwingssignalen

MITM-aanvallen verlopen vaak onopvallend, maar bepaalde patronen kunnen erop wijzen dat er iets mis is tijdens de bezorging van e-mails. Een veelvoorkomend waarschuwingssignaal is onverwachte bezorgingsfouten of vertragingen bij de communicatie met specifieke domeinen, vooral wanneer die domeinen voorheen zonder problemen berichten accepteerden. Een plotselinge toename van TLS-onderhandelingsfouten, terugval naar niet-versleutelde verbindingen of herhaalde STARTTLS-fouten kunnen ook wijzen op interferentie tijdens de verzending.

Een andere indicator is inconsistent mailrouteringsgedrag. E-mails lijken mogelijk via onbekende servers te worden verzonden, of logboeken kunnen verbindingen met hosts weergeven die niet overeenkomen met de gepubliceerde MX-records van de beoogde ontvanger. In meer geavanceerde gevallen komen berichten gewijzigd, ingekort of doorgestuurd via tussenliggende systemen aan zonder duidelijke verklaring.

Detectie is sterk afhankelijk van zichtbaarheid. Door SMTP-verbindingslogboeken te controleren, kunnen herhaalde versleutelingsfouten of certificaatconflicten worden geïdentificeerd. TLS-RPT voegt nog een extra laag toe door rapporten te genereren wanneer servers geen veilige TLS-verbindingen tot stand kunnen brengen, waarbij problemen zoals pogingen tot downgrades, ongeldige certificaten of fouten bij het afdwingen van beleid worden gemarkeerd. 

Al deze signalen helpen bij het opsporen van MITM-activiteiten die anders tijdens de normale e-mailstroom verborgen zouden blijven.

Het MTA-STS beleidsbestand

Het MTA-STS-beleidsbestand is in wezen een eenvoudig tekstbestand, dat er als volgt uitziet:

versie: STSv1
modus: afdwingen
mx: mx1.powerdmarc.com
mx: mx2.powerdmarc.com
mx: mx3.powerdmarc.com
max_age: 604800

Opmerking: het versieveld moet aan het begin van het tekstbestand staan, terwijl de andere velden in elke willekeurige volgorde kunnen worden opgenomen.

Het beleidsbestand maakt gebruik van sleutel-waardeparen, waarbij elke waarde op een aparte regel in het tekstbestand wordt gecodeerd, zoals hierboven weergegeven. De grootte van dit bestand kan oplopen tot 64 KB. De naam van het beleidsbestand moet mta-sts.txt. Beleidsbestanden moeten worden bijgewerkt telkens wanneer u mailservers toevoegt of wijzigt in uw domein.

Opmerking: Als je MTA-STS instelt op de handhavingsmodus, kan het zijn dat sommige e-mails niet worden afgeleverd. Daarom is het aan te raden om de beleidsmodus in plaats daarvan op testen in te stellen en te kiezen voor een lage max_age om er zeker van te zijn dat alles correct werkt voordat je overschakelt naar beleid afdwingen. We raden aan om TLS-RPT ook in te stellen voor je beleid in de testmodus om een melding te krijgen als e-mails in platte tekst worden verzonden. 

MTA-STS-beleid

Hoe het MTA-STS-beleidsbestand publiceren

Om het MTA-STS beleidsbestand te publiceren, moet de webserver die het bestand host:

  • Ondersteuning HTTPS/SSL

    Het beleidsbestand moet worden aangeboden via een webserver met HTTPS om ervoor te zorgen dat het veilig wordt opgehaald door mailservers.

  • Gebruik een certificaat dat is uitgegeven door een vertrouwde certificeringsinstantie.

    Het servercertificaat moet worden ondertekend en gevalideerd door een externe certificeringsinstantie, zodat verzendende MTA's de bron van het beleid kunnen authenticeren.

  • Host het bestand op een speciaal mta-sts-subdomein

    Er moet een openbare webserver worden opgezet met het subdomein mta-sts toegevoegd aan uw domein, dat uitsluitend wordt gebruikt voor het publiceren van het MTA-STS-beleid.

  • Plaats het beleidsbestand in de vereiste map.

    Het beleidsbestand moet de naam mta-sts.txt hebben en worden gepubliceerd in de map .well-known op het subdomein mta-sts.

  • Zorg ervoor dat het beleidsbestand openbaar toegankelijk is via de juiste URL.

    Verzendende MTA's moeten het bestand kunnen ophalen van een locatie met de indeling
    https://mta-sts.yourdomain.com/.well-known/mta-sts.txt zonder authenticatie of omleidingen.

gehost MTA STS

MTA-STS DNS-bestand

Een TXT DNS record voor MTA-STS wordt gepubliceerd op de DNS van je domein om aan te geven dat je domein het MTA-STS protocol ondersteunt en om een signaal te geven voor het verversen van de cache waarden in de MTA's wanneer het beleid wordt gewijzigd. Het MTA-STS DNS record wordt geplaatst op het subdomein _mta-sts zoals in: _mta-sts.powerdmarc.com. Het TXT record moet beginnen met v=STSv1, en de "id" waarde kan maximaal 32 alfanumerieke tekens bevatten, die op de volgende manier worden opgenomen:

 v=STSv1; id=30271001S00T000;

Opmerking: De TXT record id waarde moet bijgewerkt worden naar een nieuwe waarde elke keer als je wijzigingen aanbrengt in het beleid. 

Het MTA-STS DNS Record wordt gebruikt om: 

  • Ondersteuning voor MTA-STS opgeven voor het domein
  • Geef de MTA het signaal om het beleid opnieuw op te halen via HTTPS als het beleid wordt gewijzigd

Merk op dat met het MTA-STS TXT DNS record, het beleidsbestand voor een langere periode kan worden opgeslagen door MTA's zonder dat het beleid opnieuw opgehaald hoeft te worden tenzij het gewijzigd is, terwijl er nog steeds een DNS query wordt uitgevoerd elke keer als er een e-mail wordt ontvangen voor het domein.

MTA-STS configureren voor uw domein

Om MTA-STS in te schakelen voor je domein moet je het volgende doen:

  • Voeg een DNS-record van het type cname toe op mta-sts.example.comgericht naar de webserver met HTTPS-functie die het MTA-STS-beleidsbestand host.

  • Voeg een DNS-record van het type txt of cname toe aan _mta-sts.example.com dat ondersteuning voor MTA-STS specificeert voor jouw domein.

  • Stel een webserver met HTTPS-functie in met een geldig certificaat voor je domein.

  • Schakel SMTP TLS-rapportage in voor uw domein om problemen met de e-mailaflevering te detecteren als gevolg van fouten in TLS-codering.

spf record opzoeken pictogram powerdmarc

Uitdagingen bij handmatige implementatie van MTA-STS

Het handmatig implementeren van MTA-STS omvat meer dan alleen het publiceren van één DNS-record. Het vereist coördinatie van de webinfrastructuur, certificaten, beleidsregels en doorlopend onderhoud, wat verschillende uitdagingen met zich mee kan brengen als dit niet zorgvuldig wordt beheerd.

  • Vereiste voor een HTTPS-compatibele webserver

    MTA-STS-beleidsregels moeten worden gehost op een openbaar toegankelijke HTTPS-server met een geldig TLS-certificaat. Dit vereist het inrichten van infrastructuur, het correct configureren van TLS, het tijdig vernieuwen van certificaten en het waarborgen van hoge beschikbaarheid.

    Oplossing: Organisaties met een beperkte webinfrastructuur kunnen de complexiteit verminderen door gebruik te maken van een gehoste MTA-STS-service die servers en certificaten automatisch beheert.

  • Doorlopend onderhoud van beleidsdossiers

    Elke wijziging in de configuratie van de mailserver vereist een update van het MTA-STS-beleidsbestand. Als het bestand verouderd is, kunnen legitieme e-mails mogelijk niet worden afgeleverd zodra de handhaving is ingeschakeld.

    Oplossing: Gecentraliseerd beleidsbeheer of geautomatiseerde tools zorgen ervoor dat updates onmiddellijk en nauwkeurig worden toegepast.

  • DNS-recordupdates en versiebeheer

    Het MTA-STS TXT-record moet elke keer dat het beleid wordt gewijzigd, worden bijgewerkt met een nieuwe id-waarde. Ontbrekende of onjuiste updates kunnen het vernieuwen van het beleid vertragen en leiden tot inconsistente handhaving.

    Oplossing: Automatisering vermindert het risico op menselijke fouten en zorgt ervoor dat DNS-records in overeenstemming blijven met beleidswijzigingen.

  • Beperkt inzicht in leveringsfouten

    Zonder TLS-RPT kunnen problemen met de levering die verband houden met versleuteling onopgemerkt blijven. Zelfs als TLS-RPT is ingeschakeld, kunnen onbewerkte JSON-rapporten moeilijk te interpreteren zijn zonder gespecialiseerde kennis.

    Oplossing: Rapportageplatforms die TLS-rapporten analyseren en visualiseren, maken het gemakkelijker om storingen op te sporen en snel te reageren.

  • Hogere operationele overheadkosten en coördinatie-inspanningen

    Handmatige implementatie vereist coördinatie tussen DNS-, e-mail- en beveiligingsteams, waardoor het risico op verkeerde configuraties en vertragingen toeneemt.

    Oplossing: Teams moeten evalueren of ze over de tijd en expertise beschikken om MTA-STS op lange termijn te onderhouden, of dat een beheerde aanpak beter aansluit bij hun operationele prioriteiten.

Hoe u uw MTA-STS-configuratie kunt testen en valideren

Testen is een cruciale stap voordat een MTA-STS-beleid in de handhavingsmodus wordt gezet. Zodra handhaving is ingeschakeld, krijgen verzendende servers de instructie om e-mailbezorging te weigeren als er geen beveiligde TLS-verbinding tot stand kan worden gebracht. Zonder de juiste validatie kunnen configuratiefouten leiden tot onbedoeld verlies van berichten, waardoor zorgvuldig testen essentieel is voor het handhaven van betrouwbare e-mailbezorging.

  • DNS-propagatiecontroles

    Controleer na het publiceren van het MTA-STS TXT-record en de bijbehorende DNS-vermeldingen of deze correct worden omgezet door openbare DNS-resolvers. Onvolledige of vertraagde propagatie kan ertoe leiden dat verzendende servers vertrouwen op verouderde of in de cache opgeslagen beleidsregels, wat resulteert in inconsistent gedrag tijdens de levering.

  • Toegankelijkheid van beleidsbestanden

    Controleer of het MTA-STS-beleidsbestand toegankelijk is via HTTPS op de verwachte locatie op het mta-sts-subdomein. Het bestand moet bereikbaar zijn zonder omleidingen, authenticatievereisten of certificaatfouten. Elke onderbreking in de toegang kan ervoor zorgen dat verzendende servers het beleid niet kunnen ophalen.

  • TLS-ondersteuningsverificatie

    Controleer of alle MX-hosts die in het beleid worden vermeld TLS ondersteunen en geldige certificaten hebben die voldoen aan de beleidsvereisten. Een succesvolle TLS-onderhandeling zorgt ervoor dat versleutelde verbindingen consistent kunnen worden tot stand gebracht zodra de handhaving is ingeschakeld.

Gehoste MTA-STS-services van PowerDMARC

PowerDMARC maakt je leven een stuk eenvoudiger door dat allemaal voor je te regelen, volledig op de achtergrond. Als we je eenmaal helpen bij het instellen, hoef je er nooit meer over na te denken.

  • Wij helpen je met een paar klikken je cname-records te publiceren

  • Wij nemen de verantwoordelijkheid voor het onderhoud van de webserver en de hosting van de certificaten op ons

  • Met onze gehoste MTA-STS-diensten is de implementatie voor jou beperkt tot het publiceren van een paar DNS-records.

  • Je kunt MTA-STS beleidswijzigingen direct en gemakkelijk doorvoeren via het PowerDMARC dashboard, zonder dat je handmatig wijzigingen in de DNS hoeft aan te brengen.

  • De gehoste MTA-STS-services van PowerDMARC voldoen aan RFC en ondersteunen de nieuwste TLS-standaarden.

  • Van het genereren van certificaten en het MTA-STS beleidsbestand tot het afdwingen van het beleid, wij helpen de aanzienlijke complexiteit te omzeilen die komt kijken bij het invoeren van het protocol.

SMTP TLS-rapportage (TLS-RPT)

Om de verbinding tussen twee communicerende SMTP-servers veiliger te maken en te versleutelen via TLS, werd MTA-STS geïntroduceerd om versleuteling af te dwingen en te voorkomen dat e-mails in leesbare tekst worden afgeleverd wanneer er geen veilige verbinding tot stand kan worden gebracht. Er blijft echter één probleem onopgelost: hoe domeineigenaren op de hoogte te stellen wanneer externe servers problemen ondervinden met de bezorging van e-mails als gevolg van TLS-storingen. Hier komt TLS-RPT om de hoek kijken, als aanvulling op MTA-STS, door diagnostische rapporten te leveren die ondersteuning bieden bij het monitoren en oplossen van problemen met de servercommunicatie, zoals verlopen TLS-certificaten, verkeerde configuraties van mailservers of mislukte TLS-onderhandelingen.

TLS-rapporten helpen bij het detecteren van en reageren op problemen bij e-mailaflevering via een rapportagemechanisme in de vorm van JSON-bestanden. Deze JSON-bestanden kunnen ingewikkeld en onleesbaar zijn voor een niet-technisch persoon.

PowerDMARC helpt u om de JSON-bestanden te vereenvoudigen in de vorm van eenvoudige, uitgebreide en leesbare documenten met grafieken en tabellen voor uw gemak. De diagnostische rapporten voor uw domein worden ook in twee formaten weergegeven op het PowerDMARC-dashboard:per resultaat en per verzendbron.

 

powerdmarc tls rpt

Wat TLS-RPT doet

TLS-RPT is ontworpen om e-mailbezorgingsfouten te melden die verband houden met TLS-versleuteling tussen mailservers. Het belangrijkste doel ervan is domeineigenaren inzicht te geven in situaties waarin berichten niet veilig kunnen worden bezorgd, zodat problemen kunnen worden opgespoord die anders verborgen zouden blijven tijdens normale SMTP-communicatie.

Met behulp van deze rapporten helpt TLS-RPT bij het identificeren van problemen zoals mislukte TLS-onderhandelingen tussen verzendende en ontvangende servers, verlopen of ongeldige TLS-certificaten en configuratiefouten aan beide kanten van de e-mailuitwisseling. Dankzij dit inzicht kunnen beheerders precies vaststellen waar de versleuteling mislukt en corrigerende maatregelen nemen.

TLS-RPT-rapporten worden gegenereerd en verzonden door conforme Mail Transfer Agents, doorgaans op dagelijkse basis, waardoor continu inzicht wordt geboden in de gezondheid van veilige e-mailbezorging.

json-diagrammen

Hoe schakel je het in?

TLS-RPT wordt ingeschakeld door een DNS TXT-record te publiceren op de vereiste locatie _smtp._tls voor uw domein. Dit record geeft aan dat TLS-rapportage wordt ondersteund en specificeert de bestemming waar diagnostische rapporten moeten worden afgeleverd.

Het TXT-record definieert een of meer rapportageadressen, meestal e-mail- of HTTPS-eindpunten, die conforme verzendende mailservers gebruiken om TLS-RPT-gegevens te verzenden. Zodra het record is ingesteld, begint de rapportage automatisch zonder dat het gedrag van de mailserver hoeft te worden gewijzigd.

TLS-RPT kan handmatig worden geconfigureerd door het TXT-record rechtstreeks aan DNS toe te voegen of via platforms die een UI-gebaseerde installatie bieden. Het gebruik van een beheerde interface vereenvoudigt de implementatie door het aanmaken en valideren van records voor u te verzorgen, waardoor het risico op syntaxfouten of verkeerde configuraties wordt verminderd.

Lees Meer

E-mailverkeer beveiligen met MTA-STS

E-mail blijft een cruciaal communicatiekanaal, maar zonder gedwongen versleuteling is het kwetsbaar voor downgrade- en MITM-aanvallen die de inhoud van berichten kunnen blootstellen of de bezorging kunnen verstoren. Het beschermen van e-mail tijdens het transport is essentieel voor het behoud van de vertrouwelijkheid en het vertrouwen tussen verzendende en ontvangende mailservers.

MTA-STS versterkt het e-mailverkeer door TLS-encryptie verplicht te stellen en verzending te weigeren wanneer er geen beveiligde verbinding tot stand kan worden gebracht. Door de terugval op niet-versleutelde communicatie te verwijderen, zorgt het ervoor dat berichten alleen via geauthenticeerde en beveiligde kanalen worden verzonden, wat de consistentie en betrouwbaarheid van server-naar-serveruitwisselingen verbetert.

Het succesvol invoeren van MTA-STS hangt af van een zorgvuldige voorbereiding. Het beleid moet nauwkeurig worden geconfigureerd, de ondersteunende infrastructuur moet worden gevalideerd en de handhaving moet geleidelijk worden ingevoerd na grondige tests. Het overslaan van deze stappen kan leiden tot onbedoelde leveringsfouten, vooral wanneer het beleid te snel in de handhavingsmodus wordt gezet.

Voordat organisaties handhaving inschakelen, moeten ze hun huidige e-mailbeveiliging controleren, bevestigen dat alle mailservers klaar zijn voor TLS en ervoor zorgen dat DNS- en beleidsbestanden correct worden gepubliceerd. Voortdurende monitoring en periodieke validatie blijven belangrijk, aangezien serverconfiguraties veranderen en certificaten verlopen. Zo blijft het MTA-STS-beleid de e-mailbezorging effectief beschermen.

Veelgestelde Vragen

Met het controlepaneel van PowerDMARC kunt u MTA-STS en TLS-RPT automatisch instellen voor uw domein door slechts drie CNAME-records te publiceren in de DNS van uw domein. Van het hosten van MTAS-STS beleidsbestanden en certificaten tot het onderhouden van de webserver, wij regelen het allemaal op de achtergrond zonder dat u wijzigingen hoeft aan te brengen in uw DNS. De implementatie van MTA-STS van jouw kant met PowerDMARC is gereduceerd tot slechts een paar klikken.

Je kunt MTA-STS implementeren en beheren voor al je domeinen vanuit je PowerDMARC account, via één enkel venster. In het geval dat een van deze domeinen gebruik maakt van ontvangende mailservers die STARTTLS niet ondersteunen, zal dit worden weergegeven in uw TLS-rapporten, op voorwaarde dat u TLS-RPT hebt ingeschakeld voor deze domeinen.

Het is altijd aan te raden om je MTA-STS beleidsmodus in te stellen op testen in te stellen tijdens de eerste fasen van de implementatie, zodat u activiteiten kunt controleren en inzicht kunt krijgen in uw e-mailecosysteem voordat u overschakelt naar een agressiever beleid zoals afdwingen. Op deze manier worden e-mails, zelfs als ze niet over een versleutelde TLS-verbinding worden verzonden, toch in platte tekst verzonden. Zorg er wel voor dat u TLS-RPT inschakelt om een melding te krijgen als dat gebeurt.

TLS-RPT is een uitgebreid rapportagemechanisme waarmee u een melding kunt krijgen als er geen beveiligde verbinding tot stand kon worden gebracht en de e-mail niet bij u kon worden afgeleverd. Dit helpt u bij het detecteren van problemen bij het afleveren van e-mail of e-mail die is afgeleverd via een onbeveiligde verbinding, zodat u deze direct kunt beperken en oplossen.

Je moet er rekening mee houden dat MTA-STS er weliswaar voor zorgt dat e-mails via een versleutelde TLS-verbinding worden verzonden, maar dat als er niet over een beveiligde verbinding wordt onderhandeld, de e-mail mogelijk helemaal niet wordt afgeleverd. Dit is echter noodzakelijk omdat het ervoor zorgt dat e-mail niet wordt afgeleverd via een onversleuteld pad. Om dit soort problemen te voorkomen, is het aan te raden om een MTA-STS beleid in een testmodus in te stellen en TLS-RPT in eerste instantie in te schakelen voor je domein, voordat je overgaat op de MTA-STS afdwingmodus. 

Je kunt je MTA-STS modus eenvoudig wijzigen vanuit het PowerMTA-STS dashboard door de gewenste beleidsmodus te selecteren en de wijzigingen op te slaan zonder dat je iets aan je DNS hoeft te veranderen.

U kunt MTA-STS voor uw domein uitschakelen door de beleidsmodus in te stellen op 'none' (geen), waarmee u aan MTA's aangeeft dat uw domein het protocol niet ondersteunt, of door uw MTA-STS DNS TXT-record te verwijderen. 

De MX records voor het MTA-STS beleidsbestand moeten de regels bevatten voor alle ontvangende mailservers die door je domein worden gebruikt.

Plan vandaag nog een demo
beveiligde e-mail powerdmarc

Vijftien dagen op proefBoek een demo