Hoe implementeert een productteam DMARC in Cloudflare op een veilige manier?

Scheid Cloudflare-DNS van de afzenderconfiguratie

Cloudflare kan de gezaghebbende DNS verzorgen terwijl een andere provider de e-mail van je applicatie verzendt en ondertekent. Leg die grenzen vast voordat je iets wijzigt. De zone publiceert het DMARC-beleid als TXT-record; elke e-mailprovider beheert zijn return path, DKIM-ondertekeningsdomein en selector, verificatie en soms rapportage; de applicatie bepaalt tenant, berichtklasse, ontvanger, template, zichtbaar From-adres en providerpad. Een geldig DNS-record kan geen onbevoegde afzender, ontbrekende DKIM-handtekening, niet-uitgelijnd return path of From-waarde van een andere tenant herstellen. Inventariseer productie-, staging-, support-, facturerings-, identiteits-, monitoring-, CRM-, marketing- en persoonlijke mailsystemen per zichtbaar From-domein. Wijs aan elk systeem een eigenaar en een contactpersoon voor terugdraaien toe, en classificeer onbekende bronnen in rapporten voordat je de handhaving verhoogt.

Vraag de beleidsnaam op die ontvangers evalueren

Voor mail van alerts@notify.example.test begin je met TXT op _dmarc.notify.example.test. Publiceer het beleid niet per ongeluk op de websitehost, de mail exchanger, de DKIM-selector of de return-path-naam. De huidige DMARC-discovery kan een toepasselijk beleid van het organisatiedomein of het public suffix selecteren wanneer het auteursdomein geen geldig record heeft; leg daarom zowel de opgevraagde naam als het geselecteerde beleidsdomein vast. Vraag bestaande gezaghebbende en recursieve antwoorden op voordat je Cloudflare opent. Meerdere beleidsrecords op dezelfde naam, een onjuiste tag-syntaxis of een conflicterend CNAME kunnen het resultaat onbruikbaar maken. Leg de oude inhoud, TTL, resolveruitvoer, eigenaar en verwachte waarde na de wijziging vast, zodat terugdraaien exact is en niet tijdens een incident gereconstrueerd hoeft te worden.

Maak één gecontroleerd TXT-record aan in Cloudflare

Open het juiste Cloudflare-account en de juiste zone, ga naar DNS Records, kies Add record en selecteer TXT. Gebruik _dmarc als relatieve naam voor een beleid op het apex-domein of het exacte _dmarc-label voor het bedoelde subdomein. Voer één gecontroleerde waarde in zonder inconsistente aanhalingstekens; Cloudflare documenteert dat het omsluitende aanhalingstekens toevoegt aan nieuwe TXT-inhoud die zonder aanhalingstekens is opgeslagen. Kies een TTL die past bij uitrol en herstel, voeg zo nodig een privacyvriendelijke wijzigingsreferentie toe en sla pas op nadat je zone, naam, oude waarde en nieuwe waarde hebt gecontroleerd. TXT-beleidsrecords zijn DNS-gegevens, geen geproxiede webroutes. Als een hostingpartner of een andere gezaghebbende provider de zone beheert, voer de wijziging dan daar uit in plaats van aan te nemen dat het Cloudflare-dashboard gezaghebbend is.

Bouw de DMARC-waarde op uit expliciete beslissingen

Een record in de observatiefase kan beginnen met v=DMARC1; p=none en een goedgekeurde URI voor aggregate-rapportage, maar dat is een voorbeeld en geen universele waarde. Zet de versie vooraan, kies het gevraagde beleid bewust en autoriseer elke rapportagebestemming. Beoordeel subdomeinbeleid, alignment-modus, percentage en rapportagetags alleen wanneer er een gedocumenteerde eis en een actuele interpretatie van de standaard is. Kopieer geen voorbeeld van een leverancier met de rua-mailbox van iemand anders, en spring niet naar p=reject omdat de syntaxis valideert. Een geldig record drukt uit welke afhandeling je van ontvangers vraagt; het bewijst niet dat SPF of DKIM authenticeert, dat een geauthenticeerde identifier uitgelijnd is met het From-domein, dat alle legitieme verzendpaden zijn geïnventariseerd of dat een bericht een inbox heeft bereikt.

Verifieer SPF- en DKIM-alignment op echte berichten

Verstuur gecontroleerde voorbeelden vanuit elk applicatiepad naar ontvangers van wie je de ruwe headers kunt inspecteren. Leg zichtbaar From, SMTP MAIL FROM, verzendend IP-adres, DKIM d=-domein en selector, Authentication-Results, provider-identifier, berichtklasse, omgeving en tijdstip vast. DMARC kan slagen via uitgelijnde geauthenticeerde SPF of via een uitgelijnde geverifieerde DKIM-handtekening. SPF evalueert een SMTP-identiteit en kan bij doorsturen veranderen; DKIM verifieert een handtekening over geselecteerde inhoud. Geen van beide vervangt autorisatie in de applicatie. Test relaxed of strict alignment bewust, inclusief subdomeinen en failoverroutes. Acceptatie door de provider-API, acceptatie door de bestemmingsserver, een DMARC-pass, plaatsing in de mailbox en engagement zijn verschillende observaties. Houd die toestanden gescheiden, zodat een geslaagde API-call of een groene beleidsindicator nooit wordt opgewaardeerd tot sterker bewijs van bezorging.

Valideer DNS en rapporten buiten het dashboard

Vraag na het opslaan bij de gezaghebbende nameservers van Cloudflare en bij meerdere onafhankelijke recursieve resolvers het TXT-record op de exacte _dmarc-naam op. Bewaar ruwe antwoorden, geselecteerd beleidsdomein, TTL, resolver, tijdstempel en parserresultaat. Bevestig dat er precies één bruikbaar record is, dat v=DMARC1 vooraan staat, dat vereiste waarden geldig zijn en dat rapportage-URI's zijn goedgekeurd. Herhaal dit na het verwachte cachevenster. Verstuur opnieuw gecontroleerde berichten en inspecteer de headers bij de ontvanger. Cloudflare documenteert DMARC Management als een manier om verzendbronnen en geaggregeerde SPF-, DKIM- en DMARC-resultaten te bekijken, maar rapporten zijn vertraagde observaties die door ontvangers worden aangeleverd, geen volledige live telling. Correleer ze met bewijs van de provider. Pauzeer bij onenigheid tussen resolvers, ontbrekend verkeer met lage frequentie, onbekende legitieme bronnen, niet-uitgelijnde gecontroleerde berichten of onverwachte veranderingen in het rapportvolume.

Behandel Cloudflare DMARC Management als een DNS-wijziging

Volgens Cloudflare kan DMARC Management bij het inschakelen voorstellen om een record aan te maken wanneer er nog geen bestaat, of een aggregate-rapportageadres van Cloudflare toe te voegen aan een bestaande rua-tag. Beoordeel die voorgestelde wijziging zoals productie-infrastructuur: exporteer de vorige waarde, bevestig dat bestaande bestemmingen bewust blijven, verifieer de domeinscope en houd terugdraaien mogelijk. De activeringsdocumentatie beschrijft ook de huidige scope op het apex-domein en een kanttekening bij een extern SPF-record. Leid er niet uit af dat de functie een elders gehost SPF-pad veilig kan herschrijven. Een vermelde bron of een vermeld IP-adres bewijst niet welke applicatie, tenant of persoon het heeft geautoriseerd, en het ontbreken van een rij bewijst niet dat er geen verkeer is. Gebruik de weergave om bewijs te verzamelen, en bewaar daarnaast bewijs uit gezaghebbende DNS, ruwe berichten, providerlogs en applicatie-audits.

Verhoog de handhaving stapsgewijs op basis van bewijs

Observeer lang genoeg om elke legitieme afzender, berichtklasse, weekdagpatroon, batchjob, failoverroute en workflow met lage frequentie te dekken. Classificeer bronnen als eigen, goedgekeurde leverancier, doorgestuurd, onbekend of misbruik. Herstel de alignment voor legitiem verkeer voordat je een strengere behandeling aanvraagt. Een go/no-go-controle moet geldige DNS, geslaagde gecontroleerde berichten, voldoende uitgelijnde dekking, geen onbekende legitieme bronnen, eigenaarschap van incidenten, paraatheid van support en een geteste terugdraaiprocedure omvatten. Verhoog het beleid alleen via een afgebakende, goedgekeurde wijziging en monitor zowel authenticatiefouten als bedrijfsfouten. Draai terug of pauzeer bij afwijzing van legitieme berichten, verlies van rapporten, onverwachte bronnen, inconsistentie tussen resolvers, een providermigratie of verrassingen in de overerving door subdomeinen. Wijzig SPF, DKIM en DMARC waar mogelijk afzonderlijk, zodat duidelijk blijft waardoor een regressie ontstaat.

Vermijd veelvoorkomende DMARC-fouten in Cloudflare

Veelvoorkomende fouten zijn de verkeerde zone bewerken, publiceren op de verkeerde _dmarc-naam, twee beleidsrecords laten staan, kapotte aanhalingstekens toevoegen, een goedgekeurde rua-lijst vervangen, aannemen dat het beleid voor apex en subdomein identiek is, en p=reject gebruiken voordat zelden verzendende afzenders zichtbaar zijn. Een andere fout is de opgeslagen of gedetecteerde toestand in het dashboard behandelen als bewijs op berichtniveau. Gebruik exacte diffs, gecontroleerde ontvangers, onafhankelijke queries, ruwe headers en incidentlogs die per ontvanger zijn afgebakend. Houd klantadressen, berichtinhoud, API-sleutels en onbegrensde rapportgegevens buiten tickets en analytics. Als gezaghebbende en gecachte antwoorden langer inconsistent blijven dan gepland, een verwachte afzender ontbreekt of een echt bericht niet door de alignment komt, stop dan en diagnosticeer delegatie, cache, recordsyntaxis, afzenderinventaris, SPF en DKIM afzonderlijk.

Hoe SendHQ past

De veilige grens is providerneutraal: de applicatie autoriseert een bericht, de verzendprovider authenticeert het, Cloudflare publiceert of analyseert de DNS-status en ontvangers evalueren het bericht. Vertrouw op de actuele officiële documentatie van Cloudflare, de huidige DMARC-standaard, waargenomen DNS-antwoorden en bewijs uit gecontroleerd ontvangen berichten.

Veelgestelde vragen

Bronnen

• DNS-records beheren — Cloudflare
• Typen DNS-records in Cloudflare — Cloudflare
• Overzicht van Cloudflare DMARC Management — Cloudflare
• Cloudflare DMARC Management inschakelen — Cloudflare
• DMARC-statistieken in Cloudflare bekijken — Cloudflare
• RFC 9989: DMARC — RFC Editor
• RFC 7208: SPF — RFC Editor
• RFC 6376: DKIM — RFC Editor