# advmfr.com DMARC fix  prepared 2026-08-18

Scope: advmfr.com (Google Workspace mail). Its DNS zone is still hosted at
**Bluehost** (`ns1/ns2.bluehost.com`).

Roles used in this guide:
- **DNS operator (Bluehost)**: whoever holds the Bluehost panel access, where the
  advmfr.com zone is edited.
- **cPanel operator (o2switch)**: whoever holds the cPanel access for advmfr.net.
- **Workspace admin (Google)**: whoever administers Google Workspace for advmfr.com.

## Current state (dig snapshot, 2026-08-18)

| Item | Value | Verdict |
|---|---|---|
| `_dmarc` TXT | **three simultaneous records** (`p=quarantine` + `p=none` + `p=quarantine`, two different rua) | invalid: receivers ignore DMARC entirely when more than one record exists |
| SPF | `v=spf1 ip4:66.147.242.174 include:_spf.google.com ~all` | `66.147.242.174` = `box574.bluehost.com`, a shared Bluehost server from the old hosting. Anyone on that box can send SPF-passing mail as advmfr.com |
| DKIM | `google._domainkey` 2048-bit key published | ✅ good |
| MX | Google (`aspmx.l.google.com` set) | ✅ good |

Bottom line: working DKIM, but **no effective DMARC**, and an SPF that still
trusts the previous hosting provider's shared server.

Whichever option is chosen below, the first move is identical: **delete all
three `_dmarc` TXT records** and publish exactly one.

## Option 1  centralized reports (recommended)

advmfr.com reports go to the same in-house mailbox as advmfr.net
(`dmarc@advmfr.net`), digested by the same local script, one weekly digest
covering both domains.

- ✅ One mailbox, one script, one digest, one hardening ladder to read.
- ✅ Zero third party, nothing new to build (the digester already splits results
  per domain).
- ⚠️ Requires one extra one-line record on the advmfr.net side (cross-domain
  authorization), described below.

### Steps

**1  DNS operator (Bluehost)**: on the name `_dmarc`, delete the three TXT
records, then create ONE TXT record with exactly:

    v=DMARC1; p=none; rua=mailto:dmarc@advmfr.net; pct=100

**2  cPanel operator (o2switch)**: Zone Editor → advmfr.net → add the
cross-domain authorization record (receivers check consent when the report
mailbox domain differs from the reported domain):

| Field | Value |
|---|---|
| Name | `advmfr.com._report._dmarc.advmfr.net.` |
| Type | TXT |
| Value | `v=DMARC1` |

Without it, Google and Microsoft silently refuse to send the reports.

## Option 2  reports stay on the .com side

advmfr.com reports go to a mailbox of its own domain, inside Google Workspace.
No cross-domain record needed.

- ✅ Simplest DNS change (one single record, nothing on the o2switch side).
- ❌ Two report silos: the weekly digest no longer covers advmfr.com, so its
  reports live as raw zipped XML in a Gmail mailbox.
- ❌ Reading them requires either manual work or extra setup (Gmail IMAP needs
  2-Step Verification plus an app password, or OAuth). In practice, reports
  nobody reads are reports that do not exist.

### Steps

**1  Workspace admin (Google)**: create the mailbox or group
`dmarc@advmfr.com` (a group with no members other than an admin is fine; it
just needs to accept external mail).

**2  DNS operator (Bluehost)**: on the name `_dmarc`, delete the three TXT
records, then create ONE TXT record with exactly:

    v=DMARC1; p=none; rua=mailto:dmarc@advmfr.com; pct=100

## SPF cleanup (both options, after one confirmation)

Question to answer first: **does anything still send mail through Bluehost?**
(old WordPress contact forms, scripts on box574).

- If nothing sends from Bluehost anymore (expected), the DNS operator replaces
  the SPF TXT value with:

      v=spf1 include:_spf.google.com ~all

- If something still does, migrate that sender to Google or an authenticated
  channel first; the shared-box authorization must go either way.

Hardening `~all` to `-all` comes later, once DMARC reports confirm only Google
sends for the domain.

## Hardening ladder (both options)

Starting back at `p=none` is not a regression: with three records, the current
`p=quarantine` was ignored by every receiver anyway. Once reports show two
consecutive clean weeks (>= 98% alignment), follow the same ladder as
advmfr.net (runbook step 6d): quarantine pct=25 → 50 → 100 → reject, one step
per week, every step logged in the changelog.

## Verification (after each step)

- Single DMARC record: `dig +short TXT _dmarc.advmfr.com` returns exactly one
  record, with the chosen rua.
- Option 1 authorization: `dig +short TXT advmfr.com._report._dmarc.advmfr.net`
  returns `v=DMARC1`.
- SPF: `dig +short TXT advmfr.com` shows the cleaned value, one record, one `all`.
- Within 48 h: reports start arriving (Option 1: advmfr.com sections appear in
  the weekly digest; Option 2: zipped XML lands in dmarc@advmfr.com).

## Appendix: MXToolbox findings triage (report of 2026-08-18)

| Finding | Reality | Action |
|---|---|---|
| dmarc: "Quarantine/Reject policy not enabled" | True, and the only actionable line of the report | Covered by this fix: single record now, quarantine/reject at the end of the hardening ladder |
| spf/mx [SUPPLEMENTAL]: "recommended to use quarantine or reject... to enable BIMI" | BIMI = brand logo in inboxes, a marketing feature. It needs p=quarantine/reject at 100% AND a paid Verified Mark Certificate (hundreds of USD per year) plus a trademarked logo | Ignore. Re-evaluate as a pure branding decision once the ladder reaches reject, if ever |
| mx [SUPPLEMENTAL]: "Brand Logo not appearing in inboxes" | Same BIMI upsell, phrased differently | Ignore |
| dns: "SOA Serial Number Format is Invalid" | Bluehost zone cosmetics (serial not in YYYYMMDDnn convention). Zero operational impact | Ignore; fixes itself if the zone ever moves |
| dns: "SOA Expire Value out of recommended range" | Bluehost default, cosmetic | Ignore |
| smtp x5: "Reverse DNS does not match SMTP Banner" on aspmx*.l.google.com | These are **Google's** servers, not ours. Every Google Workspace domain on earth gets this line | Ignore |

What MXToolbox did NOT surface, and this fix does: the three conflicting
`_dmarc` records (which void DMARC entirely) and the stale Bluehost shared-server
IP inside SPF. A green scanner dashboard is not the goal; those two are.

## Worth noting (not blocking)

- The whole advmfr.com zone still lives at Bluehost, a provider the company
  left. A later cleanup could move the zone; keep that out of this fix.
- Legitimate senders for the domain are the Google Workspace users plus
  whatever the SPF confirmation reveals.