Share via

E-mailverificatie in Microsoft 365

Tip

Wist u dat u de functies in Microsoft Defender XDR gratis kunt uitproberen voor Office 365 Abonnement 2? Gebruik de proefversie van 90 dagen Defender voor Office 365 in de Microsoft Defender portal. Meer informatie over wie zich kan registreren en proefabonnementen kan uitvoeren op Try Microsoft Defender voor Office 365.

Als Microsoft 365-organisatie met postvakken in Exchange Online of een zelfstandige EOP-organisatie (Exchange Online Protection) zonder Exchange Online postvakken, is het belangrijk om de integriteit van e-mailberichten van afzenders in uw domeinen te beschermen. Geadresseerden moeten erop kunnen vertrouwen dat berichten van afzenders in uw domein echt afkomstig zijn van afzenders in uw domein.

Email verificatie (ook wel e-mailvalidatie genoemd) is een groep standaarden om de bezorging van e-mailberichten van vervalste afzenders (ook wel spoofing genoemd) te identificeren en te voorkomen. Vervalste afzenders worden vaak gebruikt bij zakelijke e-mailcompromittatie (BEC), phishing en andere e-mailaanvallen. Deze standaarden omvatten:

  • Sender Policy Framework (SPF): hiermee geeft u de bron-e-mailservers op die gemachtigd zijn om e-mail te verzenden voor het domein.
  • DomainKeys Identified Mail (DKIM): gebruikt een domein om belangrijke elementen van het bericht digitaal te ondertekenen om ervoor te zorgen dat het bericht niet is gewijzigd tijdens de overdracht.
  • Domain-based Message Authentication, Reporting and Conformance (DMARC): hiermee geeft u de actie op voor berichten die mislukken SPF- of DKIM-controles voor afzenders in het domein en geeft aan waar de DMARC-resultaten (rapportage) moeten worden verzonden.
  • Geverifieerde ontvangen keten (ARC): behoudt de oorspronkelijke e-mailverificatiegegevens van bekende services die berichten in overdracht wijzigen. De doel-e-mailserver kan deze informatie gebruiken om berichten te verifiëren die anders dmarc zouden mislukken.

Het is belangrijk om te beseffen dat deze standaarden onderling afhankelijke bouwstenen zijn die samenwerken om de best mogelijke e-mailbeveiliging te bieden tegen spoofing en phishing-aanvallen. Alles wat minder is dan alle e-mailverificatiemethoden, resulteert in een ondermaatse beveiliging.

Zie de volgende artikelen om e-mailverificatie te configureren voor e-mail die wordt verzonden vanuit Microsoft 365-organisaties met postvakken in Exchange Online of zelfstandige Exchange Online Protection (EOP) organisaties zonder Exchange Online postvakken:

Zie Vertrouwde ARC-sealers configureren om fouten in e-mailverificatie te voorkomen vanwege services die binnenkomende e-mail wijzigen die naar uw Microsoft 365-organisatie wordt verzonden.

In de rest van dit artikel wordt het volgende uitgelegd:

Tip

Als aanvulling op dit artikel raadpleegt u onze handleiding voor het instellen van Microsoft Defender voor Office 365 voor het controleren van best practices en ter bescherming tegen e-mail- en koppelings- en samenwerkingsbedreigingen. Functies zijn onder andere Veilige koppelingen, Veilige bijlagen en meer. Voor een aangepaste ervaring op basis van uw omgeving hebt u toegang tot de handleiding Microsoft Defender voor Office 365 geautomatiseerde installatie in de Microsoft 365-beheercentrum.

Waarom internet-e-mail verificatie nodig heeft

Standaard doet SMTP-e-mail (Simple Mail Transfer Protocol) op internet geen moeite om te valideren dat de afzender van het bericht is wie hij beweert te zijn.

Een standaard SMTP-e-mailbericht bestaat uit een berichtenvelop en berichtinhoud:

  • De berichtenvelop bevat informatie voor het verzenden en ontvangen van het bericht tussen SMTP-servers. De berichtenvelop wordt beschreven in RFC 5321. Geadresseerden zien de berichtenvelop nooit omdat deze wordt gegenereerd tijdens het verzendproces van het bericht.
  • De berichtinhoud bevat berichtkopvelden (gezamenlijk de berichtkop genoemd) en de berichttekst. De berichtkop wordt beschreven in RFC 5322.

Vanwege dit ontwerp heeft een bericht meerdere afzenderwaarden:

  • Het MAIL FROM-adres (ook wel het adres, P1-afzender 5321.MailFrom of envelopafzender genoemd) is het e-mailadres dat wordt gebruikt bij het verzenden van het bericht tussen SMTP-e-mailservers. Dit adres wordt meestal vastgelegd in het veld Retourpad-koptekst in de berichtkop (hoewel de bron-e-mailserver een ander retourpad-e-mailadres kan toewijzen). Dit e-mailadres wordt gebruikt in rapporten over niet-bezorging (ook wel NDR's of niet-bezorgde berichten genoemd).
  • Het Van-adres (ook wel het 5322.From adres of P2-afzender genoemd) is het e-mailadres in het veld Van-koptekst en is het e-mailadres van de afzender dat wordt weergegeven in e-mailclients.

In het volgende voorbeeld ziet u de vereenvoudigde transcriptie van een geldige berichtoverdracht tussen twee SMTP-e-mailservers:

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

In dit voorbeeld:

  • De bron-e-mailserver identificeert zichzelf als woodgrovebank.com de doel-e-mailserver tailspintoys.com in de HELO-opdracht.
  • De geadresseerde van het bericht is astobes@tailspintoys.com.
  • Het MAIL FROM-adres in de berichtenvelop (gebruikt om het bericht te verzenden tussen SMTP-e-mailservers) is dubious@proseware.com.
  • Het Van-adres dat wordt weergegeven in de e-mailclient van de geadresseerde is security@woodgrovebank.com.

Hoewel dit bericht geldig is volgens SMTP, komt het domein van het MAIL FROM-adres (proseware.com) niet overeen met het domein in het Van-adres (woodgrovebank.com). Dit bericht is een klassiek voorbeeld van adresvervalsing, waarbij de intentie waarschijnlijk is om de ontvanger te misleiden door de werkelijke bron van het bericht te maskeren voor gebruik in een phishing-aanval.

Het is duidelijk dat SMTP-e-mail hulp nodig heeft om te controleren of afzenders van berichten zijn wie ze beweren te zijn.

Hoe SPF, DKIM en DMARC samenwerken om afzenders van e-mailberichten te verifiëren

In deze sectie wordt beschreven waarom u SPF, DKIM en DMARC nodig hebt voor domeinen op internet.

  • SPF: Zoals uitgelegd in SPF instellen om geldige e-mailbronnen voor uw Microsoft 365-domein te identificeren, gebruikt SPF een TXT-record in DNS om geldige e-mailbronnen uit het MAIL FROM-domein te identificeren en wat u moet doen als de doel-e-mailserver e-mail ontvangt van een niet-gedefinieerde bron ('hard fail' om het bericht te weigeren; 'soft fail' om het bericht te accepteren en te markeren).

    SPF-problemen:

    • SPF valideert alleen bronnen voor afzenders in het domein MAIL FROM. SPF houdt geen rekening met het domein in het Van-adres of de uitlijning tussen de domeinen MAIL FROM en From:

      • Een aanvaller kan e-mail verzenden die door de SPF-verificatie (een fout-negatief) is geslaagd door de volgende stappen uit te voeren:
        • Registreer een domein (bijvoorbeeld proseware.com) en configureer SPF voor het domein.
        • E-mail verzenden vanuit een geldige bron voor het geregistreerde domein, met de Van e-mailadressen in een ander domein (bijvoorbeeld woodgrovebank.com).
      • Een legitieme e-mailservice die e-mail verzendt namens andere domeinen, kan het MAIL FROM-adres beheren. De andere domeinen en het MAIL FROM-domein komen niet overeen, dus de berichten kunnen niet door SPF-verificatie (een fout-positief).

    • SPF-onderbrekingen nadat berichten e-mail doorsturen op serverbasis tegenkomen die berichten omleiden of doorsturen.

      • Doorsturen van e-mail op basis van server wijzigt de berichtbron van de oorspronkelijke server in de doorstuurserver.
      • De doorstuurserver is niet gemachtigd om e-mail te verzenden vanuit het oorspronkelijke MAIL FROM-domein, zodat het bericht niet kan slagen voor SPF-verificatie (een fout-positief).

    • Elk domein en eventuele subdomeinen vereisen hun eigen afzonderlijke SPF-records. Subdomeinen nemen de SPF-record van het bovenliggende domein niet over. Dit gedrag wordt problematisch als u e-mail van gedefinieerde en gebruikte subdomeinen wilt toestaan, maar wilt voorkomen dat e-mail niet-gedefinieerde en ongebruikte subdomeinen bevat.

  • DKIM: Zoals uitgelegd in DKIM instellen voor het ondertekenen van e-mail vanuit uw Microsoft 365-domein, gebruikt DKIM een domein om belangrijke elementen van het bericht digitaal te ondertekenen (inclusief het Van-adres) en slaat DKIM de handtekening op in de berichtkop. De doelserver controleert of de ondertekende elementen van het bericht niet zijn gewijzigd.

    Hoe DKIM SPF helpt: DKIM kan berichten valideren die SPF mislukken. Bijvoorbeeld:

    • Berichten van een e-mailhostingservice waarbij hetzelfde MAIL FROM-adres wordt gebruikt voor e-mail uit andere domeinen.
    • Berichten die servergebaseerde e-mail doorsturen tegenkomen.

    Omdat de DKIM-handtekening in de berichtkop in deze scenario's niet wordt beïnvloed of gewijzigd, kunnen deze berichten DKIM doorgeven.

    DKIM-problemen: het domein dat DKIM gebruikt om een bericht te ondertekenen, hoeft niet overeen te komen met het domein in het Van-adres dat wordt weergegeven in e-mailclients.

    Net als SPF kan een aanvaller e-mail verzenden die dkim-verificatie doorstaat (een fout-negatief) door de volgende stappen te volgen:

    • Registreer een domein (bijvoorbeeld proseware.com) en configureer DKIM voor het domein.
    • E-mail verzenden met van e-mailadressen in een ander domein (bijvoorbeeld woodgrovebank.com).

  • DMARC: Zoals uitgelegd in DMARC instellen om het van-adresdomein te valideren voor afzenders in Microsoft 365, gebruikt DMARC SPF en DKIM om te controleren op uitlijning tussen de domeinen in de E-MAIL FROM- en Van-adressen. DMARC geeft ook de actie op die het doel-e-mailsysteem moet uitvoeren op berichten die DMARC mislukken, en identificeert waar DMARC-resultaten moeten worden verzonden (zowel geslaagd als mislukken).

    Hoe DMARC SPF en DKIM helpt: zoals eerder is beschreven, probeert SPF het domein in MAIL FROM-domein en Van-adressen niet te vinden. DKIM maakt het niet uit of het domein dat het bericht heeft ondertekend overeenkomt met het domein in het Van-adres.

    DMARC lost deze tekortkomingen op met behulp van SPF en DKIM om te bevestigen dat de domeinen in de MAIL FROM- en Van-adressen overeenkomen.

    DMARC-problemen: legitieme services die berichten wijzigen die worden verzonden voordat de bezorging wordt onderbroken SPF, DKIM en dus DMARC-controles.

  • ARC: Zoals uitgelegd in Vertrouwde ARC-sealers configureren, kunnen legitieme services die berichten in transit wijzigen ARC gebruiken om de oorspronkelijke e-mailverificatiegegevens van gewijzigde berichten te behouden.

    Hoe ARC DMARC helpt: het doel-e-mailsysteem kan de service identificeren als een vertrouwde ARC-sealer. ARC kan vervolgens de bewaarde e-mailverificatiegegevens gebruiken om het bericht te valideren.

Verificatie van binnenkomende e-mail voor e-mail die naar Microsoft 365 wordt verzonden

Vanwege phishingproblemen en een minder dan volledige acceptatie van een sterk e-mailverificatiebeleid door e-mailverzenders op internet, maakt Microsoft 365 gebruik van impliciete e-mailverificatie om binnenkomende e-mail te controleren. Impliciete e-mailverificatie breidt reguliere SPF-, DKIM- en DMARC-controles uit met behulp van signalen van andere bronnen om binnenkomende e-mail te evalueren. Deze bronnen zijn onder andere:

  • Reputatie van afzender.
  • Afzendergeschiedenis.
  • Geschiedenis van geadresseerden.
  • Gedragsanalyse.
  • Andere geavanceerde technieken.

Zie A Sea of Phish Part 2 - Enhanced Anti-spoofing in Microsoft 365 voor meer informatie over de oorspronkelijke aankondiging van Microsoft over impliciete verificatie.

Door deze andere signalen te gebruiken, kunnen berichten die anders niet zouden slagen voor traditionele e-mailverificatiecontroles impliciete verificatie doorgeven en worden toegestaan in Microsoft 365.

Samengestelde verificatie

De resultaten van impliciete verificatiecontroles van Microsoft 365 worden gecombineerd en opgeslagen in één waarde met de naam samengestelde verificatie of compauth kortom. De compauth-waarde wordt in de koptekst Verificatie-resultaten in de berichtkoppen gestempeld. De header Authentication-Results gebruikt de volgende syntaxis:

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Deze waarden worden uitgelegd in de berichtkop Verificatie-resultaten.

Beheerders en gebruikers kunnen de berichtkoppen bekijken om te ontdekken hoe Microsoft 365 de afzender heeft geïdentificeerd als een verdachte vervalste afzender of legitiem.

Tip

Het is belangrijk om te begrijpen dat een samengestelde verificatiefout er niet rechtstreeks toe leidt dat een bericht wordt geblokkeerd. Ons systeem maakt gebruik van een holistische evaluatiestrategie die rekening houdt met de algehele verdachte aard van een bericht, samen met samengestelde verificatieresultaten. Deze methode is ontworpen om het risico te beperken dat legitieme e-mail ten onrechte wordt geblokkeerd van domeinen die mogelijk niet strikt voldoen aan e-mailverificatieprotocollen. Met deze evenwichtige benadering kunt u echt schadelijke e-mail onderscheiden van afzenders van berichten die eenvoudigweg niet voldoen aan de standaardprocedures voor e-mailverificatie.

De volgende voorbeelden zijn alleen gericht op de resultaten van e-mailverificatie (de compauth waarde en reden). Andere Microsoft 365-beveiligingstechnologieën kunnen berichten die e-mailverificatie doorgeven, identificeren als vervalst, of berichten die mislukken voor e-mailverificatie als legitiem identificeren.

  • Scenario: Het domein in de SPF-record of de DKIM-handtekening komt niet overeen met het domein in het Van-adres.

  • Resultaat: Het bericht kan mislukken met samengestelde verificatie. Ondanks de mislukte samengestelde verificatie is het bericht mogelijk nog steeds toegestaan als andere evaluaties geen verdacht karakter aangeven:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

  • Scenario: Het fabrikam.com domein heeft geen SPF-, DKIM- of DMARC-records.

  • Resultaat: Berichten van afzenders in het fabrikam.com domein kunnen mislukken in samengestelde verificatie:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

  • Scenario: het fabrikam.com domein heeft een SPF-record en geen DKIM-record. De domeinen in de MAIL FROM- en Van-adressen komen overeen.

  • Resultaat: Het bericht kan samengestelde verificatie doorstaan, omdat het domein dat SPF heeft doorgegeven overeenkomt met het domein in het Van-adres:

    Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Scenario: Het fabrikam.com domein heeft een DKIM-record zonder een SPF-record. Het domein waarop DKIM het bericht heeft ondertekend, komt overeen met het domein in het Van-adres.

  • Resultaat: Het bericht kan samengestelde verificatie doorstaan, omdat het domein in de DKIM-handtekening overeenkomt met het domein in het Van-adres:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Scenario: Het domein in de SPF-record of de DKIM-handtekening komt niet overeen met het domein in het Van-adres.

  • Resultaat: Het bericht kan samengestelde verificatie mislukken:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

E-mailverificatiefouten voorkomen bij het verzenden van e-mail naar Microsoft 365

Tip

Microsoft 365-klanten kunnen de volgende methoden gebruiken om berichten van afzenders toe te staan die zijn geïdentificeerd als spoofing of verificatiefouten:

  • SPF-, DKIM- en DMARC-records configureren voor uw domeinen: gebruik de configuratie-informatie die wordt verstrekt door uw domeinregistrar of DNS-hostingservice. Er zijn ook externe bedrijven die zich richten op het instellen van e-mailverificatierecords.

    Veel bedrijven publiceren geen SPF-records omdat ze niet alle e-mailbronnen voor berichten in hun domein kennen.

    1. Begin met het publiceren van een SPF-record die alle e-mailbronnen bevat die u kent (met name waar uw bedrijfsverkeer zich bevindt) en gebruik de waarde van de afdwingingsregel 'soft fail' (~all). Bijvoorbeeld:

      fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"

      Als u deze SPF-record maakt, behandelt Microsoft 365 binnenkomende e-mail van uw bedrijfsinfrastructuur als geverifieerd, maar e-mailberichten van niet-geïdentificeerde bronnen worden mogelijk nog steeds gemarkeerd als spoof als de samengestelde verificatie mislukt. Dit gedrag is echter nog steeds een verbetering ten opzichte van alle e-mailberichten van afzenders in het domein die door Microsoft 365 als spoof worden gemarkeerd. Normaal gesproken accepteert het doel-e-mailsysteem berichten van afzenders in het domein van niet-geïdentificeerde bronnen wanneer SPF is geconfigureerd met een regel voor het afdwingen van soft fail.

    2. Ontdek en neem meer e-mailbronnen op voor uw berichten. Bijvoorbeeld:

      • On-premises e-mailservers.
      • E-mail die is verzonden via een software-als-een-service (SaaS)-provider.
      • E-mail die is verzonden via een cloudservice (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services, enz).

      Nadat u alle e-mailbronnen voor uw domein hebt geïdentificeerd, kunt u uw SPF-record bijwerken om de waarde van de afdwingingsregel 'hard fail' (-all) te gebruiken.

    3. DKIM instellen om berichten digitaal te ondertekenen.

    4. Stel DMARC in om te controleren of de domeinen in de E-MAIL FROM- en Van-adressen overeenkomen, om op te geven wat er moet worden uitgevoerd met berichten die dmarc-controles niet uitvoeren (weigeren of in quarantaine plaatsen) en om reporting services te identificeren om DMARC-resultaten te bewaken.

    5. Als u bulkverzenders gebruikt om namens u e-mail te verzenden, controleert u of het domein in het Van-adres overeenkomt met het domein dat SPF of DMARC doorgeeft.

  • U host de e-mail van een domein of biedt een hostinginfrastructuur waarmee e-mail kan worden verzonden:

    • Zorg ervoor dat uw klanten documentatie hebben waarin wordt uitgelegd hoe ze SPF voor hun domeinen kunnen configureren.
    • Overweeg dkim-ondertekening DKIM uitgaande e-mail, zelfs als de klant DKIM niet expliciet instelt in hun domein (ondertekenen met een standaarddomein). U kunt het e-mailbericht zelfs dubbel ondertekenen met DKIM-handtekeningen (met uw bedrijfsdomein en het domein van de klant als/wanneer deze beschikbaar is).

    Bezorging aan Microsoft is niet gegarandeerd, zelfs niet als u e-mail verifieert die afkomstig is van uw platform. Maar e-mailverificatie zorgt ervoor dat Microsoft niet automatisch ongewenste e-mail uit uw klantdomeinen verzendt, simpelweg omdat deze niet wordt geverifieerd.