Vælg afsenderbekræftelsesmodellen bevidst
For en organisations eget domæne er SMTP2GO afsender-domænebekræftelse den dokumenterede vej til kundedomænegodkendelse. Enkelt-e-mail-bekræftelse er en anden mulighed og giver ikke den samme SPF og DKIM justering. Begynd med de domæner og adresser, applikationer vil bruge i stedet for at vælge den hurtigste bekræftelsesskærm. SMTP2GO-bekræftelsesmuligheder, Sender Domain og Single Sender Email.
Liste over de faktiske kilder: applikations-API-kald, SMTP -relæklienter, enheder og integrationer. Registrer hver konto eller underkonto, beregnet fra domæne og operationel ejer. Et delt domæne betyder ikke, at hver rute bruger de samme legitimationsoplysninger eller konfiguration. Inkluder reserveruter eksplicit, og behandl ikke deres vellykkede levering som en test af den primære rute.
SMTP2GO dokumenterer verificerede afsendere efter behov og registrerer forsøg fra ubekræftede afsendere som afviste. Dens udrulningsmeddelelse forklarer også dens retur-sti underdomænemodel og hvorfor eksisterende rod SPF optager behøver ikke udvides. SMTP2GO verificeret afsender meddelelse.
Fang de tre poster, der er udstedt til kontoen
I Afsendelse > Verificerede afsendere > Afsenderdomæner skal du tilføje det tilsigtede domæne og fange de tre CNAME optegnelser. Det dokumenterede sæt dækker retursti/ SPF -funktionen, DKIM og sporing. Udgiv de aktuelle udstedte værdier i stedet for generiske eksempler. Guiden tilbyder manuelle DNS ændringer eller et automatiseret DNS flow. SMTP2GO-verificerede afsendere, trin et og to.
Afsender-domæneguiden tillader eksisterende DNS underdomæner at sende under et verificeret topdomæne. Det er afsendelsestilladelse, ikke bevis for streng justering for hvert underdomæne. Hvis politikken forbyder CNAME'er, tilbyder guiden TXT / MX konfiguration på anmodning; få det understøttede alternativ i stedet for selv at oversætte poster.
Vælg metoden gennem organisationens forandringsproces. Et automatiseret flow kan anmode om adgang til DNS , så gennemgå præcis, hvilken adgang og hvilke ændringer det foreslår, før du giver det. Manuel udgivelse bør stadig bruge det samme gennemgåede rekordsæt. Giv ikke bredere adgang blot for at undgå at forstå en navnekonflikt.
Gem den fulde ejer, mål og TTL for hver post. Tjek eksisterende brug af de foreslåede navne, herunder andre CNAME'er, certifikater, sporingstjenester og postbehandling. Spørg kontoadministratoren om et understøttet alternativt værtsnavn, når der er en kollision; opfind ikke et nyt mål eller overskriv den eksisterende service.
Hold SPF og sporing adskilt
SMTP2GO's kundedomæne-retursti er den relevante SPF identitet. Tilføjelse af en inkludering til virksomhedens rodpolitik erstatter ikke den udstedte retursti CNAME . Denne skelnen er især nyttig, hvor root-politikken allerede tillader flere ikke-relaterede tjenester. Behold disse eksisterende tilladelser uændrede, medmindre en separat gennemgået ændring kræver det.
SPF kontrollerer den SMTP identitet, der bruges i transaktionen. Dens evalueringsregler overfører ikke automatisk en politik fra det synlige Fra-domæne til et andet konvolutdomæne. RFC 7208 , afsnit 2.4 og 4.
Sporings- CNAME tjener et separat formål. SMTP2GO dokumenterer HTTPS-certifikatforsyning for det sporingsnavn efter verificering. Et sporingsproblem bør undersøges på sine egne præmisser, ikke tolkes som bevis på, at DKIM nøglen mangler. SMTP2GO verificerede afsendere, sporingsdomæne.
Registrer sporingsbekræftelse og certifikatstatus separat i arbejdsarket. Hvis privatlivs- eller kommunikationspolitikken begrænser sporing, skal du få den relevante ejer til at gennemgå disse applikationsindstillinger. Godkendelsesarbejde bør ikke i det stille aktivere en ikke-relateret analysefunktion.
Bekræft offentlig DNS og kontoadgang
Undersøg de offentlige CNAME svar fra den autoritative DNS tjeneste, og sammenlign dem med de udstedte poster. Bekræft, at DNS editoren ikke har tilføjet domænet to gange eller ændret målet. Når resultaterne er forskellige på tværs af autoritative servere, skal du løse denne inkonsistens i stedet for gentagne gange at genskabe domænet i SMTP2GO.
Udbydervejledningen understøtter at give udvalgte underkonti adgang til et domæne, der er verificeret i masterkontoen. Bekræft, at den faktiske afsendende underkonto har denne adgang. Antag ikke, at et domæne, der vises på masterkontoen, automatisk kan bruges overalt. Vejledningen identificerer tildelte domæner i underkontoen med et mastertag, der ikke kan redigeres; registrere dette bevis for den faktiske afsenderkonto. SMTP2GO-verificerede afsendere, underkontoadgang.
Registrer, hvilken konto der ejer domænet, hvilke underkonti der er godkendt, og hvem der kan ændre disse tilladelser. Til klient- eller multibrandbrug skal du beholde godkendelsen til det specifikke domæne- og afsenderformål. DNS kontrol afgør ikke, om en bestemt applikation skal have tilladelse til at sende som det pågældende mærke.
Test SMTP og API-stier separat, hvor de bruges
API-dokumentationen behandler API-nøglegodkendelse og afsenderbekræftelse som separate krav. En gyldig nøgle alene autoriserer ikke en ubekræftet From-identitet. SMTP2GO API guide, godkendelse og afsenderbekræftelse.
Brug harmløst indhold til kontrollerede eksterne postkasser og send gennem hver materialerute. Gem applikationsidentifikatorer, UTC-tider, meddelelses-id'er og tilsvarende udbyderaktivitetsregistreringer. For en enhed eller integration skal du teste fra den pågældende enhed eller integration i stedet for kun fra en udviklers separate testscript. Bevar den observerede Fra, selvom applikationen forventedes at bruge noget andet.
Ved modtageren skal du registrere Return-Path , betroet SPF -identitet og resultat, hver DKIM d- og s-værdi og DMARC resultat. Undersøg den offentlige nøgle for vælger faktisk brugt; en verificeret, men ubrugt vælger beviser ikke, at meddelelsen blev underskrevet med den. RFC 6376 , afsnit 3.5 og 6.1.
Bestem, hvilket autentificeret domæne, der stemmer overens med det synlige Fra. En subdomæne-retursti kan opfylde en afslappet SPF justering uden at opfylde streng nøjagtig-domæne-justering. Én passerende tilpasset mekanisme er tilstrækkelig til DMARC , selvom separate udbyder- eller organisatoriske krav kan bede om begge mekanismer. RFC 9989 , Identifier Alignment Explained og DMARC Evaluation.
Hold DMARC politikken under domæneejerskab
SMTP2GO's DMARC opsætningsside placerer politikpublicering i domænets DNS i stedet for afsenderplatformen. Behandl dette som en separat ændring på domæneniveau, der også påvirker andre afsendere. SMTP2GO DMARC guide, Sådan opsætter du DMARC.
Brug den aktuelle protokoldefinition til godkendelsesafgørelsen. Nogle udbyderens forklarende ordlyd komprimerer autentificering og levering til en enklere historie; den bør ikke tilsidesætte sondringen mellem justering, politik og en modtagers uafhængige filtrering. Sænk ikke en eksisterende håndhævelsespolitik blot for at gøre en ubekræftet enkelt-e-mail-rute brugbar.
Hvis mail afvises, før indsendelsen er fuldført, skal du kontrollere afsenderbekræftelse, kontoomfang og den faktiske Fra-adresse. Hvis beskeden leveres med uventet identitet, skal du kontrollere integrationens tilsidesættelser og kontovalg. Hvis godkendelsen godkendes, men spamplaceringen forbliver dårlig, skal du undersøge omdømme, modtagernes forventninger og indhold separat. Gentagen ændring af CNAME'er er ikke et generelt middel til levering.
Dokumenter udrulnings- og gendannelsesruten
Brug SMTP2GO-domæne- og applikationsarbejdsarket (opret en separat anmeldelsespost med felterne beskrevet her). Den adskiller de tre DNS funktioner, underkontotilladelse og rutespecifikke modtagerbeviser. Notér den præcise årsag til en mislykket acceptcheck i stedet for kun en rød eller grøn status.
Sæt pause eller omdiriger berørt programtrafik gennem en godkendt, tidligere testet sti, hvis en udrulning mislykkes. Bevar registreringer, der er nødvendige for post i kø og fungerende integrationer. Før du trækker et domæne tilbage, skal du kontrollere, at ingen enhed, klientkonto eller reserverute stadig afhænger af det. Gentest efter ændring af DNS vært, applikation Fra identitet eller underkontoadgang.
Fiktiv diagnostisk sag, der involverer den forkerte konto
Kun fiktiv skriftlig sag: S2G-01 antager, at masterkontoen har verificeret service.example , men en applikation, der sender alerts@service.example bruger en underkonto uden den påkrævede domæneallokering og modtager et indsendelsesafslag. Der findes ikke noget SPF , DKIM eller DMARC -resultat for modtageren for det afviste forsøg. Applikationsejeren skal verificere kontovalg og opnå godkendelse til snævert domænetildeling og derefter teste den samme rute. En hovedkontoprøve lukker ikke problemet med underkonto. Ingen API-nøgle, lejertilladelse eller besked blev brugt.
Godkendelse afventer fortsat
Accepter kun, når de faktiske ruter bruger det godkendte domæne, udstedte DNS poster løses, det relevante kontoomfang verificerer, og betroede modtagerresultater etablerer den nødvendige justering. Live lejer-, DNS og beskedtjek, accept af originalt omfang, uafhængig teknisk gennemgang, visuel gennemgang og menneskelig SMV-godkendelse afventer stadig dette upublicerede udkast.
Adskil en forbigående meddelelse fra håndhævelsesberedskab
RFC 9989 Afsnit 7.4 kræver gyldig DKIM for en domæneudgivelse p=reject og advarsler om interoperabilitet med indirekte mail. Et enkelt tilpasset SPF resultat retfærdiggør ikke i sig selv en udrulning af afvisningspolitik. Gennemgå alle lovlige ruter og politikejerskab separat fra denne udbyderopsætning.