7 externe afzenders die vaak de DMARC-regels overtreden (en hoe je ze allemaal kunt verifiëren)

De meeste organisaties versturen e-mails via veel meer systemen dan alleen hun e-mailserver. Marketingplatforms, CRM-systemen, helpdesks, factureringstools en een steeds groter wordende reeks AI-assistenten versturen allemaal berichten waarin uw domein in het ‘Van’-adres staat vermeld. Elk daarvan is een externe afzender, en elk daarvan is een plek waar SPF, DKIM en DMARC kunnen falen zonder dat iemand het merkt.

Fouten zijn nu belangrijker dan ooit. Gmail, Yahoo en Outlook.com eisen dat afzenders die meer dan 5.000 berichten per dag versturen, zich authenticeren via SPF, DKIM en DMARC en deze afstemmen op het ‘Van’-domein; anders kunnen ze niet-conforme bulkmail zonder meer weigeren. Bij een lager volume is de kans groter dat een bericht dat niet aan de DMARC-vereisten voldoet in de spamfolder terechtkomt, en het zal helemaal niet aankomen zodra je overstapt op een weigeringsbeleid.

Deze handleiding behandelt zeven categorieën externe afzenders, legt uit hoe elke categorie doorgaans de DMARC-regels overtreedt, en somt de stappen op om deze te verifiëren. De handleiding sluit af met voorbeelden van DNS-records, een verificatiemethode en een implementatieplan.

Waarom externe afzenders DMARC omzeilen

DMARC wordt goedgekeurd wanneer ten minste één van SPF of DKIM wordt goedgekeurd en deze overeenkomt met het domein in het zichtbare ‘Van’-adres. Die overeenstemming is het punt dat mensen vaak over het hoofd zien.

• SPF-vergelijking vergelijkt het domein in het retourpad, ook wel de afzender van de envelop of het bounce-adres genoemd, met het 'Van'-domein. Leveranciers gebruiken meestal hun eigen bounce-domein, waardoor SPF voor hen wordt goedgekeurd, maar niet overeenkomt met dat van u.
• DKIM-afstemming vergelijkt het ondertekeningsdomein in de DKIM-handtekening (de d=-waarde) met het 'From'-domein. Leveranciers ondertekenen standaard meestal met hun eigen domein, waardoor DKIM wel wordt goedgekeurd, maar niet overeenkomt.
• Configuratiefouten verstoren de rest. Veelvoorkomende fouten zijn meer dan 10 DNS-lookups in SPF, meer dan één SPF-record op een domein, ontbrekende DKIM-records en records die zijn achtergebleven van leveranciers die u niet langer gebruikt.

Bij ‘versoepelde afstemming’ – de standaardinstelling – wordt een subdomein afgestemd op het bovenliggende organisatiedomein. Bij ‘strikte afstemming’ is een exacte overeenkomst vereist. Aangezien DKIM-handtekeningen doorgaans intact blijven bij het doorsturen, terwijl dit bij SPF vaak niet het geval is, streven de meeste teams naar DKIM-afstemming voor elke externe afzender.

De zeven verzenders in één oogopslag

1. AI-notulisten en vergaderassistenten

Vergaderassistenten sturen samenvattingen, actiepunten en conceptversies voor vervolgstappen en delen links, vaak met deelnemers buiten uw bedrijf. Of uw team nu Fathom gebruikt of alternatieven voor Fathom overweegt alternatieven voor Fathom, vraag de leverancier dan hoe de e-mails worden geauthenticeerd voordat u een mailbox koppelt of het verzenden vanuit uw domein inschakelt.

Veel van deze tools versturen e-mails vanaf hun eigen domein en tonen uw naam als weergavenaam. Dit heeft geen invloed op uw DMARC-resultaten, omdat het domein in het ‘Van’-adres dat van de leverancier is. De problemen beginnen bij functies die uw domein in het ‘Van’-adres vermelden en vanaf de servers van de leverancier versturen, zoals vervolg-e-mails die lijken te zijn afkomstig van u. Die berichten bevatten het retourpad en de DKIM-handtekening van de leverancier, waardoor ze weliswaar voldoen aan de SPF- en DKIM-controles, maar toch niet overeenkomen met uw domein. Een derde patroon is een tool die via uw eigen Google- of Microsoft-mailbox verstuurt. Die e-mail wordt ondertekend en afgeleverd door uw e-mailprovider, dus er is wel overeenstemming zolang DKIM-ondertekening daar voor uw domein is ingeschakeld.

Vragen die je aan de verkoper moet stellen:

• Welk domein wordt weergegeven in het ‘Van’-adres van samenvattingen, uitnodigingen en herinneringen?
• Is er een functie waarmee e-mail vanaf de servers van de leverancier wordt verzonden met mijn domein in het ‘Van’-adres?
• Zo ja, kan ik me dan authenticeren met een aangepaste DKIM en een aangepast retourpad op een subdomein?
• Kunnen e-mails naar externe deelnemers worden beperkt of uitgeschakeld?
• Als de tool gegevens via mijn mailbox verstuurt, welke machtigingen vraagt hij dan?

Hoe je dit kunt verifiëren:

• Als het ‘Van’-domein eigendom is van de leverancier, hoeft u niets in te stellen voor uw DMARC. Let vooral op wie de e-mails ontvangt.
• Als de leverancier e-mails verstuurt vanaf jouw domein, voeg dan de DKIM- en return-path-records toe die in de documentatie van de leverancier worden vermeld, bij voorkeur op een speciaal daarvoor bestemd subdomein.
• Als de tool e-mails via uw mailbox verstuurt, zorg er dan voor dat DKIM-ondertekening is ingeschakeld voor uw eigen domein in Google Workspace of Microsoft 365.
• Stuur een echte samenvatting naar een extern e-mailadres en bekijk de authenticatie-headers voordat je het systeem in gebruik neemt.

2. Marketing- en e-mailserviceplatforms

Marketingplatforms versturen de grootste hoeveelheid e-mail namens derden, waardoor ze de meest voorkomende bron van DMARC-problemen zijn. Standaard ondertekenen veel platforms de e-mail met de eigen DKIM-sleutel van de leverancier en gebruiken ze het bounce-domein van de leverancier als retourpad. SPF en DKIM komen dan wel overeen met het domein van de leverancier, maar geen van beide komt overeen met het domein in uw ‘Van’-adres, waardoor DMARC mislukt.

Bij grote volumes staat er meer op het spel. Gmail, Yahoo en Outlook.com eisen dat afzenders die meer dan 5.000 berichten per dag versturen, zich authenticeren via SPF, DKIM en DMARC en dat het ‘Van’-domein overeenkomt met de afzender. Daarnaast moeten marketingmails voorzien zijn van een afmeldfunctie met één klik en een laag percentage spamklachten. Bulkmail die niet aan deze eisen voldoet, kan direct worden geweigerd.

Hoe je dit kunt verifiëren:

• Verzend e-mails via een speciaal subdomein, zoals news.example.com, zodat de marketingreputatie en de DNS-records gescheiden blijven van de zakelijke e-mail.
• Voer de domeinverificatie van het platform uit. Dit houdt meestal in dat je DKIM-records toevoegt, vaak CNAME-records, zodat berichten worden ondertekend met je domein, plus een aangepast return-path-domein indien dit wordt aangeboden.
• Plaats het SPF-record op de juiste plek. Als het retourpad een aangepast subdomein is, wordt het SPF-record op dat subdomein geplaatst, waardoor je hoofddomeinrecord kort blijft.
• Stel een DMARC-beleid in voor het subdomein, hetzij met `sp=` in het bovenliggende record, hetzij via een eigen record, en bekijk de geaggregeerde rapporten.
• Voeg kopteksten toe waarmee je je met één klik kunt afmelden en houd de klachtenpercentages in de gaten.

3. CRM- en sales engagement-platforms

Verkooptools verzenden berichten doorgaans op een van de volgende twee manieren. Eén-op-één-e-mails die via een gekoppelde Google- of Microsoft-mailbox worden verzonden, worden door uw e-mailprovider geauthenticeerd. Voor bulkcampagnes en opties waarbij berichten via het platform worden verzonden, wordt gebruikgemaakt van de eigen servers van het platform, en die moeten worden geconfigureerd. Een veelvoorkomende fout is dat een platform berichten verzendt vanaf de persoonlijke e-mailadressen van gebruikers op uw domein zonder dat DKIM of het retourpad is ingesteld.

Deze tools stapelen ook SPF-includes op. Elke include kost DNS-lookups, en SPF staat er slechts 10 per evaluatie toe (RFC 7208). Als de limiet wordt overschreden, behandelen ontvangers SPF als een permanente fout, waardoor de controle mislukt.

Hoe je dit kunt verifiëren:

• Gebruik verzending via de mailbox voor individuele benadering.
• Voor berichten die via het platform worden verzonden, moet u een speciaal subdomein verifiëren met aangepaste DKIM-instellingen en een aangepast retourpad, en de communicatie naar externe partijen op een ander domein of subdomein houden dan de bedrijfsmail.
• Controleer welke gebruikers en welke platforms berichten mogen versturen vanuit jouw domein.
• Tel regelmatig het aantal SPF-lookups. Voeg includes voor tools die je niet meer gebruikt samen of verwijder ze, en wees voorzichtig met het ‘afvlakken’ van IP-lijsten, want afgevlakte IP-lijsten raken verouderd wanneer leveranciers van adres veranderen.

4. Helpdesk- en klantenservicetools

Supportteams willen meestal dat antwoorden afkomstig zijn van [email protected]. Dat betekent dat de servers van de helpdesk e-mails versturen met uw domein in het ‘Van’-adres, wat SPF- of DKIM-validatie vereist om aan de DMARC-eisen te voldoen. Bij veel configuraties wordt dit overgeslagen, omdat tickets tijdens het testen lijken te werken: de controles van de leverancier zelf slagen en de bezorging in een minder strenge inbox verloopt succesvol.

De afhandeling van inkomende e-mail brengt een tweede reeks problemen met zich mee. Het automatisch doorsturen van een supportmailbox naar de helpdesk is eenvoudig, maar door het doorsturen wordt SPF vaak ongeldig, omdat het IP-adres van de doorstuurder niet is geautoriseerd voor de oorspronkelijke afzender. DKIM-handtekeningen blijven bij het doorsturen intact, wat een van de redenen is waarom DKIM-afstemming betrouwbaarder is dan SPF-afstemming.

Hoe je dit kunt verifiëren:

• Voeg de DKIM-records van de leverancier toe, zodat antwoorden met uw domein worden ondertekend, en voeg indien nodig de SPF- of return-path-records van de leverancier toe.
• Geef de voorkeur aan MX-routing of de door de leverancier ondersteunde doorstuurmethode boven regels voor het automatisch doorsturen van mailboxberichten.
• Test een antwoord op een ticket naar een externe mailbox en bekijk de headers; herhaal dit vervolgens voor geautomatiseerde berichten, zoals tevredenheidsenquêtes, die soms afkomstig zijn van een ander systeem.
• Verwijder de records van helpdesktools die u niet meer gebruikt.

5. Kalender- en planningshulpmiddelen

Planningstools versturen uitnodigingen, bevestigingen en herinneringen, meestal namens een organisator. De meeste versturen deze vanuit het domein van de leverancier, waarbij uw adres in het veld ‘Reply-To’ staat; dit heeft geen invloed op uw DMARC. Problemen ontstaan door merkgebonden opties die zonder authenticatie vanuit uw domein worden verstuurd, en door agenda-e-mails die ongetekend worden verzonden.

Het geval waarin geen handtekening is geplaatst, wordt gemakkelijk over het hoofd gezien. Als DKIM-ondertekening niet is ingeschakeld voor uw aangepaste domein in Microsoft 365, wordt uitgaande e-mail in plaats daarvan ondertekend met het standaardtenantdomein, dat niet overeenkomt met uw ‘Van’-domein. Ook bij Google Workspace moet DKIM voor uw domein zijn ingeschakeld.

Hoe je dit kunt verifiëren:

• Controleer voor elk berichttype welk domein de tool gebruikt in het ‘Van’-adres.
• Schakel DKIM-ondertekening in voor je eigen domein bij je e-mailprovider, zodat agenda-uitnodigingen en berichten die vanuit je mailbox worden verzonden, op elkaar zijn afgestemd.
• Als je een verzendoptie van een leverancier gebruikt, verifieer deze dan met de DKIM- en return-path-records van die leverancier.
• Bekijk herinnerings- en annuleringsmails apart van de uitnodigingen.

6. Platforms voor facturering en betaling

Facturen, kwitanties en betalingsherinneringen behoren tot de meest misbruikte soorten e-mails. Aanvallers bootsen deze na omdat ontvangers snel reageren op alles wat met geld te maken heeft, en een vervalste factuur kan ervoor zorgen dat een betaling naar een andere bestemming wordt doorgestuurd. Deze platforms versturen e-mails vaak vanuit hun eigen domein met uw bedrijfsnaam, en bieden de mogelijkheid om te verzenden via [email protected]. Die optie werkt alleen voor DMARC als de DNS-records correct zijn ingesteld.

Bedrijven maken vaak gebruik van meerdere factureringssystemen tegelijk, zoals boekhoudsoftware, een betalingsverwerker en een abonnementsbeheersysteem. Elk daarvan is een afzonderlijke afzender met zijn eigen gegevens.

Hoe je dit kunt verifiëren:

• Maak gebruik van de functie voor aangepaste e-maildomeinen van elk platform en publiceer de DKIM-, SPF- en return-path-records die het platform verstrekt.
• Maak een lijst van alle systemen die facturen versturen en controleer of elk systeem zich op de juiste manier authenticeert en de gegevens kloppen.
• Schakel over op een handhavingsbeleid zodra uit rapporten blijkt dat uw legitieme bronnen de drempel overschrijden. Dat voorkomt dat aanvallers facturen versturen die op die van u lijken.
• Laat klanten weten vanaf welke adressen uw facturen worden verzonden.

7. HR-, wervings- en salarisadministratiesystemen

Sollicitantvolgsystemen versturen e-mails naar kandidaten via adressen die eindigen op careers@ of jobs@, onboardingplatforms sturen welkomstberichten en salarisverwerkingssystemen sturen meldingen naar werknemers. Deze systemen worden vaak door HR geselecteerd en geconfigureerd zonder dat IT hierbij betrokken is, waardoor niemand de DNS-instellingen controleert. Het gevolg is dat aanbiedingen in de spamfolder terechtkomen en kandidaten uitnodigingen voor sollicitatiegesprekken mislopen.

Ook hier komt identiteitsfraude veel voor. E-mails met vacaturefraude waarin de huisstijl van een echt bedrijf wordt nagebootst, zijn een veelgebruikte tactiek, en een strikt DMARC-beleid maakt het moeilijker om dergelijke e-mails vanaf je eigen domein te versturen.

Hoe je dit kunt verifiëren:

• Maak de beoordeling van het DNS-systeem onderdeel van het aankoopproces van HR-software.
• Verifieer een speciaal subdomein voor wervingsmails met behulp van de DKIM- en return-path-records van de leverancier.
• Publiceer een korte lijst met officiële adressen voor werving en salarisadministratie, zodat sollicitanten en werknemers deze kunnen herkennen.
• Controleer of uitnodigingen voor sollicitatiegesprekken en e-mails met een aanbod daadwerkelijk in de inbox terechtkomen, ook bij gratis webmailproviders.

Voorbeelden van DNS-records

De exacte namen en waarden zijn afkomstig van de configuratiepagina van de betreffende leverancier. De onderstaande voorbeelden geven weer wat je kunt verwachten. De domeinnamen zijn tijdelijke aanduidingen.

SPF op het verzendende subdomein (één record per domein)
mail.example.com. TXT “v=spf1 include:_spf.vendor.example ~all”

DKIM-ondertekeningsrecords, die doorgaans worden geleverd als CNAME’s:
selector1._domainkey.mail.example.com. CNAME selector1.dkim.vendor.example.
selector2._domainkey.mail.example.com. CNAME selector2.dkim.vendor.example.

Aangepast domein voor het retourpad (bounce)
bounce.mail.example.com. CNAME return.vendor.example.

DMARC-record, start in de bewakingsmodus
_dmarc.example.com. TXT “v=DMARC1; p=none; rua=mailto:[email protected]” 

Hoe je een afzender kunt verifiëren voordat je live gaat

Stuur een echt bericht vanuit het systeem naar een externe mailbox, open de bron van het oorspronkelijke bericht en bekijk de authenticatieresultaten. Je wilt dat SPF of DKIM de controle doorstaan en dat het domein dat daarachter zit overeenkomt met het ‘Van’-domein.

In overeenstemming: DMARC geslaagd
spf=pass smtp.mailfrom=bounce.mail.example.com
dkim=pass header.d=mail.example.com
dmarc=pass header.from=mail.example.com

Geslaagd, maar niet in overeenstemming: DMARC-fout
spf=pass smtp.mailfrom=bounces.vendor.example
dkim=pass header.d=vendor.example
dmarc=fail header.from=example.com 

In het tweede voorbeeld worden beide controles met succes doorlopen, maar voor het domein van de leverancier. Geen van beide komt overeen met example.com, dus DMARC mislukt. Dat is het kenmerk van een niet-geverifieerde externe afzender.

Een implementatieplan

1. Maak een overzicht van je afzenders. Vraag de financiële afdeling naar SaaS-abonnementen, bekijk uw lijst met Single Sign-On-apps, bekijk uw SPF-inclusies en controleer de e-maillogboeken.
2. Publiceer DMARC met p=none en een rapportageadres. Geaggregeerde rapporten tonen elk systeem dat namens uw domein berichten verstuurt, inclusief systemen die niemand zich nog kon herinneren.
3. Verifieer elke legitieme afzender. Gebruik aangepaste DKIM en return-path, en geef de voorkeur aan subdomeinen voor systemen met een hoog volume of een hoog risico.
4. Ga over tot handhaving. Zodra uit rapporten blijkt dat legitieme e-mail wordt doorgelaten, ga dan over tot quarantaine en vervolgens tot afwijzing, waarbij u de rapporten in elke fase nauwlettend in de gaten houdt.
5. Maak er een vaste gewoonte van. Voeg een e-mailverificatie toe aan het onboardingproces van leveranciers en verwijder DNS-records wanneer je een tool buiten gebruik stelt.

FAQ

Wat is het verschil tussen het slagen voor SPF of DKIM en het slagen voor DMARC?

SPF en DKIM kunnen voor elk domein worden goedgekeurd, ook voor dat van de leverancier. DMARC voegt hieraan de eis toe dat het goedgekeurde domein overeenkomt met het domein in je „Van”-adres.

Moet ik elke leverancier aan mijn SPF-record toevoegen?

Niet altijd. Als een leverancier een aangepast retourpad op je subdomein gebruikt en ondertekent met ‘aligned’ DKIM, kan DMARC de controle doorstaan zonder dat je root-SPF-record wordt aangepast. Door minder ‘includes’ te gebruiken, blijf je bovendien binnen de limiet van 10 lookups.

Moet ik subdomeinen gebruiken voor afzenders van derden?

Vaak wel, ja. Een subdomein scheidt reputatie- en DNS-records van elkaar en maakt het gemakkelijker om elke bron te volgen en te beheren. Houd er rekening mee dat subdomeinen je DMARC-beleid overnemen, tenzij je `sp=` instelt of een apart record publiceert.

Hoe lang duurt het voordat p=reject wordt bereikt?

Dat hangt af van het aantal afzenders dat je hebt en hoe snel je de problemen kunt oplossen. Bij veel organisaties duurt dit enkele weken tot een paar maanden, waarbij ze zich baseren op geaggregeerde rapporten.

Wat als een leverancier geen overeenkomst kan sluiten met mijn domein?

Dan zou DMARC de SPF-afstemming moeten doorstaan met een aangepast retourpad. Als geen van beide mogelijk is, moet de leverancier vanaf zijn eigen domein verzenden, niet vanaf het jouwe.

Is DMARC van toepassing op e-mail die via Google Workspace of Microsoft 365 wordt verzonden?

Ja. Zorg ervoor dat DKIM-ondertekening daar voor uw eigen domein is ingeschakeld, anders wordt de e-mail mogelijk ondertekend met een standaarddomein dat niet overeenkomt.