En udbyder kan udsende gyldig DKIM signaturer uden at understøtte din organisations signeringsdomæne. Denne begrænsning har betydning, når tjenestens signatur ikke stemmer overens med det domæne, kunderne ser i From. Etabler den nøjagtige begrænsning, før du ændrer DNS eller udskifter tjenesten.
Bekræft, hvad udbyderen faktisk understøtter
Bed om aktuel dokumentation, der dækker kontoniveauet, sendegrænsefladen og domænetypen, du bruger. En bekræftet afsenderadresse, tilpasset sporingsdomæne eller brandet retursti er ikke bevis for tilpasset DKIM understøttelse. Få en rå modtaget besked fra den faktiske rute, og optag hver signaturs d- og s-værdier og den betroede modtagers verifikationsresultater.
RFC 6376 definerer d som signeringsdomænet og bruger s med dette domæne til at lokalisere verifikationsdata. Udgivelse af en nøgle under dit eget domæne kan ikke ændre d på en signatur, som udbyderen opretter. EN CNAME har ligeledes brug for en udbyder-understøttet signeringskonfiguration; et DNS alias alene instruerer ikke en tjeneste til at underskrive for dig.
Kontroller, om der findes en anden justeret sti
Med en gældende politik og ingen uløste evalueringsfejl, DMARC kan passere gennem enten en passerende justeret SPF eller DKIM resultat. Evaluer tjenestens faktiske MAIL FRA domæne og SPF resultat separat. En understøttet tilpasset retursti kan give tilpasset SPF , selv når tilpasset DKIM ikke er tilgængelig. Bekræft justering tilstand og domæneforhold; en udbyderejet returvej stemmer ikke overens, blot fordi du betaler for kontoen.
Illustrativt tilfælde: mail bruger From= notices@brand.example og passerer DKIM med d=vendor.example. Dens MAIL FROM-domæne er bounce.brand.example og SPF pas. Hvis man antager, at forholdet mellem organisation og domæne er kvalificeret, kan en afslappet SPF tilpasning tilfredsstille DMARC . Med streng SPF justering er underdomænet ikke et eksakt match. Dette er et syntetisk beslutningseksempel, ikke et krav om nogen leverandør.
RFC 9989 afsnit 7.4 og 8 kræver domæneudgivelse p=reject ikke udelukkende at stole på SPF for et DMARC -pas og at anvende gyldige DKIM signaturer. Et SPF pas med direkte levering er derfor ikke et komplet p=reject implementeringsdesign. Løs den manglende aligned-DKIM-sti, før du behandler tjenesten som klar til denne politik.
Beskriv ikke SPF som en identisk erstatning for justeret DKIM . Videresendelse kan ændre den forbindende IP og forstyrre SPF , mens en intakt justeret DKIM signatur kan overleve. Evaluer de ruter, der er vigtige for dine brugere, i stedet for at stole på en test af direkte levering.
Sammenlign understøttede alternativer
De praktiske valg er at beholde tjenesten med en dokumenteret aligned-SPF-sti, hvor den er kompatibel med domænets politik og accepterede begrænsninger, flytte afsendelse til en tjeneste, der understøtter den nødvendige DKIM identitet, eller bruge et understøttet autoriseret relæ, der signerer den endelige besked. Hver kræver test og en ejer. Et relæ skal bevare den nødvendige applikationsadfærd og underskrive efter indholdsændrende behandling; blot tilføjelse af en ikke-relateret signatur løser ikke justering.
Ændring af det synlige Fra-domæne er en anden produktbeslutning, ikke en skjult teknisk rettelse. Det påvirker genkendelse og svar, og erstatningsdomænet skal stadig have gyldig godkendelse. Undgå at svække hele organisationens DMARC -politik bare for at skjule én udokumenteret afsendelsesvej.
Registrer den accepterede begrænsning
Behold udbyderens kompetenceerklæring, modtagne meddelelsesbeviser, valgte tilpasningssti, virksomhedsejer og anmeldelsesudløser. Test transaktionsmeddelelser og videresendelsesscenarier, der er relevante for tjenesten. Hvis der stadig er en begrænsning, angiv eksplicit eksponerings- og migrationsbeslutningen. Fuldførelse betyder en bekræftet understøttet rute eller en ejet undtagelse, ikke et grønt DNS skærmbillede.
Brug en udfyldt beslutningsjournal
Overvej denne eksplicit fiktive to-rute matrix. Billing API A har From= brand.example , d=vendor.example, vælger vendor1, MAIL FROM= bounce.brand.example , rå SPF -pas og rå DKIM pas. Antag afslappet SPF justering og den angivne delte organisatorisk domæne: dens succesfulde sti er kun justeret SPF . Erstatningsrelæ B har From= brand.example , d=brand.example, selector relay2 og MAIL FROM= vendor.example , med begge råkontroller bestået: dens succesfulde sti er kun justeret DKIM . Hver kapacitet og hvert resultat her er antaget, ikke observeret fra en udbyder.
Disse feltsammenligninger forklarer de forudsatte resultater; der kræves ingen udførelse af armaturet eller udbyderbekræftelse. Billing API A illustrerer et SPF-only-resultat, ikke en acceptabel eneste sti for en p=reject implementering. Inden du implementerer begge designs, skal du indhente daterede rutespecifikke udbyderinstruktioner, genererede DNS værdier, rå modtaget mail og et betroet modtagerresultat. Sammenlign tilsigtede og observerede identiteter, test kritiske formater og relevant videresendelse, og notér, at ejeren accepterer enhver resterende begrænsning. Disse acceptfelter i den virkelige verden forbliver afventende.
Vælg det understøttede næste trin
- Ukendt kapacitet: Få aktuelle instruktioner for det nøjagtige kontoniveau og afsendelsesrute; gæt ikke DNS værdier.
- Kun tilpasset SPF tilgængelig: optag grænser for direkte levering og den aktuelle politik; Brug den ikke som den eneste DMARC -sti til p=reject.
- Understøttet signeringsrelæ tilgængeligt: verificere applikationsadfærd, endeligt indhold, justeret d= og nøgledepot før migrering.
- Ingen passende sti: Skift udbyder eller tag en eksplicit produktbeslutning om From-identitet.
- Lukning: gem modtagne meddelelsesbeviser, resterende begrænsninger, ansvarlig ejer og næste gennemgang.