Et domænealias ændrer, hvordan en adresse kan bruges eller modtages i en tjeneste. Det definerer ikke i sig selv det domæne, der er placeret i en udgående DKIM signatur. Før du bruger et alias til kundemail, skal du undersøge en meddelelse, der sendes gennem den tilsigtede rute, og bestemme, hvilken identitet tjenesten underskriver.
Alias er også et overbelastet produktudtryk. Det kan beskrive en alternativ postkasseadresse, et domæne knyttet til en lejer eller en afsenderidentitet på applikationsniveau. Denne arbejdsgang gælder for den resulterende meddelelse og DNS bevis. Se den aktuelle dokumentation for den bestemte aliasfunktion, før du antager, at den understøtter afsendelse eller brugerdefineret domæne DKIM.
Adskil modtagekonfiguration fra afsendende identitet
Bestem først, hvad aliaset er beregnet til at gøre. En adresse, der modtager beskeder i en eksisterende postkasse, bliver muligvis aldrig autoriseret til udgående brug. Hvis afsendelse understøttes, skal du bestemme, om tjenesten beholder aliasset i Fra, omskriver det til den primære adresse eller dirigerer det gennem en anden afsender.
Registrer den synlige Fra-adresse efter levering, ikke kun den adresse, der er valgt i skrivevinduet. Optag også ethvert afsenderfelt og kuvertidentitet, men forveksle dem ikke med DKIM 's sd-domæne. RFC 6376 §3.5 definerer d-signeringsdomænet, adskilt fra meddelelsesforfatterens adresse. RFC 9989 §4.4 bruger forfatterdomænet og godkendte identifikatorer til justering.
Læs hver signatur på en kontrolleret besked
Send en test fra aliaset ved hjælp af den samme klient, API eller delegerede postkasserute som produktionen. Eksporter den modtagne besked uden at redigere den. Identificer hver DKIM-Signature , dens d- og s-værdier og den betroede modtagers resultat. En tjeneste kan tilføje både en udbydersignatur og en kundedomænesignatur; den første, der vises af et værktøj, er muligvis ikke den, der er relevant for DMARC.
For hver bestået signatur skal du vurdere justeringen med det modtagne Fra-domæne. Strict mode skal have et nøjagtigt domænematch under RFC 9989 §3.2.10. Afslappet tilstand tillader det samme organisatorisk domæne under RFC 9989 §4.10.2. To adskilte registrerede domæner stemmer ikke overens, blot fordi det ene er et alias for det andet i en administrationsportal.
Brug et lille identitetsark
Illustrerende tilfælde, forudsat at der er distinkte organisatoriske domæner og en gældende DMARC -politik: Den primære adresse er person@company.example , mens det udgående alias er person@newbrand.example . Modtageren ser From på newbrand.example og en forbigående signatur med d=company.example. Denne signatur stemmer ikke overens med newbrand.example . Hvis en anden forbigående signatur bruger d=newbrand.example, leverer den anden signatur en tilpasset DKIM sti.
Optag begge udfald i stedet for at kalde hele beskeden usigneret eller sige, at DKIM er i stykker. En gyldig signatur under det primære domæne er stadig gyldig DKIM . Den manglende egenskab er justering for aliaset. Vurdere SPF separat før tildeling af det samlede DMARC resultat. Dette regneark er et syntetisk eksempel, ikke bevis for nogen tjenestes aliasadfærd.
Anmod om det understøttede middel
Spørg, om udbyderen kan signere aliasmail med aliasdomænet, og om det kræver tilføjelse af domænet som en særskilt afsenderidentitet. Få dens aktuelle DNS postnavne, posttyper og værdier. Bekræft, hvem der kontrollerer DNS zonen, og om den foreslåede ændring er i konflikt med en eksisterende vælger.
Kopier ikke en offentlig nøgle i det primære domæne manuelt, og antag, at tjenesten begynder at bruge en ny d-værdi. DNS udgivelse kan ikke instruere en vilkårlig underskriver til at ændre identitet. Sendekonfigurationen og det offentliggjorte verifikationsmateriale skal stemme overens.
Behold aliaset i livscyklusanmeldelser
Gentag testen for svar, mobilklienter og applikationsgenererede beskeder, når disse ruter bruges. Opbevar et selektor-til-udbyder-kort med aliasets virksomhedsejer og en dateret prøve. Ved migrering eller pensionering skal du bekræfte, om andre identiteter stadig er afhængige af den samme udbyder, før du fjerner delegerede poster.
Lukningserklæringen skal sige, hvilket alias og hvilken rute, der blev testet, hvilket d-domæne, der bestod, og om det passede. Hvis et produkt ikke kan levere den påkrævede identitet, skal du dokumentere denne begrænsning og vælge et understøttet afsendelsesdesign i stedet for at rapportere aliaset som autentificeret uden kvalifikationer.
Optag den næste beslutning
Brug én række pr. faktisk rute: anmodet alias, modtaget fra, hvert d/s-par, betroet resultat, justeringstilstand og resterende mellemrum. Et primært domænepas med et ikke-relateret alias From er gyldigt DKIM , men ikke justeret DKIM . Kald ikke hele beskeden for en DMARC fejl, før SPF og den gældende politik er evalueret. Ingen udbyder-specifik alias-kapacitet eller live-resultat hævdes her.