[ DNS & domains ]

Split-horizon DNS: compare internal and public authentication records

Distinguish private DNS views, public authority and caches when an internal authentication lookup succeeds but external mail fails.

By the EmailAuth research team · 8 min read

[ Key points ]

  • Label each DNS observation with its resolver and network vantage point.
  • Separate deliberate view differences from caching and inconsistent publication.
  • Publish only necessary public authentication data, then test the received message.
On this page
  1. Key points
  2. Takeaway
  3. By role
  4. Frequently asked questions
  5. Sources
  6. Glossary
  7. Related guides

[ Takeaway ]

A local success is not a public acceptance test. Compare exact owners across the relevant views and prove the external sending path separately.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Compare the exact message identities

Different lookups can both be correct for their respective DNS views.

Next steps

  1. Record the actual envelope domain and DKIM selector.
  2. Compare private, public recursive and public authoritative answers.
  3. Retain timestamps, TTLs and errors.

CISO / SecOps

Keep private zones private

Correct public authentication without disclosing the internal namespace.

Next steps

  1. Approve only required public records.
  2. Review alias and delegation dependencies.
  3. Keep internal-zone export out of public remediation.

Founder / Non-technical

Resolve the failing customer path

Office tests can miss externally visible delivery failures.

Next steps

  1. Name a business workflow and external acceptance recipient.
  2. Separate temporary cache effects from permanent view differences.
  3. Require accountable sign-off after a fresh message test.

[ FAQs ]

Frequently asked questions

What is split-horizon DNS?

It is a configuration in which DNS answers for a namespace differ according to the query’s source or other view-selection attributes. Internal and external clients may see different zone data.

RFC9499

Why does an office lookup pass while a recipient cannot verify DKIM?

The office may query a private zone containing a key absent from public authority. Compare the exact selector owner from the message across both views before concluding this is the cause.

RFC6376

Does waiting always make internal and public answers match?

No. Deliberate view differences do not expire like cached answers. Establish which authority and view supplied each result before treating a mismatch as a cache issue.

RFC9499

Can I clear a recipient’s cache by flushing my laptop?

No. A local flush does not change authoritative data or another resolver’s cached positive or negative response. Capture the relevant resolver and timing evidence.

RFC2308

Is SERVFAIL the same as a missing TXT record?

No. A server failure is an error outcome, not an authoritative declaration that the record is absent. Preserve response status and investigate the resolution path.

RFC1035

Should I copy the entire private zone to public DNS?

No. The proposed operational plan publishes only approved authentication records needed by the external route. Private services and addresses may intentionally remain private.

RFC9499

Which SPF owner should I compare?

Use the SMTP identity evaluated for the message, normally its envelope sender domain. Comparing a convenient TXT record at the visible From domain may investigate the wrong owner.

RFC7208

Do identical DNS answers guarantee DMARC success?

No. The received message still needs a passing authentication path that aligns with its visible From under the applicable policy settings.

RFC9989

[ Sources ]

Sources

  1. RFC9499

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

  2. Microsoft: Split-brain DNS deployment

    Sections Split-brain DNS deployment · Zone scopes and DNS query resolution policies

  3. RFC1034

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

  4. RFC2308

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

  5. RFC1035

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

  6. RFC7208

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

  7. RFC9989

    Sections Identifier Alignment · DMARC Policy Discovery

  8. RFC6376

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

[ Glossary ]

Glossary

DNS view
A selected set of DNS answers presented according to query attributes or server policy.

RFC9499

Vantage point
The network and resolver context from which a DNS observation is made.

RFC9499

Negative cache
A stored response indicating a name or requested data was absent, retained under negative-caching rules.

RFC2308

Public authority
The authoritative DNS reached through the public delegation chain for an owner name.

RFC1034

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