fix-dmarc

Fix my DMARC

Scan, get the one next record, the user publishes it, check it. Each step ends on the next action, so the user never has to ask "what now?".

Rules

• Never compose or edit a DMARC record. Every record comes from a DNS Doctor tool result and is printed verbatim, host and value exactly as returned. Never rewrite, reformat or "improve" it.
• The ladder is p=none → p=quarantine → p=reject, one step at a time, never with pct. A scan can justify at most p=quarantine, and only with alignment evidence. p=reject needs weeks of aggregate-report evidence that every real sender passes; no scan gives it.
• SPF is diagnose-only. Relay SPF findings; never propose an SPF record or edit (not even ~all to -all).
• The user publishes every DNS change; you never change DNS for them.
• Plain words for a non-expert: see "Explain it for a non-expert" at the end of this skill.

Flow

1. Scan. Call scan_domain. It publishes a public report page, and so does build_dmarc_upgrade (it scans fresh too): if the user wants the domain kept private, run neither and say why. Read DMARC, SPF and DKIM failing-first: temperror is a lookup that did not complete, never a failure; info is "not found", never a failure. If the report has not_registered: true, the domain does not resolve: propose no records and ask which domain they meant.
2. Get the record. Call build_dmarc_upgrade with the domain. It scans fresh and decides the step itself.
   • record present: print it verbatim and where it goes (_dmarc.<domain>, a TXT record). It replaces their current DMARC record; a domain must have only one. Say in one line what this step changes. End with: "Publish it at your DNS host and tell me when it's done; I'll check it."
   • record is null: relay its rationale as the answer and stop there. Never fill the gap with a record of your own. policy describes the returned record, so it is null too; the domain's observed policy is in current_policy. Common reasons: already at least as strong as the evidence allows, no alignment signal yet (reporting comes first), the DMARC lookup did not complete (try again shortly), the domain does not exist, or the domain is on Automatic DMARC (DNS Doctor serves the record and the owner applies steps from the dashboard).
3. Re-check. When they say it is published, call check_record with kind: dmarc and expected_value set to the record. On done, call scan_domain once more and say whether DMARC now passes. On wait, say when to look again (check_again_after_seconds) and ask them to tell you then. On edit, relay found_at if it names where the value landed instead. For "has it reached everywhere?" use check_propagation on _dmarc.<domain>, type TXT (see the verify-change skill).
4. Next step. After p=quarantine, say plainly that p=reject needs about 30 days of aggregate-report evidence, which a chat cannot collect. If the user owns the domain and wants that evidence gathered, offer DNS Doctor monitoring, set up as the dns-doctor skill describes; never promise a date.