[ DNS & domains ]

DNS hosting and email hosting: find the correct control panel

Identify who publishes DNS, hosts mailboxes and signs outbound mail so authentication changes reach the active control panel.

By the EmailAuth research team · 8 min read

[ Key points ]

  • Registration, DNS hosting, mailbox service and outbound sending can have different owners.
  • Follow public authority for the exact record name before editing.
  • Pair DNS publication with the sending service’s configuration and a received-message test.
On this page

[ Takeaway ]

Find the active DNS authority and the actual sender configuration separately. A successful save in the wrong panel changes neither public DNS nor message authentication.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Map the active control panels

Provider brands do not establish authority for a particular record.

Next steps

  1. Locate the exact zone and any delegation.
  2. Obtain provider-issued values from the sender owner.
  3. Verify authoritative answers and final message identities.

CISO / SecOps

Separate access from evidence

The service map should identify responsible owners without collecting credentials.

Next steps

  1. Keep secrets out of tickets and worksheets.
  2. Review namespace scope before any nameserver change.
  3. Preserve existing SPF and approved DMARC policy.

Founder / Non-technical

Avoid accidental infrastructure migration

A one-record fix should not silently move the whole domain.

Next steps

  1. Assign DNS and email owners explicitly.
  2. Preserve business-critical sending and receiving services.
  3. Require a reversible approved change and end-to-end acceptance.

[ FAQs ]

Frequently asked questions

Is my registrar necessarily my DNS host?

No. Registration and authoritative DNS can be supplied separately. Follow the public delegation and confirm the account owner instead of relying on the registration invoice.

RFC9499

Do MX records identify every service that sends my mail?

No. MX supports incoming delivery to the domain. Outbound applications and submission services can be different systems and need a separate inventory.

RFC5321

Where should I publish a DKIM public key?

At the active authority for the selector owner, following the sender’s supported TXT or delegation instructions. The signing service still needs the corresponding private-key configuration.

RFC6376

Why did saving a record in my registrar panel change nothing?

That panel may host an unused zone, or the record may have been saved at the wrong owner. Compare the public delegation and exact authoritative answer before diagnosing the cause.

RFC1034

Should I change nameservers just to activate that panel?

Not as an incidental fix. A nameserver move changes authority and needs a separate migration plan covering all records, dependencies, DNSSEC and recovery.

RFC1034

Will changing MX fix an application’s SMTP login error?

Not as a general remedy. Submission authorization and incoming destination routing are different functions; investigate the actual failing stage first.

RFC6409

Can I add a second SPF TXT record for another provider?

Do not publish a second SPF policy at the same owner. Update the single valid policy after preserving authorized senders and checking its evaluation limits.

RFC7208

Does a provider verification badge prove DMARC passes?

No. It can establish a configuration checkpoint, but the actual message still needs aligned passing authentication at the receiver.

RFC9989

[ Sources ]

Sources

  1. RFC6409

    Sections §1. Introduction · §3. Message Submission

  2. RFC5321

    Sections §5.1 Locating the Target Host

  3. RFC9499

    Sections §6. DNS servers and clients · §7. Zones

  4. RFC1034

    Sections §4.2.1 Technical considerations · §4.2.2 Administrative considerations · §4.3.2 Algorithm

  5. RFC2308

    Sections §2. Negative Responses · §5. Caching Negative Answers

  6. RFC1035

    Sections §3.3.11 NS RDATA format · §3.3.13 SOA RDATA format · §4.1 Message format

  7. RFC7208

    Sections §4. SPF Evaluation · §4.5 Selecting Records · §4.6.4 DNS Lookup Limits

  8. RFC9989

    Sections Identifier Alignment · DMARC Policy Discovery

  9. RFC6376

    Sections §3.5 DKIM-Signature Header Field · §3.6 Key Management and Representation · §6. Verifier Actions

[ Glossary ]

Glossary

Authoritative DNS host
The service publishing authoritative zone data used for the relevant DNS name.

RFC9499

MX record
A DNS record naming a mail exchanger for delivery to a domain.

RFC1035

Submission service
The service accepting a user or application’s outgoing message for subsequent delivery.

RFC6409

DKIM signer
The service applying a signature with a private key whose public counterpart is discoverable through DNS.

RFC6376

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base