HostGator DMARC setup

Choose the implementation approach

Use a monitoring-first rollout unless report evidence already accounts for every legitimate source.

• Use p=none when you need visibility into authentication and alignment results without asking receivers to quarantine or reject unauthenticated mail.
• Use p=quarantine only after reports show that legitimate production sources authenticate and align as intended.
• Use p=reject only after the same evidence supports full enforcement.
• Use pct when you need to apply quarantine or reject to a percentage of unauthenticated messages. Google documents that pct must be a whole number from 1 through 100 and defaults to 100 when omitted.

HostGator's article on Google's email sender requirements covers adding a DMARC TXT record, choosing a policy, and rolling it out gradually. It shows no HostGator DNS screens, and it does not replace checking the authoritative DNS zone or inspecting mail from each production path.

How to configure DMARC in HostGator DNS

1. Confirm where the domain's authoritative DNS is hosted

Check the domain's active nameservers and identify the service that answers authoritative DNS queries. Use the DNS management interface for that service.

Do not assume that a domain registered or hosted at HostGator has HostGator-managed DNS. If another service hosts the DNS zone, publishing a record in HostGator will not change the public record receivers query.

2. Create a dedicated aggregate-report destination

Choose a mailbox, group, or reporting service that can receive DMARC aggregate reports. Google recommends including the optional rua tag and using a dedicated destination because report volume can be high.

The report address must start with mailto:. Make sure the responsible team can access it and knows which domain the reports represent. Do not use a personal inbox that could be abandoned during a staffing change.

3. Add the monitoring record without replacing existing DNS records

Create a DNS TXT record for the DMARC host. The following is an illustrative starting shape only. Replace yourdomain.com and the report mailbox with values your organization controls.

Host/name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Do not delete or overwrite an existing DMARC TXT record to add this example. If one already exists, review its policy and reporting tags before making a controlled update.

Google states that v and p are required, that the version value is DMARC1, and that the v and p tags must come first. A DMARC record is published through the domain host, not through Google Admin console.

4. Save the record and query the full DMARC name

After the DNS interface confirms the change, query the full record name. The expected owner is _dmarc.yourdomain.com, even when the DNS interface asks only for _dmarc because it appends the zone automatically.

dig +short TXT _dmarc.yourdomain.com

Compare the returned record with the intended value. Query an authoritative nameserver when possible, then compare it with a public resolver. A resolver result can be delayed by caching, while the authoritative answer shows what the zone currently publishes.

5. Keep the policy at monitoring while reports accumulate

Review the aggregate reports for each known production sender. Look for sources that fail SPF or DKIM, plus sources that pass authentication but do not align with the visible From domain.

Do not move to quarantine or reject because a DNS lookup shows a valid record. A published record proves only the public DNS state. It does not prove that a CRM, website form, relay, or marketing platform is authenticated correctly.

For a broader implementation sequence, see How to set up DMARC.

How to validate the setup

Validate HostGator DMARC setup at four layers. Each layer answers a different question.

• DNS: Query _dmarc.yourdomain.com at the authoritative nameserver and a public resolver. Confirm the intended v=DMARC1 and p=none record appears.
• Sender: Check the current status in every sending service. Confirm SPF and DKIM are enabled for the exact domain and sending path in use.
• Message: Send a new message through each production path and inspect the receiver-added authentication results. A historical message cannot prove the current DNS or sender state.
• DMARC reporting: Review aggregate reports after data accumulates. Confirm legitimate sources pass and align before changing from monitoring to enforcement.

Check the DMARC record

The checker can inspect public DNS. It cannot prove that a particular application sends through the expected path, that every source is represented in reports, or that a receiver will accept or place a future message in the inbox.

If you manage many domains or recurring sender changes, Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy stage based on evidence, while your team reviews the evidence and applies the DNS change.

Start with Palisade

Palisade does not autonomously change your DMARC policy, repair every sender, or guarantee delivery or inbox placement.

Troubleshooting

The DMARC lookup returns no record

First confirm that you published the record in the authoritative DNS zone. Then check the full owner name. A DNS interface that appends the zone can create an incorrect name if you enter the domain twice.

Compare the authoritative response with the public resolver response before treating the issue as propagation. Also confirm that the record type is TXT and that the host is _dmarc, not the root domain.

The record appears in DNS but reports show unknown senders

Unknown sources in DMARC aggregate reports need investigation before enforcement. Identify the source IP address, the visible From domain, the application owner, and whether the source is expected to send for the domain.

Do not add an SPF include, DKIM record, or DMARC exception based on an IP address alone. Confirm the sender with the application owner and its current authentication instructions first.

A sender passes SPF or DKIM but fails DMARC

DMARC requires an aligned SPF or DKIM pass. Compare the visible From domain with the SPF envelope domain and the DKIM d= domain in the delivered message's authentication results.

A valid signature from an unrelated domain can pass DKIM while still failing DMARC alignment. Fix the specific sender configuration rather than weakening the DMARC policy.

cPanel is available but the DNS record is not visible publicly

cPanel's Zone Editor edits the DNS zone records that exist on the server you are logged in to, per cPanel's documentation. Receivers only see those records if the domain's active nameservers point to that server. Check the active nameservers and the authoritative DNS response before editing the record again.