Hoe DMARC-compatibele e-mail namens anderen te verzenden

By 9 december 2015E-mail technologie

Het verzenden van e-mail van anderen op een DMARC-compatibele manier kan op verschillende manieren worden uitgevoerd. Dit artikel is bedoeld voor e-mailserviceproviders (ESP's) en elk bedrijf dat e-mail verzendt met behulp van de domeinen van hun eigen klant (voorbeelden: CRM's, bedrijven voor talentbeheer, factureringssystemen, enzovoort).

dmarcian handhaaft het DMARC Operation Resource Center waaronder een map met e-mailbronnen en of de bronnen DMARC-compatibele e-mail kunnen verzenden. Als dit het geval is, worden opmerkingen gegeven over het configureren van de bron om aan DMARC te voldoen.

Deze map bespaart veel tijd, voor een hele reeks mensen:

  • Domeineigenaren kunnen onmiddellijk ontdekken of hun CRM / talent-management / facturering-systeem in staat is DMARC-compatibele e-mail te verzenden, en zo ja, hoe dit te doen. U hoeft geen uren te spenderen aan het doorzoeken van internetarchieven, telefonisch met ondersteuning of een oplossing proberen samen te stellen op basis van gedeeltelijke informatie.
  • E-mailbronnen vermijden ondersteuningsverzoeken van mensen die willen weten of DMARC beschikbaar is.
  • Productmanagers van een e-mailbron kunnen precies leren waar mensen om vragen wanneer ze om DMARC-ondersteuning vragen. Dit verduidelijkt de vereisten, versnelt de implementatie en resulteert in een verzonden functie die blije klanten maakt.

In dit artikel wordt beschreven hoe u gemachtigd bent om namens een domein te verzenden, welke mogelijkheden vereist zijn om DMARC-compatibele e-mail te verzenden, potentiële wijzigingen in het onboardingproces van een klant en wat te doen nadat DMARC is geïnstalleerd.

Hoe te verzenden met behulp van het domein van een klant

DMARC-compatibele e-mail is gemakkelijk te identificeren en werkt door een koppeling tot stand te brengen tussen het domein van een klant en een e-mailbericht. We hebben een kort filmpje gemaakt over hoe DMARC hier werkt.

Er zijn verschillende manieren om aan het domein van een klant te koppelen, zodat DMARC-compatibele e-mail kan worden verzonden namens een klant. OPMERKING: DMARC biedt u de mogelijkheid om geverifieerde e-mail te verzenden met behulp van een subdomein (zoals email.company.com), en nog steeds in staat om het hoofddomein te gebruiken in de Van: header (bijv Van: biedt @ company.com aan).

De beste benaderingen worden eerst vermeld, gevolgd door minder efficiënte benaderingen:

Domein delegatie

Wanneer een klant een subdomein delegeert dat u wilt beheren (zoals email.company.com), kunt u e-mail verzenden die naar het subdomein wordt geverifieerd en in de meeste gevallen e-mail verzenden via het hoofddomein in de Van: header (bijv Van: Beste aanbiedingen <offers@company.com>). Alles wat te maken heeft met het verzenden van DMARC-compatibele e-mail wordt nu beheerd namens de klant, omdat u het volledige subdomein beheert en beheert. Er zijn twee manieren om delegatie van subdomeinen te implementeren:

Volledige delegatie

De klant delegeert een volledig subdomein dat u kunt beheren. Door dit te doen, wordt u verantwoordelijk voor het subdomein en alles daaronder (inclusief subdomeinen van het subdomein). Het delegeren van het subdomein is het enige dat uw klant moet doen, waardoor dit een voorkeursbenadering is.

CNAMEs

De klant maakt verschillende CNAME's die verwijzen naar uw eigen domein. Dit is in feite een vorm van delegatie, behalve dat individuele services door elk worden gedelegeerd CNAME. Dit is net als volledige delegatie, behalve dat de klant aanvankelijk meer DNS-vermeldingen moet maken, waardoor dit een goede tweede is voor de voorkeursbenadering van volledige delegatie.

CNAME's worden meestal gemaakt voor:

  • SPF en bounce handling. Een klant maakt bijvoorbeeld een CNAME waaruit wordt verwezen marketing.customer-domain.org naar bounces.email-service-provider.com. De e-mail die namens de klant wordt verzonden, gebruikt een bounce-adres van @ marketing.customer-domain.org. Niet alleen wordt de corresponderende SPF-record door u beheerd (want het is echt de SPF-record voor bounces.email-service-provider.com), maar eventuele bounces worden naar u teruggestuurd in plaats van naar uw klant. (We hebben hier een korte SPF-overzichtsvideo gepubliceerd.)
  • DKIM. De klant kan op hetzelfde moment meerdere CNAME-records maken naar uw eigen gepubliceerde openbare sleutels en u kunt die CNAME-records gebruiken om DKIM-handtekeningen toe te voegen aan de e-mail die u namens de klant hebt verzonden. Als u meerdere CNAME's op hun plaats heeft, kunt u DKIM-sleutels draaien zonder dat de klant iets hoeft te doen. (We hebben hier een korte DKIM-overzichtsvideo gepubliceerd.)
  • Koppelingen koppelen met e-mail naar het domein van de klant. In plaats van links in te voegen die naar uw eigen domein verwijzen, kunt u links toevoegen aan de e-mail van uw klant die het domein van uw klant gebruiken. Wanneer iemand op een link in de e-mail klikt, wordt de CNAME teruggezet naar uw eigen services voor tracking, enzovoort.

heruitzetting

Relaying is soms een optie als slechts een kleine hoeveelheid e-mail wordt verzonden namens de klant. Het toestaan ​​van een klant om zijn e-mail te configureren voor relayering via een andere e-mailserver is een manier om DMARC-compliantie op zijn plaats te krijgen ... als het relais zelf in staat is DMARC-compliant e-mail te verzenden.

Twee manieren om dit toe te staan:

SMTP-relais

Laat klanten een SMTP-relais configureren voor alle e-mail die namens hen wordt verzonden. (We hebben een korte video-overzichtsvideo over SMTP, maar dit is niet van toepassing op doorzenden.) Degene die het relais beheert, wordt vervolgens verantwoordelijk voor DMARC-naleving. nadelen:

  • Bounce handling verdwijnt, tenzij het relais terugstuurt naar u voor afhandeling.
  • E-mailbezorging wordt de verantwoordelijkheid van de relay-operator, wat betekent dat uw e-mailservice nu afhankelijk is van iets dat door uw klant wordt beheerd.

Gebruikersreferenties configureren

Sta klanten toe om gebruikersreferenties te configureren. Hiervoor moet de klant een account maken voor uw service en vervolgens uw service configureren om de inloggegevens van de nieuwe gebruiker te gebruiken. U zou dan elke e-mail verzenden alsof u de gebruiker bent. nadelen:

  • U moet toegang op gebruikersniveau tot een groot aantal e-mailplatforms beheren, omdat uw eigen klant mogelijk Gmail, Yahoo, Microsoft, Lotus, Exchange, enz. Zou kunnen gebruiken.
  • U gebruikt de middelen van uw klanten om e-mail namens de klant te verzenden.

Handmatige configuratie

In plaats van een gedelegeerd subdomein (of met behulp van CNAME's) te gebruiken, kunt u klanten vragen hun domein zo te configureren dat u DMARC-compatibele e-mail kunt verzenden:

SPF

U kunt uw klant vragen om uw eigen netblocks toe te voegen aan het SPF-record van de klant. Dit is gebruikelijk om te vragen, maar wordt vaak gedaan om de verkeerde reden. Als u dit doet, kunt u geautoriseerde e-mail namens de klant verzenden maar alleen als het domein van de klant wordt gebruikt in het bounce-adres van de e-mail die u verzendt. nadelen:

  • Bounced-berichten worden naar uw klant gerouteerd in plaats van naar u terug. U hebt geen zicht op problemen die van invloed zijn op uw prestaties als e-mailafzender, en uw klant krijgt een slechte gebruikerservaring.
  • Uw klant moet aan u denken met behoud van zijn SPF-record. Dit is vervelend voor uw klanten die een aantal andere afzenders moeten beheren die dit hebben gevraagd opgenomen in hun SPF-record om de verkeerde redenen.

DKIM

U kunt klanten DKIM-gerelateerde sleutels in hun domein laten toevoegen. nadelen:

  • Uw klant moet grote reeksen knippen en plakken in zijn domeinbeheersoftware. Fouten komen vaak hierbij voor, irritante gebruikers en uzelf.
  • U kunt DKIM-sleutels niet draaien zonder uw klant te vragen een taak uit te voeren. Dit is op zijn best vervelend. In het slechtste geval moet een DKIM-sleutel worden geroteerd als gevolg van een noodgeval (tijdens een vakantie!) En dit is waarschijnlijk de slechtst mogelijke interactie met de klant: "Uw sleutel wordt gebruikt om frauduleuze e-mail te verzenden. Kun je alles nu laten vallen om ons te helpen dit op te lossen? "

We voegen meer benaderingen toe als we ze ontdekken. Laat het ons weten als je een nieuwe manier hebt ontdekt die delen waard is.

Vereiste capaciteiten

Zoals hierboven beschreven, kan het verzenden van DMARC-compatibele e-mail namens uw eigen klanten worden bereikt via verschillende benaderingen. Elke aanpak eindigt als een afweging tussen 'easy for me' en 'easy for my customer'. Aangezien er een vaste hoeveelheid configuratie en operationeel werk is om te presteren, kunt u:

  • Doe dit werk namens uw klant,
  • het werk splitsen tussen uzelf en uw klant, of
  • laat je klant het werk doen.

Ongeacht de aanpak, er is altijd wat werk aan de hand om u toe te staan ​​om namens uw klant te verzenden:

Delegatie van het subdomein

Klant

Eenmalige domeinconfiguratie om subdomein / CNAME's te implementeren.

U

  • Werking van het domeinsysteem voor de verwerking / verificatie / bewaking van subdomeinoverdracht / CNAME's.
  • Functies voor e-mailserver om het subdomein van de klant te gebruiken in een bounce-adres en in DKIM-handtekeningen.
  • Onderhoud van SPF-record.

heruitzetting

Klant

  • De klant moet zijn eigen relatiemiddel brengen.
  • Eenmalige configuratie om relay-informatie aan uw systeem toe te voegen.

U

  • E-mailserverfuncties om relais van de klant te gebruiken en - als u serieus e-mail wilt verzenden - om te gaan met bounce-verwerking. Omdat vrijwel elke e-mailserver de mogelijkheid ondersteunt om e-mail door te sturen, houdt het werk hier het blootstellen van deze functionaliteit aan klanten in om te profiteren van.

Handmatige configuratie

Klant

  • Eenmalige domeinconfiguratie om SPF-records en DKIM-ondertekeningssleutels toe te voegen.
  • Aanvullende configuratie als SPF-records moeten worden bijgewerkt of DKIM-ondertekeningssleutels moeten worden vervangen.

U

  • E-mailserverfuncties om het domein van de klant te gebruiken in een bounce-adres en in DKIM-handtekeningen.
  • Onderhoud van SPF-records en zorgen dat klanten hun SPF-record bijwerken wanneer u uw infrastructuur wijzigt. Dit is makkelijk als uw klanten omvatten: uw infrastructuur via SPF, of hard als uw klanten dingen toevoegen zoals ip4: in hun SPF-records.

De slimme lezer zal opmerken dat sommige veranderingen moeten worden doorgevoerd, ongeacht welke benadering wordt gevolgd. E-mail server functies zijn in alle gevallen vereist.

Er is veel gemeenschappelijke "vereiste mogelijkheid" tussen de niet-relay-benaderingen, met de belangrijkste verschillen die betrekking hebben op verschillende manieren waarop de klant zijn domein kan configureren om namens u te verzenden. Op basis van dit inzicht is het de moeite waard om het uw klanten gemakkelijk te maken als u al bent toegewijd om namens hen e-mail te verzenden.

Onboarding van klanten

De 1st-benadering (subdomeindelegatie) is efficiënt vanuit het oogpunt van minimaliseren hoeveel een klant moet implementeren voordat u DMARC-compatibele e-mail namens hen kunt verzenden.

De 2nd-aanpak (relaying) zorgt ervoor dat het verzenden van DMARC-compatibele e-mail naar uw klant wordt verzonden. Deze aanpak kan de voorkeur hebben als u heel weinig e-mail namens uw klanten verzendt en de investering die vereist is om DMARC-compatibele e-mail te verzenden, niet toeneemt.

De 3rd-benadering (handmatige configuratie) vereist dezelfde hoeveelheid klantimplementatie als de subdomeinafvaardigingsbenadering, maar er zijn meer specifieke wijzigingen vereist om aan de slag te gaan.

Bovendien kan de 3rd-aanpak als broos worden beschouwd: wijzigingen in uw eigen infrastructuur kunnen uw klant ertoe verplichten om overeenkomstige wijzigingen in de domeinconfiguratie aan te brengen. Het coördineren van dit soort wijzigingen kan omslachtig, duur en foutgevoelig zijn.

E-mail verzenden namens klanten

Het verzenden van DMARC-compatibele e-mail biedt veel voordeel voor uzelf en uw klant, en maakt uw e-mail gemakkelijk te identificeren. Als u geïnteresseerd bent in het verzenden van best-in-class e-mail (of zelfs alleen e-mail die wordt bezorgd!), overweeg om die extra stap te nemen en het domein van uw klant te gebruiken in alles met betrekking tot een e-mail:

  • E-maillinks kunnen afkomstig lijken te zijn van het domein van uw klant, maar wanneer iemand op een link klikt, kan deze worden onderhouden door uw eigen infrastructuur.
  • Hetzelfde geldt voor afbeeldingen en andere objecten: ze lijken afkomstig te zijn uit het domein van uw klant, maar worden bediend door uw eigen infrastructuur.
  • Servernamen met betrekking tot de bezorging van e-mail kunnen worden gewijzigd om het domein van uw klant weer te geven.

De bovenstaande wijzigingen zijn mogelijk als de subdomeinbenadering wordt gebruikt. Als u dit doet, is de e-mail die u namens uw klanten verzendt, ongelooflijk eenvoudig te identificeren en te bezorgen.

Als u geïnteresseerd bent om te worden vermeld de map met e-mailbronnen, Contacteer ons op support@dmarcian.com.

Als je vragen / opmerkingen hebt, kun je hieronder reageren of ons een bericht sturen support@dmarcian.com.