Remediation — staged DMARC ramp in GoDaddy

This is the procedure for taking a client domain from no DMARC (or p=none) to p=reject without breaking legitimate mail. Three phases, each verified in Cathedra before moving on.

The whole ramp takes 8–12 weeks on a typical client. Faster is possible if the mail estate is small and clean. Slower if the client has a long tail of third-party senders.

Before you start

Two things to confirm in IT Glue:

1. Access model. Is the domain in the Isidore-managed GoDaddy master account, or is it a delegated account you switch into? The procedure is the same in either case; the account context differs. (Covered in detail in Module 2.)
2. A reporting destination. Either a mailbox on the client’s domain that forwards to an Isidore-monitored address, or a dmarcian intake address, or both. Get this set up before you publish the record — there is no point publishing rua= to an address that does not exist.

Then run Cathedra once against the domain. Record the current DMARC finding. That is your baseline.

Phase 1 — Monitoring only (p=none)

The first DMARC record you publish.

v=DMARC1; p=none; rua=mailto:dmarc-reports@isidoregroup.com

GoDaddy steps

1. DNS Management → the client domain → Add under DNS Records.
2. Type: TXT.
3. Host: _dmarc (GoDaddy appends the domain automatically — do not type the full hostname).
4. TXT Value: the record above, exactly. No surrounding quotes — GoDaddy adds them on save.
5. TTL: 1 hour (the default) is fine.
6. Save.

Verify

From terminal:

dig _dmarc.isidoregroup.com TXT +short
"v=DMARC1; p=none; rua=mailto:dmarc-reports@isidoregroup.com"

Then re-run Cathedra. Expected finding change:

• Before: error / high — “No DMARC record found at _dmarc.{domain}. Phishing protection is absent.”
• After: warning / high — “DMARC policy is p=none. Unauthenticated mail is not blocked or quarantined.”

Severity stays high. That is correct. p=none is the right starting state but not a finishing state.

Wait

Leave the record at p=none for 4–6 weeks. During that window:

• Aggregate reports arrive daily from every receiver the domain produces traffic to.
• You build a list of every legitimate sender and confirm each one is aligned. Marketing platforms, CRM tools, payroll, scheduling, transactional senders — every one of them.
• For any unaligned legitimate sender, you fix the alignment: publish a DKIM CNAME the platform wants, change envelope domain in the platform’s settings, or document why an exception is permanent.

Do not move to Phase 2 until reports are clean. “Clean” means every alignment failure in the reports is something you can identify as illegitimate (a spoof attempt) or something you have decided to live with (a small specific sender you cannot fix, knowing it will be quarantined or rejected).

Phase 2 — Quarantine 10% (p=quarantine; pct=10)

Replace the record value. The TXT entry at _dmarc is edited, not added — you only ever want one DMARC record per zone.

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@isidoregroup.com

GoDaddy steps

1. DNS Management → find the existing _dmarc TXT record → Edit.
2. Replace the value with the Phase 2 string above. Save.

Verify

dig _dmarc.isidoregroup.com TXT +short
"v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@isidoregroup.com"

Re-run Cathedra. Expected findings:

• warning / medium — “DMARC policy is p=quarantine. Unauthenticated mail is sent to spam, not rejected.”
• warning / low — “DMARC pct=10%. Policy only applies to 10% of failing messages.”

Two warnings now, but the policy check moved from high to medium severity — directional progress.

Wait

2 weeks at pct=10. Watch reports for receiver disposition flipping from none (under p=none) to quarantine for the 10% slice. Confirm no legitimate sender suddenly starts complaining.

Then step up:

• Edit to pct=25. Wait 1 week.
• Edit to pct=50. Wait 1 week.
• Edit to pct=100. Wait 2 weeks.

At each step, Cathedra still reports the policy warning and the pct warning until you reach 100. At pct=100, the pct warning disappears — only the policy warning remains.

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@isidoregroup.com

(pct=100 is the default, so the tag drops out.)

Phase 3 — Reject (p=reject)

The final state.

v=DMARC1; p=reject; rua=mailto:dmarc-reports@isidoregroup.com

GoDaddy steps

1. DNS Management → edit the existing _dmarc TXT record.
2. Change p=quarantine to p=reject. Save.

Verify

dig _dmarc.isidoregroup.com TXT +short
"v=DMARC1; p=reject; rua=mailto:dmarc-reports@isidoregroup.com"

Re-run Cathedra. Expected finding:

• pass — “DMARC policy is p=reject. Unauthenticated mail will be rejected.”

The DMARC check now returns pass. You are done with the ramp.

Cheat sheet — TXT values per phase

Phase	Host	TXT Value
1 (monitor)	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc-reports@isidoregroup.com
2a (10%)	_dmarc	v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@isidoregroup.com
2b (25%)	_dmarc	v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@isidoregroup.com
2c (50%)	_dmarc	v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@isidoregroup.com
2d (100%)	_dmarc	v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@isidoregroup.com
3 (reject)	_dmarc	v=DMARC1; p=reject; rua=mailto:dmarc-reports@isidoregroup.com

Common interruptions to the ramp

A new third-party sender is added mid-ramp. Pause the ramp. Hold at the current phase, wait two weeks of reports to confirm the new sender is aligned, then resume.

Marketing pushes a campaign that fails. If you are in Phase 2 and a legitimate campaign was caught, fall back one step (pct=50 → pct=25, or pct=10 → p=none) while you fix the campaign’s alignment. Document the rollback in the engagement notes.

Client wants to skip ahead. Push back. The point of the ramp is to surface alignment problems gradually. Skipping phases trades visibility for speed and usually creates an outage that costs more than the four weeks saved.

What you should remember

• Three phases: p=none 4–6 weeks → p=quarantine ramping pct 10/25/50/100 → p=reject.
• Always edit the existing _dmarc TXT, never add a second. One DMARC record per zone.
• Cathedra finding changes track the ramp: error → warning/high → warning/medium → pass.
• Reports drive promotion. Promote on clean reports, not on calendar.
• Pause or fall back when a new sender appears or a legitimate campaign is caught. Document the rollback.

---

Cathedra alignment: DmarcRecordCheck.php — moving a domain from missing/none to reject across the three phases, verified by Cathedra at each step