dnsdoctordnsdoctor/claude-plugin/skills/fix-dmarc/SKILL.md

fix-dmarc

Skill3 starsChanged 7 days agoApache-2.0View on GitHub

Use when the user wants to fix, add, tighten or move up their DMARC record, asks how to get from p=none to quarantine or reject, or why DMARC fails. Scans the domain with DNS Doctor, gets the next validated DMARC record from build_dmarc_upgrade, has the user publish it, then re-checks it. Relays the engine's reason when there is no record; never composes one.

In this repository2 other files it gives its agents.
- dns-doctorSkill
- verify-changeSkill

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 5 are distinctive, and 6 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
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 …
line 13
Very specific:
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 …
line 28
Very specific:
Get the record: Call build_dmarc_upgrade with the domain.
line 34
Very specific:
Re-check: When they say it is published, call check_record with kind: dmarc and expected_value set to the record.
line 49
Very specific:
Next step: After p=quarantine, say plainly that p=reject needs about 30 days of aggregate-report evidence, which a chat cannot collect.
line 56
Distinctive:
If a domain's DKIM is missing, the key comes from the sending provider: point the user to that provider's DKIM setup and never invent a key …
line 61
Distinctive:
When Outlook.com refuses a bulk sender for missing SPF, DKIM or DMARC, the bounce reads "550 5.7.515 Access denied".
line 92
Distinctive:
Only about half (52.1%) of the world's 1.8 million busiest websites had a DMARC record in early 2026.
line 98
Very specific:
Every record has a TTL: how long other servers may keep the old copy before asking again.
line 224
Very specific:
If someone looked the record up before it existed, "not found" can be remembered for a while too.
line 228
Distinctive:
After a domain expires, its website and email may be interrupted until it is renewed.
line 262

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

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

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

If a domain's DKIM is missing, the key comes from the sending provider: point the user to that provider's DKIM setup and never invent a key or selector.

Explain it for a non-expert

The user is usually a small-business owner or someone who built their site with an AI tool, not a sysadmin. Say in ONE plain sentence what the result means for their mail, gloss any technical word in 3-6 words (for example "DKIM (a signature that proves the mail is really yours)"), and don't lecture or scare.

<!-- fact-bank:start (generated from backend/dns_doctor/education/facts.py by `python -m tests.mcp_server.regen_fact_bank`; never edit by hand) -->

Facts you may use

Pick a fact only from the heading for the finding you are explaining, and use at most one per reply. Quote it as written or shorter and never add a number it does not state. Each fact names its source in the comment after it. "Our numbers" are DNS Doctor's own scans: aggregates only, the domains we last checked in October 2026 that have email set up (they publish MX records). Where the DNS Doctor result card is shown it may carry its own short tip from this list, so add no fact of your own there.

No DMARC record (`No DMARC record found`)

DMARC is how you tell mail providers what to do with mail that fakes your address.
Gmail requires DMARC from anyone sending more than 5,000 messages a day to Gmail; p=none is enough.
Yahoo has required DMARC (at least p=none) from bulk senders since February 2024.
Since May 5, 2025, Outlook.com refuses mail from domains sending over 5,000 a day without SPF, DKIM and DMARC.
When Outlook.com refuses a bulk sender for missing SPF, DKIM or DMARC, the bounce reads "550 5.7.515 Access denied".
Phishing and spoofing was the crime most often reported to the FBI in 2025: 191,561 complaints.
Our numbers: of the 483 domains with email that DNS Doctor last checked in October 2026, 28% had no DMARC record.
Only about half (52.1%) of the world's 1.8 million busiest websites had a DMARC record in early 2026.
Since April 2025, GoDaddy adds a DMARC record set to p=quarantine to every domain newly bought or transferred there.

DMARC at `p=none` (`DMARC is published but p=none`)

p=none only asks for reports; it does not ask providers to block fake mail.
Providers that send DMARC reports send them about once a day by default.
Each report counts the mail sent as your domain and whether it passed SPF and DKIM.
Our numbers: of 483 domains with email we checked in October 2026, 35% were at p=none.
Of the top million websites that publish DMARC, fewer than half (46.9%) ask providers to block or junk fake mail.
95% of Fortune 500 companies publish DMARC, and more than 80% of them have moved past p=none.

DMARC without a `rua=` address (no reports requested)

Without a rua= address, mailboxes have nowhere to send their daily reports, so you cannot see who sends as you.

Two DMARC records (`Multiple DMARC records found`)

With two DMARC records, providers apply neither, as if you had none.

DMARC at `p=quarantine` or `p=reject` (why keep reading the reports)

p=quarantine asks providers to treat failing mail as suspicious, often the spam folder.
p=reject asks providers to refuse failing mail outright.
A new sending service can fail DMARC until it signs or sends mail aligned with your domain.
Forwarded mail and mailing lists can fail DMARC even when the mail is really yours.
DMARC reports are worth reading after enforcing: a new or broken sender shows up there first.
Our numbers: of 483 domains with email we checked in October 2026, 36% were at p=quarantine or p=reject (21.5% and 14.5%).
Among the 5,000 largest US organisations, 38.4% of domains are at p=reject and 22% at p=quarantine.

No SPF record (`No SPF record found`)

Since February 2024, Gmail requires SPF or DKIM from every sender.
Bulk senders to Yahoo need both SPF and DKIM.
Our numbers: of 483 domains with email we checked in October 2026, 7.5% had no SPF record.

Two SPF records (`SPF record is invalid` because a second record exists)

A domain may have only one SPF record; with two, the SPF check returns an error (permerror).

SPF over or near 10 lookups (`SPF exceeds the 10 DNS-lookup limit`, `SPF is near the 10-lookup limit`)

SPF allows 10 DNS lookups. Past that, receivers treat the whole record as broken, even for your real senders.
The limit counts the whole chain: the includes inside your includes count too.

SPF ends in `~all` (observation only: SPF is diagnose-only, never propose changing it)

Our numbers: of the SPF records we found in October 2026 on domains with email, 53% end in ~all.

DKIM not found (`DKIM: checked common selectors, none found`)

The scan tries common selector names only, so a key under another name can still exist.
Bulk senders to Yahoo and Outlook.com need DKIM, not just SPF.
DKIM usually survives forwarding when the message is unchanged; SPF often does not.

DKIM key of 1024 bits (`uses a weak 1024-bit key`)

1024-bit DKIM keys still work; 2048 bits is recommended where your email provider offers it.
Our numbers: of the DKIM keys we found in October 2026 on domains with email, 28% were 1024-bit.

DKIM found (`check_dkim_selector`: the selector is published)

DKIM signs each message so mailboxes can tell it was not changed on the way. Each sending service uses its own key.

No MX records (`No MX records`)

With no MX record, senders try your domain's own address instead, usually the website server.
A domain that takes no mail can say so with a "null MX" record.

Own mail server (`check_reverse_dns`: `ptr_missing`, `mismatch`)

Gmail requires a sending server's address to have matching forward and reverse DNS (a PTR record).
Gmail requires mail to arrive over an encrypted (TLS) connection.
Mail servers typically check blocklists on every incoming connection.

Blocklist listing (`Listed on ...`)

The blocklists this check queries list mail server IP addresses, not domain names.
Mail servers typically check blocklists on every incoming connection, so a listing can stop mail at the door.

Logo in the inbox (`check_bimi`)

Gmail shows a BIMI logo only when DMARC is at p=quarantine or p=reject.
For a BIMI logo, Gmail needs a mark certificate (VMC or CMC); the blue checkmark needs a VMC.

Propagation and TTL (`check_record` says `wait`, `check_propagation`)

Every record has a TTL: how long other servers may keep the old copy before asking again.
Each resolver keeps the old answer until its cache time (TTL) runs out, so locations update at different moments.
If someone looked the record up before it existed, "not found" can be remembered for a while too.

Look-alike domains (`check_lookalikes`)

DMARC protects only your exact domain; it cannot stop someone sending from a look-alike name.
Business email scams caused about 3 billion US dollars in losses reported to the FBI in 2025.

Email test (`get_email_test`: spam placement, alignment)

DMARC passes only when the From domain matches a domain that SPF or DKIM checked.
Gmail wants spam complaints below 0.3% of your mail and recommends staying under 0.1%.
Gmail requires one-click unsubscribe on marketing mail from anyone sending over 5,000 a day.
Since November 2025, Gmail has been stepping up enforcement on mail that misses its sender rules.

Website certificate expiring (`TLS certificate expires in`, `TLS certificate expired on`)

From March 15, 2026, new website certificates last at most 200 days; 100 from 2027, 47 from 2029.
Let's Encrypt certificates last 90 days, and it recommends renewing every 60.
Our numbers: of 600 domains we checked in October 2026, about 5% had a certificate expired or within 30 days of it.

Domain registration expiring (`domain registration expires in`, `lookup_registration`)

For .com and other generic domains, registrars must remind you about a month and a week before expiry.
After a domain expires, its website and email may be interrupted until it is renewed.
Auto-renew at your registrar reduces the risk of expiry; check that each renewal actually went through.
About 1 in 4 .com and .net domains is not renewed: the renewal rate was 75.2% in mid-2026.
About 50,000 lapsed domains are registered again by someone else every day, and can receive mail meant for the old owner.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free

The file

11 rules. About 0 are common, 5 are distinctive, and 6 are very specific to this project.

Fix my DMARC

Rules

Flow

Explain it for a non-expert

Facts you may use

No DMARC record (No DMARC record found)

DMARC at p=none (DMARC is published but p=none)

DMARC without a rua= address (no reports requested)

Two DMARC records (Multiple DMARC records found)

DMARC at p=quarantine or p=reject (why keep reading the reports)

No SPF record (No SPF record found)

Two SPF records (SPF record is invalid because a second record exists)

SPF over or near 10 lookups (SPF exceeds the 10 DNS-lookup limit, SPF is near the 10-lookup limit)

SPF ends in ~all (observation only: SPF is diagnose-only, never propose changing it)

DKIM not found (DKIM: checked common selectors, none found)

DKIM key of 1024 bits (uses a weak 1024-bit key)

DKIM found (check_dkim_selector: the selector is published)

No MX records (No MX records)

Own mail server (check_reverse_dns: ptr_missing, mismatch)

Blocklist listing (Listed on ...)

Logo in the inbox (check_bimi)

Propagation and TTL (check_record says wait, check_propagation)

Look-alike domains (check_lookalikes)

Email test (get_email_test: spam placement, alignment)

Website certificate expiring (TLS certificate expires in, TLS certificate expired on)

Domain registration expiring (domain registration expires in, lookup_registration)