{"id":78162,"plugin_id":"plugin_asdk_app_6a60c62613808191b41e39b40625b99f","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-11-03T12:11:23.383Z","digest":"3d45b95838e44079133ecbee51dc917f0e1245f76a01473fb889e923e7d30ecc","against":null,"payload":{"description":"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.","included_files":[],"name":"fix-dmarc","skill_md_contents":"---\nname: fix-dmarc\ndescription: 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.\n---\n\n# Fix my DMARC\n\nScan, get the one next record, the user publishes it, check it. Each step ends\non the next action, so the user never has to ask \"what now?\".\n\n## Rules\n\n- **Never compose or edit a DMARC record.** Every record comes from a DNS\n Doctor tool result and is printed **verbatim**, host and value exactly as\n returned. Never rewrite, reformat or \"improve\" it.\n- **The ladder is `p=none` → `p=quarantine` → `p=reject`**, one step at a time,\n never with `pct`. A scan can justify at most `p=quarantine`, and only with\n alignment evidence. `p=reject` needs weeks of aggregate-report evidence\n that every real sender passes; no scan gives it.\n- **SPF is diagnose-only.** Relay SPF findings; never propose an SPF record or\n edit (not even `~all` to `-all`).\n- The user publishes every DNS change; you never change DNS for them.\n- Plain words for a non-expert: see \"Explain it for a non-expert\" at the end of\n this skill.\n\n## Flow\n\n1. **Scan.** Call `scan_domain`. It publishes a public report page, and so\n does `build_dmarc_upgrade` (it scans fresh too): if the user wants the\n domain kept private, run neither and say why. Read DMARC, SPF and DKIM failing-first: `temperror` is a lookup\n that did not complete, never a failure; `info` is \"not found\", never a\n failure. If the report has `not_registered: true`, the domain does not\n resolve: propose no records and ask which domain they meant.\n2. **Get the record.** Call `build_dmarc_upgrade` with the domain. It scans\n fresh and decides the step itself.\n - **`record` present:** print it verbatim and where it goes\n (`_dmarc.`, a TXT record). It replaces their current DMARC record;\n a domain must have only one. Say in one line what this step changes. End\n with: \"Publish it at your DNS host and tell me when it's done; I'll check\n it.\"\n - **`record` is `null`:** relay its `rationale` as the answer and stop\n there. Never fill the gap with a record of your own. `policy` describes\n the returned record, so it is `null` too; the domain's observed policy is\n in `current_policy`. Common reasons: already at least as strong as the\n evidence allows, no alignment signal yet (reporting comes first), the\n DMARC lookup did not complete (try again shortly), the domain does not\n exist, or the domain is on Automatic DMARC (DNS Doctor serves the record\n and the owner applies steps from the dashboard).\n3. **Re-check.** When they say it is published, call `check_record` with\n `kind: dmarc` and `expected_value` set to the record. On `done`, call\n `scan_domain` once more and say whether DMARC now passes. On `wait`, say\n when to look again (`check_again_after_seconds`) and ask them to tell you\n then. On `edit`, relay `found_at` if it names where the value landed instead.\n For \"has it reached everywhere?\" use `check_propagation` on\n `_dmarc.`, type `TXT` (see the verify-change skill).\n4. **Next step.** After `p=quarantine`, say plainly that `p=reject` needs about\n 30 days of aggregate-report evidence, which a chat cannot collect. If the\n user owns the domain and wants that evidence gathered, offer DNS Doctor\n monitoring, set up as the dns-doctor skill describes; never promise a date.\n\nIf a domain's DKIM is missing, the key comes from the sending provider: point\nthe user to that provider's DKIM setup and never invent a key or selector.\n\n## Explain it for a non-expert\n\nThe user is usually a small-business owner or someone who built their site with\nan AI tool, not a sysadmin. Say in ONE plain sentence what the result means for\ntheir mail, gloss any technical word in 3-6 words (for example \"DKIM (a\nsignature that proves the mail is really yours)\"), and don't lecture or scare.\n\n\n### Facts you may use\n\nPick a fact only from the heading for the finding you are explaining, and use\nat most one per reply. Quote it as written or shorter and never add a number it\ndoes not state. Each fact names its source in the comment after it. \"Our\nnumbers\" are DNS Doctor's own scans: aggregates only, the domains we last\nchecked in October 2026 that have email set up (they publish MX records).\nWhere the DNS Doctor result card is shown it may carry its own short tip from\nthis list, so add no fact of your own there.\n\n#### No DMARC record (`No DMARC record found`)\n\n- DMARC is how you tell mail providers what to do with mail that fakes your address.\n \n- Gmail requires DMARC from anyone sending more than 5,000 messages a day to Gmail; `p=none` is enough.\n \n- Yahoo has required DMARC (at least `p=none`) from bulk senders since February 2024.\n \n- Since May 5, 2025, Outlook.com refuses mail from domains sending over 5,000 a day without SPF, DKIM and DMARC.\n \n- When Outlook.com refuses a bulk sender for missing SPF, DKIM or DMARC, the bounce reads \"550 5.7.515 Access denied\".\n \n- Phishing and spoofing was the crime most often reported to the FBI in 2025: 191,561 complaints.\n \n- Our numbers: of the 483 domains with email that DNS Doctor last checked in October 2026, 28% had no DMARC record.\n \n- Only about half (52.1%) of the world's 1.8 million busiest websites had a DMARC record in early 2026.\n \n- Since April 2025, GoDaddy adds a DMARC record set to `p=quarantine` to every domain newly bought or transferred there.\n \n\n#### DMARC at `p=none` (`DMARC is published but p=none`)\n\n- `p=none` only asks for reports; it does not ask providers to block fake mail.\n \n- Providers that send DMARC reports send them about once a day by default.\n \n- Each report counts the mail sent as your domain and whether it passed SPF and DKIM.\n \n- Our numbers: of 483 domains with email we checked in October 2026, 35% were at `p=none`.\n \n- Of the top million websites that publish DMARC, fewer than half (46.9%) ask providers to block or junk fake mail.\n \n- 95% of Fortune 500 companies publish DMARC, and more than 80% of them have moved past `p=none`.\n \n\n#### DMARC without a `rua=` address (no reports requested)\n\n- Without a `rua=` address, mailboxes have nowhere to send their daily reports, so you cannot see who sends as you.\n \n\n#### Two DMARC records (`Multiple DMARC records found`)\n\n- With two DMARC records, providers apply neither, as if you had none.\n \n\n#### DMARC at `p=quarantine` or `p=reject` (why keep reading the reports)\n\n- `p=quarantine` asks providers to treat failing mail as suspicious, often the spam folder.\n \n- `p=reject` asks providers to refuse failing mail outright.\n \n- A new sending service can fail DMARC until it signs or sends mail aligned with your domain.\n \n- Forwarded mail and mailing lists can fail DMARC even when the mail is really yours.\n \n- DMARC reports are worth reading after enforcing: a new or broken sender shows up there first.\n \n- 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%).\n \n- Among the 5,000 largest US organisations, 38.4% of domains are at `p=reject` and 22% at `p=quarantine`.\n \n\n#### No SPF record (`No SPF record found`)\n\n- Since February 2024, Gmail requires SPF or DKIM from every sender.\n \n- Bulk senders to Yahoo need both SPF and DKIM.\n \n- Our numbers: of 483 domains with email we checked in October 2026, 7.5% had no SPF record.\n \n\n#### Two SPF records (`SPF record is invalid` because a second record exists)\n\n- A domain may have only one SPF record; with two, the SPF check returns an error (permerror).\n \n\n#### SPF over or near 10 lookups (`SPF exceeds the 10 DNS-lookup limit`, `SPF is near the 10-lookup limit`)\n\n- SPF allows 10 DNS lookups. Past that, receivers treat the whole record as broken, even for your real senders.\n \n- The limit counts the whole chain: the includes inside your includes count too.\n \n\n#### SPF ends in `~all` (observation only: SPF is diagnose-only, never propose changing it)\n\n- Our numbers: of the SPF records we found in October 2026 on domains with email, 53% end in `~all`.\n \n\n#### DKIM not found (`DKIM: checked common selectors, none found`)\n\n- The scan tries common selector names only, so a key under another name can still exist.\n \n- Bulk senders to Yahoo and Outlook.com need DKIM, not just SPF.\n \n- DKIM usually survives forwarding when the message is unchanged; SPF often does not.\n \n\n#### DKIM key of 1024 bits (`uses a weak 1024-bit key`)\n\n- 1024-bit DKIM keys still work; 2048 bits is recommended where your email provider offers it.\n \n- Our numbers: of the DKIM keys we found in October 2026 on domains with email, 28% were 1024-bit.\n \n\n#### DKIM found (`check_dkim_selector`: the selector is published)\n\n- DKIM signs each message so mailboxes can tell it was not changed on the way. Each sending service uses its own key.\n \n\n#### No MX records (`No MX records`)\n\n- With no MX record, senders try your domain's own address instead, usually the website server.\n \n- A domain that takes no mail can say so with a \"null MX\" record.\n \n\n#### Own mail server (`check_reverse_dns`: `ptr_missing`, `mismatch`)\n\n- Gmail requires a sending server's address to have matching forward and reverse DNS (a PTR record).\n \n- Gmail requires mail to arrive over an encrypted (TLS) connection.\n \n- Mail servers typically check blocklists on every incoming connection.\n \n\n#### Blocklist listing (`Listed on ...`)\n\n- The blocklists this check queries list mail server IP addresses, not domain names.\n \n- Mail servers typically check blocklists on every incoming connection, so a listing can stop mail at the door.\n \n\n#### Logo in the inbox (`check_bimi`)\n\n- Gmail shows a BIMI logo only when DMARC is at `p=quarantine` or `p=reject`.\n \n- For a BIMI logo, Gmail needs a mark certificate (VMC or CMC); the blue checkmark needs a VMC.\n \n\n#### Propagation and TTL (`check_record` says `wait`, `check_propagation`)\n\n- Every record has a TTL: how long other servers may keep the old copy before asking again.\n \n- Each resolver keeps the old answer until its cache time (TTL) runs out, so locations update at different moments.\n \n- If someone looked the record up before it existed, \"not found\" can be remembered for a while too.\n \n\n#### Look-alike domains (`check_lookalikes`)\n\n- DMARC protects only your exact domain; it cannot stop someone sending from a look-alike name.\n \n- Business email scams caused about 3 billion US dollars in losses reported to the FBI in 2025.\n \n\n#### Email test (`get_email_test`: spam placement, alignment)\n\n- DMARC passes only when the From domain matches a domain that SPF or DKIM checked.\n \n- Gmail wants spam complaints below 0.3% of your mail and recommends staying under 0.1%.\n \n- Gmail requires one-click unsubscribe on marketing mail from anyone sending over 5,000 a day.\n \n- Since November 2025, Gmail has been stepping up enforcement on mail that misses its sender rules.\n \n\n#### Website certificate expiring (`TLS certificate expires in`, `TLS certificate expired on`)\n\n- From March 15, 2026, new website certificates last at most 200 days; 100 from 2027, 47 from 2029.\n \n- Let's Encrypt certificates last 90 days, and it recommends renewing every 60.\n \n- Our numbers: of 600 domains we checked in October 2026, about 5% had a certificate expired or within 30 days of it.\n \n\n#### Domain registration expiring (`domain registration expires in`, `lookup_registration`)\n\n- For .com and other generic domains, registrars must remind you about a month and a week before expiry.\n \n- After a domain expires, its website and email may be interrupted until it is renewed.\n \n- Auto-renew at your registrar reduces the risk of expiry; check that each renewal actually went through.\n \n- About 1 in 4 .com and .net domains is not renewed: the renewal rate was 75.2% in mid-2026.\n \n- About 50,000 lapsed domains are registered again by someone else every day, and can receive mail meant for the old owner.\n \n\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}