Definieer de klantgerichte identiteit
Transactionele e-mail maakt deel uit van de toegang van de klant tot een gekocht product, dus voor afzenderwijzigingen is een operationele eigenaar nodig. Geef een overzicht van de relevante ontvangstbewijzen, licentie- of downloadberichten en hun geconfigureerde Van- en Antwoord-aan-identiteiten. Selecteer een domein dat uw organisatie beheert en identificeer de DNS eigenaar. Deze handleiding beschrijft de Freemius-workflow, niet de instellingen van een niet-gerelateerd SendGrid account.
Freemius documenteert SendGrid als zijn transactioneel transport. De afzenderupdate van november 2025 legt uit dat dit onvolledig is DKIM, activeert een afzender buiten het geverifieerde domein of een generieke mailboxprovider een terugval voor Freemius-afzenders. Reply-To blijft ongewijzigd. Wanneer domeinauthenticatie en afzenderdomein overeenkomen, blijft de geconfigureerde afzender in gebruik. Bron: Freemius, verbeterde verwerking van afzenderadressen voor transactionele e-mails.
Een terugval kan een bezorgroute behouden en tegelijkertijd de identiteit veranderen die klanten zien. Noem het geen succesvolle uitrol van een merkdomein alleen maar omdat de boodschap binnenkwam. Leg de beoogde afzender, daadwerkelijke afzender en antwoordbestemming vast als afzonderlijke acceptatievelden. Ga er niet vanuit dat een aangepast antwoordadres wordt geleverd DMARC uitlijning; dat is niet het geval.
Configureer het domein in Freemius
In het gebied E-mails van het ontwikkelaarsdashboard start u Domein verifiëren met DKIM , voert u het beoogde domein in en kiest u Verifiëren. Publiceer het gegenereerde CNAME records bij de gezaghebbende DNS provider, bevestig vervolgens dat ze zijn toegevoegd en selecteer Verifiëren. Als aliassen conflicteren, start u de workflow opnieuw en selecteert u de optie die aangeeft dat er al andere DKIM records bestaan om andere adressen te verkrijgen. zegt Freemius SPF wordt automatisch afgehandeld na deze configuratie. Bron: Freemius, E-mailafleverbaarheid.
Gebruik elke door het account gegenereerde waarde exact, volgens de naamconventie van de DNS host. Plak de voorbeeldrecords van de screenshots niet in productie. Controleer vóór het bewerken of elke eigenaar dit al heeft gedaan een record en wie ervan afhankelijk is. Een CNAME kan niet worden gerepareerd door concurrerende doelen bij één eigenaar te plaatsen. De workflow voor alternatieve records verdient de voorkeur boven het verbreken van een andere afzender, maar de uiteindelijke namen moeten nog steeds worden geïnspecteerd.
Voeg geen speculatieve SendGrid opname toe aan uw hoofddomein om een mislukte CNAME controle te compenseren. Op de gedocumenteerde integratie is de automatische SPF verklaring van de aanbieder van toepassing; andere legitieme afzenders hebben nog steeds hun eigen juiste autorisatie nodig. Houd het root- SPF beleid en alle niet-gerelateerde services ongewijzigd, tenzij een afzonderlijke, op bewijzen gebaseerde wijziging vereist is.
Controleer DNS en het daadwerkelijke transactionele bericht
Vergelijk eerst gezaghebbende antwoorden met de gegenereerde recordset. Maak onderscheid tussen publiceren op de verkeerde DNS host en recursieve caching: een onjuist, gezaghebbend antwoord wordt niet opgelost door te wachten. Controleer of het domeinachtervoegsel niet twee keer is toegevoegd en dat er geen conflicterende record is overschreven. Bewaar vervolgens het verificatieresultaat van het product.
Gebruik een goedgekeurde testtransactie of een andere gecontroleerde transactionele workflow met fictieve gegevens. Breng geen echte kosten in rekening en stuur geen klantlicentie alleen maar om testheaders te verkrijgen. Behoud het origineel ontvangen bericht, de verwachte workflow, zichtbaar Van, Antwoord aan, envelopidentiteit, DKIM d=/s= en vertrouwde ontvanger Authentication-Results. Een productbadge en een leveringslogboek kunnen niet al deze identiteiten vaststellen.
Synthetisch voorbeeld: een transactioneel bericht heeft Van licenses@example.com en een geldig DKIM -handtekening 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 organisatorisch domein zonder het te authenticeren. De vorige test kan geen authenticatie voor die nieuwe identiteit tot stand brengen en de gedocumenteerde terugval kan van toepassing zijn. Test opnieuw na elke wijziging van het afzenderdomein.
DMARC vereist ten minste één passerend uitgelijnd SPF of DKIM pad onder de toepasselijke uitlijningsmodus. DKIM is een handtekening, geen inhoudsversleuteling of een garantie dat de ontvanger het bericht ziet. Een terugval die eigendom is van een provider kan geldige e-mail zijn voor de eigen identiteit, zonder een succes te worden binnen een merkdomein.
Onderzoek de levering aan klanten zonder bewijsmateriaal te verliezen
Afzonderlijke vier vragen: werd de workflow geactiveerd, werd er geprobeerd een bericht te versturen, accepteerde een ontvangend systeem het en waar verscheen het? Vraag de operator om de relevante verzendgebeurtenis en de exacte fout te bewaren in plaats van te raden op basis van het rapport over ontbrekende e-mail van een klant. Controleer het adres van de ontvanger en controleer of dit het adres is dat aan het beoogde account is gekoppeld. Voorkom herhaaldelijk opnieuw verzenden voordat de fout is begrepen.
Als de authenticatie slaagt maar de plaatsing slecht is, controleer dan de reputatie, de inhoud en de afhandeling van de ontvanger. Als de handtekening ontbreekt of ongeldig is, vergelijk dan DNS , accountverificatie en het huidige Van-domein voordat u het algemene beleid wijzigt. Een antwoordrouteringsprobleem is een andere laag en vereist een eigen test.
Houd het herstel en de voltooiing eerlijk
Bewaar eerdere DNS waarden en afzenderinstellingen. Behoud waar nodig de gedocumenteerde fallback als een expliciet goedgekeurd operationeel resultaat, in plaats van DMARC in het hele bedrijfsdomein te verzwakken. Verwijder verouderde records alleen nadat u hebt bevestigd dat er geen actief product of vertraagd bericht van afhankelijk is.
Voor acceptatie zijn de beoogde afzender en antwoorden, geverifieerde DNS en een echt ontvangen berichtrecord vereist voor elke transactieroute die binnen het bereik valt. Deze handleiding maakte gebruik van documentatie van de leverancier, gecontroleerd via de huidige primaire bronpagina's en protocolreferenties. Het bevat geen live tenant, aankoop, DNS of leveringsuitvoering. Menselijke MKB-beoordeling, onafhankelijke controle en publicatie blijven hangende.
Houd de uitkomst van de mismatch gescheiden van de antwoordroutering
Schriftelijke casus FM-02 gaat ervan uit dat example.com het geverifieerde domein is, maar een product selecteert nu licenses@other.example als afzender en support@example.com als antwoord-aan. Het nieuwe afzenderdomein is niet geverifieerd. Verwacht onder het gedocumenteerde mismatch-gedrag een terugval van Freemius From; het daadwerkelijke fallback-adres en de berichtauthenticatie zijn hier niet waargenomen. Reply-To kan support@example.com blijven zonder other.example een afgestemde Van-identiteit te maken. De producteigenaar moet de beoogde afzender goedkeuren, indien nodig de matching-instellingen voltooien en een gecontroleerd transactioneel bericht inspecteren zonder echte kosten of licentie uit te geven. Er is geen aankoop, accountwijziging of bericht uitgevoerd.
Behoud de handhavingsgrens
RFC 9989 Sectie 7.4 vereist geldige DKIM , en niet alleen SPF , voor het publiceren van domeinen p=reject, en waarschuwt voor de interoperabiliteit van indirecte e-mail en mailinglijsten. Eén enkele succesvolle test met directe berichten is geen bewijs dat elke legitieme route klaar is voor krachtiger beleid. Behoud de bestaande goedgekeurde bescherming terwijl u de feitelijke kloof diagnosticeert; elke beleidsverandering heeft zijn eigen beslissing nodig.