E-mailbezorging en DNS

DMARC RUA: instellen en aggregatierapporten lezen

Door Alexey Bulygin
DMARC RUA-adres en analyse van aggregatierapporten

DMARC RUA is de rapportagebestemming in uw DMARC-record waarmee u aggregatierapporten van ontvangers aanvraagt. Zonder deze terugkoppeling mist u een nuttige bron van informatie over geslaagde en mislukte authenticatie en mogelijk domeinmisbruik. RUA toont echter niet automatisch alle mail of alle verzenders. Voor de basis van domeinmail begint u bij zakelijke e-mail voor kleine bedrijven.

Ontbrekend inzicht kan het onderzoek bemoeilijken. Een CRM is verkeerd ingesteld, een vergeten WordPress-plug-in gebruikt uw hoofddomein of SPF faalt bij doorsturen. Mail kan anders worden verwerkt zonder dat u meteen de oorzaak kent. RUA helpt aanwijzingen verzamelen om zulke situaties te onderzoeken.

Deze gids legt uit wat RUA is, hoe u het publiceert, wat XML-rapporten betekenen en welke problemen u het eerst onderzoekt.

Wat is dmarc rua?

RUA is de DMARC-tag die aangeeft waar u aggregatierapporten wilt ontvangen. Deelnemende ontvangers vatten daarin SPF, DKIM, uitlijning, bron-IP-adressen en behandeling samen over een periode, vaak dagelijks. Niet iedere ontvanger rapporteert.

In een DMARC-record betekent rua=mailto:... dat u rapporten op die bestemming aanvraagt. Volgens RFC 7489 specificeert rua de terugkoppelingsbestemming. Rapporten kunnen gegevens bevatten over authenticatie, uitlijning, verzend- en ontvangstdomeinen, aantallen en toegepaste behandeling.

Bij p=none, p=quarantine of p=reject helpt RUA het beleid beoordelen. Combineer rapporten met uw broninventaris en tests: rapportage alleen bewijst niet dat iedere legitieme stroom klaar is voor handhaving.

Wat laten RUA-rapporten zien?

RUA-rapporten zijn samenvattingen, geen kopieën van afzonderlijke berichten. Ze tonen het gerapporteerde verkeer, SPF- en DKIM-resultaten en gegevens voor DMARC-uitlijning. Maak onderscheid tussen ruwe authenticatieresultaten en de beleidsevaluatie waarin uitlijning wordt meegewogen.

Zie RUA als periodieke operationele terugkoppeling. Berichtinhoud ontbreekt, maar de gegevens kunnen helpen bij het onderzoeken van providerfouten, misbruiksignalen en verkeerde uitlijning.

TagFunctieInhoudToepassing
ruaAggregatierapporten aanvragenXML-samenvattingen per bron-IP en authenticatieresultaatMonitoring en beleidsvoorbereiding
rufFoutrapporten aanvragenDetails op berichtniveau waar ondersteundGericht foutonderzoek

Begin doorgaans met RUA en beoordeel ruf alleen bij een concrete behoefte en passende privacymaatregelen. Aggregaten worden veel gebruikt; forensische rapporten kennen beperktere ondersteuning en grotere privacyrisico's.

Voorbeeld: u gebruikt Google Workspace, een facturatie-app en een helpdesk. Rapporten kunnen deze bronnen zichtbaar maken voor zover deelnemende ontvangers hun verkeer rapporteren. Een DKIM-uitlijningsfout kan daarin opvallen. Een onbekende buitenlandse server is echter niet automatisch een spoofer; onderzoek de bron en de route voordat u conclusies trekt.

Een RUA-record publiceren

Voeg een TXT-record toe op _dmarc.yourdomain.com met een geldig rua=mailto:-adres. Monitoring is doorgaans een passende eerste stap voordat u handhaving aanscherpt.

Dit voorbeeld gebruikt optionele strict alignment. Die is niet voor iedere omgeving de beste keuze; beoordeel de vereiste exacte domeinovereenkomst:

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

Een eenvoudiger alternatief met standaard relaxed alignment staat hieronder. Publiceer niet beide beleidsrecords tegelijk:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Gebruik een aparte rapportagepostvak of analysetool. Uw gewone supportpostvak is meestal geen geschikte plek voor een stroom gecomprimeerde XML-bijlagen.

Voor TrekMail helpt Vereiste DNS-records bij de configuratie. Ingebouwde controles kunnen SPF-, DKIM- en DMARC-fouten helpen vinden, maar vervangen niet de beoordeling van iedere verzendroute.

Uw RUA-record controleren

Controleer het DNS-record rechtstreeks en kijk daarna of rapporten binnenkomen. Een verkeerde bestemming of ongeldige recordconfiguratie kan rapportage verhinderen. Ook bij correct DNS zijn rapporten niet gegarandeerd.

Gebruik dig of nslookup:

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

De respons hoort uw DMARC-record te tonen. Dit is een alternatief voorbeeld dat past binnen RFC 7489, niet een extra beleidsrecord om erbij te publiceren:

"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"

Rapporten komen vaak dagelijks, maar schema en deelname verschillen. Uitblijvende rapporten kunnen verschillende oorzaken hebben; controleer DNS, bestemming, eventuele externe autorisatie en de verwerking van bijlagen.

Een RUA-rapport gestructureerd lezen

Ruwe XML is niet direct overzichtelijk, maar u kunt een vaste volgorde volgen: bron, authenticatie, uitlijning en gerapporteerde behandeling. Beoordeel die gegevens samen, niet als losse bewijzen.

Onderzoek rapporten als volgt:

  1. Bekijk bron-IP en reverse DNS en vergelijk met uw systemen en logs. PTR of geografische locatie bewijst geen afzenderidentiteit of misbruik.
  2. Bekijk het aantal berichten. Een bron met 2 berichten kan zakelijk even kritisch zijn als een bron met 20,000; neem belang én volume mee.
  3. Controleer SPF, DKIM en uitlijning. Een ruwe pass zonder uitlijning kan onvoldoende zijn voor DMARC.
  4. Bekijk de behandeling: none bewijst geen aflevering of uitsluitend monitoring, quarantine geen vaste map en reject geen gegarandeerde blokkering. Lokale verwerking kan afwijken.
  5. Onderzoek of de bron legitiem, verkeerd ingesteld of ongeautoriseerd is. Een onbekende relay kan ook doorsturen of gedeelde infrastructuur zijn.

Google vraagt van algemene Gmail-verzenders SPF of DKIM, en van bulkverzenders beide plus DMARC en toepasselijke uitlijning met From:. RUA helpt mogelijke uitlijningsproblemen onderzoeken, maar rapportage of een authenticatiepass garandeert geen veilige inhoud of inboxplaatsing.

Veelvoorkomende foutpatronen in RUA

Een bruikbare indeling is verkeerd ingestelde legitieme verzenders, SPF-fouten bij doorsturen en mogelijk ongeautoriseerde bronnen. Onderzoek elk type zorgvuldig om echte mail niet ten onrechte te beperken.

1. Legitieme verzender, verkeerde configuratie

Een goedgekeurd systeem kan SPF-autorisatie missen, geen uitgelijnde DKIM gebruiken of beide verkeerd hebben ingesteld. Voor DMARC volstaat één geslaagde, uitgelijnde authenticatie, maar beide correct configureren kan nuttig zijn. Herstel de bron voordat u beleid wijzigt.

Bij TrekMail stemt u DNS af op de werkelijke verzender. Voor eigen SMTP raadpleegt u Eigen SMTP gebruiken. Voor de ondersteunde beheerde route beschrijft Beheerde TrekMail SMTP de verzendconfiguratie en domeinondertekening.

2. SPF faalt door doorsturen

Een doorstuurserver verandert het verbindende IP-adres, waardoor oorspronkelijke SPF kan falen. Dat bewijst niet dat de boodschap ongewenst is. Als DKIM geldig en uitgelijnd blijft na verwerking van de ondertekende gegevens volgens de canonicalisatie, kan DMARC slagen. Onderzoek dus de route in plaats van SPF-fouten blind te negeren.

Lees bij zulke routes e-mail doorsturen en domeinmail doorsturen naar Gmail. Een SPF-fout is niet automatisch een DMARC-fout.

3. Onbekende bron, mogelijk misbruik

Een onbekend IP of platform is een reden voor onderzoek, geen sluitend bewijs van spoofing. Voeg de bron niet zonder verificatie aan SPF of een toestemmingslijst toe. Controleer eerst of sprake is van een vergeten leverancier, gedeelde relay, doorsturen of werkelijk ongeautoriseerde verzending.

RUA naar een externe analysetool sturen

Een externe dienst kan XML-analyse eenvoudiger maken, maar beoordeel privacy, toegang en de benodigde DNS-configuratie. Zonder passende autorisatie kunnen rapporterende ontvangers de externe bestemming negeren.

RFC 7489 beschrijft dat bij een bestemming in rua buiten uw organisatiedomein een bevestigingsrecord in het bestemmingsdomein nodig kan zijn. De beheerder van die bestemming publiceert bijvoorbeeld:

example.com._report._dmarc.thirdparty.example.net. IN TXT "v=DMARC1"

Ontbreekt die bevestiging, dan kunnen rapportgeneratoren de externe bestemming overslaan. Volg de instructies van de analysetool en controleer de autorisatie in het bestemmingsdomein; stilte in het postvak is geen bewijs dat er geen fouten zijn.

Van p=none naar quarantine of reject

Analyseer RUA voordat u handhaving aanscherpt. Combineer rapporten met tests en een volledige zakelijke broninventaris. Neem niet aan dat resterende fouten allemaal ongewenste mail zijn of dat ontbrekende bronnen niets versturen.

Een mogelijke aanpak:

  1. Publiceer RUA met p=none.
  2. Bekijk rapporten bijvoorbeeld 1 tot 2 weken als eerste onderzoek, en langer als zeldzame of periodieke stromen dat vereisen.
  3. Herstel legitieme bronnen zodat SPF of DKIM slaagt met uitlijning.
  4. Overweeg p=quarantine na beoordeling van de bronnen, resterende fouten en gevolgen.
  5. Overweeg p=reject na voldoende tests van geldige mail en met een herstelplan.

Zonder observatie ontdekt u een fout mogelijk pas via een klant. Rapportage verkleint dat risico, maar kan zulke incidenten niet uitsluiten.

Een samenhangende aanpak voor RUA-beheer

Handmatige XML-analyse en uiteenlopende DNS-procedures per domein kosten overzicht. Een gestandaardiseerde aanpak met zichtbare instellingen kan domeinen, postvakken, migratie en verzending beter beheersbaar maken.

Versnipperde aanpakSamenhangend beheer met TrekMail
Verschillende SPF-, DKIM- en DMARC-procedures per domeinEen dashboard voor domein-DNS en postvakbeheer
Raden welke verzender de uitlijning verstoortDNS-instructies en documentatie voor gericht onderzoek
Doorstuurproblemen alleen aan SPF toeschrijvenDKIM, DMARC en doorsturen samen beoordelen
Kosten per gebruiker bij veel domeinenDe hier genoemde abonnementen vanaf $3.50/maand; controleer gedeelde opslag en actuele prijsvoorwaarden

TrekMail wordt hier niet als DMARC-analysetool gepresenteerd, maar als omgeving voor domein- en mailbeheer. Afhankelijk van het abonnement zijn eigen domeinen, IMAP-postvakken, catch-all, doorsturen, IMAP-migratie en eigen of beheerde SMTP beschikbaar. Controleer welke mogelijkheden uw configuratie omvat.

De hier genoemde abonnementen beginnen bij $3.50/maand. Nano wordt beschreven als gratis zonder kaart. Voor betaalde abonnementen kan een proefperiode van 14 dagen gelden; controleer de actuele voorwaarden, waaronder een eventuele creditcardvereiste.

Conclusie: RUA ondersteunt uw inzicht

RUA biedt terugkoppeling waarmee u authenticatiefouten, gevolgen van doorsturen en misbruiksignalen kunt onderzoeken. De dekking is gedeeltelijk. Combineer rapporten met uw eigen inventaris en tests voordat u de gereedheid voor handhaving beoordeelt.

Bij een enkel domein, vijftig of vijfhonderd domeinen helpt regelmatige analyse uw beleidsbeslissingen onderbouwen. Stel RUA in, onderzoek rapporten periodiek en herstel legitieme bronnen voordat u beleid aanscherpt.

Breng ook de rest van uw omgeving onder controle. TrekMail kan afhankelijk van het abonnement hosting voor meerdere domeinen, gedeelde opslag, provisioning via uitnodigingen en IMAP-migratie bieden. Bekijk mogelijkheden en prijsvoorwaarden op trekmail.net; een beheerplatform vervangt de beoordeling van uw verzendroutes niet.

Dit artikel delen

We gebruiken noodzakelijke technologieën om TrekMail te laten werken en te beveiligen. Door te bevestigen staat u ook beperkte analyses en advertentiemeting toe zoals beschreven in ons Cookiebeleid.

Inloggen bij TrekMail

Toegang tot je dashboard, mailboxen en DNS.

of

12 tekens wachtwoorden komen overeen

of

Herstelmail verzonden

Als er een account bestaat voor dit e-mailadres, hebben we instructies gestuurd om je wachtwoord opnieuw in te stellen.

Door verder te gaan ga je akkoord met de TrekMail- Voorwaarden en het Privacybeleid.