База от знания

Изпращайте имейли чрез собствения си Postmark акаунт

Свържете вашия собствен Postmark акаунт: потвърждаване на домейн, защо въпреки това да добавите незадължителния return-path запис, Server токенът в сравнение с Account токена, и какво означава неактивен получател.

Ще ви трябват акаунт в Postmark и достъп до DNS на вашия домейн.

Официална документация на Postmark: Подателски подписи и домейни · API токени за сървър · Регистрация

⭐ Защо бихме избрали Postmark за това. Услугата категорично откажва да изпраща маркетингови имейли, което е точно причината за високата успеваемост при доставяне: вашите фактури не делят репутация с чужд бюлетин. Ако единственото ви изискване е транзакционните писма да пристигат, това е правилният избор.

1. Добавете и потвърдете своя домейн

Sender Signatures → Domains → Add Domain и въведете поддомейн като mail.yourdomain.com.

Postmark ви предоставя два записа:

ТипХостЦел
TXT<selector>._domainkey.mail.yourdomain.comПубличен DKIM ключ
CNAMEpm-bounces.mail.yourdomain.comДомейн за отговор (bounce)

Добавете и двата, след което натиснете Verify.

⭐ Добавете записа за връщане на отпаднали писма (return-path), въпреки че Postmark го отбелязва като незадължителен. Без него вашите съобщения се изпращат със собствения домейн за отпаднали писма на Postmark, така че SPF се уеднаднява с postmarkapp.com, а не с вашия домейн. Само с DKIM все пак ще преминете проверка по DMARC – но ще сте загубили една от двете проверки без причина и ще искате и двете, когато голям получател въведе по-строги правила.

⚠️ Postmark не изисква SPF запис, тъй като не използва вашия домейн като подател в плика (envelope sender). Ако вече имате SPF, го оставете непроменен.

2. Вземете своя API токен за сървър

Отворете сървъра, от който искате да изпращате (Postmark нарича средата за изпращане „сървър“), след това API Tokens и копирайте Server API token.

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

⭐ Обмислете създаването на отделен сървър за това – наречете го „Zinn® notifications“. Статистиката, списъците с отпаднали имейли и активността в Postmark са отделни за всеки сървър, така че отделният сървър означава, че известията до вашите клиенти няма да се смесват с нищо друго, което изпращате.

3. Свържете го в Zinn®

Отворете Email sending във вашето табло за управление:

  • Provider — Postmark
  • Send from this domain — mail.yourdomain.com
  • Message stream — оставете като outbound, освен ако не сте създали свой собствен
  • Postmark server token — токенът от стъпка 2

⚠️ Message stream трябва да бъде транзакционен поток (transactional). Postmark отхвърля писма с транзакционен вид, изпратени по поток за масови съобщения, а нулирането на пароли и фактурите са транзакционни.

4. Изпратете тестовото съобщение и въведете кода

Натиснете Send test message към входяща кутия на друг домейн, прочетете кода от нея и го въведете.

Когато не работи

„You tried to send to a recipient that has been marked as inactive“ — Postmark блокира адрес след сериозно връщане (hard bounce) или жалба за спам, за постоянно, докато не го активирате отново. Погледнете в Suppressions. Това е начинът на Postmark да ви предпази и обикновено е правилно.

422 с „Invalid 'From' address“ — домейнът в Send from this domain не е потвърден в Postmark или сте потвърдили yourdomain.com, а изпращате от mail.yourdomain.com. Postmark изисква точно съвпадение на домейна.

401 Unauthorized — поставили сте токена за акаунт вместо токен за сървър (вижте по-горе) или токенът принадлежи на друг сървър.

Всичко работи, но имейлът е в папката за спам — проверете дали DKIM показва Verified в Postmark и дали вашият DMARC запис не е зададен на p=reject, докато нещо друго във вашия домейн все още е с грешни настройки.

Най-новото от блога

Какво сме писали за хостинга, SEO и мащабното управление на сайтове.

SEO и изграждане на връзки от слоя на хостинга: Поглед на оператора за 2026 г.

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

Прочетете публикацията →

Как да направите WordPress бърз и сигурен: контролен списък за производителност и плъгини

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

Прочетете публикацията →

Как да изберете управляван уеб хостинг през 2026 г.: Ръководство за купувача

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

Прочетете публикацията →

Прочетете блога →

Все още се затруднявате?

Поддръжката е включена във всеки план, отделът работи 24 часа в денонощието и можете да ни пишете на всеки от нашите 58 езика — ние ви отговаряме на вашия.

Свържете се с поддръжката → Всички статии →