En leverandør kan sannferdig rapportere at e-posten går DKIM mens du signerer med et domene som ikke er relatert til din synlige Fra-adresse. Hvis målet er å autentisere organisasjonens forfatterdomene for DMARC, be om en støttet justert DKIM identitet og definer hvordan den skal verifiseres. En generisk forespørsel om å aktivere DKIM er for tvetydig.
Begynn med en kontrollert melding fra den faktiske tjenesten og ruten. Bevar den rå mottatte formen og det pålitelige mottakerresultatet. Dette gir leverandøren et konkret identitetsmisforhold å undersøke uten å anta at produktet tilbyr spesialtilpasset domenesignering på hver plan eller transport.
Oppgi identitetene separat
Ta opp det synlige Fra-domenet, konvoluttavsender identitet, SPF resultat, hvert DKIM d-domene, velger og verifiseringsresultat. Sette justering i et eget felt. RFC 9989 §4.4 behandler autentiseringssuksess og identifikatorjustering som ulike krav; et urelatert bestått DKIM domene blir ikke justert fordi det tilhører avsenderleverandøren.
Streng DKIM justering krever et eksakt domenematch under RFC 9989 §3.2.10. Avslappet justering sammenligner organisasjonsdomener under RFC 9989 §4.10.2. Spør hvilket d-domene leverandøren faktisk kan sende ut, og sammenlign det deretter med ditt tiltenkte From-domene og policy. Ikke be om en bestemt DNS verdi før leverandøren bekrefter den støttede identiteten og kontokonfigurasjonen.
Vis den villedende pasningen tydelig
Illustrerende arbeidsark for identitet:
- Kun leverandøridentitet: From= brand.example ; d=provider.example; antatt DKIM pass; ikke justert, forutsatt at disse er urelaterte organisasjonsdomener.
- Kundeidentitet: Fra= brand.example ; d=brand.example; antatt DKIM pass; eksakt domenematch.
Anta resultatene vist for formålet med dette eksemplet. De er ikke testbevis for mottatt melding. I det første tilfellet kan DMARC fortsatt passere gjennom justert SPF , så ikke gjør krav på en total DMARC feil uten å sjekke konvoluttidentiteten og SPF resultatet. Regnearket isolerer DKIM egenskapen som forespørres.
Send en nøyaktig teknisk forespørsel
Spør leverandøren om det navngitte produktet, kontoplanen og senderuten støtter et kundekontrollert signeringsdomene som er på linje med den tiltenkte Fra-adressen. Ta med API-, SMTP , kampanje- eller transaksjonsrutedetaljer etter behov. Spør om atferden er forskjellig for aliaser, underdomener og delegerte brukere.
Be om nøyaktige velgernavn, DNS posttyper og -verdier, aktiveringstrinn og verifiseringsprosedyre. Spør hvem som kontrollerer de private nøklene, hvordan rotasjon utføres og hva som skjer med verifiseringsposter etter avstigning. Hvis en CNAME er nødvendig, bekrefter målet og omfanget i stedet for å erstatte det med en gjettet TXT post.
Del et redigert identitetsark eller kontrollert testmelding i stedet for en kundemelding som inneholder unødvendig personlig innhold. En forespørsel om leverandørstøtte trenger ikke en privat signeringsnøkkel eller postbokspassord. Hold sensitiv legitimasjon utenfor vanlige billetter.
Enig akseptkriterier før du endrer DNS
En nyttig aksepttest krever en ny melding fra den faktiske produksjonsekvivalente ruten, en bestått ment DKIM signatur hos en pålitelig mottaker og justering under den relevante policyen. Test viktige meldingsformater og ruter separat. Bare å publisere DNS -poster eller se et verifisert merke er ufullstendig bevis.
Hvis leverandøren legger til sin egen signatur også, inspiser begge. Flere signaturer er tillatt under RFC 6376 §4.2, og en passerende justert signatur leverer DKIM banen under RFC 9989 §4.4.1. Registrer velgeren og d-domenet som faktisk er observert i stedet for å stole på den første signaturen et overskriftsverktøy viser.
Håndter funksjoner som ikke støttes ærlig
Hvis tilpasset justert DKIM ikke er tilgjengelig, spør du om de støttede alternativene og deres begrensninger. En passerende justert SPF bane kan tilfredsstille DMARC for en gjeldende direkte rute, men den skaper ikke justert DKIM eller garanterer motstandskraft gjennom videresending; RFC 7208 §10.3 diskuterer SPF mediator begrensninger. En annen støttet sendeidentitet eller tjeneste kan være nødvendig for organisasjonens krav.
Lukk forespørselen med avtalt identitet, rute, DNS eierskap, nøkkelforvalter og bevis for mottatt melding. Hvis en funksjon fortsatt ikke støttes, må du registrere den eksplisitt. Resultatet bør være et verifiserbart sendingsdesign i stedet for et løfte om at ethvert DKIM pass beviser merkevareidentiteten din.
Registrer neste avgjørelse
Klargjør disse feltene før du kontakter support: produkt og rute; ment Fra; observert d/s og pålitelig resultat; nødvendig justeringsmodus; evne spørsmål; bedt om genererte DNS instruksjoner; nøkkeldepot; rotasjons- og utgangsspørsmål; og akseptkriterier. Rediger unødvendige personopplysninger. Dette er en sjekkliste for teknisk forespørsel, ikke en sendt billett, en godkjent DNS endring eller bevis på konfigurert tjeneste.