Definer den kundevendte identiteten
Transaksjons-e-post er en del av kundens tilgang til et kjøpt produkt, så senderendringer trenger en operativ eier. List opp relevante kvitteringer, lisenser eller nedlastingsmeldinger og deres konfigurerte Fra- og Svar-Til-identiteter. Velg et domene organisasjonen din kontrollerer og identifiser DNS eieren. Denne veiledningen beskriver Freemius-arbeidsflyten, ikke innstillingene til en ikke-relatert SendGrid konto.
Freemius dokumenterer SendGrid som sin transaksjonstransport. Avsenderoppdateringen fra november 2025 forklarer at den er ufullstendig DKIM, en avsender utenfor det autentiserte domenet, eller en generisk postboksleverandør utløser en Freemius-avsenderreserve. Svar-til forblir uendret. Når domeneautentisering og avsenderdomene er enige, forblir den konfigurerte avsenderen i bruk. Kilde: Freemius, forbedret håndtering av avsenderadresser for transaksjonelle e-poster.
En reserve kan bevare en leveringsrute samtidig som den endrer identiteten kundene ser. Ikke kall det en vellykket utrulling av merkevaredomene bare fordi meldingen kom. Registrer den tiltenkte avsenderen, faktiske avsenderen og svardestinasjonen som separate akseptfelt. Unngå å anta at en tilpasset svaradresse leverer DMARC justering; det gjør det ikke.
Konfigurer domenet i Freemius
I Developer Dashboards e-postområde, start Autentiser domene med DKIM , skriv inn det tiltenkte domenet og velg Autentiser. Publiser den genererte CNAME poster hos den autoritative DNS leverandøren, bekreft deretter at de ble lagt til og velg Bekreft. Hvis aliaser er i konflikt, start arbeidsflyten på nytt og velg alternativet som indikerer at andre DKIM poster allerede eksisterer for å få andre adresser. sier Freemius SPF håndteres automatisk etter dette oppsettet. Kilde: Freemius, E-postlevering.
Bruk hver kontogenererte verdi nøyaktig, med DNS -vertens eiernavnkonvensjon. Ikke lim inn skjermbildenes eksempelposter i produksjonen. Før du redigerer, sjekk om hver eier allerede har en rekord og hvem er avhengig av det. En CNAME kan ikke repareres ved å plassere konkurrerende mål hos én eier. Arbeidsflyten med alternativ post er å foretrekke fremfor å bryte en annen avsender, men dens endelige navn krever fortsatt inspeksjon.
Ikke legg til en spekulativ SendGrid inkludering på rotdomenet ditt for å kompensere for en mislykket CNAME sjekk. Leverandørens automatiske SPF erklæring gjelder for dens dokumenterte integrasjon; andre legitime avsendere trenger fortsatt sin egen korrekte autorisasjon. Hold rot- SPF policyen og alle urelaterte tjenester uendret med mindre det kreves en separat, bevisstøttet endring.
Bekreft DNS og den faktiske transaksjonsmeldingen
Sammenlign først autoritative svar med det genererte rekordsettet. Skille publisering på feil DNS vert fra rekursiv bufring: et feil autoritativt svar fikses ikke ved å vente. Bekreft at domene-suffikset ikke ble lagt til to ganger, og at ingen motstridende oppføring ble overskrevet. Behold deretter produktets verifiseringsresultat.
Bruk en godkjent testtransaksjon eller annen kontrollert transaksjonsarbeidsflyt med fiktive data. Ikke opprett en reell avgift eller send en kundelisens bare for å få testoverskrifter. Bevar den opprinnelige mottatte meldingen, forventet arbeidsflyt, synlig Fra, Svar-Til, konvoluttidentitet, DKIM d=/s= og klarert mottaker Authentication-Results. Et produktmerke og en leveringslogg kan ikke etablere alle disse identitetene.
Syntetisk eksempel: en transaksjonsmelding har From licenses@example.com og en gyldig DKIM signatur d=example.com. Even if SPF passes for an unrelated provider envelope, exact DKIM alignment can supply the DMARC path. Now change the configured sender to a different organisasjonsdomene uten å autentisere det. Den forrige testen kan ikke etablere autentisering for den nye identiteten, og den dokumenterte reserven kan gjelde. Test på nytt etter endring av sender-domene.
DMARC krever minst én passerende justert SPF eller DKIM bane under gjeldende justeringsmodus. DKIM er en signatur, ikke innholdskryptering eller en garanti for at mottakeren ser meldingen. En leverandøreid reserve kan være gyldig e-post for sin egen identitet uten å være en merkevaredomene-suksess.
Undersøk kundelevering uten å miste bevis
Skill fire spørsmål: ble arbeidsflyten utløst, ble en melding forsøkt, godtok et mottakersystem den, og hvor dukket den opp? Be operatøren om å beholde den relevante sendehendelsen og den nøyaktige feilen i stedet for å gjette fra en kundes manglende e-postrapport. Sjekk mottakeradressen, inkludert om det er adressen knyttet til den tiltenkte kontoen. Unngå gjentatte sendinger før feilen er forstått.
Hvis autentiseringen består, men plasseringen er dårlig, må du vurdere omdømme, innhold og mottakerhåndtering. Hvis signaturen mangler eller er ugyldig, sammenligner du DNS , kontoverifisering og det gjeldende Fra-domenet før du endrer generelle retningslinjer. Et svarrutingsproblem er et annet lag og krever sin egen test.
Hold utvinning og fullføring ærlig
Lagre tidligere DNS verdier og avsenderinnstillinger. Bevar den dokumenterte reserven som et eksplisitt godkjent driftsresultat der det er hensiktsmessig, i stedet for å svekke DMARC på tvers av forretningsdomenet. Fjern foreldede poster først etter å ha bekreftet at ingen aktive produkter eller forsinket melding avhenger av dem.
Aksept krever den tiltenkte avsenderen og svarene, bekreftet DNS og en reell post for mottatte meldinger for hver transaksjonsrute innenfor omfanget. Denne veiledningen brukte leverandørdokumentasjon, sjekket gjennom gjeldende primærkildesider og protokollreferanser. Den inneholder ingen levende leietaker, kjøp, DNS eller leveringsutførelse. Menneskelig SMB-gjennomgang, uavhengig kontroll og publisering gjenstår.
Hold uoverensstemmelsesresultatet atskilt fra svarruting
Skriftlig sak FM-02 antar at example.com er det autentiserte domenet, men et produkt velger nå licenses@other.example som avsender og support@example.com som Reply-To. Det nye avsenderdomenet er ikke autentisert. Under den dokumenterte mismatchadferden, forvent en Freemius From-fallback; den faktiske reserveadressen og meldingsautentiseringen er ikke observert her. Reply-To kan forbli support@example.com uten å gjøre other.example til en justert From-identitet. Produkteieren må godkjenne den tiltenkte avsenderen, fullføre matchende oppsett om nødvendig og inspisere en kontrollert transaksjonsmelding uten å utstede en reell avgift eller lisens. Ingen kjøp, kontoendring 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.