Update to DNS Doctor - Email & DMARC

{
  "description": "Use when the user has just published or edited a DNS record (DMARC, SPF, DKIM, MX, TXT, CNAME, A) and asks whether it worked, landed, is live or has propagated. Reads the record from the domain's own nameservers with DNS Doctor, then checks propagation from six vantage points, and says when to look again after the TTL. Observation only; never composes a record.",
  "included_files": [],
  "name": "verify-change",
  "skill_md_contents": "---\nname: verify-change\ndescription: Use when the user has just published or edited a DNS record (DMARC, SPF, DKIM, MX, TXT, CNAME, A) and asks whether it worked, landed, is live or has propagated. Reads the record from the domain's own nameservers with DNS Doctor, then checks propagation from six vantage points, and says when to look again after the TTL. Observation only; never composes a record.\n---\n\n# Verify a DNS change\n\nThe user changed a record and wants to know it worked. Three reads, in order,\neach ending on the next one. Stop when the user's question is answered.\n\n## Rules\n\n- **Observation only.** No record is ever composed here. If the user needs a\n  record, it comes from a DNS Doctor tool result, printed verbatim.\n- An empty answer is absence; a lookup failure (`cant_tell`, `transient`,\n  `unavailable`) is unknown, never \"the record is missing\".\n- SPF is diagnose-only: if the SPF read looks wrong, relay what was found and\n  never propose an SPF edit of your own.\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. **Did it land?** Call `check_record` with the domain, the `kind`\n   (`spf`, `dmarc`, `txt`, `mx`, `cname`, `a`, `aaaa`), `host` for a label such\n   as `selector1._domainkey` or `www` (txt, cname, a and aaaa only), and `expected_value` set to the value\n   they published (exactly as they gave it, or as the tool that issued it\n   returned it). Relay `verdict`:\n   - `done`: their nameservers serve it and both caches agree. End with:\n     \"Want me to check it has reached every region?\" and, on yes, go to step 2.\n   - `wait`: it is published, caches are still catching up. Say when to look\n     again (`check_again_after_seconds`, said in minutes) and end with: \"Tell\n     me then and I'll check again.\"\n   - `edit`: their nameservers do not serve it. If `found_at` names another\n     place, say the value was published there instead (often the domain typed\n     twice in the host field). End with: \"Fix that, then tell me and I'll check\n     again.\"\n   - `not_registered: true`: the domain does not exist (usually a typo). Ask\n     which domain they meant.\n   Two resolvers is the whole sample of this read: never call it worldwide.\n   If the user wants to be told when it lands (on `wait` or `edit`), call\n   `watch_record_change` with the same arguments: one email to their linked\n   account. Relay `watch.note`; never ask for an email address.\n2. **Has it propagated?** Call `check_propagation` with the exact name the\n   record lives at (`_dmarc.example.com` for DMARC, `selector._domainkey.example.com`\n   for DKIM, the apex for SPF and MX), `record_type` (`TXT` for SPF, DMARC and\n   DKIM), and the same `expected_value`. You have one network vantage point; this\n   reads six. Report `vantage_reached` of `vantage_total`. An `unavailable` cell\n   is a probe that did not answer, never absence there. A `verdict` of\n   `unknown` means coverage was too thin to call: say so, never round it up.\n   If some regions still show the old value, end with when to look again (the\n   record's TTL) and \"tell me then and I'll check again\".\n3. **Confirm the effect.** When the change was a fix from a DNS Doctor scan,\n   once step 1 says `done` call `scan_domain` again and say whether the check\n   now passes. When it was a DNS Doctor verification record, call\n   `check_domain_verification` instead.\n\nOne tap of \"check again\" from the user is one call. Never loop calls while\nwaiting; ask the user to come back after the wait.\n\nThe page <https://dnsdoctor.dev/tools/dns-propagation-checker> runs the same\npropagation check for the user; if you offer it, print the link as is.\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<!-- fact-bank:start (generated from backend/dns_doctor/education/facts.py by `python -m tests.mcp_server.regen_fact_bank`; never edit by hand) -->\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  <!-- source: RFC 7489 §6.3, https://www.rfc-editor.org/rfc/rfc7489.html#section-6.3 -->\n- Gmail requires DMARC from anyone sending more than 5,000 messages a day to Gmail; `p=none` is enough.\n  <!-- source: Google, 2024, https://support.google.com/a/answer/81126 -->\n- Yahoo has required DMARC (at least `p=none`) from bulk senders since February 2024.\n  <!-- source: Yahoo, 2024, https://senders.yahooinc.com/best-practices/ -->\n- Since May 5, 2025, Outlook.com refuses mail from domains sending over 5,000 a day without SPF, DKIM and DMARC.\n  <!-- source: Microsoft, 2025, https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730 -->\n- When Outlook.com refuses a bulk sender for missing SPF, DKIM or DMARC, the bounce reads \"550 5.7.515 Access denied\".\n  <!-- source: Microsoft, 2025, https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730 -->\n- Phishing and spoofing was the crime most often reported to the FBI in 2025: 191,561 complaints.\n  <!-- source: FBI IC3 2025 Annual Report, https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf -->\n- Our numbers: of the 483 domains with email that DNS Doctor last checked in October 2026, 28% had no DMARC record.\n  <!-- source: DNS Doctor scans, October 2026, scripts/skill_stats.sql (dmarc_none_found_pct) -->\n- Only about half (52.1%) of the world's 1.8 million busiest websites had a DMARC record in early 2026.\n  <!-- source: EasyDMARC 2026 DMARC Adoption Report (top 1.8M domains), https://easydmarc.com/blog/easydmarc-releases-2026-dmarc-adoption-report/ -->\n- Since April 2025, GoDaddy adds a DMARC record set to `p=quarantine` to every domain newly bought or transferred there.\n  <!-- source: GoDaddy, 2025 (checked 2026-11), https://www.godaddy.com/resources/skills/enhancing-domain-security-dmarc-implementation -->\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  <!-- source: RFC 7489 §6.3, https://www.rfc-editor.org/rfc/rfc7489.html#section-6.3 -->\n- Providers that send DMARC reports send them about once a day by default.\n  <!-- source: RFC 7489 §6.3 (ri default 86400 seconds), https://www.rfc-editor.org/rfc/rfc7489.html#section-6.3 -->\n- Each report counts the mail sent as your domain and whether it passed SPF and DKIM.\n  <!-- source: RFC 7489 §7.2, https://www.rfc-editor.org/rfc/rfc7489.html#section-7.2 -->\n- Our numbers: of 483 domains with email we checked in October 2026, 35% were at `p=none`.\n  <!-- source: DNS Doctor scans, October 2026, scripts/skill_stats.sql (dmarc_p_none_pct) -->\n- Of the top million websites that publish DMARC, fewer than half (46.9%) ask providers to block or junk fake mail.\n  <!-- source: Internet Society Pulse, Tranco top 1M, July 2026, https://pulse.internetsociety.org/en/blog/two-providers-a-stubborn-plateau-and-a-very-long-tail-email-in-the-tranco-top-1m/ -->\n- 95% of Fortune 500 companies publish DMARC, and more than 80% of them have moved past `p=none`.\n  <!-- source: EasyDMARC 2026 DMARC Adoption Report, https://easydmarc.com/blog/easydmarc-releases-2026-dmarc-adoption-report/ -->\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  <!-- source: RFC 7489 §6.3 (rua, ri default 86400 seconds), https://www.rfc-editor.org/rfc/rfc7489.html#section-6.3 -->\n\n#### Two DMARC records (`Multiple DMARC records found`)\n\n- With two DMARC records, providers apply neither, as if you had none.\n  <!-- source: RFC 7489 §6.6.3, https://www.rfc-editor.org/rfc/rfc7489.html#section-6.6.3 -->\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  <!-- source: RFC 7489 §6.3, https://www.rfc-editor.org/rfc/rfc7489.html#section-6.3 -->\n- `p=reject` asks providers to refuse failing mail outright.\n  <!-- source: RFC 7489 §6.3, https://www.rfc-editor.org/rfc/rfc7489.html#section-6.3 -->\n- A new sending service can fail DMARC until it signs or sends mail aligned with your domain.\n  <!-- source: RFC 7489 §3.1 (alignment), https://www.rfc-editor.org/rfc/rfc7489.html#section-3.1 -->\n- Forwarded mail and mailing lists can fail DMARC even when the mail is really yours.\n  <!-- source: RFC 7960 §1 and §2.2, https://www.rfc-editor.org/rfc/rfc7960.html -->\n- DMARC reports are worth reading after enforcing: a new or broken sender shows up there first.\n  <!-- source: RFC 7489 §7.2 (reports carry per-source SPF/DKIM results), https://www.rfc-editor.org/rfc/rfc7489.html#section-7.2 -->\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  <!-- source: DNS Doctor scans, October 2026, scripts/skill_stats.sql (dmarc_quarantine_pct, dmarc_reject_pct) -->\n- Among the 5,000 largest US organisations, 38.4% of domains are at `p=reject` and 22% at `p=quarantine`.\n  <!-- source: Red Sift US DMARC adoption report, March-June 2026, https://findthephish.redsift.com/blog/us-dmarc-adoption-report -->\n\n#### No SPF record (`No SPF record found`)\n\n- Since February 2024, Gmail requires SPF or DKIM from every sender.\n  <!-- source: Google, 2024, https://support.google.com/a/answer/81126 -->\n- Bulk senders to Yahoo need both SPF and DKIM.\n  <!-- source: Yahoo, 2024, https://senders.yahooinc.com/best-practices/ -->\n- Our numbers: of 483 domains with email we checked in October 2026, 7.5% had no SPF record.\n  <!-- source: DNS Doctor scans, October 2026, scripts/skill_stats.sql (spf_missing_pct) -->\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  <!-- source: RFC 7208 §4.5, https://www.rfc-editor.org/rfc/rfc7208.html#section-4.5 -->\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  <!-- source: RFC 7208 §4.6.4, https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4 -->\n- The limit counts the whole chain: the includes inside your includes count too.\n  <!-- source: RFC 7208 §4.6.4 (\"during SPF evaluation\"), https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4 -->\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  <!-- source: DNS Doctor scans, October 2026, scripts/skill_stats.sql (spf_softfail_pct_of_found) -->\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  <!-- source: DNS Doctor's DKIM check, its own title (\"checked common selectors\") -->\n- Bulk senders to Yahoo and Outlook.com need DKIM, not just SPF.\n  <!-- source: Yahoo 2024, https://senders.yahooinc.com/best-practices/ ; Microsoft 2025, https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730 -->\n- DKIM usually survives forwarding when the message is unchanged; SPF often does not.\n  <!-- source: RFC 7960 §2.2 and §3.2.1, https://www.rfc-editor.org/rfc/rfc7960.html -->\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  <!-- source: RFC 8301 §3.2 (MUST at least 1024, SHOULD 2048), https://www.rfc-editor.org/rfc/rfc8301.html#section-3.2 -->\n- Our numbers: of the DKIM keys we found in October 2026 on domains with email, 28% were 1024-bit.\n  <!-- source: DNS Doctor scans, October 2026, scripts/skill_stats.sql (dkim_1024_pct_of_found) -->\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  <!-- source: RFC 6376 §1, https://www.rfc-editor.org/rfc/rfc6376.html#section-1 -->\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  <!-- source: RFC 5321 §5.1 (implicit MX), https://www.rfc-editor.org/rfc/rfc5321.html#section-5.1 -->\n- A domain that takes no mail can say so with a \"null MX\" record.\n  <!-- source: RFC 7505, https://www.rfc-editor.org/rfc/rfc7505.html -->\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  <!-- source: Google, 2024, https://support.google.com/a/answer/81126 -->\n- Gmail requires mail to arrive over an encrypted (TLS) connection.\n  <!-- source: Google, 2024, https://support.google.com/a/answer/81126 -->\n- Mail servers typically check blocklists on every incoming connection.\n  <!-- source: RFC 5782 §6, https://www.rfc-editor.org/rfc/rfc5782.html#section-6 -->\n\n#### Blocklist listing (`Listed on ...`)\n\n- The blocklists this check queries list mail server IP addresses, not domain names.\n  <!-- source: RFC 5782 §2, https://www.rfc-editor.org/rfc/rfc5782.html#section-2 -->\n- Mail servers typically check blocklists on every incoming connection, so a listing can stop mail at the door.\n  <!-- source: RFC 5782 §6, https://www.rfc-editor.org/rfc/rfc5782.html#section-6 -->\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  <!-- source: Google, https://knowledge.workspace.google.com/admin/security/set-up-bimi -->\n- For a BIMI logo, Gmail needs a mark certificate (VMC or CMC); the blue checkmark needs a VMC.\n  <!-- source: Google, https://knowledge.workspace.google.com/admin/security/set-up-bimi -->\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  <!-- source: RFC 1035 §3.2.1, https://www.rfc-editor.org/rfc/rfc1035.html#section-3.2.1 -->\n- Each resolver keeps the old answer until its cache time (TTL) runs out, so locations update at different moments.\n  <!-- source: RFC 1035 §3.2.1 and RFC 2181 §8, https://www.rfc-editor.org/rfc/rfc2181.html#section-8 -->\n- If someone looked the record up before it existed, \"not found\" can be remembered for a while too.\n  <!-- source: RFC 2308 §5 (negative caching, from the zone's SOA), https://www.rfc-editor.org/rfc/rfc2308.html#section-5 -->\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  <!-- source: RFC 7489 §2.4, https://www.rfc-editor.org/rfc/rfc7489.html#section-2.4 -->\n- Business email scams caused about 3 billion US dollars in losses reported to the FBI in 2025.\n  <!-- source: FBI IC3 2025 Annual Report (BEC: 24,768 complaints, 3,046,598,558 USD), https://www.ic3.gov/AnnualReport/Reports/2025_IC3Report.pdf -->\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  <!-- source: RFC 7489 §3.1, https://www.rfc-editor.org/rfc/rfc7489.html#section-3.1 -->\n- Gmail wants spam complaints below 0.3% of your mail and recommends staying under 0.1%.\n  <!-- source: Google, https://support.google.com/a/answer/81126 and https://support.google.com/a/answer/14229414 -->\n- Gmail requires one-click unsubscribe on marketing mail from anyone sending over 5,000 a day.\n  <!-- source: Google, 2024, https://support.google.com/a/answer/81126 -->\n- Since November 2025, Gmail has been stepping up enforcement on mail that misses its sender rules.\n  <!-- source: Google, https://support.google.com/a/answer/14229414 -->\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  <!-- source: CA/Browser Forum Baseline Requirements (Ballot SC-081), https://github.com/cabforum/servercert/blob/main/docs/BR.md -->\n- Let's Encrypt certificates last 90 days, and it recommends renewing every 60.\n  <!-- source: Let's Encrypt FAQ, https://letsencrypt.org/docs/faq/ -->\n- Our numbers: of 600 domains we checked in October 2026, about 5% had a certificate expired or within 30 days of it.\n  <!-- source: DNS Doctor scans, October 2026, scripts/skill_stats.sql (tls_expired_or_expiring_count; 32 of 600 registered domains, with or without email) -->\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  <!-- source: ICANN ERRP §2.1.1, https://www.icann.org/resources/pages/errp-2013-02-28-en -->\n- After a domain expires, its website and email may be interrupted until it is renewed.\n  <!-- source: ICANN ERRP §2.2, https://www.icann.org/resources/pages/errp-2013-02-28-en -->\n- Auto-renew at your registrar reduces the risk of expiry; check that each renewal actually went through.\n  <!-- source: ICANN ERRP §2.2 (DNS resolution is interrupted after expiry), https://www.icann.org/resources/pages/errp-2013-02-28-en -->\n- About 1 in 4 .com and .net domains is not renewed: the renewal rate was 75.2% in mid-2026.\n  <!-- source: Verisign Q3 2026 earnings release (Q2 2026 renewal rate), https://www.sec.gov/Archives/edgar/data/0001014473/000101447326000038/q32026earningsrelease.htm -->\n- About 50,000 lapsed domains are registered again by someone else every day, and can receive mail meant for the old owner.\n  <!-- source: Infoblox, H1 2026 dropcatch study, https://www.infoblox.com/blog/?p=13993 -->\n<!-- fact-bank:end -->\n"
}