MTA-STS and TLS-RPT Lookup API: Audit Email Transport Security in JSON

Introduction

Email authentication usually starts with SPF, DKIM, and DMARC. Transport security is the next layer: does the domain publish a policy that tells senders to use TLS for mail delivery, and does it publish a reporting address for TLS failures?

MTA-STS and TLS-RPT answer those questions. WhoisJSON returns both records through the documented DNS Lookup API /nslookup endpoint. Query the root domain, then read the MTASTS and TLSRPT arrays alongside MX, TXT and DMARC.

What Are MTA-STS and TLS-RPT?

MTA-STS is a domain policy mechanism for SMTP transport security. It lets a receiving domain advertise that mail servers should deliver messages over TLS and validate the certificate presented by the MX host.

TLS-RPT is the reporting companion. It publishes where aggregate reports about SMTP TLS delivery failures should be sent, so operators can see policy failures, certificate problems, and mail delivery paths that do not satisfy the expected TLS posture.

Lookup API vs Policy Validation

Keep the workflow honest: DNS lookup and complete MTA-STS validation are related, but not identical.

Query MTA-STS and TLS-RPT in JSON

Authenticate with the Authorization: TOKEN=YOUR_API_KEY header and pass the root domain as the domain query parameter.

curl "https://whoisjson.com/api/v1/nslookup?domain=example.com" \
  -H "Authorization: TOKEN=YOUR_API_KEY"

The response can include email routing, authentication, and transport security records in one JSON payload.

{
  "MX": [
    { "exchange": "mail.example.com", "priority": 10 }
  ],
  "DMARC": [
    "v=DMARC1; p=reject; rua=mailto:[email protected]"
  ],
  "MTASTS": [
    "v=STSv1; id=20260618000000Z"
  ],
  "TLSRPT": [
    "v=TLSRPTv1; rua=mailto:[email protected]"
  ]
}

How to Interpret Results

Start with whether the domain receives mail, then evaluate the transport security records as supporting controls.

For authentication policy, use the DMARC lookup API guide. For sender authorization, use the SPF record lookup API guide. For inbound routing, use the MX record lookup API guide.

Python Example: Audit Transport Security Records

This example extracts MX, MTA-STS, and TLS-RPT from the documented DNS response and returns a narrow audit verdict.

import requests

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://whoisjson.com/api/v1"
HEADERS = {"Authorization": f"TOKEN={API_KEY}"}


def audit_transport_security(domain: str) -> dict:
    response = requests.get(
        f"{BASE_URL}/nslookup",
        headers=HEADERS,
        params={"domain": domain},
        timeout=10,
    )
    response.raise_for_status()
    data = response.json()

    mx_records = data.get("MX") or []
    mta_sts_records = data.get("MTASTS") or []
    tls_rpt_records = data.get("TLSRPT") or []

    findings = []
    if mx_records and not mta_sts_records:
        findings.append("MX exists but no MTA-STS DNS record was found")
    if mx_records and not tls_rpt_records:
        findings.append("MX exists but no TLS-RPT DNS record was found")

    return {
        "domain": domain,
        "hasMx": bool(mx_records),
        "hasMtaSts": bool(mta_sts_records),
        "hasTlsRpt": bool(tls_rpt_records),
        "mx": mx_records,
        "mtaSts": mta_sts_records,
        "tlsRpt": tls_rpt_records,
        "findings": findings,
    }


print(audit_transport_security("example.com"))

Node.js Example: Batch Check Vendors

In vendor reviews, keep the result per domain so one failure does not hide the rest of the audit.

const API_KEY = "YOUR_API_KEY";
const BASE_URL = "https://whoisjson.com/api/v1";

async function lookupDns(domain) {
  const url = new URL(`${BASE_URL}/nslookup`);
  url.searchParams.set("domain", domain);

  const response = await fetch(url, {
    headers: { Authorization: `TOKEN=${API_KEY}` },
  });
  if (!response.ok) {
    throw new Error(`DNS lookup failed for ${domain}: ${response.status}`);
  }
  return response.json();
}

async function auditDomain(domain) {
  const dns = await lookupDns(domain);
  const mx = dns.MX ?? [];
  const mtaSts = dns.MTASTS ?? [];
  const tlsRpt = dns.TLSRPT ?? [];

  return {
    domain,
    hasMx: mx.length > 0,
    hasMtaSts: mtaSts.length > 0,
    hasTlsRpt: tlsRpt.length > 0,
    status:
      mx.length === 0 ? "no-inbound-mail" :
      mtaSts.length && tlsRpt.length ? "transport-records-present" :
      "review",
    mtaSts,
    tlsRpt,
  };
}

Promise.allSettled([
  "example.com",
  "vendor.example",
  "customer.example",
].map(auditDomain)).then(console.log);

Common Use Cases

• Vendor domain security reviews: check whether mail-receiving vendor domains publish transport security records before onboarding or renewal.
• Customer-domain onboarding: surface missing MTA-STS or TLS-RPT as optional hardening guidance after MX and DMARC checks pass.
• Portfolio monitoring: store previous MTASTS and TLSRPT arrays and alert when records disappear or IDs change unexpectedly.
• Compliance evidence: export DNS snapshots that show MX, DMARC, MTA-STS, and TLS-RPT posture at review time.

Where This Fits in the Email Security Cluster

MTA-STS and TLS-RPT are not replacements for SPF, DKIM, or DMARC. They cover the transport path between mail systems, while authentication records cover whether a message is authorized and aligned with the sender domain.

What This Lookup Cannot Prove

FAQ

Conclusion

MTA-STS and TLS-RPT lookup gives your application a practical transport-security layer for email audits. Query /nslookup once, read MX, MTASTS, and TLSRPT, and store the resulting DNS snapshot for onboarding, vendor reviews, or continuous monitoring.

Keep the boundary clear: WhoisJSON returns the DNS records. Complete MTA-STS validation, HTTPS policy-file checks, SMTP STARTTLS testing, and report mailbox validation remain separate checks that you can layer on top.