Add or Update a DMARC TXT Record in cPanel

DMARC connects SPF or DKIM authentication to the domain in the message’s visible From address. A message can pass DMARC through either an aligned SPF pass or an aligned DKIM pass; it does not require both mechanisms to fail before alignment matters. Publishing a policy does not guarantee phishing prevention or inbox placement.

Prepare before enforcing a policy

Inventory legitimate senders, inspect their authentication/alignment and choose an authorized report destination with appropriate privacy controls. Preserve any existing DMARC record. Do not immediately replace a working strict policy with a copied monitoring example, or enforce rejection before understanding legitimate traffic.

Add or update the authoritative TXT record

1. Open verified HTTPS cPanel, then Domains > Zone Editor > Manage for the intended domain. Older instructions called this Advanced Zone Editor.
2. Confirm this server controls public authoritative DNS. Otherwise make the change at the external provider instead.
3. Find the domain’s DMARC TXT record at _dmarc. Edit the intended existing record rather than creating conflicting policies at that name.
4. Enter the reviewed value and a deliberate supported TTL. Check the saved full owner name to avoid repeating the domain suffix.
5. Save and query authoritative DNS, then inspect actual receiver results and reports where supported.

A minimal monitoring value for a domain that does not already have a policy is shown below. It requests no policy-based enforcement and, without a reporting destination, requests no aggregate reports. It is not a complete deployment plan:

v=DMARC1; p=none

Understand current and legacy tags

v identifies DMARC1; p requests none, quarantine or reject handling for failures; rua requests aggregate reports and sp concerns subdomain policy. Authentication failures and receiver disposition are not identical: receivers retain local handling decisions.

RFC 9989, published May 2026, superseded RFC 7489 and removed pct, introducing a testing tag instead. Older receiver implementations and examples can differ; a percentage in a record is not an accurate measurement of spoofed-message delivery. Legacy report tags such as ruf, fo, rf and ri require their applicable specification/provider support and data-handling review. Reports are requests, not guaranteed receipts or a substitute for mail logs.

Increase enforcement only after reviewing legitimate-source coverage and recovery requirements. Do not use a fixed one-week wait or missing reports alone as evidence that enforcement is safe.

References: cPanel Zone Editor, current DMARC specification and legacy DMARC specification.

Reviewed October 15, 2026. Example syntax/publication was checked with synthetic data; no live policy, report destination or customer sending route was changed.