Zdjęcie SPF/DMARC
ważność wysokamierzonysposób dns_integrity
Rekord był w poprzednim skanie, a teraz go nie ma. Sygnał grzebania w DNS albo migracji poczty bez wiedzy agencji.
Pierwszy skan domeny tylko zapisuje wzorzec; ustalenie otwiera dopiero kolejny skan bez rekordu.
WIKI
artykuł z 16.09.2026 · źródeł 8Zdjęcie SPF/DMARC to parametr monitoringu stron internetowych, który porównuje bieżące rekordy uwierzytelniania poczty domeny z poprzednim pomiarem i sygnalizuje, że rekord SPF albo DMARC, obecny wcześniej, zniknął z DNS. Mierzy zmianę, nie stan: domena, która nigdy nie miała tych rekordów, takiego sygnału nie daje. Po zdjęciu rekordu SPF sprawdzenie u odbiorcy kończy się wynikiem none [1], a bez rekordu DMARC odbiorca nie powinien stosować mechanizmu DMARC [2].
Jak działa
Wykrywanie zmian konfiguracji (ang. drift detection) polega na porównaniu stanu bieżącego z zapisanym punktem odniesienia. NIST nazywa taki punkt konfiguracją bazową: to udokumentowany zestaw specyfikacji, przejrzany i uzgodniony w danym momencie, który wolno zmieniać tylko w ramach kontroli zmian [3]. Celem zarządzania konfiguracją ukierunkowanego na bezpieczeństwo jest zarządzanie konfiguracjami systemów i ich monitorowanie [4].
Obserwator z zewnątrz widzi tylko bieżące odpowiedzi DNS. Rekord SPF jest rekordem TXT z oznaczeniem v=spf1 w samej domenie [1], a rekord DMARC — rekordem TXT pod nazwą _dmarc domeny [2]. Zmianę widać dopiero po porównaniu z zapisanym wcześniej odczytem.
Nie każdy brak rekordu jest zdjęciem. SPF odróżnia przejściowy, zwykle DNS-owy błąd weryfikatora (temperror) od braku rekordu (none) [1], więc brak odpowiedzi nie powinien nadpisywać wzorca.
Standardy i specyfikacje
- RFC 7208 i RFC 7489 określają, gdzie leżą rekordy SPF i DMARC i co oznacza ich brak [1] [2].
- NIST SP 800-128 opisuje zarządzanie konfiguracją pod kątem bezpieczeństwa, a słownik NIST definiuje konfigurację bazową [4] [3].
- CISA ED 19-01 z 22 stycznia 2019 r. nakazywała w ciągu 10 dni roboczych audyt publicznych rekordów DNS na wszystkich serwerach autorytatywnych i zapasowych, by sprawdzić, czy wskazują zamierzone miejsce [5].
Zagrożenia i skutki
Migracja poczty lub hostingu. Przy przenoszeniu strefy do nowego dostawcy DNS automatyczne skanowanie nie gwarantuje odnalezienia wszystkich rekordów, dlatego trzeba je przejrzeć, ze szczególnym uwzględnieniem rekordów poczty: MX oraz TXT dla SPF, DKIM i DMARC [6]. Rekord pominięty przy przenosinach znika bez żadnego błędu, a strona nadal działa.
Ingerencja w panel DNS. Według ED 19-01 napastnik zdobywa dane logowania konta, które może zmieniać rekordy DNS, i modyfikuje je, by przekierować i przechwycić ruch WWW i pocztowy [5]. W kampanii opisanej przez Mandiant w styczniu 2019 r. przekierowywano ruch serwera poczty ofiary i zbierano dane logowania, a zalecenia obejmowały uwierzytelnianie wieloskładnikowe w panelu domeny oraz weryfikację zmian rekordów A i NS [7]. Rekordy TXT poczty nie są na tej liście, choć ich zdjęcie także jest zmianą, którą warto potwierdzić.
Skutek zdjęcia. SPF, DMARC i DKIM działając wspólnie mogą uniemożliwić wykorzystanie domeny do podszywania się [8]. Po zdjęciu rekordów odbiorca nie ma deklaracji SPF [1] ani polityki DMARC [2].
Wartość wzorca. Pomiar samej obecności nie odróżnia domeny, która nigdy nie miała SPF, od domeny, której go właśnie usunięto. Porównanie z poprzednim stanem wskazuje moment zmiany, a więc okno, w którym warto szukać przyczyny. Porównanie samej obecności nie wykryje jednak zmiany treści, np. zamiany -all na ~all albo p=reject na p=none.
Przykłady
| Poprzedni pomiar | Bieżący pomiar | Interpretacja |
|---|---|---|
| SPF i DMARC | SPF i DMARC | bez zmian |
| SPF | brak rekordu v=spf1 | zdjęcie; odbiorca dostaje wynik none [1] |
| DMARC | brak rekordu pod _dmarc | zdjęcie; DMARC przestaje być stosowany [2] |
| SPF | błąd DNS lub brak odpowiedzi | nierozstrzygnięte, jak temperror [1] |
| brak | brak | nie zdjęcie, tylko stały brak deklaracji |
| MX i SPF starego dostawcy | nowe MX, brak SPF | migracja z pominiętym rekordem [6] |
| SPF, NS bez zmian | brak SPF | zmiana w panelu DNS do potwierdzenia [5] |
- [1] RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 · IETF
- [2] RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) · IETF
- [3] Glossary — baseline configuration · NIST CSRC
- [4] SP 800-128 — Guide for Security-Focused Configuration Management of Information Systems · NIST
- [5] Emergency Directive 19-01 — Mitigate DNS Infrastructure Tampering · CISA
- [6] Full setup — Change your nameservers · Cloudflare Docs
- [7] Global DNS Hijacking Campaign: DNS Record Manipulation at Scale · Mandiant (FireEye)
- [8] Ustawa o zwalczaniu nadużyć w komunikacji elektronicznej · CERT Polska
STATS
wyniki z systemu · tylko liczby zbiorczeTen parametr nie zapisuje odczytu per strona — przebieg zostawia tylko ustalenia, więc liczby sprawdzonych stron i wyników „ok” system nie ma. Pojawią się po wdrożeniu zapisu przebiegów per strona per parametr.
Ten parametr nie otworzył jeszcze żadnego ustalenia w bazie LAB247. Pusto nie znaczy „czysto” — znaczy, że nic nie przekroczyło reguły.
- Przebiegów
- 33sposób dns_integrity
- W 30 dni
- 33przebiegów
- Ostatni
- 19.09.2026start przebiegu
- Stron w przebiegach
- —33 przebiegów bez liczby stron
CARD
karta z kodu CREATO_PING, odczyt 16.09.2026| Obszar i ważność | Bezpieczeństwo · wysoka (B26) |
|---|---|
| Workflow i częstotliwość | creato_ping_security_v2 · P3 działa na LAB247cron co 24 h, T1–T3; T4 raz po anomalii · Dokładny skan. dns_integrity porównuje NS, MX, SPF i DMARC z wzorcem z poprzedniego przebiegu. |
| Sonda i helper | sposób dns_integrity · CREATO_PING/helpers/dns_integrity_check.py |
| Testy |
|
| Typ wyniku | 0 albo 1 ustalenie dns_mail_auth_removed na przebieg; w szczegółach, które rekordy zniknęły, w dowodzie ich poprzednia treść |
| Jednostka | brak — wynik jakościowy (zniknięcie rekordu względem wzorca z poprzedniego przebiegu) |
| Próg i reguła | Timeout 5,0 s na zapytanie. Reguła: rekord niepusty we wzorcu i pusty teraz = dns_mail_auth_removed (jedno ustalenie na oba rekordy). Porównywana tylko obecność. |
| Gdzie leżą pokrętła | CREATO_PING/helpers/dns_integrity_check.py → diff_snapshot, _LIFETIME, _BASELINE_FILENAMECREATO_PING/helpers/security_runner.py → _TASK_SEVERITIES (dalej idą tylko urgent i high)CREATO_PING/config/incident_policy.toml → [finding] dns_mail_auth_removed |
| Retencja odczytów | Żadna dla ustalenia. Plik wzorca trzyma tylko ostatni stan i po zdjęciu nadpisuje poprzednią treść rekordu wartością pustą — już po jednym przebiegu nie ma z czym porównać. |
| Znane rozbieżności |
|
| Karta przepisana z | CREATO_PING/helpers/dns_integrity_check.py · CREATO_PING/helpers/security_runner.py · CREATO_PING/config/incident_policy.toml · CREATO_PING/workflows/_prod/creato_ping_security_v2.json · odczyt 16.09.2026 |
Helper zgłasza powagę normalną, a filtr przebiegu przepuszcza tylko pilną i wysoką — ustalenie odpada przed zapisem. Polityka (normalna, niepewna, do weryfikacji, gate=true) przewiduje subtask do sprawdzenia przez człowieka, ale nigdy nie zostaje zastosowana. W produkcji zdjęcie SPF lub DMARC nie zostawia śladu poza nadpisanym wzorcem.
| Ustalenie | Powaga | Pewność | Skutek | Subtask / alarm | Co zrobić |
|---|---|---|---|---|---|
| Zniknął SPF lub DMARCdns_mail_auth_removed | Normalne | Niepewne | DO WERYF. | tak / nie | Potwierdź zmianę u klienta i przywróć rekord. |
LOOP
bez pętliTrafności jeszcze nie liczymy: zamknięcie subtaska nie niesie dziś werdyktu (prawdziwy / fałszywy / nie dało się sprawdzić). Cztery liczby pojawią się, gdy każde zamknięcie dostanie werdykt — to warunek startu pętli 1.
Ten parametr nie przeszedł jeszcze żadnej pętli. Kolejność po pierwszych pięciu grupach ustali miara trafności.