[ DNS & domains ]

DNS-over-HTTPS results and mail-receiver DNS: interpret different observations

Interpret DoH as a DNS transport and resolver choice, not as evidence that an email receiver observed the same answer.

By the EmailAuth research team

[ Key points ]

  • HTTP success can contain a DNS failure.
  • Account for HTTP Age as well as DNS cache lifetime.
  • HTTPS transport does not prove DNSSEC validation or receiver agreement.
On this page

DNS-over-HTTPS carries DNS messages over HTTPS. It protects the transport relationship with the chosen DoH endpoint, but it does not make that endpoint the resolver used by a mail receiver. A browser's current answer and a receiver's authentication lookup can legitimately differ because their resolver paths, caches and policies differ.

Distinguish transport from DNS trust

References: RFC 8484 §8.1, RFC 4033 §3.

RFC 8484 defines application/dns-message exchanges using the DNS wire format. An HTTPS success status does not by itself mean the embedded DNS response contains the requested records. Read the DNS response code, flags and record sets as well as the HTTP status.

TLS to the DoH service authenticates the HTTPS endpoint under its trust model. It is not a substitute for DNSSEC validation of authoritative DNS data. A DoH service may validate, filter or apply other policy; establish its documented behavior instead of inferring it from the HTTPS scheme.

Account for two caching layers

References: RFC 8484 §5.1, RFC 8484 §6.

DoH can involve HTTP caches in addition to DNS caches. RFC 8484 constrains HTTP freshness relative to the DNS data and requires clients to account for the HTTP Age value when calculating remaining DNS lifetime. A diagnostic that ignores these layers can compare responses of different ages as if they were simultaneous fresh lookups.

A provider's JSON DNS API is not automatically the RFC 8484 wire-format interface. Record the endpoint, request method, media type, DNS question and response headers. Do not substitute a web-page status label for the actual DNS message.

Reproduce a captured-response comparison

References: RFC 8484 §4.2.1, RFC 8484 §5.1.

Construct an offline fixture with two valid DNS-response descriptions for the same owner and TXT type. The DoH fixture contains policy P with DNS TTL 300, HTTP Age 120 and compatible HTTP freshness metadata. In the simplified no-other-delay model, no more than 180 seconds of DNS TTL remains. A receiver-resolver fixture obtained after a change contains policy Q.

Expected analysis says the observations differ in resolver and age, not that either transport is inherently wrong. Add a second fixture with HTTP 200 but an embedded DNS SERVFAIL; expected classification is DNS failure, not successful policy retrieval. The original companion model checks these classifications only. The retained historical isolated HTTPS exchange below tested wire decoding separately.

For live reproduction, use an RFC 8484-capable client, record its version and save the raw DNS and HTTP metadata from an authorized endpoint. Compare the same owner and type against the intended mail resolver where accessible and against each authority. Production DoH and receiver-path tests remain pending; the isolated HTTPS experiment below is separate.

Keep privacy claims bounded

References: RFC 8484 §8.2.

The DoH operator receives the query and can observe relevant client connection information. HTTPS does not hide the query from that operator or guarantee that every subsequent DNS exchange is encrypted. Do not move sensitive internal names to an external resolver without an authorized purpose and data-sharing scope.

Use DoH results as one observation. Diagnose differences by name, type, authority state, cache age, validation and policy. Finish authentication investigations with the message and receiver evidence needed for the claim; a green browser-side DNS result is not a mail-delivery guarantee.

Retained historical lab evidence

The retained capture is dated 7 November 2026. The following describes that bounded historical observation, not a new execution or a test of EmailAuth.ai.

A real HTTPS POST carried a DNS wire-format question to an isolated loopback endpoint with a temporary certificate trusted only by that test client. The endpoint returned application/dns-message and the primed forwarder's older p=none response; a separate forwarder returned current p=reject data. A second HTTPS POST returned HTTP 200 with embedded DNS SERVFAIL, which the client decoded correctly. HTTP headers, DNS bytes and times are retained. This endpoint used Cache-Control: no-store; the earlier Age arithmetic remains a separate model, not an observed HTTP-cache experiment. The capture labels are HTTPS_/dns-query; HTTPS_/dns-error; resolver2_fresh_new. The retained runner and raw captures are included in this review package as historical evidence. They were inspected, not rerun for this review. Production DNS, DNSSEC and SMTP outcomes remain untested.

[ Takeaway ]

HTTPS transport does not prove DNSSEC validation or receiver agreement.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Inspect HTTP and DNS together

An HTTP success can carry a DNS error.

Next steps

  1. Retain media type and Age.
  2. Decode the DNS response.
  3. Match questions across paths.

CISO / SecOps

Know who receives queries

DoH changes the transport and potentially the data recipient.

Next steps

  1. Review resolver selection.
  2. Protect internal names.
  3. Separate TLS and DNSSEC assurance.

Founder / Non-technical

Use the relevant observation path

Browser DNS success can coexist with receiver lookup trouble.

Next steps

  1. Identify the failing mail service.
  2. Avoid broad delivery claims.
  3. Require timed comparison evidence.

[ FAQs ]

Frequently asked questions

Does DoH make my browser use the receiver’s resolver?

No. Those are separate systems unless explicitly configured otherwise.

Does HTTP 200 mean the DNS lookup succeeded?

No. Inspect the embedded DNS response code and data.

RFC 8484 §4.2.1

Is DoH the same as DNSSEC?

No. HTTPS transport and DNS data validation protect different properties.

RFC 8484 §8.1

Can HTTP caches affect DoH observations?

Yes. HTTP freshness and Age handling matter alongside DNS caching.

RFC 8484 §5.1

Is every JSON DNS API RFC 8484?

No. Verify the endpoint and media type; the standard uses DNS wire-format messages.

RFC 8484 §6

Can the DoH operator see the query?

Yes. Encryption protects the transport to that endpoint, not against the endpoint itself.

RFC 8484 §8.2

May I send internal names to any public DoH endpoint?

Do not do so without the appropriate authorized purpose and disclosure scope.

Was the fixture a real HTTPS test?

The Age arithmetic is an offline model. The retained 7 November 2026 capture records a separate loopback HTTPS POST and DNS decoding test, not rerun here. Production testing remains unverified.

[ Sources ]

Sources

  1. RFC 4033

    Sections §3

  2. RFC 8484

    Sections §1 · §4.2.1 · §5.1 · §6 · §8.1 · §8.2

[ Glossary ]

Glossary

DoH
DNS queries and responses carried over HTTPS.

RFC 8484 §1

HTTP Age
A response header describing the estimated age of a cached HTTP response.

RFC 8484 §5.1

DNS wire format
The binary message representation used by DNS.

RFC 8484 §6

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