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
- 0przebiegów
- Ostatni
- 19.09.2026start przebiegu
- Stron w przebiegach
- —33 przebiegów bez liczby stron
CARD
karta z kodu CREATO_PING, odczyt 22.09.2026Jak ten parametr trafia do ClickUpa: wynik sondy to linia w subtasku 2. Pomiar, a usterka, którą otwiera — linia w subtasku 1. Podsumowanie (z identyfikatorem CWE i kategorią OWASP), skąd liczy się wskaźnik zagrożenia i status strony. Projekcja z bazy skanera odświeża oba subtaski co godzinę. Do 22.09 każde ustalenie dostawało własny subtask i status ze starego słownika (PODATNA, WARNING…) — te słowa zostały jeszcze w części opisów pomiaru niżej jako język wewnętrzny sond.
| Obszar i ważność | Bezpieczeństwo · wysoka (B26) |
|---|---|
| Workflow i częstotliwość | creato_ping_security_v2 · P3 działa na LAB247Skaner 2.0, rytm „p3” / „bezpieczenstwo”: premium co 6 h, reszta co 24 h (tier 1–3), co 9 dni (tier 4) · 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 → do_writera (bramka gate z polityki; sito powagi zniknęło 18.09)CREATO_PING/config/incident_policy.toml → [finding] dns_mail_auth_removed |
| Retencja odczytów | Surowy pomiar jako NIEZMIENNY wiersz tabeli `odczyty` w bazie skanera (wejście, wyjście, dowody, sha karty sondy i helpera, commit kodu) — trigger odrzuca każdą zmianę. Okno retencji z kohorty: 90 dni premium, 30 dni reszta; poza oknem zostają odczyty z werdyktem problemu, akcją albo etykietą, bo replay reguł ich potrzebuje (`skaner/retencja.py`). Do LAB247 ten kanał nie idzie (do bazy serwisu jadą dziś tylko sprawdzenia dostępności), więc poza odczytem zostaje werdykt w tabeli `werdykty` i sprawa w tabeli `sprawy`. |
| 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/skaner/klasyfikacja.py · CREATO_PING/skaner/usterki.toml · CREATO_PING/skaner/ocena.py · odczyt 22.09.2026 |
dns_mail_auth_removed: bramka polityki otwarta (gate=true) → sprawa w skanerze → Zniknęło zabezpieczenie poczty (SPF/DMARC) — waga 3 → ocena 5–6 (żółty), status strony „sredni”, dopóki sprawa jest otwarta. Waga 3 mimo „normalnej” powagi w polityce ma w katalogu jawne uzasadnienie: poczta klienta staje się podszywalna, a skutek biznesowy jest większy niż sama powaga ustalenia.
| Kod | Finding | Severity | Pewność | Skutek | Finding / alarm | Waga → ocena | Co zrobić |
|---|---|---|---|---|---|---|---|
| B26.01 | Zniknął SPF lub DMARCdns_mail_auth_removed | Średnia | Niepewne | do weryfikacji | tak / nie | waga 3 → ocena 5–6 (żółty) | Potwierdź zmianę u klienta i przywróć rekord. |
| Kod i klucz | B26.01 · dns_mail_auth_removed · w tabeli typów |
|---|---|
| Co znaczy | Rekord był w poprzednim skanie, a teraz go nie ma — grzebanie w DNS albo migracja poczty bez wiedzy agencji. |
| Kiedy powstaje | W baseline był rekord SPF (TXT zaczynający się od v=spf1 na domenie) albo DMARC (TXT v=DMARC1 na _dmarc.domena), a w nowym odczycie go nie ma. Nowe NS muszą być niepuste. |
| Severity · pewność | Średnia · Niepewne |
| Skutek dla strony | do weryfikacji · zakłada Finding · alarm nie |
| Waga → ocena | waga 3 → ocena 5–6 (żółty) |
| Klasyfikacja | CWE: CWE-290 (Authentication Bypass by Spoofing)OWASP Top 10:2025: A07:2025 Authentication FailuresOCSF 1.9.0: Compliance Finding (class_uid 2003) |
| Rekord OCSF | finding_info.analytic.uid = "B26.01" · analytic.name = "dns_mail_auth_removed" · finding_info.types = ["B26 Zdjęcie SPF/DMARC"] |
| Co zrobić | Potwierdź zmianę u klienta i przywróć rekord. |
| Wersje typu |
|
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.