SPF, DKIM En DMARC bijdragen aan ander bewijsmateriaal over een e-mail. SPF beoordeelt een verbindende bron op basis van het verzendbeleid van een geëvalueerd domein. DKIM verifieert een domeingerelateerde handtekening via afgedekt berichtmateriaal. DMARC relateert een voorbijgaande geauthenticeerde identiteit aan het domein in From en past het bijbehorende beleidskader toe.
Ze werken samen omdat geen enkel groen resultaat elke identiteitsvraag beantwoordt. Een nuttige implementatie volgt het bericht via de verzendende service, DNS afhankelijkheden en het ontvangende systeem, waarbij wordt behouden wat elke controle feitelijk heeft vastgesteld.
Geef elke cheque een eigen vraag
- Mechanisme: SPF ; Vraag beantwoord: Voldoet deze verbindingsbron aan het verzendbeleid voor de geëvalueerde identiteit?; Belangrijke grens: die identiteit hoeft niet het zichtbare Van-domein te zijn
- Mechanisme: DKIM ; Vraag beantwoord: Wordt deze domein-geassocieerde handtekening geverifieerd in het gedekte berichtmateriaal?; Belangrijke grens: Uit verificatie blijkt niet dat elk onderdeel van het bericht of verzoek veilig is
- Mechanisme: DMARC ; Vraag beantwoord: Komt een kwalificerende passerende identiteit overeen met Van, en welk beoordelingsbeleid is van toepassing?; Belangrijke grens: De afhandeling van de ontvanger omvat bewijsmateriaal dat verder gaat dan DMARC
De controles zijn gerelateerd, maar het zijn niet drie exemplaren van dezelfde test. Een systeem kan alle drie de soorten DNS records publiceren terwijl een applicatie nog steeds berichten verzendt zonder de beoogde handtekening of domein uitlijning.
Volg SPF vanaf de verzendende verbinding
Voor de MAIL VAN controle van een gewoon bericht met een niet-lege envelopretouradres, RFC 7208 §2.4 specificeert dat SPF de verzendende bron evalueert met behulp van de MAIL FROM-identiteit. De ontvanger raadpleegt het gepubliceerde beleid van dat domein, dat kan verwijzen naar andere beleidsgegevens.
Dit is de reden waarom de identiteit van belang is vóór elke DNS bewerking. Een dienst toevoegen aan example.com 's SPF record kan een SPF evaluatie die feitelijk elders een servicegecontroleerd domein gebruikt, niet repareren. Bepaal eerst wat het bericht en de route gebruiken.
Onder RFC 7208 §2.3 En RFC 7208 §2.4, SPF kan ook evalueren HELO, en de specificatie ervan definieert de afhandeling voor een nul-omkeerpad. Deze gevallen rechtvaardigen niet het vervangen van een willekeurig domein uit de weergavevelden van het bericht. Bewaar de geëvalueerde identiteit met het resultaat.
Een SPF -pas creëert geen handtekening over de berichtinhoud. Het bewijsmateriaal gaat over de geëvalueerde bron en identiteit op dat ontvangstpunt.
Volg DKIM van ondertekening tot verificatie
Een zendsysteem hanteert a DKIM -handtekening met behulp van een privésleutel. Onder RFC 6376 §3.6.2.1, bij de verificatie wordt gebruik gemaakt van openbaar materiaal dat is gevonden via het ondertekeningsdomein van die handtekening en keuzeschakelaar. De privésleutel hoort thuis in het geautoriseerde ondertekeningssysteem, niet in de openbare DNS .
Zowel ondertekening als publicatie moeten werken. Een publieke sleutel met de juiste naam bewijst niet dat de applicatie zijn berichten ermee heeft ondertekend. Omgekeerd garandeert een aanwezige handtekening niet dat de sleutel ervan kan worden opgehaald of dat de verificatie na aflevering slaagt.
Onder RFC 6376 §3.7, beschermt DKIM het materiaal dat onder de gedefinieerde handtekeningberekening valt. Een gateway die na ondertekening relevante inhoud wijzigt, kan de verificatie beïnvloeden. De onderzoeksgids voor body-hash legt uit hoe je een bepaalde fout kunt traceren zonder te raden dat voor elke DKIM fout een nieuwe sleutel nodig is.
Gebruik DMARC om bewijsmateriaal aan From te koppelen
DMARC evalueert het domein in het Van-adres, met behulp van het toepasselijke beleid en uitlijningsrelaties. Onder RFC 9989 §5.3.5, een pas op berichtniveau met een toepasselijk beleid en voltooide controles kan afkomstig zijn van een passerende SPF identiteit of een passerende DKIM handtekening.
Die voorwaarde voor het slagen is geen aanbeveling om slechts één mechanisme te configureren. RFC 9989 §8 vereisten voor volledige deelname omvatten afgestemde SPF en DKIM , rapportage en beleidspublicatie. Onder RFC 9989 §7.4, domeinen publiceren p=reject mogen niet uitsluitend op SPF vertrouwen en moeten geldige DKIM handtekeningen toepassen.
Mailboxaanbieders kunnen ook hun eigen afzendervereisten opleggen. Google's richtlijnen voor bulkafzendersRoep bijvoorbeeld op voor SPF , DKIM en DMARC . Houd het resultaat op berichtniveau van een protocol gescheiden van de naleving van het volledige verzendbeleid van een provider.
Begrijp waarom de paden anders kunnen overleven
Het volgende is een synthetisch voorbeeld, geen accounttest. Een notificatieservice produceert een passerend uitgelijnd SPF resultaat en een passerend uitgelijnde DKIM handtekening voor zijn directe route.
Overweeg nu twee wijzigingen in die route:
- Een doorstuurservice verandert de verbindingsbron die de uiteindelijke ontvanger ziet. Het eerdere SPF resultaat is geen garantie voor de latere evaluatie. Als relevante ondertekende inhoud behouden blijft, kan de origineel uitgelijnde DKIM handtekening nog steeds verifiëren.
- Een gateway wijzigt ondertekende inhoud na de ondertekeningsfase. DKIM kan mislukken bij de volgende ontvanger, terwijl SPF afhankelijk is van de uiteindelijke verbindingsroute en de geëvalueerde identiteit.
Geen van beide uitkomsten is voor iedere tussenpersoon onvermijdelijk. Inspecteer de daadwerkelijke route, identiteiten en verificatieresultaten. Dit verschil verklaart waarom de twee mechanismen bruikbare, verschillende paden bieden zonder dat ze universeel betrouwbaar worden door alle doorsturing of wijziging.
Houd configuratiebewijs gescheiden van berichtbewijs
Een klein serviceniveaurecord is nuttiger dan een onverklaarde domeinbrede status. Deze fictieve acceptatiematrix illustreert het onderscheid:
- Serviceobservatie: Medewerkersmail heeft een openbare DKIM sleutel; Er is nog steeds bewijs nodig: bewijs dat het geselecteerde domein zijn echte route ondertekent en verifieert
- Serviceobservatie: factureringsmail geeft SPF door voor een providerdomein; Er is nog steeds bewijs nodig: de relatie met From en elk uitgelijnd DKIM pad
- Serviceobservatie: Marketingmail heeft een geldig DMARC beleid; Er is nog steeds bewijs nodig: daadwerkelijke ondertekening, authenticatie en beleidscontextbewijs
- Serviceobservatie: een ontvangen bericht doorstaat de relevante controles; Bewijs nog steeds nodig: de bedrijfseigenaar en het goedgekeurde gebruik, afzonderlijk beoordeeld
Bewaar voor elke service de ondersteunde configuratie, belangrijke identiteiten en een representatief origineel ontvangen bericht. Onder RFC 8601 §7.1, gebruik vertrouwde ontvangstsysteemresultaten; een pass-bewering ingevoegd door een niet-vertrouwde afzender kan het werk van de ontvanger niet vervangen.
De afzender inventaris verbindt deze records met eigenaren. De DMARC -opnameworkflow voegt publicatie toe aan bericht- en rapportageverificatie.
Behoud de grenzen van het gecombineerde resultaat
Als het handtekeningbereik in RFC 6376 §3.7 en ontvangerafhandeling RFC 9989 §5.4 laten zien, coderen deze controles het bericht niet voor de ontvanger, stellen de waarheid van de inhoud niet vast en garanderen geen plaatsing in de inbox. Transportbeveiliging en bescherming van gevoelige berichtinhoud zijn afzonderlijke aandachtspunten.
Een gecompromitteerde geautoriseerde service kan nog steeds geverifieerde e-mail verzenden. Op dezelfde manier bewijst een geldig technisch resultaat niet dat de organisatie dat specifieke applicatieaccount of bedrijfsverzoek heeft goedgekeurd.
De bruikbare gecombineerde uitkomst is daarom nauwkeurig: de ontvanger evalueerde de feitelijke bron- en handtekeningidentiteiten, vond het vereiste uitgelijnde doorgangspad voor Van en overwoog het relevante beleid. Bewaar dat bewijsmateriaal bij de dienst en route die het heeft geproduceerd. Drie geconfigureerde records vormen een startafhankelijkheid; geverifieerde, onderhouden communicatie is het bedrijfsresultaat.
Zorg voor een beperkte conclusie
In de fictieve acceptatiematrix sluit een publieke sleutel alleen publicatiebewijs af. Bij een SPF -pas voor een providerdomein moet de relatie met Van nog steeds zijn aangevinkt. Voor elke geclaimde DMARC pas dient u het toepasselijke beleid en het specifieke uitgelijnde passeerpad te behouden, en vervolgens accountgoedkeuring en inhoudveiligheid gescheiden te houden. Er is hier geen serviceconfiguratie of berichtentest uitgevoerd.