DMARC-rapporten lezen: bronnen, uitlijning en beleid

DMARC-rapporten geven inzicht in verkeer dat deelnemende ontvangers met uw domein hebben gezien, de SPF- en DKIM-uitlijning en de gerapporteerde behandeling. Ze kunnen helpen bij het onderzoeken van spoofing, verkeerde providerinstellingen en de voorbereiding op handhaving. Ze tonen echter niet automatisch al uw mail of iedere verzender.

Veel teams publiceren DMARC, verwijzen rua= naar een postvak en analyseren de gegevens daarna niet. De XML stapelt zich op, fouten blijven bestaan en misbruik kan onopgemerkt blijven. Voor de basis begint u bij zakelijke e-mail voor kleine bedrijven en e-mail met uw eigen domein maken. Gebruik de rapporten vervolgens om een verzendinventaris op te bouwen, aangevuld met uw eigen systemen en logboeken.

De aanpak: verzamel rapporten, identificeer legitieme bronnen en herstel uitlijning. Onderzoek SPF-fouten bij doorsturen ook wanneer DKIM slaagt; controleer dat de geldige handtekening uitgelijnd blijft. Beoordeel daarna strenger beleid op basis van gegevens en tests.

Wat zijn DMARC-rapporten?

DMARC-rapporten zijn terugkoppeling van deelnemende ontvangers na hun beoordeling van mail die uw domein in From gebruikt. Ze bevatten authenticatieresultaten, uitlijning, bron-IP-adressen en beleidsacties. Daarmee helpen ze bij beveiligings- en afleveringsonderzoek, zonder volledige dekking te bieden.

Er zijn verschillende soorten rapportage.

Aggregatierapporten worden aangevraagd met rua en komen doorgaans als XML-samenvattingen. Ze groeperen verkeer op onder meer ontvanger, bron-IP, authenticatieresultaat en behandeling. Daarmee kunt u bronnen als Google Workspace, Microsoft 365, SendGrid, Mailchimp, uw appserver of een onbekende VPS onderzoeken. Een IP-adres alleen bewijst nog niet welke partij verzond.

Foutrapporten worden aangevraagd met ruf en kunnen details op berichtniveau bevatten. De aanleiding hangt af van de rapportagevoorwaarden en is niet noodzakelijk alleen een totale DMARC-fout. Ondersteuning is beperkt en privacyoverwegingen leiden tot minder of geen rapporten bij veel ontvangers. Gebruik aggregaten als basis en foutrapporten als aanvullende informatie.

In de praktijk helpen de rapporten bij deze vragen:

1. Welke bronnen zien rapporterende ontvangers met mijn domein?
2. Slaagt SPF of DKIM met de vereiste uitlijning?
3. Rapporteren ontvangers quarantine of reject?
4. Welke risico's moet ik onderzoeken voordat ik p=quarantine of p=reject invoer?

Hoe werkt DMARC-rapportage?

Uw DMARC-record vermeldt waar u terugkoppeling wilt ontvangen. Publiceer een TXT-record op _dmarc.yourdomain.com, kies beleid en voeg rapportageadressen toe. Deelnemende ontvangers kunnen gegevens terugsturen. Voor een externe rapportagebestemming kan aanvullende DNS-autorisatie nodig zijn.

Een monitoringrecord kan er zo uitzien:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

Dit vraagt monitoring zonder DMARC-specifieke handhaving en aggregatierapporten naar dmarc@example.com. De opties adkim=s en aspf=s eisen exacte domeinovereenkomst en zijn niet verplicht of voor iedere omgeving de beste keuze. Bij de standaard relaxed alignment kan hetzelfde organisatiedomein volstaan. Controleer de gevolgen voor uw verzenders.

Belangrijke tags:

• v=DMARC1: vereiste versietag.
• p=: gevraagde behandeling bij DMARC-falen.
• rua=: bestemming voor aggregatierapporten.
• ruf=: bestemming voor foutrapporten.
• pct=: gevraagd aandeel DMARC-falende mail waarop handhaving wordt toegepast; ondersteuning verschilt.
• adkim en aspf: uitlijningsmodus voor DKIM en SPF.

Rapportage en beleidslogica zijn beschreven in RFC 7489. Daarom komen ruwe rapporten vaak als gecomprimeerde XML-bijlagen in plaats van een direct leesbaar overzicht.

Wat staat in een aggregatierapport?

Aggregaten beschrijven gerapporteerd verkeer met onder meer organisatie, bron-IP, aantal berichten, SPF, DKIM en behandeling. Maak onderscheid tussen ruwe authenticatieresultaten en de DMARC-beleidsevaluatie: een authenticatiepass is niet automatisch een uitgelijnde pass.

U vindt doorgaans:

• De rapporterende ontvanger, bijvoorbeeld Google of Microsoft.
• De rapportageperiode.
• Het IP-adres dat de mail bij deze ontvanger afleverde.
• Het aantal geziene berichten van die bron.
• Het ruwe SPF-authenticatieresultaat.
• Het ruwe DKIM-authenticatieresultaat.
• De SPF-beoordeling inclusief uitlijning met From.
• De DKIM-beoordeling inclusief uitlijning met From.
• De gerapporteerde DMARC-behandeling: none, quarantine of reject.

Niet iedere SPF-fout betekent een fout bij uw oorspronkelijke verzender. Doorsturen verandert vaak het verzendende IP-adres. Als DKIM geldig én uitgelijnd blijft, kan DMARC slagen.

Ontvanger: gmail.com
Bron-IP: 198.51.100.24
Aantal: 842
From-domein: example.com
SPF: fail
DKIM: pass
DMARC: pass
Behandeling: none

Dit kan passen bij correct doorsturen met behouden DKIM-uitlijning. Controleer de bron en de handtekening; geslaagde authenticatie bewijst niet dat de inhoud veilig of de afzender zakelijk goedgekeurd is.

Ontvanger: outlook.com
Bron-IP: 203.0.113.77
Aantal: 314
From-domein: example.com
SPF: fail
DKIM: fail
DMARC: fail
Behandeling: quarantine

Dit vraagt onderzoek. Mogelijke oorzaken zijn een verkeerd ingestelde verzender, een nieuwe leverancier zonder juiste authenticatie, misbruik of berichtwijzigingen onderweg. Het rapport alleen bewijst geen spoofing.

Aggregatierapporten en foutrapporten vergelijken

Aggregaten geven een overzicht van het verkeer dat deelnemende ontvangers rapporteren. Foutrapporten kunnen afzonderlijke gebeurtenissen tonen. Voor veel domeinen zijn aggregaten de basis, maar ook zij garanderen geen volledige inventaris of veilige beleidswijziging.

Een dashboard is pas nuttig als de leverancier deze verschillen uitlegt en u met de gegevens concrete configuratiebeslissingen kunt nemen.

DMARC-rapporten efficiënt analyseren

Begin met bronnen die veel verkeer rapporteren, koppel ze aan zakelijke systemen en herstel legitieme fouten. Zo pakt u belangrijke stromen eerst aan. Vergeet daarna de zeldzame maar bedrijfskritische bronnen niet.

Een bruikbare werkwijze:

1. Begin bij de bronnen met het meeste gerapporteerde verkeer.
2. Koppel bronnen aan Google Workspace, Microsoft 365, marketing, uw app, helpdesk of een nog onbekend systeem.
3. Controleer of SPF of DKIM slaagt én uitgelijnd is met het zichtbare From-domein.
4. Herstel legitieme fouten voordat u beleid aanscherpt.
5. Markeer onbekende bronnen voor onderzoek. Een gedeelde relay of doorstuurserver kan ook legitiem verkeer verklaren.

Onderzoek niet alleen kleine foutstromen terwijl belangrijke verzenders onjuist zijn ingesteld. Prioriteer op omvang én zakelijke betekenis.

Veelvoorkomende herstelacties:

• De juiste SPF-include voor een bevestigde legitieme verzender toevoegen, binnen de SPF-limieten.
• Domeinondertekening met DKIM bij de leverancier activeren.
• Een passende eigen return-path voor SPF-uitlijning instellen.
• Een leverancier een subdomein laten gebruiken als dat bij uw domeinbeleid past.
• Doorstuurconfiguratie herstellen in plaats van alleen op SPF te vertrouwen.

Met de opdrachtregel controleert u beschikbare DNS-antwoorden; niet noodzakelijk iedere cache die rapporterende ontvangers gebruiken:

dig TXT _dmarc.example.com +short
dig TXT example.com +short
dig TXT selector1._domainkey.example.com +short

Voor DNS-configuratie helpt TrekMail's documentatie over vereiste DNS-records en mail die in spam belandt.

Problemen die rapporten zichtbaar kunnen maken

DMARC-rapporten helpen bij het vinden van ontbrekende providerconfiguratie, verkeerde uitlijning, doorstuurproblemen en beleid dat niet wordt geëvalueerd. Ze moeten worden aangevuld met uw eigen verzendadministratie.

Een nieuwe zakelijke tool kan mail met uw domein versturen voordat SPF of DKIM is ingericht. Een onbekend IP in rapporten is een aanwijzing om de bron te onderzoeken, geen sluitend bewijs dat dit de oorzaak is.

SPF kan slagen voor het envelopdomein terwijl DMARC faalt als dat domein niet met From is uitgelijnd en ook geen uitgelijnde DKIM slaagt. Dit kan voorkomen bij marketing- en ticketsystemen zonder passende bounceconfiguratie.

Alleen op SPF vertrouwen is kwetsbaar bij doorsturen. Ontbreekt geldige, uitgelijnde DKIM, dan kan DMARC onderweg falen. Lees bij zulke routes e-mail doorsturen instellen en herstellen en test ze apart van directe mail.

Een ander probleem is p=none publiceren en rapporten verzamelen zonder ze te onderzoeken. Daarmee mist u de kans fouten en misbruiksignalen op te volgen.

Ook te snel p=reject invoeren is riskant. Inventariseer legitieme bronnen en test belangrijke en zeldzame stromen voordat u handhaving aanscherpt. Rapporten alleen bewijzen niet dat de overgang veilig is.

De rol van TrekMail

Rapporten zijn nuttig wanneer u hun bevindingen kunt opvolgen. TrekMail kan domeinbeheer, DNS-controles en verzendinstellingen samenbrengen en zo handmatig beheer beperken. Externe bronnen moet u zelf blijven beoordelen.

Bij versnipperd beheer staan domeinen bij verschillende hosts, SMTP-diensten elders en rapporten in een gedeeld postvak. Dan kan een nieuw verzendsysteem makkelijk buiten het overzicht vallen.

Een samenhangende aanpak gebruikt waar beschikbaar het TrekMail-dashboard, DNS- en authenticatie-instructies en de geschikte eigen of beheerde SMTP-route. Postvakken, doorsturen en migratie kunnen in dezelfde omgeving worden beheerd. Voor meerdere klantomgevingen leest u e-mailhosting voor meerdere domeinen.

TrekMail biedt, afhankelijk van het abonnement, eigen domeinen, IMAP-postvakken, catch-all, doorsturen, IMAP-migratie en API-toegang. Nano gebruikt eigen SMTP volgens de instructies voor eigen SMTP. Betaalde abonnementen kunnen beheerde SMTP gebruiken. De hier genoemde Starter-prijs begint bij $3.50 per maand; Nano wordt beschreven als gratis zonder creditcard. Voor betaalde functies kan een proefperiode van 14 dagen met creditcardvereiste gelden. Controleer actuele prijzen en voorwaarden.

Rapporten herstellen niets vanzelf. Ze geven aanwijzingen voor onderzoek; een samenhangende beheeromgeving kan het uitvoeren van correcties eenvoudiger maken.

Van p=none naar quarantine of reject

Rapporten kunnen helpen beoordelen of legitieme verzenders succesvol en uitgelijnd authenticeren. Combineer ze met broninventarisatie, tests van zeldzame stromen en een herstelplan voordat u quarantine of reject invoert. Neem niet aan dat alle resterende fouten onbelangrijk of kwaadaardig zijn.

De volgende records zijn opeenvolgende alternatieven voor een mogelijke invoering. Publiceer slechts één beleidsrecord tegelijk:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=25"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"

Een percentage is geen gegarandeerde verkeerssplitsing: ontvangers passen het niet allemaal hetzelfde toe en het betreft DMARC-falende mail. Analyseer meerdere relevante rapportagecycli, controleer kritieke en zeldzame bronnen en test dat DKIM bij belangrijke doorstuurstromen geldig én uitgelijnd blijft. De ontvanger kan het gevraagde beleid overrulen.

Google vraagt van algemene Gmail-verzenders SPF of DKIM. Voor bulkverzenders gelden beide plus DMARC en de toepasselijke uitlijning. Raadpleeg de veelgestelde vragen over Gmail-verzendrichtlijnen voor de relevante voorwaarden.

Conclusie: maak rapportage onderdeel van het beheer

DMARC-rapporten geven bruikbare, maar gedeeltelijke informatie over bronnen, authenticatie en behandeling. Analyseer ze regelmatig samen met uw verzendinventaris en logs, zodat fouten worden onderzocht in plaats van alleen opgeslagen.

Bij veel domeinen en leveranciers kan eenvoudiger beheer helpen. TrekMail biedt afhankelijk van het abonnement hosting voor meerdere domeinen, gedeelde opslag, IMAP-migratie, eigen of beheerde SMTP en authenticatiecontroles. Controleer de actuele functionaliteit en prijsopzet bij TrekMail-prijzen. Deze hulpmiddelen ondersteunen uw onderzoek, maar garanderen geen veilige handhaving of inboxplaatsing.