Velg forretningsidentitet før du endrer DNS
EngageLab Email har både tilpasset domenesending og en vertsdelt rute for delt domene. Dette er forskjellige identitetsvalg, ikke utskiftbare snarveier. Bestem om mottakere må se organisasjonens domene. En vellykket test fra en leverandøreid adresse viser ikke at bedriftsdomenet ditt er autentisert. Registrer nøyaktig applikasjon, synlig avsenderadresse og meldingstype før du åpner DNS innstillinger.
Dokumentasjonen for sendeinnstillinger beskriver et innledende testdomene, en separat funksjon for delt domene og tilpassede forretningsdomener. Den delte ruten bruker et underdomene av base.engagelab.com , med den synlige adressen på det vertsbaserte navneområdet. For utrulling av forretningsdomene bruker du arbeidsflyten for tilpasset domene. Ikke behandle tjenestens påstander om delt omdømme eller gratis kvoter som en leveringsgaranti eller en kontraktsrett. Bekreft kommersielle grenser separat.
Registrer den domenespesifikke konfigurasjonen
I Innstilling, domene, opprett eller velg avsenderdomenet og hent gjeldende DNS instruksjoner. EngageLab-lister SPF, DKIM og MX etter behov, med DMARC valgfritt for sine valideringstilstander. Ubekreftet betyr at en nødvendig sjekk mangler; Brukbar betyr at de nødvendige sjekkene består; Verifisert betyr at alle viste sjekker består. Disse etikettene beskriver produktvalidering, ikke en dom fra mottatt melding.
La DNS eieren gjennomgå hele den foreslåtte posten før publisering. En MX endring påvirker innkommende ruting på eiernavnet. Hvis det foreslåtte navnet allerede mottar e-post fra ansatte, pause og løs kollisjonen i stedet for å erstatte e-postutvekslerne. Et dedikert sendenavnsområde kan redusere kollisjoner, men dets egnethet må bekreftes mot den faktiske kontokonfigurasjonen. Registrer eiernavn, type, verdi, TTL, gammel verdi og årsak for hver endring.
Domain API-dokumentasjonen viser SPF , DKIM , MX og DMARC konfigurasjonsverdier og bekreftelsesresultater per post. Det er nyttig for å krysssjekke hva kontoen forventer, ikke som en kilde til gjenbrukbar prøvelegitimasjon eller DNS nøkler. Kopier verdier fra ditt eget domeneobjekt. Aldri gjenbruk eksempeldomenets offentlige nøkkel, anta at den er velger gjelder for deg, eller vedta dens eksempelretningslinjer for avvisning uten å gjennomgå dine andre legitime e-poststrømmer.
Publiser uten å erstatte urelaterte tillatelser
Hos den autoritative DNS verten legger du til de nøyaktige nødvendige posttypene og eiernavnene. DNS paneler er forskjellige når det gjelder om de legger til sonenavnet, så inspiser det resulterende fullt kvalifiserte navnet. En feilplassert velger kan etterlate en post som ser plausibel ut som mottakere aldri spør etter. Ta vare på fullstendige nøkkeldata og unngå å legge til andre data på en CNAME eier.
Der SPF allerede eksisterer, avstem den nye autorisasjonen med den enkelte SPF -policyen. Ikke lag en ny v=spf1 -policy med samme navn. Evaluer den kombinerte policyens DNS-oppslagsavhengigheter i stedet for bare å telle synlige inkluderer. Behold aktive avsendere og den etablerte endelige kvalifiseringen med mindre domeneeieren har godkjent en endring separat. Ingen av disse trinnene tillater utvidelse av tillatelser til urelaterte e-posttjenester.
Spør etter autoritative poster og sammenlign dem med de lagrede kontoinstruksjonene. Kjør deretter EngageLab-valideringen på nytt etter at cachene har hatt tid til å utløpe. Dokumentasjonens estimerte DNS forsinkelse er ikke en universell frist. Et feil autoritativt svar vil ikke reparere seg selv ved å vente. Hvis plattformen og autoritative svar er uenige, bevar begge med tidsstempler før du feilsøker resolver-bufring.
Bind søknaden til den tiltenkte ruten
EngageLab instruerer også brukere til å bruke forskjellige sendedomener med forskjellige primære domener for trigger- og bulkpost, for å forhindre at bulkrestriksjoner forsinker triggermeldinger. Bekreft denne separasjonen med kontoeieren før du binder API_USER-rutene; to underdomener av samme primærdomene oppfyller ikke den angitte instruksen. Registrer det godkjente domenet for hver meldingstype.
Det dokumenterte API_USER-oppsettet knytter et avsenderdomene og en trigger- eller batchmeldingstype. Bekreft at applikasjonen bruker den tiltenkte tilknytningen. Å teste en legitimasjon mens produksjonen bruker en annen kan gi et misvisende grønt resultat. Oppbevar hemmeligheter i godkjent hemmelig lagring, ikke denne bevisposten, skjermbilder eller støttevedlegg.
Lag et lite rutearbeidsark: applikasjon, miljø, API- eller SMTP -transport, meldingstype, bundet domene, synlig Fra-adresse, eier og tilbakeføringsrute. Test den produksjonsekvivalente kodebanen med kontrollerte mottakere. Ikke drag ut av at en forhåndsvisning, testkonto eller ikke-relatert applikasjon beviser integrasjonen. For tidssensitiv transaksjonspost, test utløserarbeidsflyten eksplisitt i stedet for å stole på en vellykket massekampanje.
Bevis samsvar med en mottatt melding
Behold den opprinnelige mottatte meldingen og den pålitelige mottakeren Authentication-Results. Registrer fra, konvoluttdomene, hver DKIM d= og s= verdi, SPF resultat, DKIM resultat og DMARC resultat. SPF autentiserer konvoluttdomenet; DKIM autentiserer signeringsdomenet sitt. DMARC trenger minst én passerende autentisert bane justert med det synlige Fra-domenet i gjeldende modus. Autentisering garanterer ikke plassering av innboks.
Syntetisk resonnementeksempel, ikke en EngageLab-standard: Fra receipts@example.com , envelope bounce@other.example.net og en bestått signatur med d=example.com. SPF for other.example.net stemmer ikke overens med example.com , men signaturen gir nøyaktig DKIM justering. Hvis signaturen er fraværende eller ugyldig, støttes ikke det antatte DMARC passet. Skriv identitetene ved siden av dommene slik at et bart ord som pass ikke kan skjule feil domene.
Lukk endringen og bevar gjenopprettingen
Hvis verifiseringen mislykkes, isoler om problemet er DNS , domenetilknytning eller meldingssignering. Gjenopprett den kjente applikasjonsruten i stedet for å svekke hele domenets DMARC policy. Ikke slett nøkler som fortsatt brukes av meldinger i kø. Etter suksess, behold den godkjente DNS diff, kontovalidering, ruteregneark og meldingsbevis, og planlegg en gjentatt sjekk etter en transport- eller domeneendring.
Dette er en dokumentarkonfigurasjonsveiledning. Ingen EngageLab-leietaker ble endret, ingen produksjons- DNS ble målt og ingen reell tabell for mottatte meldingsidentitet ble samlet inn for dette utkastet. Kontrollene ovenfor er akseptarbeid for operatøren, ikke påståtte resultater. Menneskelig godkjenning og en rutespesifikk test er fortsatt nødvendig før produksjonen lanseres.
Løs en domenebindingsmismatch før utgivelse
Skriftlig sak EL-01 antar at konsollen merker notify.example.com Brukbar, mens produksjonsutløserapplikasjonen forblir bundet til et vertsdelt delt domene API_USER. Den tiltenkte Fra er receipts@notify.example.com ; de faktiske resultatene fra Fra, konvoluttidentitet og signatur er ikke samlet inn. Den brukbare DNS tilstanden kan ikke bevise den tiltenkte applikasjonsidentiteten. Applikasjonseier må avstemme bundet domene og triggertype med den godkjente ruten før en harmløs kontrollert kvitteringstest. Ikke opprett legitimasjon eller endre MX bare for å gjøre regnearket grønt. Ingen API-kall, hemmelig, DNS redigering eller melding ble utført.
Bevar håndhevingsgrensen
RFC 9989 Avsnitt 7.4 krever gyldig DKIM , ikke SPF alene, for domenepublisering p=reject, og advarer om interoperabilitet mellom indirekte e-post og e-postlister. En enkelt vellykket test med direktemeldinger er ikke et bevis på at alle legitime ruter er klare for sterkere politikk. Behold eksisterende godkjent beskyttelse mens du diagnostiserer det faktiske gapet; enhver politikkendring trenger sin egen beslutning.