Read DMARC reports and fix who sends as us

When to use

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.

Before you start

• 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.

What a run requires3

The trail8 steps

1. S1

   Collect the month's reportsagent

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

   Done when the number of report files matches the number expected for the window, and gaps (if any) are noted.

2. S2

   Parse into a sender tableagent

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

   Done when one table per domain covers all report files, and the totals add up to the reported volume.

3. S3

   Classify every sending organisationagent

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

   Done when no row is unclassified; every row has a label and, for approved, the reason it sends.

4. S4

   Investigate the unknown and the failingagent

   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.

   Done when 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 changesagentneeds approval · owner

   Approval · S5 · owner — the run stops until a named person records the decision

   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.

   Done when the owner approves or rejects each proposed change, by name and date.

6. S6

   Apply the approved DNS changesagent

   Edit the records in the dns module.

   Done when the published records read back exactly as approved (bc dns show, or the provider's zone view).

7. S7

   Decide the enforcement stepagentneeds approval · ownerirreversible

   Approval · S7 · owner — the run stops until a named person records the decision

   Irreversible · S7 — an agent never closes it alone

   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.

   Done when the owner has decided and the decision is recorded — including "stay at the current level, because …". ⚠ verify 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 backagent

   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.

   Done when the summary is sent and bc tasks add has next month's review scheduled.

Checks — how we know it worked

• 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.

If it goes wrong

What each step leaves behind

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 …". ⚠ verify 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.

Evidence to keep

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.

How this playbook improves

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.