Dostarczalność e-mail z formularzaSPF, DKIM i DMARC w 2026

TL;DR

Formularz działa, lead zapisuje się w bazie, ale mail z potwierdzeniem trafia do spamu — w 2026 roku najczęściej winne są brakujące rekordy SPF, DKIM i DMARC oraz wysyłka z domeny, która nie autoryzuje serwera aplikacji. Poniżej praktyczny przewodnik dla stron na Next.js: od DNS po testy, z przykładami rekordów i checklistą po wdrożeniu na DevStudioIT Cloud z zapisem zgłoszeń w Branchly.

Dla kogo

• Firm, których klienci nie dostają potwierdzeń z formularza kontaktowego
• Developerów konfigurujących SMTP (Resend, Brevo, SendGrid, własny Postfix)
• Marketingu martwiącego się, że „odpowiedzi z CRM też wpadają do spamu”
• Właścicieli domen, którzy widzą w Gmail „Bez uwierzytelnienia” obok maila

Fraza (SEO)

spf dkim dmarc formularz kontaktowy, dostarczalność email transakcyjny, maile ze strony w spamie, konfiguracja dns email 2026

Trzy filary uwierzytelnienia — co robi ka który

Bez SPF i DKIM Gmail i Outlook od 2024–2026 agresywniej filtrują maile z domen firmowych. Bulk marketing to osobny temat — tu skupiamy się na mailach transakcyjnych: potwierdzenie formularza, kopia do admina, reset hasła, faktura PDF.

Typowy flow formularza na stronie firmowej

1. Użytkownik wysyła formularz na example.com
2. Route Handler (Next.js) waliduje dane, zapisuje lead w Branchly (branchly.cloud)
3. Serwer wywołuje API providera mail (np. Resend) z From: kontakt@example.com
4. Provider wysyła przez swoją infrastrukturę SMTP
5. Skrzynka klienta sprawdza SPF/DKIM/DMARC domeny example.com

Problem: krok 4 używa IP providera, którego nie ma w SPF domeny klienta → soft fail → spam folder.

Aplikacja hostowana na DevStudioIT Cloud (devstudioit.cloud) nie wysyła maili „sama z serwera Node” w produkcji — używamy API transactional providera z poprawnie skonfigurowanym DNS. To stabilniejsze niż otwarty port 25 na VPS.

SPF — przykład rekordu

Jedna domena, Resend jako provider:

; DNS TXT dla example.com
example.com.  IN  TXT  "v=spf1 include:amazonses.com include:_spf.resend.com ~all"

Zasady:

• Jeden rekord SPF na domenę (łącz include zamiast wielu TXT v=spf1)
• ~all = soft fail ( tolerowane przy migracji); docelowo -all hard fail
• Dodaj include każdego providera (Google Workspace do maili biurowych ≠ Resend do transakcyjnych — często dwie ścieżki w jednym SPF)

Po zmianie DNS odczekaj propagację (do 48 h) i testuj:

dig TXT example.com +short

DKIM — selektor i rekord

Provider generuje parę kluczy; w DNS dodajesz CNAME lub TXT:

; przykład Resend
resend._domainkey.example.com.  IN  CNAME  xxx.dkim.resend.com.

W nagłówku maila zobaczysz DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=resend; .... Selektor s= musi pasować do rekordu DNS. Rotacja kluczy — raz na rok lub po incydencie; provider zwykle daje drugi selektor do zero-downtime rotation.

DMARC — polityka i raporty

Start z monitorowaniem, nie od razu reject:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100; adkim=s; aspf=s"

Po 2–4 tygodniach analizy raportów XML (rua):

• p=quarantine — podejrzane maile w spam
• p=reject — docelowo dla domen produkcyjnych wysyłających tylko przez autoryzowane źródła

DMARC wymaga alignment: domena w From: musi zgadzać się z domeną SPF lub DKIM (strict aspf=s; adkim=s utrudnia spoofing, ale wymaga dyscypliny w konfiguracji).

From, Reply-To i treść — pułapki deliverability

Maile z formularza powinny zawierać kontekst: „Otrzymaliśmy Twoje zgłoszenie z formularza na example.com dnia …” — to odróżnia transakcję od phishingu.

Implementacja w Next.js — fragment

// lib/mail/send-contact-confirmation.ts
import { Resend } from 'resend';

const resend = new Resend(process.env.RESEND_API_KEY);

export async function sendContactConfirmation({
  to,
  name,
  locale,
}: {
  to: string;
  name: string;
  locale: 'pl' | 'en' | 'de';
}) {
  const from = 'DevStudio.it <kontakt@devstudioit.com>';

  await resend.emails.send({
    from,
    to,
    replyTo: 'hello@devstudioit.com',
    subject: locale === 'pl' ? 'Potwierdzenie zgłoszenia' : 'Submission received',
    text: `Cześć ${name},\n\nOtrzymaliśmy Twoje zgłoszenie.\n\nZespół DevStudio.it`,
    html: `<p>Cześć ${name},</p><p>Otrzymaliśmy Twoje zgłoszenie.</p>`,
  });
}

Klucz API trzymamy w env na DevStudioIT Cloud, nie w repozytorium. Logi wysyłki (message ID providera) zapisujemy obok submission w Branchly — ułatwia support „mail nie doszedł”.

Testowanie po wdrożeniu

1. mail-tester.com — jednorazowy score /10
2. Gmail — „Pokaż oryginał” → SPF PASS, DKIM PASS, DMARC PASS
3. Microsoft Message Header Analyzer — dla Outlook
4. Wysyłka na skrzynki testowe: Gmail, Outlook, Onet, WP — polski rynek ma własne filtry
5. Monitoruj bounce rate i complaint rate u providera (>0,1% complaints = problem reputacji)

FAQ

Czy wystarczy SPF bez DKIM?

Nie w 2026 — większość dużych providerów wymaga obu. DMARC bez DKIM/SPF alignment daje mało wartości.

Czy mogę wysyłać z @gmail.com przez API?

Nie — używaj własnej domeny z zweryfikowanym DNS. Gmail jako From przez Resend/SendGrid i tak failuje SPF.

Co z mailami do admina wewnętrznego?

Ten sam stack DNS — From: formularz@example.com, To: biuro@example.com. Jeśli biuro to Google Workspace, SPF musi include Google oraz providera transakcyjnego.

Czy DMARC p=reject zepsuje forwardy?

Tak — forwardy mogą łamać alignment. Rozważ subdomain do transakcyjnych: notify.example.com z osobnym DMARC.

CTA

Formularz zapisuje leady, ale maile giną? Skonfigurujemy DNS, wysyłkę i monitoring deliverability.

• Zgłoś problem z mailami — audyt SPF/DKIM/DMARC pod Twoją domenę
• Strony WWW — formularze, Branchly, hosting DevStudioIT Cloud