Lasīt DMARC atskaites un novērst sūtīšanu mūsu vārdā

Kad izmantot

Monthly, for every domain the company sends mail from. Not for the first setup of the DMARC record — that happens in tech.create-mailbox / mail setup, and this playbook only assumes a record exists and reports arrive. Not for responding to a live phishing incident using the company's domain — use tech.phishing-report first, then let its findings feed this review.

Pirms sāc

• The rua address in the DMARC record is known and the reports actually arrive there (check last month's exist).
• The approved-sender list is current: every tool that sends as @company.lv is on it. An unlisted sender is
• The current policy level is known (none / quarantine / reject) per domain.

Ko izpilde pieprasa3

Ceļš8 soļi

1. S1

   Collect the month's reportsaģents

   Gather every aggregate report for the reporting window from the rua mailbox or report service, per domain.

   Izdarīts, kad the number of report files matches the number expected for the window, and gaps (if any) are noted.

2. S2

   Parse into a sender tableaģents

   For each report: source IP, sending organisation, message volume, SPF result, DKIM result, alignment.

   Izdarīts, kad one table per domain covers all report files, and the totals add up to the reported volume.

3. S3

   Classify every sending organisationaģents

   Label each row: approved (on the list) · known-but-unlisted (identifiable vendor) · unknown · forwarder (mailing list or via relay pattern).

   Izdarīts, kad no row is unclassified; every row has a label and, for approved, the reason it sends.

4. S4

   Investigate the unknown and the failingaģents

   For unknown senders: identify the organisation from the report's contact data and reverse lookup; check whether it is a vendor the company actually uses. For approved senders that fail: find the missing SPF include or unaligned DKIM domain from their documentation.

   Izdarīts, kad each unknown is either identified with evidence or marked suspicious with what was searched.

   ⛔ A failing approved sender is a configuration debt, not a reason to delay enforcement — but it is also never ignored.

5. S5

   Prepare the DNS changesaģentsvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S5 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Draft the exact record edits: add missing SPF includes, add DKIM selectors the vendor requires, adjust the DMARC record only if the data supports it. Show the owner: the table, the proposed diff, and what mail could be affected.

   Izdarīts, kad the owner approves or rejects each proposed change, by name and date.

6. S6

   Apply the approved DNS changesaģents

   Edit the records in the dns module.

   Izdarīts, kad the published records read back exactly as approved (bc dns show, or the provider's zone view).

7. S7

   Decide the enforcement stepaģentsvajag apstiprinājumu · īpašnieksneatgriezenisks

   Apstiprinājums · S7 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Neatgriezenisks solis · S7 — aģents to nekad nenoslēdz viens

   Propose moving the policy one step only when the evidence supports it: to quarantine, legitimate volume passes alignment for at least two consecutive months with no unexplained senders; to reject, the same under quarantine plus a monitored quarantine period. State the risk in one line.

   Izdarīts, kad the owner has decided and the decision is recorded — including "stay at the current level, because …". ⚠ jāpārbauda the exact subdomain/policy interaction for any subdomains in use, at dmarc.org — do not assume the parent record covers them.

8. S8

   Verify and hand backaģents

   Re-check alignment for the top senders after the change window; confirm the rua address still resolves and receives. Send the owner a three-line summary: legitimate pass rate, unknown senders and their status, policy decision.

   Izdarīts, kad the summary is sent and bc tasks add has next month's review scheduled.

Pārbaudes — kā zinām, ka izdevās

• Every sending organisation in the table is labelled; zero rows marked "unknown" at month-end without a note.
• Legitimate volume passing alignment is read back from the reports, not estimated (target: 100 % before any
• The published DMARC and SPF records read back character-for-character as approved in S5.
• The enforcement decision in S7 exists as a written record with the month's evidence attached.

Ja noiet greizi

Ko atstāj katrs solis

1. S1the number of report files matches the number expected for the window, and gaps (if any) are noted.
2. S2one table per domain covers all report files, and the totals add up to the reported volume.
3. S3no row is unclassified; every row has a label and, for approved, the reason it sends.
4. S4each unknown is either identified with evidence or marked suspicious with what was searched.
5. S5the owner approves or rejects each proposed change, by name and date.
6. S6the published records read back exactly as approved (bc dns show, or the provider's zone view).
7. S7the owner has decided and the decision is recorded — including "stay at the current level, because …". ⚠ jāpārbauda the exact subdomain/policy interaction for any subdomains in use, at dmarc.org — do not assume the parent record covers them.
8. S8the summary is sent and bc tasks add has next month's review scheduled.

Ko saglabāt

The parsed sender table per domain · the raw report files for the month · the S5 approval (who, when, what diff) · the published records after S6 · the S7 decision with its evidence · the S8 summary sent to the owner.

Kā šī procedūra uzlabojas

After every 6 runs ask: did legitimate pass rate reach 100 % before each raise, and if not, which sender was the holdout and why? How long did an unknown sender take to identify? Did any month have missing reports? A new version changes the step that caused the delay or the miss, and says so in its change note.