kmaofny.com — DNS Changes Log

Running record of every DNS modification made during the 2026-04-22 incident remediation. Format: what was changed, when, why. For inclusion in the final client-facing email.

2026-04-22 — DMARC policy strengthened

Record changed: _dmarc (TXT)

Before After
Value "v=DMARC1; p=none;" "v=DMARC1; p=quarantine;"

Why: The previous DMARC policy was in "monitor only" mode (p=none). This tells receiving mail servers to observe but not act on failed DMARC alignment checks. After a site compromise that included potential outbound-spam abuse from the kmaofny.com domain, moving to p=quarantine instructs receiving servers to send any email that fails SPF or DKIM alignment to recipients' spam folders instead. This starts actively protecting the domain's sending reputation and is the minimum policy level mail-security-conscious receivers (including AECOM) look for.

Effect on legitimate mail: None. Microsoft 365 outbound mail (via SPF include:spf.protection.outlook.com) remains unaffected. Mailchimp mail remains unaffected (signed with DKIM via k2._domainkey and k3._domainkey). Salesforce mail remains unaffected (signed via kmdnsselector._domainkey and km._domainkey). Only mail that falsely claims to be from @kmaofny.com without valid authentication will be quarantined.

Portal: Earthlink DNS Manager (https://control.earthlink.net/portal/ → Domain Manager → DNS Manager → _dmarc TXT row → Edit).

Propagation: Earthlink's portal notes "up to one business day" for zone file edits to complete. External resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1) will show the updated record once Earthlink's authoritative nameservers publish the change.

Planned next steps (future DMARC graduation):

  1. Monitor for 1-2 weeks with p=quarantine — verify no legitimate mail is flagged.
  2. If clean, graduate to p=reject for maximum protection.
  3. Optionally add rua=mailto:postmaster@kmaofny.com for aggregate report delivery (requires postmaster@ inbox to be active).

2026-04-27 — Salesforce DKIM CNAMEs added (new selectors)

Records added: Two new CNAMEs to authenticate Salesforce-sent mail under fresh DKIM keys provisioned by KMA's Salesforce admin.

Name Type Value
kma2026._domainkey.kmaofny.com CNAME kma2026.8rq594.custdkim.salesforce.com.
kmaofny2026._domainkey.kmaofny.com CNAME kmaofny2026.g39iib.custdkim.salesforce.com.

Why: Per the client's Salesforce DKIM record (Key Size 2048, selectors kma2026 + kmaofny2026, domain kmaofny.com, TXT Record Status "Published"). Salesforce will not flip the record to "Active" until both CNAMEs resolve from public DNS. These supplement the existing Salesforce DKIM CNAMEs (kmdnsselector._domainkey and km._domainkey) — the older selectors remain in place; the new pair is the rotation/replacement set.

Effect on legitimate mail: None directly; this enables future Salesforce-sent mail signed with the new selectors to pass DKIM. SPF, MX, DMARC unchanged.

Portal: Earthlink DNS Manager → DNS Records → ADD RECORD (CNAME). Both records confirmed visible in the zone after save (zone now has 20 records, was 18).

Propagation: Initial dig at submission time (~9:30 AM Central) returned empty from public resolvers AND from Earthlink's own authoritative nameserver — consistent with Earthlink's documented "up to one business day" zone publish delay. Re-checked at ~9:45 AM Central and BOTH records were already resolving worldwide from dns1.earthlink.net, Google 8.8.8.8, and Cloudflare 1.1.1.1 with the expected Salesforce targets. Far faster than the documented window. Pre-scheduled tomorrow-morning verification routine was disabled (no longer needed).

Verified resolutions (2026-04-27 ~9:45 AM CDT):

$ dig +short CNAME kma2026._domainkey.kmaofny.com @8.8.8.8
kma2026.8rq594.custdkim.salesforce.com.

$ dig +short CNAME kma2026._domainkey.kmaofny.com @1.1.1.1
kma2026.8rq594.custdkim.salesforce.com.

$ dig +short CNAME kmaofny2026._domainkey.kmaofny.com @8.8.8.8
kmaofny2026.g39iib.custdkim.salesforce.com.

$ dig +short CNAME kmaofny2026._domainkey.kmaofny.com @1.1.1.1
kmaofny2026.g39iib.custdkim.salesforce.com.

2026-04-27 (cont.) — Older Salesforce DKIM records found broken (no change made yet)

Discovery during today's verification work: the two pre-existing Salesforce DKIM CNAMEs in the zone (km._domainkey and kmdnsselector._domainkey — likely added years ago for an earlier Salesforce setup) were entered with the FQDN typed into Earthlink's Name field. Earthlink then auto-appended .kmaofny.com to the entry, so the records actually live at the doubled name:

$ dig CNAME km._domainkey.kmaofny.com.kmaofny.com @dns1.earthlink.net
;; ANSWER SECTION:
km._domainkey.kmaofny.com.kmaofny.com. 86400 IN CNAME km.xrvz6g.custdkim.salesforce.com.

$ dig CNAME kmdnsselector._domainkey.kmaofny.com.kmaofny.com @dns1.earthlink.net
;; ANSWER SECTION:
kmdnsselector._domainkey.kmaofny.com.kmaofny.com. 86400 IN CNAME kmdnsselector.ld6qom.custdkim.salesforce.com.

No mail server queries ..._domainkey.kmaofny.com.kmaofny.com. for DKIM verification — they query the singly-named version, which doesn't exist. So both old records have been silently inert since their creation. The entire reason Chris generated new selectors (kma2026 / kmaofny2026) today is the rotation away from these stale keys.

No action taken. Pending Chris's confirmation that km and kmdnsselector are fully deprecated on the Salesforce side (question included in the 2026-04-27 reply email). If deprecated → delete the broken DNS entries and log here. If still in use on Salesforce's end → re-publish at the correct (relative) path.

Other DKIM records in zone are correctly entered and resolving: k2._domainkey → dkim2.mcsv.net. (Mailchimp), k3._domainkey → dkim3.mcsv.net. (Mailchimp). No double-domain issue with those — only the older Salesforce pair is affected.

What was NOT changed

For the record: no other DNS records on kmaofny.com were modified during this incident response. SPF remains v=spf1 include:spf.protection.outlook.com -all (correctly strict). DKIM records for Mailchimp and the older Salesforce selectors remain in place. MX records still route via AppRiver (arsmtp.com). A records for web, VPN, and webmail endpoints are unchanged.

The nameservers themselves (dns1/2/3.earthlink.net) were not changed. Earthlink remains the DNS authority for kmaofny.com.

Future recommendations (not yet executed)

The following DNS-related work is recommended but was NOT done in this engagement:

  1. Add DMARC aggregate reporting: rua=mailto:postmaster@kmaofny.com so KMA receives weekly reports of authentication failures. Requires verifying that postmaster@kmaofny.com or a chosen alternative inbox accepts mail.
  2. Graduate DMARC to p=reject after 1-2 weeks of clean monitoring under p=quarantine.
  3. Consider MTA-STS and TLS-RPT records for stronger mail security signaling.
  4. Nameserver redundancy review: Earthlink's three nameservers are all on the same provider. Not a security issue, but a resilience consideration.

Document maintained by Grain & Mortar during the 2026-04-22 kmaofny.com security incident response.