Dlaczego Twoje transakcyjne mejle mogą zawodzić, choć nic o tym nie wiesz

Sporo czasu poświęcasz na dopracowanie workflow'ów w HubSpot. Sekwencje powitalne rozciągnięte na tygodnie. Przypomnienia o porzuconych koszykach. Maile z resetem hasła, które faktycznie ktoś otwiera.

Ale jest niewygodna prawda: kiedy Twój klient dostaje tego maila z resetem hasła, jego klient pocztowy może wyświetlać ostrzeżenie. Takie: „Gmail nie mógł zweryfikować, że yahoo.com faktycznie wysłał tę wiadomość."

Nie wygląda to dobrz dla Twojej marki.

System transactional email w HubSpot jest solidny — dopóki nie spojrzysz na nagłówki autoryzacji. Domyślnie HubSpot podpisuje te maile swoimi kluczami DKIM, nie Twoimi. A kiedy mechanizmy autoryzacji Google przeprowadzają weryfikację, widzą rozbieżność: adres From mówi ty@twojafirma.pl, ale podpis DKIM wskazuje na header.d=hubspot.com.

To jest błąd wyrównania DMARC. I dla transactional emails — tych, które mają największe znaczenie, bo użytkownicy na nie reagują — to poważny problem.

Marketing vs. transakcyjne: dwie różne ligi

Zanim cokolwiek naprawimy, ustalmy, z czym dokładnie mamy do czynienia.

Marketingowe maile w HubSpot przechodzą przez dedykowaną infrastrukturę wysyłkową. Cały zespół zajmuje się reputacją IP, rozgrzewaniem adresów i wynikami sender score. Dla masowych kampanii to w porządku.

Transactional emails to co innego. To komunikacja jeden-do-jednego, wyzwalana przez działania użytkownika: resety haseł, potwierdzenia zamówień, powiadomienia z formularzy, faktury. Klienci oczekują, że te wiadomości przyjdą wprost od Twojej firmy. A klienci pocztowi traktują je inaczej — stosują ostrzejszą autoryzację, bo transactional emails to wysokowartościowe cele dla phishingu.

Kiedy HubSpot wysyła je przez swoją infrastrukturę z ich podpisem, pożyczasz ich reputację zamiast budować własną.

MailKite: tożsamość mailowa Twojej domeny

MailKite to usługa SMTP relay, która stoi między Twoją aplikacją a serwerami pocztowymi odbiorców. Kluczowa funkcja: podpisuje każdy wychodzący mail kluczem DKIM Twojej domeny, nie zewnętrznym.

Dzięki temu:

• DMARC alignment przechodzi. Twoja domena w polu From zgadza się z podpisem DKIM.
• Reputacja Twojej domeny rośnie. Każdy wysłany mail przez Twoją domenę buduje historię wysyłkową.
• Pełne logi i analityka. Wiesz dokładnie, które maile gdzie trafiły i z jakim statusem.
• Retry i failover. Jeśli serwer odbiorcy jest tymczasowo niedostępny, MailKite zajmuje się logiką ponowień.

Konfiguracja jest zaskakująco prosta.

Krok po kroku: jak przepuścić HubSpot przez własną domenę

Krok 1: Podłącz domenę w MailKite

Zarejestruj się w MailKite i dodaj swoją domenę wysyłkową. Potrzebujesz dostępu do ustawień DNS (jeśli zarządzasz DNS gdzie indziej, zajmie to 5 minut; jeśli używasz panelu NameOcean, będzie jeszcze szybciej).

MailKite dostarczy Ci trzy rekordy DNS do opublikowania:

• Rekord MX do routowania przychodzącej poczty
• Rekord TXT dla SPF
• Rekord DKIM do podpisu maili

Po propagacji (zazwyczaj 5-30 minut) Twoja domena jest zweryfikowana.

Krok 2: Pobierz dane SMTP

W panelu MailKite utwórz użytkownika SMTP. Skopiuj adres serwera, port i klucz API. Będą Ci potrzebne w HubSpot.

Wygląda to tak:

Server: smtp.mailkite.dev
Port: 587
Username: Twój username z MailKite
Password: Twój klucz API (zaczyna się od mk_live_)
Security: STARTTLS wymagany

Krok 3: Skonfiguruj SMTP Relay w HubSpot

W HubSpot przejdź do Settings → Transactional Email. Konfigurację SMTP znajdziesz w ustawieniach domeny wysyłkowej.

Wklej dane z MailKite. HubSpot wyśle testowego maila — upewnij się, że go otrzymałeś.

Krok 4: Przetestuj nagłówki autoryzacji

Nie pomijaj tego kroku. Wyślij testowego maila transakcyjnego przez swój workflow w HubSpot. Potem otwórz go w Gmail i sprawdź nagłówki.

Szukaj tego:

Authentication-Results: mx.google.com;
    dkim=pass header.d=twojafirma.pl;
    spf=pass;
    dmarc=pass

Wszystkie trzy powinny pokazywać pass. Jeśli dkim pokazuje header.d=hubspot.com, coś w konfiguracji wymaga poprawki. Sprawdź, czy domena wysyłkowa w HubSpot dokładnie odpowiada tej zweryfikowanej w MailKite.

SMTP czy API: co wybrać?

HubSpot oferuje dwa sposoby wysyłki transactional email. Praktyczne porównanie:

Wybierz SMTP, gdy:

• Chcesz prostą konfigurację działającą automatycznie dla wszystkich maili z HubSpot
• Wysyłasz z zewnętrznych systemów (aplikacja Laravel, wtyczka WordPress, własny CRM)
• Zależy Ci na logach i logice retry MailKite dla każdego maila
• Nie polegasz na śledzeniu otwarć/kliknięć HubSpot dla wiadomości transakcyjnych

Wybierz API, gdy:

• Potrzebujesz natywnych statystyk otwarć i kliknięć HubSpot dla transactional emails
• Chcesz, żeby każdy mail pojawiał się automatycznie na osi czasu w HubSpot
• Budujesz niestandardową integrację, gdzie zdarzenia mailowe wyzwalają inne workflow'y

Szczera odpowiedź? SMTP jest łatwiejsze w utrzymaniu. Po skonfigurowaniu każdy transactional email z HubSpot przechodzi przez MailKite bez dodatkowego kodu. API wymaga aktualizacji każdego wywołania wysyłki.

Bonus: przechwytywanie odpowiedzi i kierowanie ich do HubSpot

Tu robi się ciekawie. Kiedy klienci odpowiadają na Twoje transactional emails, te odpowiedzi muszą gdzieś trafić. Z funkcją inbound routing w MailKite możesz przekierować przychodzące odpowiedzi na webhook.

Chcesz, żeby te odpowiedzi trafiały do właściwego kontaktu w HubSpot? Oto Cloudflare Worker, który się tym zajmie:

export default {
  async fetch(request, env) {
    if (request.method !== "POST") return new Response("OK");
    
    const { from, subject, text } = await request.json();
    
    // Znajdź pasujący kontakt w HubSpot
    const searchRes = await fetch(
      "https://api.hubapi.com/crm/v3/objects/contacts/search",
      {
        method: "POST",
        headers: {
          Authorization: "Bearer " + env.HUBSPOT_API_KEY,
          "Content-Type": "application/json",
        },
        body: JSON.stringify({
          filterGroups: [{
            filters: [{
              propertyName: "email",
              operator: "EQ",
              value: from,
            }]
          }],
          properties: ["email", "firstname", "lastname"],
        }),
      }
    );
    
    const { results } = await searchRes.json();
    if (!results.length) return new Response('{"ok":true}', { status: 200 });
    
    const contactId = results[0].id;
    
    // Dołącz odpowiedź jako notatkę
    await fetch(
      "https://api.hubapi.com/crm/v3/objects/notes",
      {
        method: "POST",
        headers: {
          Authorization: "Bearer " + env.HUBSPOT_API_KEY,
          "Content-Type": "application/json",
        },
        body: JSON.stringify({
          properties: {
            hs_note_body: `Odpowiedź na: ${subject}\n\n${text}`,
            hs_timestamp: Date.now(),
          },
          associations: [{
            to: { id: contactId },
            types: [{
              associationCategory: "HUBSPOT_DEFINED",
              associationTypeId: 202,
            }],
          }],
        }),
      }
    );
    
    return new Response('{"ok":true}', { status: 200 });
  },
};

Teraz każda odpowiedź klienta staje się notatką w jego profilu kontaktowym w HubSpot — razem z oryginalnym tematem wiadomości.

Szerszy obraz: email to część strategii domenowej

To nie jest tylko kwestia deliverability maili. Twoja domena to Twoja tożsamość cyfrowa. Każdy mail, każde zapytanie DNS, każda kontrola autoryzacji albo buduje, albo podważa zaufanie do tej tożsamości.

Kiedy kierujesz transactional emails przez własną domenę z podpisem DKIM:

• Gmail i Outlook bardziej ufają Twoim wiadomościom
• Twoja reputacja nadawcy rośnie niezależnie od jakiejkolwiek platformy
• Klienci widzą Twoją markę, nie dostawcę
• Twoja domena staje się cenniejszym aktywem

W NameOcean widzimy klientów, którzy traktują domeny jako jednorazowe zakupy, i tych, którzy rozumieją je jako infrastrukturę. Autoryzacja mailowa — DMARC, DKIM, SPF — jest tak samo fundamentalna jak dostępność Twojej strony.

Twoje transactional emails to często najważniejsze komunikaty, jakie wysyłasz. Zasługują na tę samą dbałość o markę co landing pages i sam produkt.