Как да изпращате електронна поща, отговаряща на DMARC от името на други лица

By 9 декември 2015 Без коментари

Изпращане на имейл на други хора в DMARC съвместимият начин може да бъде постигнат по много различни начини. Тази статия е предназначена за доставчици на услуги за електронна поща (ESP) и всеки бизнес, който изпраща имейли, използвайки собствените им клиенти (например: CRM, компании за управление на таланти, системи за фактуриране и т.н.).

dmarcian поддържа Център за ресурси на DMARC (DMARC Operation Resource Center) който включва директория на имейл източници и ако източниците могат да изпращат DMARC съвместим имейл. В такъв случай са включени бележки за това как да конфигурирате източника, за да се съобразите с него DMARC.

Тази директория спестява много време за цяла група хора:

  • Собствениците на домейни могат веднага да открият дали тяхната CRM / система за управление на таланти / фактуриране може да изпраща DMARC съвместим имейл и ако да, как да го направите. Не е необходимо да прекарвате часове, ровейки се в интернет архиви, по телефона с поддръжка или да се опитвате да съставите решение, базирано на частична информация.
  • Източниците на имейл избягват заявки за поддръжка от хора, които искат да знаят дали DMARC е на разположение.
  • Продуктовите мениджъри от имейл източник могат да научат какво точно искат хората, когато поискат DMARC поддържа. Това изяснява изискванията, ускорява внедряването и води до доставена функция, която прави щастливи клиенти.

Тази статия описва как да получите разрешение за изпращане от името на домейн и какви възможности са необходими за изпращане DMARC съвместим имейл, потенциални промени в процеса на борда на клиента и какво да правите след това DMARC е на мястото си.

Как да изпращаме с използване на домейн на клиента

DMARC съвместим имейл е лесен за идентифициране и работи чрез създаване на връзка между домейна на клиента и част от имейла. Пуснахме кратко видео за това как DMARC работи тук.

Има няколко начина да се свържете с домейна на клиента, така че DMARC съвместим имейл може да бъде изпратен от името на клиент. ЗАБЕЛЕЖКА: DMARC ви позволява да изпращате удостоверени имейли с помощта на поддомейн (като например email.company.com) и все още ще можете да използвате домейна от най-високо ниво в From: (напр From: offers@company.com).

Най-добрите подходи са изброени първо, последвани от по-малко ефективни подходи:

Делегиране на домейн

Когато клиент делегира поддомен, който да управлявате (като например email.company.com), ще можете да изпращате имейли, удостоверяващи самоличността ви в под-домейна, и в повечето случаи да бъде позволено да изпращат имейли с домейн от най-високо ниво в From: (напр From: Best Offers <offers@company.com>). Всичко, свързано с изпращане DMARC съвместим имейл вече се управлява от името на клиента, тъй като вие контролирате и управлявате целия поддомен. Има два начина за осъществяване на делегиране на поддомейни:

Пълно делегиране

Клиентът делегира цял поддомейн, който да управлявате, Като правите това, вие ставате отговорни за под-домейна и всичко под него (включително под-домейните на под-домейна). Делегирането на под-домейна е единственото нещо, което вашият клиент трябва да направи, което прави този подход предпочитан.

на CNAME

Клиентът създава няколко CNAME, които сочат към вашия собствен домейн, Това всъщност е форма на делегиране, с изключение на отделните услуги, които се делегират от всяка една CNAME, Това е като пълно делегиране, с изключение на това, че клиентът първоначално трябва да създаде повече DNS записи, което прави това второ място на предпочитания подход за пълно делегиране.

Обикновено CNAME са създадени за:

  • SPF & манипулиране, Например, клиент създава CNAME, от който се посочва marketing.customer-domain.org да се bounces.email-service-provider.com, Имейлът, изпратен от името на клиента, използва адрес за отказ на @marketing.customer-domain.org, Не само това е съответното SPF запис, управляван от вас (тъй като това е наистина SPF запис за bounces.email-service-provider.com), но всички откази ще ви бъдат изпратени обратно вместо на клиента. (Публикувахме кратко SPF Преглед на видео тук.)
  • DKIM, Клиентът може да създаде множество записи на CNAME веднъж, които насочват към вашите собствени публикувани публични ключове, и можете да използвате тези записи на CNAME, за да добавите DKIM подписи на имейла, който изпращате от името на клиента. Наличието на няколко CNAME на място ви позволява да се въртите DKIM ключове, без да се изисква от клиента да прави нищо. (Публикувахме кратко DKIM Преглед на видео тук.)
  • Картографиране на връзки с имейл до домейна на клиента, Вместо да вграждате връзки, които сочат към собствения ви домейн, можете да добавите връзки към имейла на клиента си, който използва домейна на клиента ви. Когато някой кликне върху връзка в имейла, CNAME се връща към собствените ви услуги за проследяване и т.н.

Трансферна

Препредаването понякога е опция, ако се изпраща само малко имейл от името на клиента. Разрешаването на клиент да конфигурира имейла си, за да бъде препредаван чрез различен имейл сървър е един от начините за получаване DMARC съответствие на мястото ... ако самото реле може да изпрати DMARC съвместим имейл.

Два начина да разрешите това:

SMTP реле

Позволете на клиентите да конфигурират SMTP реле за целия имейл, който изпращате от тяхно име. (Имаме кратко видео за видео обзор на SMTP, но не обхваща ретранслацията.) Който управлява щафетата, тогава става отговорен за DMARC спазване. Недостатъци:

  • Обработката на отпадане се изключва, освен ако релето не може да препраща обратно към вас за работа.
  • Изпращането на електронна поща е отговорност на оператора на релето, което означава, че услугата ви за електронна поща сега зависи от нещо, управлявано от клиента.

Конфигуриране на потребителски идентификационни данни

Позволява на клиентите да конфигурират потребителските идентификационни данни. Това изисква клиентът да предостави акаунт за вашата услуга и след това да конфигурира услугата, за да използва пълномощията на новия потребител. След това ще изпратите имейл, както ако сте потребител. Недостатъци:

  • Трябва да управлявате потребителския достъп до множество имейл платформи, тъй като вашият клиент може да използва Gmail, Yahoo, Microsoft, Lotus, Exchange и др.
  • Използвате ресурсите на своите клиенти, за да изпращате имейл от името на клиента.

Ръчна конфигурация

Вместо да управлявате делегиран поддомен (или да използвате CNAME), можете да помолите клиентите да конфигурират домейна им, така че да можете да изпращате DMARC съвместим имейл:

SPF

Можете да помолите клиента си да добави вашите собствени мрежови блокове в него SPF запис. Това е често срещано нещо, което трябва да поискате, но често се прави по грешна причина. Това ще ви позволи да изпращате упълномощен имейл от името на клиента но само ако домейнът на клиента се използва в адреса за отпадане на имейла, който изпращате, Недостатъци:

  • Отхвърлените съобщения ще бъдат пренасочени към клиента ви, вместо към вас. Ще имате нулева видимост за проблеми, които оказват влияние върху вашата производителност като имейл подател и клиентът ви ще получи лошо потребителско изживяване.
  • Клиентът ви трябва да мисли за вас, докато поддържа тяхната SPF запис. Това е досадно за вашите клиенти, които трябва да управляват куп други изпращачи, които са поискали да бъдат включени в техните SPF запис по грешни причини.

DKIM

Можете да добавите клиенти DKIM свързани ключове в тяхната област. Недостатъци:

  • Вашият клиент трябва да изреже и постави големи струни в своя софтуер за управление на домейн. Често се случват грешки, досадни потребители и себе си.
  • Не можете да се въртите DKIM ключове, без да поискате клиента да изпълни задача. Това е досадно в най-добрия случай. В най-лошия случай, a DKIM ключът трябва да се завърти поради спешна ситуация (по време на празник!) и това е най-лошото възможно взаимодействие с клиента: „Вашият ключ се използва за изпращане на измамен имейл. Можете ли да пуснете всичко веднага, за да ни помогнете да поправим това? “

Ще ги добавим, докато ги откриваме. Чувствайте се свободни да ни уведомите, ако сте открили нов начин, който си струва да споделите.

Необходими възможности

Както е описано по-горе, изпращане DMARC съвместим имейл от името на вашите собствени клиенти може да бъде осъществен чрез различни подходи. Всеки подход в крайна сметка е компромис във възможностите между "лесно за мен" срещу "лесно за моя клиент". Тъй като има определено количество конфигурация и оперативна работа за изпълнение, можете да:

  • Правете тази работа от името на клиента си,
  • разделете работата между себе си и клиента си, или
  • Клиентът трябва да свърши работата.

Независимо от подхода, винаги има известна работа, която ви позволява да изпращате от името на клиента си:

Делегиране на поддомейни

Клиент

Еднократна конфигурация на домейн за внедряване на поддомейни / CNAME.

Вие

  • Функциониране на домейн системата за обработка / проверка / наблюдение на делегиране на поддомейни / CNAMEs.
  • Функции на имейл сървъра, за да се използва поддомейнът на клиента в адрес за отскачане и в DKIM подписи.
  • Поддръжка на SPF запис.

Трансферна

Клиент

  • Клиентът трябва да донесе собствен ресурс за препредаване.
  • Една времева конфигурация за добавяне на релейна информация към вашата система.

Вие

  • Функциите на сървъра за електронна поща да използват релето на клиента и - ако сте сериозни с изпращането на имейли - да се справят с обработката на отскок. Тъй като почти всеки имейл сървър поддържа възможността за препредаване на електронна поща, работата тук включва излагане на тази функционалност на клиентите, за да се възползват от тях.

Ръчна конфигурация

Клиент

  • Еднократна конфигурация на домейна, която трябва да добавите SPF записи и DKIM ключове за подписване
  • Допълнителна конфигурация, ако SPF записите трябва да бъдат актуализирани или DKIM ключовете за подписване трябва да бъдат заменени.

Вие

  • Функции на имейл сървъра, за да се използва домейнът на клиента в адрес за отскачане и в DKIM подписи.
  • Поддръжка на SPF запис и се уверете, че клиентите актуализират своите SPF запишете, когато промените инфраструктурата си наоколо. Това е лесно, ако вашите клиенти include: вашата инфраструктура чрез SPFили трудно, ако имате клиенти, добавете неща като ip4: в техните SPF записи.

Проницателният читател ще отбележи, че трябва да се направят някои промени, независимо от подхода. Функциите на сървъра за електронна поща се изискват във всички случаи.

Има много общи "необходими възможности" между нерелейните подходи, като основните различия включват различни начини, по които клиентът може да конфигурира своя домейн, за да ви позволи да изпращате от тяхно име. Въз основа на тази информация, си струва да улесните клиентите си, ако вече сте се ангажирали да изпращате имейли от тяхно име.

Включване на клиенти

Подходът на 1st (делегиране на поддомейни) е ефективен от гледна точка на свеждане до минимум колко клиент трябва да приложи, преди да можете да изпратите DMARC съвместим имейл от тяхно име.

Подходът 2nd (релето) по същество разтоварва изпращането на DMARC съвместим имейл на вашия клиент. Този подход може да се предпочете, ако изпратите много малко имейл от името на клиентите си и инвестицията, необходима за изпращане DMARC съвместим имейл не се добавя.

Подходът 3rd (ръчна конфигурация) изисква същото количество клиентска реализация като подчинението на поддомейн делегиране, освен ако не са необходими по-специфични промени, за да започнете.

Освен това, подходът 3rd може да се счита за крехък: промените в собствената ви инфраструктура може да изискват клиентът да направи съответните промени в конфигурацията на домейна. Координирането на този тип промени може да бъде тромаво, скъпо и склонно към грешки.

Изпращане на имейл от името на клиентите

Изпращане DMARC съвместим имейл предоставя много ползи за себе си и за вашия клиент и отива дълъг път до улесняване на идентифицирането на имейла ви. Ако се интересувате от изпращане на имейл от най-добрия клас (или дори само имейл, който се доставя!), помислете дали да изминете допълнителната миля и да използвате домейна на клиента си във всичко, свързано с имейл:

  • Връзките по имейл могат да изглеждат от домейна на клиента ви, но когато някой кликне върху дадена връзка, той може да бъде обслужван от собствената ви инфраструктура.
  • Същото важи и за изображения и за други обекти: изглежда, че идват от домейна на клиента ви, но се обслужват от собствената ви инфраструктура.
  • Имената на сървърите, свързани с доставката на имейли, могат да бъдат променени, за да отразят домейна на клиента ви.

Горните промени са възможни, ако се използва под-домейн подход. Това прави имейла, който изпращате от името на клиентите си, невероятно лесен за идентифициране и доставяне.

Ако се интересувате от включване в списъка директорията на източниците на имейли, свържете се с нас на поддържа@dmarcian. С.

Ако имате въпроси / коментари, не се колебайте да коментирате по-долу или ни пуснете поддържа@dmarcian. С.