GoDaddy DMARC record: how to add and verify it

Edit it rather than replacing or duplicating it. Since April 2025 GoDaddy publishes a default DMARC record at p=quarantine on domains newly registered or transferred in, and its aggregate reports go to GoDaddy rather than to you. That default is a reasonable starting point, but you cannot see what it is catching, so change the rua address to a mailbox or monitoring service you control. Never add a second record alongside it: receivers that find two policy records discard both, which leaves the domain with no policy at all.

_dmarc on its own. GoDaddy's help describes the Name field as the prefix without the domain name, and @ as the value meaning the root domain. A DMARC record never goes at the root, so @ is wrong here even though it is right for SPF. Typing the fully qualified _dmarc.yourdomain.com is also wrong, because GoDaddy appends the domain and the record lands at _dmarc.yourdomain.com.yourdomain.com, where nothing will ever look for it.

You can, and it is the most reliable way to block your own invoices. p=reject tells receivers to refuse anything that fails authentication, and on a domain that has never published DMARC you do not yet know which legitimate services fail. Start at p=none, read the aggregate reports for a full sending cycle, fix each failing sender, then tighten in stages.

You need at least one of them to pass AND to align with the domain in the visible From header. RFC 9989 defines a DMARC pass as an aligned SPF pass or an aligned DKIM pass, so either alone is enough in principle. In practice publish both: SPF breaks on forwarding while DKIM survives it, so a domain with only one has mail that fails for reasons it cannot control. Senders of close to 5,000 or more messages to personal Gmail accounts in 24 hours are required to have both.

No. Palisade never asks for, stores, or sees a GoDaddy credential. Through MCP, your assistant publishes with the DNS tooling it already has and the keys stay on your side. In the Palisade app, Smart DNS Deployment has you authorise the connection in GoDaddy's own window instead, scoped to email-authentication records and revocable at any time.

Not necessarily, and this is the most common reason a correctly written record does nothing. Registration and DNS hosting are separate, and a GoDaddy domain whose nameservers point at another host is edited at that host. Palisade resolves the domain's live nameservers and reports the host that actually answers, so your assistant is aimed at the right dashboard before anything is typed.

It changes who generates the SPF and DKIM values, not where DMARC goes. The DMARC record is still one TXT record at _dmarc in the authoritative zone. Microsoft 365 domains take their DKIM records from Microsoft, and GoDaddy publishes them, which is the same split every sending platform follows.

Palisade reports no provider rather than the wrong one. Detection reads the domain's live NS records and only names a host when every nameserver belongs to it, so a zone half-delegated to GoDaddy and half somewhere else comes back with the provider unresolved. Your assistant is told to check the nameserver list and ask you, instead of picking a DNS tool that would write into the zone that is on its way out.

Not on its own, and Palisade flags the case where it might. Records come back with an action of create, replace or delete, an already_published flag so nothing live is rewritten with the value it already holds, and a warnings array that is normally empty. A warning means applying the set as-is could affect mail for the domain, and it is meant to be read and confirmed rather than applied silently.