When Your Registrar Edits Your DMARC: The GoDaddy DMARC Injection Pattern

In mid-2025, customers managing domains on GoDaddy's DNS started noticing something: new DMARC records appearing on their domains, with rua=mailto:dmarc_rua@onsecureserver.net as the reporting address. They hadn't added the records. They hadn't been notified the records were being added. The reporting destination was a domain (onsecureserver.net) that had been registered only weeks earlier, with no public attribution to GoDaddy at the time.

What started as a "GoDaddy is silently pushing DMARC on new domains" story became something more complicated over the following months. The behavior was modified, then defended, then expanded, then partially walked back. And then we found a domain we manage where GoDaddy had added an SPF include and two new CNAME records pointing into their own email infrastructure — also without notification or owner consent. Two of those SPF-aligned messages had been sent from the domain, bypassing its p=reject DMARC policy.

This post is about what happens when DNS providers make security decisions on behalf of their customers without consent, and what to do about it as a domain owner. It's also about the broader question of who controls your email security posture when you don't directly manage your DNS.

What GoDaddy Was Doing

The initial pattern: newly registered domains, or domains migrated to GoDaddy DNS, would have a DMARC record published automatically. The policy started as p=reject, then was modified to p=quarantine later in the year. The reporting destination was dmarc_rua@onsecureserver.net — a domain GoDaddy says they own but that hadn't been publicly attributed at the time we first published our research.

Felix Gorodishter, Senior Principal Architect at GoDaddy, responded directly in our LinkedIn comments to clarify GoDaddy's position:

"The DMARC record is only applied to new domains without MX, SPF, etc. with the aim that no legitimate mail-flow is affected. We've been iterating based on feedback, M3AAWG best practices, and providing the best user experience that reflects our commitment to balancing security with deliverability. Rest assured onsecureserver.net is a legitimate domain created for this and does not involve third parties. At all times the DMARC record is fully editable by domain owners including the RUA field."

That clarification is important and we're treating it as good-faith. GoDaddy's stated logic — that a parked domain with no mail infrastructure benefits from a default-deny DMARC policy to prevent abuse — is defensible on its face. As Barry Jones (formerly at dmarcian) argued in the same thread:

"GoDaddy did the right thing here and every registrar needs to do the same thing. When you setup a web server, you have to point the domain to the host. When you setup to receive email, you have to point to the MX servers. When you setup to send email…you just do it. Because by default everything is turned on for every domain which is the core cause the global phishing and spam problem."

The defense holds up if you accept the premise that registrar-level enforcement is the right place to fix a global problem. The objections start when you look at the specifics.

The Three Objections

Notification. Of the 150+ GoDaddy accounts and thousands of domains we manage on behalf of clients, none received notification of the change at the time it began. Multiple GoDaddy customers in the thread reported the same. As Mario Procopio put it: "Security by default. In principle a good initiative, but can be tricky as you have rightfully highlighted. Hopefully customers were informed in advance and the most mature can still override to choose where to send their rua reporting." They weren't.

The reporting destination. Routing aggregate reports for millions of domains to a single recently-registered third-party domain — even one the registrar says they own — is, at minimum, a striking design choice. DMARC aggregate reports contain source IPs, sending volumes, header-from domains, and authentication metadata. As Eric Donn pointed out, secureserver.net (the parent domain) had been involved in a security breach within the previous year. As of when we wrote our original post, there was no public attribution of onsecureserver.net to GoDaddy, and no published statement about what happens to the reports — whether they're being aggregated into a service, processed, retained, or simply dropped.

The policy flip. GoDaddy moved the default from p=reject to p=quarantine partway through the rollout. That's a substantive policy change on millions of customer domains, executed without coordination with the affected customers. Both of those policies have real consequences for receiver behavior, sender reputation, and how spoofing attempts get handled. Modifying the default after the fact suggests that the original default was set without enough analysis — which is exactly the concern customers had about the change being made on their behalf in the first place.

The compounding issue: a customer who didn't know the DMARC record was added, who didn't know it had been changed from reject to quarantine, and who is operating under the assumption that their domain is unprotected, is now in the worst of both worlds. They have a DMARC policy they didn't author. The policy is publishing data about their mail flow to an address they don't control. And if they ever do add legitimate sending sources without proper authentication, their own mail will be quarantined — by a policy they don't know exists.

The SPF Tampering Case

A separate incident, on a domain we monitor for a high-profile client, raised the stakes. The domain receives minimal legitimate traffic — about 10 emails per month through Google Workspace — and has p=reject enforced due to a high volume of historical spoofing attempts.

In late 2024, URIports flagged an unexpected change to the SPF record. The previous SPF, which contained only include:_spf.google.com, had been modified to:

v=spf1 include:spf.em.secureserver.net include:_spf.google.com ~all

Two new CNAME records pointing to secureserver.net infrastructure had also appeared. Only two people had DNS access — neither had made the changes. We removed the unauthorized records. They reappeared a few days later, and during the window they were live, two SPF-aligned messages were sent from the domain — bypassing DMARC p=reject because the include explicitly authorized GoDaddy's email IPs.

We have no evidence of who specifically initiated the change. GoDaddy doesn't provide DNS change logs at a granularity that would identify the actor. But the pattern — silent record addition, an SPF include authorizing GoDaddy infrastructure, mail being sent through that infrastructure during the window — suggests an automated process tied to GoDaddy's email product upsell. We've never publicly received an explanation for this specific incident.

What This Means for You

The general lesson is that DNS at a registrar that also sells email products creates a conflict of interest. The registrar's commercial incentives — sell more email products, reduce abuse-related operational costs — can lead to operational decisions that override the customer's explicit authentication intentions. As long as the registrar controls the DNS zone, the registrar is in a position to add, modify, or remove the records that govern your domain's security posture.

This is structural, not malicious. But it's a reason to be deliberate about where your DNS lives:

Audit your DNS for unexpected records. Pull a full zone listing. Compare against what you expect to be there. Pay particular attention to TXT records (where DMARC and SPF live), CNAME records (where vendor-managed subdomains route), and MX records.

Monitor for DNS changes. URIports, EasyDMARC, and other monitoring platforms can alert on DMARC and SPF changes. Cloudflare and some other DNS providers offer audit logs that show every change with timestamp and source. If your DNS provider doesn't, that's information.

Consider separating DNS from your registrar. Domain registration and DNS hosting are not the same service. You can register at one provider and host DNS at another. The split reduces the surface for registrar-side DNS changes, though it doesn't eliminate it (the registrar still controls the nameserver records at the registry level).

Verify your DMARC reporting destination. If your DMARC record lists a rua address you didn't configure, you don't actually know where your DMARC reports are going. Replace it with a destination you control or a DMARC monitoring service you actively pay for.

Know the policy you have, not the policy you think you have. Pull the live DMARC record from DNS, not from your last memory of what you configured:

dig TXT _dmarc.example.com

If the record doesn't match what you expect, something between you and DNS has decided to change it.

The Broader Principle

The right thing for the email ecosystem is more domains at p=reject with proper authentication. The wrong thing is registrars making that decision for customers without notification, without explanation, and without giving customers the means to verify what's been configured on their behalf.

Security by default is a defensible design philosophy. Security by silent default — with no notification, no opt-out at signup, no audit trail, and changes to the default mid-stream — is a customer-trust problem dressed up as a security improvement. The customers who lost mail flow when the policy was applied (and there were some, despite GoDaddy's stated intent to apply it only to domains without MX records) didn't get the benefit of the doubt that the change was made carefully.

The fix from GoDaddy's side would be straightforward: notification at signup, an explicit opt-out, an audit log of registrar-initiated DNS changes, public documentation of onsecureserver.net, and stable policy defaults that don't flip without coordination. The fix from the customer side is the one above — know what's in your DNS, monitor for changes, and don't assume the records you put there are the records that are there.

---

Written by the team at SH Consulting. If you want an audit of your DNS to identify records you didn't add, registrar-initiated changes, and authentication that isn't doing what you think it's doing, book a call.