DEV Community: Jose Pollman

Checking a sending IP's reverse DNS and HELO in stdlib Python, before Spamhaus's November requirement

Jose Pollman — Tue, 03 Nov 2026 08:45:09 +0000

Spamhaus's Sender Guidelines now open with a dated note: "Starting in November 2026, we are gradually rolling out a requirement for every sending IP to have a valid HELO, a reverse DNS (PTR) record, and a matching A record." The page lists that as a minimum requirement, and says a missing or mismatched reverse DNS "is one of the most common reasons for an IP to be considered for listing".

None of this is new as a practice. What is new is a dated rollout from Spamhaus. If you send mail from a VPS, a home lab, or a small app on your own IP, it is worth checking your sending address today. The check fits in the Python standard library over DNS-over-HTTPS, so I wrote one and ran it on 3 November 2026. The script is below in eight blocks; pasted in order into one file, it runs.

What the three checks are

Spamhaus spells out each one.

Reverse DNS. "Every sending IP must have a reverse DNS entry pointing to a fully qualified domain name (FQDN)."
Forward confirmation. "That hostname must, in turn, resolve back to the same sending IP address. This is known as forward-confirmed reverse DNS (FCrDNS)."
HELO. "The hostname the server announces in the HELO/EHLO command must resolve to the IP it is connecting from, and must stay consistent across connections from that IP."

The FCrDNS part has a precise statement in an RFC. RFC 8601 section 3 calls it "iprev" and gives it as an algorithm: if the client's address is I, the PTR names for I are the set N, and the union of the A and AAAA answers for every member of N is L, "then this test is successful if I is an element of L". It also says the number of names you look up "MUST" be limited, and points at SPF's limit of 10 as an example. The same section is frank that "there is some contention regarding the wisdom and reliability of this test". It also points to a DNSOP document that recommends applications avoid using the test "as a means of authentication or security".

The HELO part has an older rule pulling the other way. RFC 5321 section 4.1.4 says a receiving server "MAY verify" that the EHLO name matches the client's address, but "MUST NOT refuse to accept a message on that basis". That rule binds a server inside an SMTP session. A blocklist deciding which addresses to list is a different decision, made elsewhere, and Spamhaus's page is about that decision.

Asking DNS without dig

There is no dig on the machine I used, so every lookup goes to Google Public DNS's JSON API. One helper is enough. Record types are passed as numbers, because the API returns numeric types in its answers and comparing against strings silently matches nothing.

# fcrdns_check.py - forward-confirmed reverse DNS and HELO checks, stdlib only.
# Usage: python3 fcrdns_check.py IP [HELO]   or   python3 fcrdns_check.py --eml FILE
import ipaddress, json, re, sys, urllib.parse, urllib.request
from email import message_from_binary_file, policy

# --- block 1: one DNS question over DNS-over-HTTPS
A, CNAME, PTR, AAAA = 1, 5, 12, 28

def doh(name, rrtype):
    q = urllib.parse.urlencode({"name": name, "type": rrtype})
    with urllib.request.urlopen(f"https://dns.google/resolve?{q}", timeout=10) as r:
        reply = json.load(r)
    return reply["Status"], reply.get("Answer", [])

The PTR side

The reverse name for an address is the address written backwards under in-addr.arpa for IPv4, or nibble by nibble under ip6.arpa for IPv6 (RFC 3596 section 2.5). Python's ipaddress module already builds it, so there is no string reversing to get wrong:

# --- block 2: the PTR side
def ptr_names(ip):
    rname = ipaddress.ip_address(ip).reverse_pointer
    status, answers = doh(rname, PTR)
    names = [a["data"].rstrip(".").lower() for a in answers if a["type"] == PTR]
    return rname, status, names

For 2a01:111:f403:c206::1 that property gives a 32-nibble name ending in ip6.arpa, which is tedious to build by hand.

The forward side, compared as addresses

For each PTR name, look up A and AAAA and keep the results as ipaddress objects rather than strings. The reason is IPv6: the same address has many spellings.

>>> "2001:db8::1" == "2001:0db8:0:0::1"
False
>>> ipaddress.ip_address("2001:db8::1") == ipaddress.ip_address("2001:0db8:0:0::1")
True

A string comparison would fail a correctly configured IPv6 sender. The helper also notes when the answer came through a CNAME. RFC 1912 section 2.1 says "PTR records must point back to a valid A record, not a alias defined by a CNAME". A resolver follows the CNAME for you, so the match can still succeed, but it is worth printing.

# --- block 3: the forward side, as address objects
def forward(name):
    addrs, via_cname = set(), False
    for rrtype in (A, AAAA):
        _, answers = doh(name, rrtype)
        for a in answers:
            if a["type"] == CNAME:
                via_cname = True
            elif a["type"] == rrtype:
                addrs.add(ipaddress.ip_address(a["data"]))
    return addrs, via_cname

iprev, as the RFC states it

With both halves in place, the test is a few lines, and the limit of 10 names comes straight from RFC 8601's pointer to SPF:

# --- block 4: iprev as RFC 8601 section 3 states it
def fcrdns(ip, limit=10):
    client = ipaddress.ip_address(ip)
    rname, status, names = ptr_names(ip)
    result = {"ip": ip, "ptr_query": rname, "ptr_status": status,
              "ptr": names, "checked": [], "pass": False}
    for name in names[:limit]:
        addrs, via_cname = forward(name)
        result["checked"].append((name, sorted(map(str, addrs)), via_cname))
        if client in addrs:
            result["pass"] = True
    return result

A PTR answer with several names passes if any one of them leads back to the address. Every name past the tenth is ignored.

The HELO name

The HELO check is the same forward lookup, run on the name the client announced. RFC 5321's grammar allows EHLO with an address literal such as [192.0.2.1] when the client has no meaningful name, but then there is no name to resolve, so the function says so instead of guessing.

# --- block 5: the HELO name
def helo_check(helo, ip):
    helo = helo.rstrip(".").lower()
    if helo.startswith("["):
        return {"helo": helo, "fqdn": False, "resolves_to_ip": False,
                "note": "address literal, no name to check"}
    addrs, _ = forward(helo)
    return {"helo": helo, "fqdn": "." in helo,
            "resolves_to_ip": ipaddress.ip_address(ip) in addrs,
            "forward": sorted(map(str, addrs))}

Spamhaus also asks senders to avoid "generic or auto-generated rDNS entries for dedicated IPs", and gives examples like static-203-0-113-25.hosting.example.net. There is no exact test for "generic", but a name that spells out the address forwards or backwards is the usual shape, so the script flags it as a note rather than a failure:

# --- block 5b: does the PTR name just spell out the address?
def looks_generic(name, ip):
    ip = ipaddress.ip_address(ip)
    if ip.version == 4:
        o = str(ip).split(".")
        patterns = ["[.-]".join(o), "[.-]".join(reversed(o))]
    else:
        patterns = [ip.exploded.replace(":", "")[-8:]]
    flat = name.replace("-", ".")
    return any(re.search(p, flat) for p in patterns)

I tried it on Spamhaus's three example names with 203.0.113.25 as the address. It flags static-203-0-113-25.hosting.example.net. It misses 203.113.0.25.broadband.example.net, whose octets are in neither order, and vps-25.dedicated.hosting.example.com, which carries only the last octet. It does not flag a branded name such as o3.email2.mlh.io. Treat it as a hint that catches the common shape, nothing more.

Getting the IP and HELO from a message you received

To check a sender, you need the address and the HELO name it actually used. Both are in the Received field that the receiving server added. In RFC 5321 section 4.4 the from clause carries the name the client gave in EHLO, followed by a parenthesised part that the grammar labels "Information derived by server from TCP connection not client EHLO". So in

Received: from o3.email2.mlh.io (o3.email2.mlh.io. [168.245.48.148])

the first o3.email2.mlh.io is what the client said, and the part in parentheses is what the receiving server saw: the reverse name it looked up and the connecting address.

# --- block 6: HELO and IP from the Received field your own MX added
RECEIVED = re.compile(r"from\s+(\S+)\s+\((\S*?)\.?\s*\[(?:IPv6:)?([0-9a-fA-F.:]+)\]\)")

def first_hop(path):
    with open(path, "rb") as f:
        msg = message_from_binary_file(f, policy=policy.default)
    for field in msg.get_all("Received", []):
        m = RECEIVED.search(" ".join(str(field).split()))
        if m:
            helo, rdns, ip = m.groups()
            return helo, rdns, ip
    raise SystemExit("no Received field with a from (... [ip]) clause")

The loop skips fields without a from (... [address]) clause, such as a mailbox provider's internal hops. The pattern matches the common from helo (rdns [ip]) layout. Other servers format the field differently, so adjust it for yours, and only trust the field your own receiving server added. Everything below it was written by the sender.

Running it

The last block prints a report:

# --- block 7: run it
def report(ip, helo=None):
    r = fcrdns(ip)
    print(f"{ip}")
    print(f"  PTR {r['ptr_query']} -> status {r['ptr_status']} {r['ptr'] or '(none)'}")
    for name, addrs, via_cname in r["checked"]:
        hop = " (via CNAME)" if via_cname else ""
        print(f"  {name} -> {addrs or '(no A/AAAA)'}{hop}")
    print(f"  FCrDNS: {'pass' if r['pass'] else 'FAIL'}")
    for name in r["ptr"]:
        if looks_generic(name, ip):
            print(f"  note: {name} spells out the address (generic rDNS?)")
    if helo:
        h = helo_check(helo, ip)
        print(f"  HELO {h['helo']}: fqdn={h['fqdn']} resolves_to_ip={h['resolves_to_ip']}"
              f" same_as_ptr={h['helo'] in r['ptr']}")

if __name__ == "__main__":
    if sys.argv[1] == "--eml":
        helo, rdns, ip = first_hop(sys.argv[2])
        print(f"Received: HELO={helo} rDNS-at-receiver={rdns} IP={ip}")
        report(ip, helo)
    else:
        report(sys.argv[1], sys.argv[2] if len(sys.argv) > 2 else None)

I ran it at 08:41 UTC on 3 November 2026 on three inputs. The first is the headers of a DEV newsletter that arrived on 1 November, with my address replaced by me@example.com. The second is 192.0.2.1, from a block that RFC 5737 sets aside for documentation, so it should have no PTR. The third is the same sending address with localhost as a pretend HELO, the placeholder value Spamhaus names as a "Don't".

2026-11-03 08:41 UTC
$ python3 fcrdns_check.py --eml fcrdns_sample.eml
Received: HELO=o3.email2.mlh.io rDNS-at-receiver=o3.email2.mlh.io IP=168.245.48.148
168.245.48.148
  PTR 148.48.245.168.in-addr.arpa -> status 0 ['o3.email2.mlh.io']
  o3.email2.mlh.io -> ['168.245.48.148']
  FCrDNS: pass
  HELO o3.email2.mlh.io: fqdn=True resolves_to_ip=True same_as_ptr=True
$ python3 fcrdns_check.py 192.0.2.1
192.0.2.1
  PTR 1.2.0.192.in-addr.arpa -> status 3 (none)
  FCrDNS: FAIL
$ python3 fcrdns_check.py 168.245.48.148 localhost
168.245.48.148
  PTR 148.48.245.168.in-addr.arpa -> status 0 ['o3.email2.mlh.io']
  o3.email2.mlh.io -> ['168.245.48.148']
  FCrDNS: pass
  HELO localhost: fqdn=False resolves_to_ip=False same_as_ptr=False

The newsletter's sending address passes all three checks: one PTR name, that name resolves back to the same address, and the HELO name matches both. The rDNS name sits under a different domain from the From: address, which FCrDNS does not care about. Status 3 is NXDOMAIN, so the documentation address fails at the first step, as expected. localhost fails the HELO check on both counts.

What you can fix, and what you can't

PTR records live in the reverse zone of whoever holds the address block, not in your domain's zone. On a VPS that usually means the hosting provider's control panel or a support ticket. On a dedicated IP at an email service provider it is the provider's setting, sometimes with your own branded name. On shared, hosted mail it is entirely the provider's job, and you cannot fix it from your side even when the check fails.

I saw that case on the morning I ran the script: four IPv4 addresses inside one large hosted mail provider's published SPF range returned NXDOMAIN for PTR, while the address next to one of them resolved and passed. DNS alone cannot tell you whether those addresses send mail at all. If yours is one of them, the useful step is a support ticket to the provider, not a change to your own records.

If you run the mail server yourself, the HELO name is the one setting entirely in your hands. In Postfix it is smtp_helo_name, which defaults to $myhostname. Set it to the name your PTR record points at, and make sure that name has an A (and, if you send over IPv6, AAAA) record for the sending address.

What this check does not do

It asks one recursive resolver. A stale cache or a split-horizon setup can give a different answer from what a receiver sees. Asking a second resolver, or the authoritative servers, is a cheap extra step.
It checks a single connection. Spamhaus also wants the HELO to "stay consistent across connections", and that needs your server's logs over time, not one lookup.
It does not check the IPv6 allocation size. Spamhaus asks for at least a /64 for IPv6 senders, and DNS cannot tell you that.
Spamhaus has its own checker on the same page, and says you can also send a message to helocheck@abuseat.org to see the HELO your server uses. Those report what Spamhaus sees, which is the view that matters for a listing.

If the three lines for your sending address say pass, fqdn=True and resolves_to_ip=True, the address meets the November requirement as far as public DNS can show.

Written with AI assistance from my own notes and test results. I checked every fact and command before publishing.

Checking CDS and CDNSKEY on every nameserver before a DS update, in stdlib Python

Jose Pollman — Thu, 29 Oct 2026 08:50:32 +0000

RFC 10026 came out in July 2026 as BCP 246, "Operational Recommendations for DNSSEC Delegation Signer (DS) Automation". Its first recommendation, in section 4.1, says that whoever automates DS maintenance "MUST verify" two things before touching the parent zone: that the request is consistent "between any published CDS and CDNSKEY records" and "across all authoritative nameservers in the delegation", and "that the resulting DS record set would allow continued DNSSEC validation if deployed". If either check fails, cancel.

All of it fits in the Python standard library: raw DNS over UDP, a SHA-256 digest, and ECDSA and RSA signature checks done by hand. I wrote the check and ran it on 29 October 2026 against four zones that publish CDS records. The whole script is below in seven blocks. Paste them in order into one file and run it with a zone name, or with --simulate and a zone name.

What the RFCs actually ask for

Four documents set the rules.

RFC 7344 section 4.1 has the original acceptance rules. CDS and CDNSKEY records must sit at the child zone apex, must be signed "with a key that is represented in both the current DNSKEY and DS RRsets", and must not break the current delegation. No CDS and no CDNSKEY at all means "no change".

RFC 9975 (May 2026) defines consistency. The parent has to take the NS hostnames from its own delegation, look up "all IP addresses for each nameserver hostname" with a validating resolver, including glue, and query every one of those addresses. Each key referenced in one answer must be referenced in all the others, CDS must agree with CDNSKEY, and a delete request on one server next to a key on another is inconsistent. A NODATA answer counts as a received response. Only CDS records whose digest type is "MUST" in the "Implement for DNSSEC Delegation" column of the IANA digest registry are compared, and today that is only type 2, SHA-256. On any inconsistency the parent "MUST abort the operation".

RFC 10026 section 4.2.1 defines "would allow continued validation": the child's DNSKEY RRset must carry "a valid RRSIG signature from a key that is referenced by at least one DS record" in the new set.

RFC 8078 section 4 adds the delete signal. A CDS of 0 0 0 0 or a CDNSKEY of 0 3 0 0, each the only record in its set, asks the parent to remove the whole DS RRset.

Step 1: talk to each server directly

A recursive resolver can't do this job. It gives you one cached answer from whichever nameserver it last asked, so two servers that disagree look like one server that agrees with itself. This block builds a query with the DO bit set, sends it over UDP, retries over TCP if the answer comes back truncated, and parses the three answer sections. The largest answer this morning was 313 bytes, but a zone with several RSA keys mid-rollover can pass 1,232, which is what the TCP path is for.

# --- block 1: one DNS query over UDP, TCP if truncated
import base64, hashlib, json, random, socket, struct, sys, time, urllib.request

CDS, CDNSKEY, DNSKEY, DS, RRSIG, NS, A, AAAA = 59, 60, 48, 43, 46, 2, 1, 28

def wire_name(name):
    out = b""
    for label in name.rstrip(".").lower().split("."):
        out += bytes([len(label)]) + label.encode()
    return out + b"\x00"

def read_name(msg, i):
    labels, jumped, end = [], False, i
    while True:
        n = msg[i]
        if n == 0:
            i += 1
            break
        if n & 0xC0 == 0xC0:  # compression pointer
            if not jumped:
                end = i + 2
            i, jumped = struct.unpack("!H", msg[i:i + 2])[0] & 0x3FFF, True
            continue
        labels.append(msg[i + 1:i + 1 + n].decode().lower())
        i += 1 + n
    return ".".join(labels) + ".", (end if jumped else i)

def query(server, name, rrtype, timeout=4):
    qid = random.randrange(65536)
    msg = (struct.pack("!HHHHHH", qid, 0, 1, 0, 0, 1) + wire_name(name)
           + struct.pack("!HH", rrtype, 1)
           + b"\x00" + struct.pack("!HHIH", 41, 1232, 0x8000, 0))  # EDNS0, DO bit set
    with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as s:
        s.settimeout(timeout)
        s.sendto(msg, (server, 53))
        resp = s.recv(65535)
    if struct.unpack("!H", resp[2:4])[0] & 0x0200:  # TC bit: retry over TCP
        with socket.create_connection((server, 53), timeout=timeout) as s:
            s.sendall(struct.pack("!H", len(msg)) + msg)
            size = struct.unpack("!H", s.recv(2))[0]
            resp = b""
            while len(resp) < size:
                resp += s.recv(size - len(resp))
    return parse(resp)

def parse(msg):
    flags, qd, an, ns, ar = struct.unpack("!5H", msg[2:12])
    i = 12
    for _ in range(qd):
        _, i = read_name(msg, i)
        i += 4
    sections = []
    for count in (an, ns, ar):
        rrs = []
        for _ in range(count):
            owner, i = read_name(msg, i)
            rtype, _, ttl, rdlen = struct.unpack("!HHIH", msg[i:i + 10])
            i += 10
            rrs.append((owner, rtype, ttl, msg[i:i + rdlen], i))
            i += rdlen
        sections.append(rrs)
    return {"aa": bool(flags & 0x0400), "rcode": flags & 0xF, "msg": msg,
            "answer": sections[0], "authority": sections[1], "additional": sections[2]}

Step 2: the delegation as the parent sees it

The NS list has to come from the parent, not from the child. A child zone can list whatever it likes in its own NS records, but the parent's referral is what sends resolvers to the child's servers in the first place. The script asks one of the parent's servers for the child's NS and reads the referral from the authority section, along with any glue. Then it looks up A and AAAA for each hostname through Google Public DNS, which validates. It also asks the same parent server for the current DS set, which it needs later.

# --- block 2: the delegation, as the parent publishes it
def doh(name, rrtype):
    url = f"https://dns.google/resolve?name={name}&type={rrtype}"
    with urllib.request.urlopen(url, timeout=10) as r:
        j = json.load(r)
    return [a["data"] for a in j.get("Answer", []) if a["type"] == rrtype], j.get("AD")

def delegation(zone):
    parent = zone.split(".", 1)[1] or "."
    parent_ns, _ = doh(parent, NS)
    parent_ip = doh(sorted(parent_ns)[0], A)[0][0]
    ref = query(parent_ip, zone, NS)
    hosts = sorted({read_name(ref["msg"], off)[0] for o, t, _, rd, off in ref["authority"] if t == NS})
    glue = {(o, socket.inet_ntop(socket.AF_INET if t == A else socket.AF_INET6, rd))
            for o, t, _, rd, _ in ref["additional"] if t in (A, AAAA)}
    ips = {}
    for host in hosts:
        found = set(doh(host, A)[0] + doh(host, AAAA)[0]) | {ip for o, ip in glue if o == host}
        ips[host] = sorted((ip, 6 if ":" in ip else 4) for ip in found)
    ds = sorted(rd for o, t, _, rd, _ in query(parent_ip, zone, DS)["answer"] if t == DS)
    return parent_ip, hosts, ips, ds

Step 3: ask every address for CDS, CDNSKEY and DNSKEY

For each address the script asks for all three types and insists on the AA bit, so the answer comes from an authoritative server and not a forwarder. A server that times out or answers without AA is recorded, not dropped. RFC 9975 asks for consistency across responses you actually received, and says the parent should retry the silent ones later before giving up on them.

# --- block 3: ask every address for CDS, CDNSKEY and DNSKEY
def rrset(resp, owner, rrtype):
    rdatas = sorted(rd for o, t, _, rd, _ in resp["answer"] if o == owner and t == rrtype)
    sigs = [rd for o, t, _, rd, _ in resp["answer"]
            if o == owner and t == RRSIG and struct.unpack("!H", rd[:2])[0] == rrtype]
    return rdatas, sigs

def collect(zone, ips):
    owner = zone.rstrip(".").lower() + "."
    seen = {}
    for host, addrs in ips.items():
        for ip, family in addrs:
            if family == 6:
                seen[(host, ip)] = "skipped: no IPv6 route from this machine"
                continue
            try:
                answers = {}
                for rrtype in (CDS, CDNSKEY, DNSKEY):
                    resp = query(ip, zone, rrtype)
                    if not resp["aa"] or resp["rcode"]:
                        raise ValueError(f"aa={resp['aa']} rcode={resp['rcode']}")
                    answers[rrtype] = rrset(resp, owner, rrtype)
                seen[(host, ip)] = answers
            except (OSError, ValueError) as e:
                seen[(host, ip)] = f"no usable response: {e}"
    return seen

Step 4: turn each answer into a request

A CDNSKEY record holds the key itself. A CDS record holds what the DS record will be. To compare them, the script computes the DS digest from each CDNSKEY the way RFC 4034 section 5.1.4 defines it: SHA-256 over the owner name in wire format followed by the DNSKEY RDATA. The owner name in that hash matters, and it comes back in the results below.

Each server's answer becomes one of four things: no request, a delete request, an inconsistency, or a set of DS records. CDS records with digest types other than 2 are left out of the comparison, as RFC 9975 allows.

# --- block 4: what each server is asking the parent to publish
def key_tag(rdata):  # RFC 4034 Appendix B
    ac = sum(b if i & 1 else b << 8 for i, b in enumerate(rdata))
    return (ac + ((ac >> 16) & 0xFFFF)) & 0xFFFF

def ds_from_dnskey(zone, rdata):  # RFC 4034 5.1.4, digest type 2 (SHA-256)
    digest = hashlib.sha256(wire_name(zone) + rdata).digest()
    return struct.pack("!HBB", key_tag(rdata), rdata[3], 2) + digest

# RFC 8078 section 4: "CDS 0 0 0 0" and "CDNSKEY 0 3 0 0", each with a single zero byte of payload
DELETE_CDS, DELETE_CDNSKEY = bytes.fromhex("0000000000"), bytes.fromhex("0000030000")

def request(zone, answers):
    cds = sorted(rd for rd in answers[CDS][0] if rd[3] == 2)  # only SHA-256 is compared (RFC 9975 3.1)
    cdnskey = answers[CDNSKEY][0]
    if not answers[CDS][0] and not cdnskey:
        return "no request (NODATA)"
    if DELETE_CDS in cds or DELETE_CDNSKEY in cdnskey:
        if set(cds) <= {DELETE_CDS} and set(cdnskey) <= {DELETE_CDNSKEY}:
            return "delete DS"
        return "inconsistent: delete signal mixed with keys"
    from_cdnskey = sorted(ds_from_dnskey(zone, rd) for rd in cdnskey)
    if cds and cdnskey and from_cdnskey != cds:
        return "inconsistent: CDS and CDNSKEY name different keys"
    return (tuple(cds), tuple(from_cdnskey))

def show_ds(rd):
    tag, alg, dtype = struct.unpack("!HBB", rd[:4])
    return f"{tag} {alg} {dtype} {rd[4:].hex().upper()[:16]}..."

Step 5: signatures, and whether the new set would validate

Every zone in this test signs with algorithm 13, ECDSA P-256 with SHA-256, which takes a few dozen lines of modular arithmetic. RSA/SHA-256 (algorithm 8) is a single pow() and a padding comparison. Anything else raises an error instead of quietly passing.

signed_by rebuilds the data the signer signed (RFC 4034 section 3.1.8.1): the RRSIG fields without the signature, then each record of the set in canonical order with the original TTL from the RRSIG. It also checks the inception and expiration times. keeps_validating is the RFC 10026 test: of the keys the new DS set points at, which ones produced a valid signature over the DNSKEY RRset? An empty answer means the update would break the zone.

# --- block 5: would the new DS set keep validation working?
P256 = dict(p=2**256 - 2**224 + 2**192 + 2**96 - 1,
            n=0xFFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551,
            g=(0x6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296,
               0x4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5))

def ec_add(P, Q, p=P256["p"]):
    if P is None or Q is None:
        return P or Q
    if P[0] == Q[0] and (P[1] + Q[1]) % p == 0:
        return None
    if P == Q:
        lam = (3 * P[0] * P[0] - 3) * pow(2 * P[1], -1, p) % p
    else:
        lam = (Q[1] - P[1]) * pow(Q[0] - P[0], -1, p) % p
    x = (lam * lam - P[0] - Q[0]) % p
    return x, (lam * (P[0] - x) - P[1]) % p

def ec_mul(k, P):
    R = None
    while k:
        if k & 1:
            R = ec_add(R, P)
        P, k = ec_add(P, P), k >> 1
    return R

def verify(dnskey, data, sig):
    alg, key = dnskey[3], dnskey[4:]
    if alg == 13:  # ECDSA P-256 with SHA-256, RFC 6605
        n = P256["n"]
        Q = (int.from_bytes(key[:32], "big"), int.from_bytes(key[32:], "big"))
        r, s = int.from_bytes(sig[:32], "big"), int.from_bytes(sig[32:], "big")
        e = int.from_bytes(hashlib.sha256(data).digest(), "big")
        w = pow(s, -1, n)
        X = ec_add(ec_mul(e * w % n, P256["g"]), ec_mul(r * w % n, Q))
        return X is not None and X[0] % n == r
    if alg == 8:  # RSA/SHA-256, RFC 5702
        elen, k = (key[0], key[1:]) if key[0] else (int.from_bytes(key[1:3], "big"), key[3:])
        e, m = int.from_bytes(k[:elen], "big"), int.from_bytes(k[elen:], "big")
        size = (m.bit_length() + 7) // 8
        digest = bytes.fromhex("3031300d060960864801650304020105000420") + hashlib.sha256(data).digest()
        em = pow(int.from_bytes(sig, "big"), e, m).to_bytes(size, "big")
        return em == b"\x00\x01" + b"\xff" * (size - 3 - len(digest)) + b"\x00" + digest
    raise ValueError(f"algorithm {alg} not implemented here")

def signed_by(zone, rrtype, rdatas, sigs, keys, now=None):
    """Tags of keys in `keys` whose RRSIG over this RRset verifies and is in its validity window."""
    now = now or int(time.time())
    good = set()
    for sig in sigs:
        covered, alg, labels, ottl, exp, inc, tag = struct.unpack("!HBBIIIH", sig[:18])
        signer, end = read_name(sig, 18)
        if not inc <= now <= exp:
            continue
        data = sig[:end] + b"".join(
            wire_name(zone) + struct.pack("!HHIH", rrtype, 1, ottl, len(rd)) + rd for rd in sorted(rdatas))
        for k in keys:
            if key_tag(k) == tag and k[3] == alg and verify(k, data, sig[end:]):
                good.add(tag)
    return good

def keeps_validating(zone, ds_set, dnskeys, dnskey_sigs):
    """RFC 10026 4.2.1: the DNSKEY RRset carries a valid RRSIG from a key some DS points at."""
    pointed = [k for k in dnskeys if ds_from_dnskey(zone, k) in ds_set]
    return signed_by(zone, DNSKEY, dnskeys, dnskey_sigs, pointed)

Step 6: one verdict for the whole delegation

Per server, the script checks the existing chain first. The current DS has to point at a key whose signature over the DNSKEY RRset verifies, and the CDS and CDNSKEY sets must be signed by a key in both DNSKEY and the current DS, which is the RFC 7344 signer rule. Only then does it read what the server is asking for. Then all the answers have to be identical.

# --- block 6: one verdict for the whole delegation
def verdict(zone, requests, unreached, current_ds, dnskeys, dnskey_sigs):
    asked = set(requests.values())
    note = f" ({len(requests)} addresses answered, {unreached} not reached: retry those later)" if unreached else ""
    if len(asked) != 1:
        return "servers disagree -> cancel the update (RFC 9975 3, RFC 10026 4.1)" + note
    req = asked.pop()
    if isinstance(req, str):
        return req + (" -> cancel" if req.startswith(("inconsistent", "signatures")) else "") + note
    new_ds = list(req[0] or req[1])
    signers = keeps_validating(zone, new_ds, dnskeys, dnskey_sigs)
    if not signers:
        return "consistent, but no key in the new DS set signs the DNSKEY RRset -> cancel" + note
    if sorted(new_ds) == sorted(d for d in current_ds if d[3] == 2):
        return f"consistent, same as the current DS, nothing to do (DNSKEY signed by {sorted(signers)})" + note
    return f"consistent and would keep validating (DNSKEY signed by {sorted(signers)}) -> update" + note

def check(zone):
    zone = zone.rstrip(".").lower() + "."
    parent_ip, hosts, ips, current_ds = delegation(zone)
    print(f"{zone}  delegation NS from parent server {parent_ip}: {', '.join(hosts)}")
    print("  current DS at parent: " + "; ".join(show_ds(d) for d in current_ds))
    seen = collect(zone, ips)
    requests, unreached, last = {}, 0, None
    for (host, ip), answers in seen.items():
        if isinstance(answers, str):
            print(f"  {host:24} {ip:28} {answers}")
            unreached += 1
            continue
        dnskeys, dnskey_sigs = answers[DNSKEY]
        trusted = [k for k in dnskeys if ds_from_dnskey(zone, k) in current_ds]
        chain = signed_by(zone, DNSKEY, dnskeys, dnskey_sigs, trusted)
        # RFC 7344 4.1 Signer: CDS/CDNSKEY signed by a key that is in both DNSKEY and the current DS
        sig_ok = all(signed_by(zone, t, *answers[t], trusted) for t in (CDS, CDNSKEY) if answers[t][0])
        req = request(zone, answers) if chain and sig_ok else "signatures do not validate"
        requests[(host, ip)], last = req, answers[DNSKEY]
        label = req if isinstance(req, str) else "; ".join(show_ds(d) for d in (req[0] or req[1]))
        print(f"  {host:24} {ip:28} DNSKEY RRset signed by DS key {sorted(chain)}, asks for: {label}")
    if last is None:
        print("  VERDICT: no server answered -> retry later")
        return
    print("  VERDICT: " + verdict(zone, requests, unreached, current_ds, *last))

What it printed this morning

I ran it at about 08:44 UTC on 29 October against desec.io, cloudflare.com, isc.org and ietf.org. Here is the first zone in full and the verdict line for the other three:

desec.io.  delegation NS from parent server 65.22.160.17: ns1.desec.io., ns2.desec.org.
  current DS at parent: 53307 13 2 3F6A815A28593BA6...; 53307 13 4 156E3DFCCEB69A9B...
  ns1.desec.io.            2607:f740:e633:deec::2       skipped: no IPv6 route from this machine
  ns1.desec.io.            45.54.76.1                   DNSKEY RRset signed by DS key [53307], asks for: 53307 13 2 3F6A815A28593BA6...
  ns2.desec.org.           157.53.224.1                 DNSKEY RRset signed by DS key [53307], asks for: 53307 13 2 3F6A815A28593BA6...
  ns2.desec.org.           2607:f740:e00a:deec::2       skipped: no IPv6 route from this machine
  VERDICT: consistent, same as the current DS, nothing to do (DNSKEY signed by [53307]) (2 addresses answered, 2 not reached: retry those later)

cloudflare.com.  delegation NS from parent server 192.5.6.30: ns3.cloudflare.com., ns4.cloudflare.com., ns5.cloudflare.com., ns6.cloudflare.com., ns7.cloudflare.com.
  VERDICT: consistent, same as the current DS, nothing to do (DNSKEY signed by [2371]) (10 addresses answered, 10 not reached: retry those later)
isc.org.  delegation NS from parent server 199.19.56.1: ns.isc.afilias-nst.info., ns1.isc.org., ns2.isc.org., ns3.isc.org., nsp.dnsnode.net.
  VERDICT: consistent, same as the current DS, nothing to do (DNSKEY signed by [7250]) (5 addresses answered, 5 not reached: retry those later)
ietf.org.  delegation NS from parent server 199.19.56.1: jill.ns.cloudflare.com., ken.ns.cloudflare.com.
  VERDICT: consistent, same as the current DS, nothing to do (DNSKEY signed by [2371]) (6 addresses answered, 6 not reached: retry those later)

All four are in the steady state: every reachable server asks for exactly the DS set the parent already publishes, so a parent running this check would do nothing. Three details in the output need a word.

First, half the addresses were not reached. This machine has no IPv6 route, so every AAAA address came back as skipped. The script says so in the verdict and does not count those addresses as agreeing. A real parental agent has to reach them, because a server that's only wrong over IPv6 is still wrong for every IPv6 resolver.

Second, desec.io publishes two CDS records for the same key, one with digest type 2 and one with type 4 (SHA-384), and the parent publishes both as DS. The check compares only the type 2 record, as RFC 9975 says.

Third, cloudflare.com and ietf.org (whose nameservers are Cloudflare's) serve the same DNSKEY records byte for byte, key tags 2371 and 34505 in both, yet their DS digests differ. This snippet, run after the blocks above, shows it:

for zone, ip in [("cloudflare.com.", "162.159.0.33"), ("ietf.org.", "108.162.192.122")]:
    keys = sorted(rd for _, t, _, rd, _ in query(ip, zone, DNSKEY)["answer"] if t == DNSKEY)
    ksk = [k for k in keys if k[1] & 1]  # SEP bit set: flags 257
    print(zone, "DNSKEY tags", [key_tag(k) for k in keys],
          "RRset sha256", hashlib.sha256(b"".join(keys)).hexdigest()[:16],
          "DS", show_ds(ds_from_dnskey(zone, ksk[0])))

cloudflare.com. DNSKEY tags [34505, 2371] RRset sha256 69e8f4852724126a DS 2371 13 2 32996839A6D808AF...
ietf.org. DNSKEY tags [34505, 2371] RRset sha256 69e8f4852724126a DS 2371 13 2 B1AE88AFF068DDEC...

The zone name is part of the hashed input, so the same key gives a different DS under each name. A check that compared key tags, or even key bytes, would treat these two delegations as interchangeable. Compare full DS records.

The cases that should be refused

The live run only exercised the happy path, so the last block reruns the same decision on edited copies of the real answers: 64 random bytes in the shape of a P-256 public key that no zone publishes, a delete signal, and a CDS that no longer matches its CDNSKEY. These are simulated, and the edited records are not re-signed, so this exercises the consistency and continuity logic only, not the signature checks.

# --- block 7: the same decision on answers that should be refused (simulated, signatures not re-made)
def simulate(zone):
    zone = zone.rstrip(".").lower() + "."
    _, _, ips, current_ds = delegation(zone)
    real = {k: v for k, v in collect(zone, ips).items() if not isinstance(v, str)}
    first = next(iter(real))
    other_key = struct.pack("!HBB", 257, 3, 13) + random.randbytes(64)  # a key nobody published
    new_key_only = {CDS: ([ds_from_dnskey(zone, other_key)], []), CDNSKEY: ([other_key], [])}
    cases = [  # (description, change, apply to every server?)
        ("one server still serves an old key", new_key_only, False),
        ("CDS and CDNSKEY name different keys", {CDS: ([ds_from_dnskey(zone, other_key)], [])}, True),
        ("all agree on a key that is not in DNSKEY", new_key_only, True),
        ("all ask for deletion", {CDS: ([DELETE_CDS], []), CDNSKEY: ([DELETE_CDNSKEY], [])}, True),
    ]
    for name, change, everywhere in cases:
        answers = {k: dict(v) for k, v in real.items()}
        for k in (answers if everywhere else [first]):
            answers[k].update(change)
        requests = {k: request(zone, a) for k, a in answers.items()}
        print(f"  {name:42} -> {verdict(zone, requests, 0, current_ds, *real[first][DNSKEY])}")

if __name__ == "__main__":
    if sys.argv[1:2] == ["--simulate"]:
        for z in sys.argv[2:]:
            print(z)
            simulate(z)
    else:
        for z in sys.argv[1:]:
            check(z)
            print()

desec.io
  one server still serves an old key         -> servers disagree -> cancel the update (RFC 9975 3, RFC 10026 4.1)
  CDS and CDNSKEY name different keys        -> inconsistent: CDS and CDNSKEY name different keys -> cancel
  all agree on a key that is not in DNSKEY   -> consistent, but no key in the new DS set signs the DNSKEY RRset -> cancel
  all ask for deletion                       -> delete DS

The second-to-last line is the one RFC 10026 adds. Every server agrees, the signatures could all be valid in a real case, and the update would still make the zone fail validation for every validating resolver, because no key in the requested DS set signs the DNSKEY RRset. That is how a rollover goes wrong when the new DS goes up before the new key is in the zone. The last line shows that a consistent delete request passes this check. The parent's own policy decides what happens next.

What this script does not do

It does not reach IPv6 addresses from this machine, and it does not retry silent servers on a back-off schedule, which RFC 9975 recommends.
It trusts Google Public DNS for the nameserver addresses and does not check the AD bit itself.
It verifies algorithms 8 and 13 only.
It does not handle bootstrapping a zone that has no DS yet. That's RFC 9615, a different procedure.
It queries from one network location. RFC 9975 allows trying another vantage point when a server is unreachable.

RFC 10026 is a Best Current Practice. It says what parents doing DS automation should check, not what any particular registry or registrar does today, and I didn't test any of them. If you publish CDS records for your own zone, the script will tell you whether they would pass these checks.

Written with AI assistance from my own notes and test results. I checked every fact and command before publishing.

Asking Let's Encrypt when to renew: an ARI request built by hand in Python

Jose Pollman — Tue, 27 Oct 2026 08:45:42 +0000

Let's Encrypt's 7 October post moves the default certificate lifetime from 90 days to 64 days on 10 February 2027, and the post scheduled staging to switch on 14 October. The advice in it comes in two parts. If your client supports ACME Renewal Information (ARI), "you should be all set". If it doesn't, renew "at approximately ⅔ of the lifetime instead".

I wanted to see what "all set" means on the wire: what the client asks, what the CA answers, and how close the answer is to the two-thirds rule. ARI is a plain unauthenticated GET, so you can make the request yourself with the Python standard library and no ACME account. Everything below was run on 27 October 2026.

Step 1: the directory tells you where to ask

Every ACME server publishes a directory object. Let's Encrypt's production one, trimmed:

curl -s https://acme-v02.api.letsencrypt.org/directory

{
  "meta": {
    "caaIdentities": ["letsencrypt.org"],
    "profiles": {
      "classic": "https://letsencrypt.org/docs/profiles#classic",
      "shortlived": "https://letsencrypt.org/docs/profiles#shortlived",
      "tlsserver": "https://letsencrypt.org/docs/profiles#tlsserver"
    },
    "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.8-July-06-2026.pdf",
    "website": "https://letsencrypt.org"
  },
  "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
  "renewalInfo": "https://acme-v02.api.letsencrypt.org/acme/renewal-info",
  "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
}

Two fields matter here. renewalInfo is the ARI endpoint, and RFC 9773 §3 says a server that offers ARI MUST put it there. profiles lists the certificate profiles you can request. The staging directory returned the same three names that day.

The directory gives names only. Lifetimes live on the profiles page: tlsserver is 45 days, shortlived is 160 hours. That page was last updated on 4 October and still lists classic at 90 days, three days before the 64-day announcement. So the directory won't tell your code how long its certificate lasts. The certificate will, and ARI doesn't need you to know.

Step 2: build the certificate ID

RFC 9773 §4.1 defines the path. Take the keyIdentifier from the certificate's Authority Key Identifier extension, take the DER bytes of the serial number without the tag and length, base64url both, strip the = padding, and join them with a dot. The RFC includes a worked example, which makes a free unit test.

The standard library's ssl module hands you the peer certificate as DER, and its parsed dictionary form has no AKI in it, so here is a small DER reader. It only handles what an X.509 certificate needs to get to the serial, the validity dates and the AKI.

import base64, json, socket, ssl, sys, urllib.request
from datetime import datetime, timezone

DIRECTORY = "https://acme-v02.api.letsencrypt.org/directory"


def read_tlv(buf, i):
    tag = buf[i]
    length = buf[i + 1]
    i += 2
    if length & 0x80:
        n = length & 0x7F
        length = int.from_bytes(buf[i:i + n], "big")
        i += n
    return tag, buf[i:i + length], i + length


def children(buf):
    i, out = 0, []
    while i < len(buf):
        tag, val, i = read_tlv(buf, i)
        out.append((tag, val))
    return out


def parse_time(tag, val):
    s = val.decode()
    fmt = "%y%m%d%H%M%SZ" if tag == 0x17 else "%Y%m%d%H%M%SZ"
    return datetime.strptime(s, fmt).replace(tzinfo=timezone.utc)


AKI_OID = bytes.fromhex("551d23")  # 2.5.29.35


def cert_fields(der):
    _, cert, _ = read_tlv(der, 0)
    tbs = children(children(cert)[0][1])
    pos = 1 if tbs[0][0] == 0xA0 else 0  # skip [0] version
    serial = tbs[pos][1]                 # DER INTEGER content bytes
    validity = children(tbs[pos + 3][1])
    not_before = parse_time(*validity[0])
    not_after = parse_time(*validity[1])
    aki = None
    for tag, val in tbs:
        if tag != 0xA3:                  # [3] extensions
            continue
        for _, ext in children(children(val)[0][1]):
            parts = children(ext)
            if parts[0][1] == AKI_OID:
                aki_seq = children(parts[-1][1])[0][1]
                for t, v in children(aki_seq):
                    if t == 0x80:        # [0] keyIdentifier
                        aki = v
    return serial, not_before, not_after, aki

The serial is the one place it's easy to get wrong. DER integers are signed, so a serial whose first byte has the top bit set carries a leading 0x00. The RFC wants those bytes as encoded, leading zero included. Converting the serial to an int and back with the minimum byte length drops the zero and gives you an ID the server has never heard of. Taking the INTEGER's content bytes straight from the DER avoids the problem.

def b64url(b):
    return base64.urlsafe_b64encode(b).decode().rstrip("=")


def ari_id(aki, serial):
    return b64url(aki) + "." + b64url(serial)

Step 3: ask, and compare with two thirds

The rest connects to a host, pulls its certificate, builds the ID and asks Let's Encrypt. The first line checks the RFC's worked example, serial 00:87:65:43:21 with its leading zero.

def fetch_cert(host):
    ctx = ssl.create_default_context()
    with socket.create_connection((host, 443), timeout=10) as sock:
        with ctx.wrap_socket(sock, server_hostname=host) as tls:
            return tls.getpeercert(binary_form=True)


def get_json(url):
    req = urllib.request.Request(url, headers={"User-Agent": "ari-check/0.1"})
    with urllib.request.urlopen(req, timeout=10) as r:
        return json.load(r), r.headers.get("Retry-After")


# Self-test against the worked example in RFC 9773 section 4.1
assert ari_id(bytes.fromhex("69885B6B87464041E1B37B847BA0AE2CDE01C8D4"),
              bytes.fromhex("0087654321")) == "aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE"

directory, _ = get_json(DIRECTORY)
print("profiles:", ", ".join(directory["meta"]["profiles"]))
base = directory["renewalInfo"]

for host in sys.argv[1:]:
    serial, nb, na, aki = cert_fields(fetch_cert(host))
    life = na - nb
    two_thirds = nb + life * 2 / 3
    cid = ari_id(aki, serial)
    print(f"\n{host}")
    print(f"  notBefore  {nb:%Y-%m-%d %H:%M}Z  notAfter {na:%Y-%m-%d %H:%M}Z")
    print(f"  lifetime   {life.total_seconds() / 86400:.2f} days")
    print(f"  2/3 point  {two_thirds:%Y-%m-%d %H:%M}Z")
    print(f"  ARI id     {cid}")
    try:
        info, retry = get_json(f"{base}/{cid}")
    except Exception as e:
        print(f"  ARI        no answer ({e})")
        continue
    w = info["suggestedWindow"]
    start = datetime.fromisoformat(w["start"].replace("Z", "+00:00"))
    end = datetime.fromisoformat(w["end"].replace("Z", "+00:00"))
    print(f"  ARI window {start:%Y-%m-%d %H:%M}Z -> {end:%Y-%m-%d %H:%M}Z")
    print(f"  as share of lifetime {(start - nb) / life:.3f} -> {(end - nb) / life:.3f}")
    print(f"  Retry-After {retry}s")
    if "explanationURL" in info:
        print(f"  explanation {info['explanationURL']}")

I pointed it at two hosts that use Let's Encrypt and one that doesn't:

$ python3 ari_check.py letsencrypt.org community.letsencrypt.org google.com
profiles: classic, shortlived, tlsserver

letsencrypt.org
  notBefore  2026-09-04 14:34Z  notAfter 2026-12-03 14:34Z
  lifetime   90.00 days
  2/3 point  2026-11-03 14:34Z
  ARI id     uVnyjs8i8IbTN0j_dhQYuoLYVYc.BUOTO-OGs6KzrdU08hA7yLZf
  ARI window 2026-11-02 17:18Z -> 2026-11-04 12:29Z
  as share of lifetime 0.657 -> 0.677
  Retry-After 22509s

community.letsencrypt.org
  notBefore  2026-10-17 00:01Z  notAfter 2027-01-15 00:01Z
  lifetime   90.00 days
  2/3 point  2026-12-16 00:01Z
  ARI id     QBUtJnntMiCe35pyHdYyH4EMgQw.BaDPfcSmSl1rE-x3CK9ycwDS
  ARI window 2026-12-15 02:45Z -> 2026-12-16 21:56Z
  as share of lifetime 0.657 -> 0.677
  Retry-After 18328s

google.com
  notBefore  2026-09-28 18:38Z  notAfter 2026-12-21 18:38Z
  lifetime   84.00 days
  2/3 point  2026-11-23 18:38Z
  ARI id     db7Ed66J9kQ3fc-xaB8dGuvcNFk.AKNba7BW76hrEPyYtBP27-k
  ARI        no answer (HTTP Error 404: Not Found)

Three things in that output.

The window is close to two thirds but it isn't a point. For both certificates it ran from 65.7% to 67.7% of the lifetime, about 43 hours wide, with the two-thirds mark inside it. Two certificates issued six weeks apart got the same shape, which suggests a rule applied to the lifetime rather than a fixed day count. Two certificates aren't enough to say what the rule is, and nothing stops Let's Encrypt changing it. That's the point of asking.

Retry-After came back at 22,509 and 18,328 seconds, about 6.3 and 5.1 hours. Under §4.3 that's not a minimum. It "indicates the desired (i.e., both requested minimum and maximum) amount of time to wait", so a client should check again after roughly that long, not whenever it likes.

The ID only means something to the CA that issued the certificate. google.com's certificate isn't from Let's Encrypt, so its ID got a 404. A tool that manages certificates from more than one CA has to read each CA's own directory.

What a client should do with the window

RFC 9773 §4.2 recommends picking a uniformly random time inside the window and renewing right away if that time has passed. Otherwise the client schedules itself for that time if it can, renews now if the pick falls before its next normal wake-up, and failing both, sleeps until Retry-After and asks again. The random pick spreads load across the window. A window whose end is not after its start is invalid, and the client has to treat it as no answer at all. Here's that as a function with a two-thirds fallback for when ARI fails:

import random


def next_renewal(nb, na, window=None, now=None):
    now = now or datetime.now(timezone.utc)
    if window:
        start, end = window
        if end > start:
            pick = start + (end - start) * random.random()
            return max(pick, now)
    # No usable ARI answer: fall back to two thirds of the lifetime
    return max(nb + (na - nb) * 2 / 3, now)

Two more rules from the RFC catch out home-grown scripts. A client MUST NOT check a certificate's renewal info after it has expired, or after the certificate has been replaced. And a long-term error, such as a missing Retry-After or any non-5xx HTTP error, means making the next request once six hours have passed (or a locally configured default) rather than hammering the endpoint. When the client does renew, §5 lets it put the old certificate's ID in a replaces field on the new order, which tells the CA which certificate the new one supersedes.

Why the fallback should be a fraction, not a day count

The two-thirds fallback stays sensible when the lifetime changes. A rule written as a fixed number of days doesn't. On a 90-day certificate, two thirds is day 60. On a 64-day one it's day 42.7, and on a 45-day tlsserver certificate it's day 30. A cron job that renews every 60 days was fine at 90 and lets a 45-day certificate expire. Computing from notBefore and notAfter, as the script does, means the next lifetime change needs no code change.

The staging change in the 7 October post is how to find out before February. A second staging change is scheduled for today. From 27 October, Let's Encrypt staging is due to validate domains from seven places, one primary and six remote perspectives instead of four, with production planned for 10 November if staging goes well. A staging run this week tests both the new lifetime and the new validation path in one go. I didn't issue a staging certificate for this post, so I can't show a 64-day one here. The ARI request above works against the staging renewalInfo URL the same way.

Written with AI assistance from my own notes and test results. I checked every fact and command before publishing.

Eight CA private keys under 256: checking every EC key in CCADB with the Python standard library

Jose Pollman — Thu, 22 Oct 2026 07:53:28 +0000

On 17 October, someone told the browser root programs they could recover the private keys of eight intermediate CA certificates issued by eMudhra. Mozilla's incident report, Bugzilla 2083449, explains how that was possible in one line:

The 8 impacted keys all used integers less than 256.

A P-384 private key should be a random number about 384 bits long. These were one byte. Every signature they made was valid and every chain built on them validated. Anyone could find the keys by trying 255 numbers.

I wanted to see that myself without installing anything, so I wrote a check that uses only the Python standard library. It reads the public key out of every certificate in CCADB's public reports, compares it with the public keys for private keys 1 to 65,535, and matches SPKI hashes against the list Go shipped on 19 October. Then I pointed a second script at the trust store on the machine I ran it on, and found the distrusted root still in it. Everything below was run on 22 October 2026.

What the incident report says

From the report and its comments, attributed to whoever said it:

The report reached Mozilla at 20:06 UTC on 17 October with proof of key control for all eight. Mozilla says it recovered the keys independently by 21:48 UTC.
Six are TLS intermediates trusted by Chrome, Mozilla, Microsoft and Apple. Two are code-signing intermediates trusted by Microsoft.
eMudhra revoked all eight on 18 October with the reason cACompromise. Sectigo revoked its cross-signatures of the same keys on 19 October.
eMudhra says the keys came from one key ceremony on 30 April 2025, only one of the eight was in production, and no end-entity certificates were issued from any of them. Its preliminary assessment points at a flaw in the key-generation script during a wrap/unwrap test that departed from its usual ceremony. It says it is still assessing.
On 20 October, Mozilla wrote that "multiple individuals have independently recovered the private keys" and removed trust in the whole emSign ECC Root CA - G3. Chrome said it would take a similar path.

Go's fix landed a day earlier. Go 1.26.10 and 1.27.3 add a distrustedSPKIHashes map of eight SHA-256 hashes to crypto/x509 and drop any chain containing one of them. The commit names no CA. My reading of why Go needed its own list comes from verify.go itself. The doc comment on Verify says "this function doesn't do any revocation checking", and on Linux the roots come from the OS bundle (root_linux.go tries /etc/ssl/certs/ca-certificates.crt first). With no CRL check and no control over the OS bundle, a list of bad keys is the one thing Go can enforce everywhere, and the same commit adds the check to the macOS and Windows verifier paths too.

Finding a small private key without any discrete-log maths

An EC public key is the point d·G, where d is the private key and G is the curve's generator. Recovering d from a properly random key is the hard problem the whole scheme rests on. Recovering it when d is below 256 is a loop: compute G, 2G, 3G and so on, and compare each one with the public key.

Here is the curve arithmetic for P-256 and P-384, in affine coordinates with Python's built-in modular inverse. The self-test matters more than it looks. A typo in the generator or the prime would make the table silently useless, and checking that G is on the curve and that n·G is the point at infinity catches a typo in any of the four constants.

import csv, hashlib, re, sys
from base64 import b64decode

# NIST P-256 and P-384: field prime, curve b (a = -3 on both), generator, order
CURVES = {
    "P-256": dict(
        oid=bytes.fromhex("2a8648ce3d030107"),
        p=2**256 - 2**224 + 2**192 + 2**96 - 1,
        b=0x5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63BCE3C3E27D2604B,
        g=(0x6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296,
           0x4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5),
        n=0xFFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551),
    "P-384": dict(
        oid=bytes.fromhex("2b81040022"),
        p=2**384 - 2**128 - 2**96 + 2**32 - 1,
        b=0xB3312FA7E23EE7E4988E056BE3F82D19181D9C6EFE8141120314088F5013875AC656398D8A2ED19D2A85C8EDD3EC2AEF,
        g=(0xAA87CA22BE8B05378EB1C71EF320AD746E1D3B628BA79B9859F741E082542A385502F25DBF55296C3A545E3872760AB7,
           0x3617DE4A96262C6F5D9E98BF9292DC29F8F41DBD289A147CE9DA3113B5F0B8C00A60B1CE1D7E819D7A431D7C90EA0E5F),
        n=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC7634D81F4372DDF581A0DB248B0A77AECEC196ACCC52973),
}


def ec_add(c, P, Q):
    """Affine point addition on y^2 = x^3 - 3x + b. None is the point at infinity."""
    p = c["p"]
    if P is None:
        return Q
    if Q is None:
        return P
    if P[0] == Q[0] and (P[1] + Q[1]) % p == 0:
        return None
    if P == Q:
        lam = (3 * P[0] * P[0] - 3) * pow(2 * P[1], -1, p) % p
    else:
        lam = (Q[1] - P[1]) * pow(Q[0] - P[0], -1, p) % p
    x = (lam * lam - P[0] - Q[0]) % p
    return x, (lam * (P[0] - x) - P[1]) % p


def ec_mul(c, k, P):
    R = None
    while k:
        if k & 1:
            R = ec_add(c, R, P)
        P = ec_add(c, P, P)
        k >>= 1
    return R


def self_test(c):
    x, y = c["g"]
    assert (y * y - (x**3 - 3 * x + c["b"])) % c["p"] == 0, "G is not on the curve"
    assert ec_mul(c, c["n"], c["g"]) is None, "n*G is not the point at infinity"


def small_key_table(c, limit):
    """Public points for private keys 1..limit-1, keyed by point."""
    table, P = {}, None
    for d in range(1, limit):
        P = ec_add(c, P, c["g"])
        table[P] = d
    return table

Pulling the public key out of a certificate

Go hashes RawSubjectPublicKeyInfo, the complete DER-encoded SubjectPublicKeyInfo, so the script has to cut out exactly those bytes. A certificate is a SEQUENCE containing the to-be-signed SEQUENCE, and the SPKI is the sixth field of that once the optional [0] version tag is skipped. A minimal DER reader is enough:

def tlv(buf, i):
    """Read one DER tag-length-value. Returns (tag, value_start, value_end)."""
    tag, length = buf[i], buf[i + 1]
    i += 2
    if length & 0x80:
        n = length & 0x7F
        length = int.from_bytes(buf[i:i + n], "big")
        i += n
    return tag, i, i + length


def children(buf, start, end):
    out = []
    while start < end:
        tag, vs, ve = tlv(buf, start)
        out.append((tag, start, vs, ve))
        start = ve
    return out


def spki_der(cert):
    """The raw SubjectPublicKeyInfo bytes, the thing Go hashes."""
    _, vs, ve = tlv(cert, 0)
    _, tvs, tve = tlv(cert, vs)  # tbsCertificate
    fields = children(cert, tvs, tve)
    if fields[0][0] == 0xA0:  # explicit [0] version
        fields = fields[1:]
    _, start, _, end = fields[5]  # serial, sigAlg, issuer, validity, subject, spki
    return cert[start:end]


def ec_public_point(spki):
    """(curve name, (x, y)) for an EC key, or (None, None) for anything else."""
    _, vs, ve = tlv(spki, 0)
    (_, _, avs, ave), (_, _, bvs, bve) = children(spki, vs, ve)
    params = children(spki, avs, ave)
    if len(params) < 2:
        return None, None
    curve_oid = spki[params[1][2]:params[1][3]]
    point = spki[bvs + 1:bve]  # skip the unused-bits byte
    for name, c in CURVES.items():
        if c["oid"] == curve_oid and point[0] == 4:
            half = (len(point) - 1) // 2
            return name, (int.from_bytes(point[1:1 + half], "big"),
                          int.from_bytes(point[1 + half:], "big"))
    return None, None


def pem_to_der(text):
    m = re.search(r"-----BEGIN CERTIFICATE-----(.*?)-----END CERTIFICATE-----", text, re.S)
    return b64decode("".join(m.group(1).split())) if m else None

Running it over CCADB

The last part holds Go's eight hashes, copied from verify.go at tag go1.27.3, and walks a CCADB CSV. The three CCADB reports below are Mozilla's revoked intermediates, all intermediates, and included roots, each with a PEM column.

GO_DISTRUSTED = {  # crypto/x509/verify.go at go1.27.3, lines 1417-1426
    "ebed6475c2c2d80fcb199f3fe8dd6e6b3ce60b77eb15d4e42c3dec0c6f5b5105",
    "49dd353dc2b919a3770645117d0e60c16115e7d1bc259eefe734b00ea434fe5f",
    "e0254c7fcdc265e2f0f8a428dabb75ab4ae039b4872d62f5ee57f0877d5a8a41",
    "5c0660a2b164910d8ff589c18e14552e9e0ec237dcefe2cb736d41a4811f81a0",
    "43bffa19d6ef651451f6841e019931e96f6f2eaeff28ab4b6f1ce4576de2717b",
    "63ecefee431d49523bc1136c4e72d0206a477086caf606cd5cf025686c109cf8",
    "ec4ffa1ad0ac88081314b7aaffef6a91f97cd57291bb5ba686c5415f5eb4f6b6",
    "92c063d67e8f14db71d288e11266ffdaf69cbf115f7bab14f3bc2f68d25e0e30",
}

LIMIT = 2**16  # private keys 1..65535: covers "below 256" with room to spare


def scan(path, tables):
    csv.field_size_limit(sys.maxsize)
    rows = list(csv.DictReader(open(path, encoding="utf-8")))
    pem_col = next(k for k in rows[0] if "PEM" in k)
    name_col = next(k for k in ("Certificate Subject Common Name",
                                "Common Name or Certificate Name") if k in rows[0])
    counts = {"rows": len(rows), "P-256": 0, "P-384": 0, "go_match": 0}
    hits = []
    for r in rows:
        der = pem_to_der(r[pem_col])
        if der is None:
            continue
        spki = spki_der(der)
        spki_hash = hashlib.sha256(spki).hexdigest()
        in_go = spki_hash in GO_DISTRUSTED
        counts["go_match"] += in_go
        curve, point = ec_public_point(spki)
        if curve is None:
            continue
        counts[curve] += 1
        d = tables[curve].get(point)
        if d is not None or in_go:
            hits.append((r[name_col], r.get("Certificate Issuer Common Name", ""),
                         curve, d, spki_hash[:16], in_go))
    return counts, hits


if __name__ == "__main__":
    tables = {}
    for name, c in CURVES.items():
        self_test(c)
        tables[name] = small_key_table(c, LIMIT)
    print(f"self-test passed; tables hold private keys 1..{LIMIT - 1} on P-256 and P-384")
    for path in sys.argv[1:]:
        counts, hits = scan(path, tables)
        print(f"\n{path.split('/')[-1]}: {counts['rows']} rows, "
              f"{counts['P-256']} P-256 keys, {counts['P-384']} P-384 keys, "
              f"{counts['go_match']} certificates whose SPKI hash is in Go's list")
        for subj, issuer, curve, d, h, in_go in sorted(hits):
            size = f"{d.bit_length()}-bit key" if d else "not small"
            print(f"  {subj:<20} issuer={issuer:<26} {curve} {size:<10} spki={h}... in_go={in_go}")

curl -s -o ccadb.csv 'https://ccadb.my.salesforce-sites.com/mozilla/PublicIntermediateCertsRevokedWithPEMCSV'
curl -s -O 'https://ccadb.my.salesforce-sites.com/mozilla/PublicAllIntermediateCertsWithPEMCSV'
curl -s -O 'https://ccadb.my.salesforce-sites.com/mozilla/IncludedCACertificateReportPEMCSV'
mv PublicAllIntermediateCertsWithPEMCSV PublicAllIntermediateCertsWithPEMCSV.csv
mv IncludedCACertificateReportPEMCSV IncludedCACertificateReportPEMCSV.csv
python3 tinykey_check.py ccadb.csv PublicAllIntermediateCertsWithPEMCSV.csv IncludedCACertificateReportPEMCSV.csv

self-test passed; tables hold private keys 1..65535 on P-256 and P-384

ccadb.csv: 2977 rows, 114 P-256 keys, 243 P-384 keys, 16 certificates whose SPKI hash is in Go's list
  EM DV TLS CA - G3B   issuer=AAA Certificate Services   P-384 8-bit key  spki=ebed6475c2c2d80f... in_go=True
  EM DV TLS CA - G3B   issuer=emSign Root TLS CA - G3    P-384 8-bit key  spki=ebed6475c2c2d80f... in_go=True
  EM DV TLS CA - G3C   issuer=AAA Certificate Services   P-384 8-bit key  spki=49dd353dc2b919a3... in_go=True
  EM DV TLS CA - G3C   issuer=emSign Root TLS CA - G3    P-384 8-bit key  spki=49dd353dc2b919a3... in_go=True
  EM EV TLS CA - G3B   issuer=AAA Certificate Services   P-384 7-bit key  spki=e0254c7fcdc265e2... in_go=True
  EM EV TLS CA - G3B   issuer=emSign Root TLS CA - G3    P-384 7-bit key  spki=e0254c7fcdc265e2... in_go=True
  EM EV TLS CA - G3C   issuer=AAA Certificate Services   P-384 6-bit key  spki=5c0660a2b164910d... in_go=True
  EM EV TLS CA - G3C   issuer=emSign Root TLS CA - G3    P-384 6-bit key  spki=5c0660a2b164910d... in_go=True
  EM OV CS CA - G3B    issuer=AAA Certificate Services   P-384 7-bit key  spki=ec4ffa1ad0ac8808... in_go=True
  EM OV CS CA - G3B    issuer=emSign Root CS CA - G3     P-384 7-bit key  spki=ec4ffa1ad0ac8808... in_go=True
  EM OV CS CA - G3C    issuer=AAA Certificate Services   P-384 8-bit key  spki=92c063d67e8f14db... in_go=True
  EM OV CS CA - G3C    issuer=emSign Root CS CA - G3     P-384 8-bit key  spki=92c063d67e8f14db... in_go=True
  EM OV TLS CA - G3B   issuer=AAA Certificate Services   P-384 8-bit key  spki=43bffa19d6ef6514... in_go=True
  EM OV TLS CA - G3B   issuer=emSign Root TLS CA - G3    P-384 8-bit key  spki=43bffa19d6ef6514... in_go=True
  EM OV TLS CA - G3C   issuer=AAA Certificate Services   P-384 3-bit key  spki=63ecefee431d4952... in_go=True
  EM OV TLS CA - G3C   issuer=emSign Root TLS CA - G3    P-384 3-bit key  spki=63ecefee431d4952... in_go=True

PublicAllIntermediateCertsWithPEMCSV.csv: 2517 rows, 420 P-256 keys, 374 P-384 keys, 0 certificates whose SPKI hash is in Go's list

IncludedCACertificateReportPEMCSV.csv: 169 rows, 3 P-256 keys, 48 P-384 keys, 0 certificates whose SPKI hash is in Go's list

The whole run took about four seconds. Sixteen revoked certificates carry the eight keys, because each key was certified twice: once by eMudhra's own emSign root and once by Sectigo's AAA Certificate Services cross-sign. All eight of Go's hashes are there, and every one of the eight keys is between 3 and 8 bits long.

I print the bit length rather than the number. The smallest is EM OV TLS CA - G3C, whose private key is 4. That value is already public: mitmproxy's main branch has a new --emudhra option, listed under "Unreleased" in its changelog, that lets the proxy sign the certificates it generates with this key. I parsed the PEM from that commit with openssl pkey, and it is 47 zero bytes followed by 04, with an SPKI hash of 63ecefee..., the sixth entry in Go's map. The other seven values are just as easy to print. I left them out because there is no reason to copy them around.

The other two reports are the control group. Among the 794 EC keys in CCADB's all-intermediates report and the 51 EC roots in Mozilla's included-roots report, nothing has a private key under 65,536. The revoked list also holds a second batch of eMudhra cross-signs that Sectigo revoked on 21 October with the reason cessationOfOperation, and none of those keys is small either. This test catches one specific failure: a key that is a small integer. A key drawn from a broken random number generator would pass it.

The part that applies to your machine

Revoking an intermediate only protects clients that check revocation. OpenSSL's verify does not by default, and neither does Python's ssl module. Here is the G3C intermediate from the CCADB CSV, checked against the system bundle on the Ubuntu 24.04 container I ran all of this in. The certificate linking emSign Root TLS CA - G3 to emSign ECC Root CA - G3 is not in either CCADB intermediate report I downloaded, so I took it from the same mitmproxy commit.

BUNDLE=/etc/ssl/certs/ca-certificates.crt

# 1. Path validation only (openssl verify does not check CRLs by default)
openssl verify -CAfile "$BUNDLE" -untrusted emsign-root-tls-g3-cross.pem em-ov-tls-g3c.pem

# 2. Same chain, with the issuer's CRL checked
curl -s --retry 3 -A Mozilla/5.0 -o roottlscag3.crl 'http://crl.emsign.com/?roottlscag3.crl'
openssl crl -inform DER -in roottlscag3.crl -out roottlscag3.pem
openssl verify -CAfile "$BUNDLE" -untrusted emsign-root-tls-g3-cross.pem \
  -crl_check -CRLfile roottlscag3.pem em-ov-tls-g3c.pem

em-ov-tls-g3c.pem: OK
C = US, O = eMudhra Inc, CN = EM OV TLS CA - G3C
error 23 at 0 depth lookup: certificate revoked
error em-ov-tls-g3c.pem: verification failed

Path validation alone says OK. The CRL says revoked. When I ran this, the CRL host answered curl's default user agent with a 403, so the script sends a different one.

Python's default context on the same container:

import ssl

ctx = ssl.create_default_context()
crl_flags = ssl.VERIFY_CRL_CHECK_LEAF | ssl.VERIFY_CRL_CHECK_CHAIN
print("CRL checking on by default:", bool(ctx.verify_flags & crl_flags))
for cert in ctx.get_ca_certs():
    name = dict(rdn[0] for rdn in cert["subject"]).get("commonName", "")
    if name.startswith("emSign"):
        print("trusted root:", name)

CRL checking on by default: False
trusted root: emSign Root CA - C1
trusted root: emSign ECC Root CA - C3
trusted root: emSign Root CA - G1
trusted root: emSign ECC Root CA - G3

So on this container, a Python client with default settings trusted the root above the revoked intermediates and did not look at the CRL. The fix for that is the trust bundle, and different bundles took different routes. This script checks a bundle by the root's SPKI hash rather than its name:

import hashlib, re, sys
from tinykey_check import pem_to_der, spki_der

# SPKI SHA-256 of emSign ECC Root CA - G3, as listed in rustls/webpki-roots PR 133
G3_ROOT = "8d417db2dd8bf5e3084d1e3f196d583849d81bdd4c00c70b9d39369e96b8c782"

for path in sys.argv[1:]:
    pems = re.findall(r"-----BEGIN CERTIFICATE-----.*?-----END CERTIFICATE-----",
                      open(path).read(), re.S)
    hashes = {hashlib.sha256(spki_der(pem_to_der(p))).hexdigest() for p in pems}
    print(f"{path}: {len(pems)} certificates, emSign ECC Root CA - G3 present: {G3_ROOT in hashes}")

for v in 2026.07.22 2026.10.18 2026.10.19; do
  curl -s -o certifi-$v.pem https://raw.githubusercontent.com/certifi/python-certifi/$v/certifi/cacert.pem
done
python3 bundle_check.py /etc/ssl/certs/ca-certificates.crt certifi-2026.07.22.pem certifi-2026.10.18.pem certifi-2026.10.19.pem

/etc/ssl/certs/ca-certificates.crt: 121 certificates, emSign ECC Root CA - G3 present: True
certifi-2026.07.22.pem: 121 certificates, emSign ECC Root CA - G3 present: True
certifi-2026.10.18.pem: 117 certificates, emSign ECC Root CA - G3 present: False
certifi-2026.10.19.pem: 120 certificates, emSign ECC Root CA - G3 present: False

Three different answers:

Ubuntu published ca-certificates 20260816ubuntu0.24.04.1 to noble-security on 20 October. Its changelog blacklists emSign ECC Root CA - G3 "due to intermediate cert compromise". My container still had 20260601~24.04.1 because nobody had upgraded it since. The fix existed and it was not on the machine.
certifi 2026.10.18 removed all four emSign roots. Universities whose services chain to other emSign roots reported breakage in certifi issue 439, and 2026.10.19 put three back and kept G3 out. A maintainer explained in that thread why the first release went wider than the intermediates: "there's no facility for revoking an intermediate only."
rustls webpki-roots 1.0.10 (PR 133) removed only G3 and printed its SPKI hash, 8d417db2...c782. That is the same hash bundle_check.py computes from Ubuntu's copy of the root, which is how I know the script is matching the right certificate.

What I am keeping from this

A root bundle is the only lever most clients have, and a machine can hold several copies: the OS package, a pinned certifi in a lockfile, a container image built before 20 October, and Go binaries built with a toolchain older than 1.26.10 or 1.27.3. Each needs its own update or rebuild. The SPKI-hash check above takes a few seconds per bundle.

The small-key test is cheap enough to run on any EC public key you generate yourself, as a smoke test. It would have flagged these eight on the day of the ceremony. It says nothing about keys that are bad in subtler ways.

And a valid signature tells you nothing about how the key behind it was made. Every chain here validated, and that was the problem.

Written with AI assistance from my own notes and test results. I checked every fact and command before publishing.

Three DNSSEC keys, one key tag: re-checking the .de outage report in Python

Jose Pollman — Tue, 20 Oct 2026 07:48:21 +0000

On 5 May 2026, .de domains were hard to reach for what DENIC puts at approximately three hours. DENIC published its final report on 11 June. It is short, and the cause comes down to one sentence:

This was therefore not a classic key tag collision, but rather three key pairs with different contents but identical metadata.

To see what that looks like from the validator's side, I wrote a check using nothing but the Python standard library. It computes the key tags of the live .de keys, matches the signing key to the DS record in the root, verifies two real signatures by hand, and then reproduces the failure mode with a throwaway key. Everything below was run on 20 October 2026.

What the report says happened

This is DENIC's own assessment of its own outage, so I am staying close to its wording. A rollover agent, an in-house component, was supposed to generate one key pair and load it into every connected HSM. A bug made it generate a separate key pair for each HSM and load each one into exactly one of them. All three carried the same identifiers, including key tag 33834. One of the three public keys was written into the zone as the ZSK, so only signatures made by the HSM holding the matching private key could be validated: "in practice, therefore, only about a third of all signatures."

The test environment had one HSM at one location, so the code path that only misbehaves with several HSMs never ran before go-live. The report also says three continuously running validation tools "detected the errors as intended; however, the generated notifications were not processed correctly." And it rules out a few things explicitly: no compromise or attack, no fault in the Knot name server, no HSM malfunction, and no classic key tag collision.

A key tag is a 16-bit checksum

RFC 4034 Appendix B defines the key tag as the sum of the DNSKEY RDATA taken as 16-bit words, with the carry folded back in once. The same appendix is blunt about what that means: "Implementations MUST NOT assume that the key tag uniquely identifies a DNSKEY RR."

There is no dig on the machine I use for these checks, so the script asks Google's DNS-over-HTTPS JSON API with do=1, which returns the RRSIG records alongside the answers. That is a resolver's view, not the authoritative servers', which is fine for this purpose. The Python blocks in this post, pasted into one file in the order shown, are the whole script. First the parsing helpers and the key tag function:

import base64, hashlib, json, secrets, struct, urllib.request

def doh(name, rrtype):
    url = f"https://dns.google/resolve?name={name}&type={rrtype}&do=1"
    with urllib.request.urlopen(url, timeout=10) as r:
        return json.load(r)

def answers(resp, rrtype):
    return [a["data"] for a in resp.get("Answer", []) if a["type"] == rrtype]

def wire_name(name):
    out = b""
    for label in name.rstrip(".").lower().split("."):
        out += bytes([len(label)]) + label.encode()
    return out + b"\x00"

def dnskey_rdata(text):
    flags, proto, alg, key = text.split(" ", 3)
    return struct.pack("!HBB", int(flags), int(proto), int(alg)) + base64.b64decode(key)

def key_tag(rdata):
    # RFC 4034 Appendix B, for every algorithm except 1
    ac = 0
    for i, b in enumerate(rdata):
        ac += b if i & 1 else b << 8
    ac += (ac >> 16) & 0xFFFF
    return ac & 0xFFFF

def rsa_public(rdata):
    # RFC 3110: exponent length, exponent, modulus (after flags/proto/alg)
    k = rdata[4:]
    if k[0] == 0:
        elen, k = int.from_bytes(k[1:3], "big"), k[3:]
    else:
        elen, k = k[0], k[1:]
    return int.from_bytes(k[:elen], "big"), int.from_bytes(k[elen:], "big")

rsa_public follows RFC 3110: one length octet for the exponent (or a zero octet plus two length octets if it is longer than 255 bytes), then the exponent, then the modulus.

Matching the signing key to the root

zone = "de."
keys = [dnskey_rdata(t) for t in answers(doh(zone, "DNSKEY"), 48)]
by_tag = {}
for rd in keys:
    flags = struct.unpack("!H", rd[:2])[0]
    by_tag.setdefault(key_tag(rd), []).append(rd)
    print(f"DNSKEY flags={flags} alg={rd[3]} bits={rsa_public(rd)[1].bit_length()} tag={key_tag(rd)}")

for ds in answers(doh(zone, "DS"), 43):
    tag, alg, dtype, digest = ds.split()
    for rd in by_tag.get(int(tag), []):
        ok = hashlib.sha256(wire_name(zone) + rd).hexdigest().upper() == digest.upper()
        print(f"DS in root: tag={tag} digest_type={dtype} matches DNSKEY {key_tag(rd)}: {ok}")

The DS digest is SHA-256 over the owner name in wire format followed by the DNSKEY RDATA (RFC 4034 section 5.1.4; digest type 2 is SHA-256). The first three lines of output:

DNSKEY flags=257 alg=8 bits=2048 tag=26755
DNSKEY flags=256 alg=8 bits=1024 tag=32911
DS in root: tag=26755 digest_type=2 matches DNSKEY 26755: True

So today .de publishes a 2048-bit KSK with tag 26755, which is what the root's DS points at, and a 1024-bit ZSK with tag 32911. Tag 33834 from the report is no longer in the DNSKEY set.

Verifying the signatures by hand

Checking a tag against a DS is the easy half. The part that failed on 5 May is the signature check, so the script does that too. For algorithm 8 (RSA/SHA-256), verification means raising the signature to the public exponent and comparing the result with the padded SHA-256 digest, using the DigestInfo prefix from RFC 5702. The signed data is the RRSIG RDATA without the signature field, followed by every record in the RRset in canonical order, each one carrying the original TTL from the RRSIG rather than whatever TTL the resolver returned.

SHA256_PREFIX = bytes.fromhex("3031300d060960864801650304020105000420")  # RFC 5702

def rsa_sha256_verify(e, n, data, sig):
    k = (n.bit_length() + 7) // 8
    em = pow(int.from_bytes(sig, "big"), e, n).to_bytes(k, "big")
    digest = SHA256_PREFIX + hashlib.sha256(data).digest()
    return em == b"\x00\x01" + b"\xff" * (k - 3 - len(digest)) + b"\x00" + digest

TYPES = {"soa": 6, "dnskey": 48}

def soa_rdata(text):
    mname, rname, *nums = text.split()
    return wire_name(mname) + wire_name(rname) + struct.pack("!5I", *map(int, nums))

def signed_data(rrsig_text, owner, rdatas):
    # RFC 4034 3.1.8.1: RRSIG RDATA without the signature, then the RRset in canonical order
    covered, alg, labels, ttl, exp, inc, tag, signer, _ = rrsig_text.split(" ", 8)
    head = struct.pack("!HBBIIIH", TYPES[covered], int(alg), int(labels), int(ttl),
                       int(exp), int(inc), int(tag)) + wire_name(signer)
    rrs = b""
    for rd in sorted(rdatas):
        rrs += wire_name(owner) + struct.pack("!HHIH", TYPES[covered], 1, int(ttl), len(rd)) + rd
    return head + rrs, int(tag)

def check(rrtype, rdatas_from):
    resp = doh(zone, rrtype)
    rdatas = rdatas_from(resp)
    for sig in answers(resp, 46):
        data, tag = signed_data(sig, zone, rdatas)
        raw = base64.b64decode(sig.rsplit(" ", 1)[1])
        for rd in by_tag.get(tag, []):
            e, n = rsa_public(rd)
            print(f"RRSIG over {rrtype} names tag {tag}: verifies = {rsa_sha256_verify(e, n, data, raw)}")
    return resp

check("DNSKEY", lambda r: [dnskey_rdata(t) for t in answers(r, 48)])
soa = check("SOA", lambda r: [soa_rdata(t) for t in answers(r, 6)])

The script only knows how to rebuild SOA and DNSKEY records, which is all it needs. Output:

RRSIG over DNSKEY names tag 26755: verifies = True
RRSIG over SOA names tag 32911: verifies = True

Both verify. The KSK (flags 257, Secure Entry Point bit set) signs the DNSKEY set, and the ZSK (flags 256) signs the SOA.

Reproducing "different contents, identical metadata"

Now the failure mode. The Key Tag field in an RRSIG is a number the signer writes. A validator reads it, looks for DNSKEY records in the zone with that owner, algorithm and tag, and tries them. RFC 4035 section 5.3.1 says that when several keys match, the validator "MUST try each matching DNSKEY RR until either the signature is validated or the validator has run out of matching public keys to try."

On 5 May there was exactly one matching DNSKEY to try, and for two of the three HSMs it was the wrong public key. The tag cannot tell a validator that, because it identifies a public key that is in the zone, not the private key that produced the signature.

So the last part of the script generates a second RSA key, signs the real .de SOA RRset with it, and writes the published ZSK's tag into the RRSIG fields:

# The 5 May failure mode: a second private key signs, and the RRSIG carries the published tag.
def probable_prime(bits):  # Fermat test: good enough for a throwaway demo key
    while True:
        p = secrets.randbits(bits) | (1 << bits - 1) | 1
        if all(pow(a, p - 1, p) == 1 for a in (2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37)):
            return p

e = 65537
while True:
    p, q = probable_prime(512), probable_prime(512)
    phi = (p - 1) * (q - 1)
    if p != q and phi % e:
        break
n2, d2 = p * q, pow(e, -1, phi)
k2 = (n2.bit_length() + 7) // 8
other_rdata = struct.pack("!HBB", 256, 3, 8) + b"\x03" + e.to_bytes(3, "big") + n2.to_bytes(k2, "big")

sig_text = answers(soa, 46)[0]
zsk_tag = int(sig_text.split()[6])
data, _ = signed_data(sig_text, zone, [soa_rdata(t) for t in answers(soa, 6)])
digest = SHA256_PREFIX + hashlib.sha256(data).digest()
em = b"\x00\x01" + b"\xff" * (k2 - 3 - len(digest)) + b"\x00" + digest
other_sig = pow(int.from_bytes(em, "big"), d2, n2).to_bytes(k2, "big")

print(f"second key's own tag: {key_tag(other_rdata)}; RRSIG written with tag {zsk_tag}")
print(f"  verifies against the second key: {rsa_sha256_verify(e, n2, data, other_sig)}")
for rd in by_tag[zsk_tag]:
    pe, pn = rsa_public(rd)
    print(f"  verifies against published DNSKEY {zsk_tag}: {rsa_sha256_verify(pe, pn, data, other_sig)}")

second key's own tag: 31959; RRSIG written with tag 32911
  verifies against the second key: True
  verifies against published DNSKEY 32911: False

The second key is random, so its own tag changes from run to run (31959 in the run shown here). The signature is valid under the key that made it, and it carries the published tag, so a validator finds a candidate DNSKEY straight away. It just fails, and with no other key carrying tag 32911 there is nothing left to try. That RRset is bogus.

The report does not explain how three different keys ended up carrying the same tag, and I am not going to guess. The demonstration only shows the validator's side: a matching tag tells you which published key to try, and nothing more.

Why unsigned .de domains broke too

The report also says that domains with no DNSSEC at all failed to resolve. The reason is the proof that a delegation has no DS record. Here is what a validating resolver gets back when it asks for the DS of example.de, which is a real, unsigned delegation:

curl -s "https://dns.google/resolve?name=example.de&type=DS&do=1" | python3 -c '
import json, sys
r = json.load(sys.stdin)
print("Status", r["Status"], "AD", r["AD"], "answers", len(r.get("Answer", [])))
for a in r["Authority"]:
    if a["type"] == 50:
        print("NSEC3 ", a["name"], a["data"])
    elif a["type"] == 46 and a["data"].startswith("nsec3"):
        print("RRSIG ", " ".join(a["data"].split()[:8]))
'

Status 0 AD False answers 0
NSEC3  a0d5d1p51kijsevll74k523htmq406bk.de. 1 1 0 - A0D5F6VETKD4HE1UG3NJGF20U4QMCIAQ NS SOA RRSIG DNSKEY NSEC3PARAM
NSEC3  cjkj4kvicg7rjbjst1mqfmeb6q28thd0.de. 1 1 0 - CJKJR41VLNHBFMDL2HTKSS0TBVM1GB73 NS DS RRSIG
RRSIG  nsec3 8 2 7200 1793603732 1792388732 32911 de.
RRSIG  nsec3 8 2 7200 1793603732 1792388732 32911 de.

No answer, and two NSEC3 records in the authority section: one for the zone apex and one whose range covers the hash of example.de (SHA-1, no salt, zero extra iterations per the NSEC3 parameters: cjkjelihnuqdpp2fevo6dvn8qdtj47ki, which sorts between that record's owner and its next-hashed name). Both have the opt-out flag set (the first field, 1). RFC 5155 section 3.1.2.1 says an NSEC3 with opt-out set "covers zero or more unsigned delegations." The resolver accepts that example.de is unsigned only after validating these records, and both are signed by the ZSK. If those signatures had been among the two thirds made by the wrong HSM, the "no DS here" proof would itself be bogus, and the resolver could not resolve example.de even though example.de never signed anything. The report describes the same mechanism and adds that non-validating resolvers kept serving .de without trouble.

What I took from running it

If you sign your own zone, a key tag that lines up with the DS or with an RRSIG proves very little. The useful post-rollover check verifies the signatures against the published DNSKEY set from outside your signer, the way the script does, on more than one record type. DENIC's own list of measures includes a partial validation of the zone before deployment, which is that check placed before publication rather than after.

The other lesson is in the report's own sentence about monitoring. The three validation tools found the fault. The alerts were not processed in time. DENIC published all of this, including the parts that reflect badly on its own process, and that is why anyone outside can learn from it.

Written with AI assistance from my own notes and test results. I checked every fact and command before publishing.

DMARC reports and out-of-office replies: the header the RFCs never mention

Jose Pollman — Thu, 15 Oct 2026 07:47:47 +0000

DMARC aggregate reports are mail sent by a machine, on a schedule, to whatever address a domain owner put in rua=. Nobody reads them as they arrive. That makes them exactly the kind of message an out-of-office reply should never answer, and the standard way to say so is one header: Auto-Submitted: auto-generated.

The DMARC RFCs never mention it. Two open-source report generators set it anyway. This post is the check behind those two sentences, plus a short script that shows what happens to a report with and without the header.

What the specs say, counted

DMARC was split into three documents in May 2026: RFC 9989 (the protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting). All three obsolete RFC 7489. The header itself is defined in RFC 3834, "Recommendations for Automatic Responses to Electronic Mail", from 2004.

I pulled the plain-text versions this morning and counted:

for r in 7489 9989 9990 9991 3834; do
  curl -s "https://www.rfc-editor.org/rfc/rfc$r.txt" -o "rfc$r.txt"
  echo "rfc$r: $(grep -ci 'auto-submitted' "rfc$r.txt")"
done

rfc7489: 0
rfc9989: 0
rfc9990: 0
rfc9991: 0
rfc3834: 22

Zero in all four DMARC documents. RFC 3834 is the control: its 22 hits show the grep works.

RFC 9990 is not vague about the report email. Section 3.5.2 pins down a lot: the message must follow RFC 5322 and MIME, the XML goes in an attachment typed application/gzip or text/xml, the filename follows an ABNF (receiver!policy-domain!begin!end.xml.gz), the Subject follows another ABNF (Report Domain: ... Submitter: ... Report-ID: ...), and the report stream must itself pass DMARC with alignment. It even says a re-sent report must reuse the original filename. It says nothing about how the message should present itself to software that auto-replies.

Why that header is the one that matters

RFC 3834 defines three values. auto-generated is for messages from automatic processes that are not replies to anything; the RFC's own example is a cron job. auto-replied is for automatic responses to another message, such as a vacation notice. no means a person sent it.

Then section 2 sets the rule for responders: automatic responses "SHOULD NOT be issued in response to any message which contains an Auto-Submitted header field" with any value other than no.

RFC 5230, the Sieve extension that defines a vacation autoresponder for mail servers, repeats it in section 4.6. The same RFC has another rule that a report email passes without trying: section 4.5 says vacation must not respond unless the recipient's address is in To, Cc or Bcc. A DMARC report is addressed straight to the rua= mailbox, so it passes that check.

That leaves the header, plus a few heuristics a responder may or may not apply, as the main thing between an aggregate report and an out-of-office reply. Where rua= points makes this more than theory. When I checked my own seven domains this morning, four of them sent aggregate reports to a hello@ address, and on three of those sites that is the contact address printed on the page. If I ever switch on an out-of-office for one of them, the reports and the human mail land in the same mailbox, under the same rule.

What two open-source generators actually send

With the RFCs silent, the choice falls to whoever writes the generator. I read the report-sending code of two widely used open-source mail filters that generate aggregate reports.

OpenDMARC builds the message by hand in reports/opendmarc-reports.in. That file has been unchanged on the master branch since May 2018:

$mailout .= "Message-ID: <$report_id>\n";
$mailout .= "Auto-Submitted: auto-generated\n";
$mailout .= "MIME-Version: 1.0\n";

rspamd uses a template in lualib/rspamadm/dmarc_report.lua (last changed July 2026) that sets three suppression headers instead of one:

Auto-Submitted: auto-generated
Precedence: bulk
X-Auto-Response-Suppress: All

Each of the three reaches a different set of responders.

Auto-Submitted is the standard one, from RFC 3834.
Precedence: bulk was never standardised. RFC 3834 says so in as many words, declines to recommend any behaviour for it, and still lists "list", "junk" and "bulk" among the reasons its own example vacation program refuses to reply. Sending it costs nothing and reaches responders that look for it.
X-Auto-Response-Suppress is Microsoft's. The MS-OXCMAIL spec maps it to individual flags: DR, NDR, RN, NRN, OOF and AutoReply. All sets every one of them, so it also asks transport to suppress delivery and non-delivery reports. That is a trade-off for a report generator: a bounce from a dead rua= address is information it may want.

OpenDMARC's code turned up one more thing on the way. It zips the report (IO::Compress::Zip), names it .zip and sends it as application/zip. Both RFC 7489 and RFC 9990 only allow .xml or .xml.gz. That matters to anyone writing the receiving side: a parser that follows RFC 9990 to the letter would reject those reports. Accepting .zip as well costs a few lines.

A script that shows the difference

To make this concrete I wrote a script that builds three report emails, all with an RFC 9990 subject and attachment name, and all using the RFC's own placeholder names (example.com, mail.receiver.example):

one with only the fields RFC 9990 requires,
one with rspamd's three headers,
one shaped like OpenDMARC's output: the header, plus a .zip attachment.

Each one goes through a format check and then a vacation_decision() function. That function applies the personal-responder rules from RFC 3834 section 2 and RFC 5230 sections 4.5 and 4.6, the same way a careful out-of-office implementation would. It is standard library Python, 3.12 here. The subject and filename patterns are lenient readings of the RFC 9990 ABNF, close to the ones in my last post on testing a DMARC report pipeline.

import gzip
import re
from email import policy
from email.message import EmailMessage
from email.parser import BytesParser
from email.utils import getaddresses

RUA = "dmarc-reports@example.com"
SUBMITTER = "mail.receiver.example"

# Lenient reading of the RFC 9990 section 3.5.2 subject and filename rules.
DOMAIN = r"[A-Za-z0-9](?:[A-Za-z0-9.-]*[A-Za-z0-9])?"
SUBJECT_RE = re.compile(
    rf"^Report\s+Domain:\s+({DOMAIN})\s+Submitter:\s+({DOMAIN})"
    r"(?:\s+Report-ID:\s+(<?[^\s<>]+>?))?\s*$"
)
FILENAME_RE = re.compile(
    rf"^({DOMAIN})!({DOMAIN})!(\d+)!(\d+)(?:![A-Za-z0-9]+)?\.(xml|xml\.gz)$"
)
MEDIA_TYPES = {"xml": "text/xml", "xml.gz": "application/gzip"}


def build_report(extra_headers, filename, ctype="application/gzip"):
    msg = EmailMessage()
    msg["From"] = f"DMARC reports <noreply-dmarc@{SUBMITTER}>"
    msg["To"] = RUA
    msg["Subject"] = (f"Report Domain: example.com Submitter: {SUBMITTER} "
                      f"Report-ID: <1792022400.example.com@{SUBMITTER}>")
    msg["Return-Path"] = f"<bounces@{SUBMITTER}>"
    for name, value in extra_headers:
        msg[name] = value
    msg.set_content(f"This is an aggregate report from {SUBMITTER}.")
    payload = gzip.compress(b"<feedback>placeholder</feedback>")
    maintype, subtype = ctype.split("/")
    msg.add_attachment(payload, maintype=maintype, subtype=subtype,
                       filename=filename)
    # Round-trip through bytes so we test what a receiver would parse.
    return BytesParser(policy=policy.default).parsebytes(bytes(msg))


def check_report(msg):
    notes = []
    subject = str(msg["Subject"])
    notes.append("subject ok" if SUBJECT_RE.match(subject)
                 else f"subject does not match: {subject!r}")
    for part in msg.iter_attachments():
        name = part.get_filename() or ""
        m = FILENAME_RE.match(name)
        if not m:
            notes.append(f"filename does not match: {name}")
            continue
        want = MEDIA_TYPES[m.group(5)]
        got = part.get_content_type()
        notes.append("attachment ok" if got == want
                     else f"attachment is {got}, spec says {want}")
    return notes


def suppression_headers(msg):
    return {h: str(msg[h]) for h in
            ("Auto-Submitted", "Precedence", "X-Auto-Response-Suppress")
            if msg[h] is not None}


def vacation_decision(msg, my_addresses):
    """Personal responder rules from RFC 3834 section 2 and RFC 5230 4.5/4.6."""
    auto = str(msg.get("Auto-Submitted", "no")).split(";")[0].strip().lower()
    if auto != "no":
        return f"skip: Auto-Submitted is {auto}"
    if any(h in msg for h in ("List-Id", "List-Unsubscribe", "List-Post")):
        return "skip: mailing list headers"
    if str(msg.get("Precedence", "")).strip().lower() in ("list", "junk", "bulk"):
        return "skip: Precedence (not standard, but common)"
    rp = str(msg.get("Return-Path", "")).strip()
    if rp in ("", "<>"):
        return "skip: null Return-Path"
    local = rp.strip("<>").split("@")[0].lower()
    if local == "mailer-daemon" or local.startswith("owner-") or local.endswith("-request"):
        return "skip: daemon or list address"
    listed = {a.lower() for _, a in getaddresses(
        msg.get_all("To", []) + msg.get_all("Cc", []))}
    if not listed & {a.lower() for a in my_addresses}:
        return "skip: not addressed to me in To/Cc"
    return f"REPLY to {rp}"


SAMPLES = {
    "spec minimum (RFC 9990 fields only)": build_report(
        [], f"{SUBMITTER}!example.com!1791936000!1792022400.xml.gz"),
    "rspamd-style headers": build_report(
        [("Auto-Submitted", "auto-generated"), ("Precedence", "bulk"),
         ("X-Auto-Response-Suppress", "All")],
        f"{SUBMITTER}!example.com!1791936000!1792022400.xml.gz"),
    "opendmarc-style headers": build_report(
        [("Auto-Submitted", "auto-generated")],
        f"{SUBMITTER}!example.com!1791936000!1792022400.zip",
        ctype="application/zip"),
}

for label, msg in SAMPLES.items():
    print(f"== {label}")
    for note in check_report(msg):
        print("  format:", note)
    print("  suppression headers:", suppression_headers(msg) or "none")
    print("  vacation responder:", vacation_decision(msg, [RUA]))

Output:

== spec minimum (RFC 9990 fields only)
  format: subject ok
  format: attachment ok
  suppression headers: none
  vacation responder: REPLY to <bounces@mail.receiver.example>
== rspamd-style headers
  format: subject ok
  format: attachment ok
  suppression headers: {'Auto-Submitted': 'auto-generated', 'Precedence': 'bulk', 'X-Auto-Response-Suppress': 'All'}
  vacation responder: skip: Auto-Submitted is auto-generated
== opendmarc-style headers
  format: subject ok
  format: filename does not match: mail.receiver.example!example.com!1791936000!1792022400.zip
  suppression headers: {'Auto-Submitted': 'auto-generated'}
  vacation responder: skip: Auto-Submitted is auto-generated

The message that follows RFC 9990 to the letter is the one that gets an out-of-office reply, sent to the report generator's bounce address. The other two are skipped on the first test. The OpenDMARC-shaped one also fails the filename check, for the .zip reason above.

The script is a model, not a survey. Real responders differ. Some check Precedence, some only reply once per sender per few days (RFC 3834 recommends 7 days as the default), and some do whatever their vendor decided. The point it makes is narrower: a report that carries only what the DMARC RFCs require gives a standards-following responder no reason to stay quiet.

auto-generated or auto-replied?

Picking the value is less obvious than it looks. RFC 3834 says auto-generated MUST NOT be used on delivery status notifications, message disposition notifications, "or other reports of message (non)receipt or (non)delivery". A DMARC aggregate report is a report about mail, so the clause is worth a second read.

I read it as not covering aggregate reports. Those exclusions are all responses to one specific message: this message bounced, this message was read. An aggregate report is a periodic summary of authentication results across many messages, produced on a timer, which is the cron-job case the RFC gives for auto-generated. It is not a direct response to anything, which is the condition for auto-replied. Both projects above made the same call. A failure report under RFC 9991 is a different shape, since it is about one message, and I have not checked what generators put on those.

If you write either side

If you generate reports, even from a homegrown script that mails a weekly summary for your own domains, set the three headers rspamd sets, or at least Auto-Submitted: auto-generated. It costs one line and the spec will not remind you.

If you write an auto-responder, such as a support-desk acknowledgement or a "we got your message" reply, check Auto-Submitted before anything else and skip anything that is not no. Then check the List-* headers, a null Return-Path, and addresses like MAILER-DAEMON, owner-* and *-request. All of that is in the vacation_decision() function above, in about twenty lines.

If you point rua= at a mailbox a human also uses, know that the safety net here is a header the DMARC RFCs never ask for. The well-behaved generators set it anyway. A small homegrown one may not.

Written with AI assistance from my own notes and test results. I checked every fact and command before publishing.

Testing a DMARC aggregate report pipeline before the first real report arrives

Jose Pollman — Tue, 13 Oct 2026 07:46:08 +0000

The first DMARC aggregate report for a new domain arrives a day or more after you publish the record. It comes from a receiver you do not control, on a schedule you cannot change. If the code that reads those reports has a bug, you find out a day late, and whatever it dropped is gone unless the sender happens to send it again.

Most of that pipeline can be tested today. I split it into three parts: the DNS half that decides whether anyone sends you a report at all, the mail half that carries the file to your code, and the parser. Everything below uses only Python's standard library. Section numbers refer to RFC 9990, which took over aggregate reporting from RFC 7489 in May 2026.

What you cannot speed up

Start with the part no test fixes. RFC 7489 had an ri tag that asked receivers for a reporting interval. It defaulted to 86400 seconds, and anything other than daily was "accommodated on a best-effort basis". RFC 9989, the new DMARC core spec, lists ri under "Tags Removed" and marks it historic in the IANA table. RFC 9990 describes "daily (or more frequent)" reports and says a reporting period will typically "encompass a single UTC day, beginning at 0000UTC".

So the earliest a real report can cover your new record is the UTC day you publish it, and it arrives after that day closes and the receiver gets round to sending. Nothing in your DNS changes that. Which receivers send first, and which never send at all, is outside the spec.

The DNS half: will anyone send at all

A receiver discovers the rua tag when it looks up your DMARC record for mail it received (§3.4). No rua, no reports.

If the rua address is in a different organisational domain from the one publishing the policy, section 4 adds a step. The receiver must look up a TXT record at <policy domain>._report._dmarc.<destination host> and find one that starts with v=DMARC1. If it does not, "the URI MUST be ignored". Nothing tells you this happened. You just get no reports.

That check runs in DNS, so you can run it yourself. This script reads a domain's DMARC record, and for each rua destination on another domain it queries the authorisation name through Google's DNS-over-HTTPS JSON API. It also queries a name that cannot exist under the destination, to see whether the destination publishes a wildcard, which section 4 explicitly allows (*._report._dmarc.example.com).

import json
import sys
import urllib.request


def txt(name):
    url = f"https://dns.google/resolve?name={name}&type=TXT"
    with urllib.request.urlopen(url) as r:
        d = json.load(r)
    return d["Status"], [a["data"].strip('"') for a in d.get("Answer", []) if a["type"] == 16]


def check(domain):
    _, records = txt(f"_dmarc.{domain}")
    dmarc = next(r for r in records if r.startswith("v=DMARC1"))
    tags = dict(p.strip().split("=", 1) for p in dmarc.split(";") if "=" in p)
    uris = [u for u in tags.get("rua", "").split(",") if u.strip()]
    if not uris:
        print("no rua tag: nobody will send you aggregate reports")
    for uri in uris:
        host = uri.strip().split("@", 1)[1]
        # crude org-domain test: last two labels; good enough for .com/.org/.net
        if host.split(".")[-2:] == domain.split(".")[-2:]:
            print(f"{uri.strip()}: same organisation, no check needed")
            continue
        status, ok = txt(f"{domain}._report._dmarc.{host}")
        _, wild = txt(f"zz-not-a-real-name.invalid._report._dmarc.{host}")
        print(f"{uri.strip()}: authorised={any(r.startswith('v=DMARC1') for r in ok)} "
              f"(status {status}), wildcard={bool(wild)}")


for d in sys.argv[1:]:
    print(f"== {d}")
    check(d)

Run on 13 October 2026 at 07:41 UTC:

== mozilla.org
mailto:dmarc_agg@vali.email: authorised=True (status 0), wildcard=True
mailto:dmarc@mozilla.com: authorised=True (status 0), wildcard=False
== wikipedia.org
mailto:dmarc-rua@wikimedia.org: authorised=True (status 0), wildcard=False
== stackoverflow.com
mailto:dmarc-aggregates@stackoverflow.com: same organisation, no check needed
== example.com
no rua tag: nobody will send you aggregate reports

status 0 is NOERROR. Two patterns show up. The hosted reporting address answers for a made-up name too, so it publishes a wildcard and any domain pointing at it passes. Two other hosted report addresses I queried the same morning behaved the same way. The organisations that receive their own reports on a sister domain publish one record per domain: mozilla.org._report._dmarc.mozilla.com exists, and the made-up name under mozilla.com came back NXDOMAIN.

The second pattern is the one to test if you run your own report mailbox. Add a new sending domain, forget its record on the receiving domain, and that domain's reports stop before they start. The organisational-domain comparison in the script is the crude last-two-labels version. RFC 9989 uses a DNS tree walk, so replace it before you trust the script on something like a .co.uk domain.

The mail half: build the message a receiver would send

Section 3.5.2 is specific about the envelope. The XML SHOULD be gzipped and sent as application/gzip (text/xml if it is not compressed). The attachment filename follows an ABNF: receiver!policy-domain!begin!end[!unique-id].xml[.gz]. The subject follows another: Report Domain: <domain> Submitter: <receiver>, with an optional Report-ID: after it. A re-sent report MUST use the same filename as the original.

That is enough to build a realistic message locally. This half of the script writes a report in the RFC 9990 namespace, gzips it and attaches it to an EmailMessage the way a receiver would:

"""Build an RFC 9990 DMARC aggregate report, mail it to yourself in memory,
and push it through the same ingest path a real report would take.
Standard library only. Run: python3 dmarc_agg_test.py
"""
import gzip
import re
import xml.etree.ElementTree as ET
from email import message_from_bytes, policy
from email.message import EmailMessage

NS = "urn:ietf:params:xml:ns:dmarc-2.0"


def build_report(policy_domain, receiver, begin, end, rows, ns=NS, with_selector=True):
    q = (lambda t: f"{{{ns}}}{t}") if ns else (lambda t: t)
    if ns:
        ET.register_namespace("", ns)

    def sub(parent, tag, text=None):
        el = ET.SubElement(parent, q(tag))
        if text is not None:
            el.text = str(text)
        return el

    root = ET.Element(q("feedback"))
    sub(root, "version", "1.0")
    md = sub(root, "report_metadata")
    sub(md, "org_name", receiver)
    sub(md, "email", f"dmarc-noreply@{receiver}")
    report_id = f"{begin}-{policy_domain}@{receiver}"
    sub(md, "report_id", report_id)
    dr = sub(md, "date_range")
    sub(dr, "begin", begin)
    sub(dr, "end", end)
    pp = sub(root, "policy_published")
    sub(pp, "domain", policy_domain)
    sub(pp, "p", "none")
    for ip, count, dkim, spf in rows:
        rec = sub(root, "record")
        row = sub(rec, "row")
        sub(row, "source_ip", ip)
        sub(row, "count", count)
        pe = sub(row, "policy_evaluated")
        sub(pe, "disposition", "none")
        sub(pe, "dkim", dkim)
        sub(pe, "spf", spf)
        ids = sub(rec, "identifiers")
        sub(ids, "header_from", policy_domain)
        ar = sub(rec, "auth_results")
        d = sub(ar, "dkim")
        sub(d, "domain", policy_domain)
        if with_selector:
            sub(d, "selector", "s1")
        sub(d, "result", dkim)
        s = sub(ar, "spf")
        sub(s, "domain", policy_domain)
        sub(s, "result", spf)
    return report_id, ET.tostring(root, xml_declaration=True, encoding="utf-8")


def wrap_in_email(xml_bytes, policy_domain, receiver, begin, end, report_id, rua):
    msg = EmailMessage()
    msg["From"] = f"dmarc-noreply@{receiver}"
    msg["To"] = rua
    msg["Subject"] = (f"Report Domain: {policy_domain} Submitter: {receiver} "
                      f"Report-ID: <{report_id}>")
    msg.set_content("DMARC aggregate report attached.")
    filename = f"{receiver}!{policy_domain}!{begin}!{end}.xml.gz"
    msg.add_attachment(gzip.compress(xml_bytes), maintype="application",
                       subtype="gzip", filename=filename)
    return msg.as_bytes()

Building the whole message, and not just the XML, means the ingest code gets exercised from the same entry point a real report hits: subject, attachment, filename, decompression, then parsing.

The parser, and three cases to test it against

Here is the ingest side:

FILENAME = re.compile(
    r"^(?P<receiver>[^!]+)!(?P<domain>[^!]+)!(?P<begin>\d+)!(?P<end>\d+)"
    r"(?:![A-Za-z0-9]+)?\.(?P<ext>xml|xml\.gz)$")
SUBJECT = re.compile(r"^Report\s+Domain:\s+(\S+)\s+Submitter:\s+(\S+)"
                     r"(?:\s+Report-ID:\s+(\S+))?$")


def local(tag):
    return tag.rsplit("}", 1)[-1]


def kids(el, name):
    return [c for c in el if local(c.tag) == name]


def one(el, name):
    found = kids(el, name)
    if len(found) != 1:
        raise ValueError(f"<{local(el.tag)}> needs exactly one <{name}>, has {len(found)}")
    return found[0]


def parse_report(xml_bytes):
    root = ET.fromstring(xml_bytes)
    if local(root.tag) != "feedback":
        raise ValueError(f"root is <{local(root.tag)}>, not <feedback>")
    ns = root.tag[1:].split("}")[0] if root.tag.startswith("{") else None
    warnings = []
    md = one(root, "report_metadata")
    dr = one(md, "date_range")
    pp = one(root, "policy_published")
    out = {
        "namespace": ns,
        "org": one(md, "org_name").text,
        "report_id": one(md, "report_id").text,
        "begin": int(one(dr, "begin").text),
        "end": int(one(dr, "end").text),
        "domain": one(pp, "domain").text,
        "p": one(pp, "p").text,
        "rows": [],
    }
    records = kids(root, "record")
    if not records:
        raise ValueError("no <record>; RFC 9990 requires at least one")
    for rec in records:
        row = one(rec, "row")
        pe = one(row, "policy_evaluated")
        for d in kids(one(rec, "auth_results"), "dkim"):
            if not kids(d, "selector"):
                warnings.append("dkim result without <selector> (required since RFC 9990)")
        out["rows"].append((one(row, "source_ip").text, int(one(row, "count").text),
                            one(pe, "dkim").text, one(pe, "spf").text))
    return out, warnings


seen = set()


def ingest(raw_message):
    msg = message_from_bytes(raw_message, policy=policy.default)
    m = SUBJECT.match(" ".join(str(msg["Subject"]).split()))
    if not m:
        return f"skip: subject does not match RFC 9990: {msg['Subject']!r}"
    for part in msg.iter_attachments():
        name = part.get_filename() or ""
        fn = FILENAME.match(name)
        if not fn:
            return f"skip: attachment name does not match RFC 9990: {name!r}"
        data = part.get_content()
        if fn["ext"] == "xml.gz":
            data = gzip.decompress(data)
        report, warnings = parse_report(data)
        key = (fn["receiver"], report["report_id"])
        if key in seen:
            return f"duplicate, ignored: {key}"
        seen.add(key)
        return report, warnings
    return "skip: no attachment"

The namespace

RFC 9990 reports put every element in urn:ietf:params:xml:ns:dmarc-2.0. The schema in RFC 7489 declared a different target namespace, http://dmarc.org/dmarc-xml/0.1. ElementTree's find("report_metadata") only matches the un-namespaced name, so on an RFC 9990 report it returns None, and a parser written that way sees an empty report and moves on. Matching on the local name works whichever namespace a report carries, or none.

Re-sent reports

Section 3.5.4 leaves duplicate handling to the report consumer but requires senders to reuse their identifiers when they re-send. Key your store on the receiver and the report_id, and a second copy becomes a no-op instead of doubled counts.

Old-format reports

RFC 9990 made <selector> required inside a DKIM result (its Appendix C: "Selector is now required when reporting a DKIM signature"). Receivers will not all move to the new format on the same day. A parser that rejects a report over a missing selector throws away a day of data from that receiver over a field you can live without, so this one records a warning and keeps the rows.

The test driver exercises all three:

if __name__ == "__main__":
    begin, end = 1791763200, 1791849599          # 2026-10-12 00:00:00 to 23:59:59 UTC
    rows = [("192.0.2.10", 41, "pass", "pass"), ("198.51.100.7", 3, "fail", "fail")]
    rid, xml_bytes = build_report("example.com", "mx.receiver.example", begin, end, rows)

    root = ET.fromstring(xml_bytes)
    print("naive find():", root.find("report_metadata"))
    print("local-name match:", one(root, "report_metadata").tag)

    raw = wrap_in_email(xml_bytes, "example.com", "mx.receiver.example", begin, end,
                        rid, "dmarc@example.com")
    print("first ingest:", ingest(raw))
    print("re-sent copy:", ingest(raw))

    rid2, old_style = build_report("example.org", "mx.receiver.example", begin, end,
                                   rows[:1], ns=None, with_selector=False)
    raw2 = wrap_in_email(old_style, "example.org", "mx.receiver.example", begin, end,
                         rid2, "dmarc@example.org")
    print("no namespace, no selector:", ingest(raw2))

Output:

naive find(): None
local-name match: {urn:ietf:params:xml:ns:dmarc-2.0}report_metadata
first ingest: ({'namespace': 'urn:ietf:params:xml:ns:dmarc-2.0', 'org': 'mx.receiver.example', 'report_id': '1791763200-example.com@mx.receiver.example', 'begin': 1791763200, 'end': 1791849599, 'domain': 'example.com', 'p': 'none', 'rows': [('192.0.2.10', 41, 'pass', 'pass'), ('198.51.100.7', 3, 'fail', 'fail')]}, [])
re-sent copy: duplicate, ignored: ('mx.receiver.example', '1791763200-example.com@mx.receiver.example')
no namespace, no selector: ({'namespace': None, 'org': 'mx.receiver.example', 'report_id': '1791763200-example.org@mx.receiver.example', 'begin': 1791763200, 'end': 1791849599, 'domain': 'example.org', 'p': 'none', 'rows': [('192.0.2.10', 41, 'pass', 'pass')]}, ['dkim result without <selector> (required since RFC 9990)'])

I also fed parse_report the sample report from RFC 9990 Appendix B, unchanged. It came back as one row: 192.0.2.123, count 123, DKIM pass, SPF fail, no warnings.

The schema in Appendix A also settles which order rules matter. Only a few containers use xs:sequence, where order matters: feedback, record, policy_evaluated, auth_results and the extension wrapper. The rest, including report_metadata, policy_published, row and the DKIM and SPF results, use xs:all, where any order is valid. The RFC's own sample puts discovery_method last in policy_published, while the table in §3.1.1.5 lists it second, and that is fine. A parser that reads children by position will break on reports that are perfectly valid.

What this does not test

It does not validate against the XSD. The standard library cannot do that. It does not prove that a given receiver will send to you, or how soon, or what it will put in <error> when your record is malformed. And section 3.3 warns that a report covering a day when you changed your policy may mix the old and new policy under a single policy_published. If you change p= mid-day, expect the next reports to look inconsistent, and do not go hunting for a bug in your parser.

What it does give you is a pipeline that has already handled a namespaced report, an old-style one, a re-send and the spec's own sample before any receiver sends you anything. When the first real report lands, the only unknown left is the data in it.

Written with AI assistance from my own notes and test results. I checked every fact and command before publishing.

Bounding a proprietary blend on a supplement label with two inequalities

Jose Pollman — Sun, 11 Oct 2026 15:19:37 +0000

A supplement label can hide how much of an ingredient is in the tub. It lists a "proprietary blend" with one total weight and a column of names under it, and no amount next to any of them. I run a label checker for pre-workout powders. The easy thing for a checker to do is mark every one of those lines "hidden" and move on. That's accurate, but not very useful.

It turns out the US labelling rule gives you more than nothing. With the blend's total weight and the order of the names, you can put hard limits on each ingredient. This post is the arithmetic, about 30 lines of Python, and what the limits can and can't tell you.

What the label rule gives you

The rule is 21 CFR 101.36, the federal regulation for the Supplement Facts panel. Two parts of paragraph (c) matter here (full text at Cornell LII).

Paragraph (c)(2) says the dietary ingredients in the blend "shall be declared in descending order of predominance by weight". Heaviest first.

Paragraph (c)(3) says the amount printed next to the blend's name "shall be the total weight of all other dietary ingredients contained in the proprietary blend".

So for every blend you get two facts: the total, and the order. That's enough for two inequalities.

Two inequalities

Say a blend has k ingredients and a total weight T, listed heaviest first.

The first ingredient is at least T / k. It weighs at least as much as each of the others, so k copies of it weigh at least T. If it weighed less than T / k, the whole blend would weigh less than T.

The ingredient in position n is at most T / n. The n ingredients from the top down to it each weigh at least as much as it does. Together they can't weigh more than T, so n copies of it can't either.

Everything after position 1 has a lower limit of zero. The label allows the first ingredient to take almost all the weight.

The code

UNITS_TO_MG = {"mg": 1.0, "g": 1000.0, "mcg": 0.001, "µg": 0.001, "ug": 0.001}


def to_mg(amount, unit):
    """Convert a label amount to milligrams."""
    return amount * UNITS_TO_MG[unit.strip().lower()]


def blend_bounds(total_mg, k):
    """Bounds for each position in a blend of k ingredients listed heaviest
    first, when the label only gives the blend's total weight."""
    bounds = []
    for n in range(1, k + 1):
        low = total_mg / k if n == 1 else 0.0
        high = total_mg / n
        bounds.append((n, low, high))
    return bounds


def compare(low_mg, high_mg, studied_mg):
    """What the bound can and can't say against a research dose."""
    if high_mg < studied_mg:
        return "below the studied dose, even at the most the label allows"
    if low_mg >= studied_mg:
        return "at or above the studied dose, even at the least the label allows"
    return "can't tell from the label"

to_mg exists because labels mix units. A blend total in grams and a research dose in milligrams is the easiest way to be wrong by a factor of 1,000.

compare has three answers, not two. That's the important part. A range is not an amount, so most of the time the honest answer is the third one.

Running it on a real label

One best-selling pre-workout lists a 6,603 mg blend of eight ingredients, with beta-alanine first. Studies on beta-alanine used 3.2 to 6.4 g a day, so the low end is 3,200 mg.

total = to_mg(6603, "mg")
n, low, high = blend_bounds(total, 8)[0]
print(f"position {n}: {low:.0f} mg to {high:.0f} mg ->",
      compare(low, high, to_mg(3.2, "g")))

position 1: 825 mg to 6603 mg -> can't tell from the label

Beta-alanine is somewhere between 825 mg and the whole 6,603 mg. The studied dose sits inside that range, so the label can't say which side of it the product is on. The checker leaves that line as "hidden in a blend" rather than guessing.

When the limit does decide

The upper limit becomes useful further down the list. Here is a made-up label to show it: a 2 g blend of five ingredients, with citrulline third. Studies on citrulline used about 4 g.

total = to_mg(2, "g")
n, low, high = blend_bounds(total, 5)[2]
print(f"position {n}: {low:.0f} mg to {high:.0f} mg ->",
      compare(low, high, to_mg(4, "g")))

for n, low, high in blend_bounds(total, 5):
    print(f"  #{n}: {low:7.1f} to {high:7.1f} mg")

position 3: 0 mg to 667 mg -> below the studied dose, even at the most the label allows
  #1:   400.0 to  2000.0 mg
  #2:     0.0 to  1000.0 mg
  #3:     0.0 to   666.7 mg
  #4:     0.0 to   500.0 mg
  #5:     0.0 to   400.0 mg

Third in a 2 g blend means at most 667 mg. That's below 4 g whatever the real number is, so here the label settles it without disclosing anything.

The further down the list and the smaller the blend, the lower that ceiling gets: position n can never hold more than T / n.

How often this comes up

For the checker I read Amazon's pre-workout best-seller list, ranks 1 to 100, and checked the 52 that were multi-ingredient powders with a label I could confirm. 16 of the 52 (31%) put at least one ingredient in a blend without its amount. Across all 670 ingredient lines on those labels, 164 (24.5%) sat inside a blend with no amount.

So about a quarter of the lines on a best-selling pre-workout label are lines where these two inequalities are the only arithmetic available.

What the limits don't tell you

They're limits, not amounts. "825 mg to 6,603 mg" is the honest output. Showing the midpoint, or the maximum, as if it were the amount would be inventing a number. The checker only uses the ceiling: when even the maximum is below the studied dose, it says so, and everything else stays "hidden in a blend".

They assume the listed names make up the whole total. That's what (c)(3) says the number is: the weight of the dietary ingredients in the blend. If a label prints a total that doesn't match its list, the limits inherit the error.

They describe the label, not the powder. Every number here is what the manufacturer printed. Whether the tub matches is a lab question. When NOW Foods tested 12 brands of creatine gummies in 2024, 6 failed their label claim (Nutritional Outlook's report), and no amount of label arithmetic would have caught that.

Servings multiply everything. If the directions say two scoops, the blend total, the limits and every other ingredient double together. The checker computes per serving as printed and lets you change the number of scoops.

Nested blends need care. Some labels put a blend inside a blend. The inner blend's total is itself bounded by its position in the outer list, so the limits stack, and a parser that treats every indented line the same way gets them wrong.

The short version

Heaviest first plus a total gives you T / k as a floor for the first ingredient and T / n as a ceiling for the one in position n. Most of the time that still isn't enough to know the dose, and the right output is "can't tell". Sometimes, especially for small blends with long lists, the ceiling alone shows the dose can't reach what studies used. That case is worth computing, because the label has already answered the question without meaning to.

Written with AI assistance from my own notes and test results. I checked every fact and command before publishing.

Reading a vendor's email and HTTPS setup from DNS before you sign

Jose Pollman — Thu, 08 Oct 2026 07:58:04 +0000

Before a vendor gets to send mail as your domain, or hosts a login page your team will type passwords into, there are six things you can check yourself in about a minute: where their mail goes, who is allowed to send as them, what they ask receivers to do with forged mail, whether they require TLS for mail coming in, whether anyone reads the reports when that TLS fails, and whether their web hosts insist on HTTPS. All six are public, and none of them needs the vendor's cooperation.

This is a capability check, not a verdict. A missing record tells you a protection is absent. It does not tell you why, and it says nothing about how a company handles your data internally. What it does give you is a short list of specific questions, which gets better answers than a generic security questionnaire.

No dig required

The machine I wrote this on has no dig, so everything below goes through DNS over HTTPS instead. Google Public DNS answers plain GET requests with JSON:

curl -s "https://dns.google/resolve?name=_dmarc.google.com&type=TXT"

{"Status":0,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,"Question":[{"name":"_dmarc.google.com.","type":16}],"Answer":[{"name":"_dmarc.google.com.","type":16,"TTL":300,"data":"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"}],"Comment":"Response from 216.239.34.10."}

Status is the ordinary DNS response code (Google documents the format here): 0 is NOERROR, 3 is NXDOMAIN. A name with no record of the type you asked for comes back as 0 with no Answer array. In principle that differs from a name that does not exist at all, but some zones answer 0 even for names nobody created (a made-up name under example.com got 0 that morning), so the script prints the status and treats both as "none".

The script

Standard library only, Python 3, 68 lines. It looks up the five DNS records, fetches the MTA-STS policy file if the record says there is one, and walks the HTTPS redirect chain without following it automatically, so you see the HSTS header on every hop rather than only the last one.

import json, sys, urllib.request, urllib.error
from urllib.parse import urljoin

def doh(name, rtype):
    url = f"https://dns.google/resolve?name={name}&type={rtype}"
    with urllib.request.urlopen(url, timeout=10) as r:
        data = json.load(r)
    if data["Status"] == 3:
        return "NXDOMAIN", []
    want = {"TXT": 16, "MX": 15, "A": 1, "AAAA": 28}[rtype]
    answers = [a["data"] for a in data.get("Answer", []) if a["type"] == want]
    if rtype == "TXT":
        answers = [a.strip('"').replace('" "', "") for a in answers]
    return "NOERROR", answers

def record(name, prefix):
    status, answers = doh(name, "TXT")
    found = [a for a in answers if a.lower().startswith(prefix)]
    return found[0] if found else f"none ({status})"

class NoRedirect(urllib.request.HTTPRedirectHandler):
    def redirect_request(self, *args, **kwargs):
        return None

opener = urllib.request.build_opener(NoRedirect)

def hsts_chain(url, hops=5):
    for _ in range(hops):
        req = urllib.request.Request(url, method="HEAD")
        try:
            resp = opener.open(req, timeout=10)
        except urllib.error.HTTPError as e:
            resp = e
        print(f"  {resp.status} {url}")
        print(f"      HSTS: {resp.headers.get('Strict-Transport-Security', 'none')}")
        location = resp.headers.get("Location")
        if resp.status not in (301, 302, 303, 307, 308) or not location:
            return
        url = urljoin(url, location)

def mta_sts_policy(domain):
    host = f"mta-sts.{domain}"
    if not (doh(host, "A")[1] or doh(host, "AAAA")[1]):
        return f"{host} has no A or AAAA record"
    try:
        with urllib.request.urlopen(f"https://{host}/.well-known/mta-sts.txt", timeout=10) as r:
            body = r.read().decode()
    except Exception as e:
        return f"fetch failed: {e}"
    modes = [l.strip() for l in body.splitlines() if l.startswith("mode:")]
    return modes[0] if modes else "no mode line"

def check(domain):
    print(f"== {domain}")
    status, mx = doh(domain, "MX")
    print("MX      ", sorted(mx) or f"none ({status})")
    print("SPF     ", record(domain, "v=spf1"))
    print("DMARC   ", record(f"_dmarc.{domain}", "v=dmarc1"))
    sts = record(f"_mta-sts.{domain}", "v=stsv1")
    print("MTA-STS ", sts)
    if not sts.startswith("none"):
        print("  policy", mta_sts_policy(domain))
    print("TLS-RPT ", record(f"_smtp._tls.{domain}", "v=tlsrptv1"))
    print("HTTPS   ")
    hsts_chain(f"https://{domain}/")

for d in sys.argv[1:]:
    check(d)

Here is what it printed for google.com on the morning of 8 October 2026:

$ python3 vendorcheck.py google.com
== google.com
MX       ['10 smtp.google.com.']
SPF      v=spf1 include:_spf.google.com ~all
DMARC    v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com
MTA-STS  v=STSv1; id=20210803T010101;
  policy mode: enforce
TLS-RPT  v=TLSRPTv1;rua=mailto:sts-reports@google.com
HTTPS
  301 https://google.com/
      HSTS: none
  200 https://www.google.com/
      HSTS: none

Every mail record is present and the MTA-STS policy is in enforce mode. Neither HTTPS response carries an HSTS header, which I come back to below.

What each line tells you, and what it does not

MX

Who receives their mail. Usually this names the provider outright (*.mail.protection.outlook.com, smtp.google.com, and so on), which tells you whose security model their inbox inherits. A single MX of 0 . is a null MX, defined in RFC 7505 as the way a domain says it accepts no mail at all.

SPF

Which servers may send mail using the domain in the envelope sender. The all term at the end matters less than it looks. ~all is softfail, which RFC 7208 calls "a weak statement", and google.com uses it. That is not a weakness on its own, because DMARC sits on top: under RFC 9989, the current DMARC spec, a message only passes DMARC with an SPF or DKIM pass that is aligned with the From domain. A softfail is not a pass. With p=reject behind it, ~all is fine.

DMARC

What the domain asks receivers to do with mail that fails. RFC 9989 defines three values for p=. none means "the Domain Owner offers no expression of preference", quarantine means the mail is suspicious, and reject means a failure is a clear sign the domain is being misused. If a vendor will send invoices or password resets on your behalf, p=none is the line worth asking about, because forged mail claiming to be them gets no instruction at all.

MTA-STS

This one has two parts, and checking only the first gives a wrong answer. The TXT record at _mta-sts.<domain> only announces that a policy exists. The policy itself is a text file at https://mta-sts.<domain>/.well-known/mta-sts.txt, and its mode line is what changes sender behaviour. RFC 8461 defines three modes. In enforce, sending servers must not deliver to an MX that fails certificate validation or does not offer STARTTLS. In testing, they deliver anyway and report the failure. none means no active policy.

The reason the script fetches the file: one large domain I checked the same morning publishes a valid v=STSv1 TXT record, but its mta-sts. host returns no A and no AAAA record at either Google or Cloudflare DNS. The output looked like this:

MTA-STS  v=STSv1;id=<redacted>;
  policy mta-sts.<redacted> has no A or AAAA record

RFC 8461 section 3.3 covers exactly this case: "If a valid TXT record is found but no policy can be fetched via HTTPS (for any reason), and there is no valid (non-expired) previously cached policy, senders MUST continue with delivery as though the domain has not implemented MTA-STS." So a checker that stops at the TXT record reports MTA-STS as deployed when a sender without a cached policy would treat it as absent. I am not naming the domain because I don't know whether this is a mistake, a policy that was retired with the TXT record left behind, or something mid-migration. It goes on the list of questions to ask.

TLS-RPT

A TXT record at _smtp._tls.<domain> (RFC 8460) tells other mail servers where to send reports about TLS failures when they deliver to this domain. Its presence means someone has at least set up a mailbox for those reports. It does not prove anyone reads them.

HSTS, which is per host

Strict-Transport-Security tells a browser to refuse plain HTTP for that host for the next max-age seconds. RFC 6797 only lets a site send it over HTTPS, and it applies to the host that sent it plus subdomains if includeSubDomains is set.

google.com sends no HSTS header on the redirect or on www.google.com. That looks bad until you check the host where the password actually goes:

  302 https://accounts.google.com/
      HSTS: max-age=31536000; includeSubDomains

There is also a second route to HSTS that no header check can see: the preload list built into browsers (RFC 6797 section 12.3 describes the idea). Chromium's list is a JSON file in its source tree, net/http/transport_security_state_static.json. I downloaded it on the same morning and searched it. It has entries for accounts.google.com and mail.google.com, and none for google.com or www.google.com.

So for a vendor, run the HTTPS check against the login host and the API host you will actually use, not the marketing domain. A missing header on the home page and a preloaded login domain can both be true at the same company.

A reference point: a domain that sends no mail

It helps to see what a domain that does no email at all should look like. example.com, reserved for documentation by RFC 2606, is a clean example. The mail lines from the same run:

== example.com
MX       ['0 .']
SPF      v=spf1 -all
DMARC    v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s
MTA-STS  none (NOERROR)
TLS-RPT  none (NOERROR)

Null MX, an SPF record that authorises nobody, and DMARC set to reject with strict alignment. No MTA-STS or TLS-RPT, which is correct for a domain that accepts no mail. If a vendor has extra domains they use only for marketing pages, this is the setup you would hope to see on them, because without these records nothing tells a receiver that mail from that domain should not exist.

What this does not check

DKIM: you cannot list a domain's DKIM keys from DNS. You need a selector, and the only reliable place to get one is the s= tag in the DKIM-Signature header of a real message from them. Ask them to send you one.
Whether the SPF includes are current: an include: for a service they dropped two years ago still authorises that service to send as them.
DNSSEC, CAA and security.txt: each needs its own lookup, and they are left out to keep the script short.
Anything internal: access control, logging, how they store your data. DNS cannot see any of it.

Questions this gives you

From one run you get specific questions instead of a questionnaire. Why is DMARC at p=none? Is the MTA-STS policy meant to be live? Which host serves the login page, and does it send HSTS? Can you send us a message from your production mail system so we can check the DKIM signature?

Written with AI assistance from my own notes and test results. I checked every fact and command before publishing.

The IETF datatracker never sets rfc_number on a draft: fixing my status check and running it on DKIM2

Jose Pollman — Tue, 06 Oct 2026 09:06:37 +0000

In an earlier post I wrote a short Python function that asks the IETF datatracker six questions about an Internet-Draft and counts the yes answers. I re-ran it three weeks later and two of its answers were wrong. One field does not mean what its name says. Another changes earlier than I said it does. This post fixes both, then runs the fixed version against every draft the DKIM working group has ever had.

Bug one: rfc_number is null on every draft

The old function counted a draft as published when rfc_number was not null. On 13 September it printed this for the DMARC working group's draft:

draft-ietf-dmarc-dmarcbis-41  (83 pages, expires 2025-10-06)
  ...
  no   published as an RFC
  5/6 signals present

That draft had been published as RFC 9989 on 20 May 2026. The RFC Editor's record lists draft-ietf-dmarc-dmarcbis-41 as its source and RFC 7489 and RFC 9091 as the documents it obsoletes.

The datatracker stores an RFC as its own document record, named rfc9989. That record has rfc_number set. The draft that became it never does. You can see the scale of it with one request:

import json
import urllib.request

API = "https://datatracker.ietf.org/api/v1"

def get(path):
    sep = "&" if "?" in path else "?"
    with urllib.request.urlopen(f"{API}{path}{sep}format=json") as r:
        return json.load(r)

docs = get("/doc/document/?name__startswith=draft-ietf-dkim-&limit=100")["objects"]
print(len(docs), "drafts,", sum(d["rfc_number"] is not None for d in docs), "with rfc_number set")

16 drafts, 0 with rfc_number set

Nine of those sixteen are published RFCs. The link from a draft to its RFC lives in a separate table, under the relationship became_rfc:

rels = get("/doc/relateddocument/?source__name=draft-ietf-dmarc-dmarcbis&relationship__slug=became_rfc")
print(rels["objects"][0]["target"])

/api/v1/doc/document/rfc9989/

There is a cheaper tell on the draft itself. Its states list includes one state of the type draft, and that state's slug is active, expired or rfc. So the fixed check reads the state first and only makes the second request when it says rfc.

The earlier post also said that once rfc_number is set, "the draft is history". On a draft record it is never set, so that sentence described something that does not happen.

Bug two: stream is set at the call for adoption

The earlier post said that when stream stops being null, the document has been adopted. Its example of a draft with nothing going for it yet was draft-brotman-aggregate-performance-reporting. Here are its latest three events:

events = get("/doc/docevent/?doc__name=draft-brotman-aggregate-performance-reporting&limit=3")
for e in events["objects"]:
    print(e["time"][:10], e["desc"])

2026-09-24 IETF WG state changed to <b>Call For Adoption By WG Issued</b>
2026-09-24 Changed group to <b>Mail Maintenance (MAILMAINT)</b>
2026-09-24 Changed stream to <b>IETF</b>

On 24 September a call for adoption went out in the mailmaint working group, and the stream, the group and the working group state all changed in the same second. The name still starts with draft-brotman-. Nothing has been adopted. A call for adoption is a question to the group, and the answer can be no.

So a non-null stream means a working group is either considering the document or already owns it. The state of type draft-stream-ietf says which. These are the slugs worth knowing:

c-adopt   Call For Adoption By WG Issued
wg-doc    WG Document
sub-pub   Submitted to IESG for Publication
dead      Dead WG Document

The fixed version drops the old "name contains ietf" signal, because the stream state answers the same question with more detail, and prints that state as its own column.

The fixed check

_states = {}

def states(doc):
    """Return {state type: slug}, e.g. {'draft': 'rfc', 'draft-stream-ietf': 'wg-doc'}."""
    out = {}
    for uri in doc["states"]:
        if uri not in _states:
            s = get(uri.removeprefix("/api/v1"))
            _states[uri] = (s["type"].rstrip("/").split("/")[-1], s["slug"])
        kind, slug = _states[uri]
        out[kind] = slug
    return out

def became_rfc(name):
    rels = get(f"/doc/relateddocument/?source__name={name}&relationship__slug=became_rfc")["objects"]
    return rels[0]["target"].rstrip("/").split("/")[-1] if rels else None

def row(doc):
    st = states(doc)
    rfc = became_rfc(doc["name"]) if st.get("draft") == "rfc" else None
    signals = [
        doc["stream"] is not None,
        doc["intended_std_level"] is not None,
        doc["ad"] is not None,
        doc["shepherd"] is not None,
        rfc is not None,
    ]
    return (f"{doc['name']:<38} {doc['rev']:>3}  {doc['time'][:10]}  "
            f"{st.get('draft', '-'):<8} {st.get('draft-stream-ietf', '-'):<8} "
            f"{sum(signals)}/5  {rfc or ''}")

def group_report(prefix):
    docs = get(f"/doc/document/?name__startswith={prefix}&limit=100")["objects"]
    for doc in sorted(docs, key=lambda d: d["time"], reverse=True):
        print(row(doc))

group_report("draft-ietf-dkim-")

State lookups are cached because the same dozen state URIs repeat across every document.

Running it on a whole working group

name__startswith returns every draft under a prefix, so one request covers a working group's whole history. Output on 6 October 2026:

draft-ietf-dkim-dkim2-bcp               01  2026-09-09  active   wg-doc   1/5
draft-ietf-dkim-dkim2-spec              06  2026-08-28  active   wg-doc   1/5
draft-ietf-dkim-dkim2-dns               00  2026-07-20  active   wg-doc   1/5
draft-ietf-dkim-dkim2-header            00  2026-05-07  expired  dead     1/5
draft-ietf-dkim-dkim2-motivation        02  2026-05-06  expired  wg-doc   1/5
draft-ietf-dkim-replay-problem          00  2024-01-29  expired  -        0/5
draft-ietf-dkim-mailinglists            12  2020-01-21  rfc      wg-doc   5/5  rfc6377
draft-ietf-dkim-rfc4871bis              15  2020-01-21  rfc      sub-pub  5/5  rfc6376
draft-ietf-dkim-base                    10  2020-01-21  rfc      wg-doc   4/5  rfc4871
draft-ietf-dkim-rfc4871-errata          07  2015-10-14  rfc      wg-doc   4/5  rfc5672
draft-ietf-dkim-deployment              11  2015-10-14  rfc      -        4/5  rfc5863
draft-ietf-dkim-overview                12  2015-10-14  rfc      -        4/5  rfc5585
draft-ietf-dkim-ssp-requirements        05  2015-10-14  rfc      -        4/5  rfc5016
draft-ietf-dkim-threats                 03  2015-10-14  rfc      -        4/5  rfc4686
draft-ietf-dkim-ssp                     10  2015-10-14  rfc      -        4/5  rfc5617
draft-ietf-dkim-implementation-report   06  2011-03-28  expired  dead     2/5

The columns are name, revision, the record's time, draft state, working group state, signals out of five (stream, intended status, AD, shepherd, RFC) and the RFC it became.

The prefix spans two eras. The bottom ten rows are the first DKIM working group, which produced RFC 4871 in May 2007 and its replacement, RFC 6376, in September 2011. The top five rows are DKIM2, and replay-problem from January 2024 sits between the two. All of them share one name prefix and one group record.

The time column is not a history. draft-ietf-dkim-base became RFC 4871 in 2007 and its record says 2020-01-21. Six records share 2015-10-14. Those are the dates the database rows were last touched. For when something happened, read the event log or the RFC.

Most of the old RFCs score 4/5 because their shepherd field is empty, while two from the same group have one. Treat a missing field on an old published record as missing data, not as a signal.

Every DKIM2 row scores 1/5: on the IETF stream, with no intended status, no AD and no shepherd yet. Two of the five have expired. The motivation document is still marked as a WG document, while the header document is marked dead.

The group record has its own history

The group's state changes and closing notes come from the same API:

for e in get("/group/groupevent/?group__acronym=dkim&type=changed_state&limit=20")["objects"]:
    print(e["time"][:10], e["desc"])

2025-02-20 Charter approved, group active
2024-01-18 State changed to <b>Concluded</b> from Active
2023-02-21 Charter approved, group active
2011-09-26 Concluded group
2006-01-05 Started group
2005-10-01 Proposed group

The closing note from January 2024, read with type=closing_note, says: "WG closing without coming to consensus on even its first deliverable. Little to no activity in several months." The current charter came a year later. Its milestones are in /group/groupmilestone/:

2025-04-30 not resolved | Adopt overview document
2025-04-30 not resolved | Adopt mechanism document
2025-11-30 not resolved | Adopt implementation guide
2025-12-31 not resolved | All documents submitted to the IESG

The first two look met: adopted draft-ietf-dkim- drafts exist that fit both descriptions. Neither is marked resolved. Milestones are the weakest signal on the page. They slip routinely and the records often lag the work, so read them as the schedule the charter set, not as a status.

Following one reference

A third trap shows up when you follow a document's references through the API.

draft-ietf-dmarc-arc-to-historic-00, dated 22 April 2026, asks for RFC 8617 (ARC) to be reclassified as Historic and names DKIM2 as the direction the work has moved in. Its one reference to DKIM2 is informative, to draft-ietf-dkim-dkim2-motivation-02. In the table above, that document has expired.

Ask the API for the ARC draft's references and you get this:

for r in get("/doc/relateddocument/?source__name=draft-ietf-dmarc-arc-to-historic")["objects"]:
    print(r["relationship"].split("/")[-2], r["target"].split("/")[-2])

refnorm rfc7208
refnorm rfc6376
refnorm rfc8174
refnorm rfc8617
refnorm rfc2119
refnorm rfc7489
replaces draft-adams-arc-experiment-conclusion

Six normative references and a replaces link. Neither informative reference appears, so the DKIM2 pointer is invisible here. If you are tracing what a document depends on, read the references section of the document itself as well.

What this does not say

An expired motivation document does not mean DKIM2 has stalled. The spec draft reached revision 06 on 28 August and the BCP draft reached revision 01 on 9 September. Drafts lapse after six months unless revised, and a lapsed one stays in the record.

ARC is not Historic. The request is a revision 00 working group document, and its IESG state is "I-D Exists", which means the IESG has not started on it. That draft expires on 24 October 2026 unless a new revision is posted.

And citing the motivation draft was not a mistake. Revision 02 is dated 2 November 2025 and expired in early May 2026, so it was a live draft when the ARC document cited it in April.

The lesson I am keeping

The dmarcbis row was a known answer sitting in the output of the first post, and the function printed it as a no. A check that prints confident yes and no answers needs a case where you already know the answer, run every time the check changes. The fixed version now starts with two:

assert became_rfc("draft-ietf-dmarc-dmarcbis") == "rfc9989"
assert became_rfc("draft-ietf-dkim-base") == "rfc4871"

The API itself is documented at datatracker.ietf.org/api, and none of it needs a key.

Written with AI assistance from my own notes and test results. I checked every fact and command before publishing.

Why INP comes back blank in lab speed tests, and what the Event Timing API actually reports

Jose Pollman — Tue, 29 Sep 2026 09:59:26 +0000

Five numbers and a blank

I run a Core Web Vitals checker. Pointed at its own URL this morning, on a simulated mid-range phone over throttled 4G, it returned this:

LCP   Largest Contentful Paint     3.32 s    Needs work
CLS   Cumulative Layout Shift      0         Good
INP   Interaction to Next Paint    (blank)   Not measured
TTFB  Time to First Byte           3 ms      Good
FCP   First Contentful Paint       1.71 s    Good
TBT   Total Blocking Time          78 ms     Good

Tested whattofixfirst.com on mobile, 29 Sept 2026, 11:47.
Lighthouse performance score: 89/100.

Five numbers and a blank. The blank is one of the three Core Web Vitals, and no lab-only test can fill it, including the one I built.

That is not a bug in any of them. It is what the metric is.

INP needs a person

LCP and CLS can be observed by loading a page and watching it. INP cannot, because there is nothing to observe until somebody touches something.

Google's own documentation for the metric is direct about the conditions that produce no value at all. A page returns no INP when the user never clicked, tapped or pressed a key; when they only scrolled or hovered, neither of which counts; or when "the page is being accessed by a bot such as a search crawler or headless browser that has not been scripted to interact with the page."

That last line describes every lab run. Lighthouse loads the page in a headless browser and does not click anything, so there is no interaction, so there is no latency to report. The same documentation says so plainly: "some lab tools won't report a page's INP because they only observe the loading of a page without any interactions."

The only three interaction types INP observes are a mouse click, a tap on a touchscreen, and a key press on a physical or onscreen keyboard. Scrolling and hovering are excluded outright.

So a checker has two honest options. Report the blank and say why, or report something else and pretend it is the same thing. I went with the blank.

TBT is a stand-in, not a substitute

The usual advice is to read Total Blocking Time instead, and that advice is reasonable as far as it goes. Google phrases it with a caveat worth copying verbatim: TBT "may be a reasonable proxy metric for INP, but it's not a substitute for INP in and of itself."

The reason is in the thresholds. INP is assessed at the 75th percentile of page loads in the field, and the bands are 200 ms or less for good, above 200 ms up to 500 ms for needs improvement, and above 500 ms for poor. TBT measures main thread blocking during load only. A page can load with almost nothing blocking the main thread, score well on TBT, and then hang for 400 ms the first time someone opens a menu. My own check above reports TBT at 78 ms, which is good, and that tells you approximately nothing about what happens when a visitor types in the URL box.

Field data closes the gap when it exists. On this run it did not: the checker reported that Google does not yet have enough real-visitor data for the origin, which is the normal state for a small site. Blank in the lab, blank in the field, and the output says so twice rather than filling the space.

Collecting it yourself

If you want the number for your own page, you collect it from real visitors with the Event Timing API. Here is the version most people write first:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log(entry.name, entry.duration);
  }
}).observe({ type: 'event', buffered: true });

This runs, it throws no errors, and on a responsive page it logs nothing at all. There are three reasons, and all three are written into the spec rather than hidden in browser behaviour.

The default cutoff is 104 ms

The Event Timing API does not surface every event. The W3C Working Draft of 19 March 2026 sets a default duration threshold of 104 ms, and explains the number: it "is just the first multiple of 8 greater than 100ms. An event whose rounded duration is greater than or equal to 104ms will have its pre-rounded duration greater than or equal to 100ms."

So the observer above is, by default, a slow-interaction detector. A page where every interaction lands in 90 ms produces an empty log, and an empty log looks identical to a broken observer.

Durations are rounded to 8 ms

That "rounded duration" is not incidental. The spec picked 8 ms as the granularity because it "allows relatively precise timing even for 120Hz displays." Every duration you read has been rounded to a multiple of 8, which is why the default cutoff is 104 and not 100. If you are comparing two interactions that differ by 5 ms, you are comparing noise.

The floor on durationThreshold is 16 ms

You can lower the threshold, but not to zero. The minimum allowed value is 16 ms, and the spec's reasoning is about frames rather than milliseconds: "In 120Hz displays, a response that skips more than a single frame will be at least 16ms, so the entry corresponding to this user input will be surfaced in the API under the minimum value."

A response that skips no more than a single frame is, as far as this API is concerned, not worth a record.

first-input is the exception

There is one entry type that ignores all of this. The spec says the first input entry "is reported even if it does not exceed a provided durationThreshold, and is buffered even if it does not exceed the default duration threshold of 104ms."

That matters because it is the only way to guarantee a page with interactions reports something. Google's guidance says the same: observe first-input alongside event so that consistently fast pages still produce a value instead of looking like pages nobody touched.

Put together, the version that actually collects data looks like this:

const interactions = [];

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.interactionId) {
      interactions.push(entry.duration);
    }
  }
}).observe({ type: 'event', buffered: true, durationThreshold: 16 });

// Guaranteed to fire even on a very fast page.
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    interactions.push(entry.duration);
  }
}).observe({ type: 'first-input', buffered: true });

Four things that still will not be right

Even with that, a hand-rolled collector disagrees with what Google records, in four specific ways that Google documents.

The percentile. INP is not the worst interaction. It is approximately the 98th percentile across all interactions on the page, computed when the page is unloaded. Keeping every sample in memory to compute that exactly is wasteful, and the documented shortcut is to keep only the worst N interactions, with 10 as the common choice.

Back/forward cache. If a page is restored from bfcache, INP resets to zero, because a user experiences that as a separate visit. A collector that keeps accumulating across a restore reports a number nobody experienced.

Backgrounded tabs. People leave tabs open for weeks and mobile browsers often do not run unload callbacks for background tabs, so waiting for unload loses the data. The fix is to report on visibilitychange, which covers both backgrounding and unload, and to compute the final value server side.

Iframes. The API does not report event entries from inside iframes. The metric does count them, because a visitor clicking play on an embedded video has no idea they crossed a frame boundary. This is a documented source of disagreement between CrUX and your own monitoring, and closing it means having the subframe post its entries up to the parent.

That list is why the practical answer for most people is onINP from the web-vitals library, which handles all of it except the iframe case. I am not arguing against using it. I am arguing that you should know what it is doing, because when your own dashboard and Search Console disagree, one of these four is usually the reason.

Two lines you can run right now

Open the console on any page you have interacted with:

PerformanceObserver.supportedEntryTypes.filter(t => /event|input/.test(t));
// ["event", "first-input"] in Chrome, checked 29 Sept 2026

performance.eventCounts.get('click');
// how many click events this page has recorded

The second one is the cheapest sanity check available. If eventCounts is counting clicks and your observer array is still empty, your observer is not broken. It is doing exactly what the default 104 ms threshold tells it to do, and your page is fast.

Which brings it back to the blank cell. A lab tool reporting no INP is not missing a feature. It is reporting, correctly, that nobody was there.

Written with AI assistance from my own notes and test results. I checked every fact and command before publishing. The cover image was generated with DEV's built-in image tool.

Checking whether an IETF draft is actually a standard, from the command line

Jose Pollman — Sun, 13 Sep 2026 18:54:34 +0000

Someone links an Internet-Draft, calls it a new standard, and now you have to decide whether to build against it. The draft looks official. It has a document number, section headings full of MUST and SHOULD, an IANA Considerations section and a Normative References list. None of that tells you what stage it is at.

The IETF publishes the answer as structured data. You can get it in one HTTP request, and the fields you need are all null or not null, so the check fits in a few lines of code.

The filename already tells you something

Every Internet-Draft name follows a pattern:

draft-<who-submitted-it>-<topic>-<revision>

If the second segment is ietf, a working group adopted the document and owns it. draft-ietf-dmarc-dmarcbis is the DMARC working group's revision of DMARC. Anything else is the submitter's own name or their employer's. draft-brotman-aggregate-performance-reporting is an individual submission by Alex Brotman.

That is a signal and it costs nothing to read. It is not the whole answer, because a document can be adopted later and keep circulating under the old name in people's bookmarks, so the rename matters and you want the current record.

One request to the datatracker

The IETF datatracker has a read-only REST API at /api/v1/. No key, no signup.

curl -s "https://datatracker.ietf.org/api/v1/doc/document/?name=draft-brotman-aggregate-performance-reporting&format=json" \
  | jq '.objects[0] | {name, rev, stream, intended_std_level, ad, shepherd, rfc_number, pages, expires}'

Run on 13 September 2026, that returns:

{
  "name": "draft-brotman-aggregate-performance-reporting",
  "rev": "01",
  "stream": null,
  "intended_std_level": null,
  "ad": null,
  "shepherd": null,
  "rfc_number": null,
  "pages": 14,
  "expires": "2027-03-12T15:50:05Z"
}

Five nulls in a row. Now the same query against the DMARC working group document:

{
  "name": "draft-ietf-dmarc-dmarcbis",
  "rev": "41",
  "stream": "/api/v1/name/streamname/ietf/",
  "intended_std_level": "/api/v1/name/intendedstdlevelname/ps/",
  "ad": "/api/v1/person/person/106842/",
  "shepherd": "/api/v1/person/email/tjw.ietf@gmail.com/",
  "rfc_number": null,
  "pages": 83,
  "expires": "2025-10-06T21:29:30Z"
}

Same API, same shape, completely different picture. Revision 41 instead of 01. A stream. An intended status. A named Area Director and a named shepherd.

What each field is actually telling you

stream is the publication path a document is on. GET /api/v1/name/streamname/ lists all six: IETF, ISE (Independent Submission), IRTF, IAB, Editorial, Legacy. null means the document is not on any of them yet. This is the single most useful field, because a document with no stream has no group of people responsible for moving it forward.

intended_std_level is what the document is aiming to become. Dereference the URI to get the human name:

curl -s "https://datatracker.ietf.org/api/v1/name/intendedstdlevelname/ps/?format=json" | jq -r .name
# Proposed Standard

Worth knowing: the text inside a draft can say Intended status: Standards Track in its own header while this field is null. The header line is typed by the author into the document template. The API field is set through the process. When they disagree, they are answering different questions, and the API field is the one that reflects where the document sits.

ad and shepherd are the two humans assigned to shove a document through publication. Both null means nobody has been assigned, which means the publication process has not started.

rfc_number is null until the document is published as an RFC. Once it is set, the draft is history and you should be reading the RFC.

group is the working group. Individual submissions all point at the same placeholder group, which is worth resolving once so you recognise it:

curl -s "https://datatracker.ietf.org/api/v1/group/group/1027/?format=json" | jq '{acronym, name, type}'

{
  "acronym": "none",
  "name": "Individual Submissions",
  "type": "/api/v1/name/grouptypename/individ/"
}

states is a list of state URIs. The one from the draft-iesg state type is the one people mean by "where is it":

curl -s "https://datatracker.ietf.org/api/v1/doc/state/150/?format=json" | jq '{name, desc}'

{
  "name": "I-D Exists",
  "desc": "The IESG has not started processing this draft, or has stopped processing it without publication."
}

That description is the clearest sentence on the whole site. It is the IESG saying, in its own data model, that nothing has happened.

The whole check in one function

This is small enough to keep in a scratch file and run whenever a draft turns up in a thread.

import json
import urllib.request

API = "https://datatracker.ietf.org/api/v1"

def draft_status(name):
    url = f"{API}/doc/document/?name={name}&format=json"
    with urllib.request.urlopen(url) as r:
        objects = json.load(r)["objects"]
    if not objects:
        return f"{name}: no such document"

    d = objects[0]
    adopted = name.split("-")[1] == "ietf"
    signals = {
        "adopted by a working group": adopted,
        "on a publication stream": d["stream"] is not None,
        "has an intended status": d["intended_std_level"] is not None,
        "has a responsible AD": d["ad"] is not None,
        "has a shepherd": d["shepherd"] is not None,
        "published as an RFC": d["rfc_number"] is not None,
    }

    print(f"{name}-{d['rev']}  ({d['pages']} pages, expires {d['expires'][:10]})")
    for label, value in signals.items():
        print(f"  {'yes' if value else 'no ':<3}  {label}")
    print(f"  {sum(signals.values())}/6 signals present")

draft_status("draft-brotman-aggregate-performance-reporting")
draft_status("draft-ietf-dmarc-dmarcbis")

Output on 13 September 2026:

draft-brotman-aggregate-performance-reporting-01  (14 pages, expires 2027-03-12)
  no   adopted by a working group
  no   on a publication stream
  no   has an intended status
  no   has a responsible AD
  no   has a shepherd
  no   published as an RFC
  0/6 signals present

draft-ietf-dmarc-dmarcbis-41  (83 pages, expires 2025-10-06)
  yes  adopted by a working group
  yes  on a publication stream
  yes  has an intended status
  yes  has a responsible AD
  yes  has a shepherd
  no   published as an RFC
  5/6 signals present

Note the expiry dates. The individual submission expires in 2027 and the working group document expired in 2025. An expiry date in the past is not a signal of abandonment. Drafts lapse after six months and get replaced by an RFC or a newer revision, and the record stays. Use rev and the time field for freshness, not expires.

Watching a draft instead of checking it once

If you have decided a draft is worth tracking, the field to store is time, which is when the record last changed. Poll it and compare.

curl -s "https://datatracker.ietf.org/api/v1/doc/document/?name=$1&format=json" \
  | jq -r '.objects[0] | "\(.rev) \(.time)"'

For the Brotman draft that prints 01 2026-09-08T15:50:05Z, so the revision that is live today went up on 8 September 2026. Store that string, run the same command on a schedule, and diff. When rev moves you have a new version to read. When stream stops being null, the document has been adopted and the questions above change.

The datatracker also exposes a /api/v1/submit/submission/ endpoint, and the document record carries a list of submission URIs, one per revision. That list is the cheapest way to see how many times a document has actually been revised without scraping the history tab.

What none of this measures

Zero out of six is not a criticism of a document. Individual submissions are the normal front door, and DMARC itself came in through it. Run the same query against draft-kucherawy-dmarc-base and you get group 1027, the same Individual Submissions placeholder, stream set to ise rather than ietf, and rev stopping at 13 with an expiry of 2015-08-10. That document became RFC 7489, on the Independent Submission stream, without a working group ever adopting it. The DMARC working group and draft-ietf-dmarc-dmarcbis came afterwards.

What the six signals tell you is narrower and more useful: how much process has run, and therefore how much the wire format is likely to move under you. A draft at 0/6 can change shape completely at the next revision, because nobody has agreed to anything yet. A document at 5/6 with an AD attached has had its incompatible changes argued out already.

There is also a plain-language version of all of this on every datatracker page, in a yellow box, above the metadata. For an unadopted draft it reads: "This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process." The API just lets you check a list of them without opening fifteen tabs.

Most of what I build sits on email authentication records, which is an area with a lot of draft traffic, so this check runs before I read a new proposal rather than after. It takes about ten seconds. Implementing the wrong revision of a wire format takes a weekend.

Written with AI assistance from my own notes and test results. I checked every fact and command before publishing. The cover image was generated with DEV's built-in image tool.