mailops: SPF, DKIM, DMARC i reszta poczty z jednego terminala

Poczta psuje się po cichu. SPF nadal się resolvuje, ale w zeszłym tygodniu przekroczyłeś limit dziesięciu lookupów. DKIM działa na starym selektorze, a na nowym go nie ma. DMARC mówi p=reject, tylko że połowa nadawców nigdy nie była wyrównana. MTA-STS jest opublikowane — ale polityka nie pokrywa hosta MX, na który się przeniosłeś. Nic z tego nie rzuca błędu. Poczta po prostu zaczyna lądować w spamie, a dowiadujesz się od klienta.

Dlatego napisałem mailops — małe CLI w Go, które sprawdza całą posturę pocztową domeny w jednym przebiegu, z terminala albo z CI.

Co robi

Jedna subkomenda, mailops check example.com, i patrzy na:

• SPF — obecność, wiele rekordów, politykę all oraz szacowany DNS-lookup count po rozwinięciu include / redirect, żebyś widział nadciągający limit dziesięciu lookupów.
• DKIM — wykrywanie selektorów (common i providerowych), parsowanie klucza publicznego i rozmiar klucza.
• DMARC — polityka, pct, adresy raportów oraz podpowiedzi o autoryzacji raportów zewnętrznych.
• MTA-STS & TLS-RPT — rekord TXT, plik polityki po HTTPS oraz to, czy Twoje realne hosty MX faktycznie są pokryte wzorcami mx: w polityce.
• BIMI — składnia rekordu, logo SVG i URI dowodu autorytetu (VMC) oraz zgodność z egzekwowaniem DMARC.
• Reputacja — DNSBL dla adresów IP MX od ręki, plus opcjonalne strefy domenowe DBL / SURBL / URIBL.

Z --smtp robi się aktywnie: połączenie do hostów MX albo submission, banner, EHLO, STARTTLS na 25/587, implicit TLS na 465, sprawdzenie wynegocjowanej wersji TLS i expiry certyfikatu, lista reklamowanych mechanizmów AUTH oraz nieautoryzowany probe open-relay RCPT, który nigdy nie wysyła DATA. --mda robi tę samą kontrolę postury dla IMAP/POP na 143/993/110/995 — tylko dostępność i TLS, bez logowania, bez czytania skrzynek.

Profile providerów

Większość domen stoi za znaną platformą, więc --profile google-workspace (albo microsoft-365, amazonses, sendgrid, mailgun, postmark, zoho, …) podstawia właściwe selektory DKIM i endpointy. To, co podasz jawnie, zawsze wygrywa z profilem.

W CI

Output domyślnie to czytelny tekst, albo --json / --yaml / --prom, a --otel-endpoint wysyła metryki OTLP/HTTP prosto do kolektora. Exit codes znaczą to, co znaczą — --fail-on warn i --strict decydują dokładnie, które findingi wywalają build. Wrzuć to do zaplanowanego joba i złap zepsuty SPF, wygasający cert MX albo świeży wpis na DNSBL, zanim zrobią to klienci.

Gdzie żyje

• Landing: systeam.pl/mailops
• Źródła: github.com/systeampl/mailops — Apache 2.0
• Ta sama rodzina co dnsops i certops
• Issues i PRy mile widziane

— Paweł