Set up DMARC reports and policy in cPanel, Cloudflare and other DNS providers Print

Quick answer

Set up DMARC by inventorying legitimate senders, verifying SPF/DKIM alignment with your visible From domain, and publishing one reviewed TXT policy at the correct _dmarc name. Start a new rollout with monitoring and an approved aggregate-report destination, then review real sending before considering enforcement. Preserve a stricter existing policy unless a deliberate recovery decision requires changing it.

Applies to

Interactive Online business domains using cPanel mail or external senders. You need permission to edit authoritative DNS and access to the sending services and report destination. DMARC concerns use of your domain in outgoing From addresses; changing your policy does not configure every incoming-mail filter or prevent display-name and lookalike-domain scams.

Understand alignment and policy

A message needs a passing authentication result that aligns with its visible From domain. SPF evaluates the envelope-sender domain; DKIM authenticates the signature's signing domain. An unrelated vendor domain can pass its own checks while your From domain still fails DMARC. Relaxed alignment permits the appropriate related domain relationship; strict alignment requires an exact domain match. Check the current domain-discovery rules and actual receiver result rather than assuming any similar-looking domain aligns.

• p=none requests monitoring without DMARC-specific enforcement. It does not disable a receiver's spam or security filtering.
• p=quarantine requests more restrictive handling for failures, commonly junk/quarantine.
• p=reject requests rejection handling for failures. Receivers also apply their own policies and analysis; this is not a guarantee that every failed message is rejected.

The May 2026 DMARC standard, RFC 9989, replaced RFC 7489 and removed the old pct tag. Some provider screens and help pages still expose it. Do not use a low percentage as a dependable safety control. Domains publishing p=reject must not rely on SPF alone and must apply valid DKIM signatures; forwarding and mailing lists need particular review.

1. Prepare monitoring and a record of the old policy

1. Read the existing DMARC TXT record and TTL for the From domain. Also review relevant organizational-domain and subdomain policies. Keep the exact old value and identify who approves a change.
2. Verify all legitimate senders, including mailbox users, forms, newsletters, billing and store messages. Fix their SPF and DKIM setup before tightening policy.
3. Create or select a controlled aggregate-report mailbox or approved reporting service. Confirm it accepts reports and who can read the resulting sender/IP/volume data. External reporting destinations can require additional DNS authorization supplied by the reporting provider.
4. Choose an initial monitoring policy for a new rollout. If a restrictive policy already works, investigate the specific problem rather than replacing it with this starter example.

2. Publish the reviewed TXT record

This fictional example requests aggregate reports in monitoring mode. The mailbox must exist and be approved before adapting it:

Name: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

1. Our cPanel is authoritative: open Domains > Zone Editor > Manage for the domain. Edit its existing _dmarc TXT value or add the intended TXT record. Some versions offer a DMARC form; review the resulting TXT value. Email Deliverability can offer a suggested policy, but that default is not a substitute for your sender inventory and report destination.
2. Cloudflare is authoritative: select the domain, open DNS > Records, then edit the existing _dmarc TXT record or use Add record > TXT if none exists. Enter the reviewed name and content, save, and read it back.
3. Another provider is authoritative: use the overview's GoDaddy, Namecheap, Squarespace or Route 53 path. Follow its relative-name rules. For a sending subdomain, the record name differs, for example _dmarc.news within an example.com zone.
4. Keep one valid DMARC policy at that exact name. Do not create several TXT policies beginning v=DMARC1 or overwrite SPF, DKIM or unrelated verification records. A local cPanel record does not update an external authoritative zone.

3. Verify reports and legitimate messages

nslookup -type=TXT _dmarc.example.com

Check the public answer and the provider's saved record separately. Then inspect fresh controlled messages from every important sender for dmarc=pass header.from= and the aligned SPF or DKIM result. Allow for the previous DNS TTL and the reporting services' delivery schedule. Not every receiver sends reports, and reports are not immediate.

Review aggregate results over a complete business sending cycle. Identify legitimate sources, authentication/alignment failures, forwarding and mailing-list traffic, and unknown sources. Investigate an unknown source before authorizing it. Aggregate reports are typically machine-readable files; use an approved parser or reporting service. Avoid enabling forensic/failure reports casually, since they can expose message-related data and are not universally supported.

4. Decide whether enforcement fits your domain

After resolving legitimate failures, agree on an enforcement plan and recovery criteria with the email administrator. Review subdomain policy separately, keep aligned DKIM working, test representative forwarding paths, and monitor after each intentional change. For routine user domains that participate in internet mailing lists, the current standard cautions against blanket reject policies and recommends extended monitoring before considering one. There is no universal deadline after which every domain is safe to switch to reject.

Troubleshooting and recovery

• SPF/DKIM pass, DMARC fails: compare their authenticated domains with From; a green vendor check alone does not establish alignment.
• Reports do not arrive: verify the rua address, delivery/filtering, DNS value and any external-destination authorization. A missing report does not prove no messages were sent.
• Permerror or no policy found: check syntax, the exact name, duplicate policy records and authoritative DNS. Do not add repeated records while waiting for caches.
• Legitimate mail fails after enforcement: identify its sender/path and compare the change record. If an approved temporary rollback is needed, restore only the reviewed policy after checking for later edits, then fix the sender and revalidate. Do not disable domain protection permanently to hide an unresolved fault.

When to contact support

Contact Interactive Online if your email-enabled hosting service, cPanel controls, DNS authority or suggested cPanel sender values are unclear. Include the domain, exact error, affected sending service, time and time zone, and redacted authentication results or bounce details. Use a sample screenshot when possible. Keep passwords, cookies, private signing keys and API tokens out of the ticket. For Google Workspace, Microsoft 365 or another sender, obtain that service's current authentication values from its administrator. We can help identify the hosting side; access to your external DNS or email account is separate.

Related help

• Overview and DNS-provider instructions
• Review SPF sender authorization
• Enable aligned DKIM signing
• Investigate a missing message
• Preserve email records when moving DNS to Cloudflare

Official references

• Current DMARC standard and rollout considerations
• DMARC aggregate reporting and external destinations
• Google Workspace DMARC preparation
• Microsoft 365 DMARC setup and diagnostic examples
• cPanel TXT and DMARC editing controls
• Cloudflare email DNS records

Content and primary-source review by Interactive Online: November 2, 2026. Provider documentation and applicable standards were reviewed. DNS records, signing keys and mail settings were not changed for this article. Menu names and available controls depend on your account, theme and permissions.