---
title: Fixing DMARC on advmfr.com
description: Three conflicting records make DMARC invalid, and SPF still trusts the old host. What to change, and who has to change it.
icon: ShieldCheck
verified: 2026-08-18
---

`advmfr.com` is the Google Workspace domain, a different system from
`advmfr.net`, and out of scope of the anti-spam work. It came up anyway, because
its DNS is broken in a way that matters.

Its DNS zone is still hosted at the **previous provider**, which is where the two
problems come from.

## Who has to act

This fix crosses three panels, and no single person holds all three.

| Role | Holds | Acts on |
|---|---|---|
| DNS operator | The old provider's panel | The `advmfr.com` zone |
| cPanel operator | o2switch | The `advmfr.net` zone |
| Workspace admin | Google | Mailboxes on `advmfr.com` |

## Current state

| Item | Verdict |
|---|---|
| `_dmarc` TXT | **Three simultaneous records**: invalid |
| SPF | Still authorises a shared server of the abandoned host |
| DKIM | 2048-bit key published, correct |
| MX | Google, correct |

**DMARC does not work at all.** Not "works partially": when more than one `_dmarc`
record exists, receivers ignore DMARC for the domain entirely. Three records that
each look reasonable add up to none.

**SPF still trusts the old host's shared server.** Anyone with an account on that
machine can send mail as `advmfr.com` and pass SPF. That is a spoofing hole
inherited from a migration that was never finished on the DNS side.

## The first move: whichever option is chosen

**Delete all three `_dmarc` TXT records and publish exactly one.** No option below
works until the domain has a single record.

<Tabs items={['Option 1: reports in-house (recommended)', 'Option 2, reports on the Google side']}>

<Tab>

Reports for both domains land in `dmarc@advmfr.net`, digested by the same local
script, in one weekly report covering both. One mailbox, one script, one digest.
Nothing new to build, and no third party.

<Steps>

<Step>

### DNS operator

On the name `_dmarc`, delete the three TXT records and create one:

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

</Step>

<Step>

### cPanel operator

<CpanelPath steps={['Zone Editor', 'advmfr.net']} /> → add the cross-domain
authorisation:

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

<Callout type="warn">
  This second record is not optional. When the report mailbox is on a different
  domain from the one being reported on, receivers check that the mailbox's domain
  consents. Without it, Google and Microsoft simply never send the reports: and
  they do so silently, so the setup looks correct and produces nothing.
</Callout>

</Step>

</Steps>

</Tab>

<Tab>

Reports go to a mailbox on `advmfr.com`, inside Workspace. No cross-domain record
needed, and the DNS change is a single record.

The cost is two report silos: the weekly digest stops covering `advmfr.com`, whose
reports then sit as raw zipped XML in a Gmail mailbox. Reading them means either
manual work, or extra setup: Gmail IMAP requires two-step verification and an app
password, or OAuth.

In practice, reports nobody reads are reports that do not exist. That is the whole
argument for Option 1.

</Tab>

</Tabs>

## Why `p=none` and not something stronger

`p=none` asks receivers to report, not to act. That is deliberate: hardening a
policy before reading a single report is how legitimate mail gets rejected by your
own DNS. The reports come first; the policy tightens once they show what actually
sends mail as this domain.

The same reasoning drove step 6 of the
[deployment runbook](/docs/it/email/deployment-runbook) on the `.net` side.