DEV Community: Jose Pollman

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.

Which EU countries let you check a company for free: a status table

Jose Pollman — Fri, 07 Aug 2026 15:24:10 +0000

If you are building anything that touches European business data — onboarding, invoicing, KYB, fraud checks — you will eventually ask the same question I did: which countries can I actually get company data from, for free, without an account?

I could not find this written down anywhere, so I worked it out the hard way while building a supplier checker. Here it is.

The baseline: VIES

The European Commission runs VIES, which validates VAT numbers across all 27 member states plus Northern Ireland (XI). It is free, it needs no key, and it is the obvious starting point.

Two things about it are worth knowing before you build on it.

It answers one question: is this VAT number currently registered. It does not tell you the company is solvent, trading, or that it has not been struck off. A company in liquidation keeps a cleanly resolving VAT number for months, because deregistration and insolvency are run by different authorities on different timetables.

Name and address are returned for 25 of the 28 jurisdictions, not all of them. Germany and Spain confirm registration but publish no company name through VIES. I tested three valid numbers for each before accepting that. For those two, a yes/no is genuinely all you can honestly show.

Where you can go further, free

Ten countries publish enough through a national register to add something meaningful on top of VIES:

Country	Free register	Reports company state	Reports VAT-active
Romania	yes	yes	yes
Poland	yes	—	yes
Slovenia	yes	—	yes
Estonia	yes	yes	—
France	yes	yes	—
Greece	yes	yes	—
Bulgaria	yes	yes	—
Latvia	yes	yes	—
Czechia	yes	—	—
Finland	yes	—	—

Company state means the register tells you whether a business is inactive, in liquidation, bankrupt, insolvent, terminated or struck off. This is the valuable column, and only six countries have it.

VAT-active matters more than it sounds. VIES cannot distinguish "this is a real company that is not VAT-registered" from "this number belongs to nobody". Three registers can.

Note that Czechia and Finland are in the list but in neither of the other columns — they confirm a name and little else. Worth knowing before you design a feature around "the ten countries".

Where you cannot

No free company-data source I could find at all: Germany, Austria, Italy, Spain, Portugal, Lithuania, Luxembourg, Cyprus, Malta.

Behind an account, an API key or a payment: Hungary, Ireland, Belgium, Denmark, Croatia, Netherlands, Sweden.

Hungary deserves its own paragraph. It does return name and address through VIES, so it looks fine at first. What is missing is company state — and I found six separate official routes to it, every single one behind a CAPTCHA. That is not a technical problem you can engineer around. It is a policy decision, and the answer is no.

The UK, post-Brexit

Great Britain left VIES on 1 January 2021. GB VAT numbers now return invalid there, and HMRC's own VAT checking API requires an approved application. If you do not hold one, what you can do for free is verify the official check digit locally — which proves a number is impossible, never that it exists — and then link people to the free checker on GOV.UK.

Northern Ireland is a separate case: XI numbers go through VIES normally.

Poland is the outlier worth knowing about

Poland is the only EU member state where you can check whether a bank account belongs to a company.

The Ministry of Finance publishes the accounts that VAT-registered businesses have declared, on what is known as the white list. It exists because paying into an unlisted account has tax consequences for the payer, so there is a statutory reason for the data to be public and current.

Nowhere else in the EU can you do this from public data. Everywhere else, an IBAN tells you the country and the bank and absolutely nothing about who owns it.

Practical notes for anyone building this

Greece files VAT under EL, not GR. Every ISO country code list will tell you GR. VIES wants EL. This will cost you an afternoon if nobody warns you.
Northern Ireland is XI.
Implement the check digits locally. They are published arithmetic, they work offline, and they work when a registry is down. I did 19 countries and it is one of the highest value-per-line things in the project — it catches a transposed digit instantly with no network call.
Assume the registers will break. They change their markup without warning, and that is the real maintenance cost. It is also why I have not shipped an API: I would rather a scraper break for me than inside somebody else's production pipeline.
VIES has downtime, disproportionately at weekends and quarter ends. National registers are a useful fallback for the ten countries above.

Why the gaps matter more than the coverage

The temptation when you build something like this is to present the ten countries as "European coverage" and let people assume the rest works too. It does not, and the honest version is more useful: sixteen of twenty-seven member states have no free route to company status at all.

If you are relying on this data for anything that matters, know which column your country is in.

I keep a running version of this against a free tool I maintain — a worked example is here if you want to see what the combined output looks like. Happy to answer questions about any specific register in the comments.

Four things get called "someone is spoofing my domain". DMARC fixes one.

Jose Pollman — Wed, 05 Aug 2026 13:52:25 +0000

Someone forwards you a message. It has your company's address on it and you did not send it. The obvious next move is to go and publish p=reject.

Wait. Four quite different attacks get reported in exactly those words, and DMARC only fixes one of them. Enforcing against the wrong one costs weeks and changes nothing.

Triage first: look at the actual From address

Not the display name your mail client shows you. The address.

What you see	What it is	What fixes it
`billing@example.com` — your exact domain	Domain spoofing. Anyone can write any address into a `From:` header.	SPF + DKIM + DMARC at `p=reject`
`Your Company <randomuser@gmail.com>`	Display-name impersonation. The address is theirs. Only the label is yours.	Nothing in your DNS. Receiver-side rules and staff training.
`billing@examp1e.com`, `example-inc.com`	Lookalike domain. A different domain that reads like yours.	Monitoring and takedowns. Your DMARC record has no authority over it.
Genuinely from your account, in your Sent folder	Compromised account.	Password, revoke sessions, and check for forwarding rules the attacker added.

Only the first row is domain spoofing. It's also the only one where a stranger can put your domain in front of your customers, which is why it's worth fixing first and why DMARC exists.

If you can't tell which you're looking at, the raw headers will settle it — the Authentication-Results header names the domain that actually authenticated.

"I'm getting bounces for mail I never sent"

This is how most people discover the problem, and it's alarming in a misleading way.

A spammer sent to a few thousand addresses with your address forged as the sender. Some of those didn't exist. Those servers bounced the messages back to the forged sender — you.

It does not mean anything of yours was accessed. No password is required to type your address into a header. It's evidence your domain is being forged, and a good reason to get to enforcement, but it is not a breach.

One exception worth ruling out immediately: if the bounces correspond to messages that appear in your own Sent folder, that's a compromised account, not spoofing. Different problem, much more urgent.

Why fixing the real thing takes weeks

Worth understanding the mechanism, because it explains the timeline.

Nothing in the original design of email verifies the From: header. SMTP accepts whatever a sender writes. SPF, DKIM and DMARC are a layer bolted on afterwards that lets you publish a claim about who may send as you, and lets receivers act on it.

1. Get SPF or DKIM passing for every legitimate sender. Not just your mailbox provider — the CRM, the invoicing system, the ticketing tool, the booking form. And each must pass aligned with your domain. A vendor sending from its own envelope domain can pass SPF perfectly and still fail DMARC.

2. Publish DMARC at p=none with a reporting address.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

This blocks nothing. It tells you who is sending as you — including the forger, and including the three internal systems you'd forgotten about.

3. Read the reports for four to six weeks, then enforce. Long enough that monthly and quarterly senders show up. Then p=quarantine, then p=reject.

There's no shortcut here that doesn't risk blocking your own mail.

The `sp=` footgun

Attackers move to subdomains once the parent is unusable, because billing.example.com is just as convincing to a recipient and is usually left unprotected.

Subdomains inherit p= unless you override it, so a bare p=reject already covers them.

The mistake is publishing sp=none alongside it — almost always copied from an example record found somewhere — which reopens precisely the door you just shut. If you don't have a specific reason for an sp= tag, don't publish one.

What DMARC will not do, whatever the vendor said

It does not stop lookalike domains. examp1e.com belongs to someone else. Your DNS says nothing about it, and p=reject on your domain has no effect on theirs.
It does not stop display-name impersonation. That message is properly authenticated for the sender's own domain. There is no authentication failure for DMARC to act on. This is now the more common attack against small organisations — precisely because DMARC adoption made the easy version harder.
It does not stop your name being used in the message body.
It does not apply retroactively. Mail already delivered stays delivered.

What it does is remove your domain from the attacker's toolkit. That's worth the few weeks. The rest is a filtering and training problem, not a DNS one.

I maintain notspoofed — a free, no-signup SPF/DKIM/DMARC checker. It reports whether your policy is actually enforcing and flags an sp= tag that's quietly weakening it, which is the failure above that people don't find on their own. There's also an in-browser header analyzer for the triage step; headers are parsed locally and never uploaded. Source on GitHub under MIT.

If you've had the bounce-flood experience and it turned out to be something other than plain domain spoofing, I'd be interested to hear which of the four it was.

What I learned reading ten EU company registers

Jose Pollman — Wed, 05 Aug 2026 00:34:46 +0000

I built a free tool that checks a supplier before you pay them. The part that took most of the work, and taught me most, was reading ten national company registers instead of relying on the EU's own VIES service.

This is what I found out, mostly so the next person doesn't have to.

The problem with "the VAT number is valid"

VIES — the European Commission's VAT Information Exchange System — answers one question: is this VAT number currently registered. That sounds like the question you want answered. It isn't.

A company that has gone into liquidation keeps a cleanly resolving VAT number in VIES. So does one that has been struck off the register. Deregistration and insolvency are run by different authorities on different timetables, and the gap between "this company has stopped being a going concern" and "the VAT number stops validating" can be months.

So you can check a supplier, get a green tick, and be looking at an insolvency estate.

The national registers know. VIES doesn't ask them.

Ten registers, and what each actually gives you

I found free, public, machine-readable-enough sources for ten countries: Bulgaria, Czechia, Estonia, Finland, France, Greece, Latvia, Poland, Romania and Slovenia.

They are not equivalent, and this is the thing I'd have liked written down somewhere before I started:

Six of them report company *state* — inactive, in liquidation, bankrupt, insolvent, terminated, ceased, struck off: Romania, Estonia, France, Greece, Bulgaria, Latvia. This is the valuable one.
Three report whether the company is actually VAT-active — Poland, Romania, Slovenia. That matters more than it sounds, because VIES does not distinguish "this is a real company that isn't VAT-registered" from "this number belongs to nobody".
The rest give you a name and not much more.

Czechia, for instance, is in the ten but in neither of the other two groups. It confirms a name. That's it. Worth knowing before you build a feature around it.

Poland is the interesting one

Poland is the only EU member state where you can check whether a bank account belongs to the supplier.

Not because of anything clever — because the Ministry of Finance publishes the accounts that VAT-registered businesses have declared, on what's known as the white list. It exists because paying an unlisted account has tax consequences for the payer, so there's a statutory reason for the data to be public and current.

Nowhere else in the EU can you do this from public data. In every other country, an IBAN tells you the country and the bank and nothing whatsoever about who owns it.

Where it gets ugly

Nine countries have no free company-data source I could find at all: Germany, Austria, Italy, Spain, Portugal, Lithuania, Luxembourg, Cyprus, Malta.

Seven more are gated behind an account, an API key or a payment: Hungary, Ireland, Belgium, Denmark, Croatia, Netherlands, Sweden.

Hungary deserves a specific mention. It does return a name and address through VIES. What's missing is company state — and I found six separate official routes to it, every one of them behind a CAPTCHA. That's not a technical problem, it's a policy one, and no amount of engineering fixes it.

Germany and Spain are a different flavour of annoying: VIES confirms registration for both, but neither publishes a company name through it. I tested three valid numbers for each to be sure I wasn't holding it wrong. For those two, all you can honestly show is a yes/no.

Small things that cost me time

Greece files VAT under EL, not GR. Every list of ISO country codes will tell you GR. VIES wants EL.
Northern Ireland is XI. Post-Brexit, NI numbers go through VIES; Great Britain numbers don't.
GB is not available unless you hold an approved application for HMRC's VAT API. I don't. What you can do for free is verify the official check digit locally — which proves a number is impossible, never that it exists — and then link to the free checker on GOV.UK, which answers the user's actual question in ten seconds.
Check digits are arithmetic, so they work when the registry is down. I implemented them for 19 countries. This turned out to be one of the highest-value-per-line things in the project: it catches a transposed digit immediately, offline, with no network call.
Registers change their markup without warning. This is the real maintenance cost, and the main reason I haven't shipped an API — I'd rather a scraper break for me than in someone else's production pipeline.

The design decision I'd defend hardest

The tool shows five separate results and deliberately refuses to combine them into a score or a "safe to pay" verdict.

That's not modesty, it's the whole point. The most common invoice fraud is bank-detail redirection: a real supplier's mailbox is compromised and only the account number on the invoice changes. The company is real. The VAT number is valid. The goods were delivered. The sanctions check is clean. Every individual check passes, because everything is genuine except the destination of the money.

A single green tick would be a confident lie about the one attack that actually happens. So there are five answers, and a standing instruction to confirm bank details by phone on a number you already had.

If you're building anything in this space, that's the trap: the aggregate score is the most saleable feature and the most dishonest one.

Boring stack, on purpose

The whole thing runs in about 300 MB on a single VPS in Helsinki. No account, no cookies, no ads, no third-party analytics. The full IBAN is never stored or displayed — only country code, check digits and last four — and saved results are deleted after 90 days.

There's no API and no bulk checking. For a developer audience that's probably the whole review, and it's a fair criticism. It's one person maintaining sixteen fragile integrations, and an API is the fastest way to turn that into an operations job I can't staff.

A worked example, if you'd rather see the output than type a VAT number: vetthisvendor.com/example

Happy to go into any of the registry scraping in the comments — that was most of the work and most of the pain.

Every DKIM checker is guessing — including mine

Jose Pollman — Tue, 04 Aug 2026 12:53:34 +0000

Almost every DNS record you care about can be looked up. Ask for the SPF record, you get it. Ask for _dmarc, it's there.

DKIM doesn't work that way, and almost nobody building tooling around it says so out loud.

You cannot list selectors. At all.

A DKIM public key lives at:

<selector>._domainkey.<domain>

The selector is an arbitrary label chosen by whoever set up signing. Google Workspace uses google. Microsoft 365 uses selector1 and selector2. Mailchimp uses k1. Amazon SES generates three random tokens per identity.

There is no DNS query that returns "every name under _domainkey". ANY doesn't do it. Zone transfers are refused by every sane nameserver. To read a DKIM key, you must already know its name.

Which means every DKIM checker in existence — mine included — is guessing from a list.

So when a tool tells you "no DKIM found", the honest translation is:

We tried our list of forty or fifty common selectors and none of them matched.

That is a genuinely different statement from "you have no DKIM", and the gap between the two is where people waste afternoons.

Amazon SES makes it concrete. Its selectors are random tokens. No guess list will ever find them. A domain signing perfectly through SES will read as "no DKIM" on every guessing tool, forever. If your checker doesn't tell you that, it's misleading you by omission.

The opposite failure: selectors that were never there

Now the direction that's actually dangerous, because it produces confident output instead of a shrug.

Some domains publish a wildcard DNS record, which answers every name under the domain. On such a domain:

dig +short TXT totally-made-up-selector._domainkey.example.com

...returns something. Not because that selector exists. Because the wildcard matches everything.

A checker whose test is "did I get an answer?" will report a dozen imaginary selectors on these domains, and it will look authoritative doing it.

The obvious defence is to require the answer to actually parse as DKIM — specifically to carry a p= tag, which RFC 6376 makes mandatory.

That's necessary, and it isn't sufficient. Here's the one that got me:

*._domainkey.example.com.  TXT  "v=DKIM1; p="

That's a structurally valid DKIM record with an empty key. It passes the p= test. So every guessed selector comes back looking like a revoked key — and now your tool is telling someone they have thirty revoked DKIM selectors, which is both alarming and entirely fictional.

The only defence I've found that holds: query a deliberately nonsensical selector first, then discard any result identical to what the wildcard returned. Establish the baseline lie, then subtract it.

If a checker has ever told you that you have dozens of revoked selectors, this is what happened. Ignore it.

Finding yours for certain

Two methods, neither of which involves guessing.

Read a message you sent. Most reliable, and needs access to nothing. Send yourself a message, view the raw source (⋮ → Show original in Gmail), and find:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=selector1; t=1785453729;

s= is your selector. d= is the signing domain — check that d= matches your visible From: domain, because if it doesn't, DKIM is passing and not aligning, and DMARC fails anyway.

Do this once per sending system. Each has its own selector and they all have to work.

Or check the provider's console. Every platform exposes this under "authentication", "verified domains" or "DKIM" — which is also where you switch signing on if it turns out it was never enabled.

Reading the record once you have the name

dig +short TXT selector1._domainkey.example.com

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…"

Four things worth noticing:

p= with nothing after it means revoked. If anything is still signing with that selector, that mail is failing DKIM right now.
A missing v= tag is fine. RFC 6376 only recommends it. Plenty of production records start straight at k=rsa and validate perfectly.
Key length. 1024-bit RSA is still accepted everywhere but is no longer considered strong. 2048 is the norm. Rotate through your provider, not by hand-editing DNS.
A CNAME instead of a TXT is normal. Most platforms have you delegate the selector to them so they can rotate keys without touching your zone. Follow it and you should land on a valid key.

Worth stealing: the revoke-everything wildcard

The wildcard pattern that breaks checkers is genuinely useful if you own a domain that sends no mail:

*._domainkey.example.com.  TXT  "v=DKIM1; p="

That declares every selector on the domain revoked. Combined with v=spf1 -all and p=reject, it's an unambiguous statement that this domain sends nothing and any signature claiming otherwise is forged.

And it doesn't paint you into a corner: DNS wildcards only apply where no exact match exists, so publishing a real selector later takes precedence automatically. One working key coexists happily with a revoke-everything wildcard.

Most parked and brand-protection domains have SPF and DMARC locked down and leave DKIM wide open. This closes it.

I maintain notspoofed — a free, no-signup SPF/DKIM/DMARC checker. It guesses fifty selectors like everything else, but it says so, it verifies each hit is a real parseable signing key rather than a wildcard echo, and it runs the nonsense-selector baseline described above so it won't invent thirty revoked keys for you. I built that last part because I got it wrong first. Source is on GitHub under MIT.

If you've seen a checker confidently report selectors that don't exist, I'd like to know which — that failure mode is more common than it should be.

SPF passed. DKIM passed. DMARC failed. Nothing is broken.

Jose Pollman — Mon, 03 Aug 2026 19:50:40 +0000

This header block is where most people's understanding of email authentication falls apart:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=bounce@esp-vendor.net;
  dkim=pass header.d=esp-vendor.net;
  dmarc=fail (p=REJECT) header.from=yourcompany.com

Two passes and a fail. No malformed record anywhere. Nothing to fix in DNS. And the mail is being rejected.

Every part of that is correct behaviour.

The question DMARC actually asks

DMARC does not ask "did SPF pass?"

It asks: did SPF or DKIM pass for the same domain that appears in the From: header?

There are three domains in play in any message, and only one of them is visible to a human:

Identifier	Lives in	Who sees it	Checked by
`From:`	The message headers	Your recipient	Nothing, on its own
Envelope sender (`MAIL FROM`)	The SMTP conversation	Nobody	SPF
DKIM `d=`	The signature header	Nobody	DKIM

SPF authenticates the envelope sender. DKIM authenticates the signing domain. Neither of them is the From: header. DMARC exists entirely to insist that at least one of them matches it.

In the header above, SPF authenticated esp-vendor.net and DKIM signed as esp-vendor.net. The recipient sees yourcompany.com. Nothing authenticated yourcompany.com, so DMARC fails.

It has to work this way. If DMARC accepted "SPF passed" without the matching step, anyone with a mailbox at a provider with a valid SPF record could send as you and pass.

How you get here without doing anything wrong

You sign up for a marketing platform, an invoicing tool, or a helpdesk. You set the From address to hello@yourcompany.com because that is what your customers should see.

The platform sends from its own infrastructure with its own envelope domain — it has to, because that is where bounces go. SPF passes, for them. Your From: says you.

Those do not align. If nothing is DKIM-signed with your domain, every message from that platform fails DMARC.

This is the single most common cause of "we set up SPF and it still doesn't work".

The fix that feels right and does nothing

Adding include:esp-vendor.net to your SPF record.

It is the intuitive move. It changes nothing.

That include authorises their servers to send for your envelope domain. Their mail still uses their envelope domain, so the alignment comparison is untouched. You have spent one of your ten SPF DNS lookups for no benefit at all.

If your reaction to a dmarc=fail is to edit your SPF record, stop and read the Authentication-Results header first.

Relaxed vs strict, and the trap in the middle

Alignment has two modes, set per-mechanism with aspf= and adkim= in your DMARC record:

Relaxed (r, the default) — organisational domains must match. mail.example.com aligns with example.com.
Strict (s) — exact match only. mail.example.com does not align with example.com.

Relaxed is right for almost everyone. Strict is worth it only if you are confident every sender uses the exact apex domain, and it breaks the day someone starts sending from a subdomain.

Here is the part that matters if you are implementing this yourself: "organisational domain" is not "the last two labels".

attacker.co.uk and victim.co.uk share their last two labels and have no relationship whatsoever. Getting this right means consulting the Public Suffix List, not counting dots. A checker that counts dots will tell you two unrelated domains are aligned, which is the worst possible direction to be wrong in.

Reading it from your own mail

Send a message to a mailbox at a different provider. Open the delivered copy and view the source — ⋮ → Show original in Gmail, View message details in Outlook.

Then compare exactly three lines:

From: Your Company <hello@yourcompany.com>     <- the domain that must be matched
spf=pass smtp.mailfrom=bounce@esp.net          <- authenticated esp.net
dkim=pass header.d=esp.net                     <- signed by esp.net

If neither the smtp.mailfrom domain nor the DKIM d= matches your From domain, DMARC fails regardless of how correct your SPF record is.

Use a message you received, not one from your Sent folder. Sent copies have no Authentication-Results header at all — that verdict is written by the receiving server. Nearly everyone trips on this the first time and concludes their headers are broken.

Fixing it properly

Get DKIM signing with your own domain. Every serious sending platform supports it. It is usually called "authenticate your domain", "domain authentication" or "custom DKIM", and it hands you a selector to publish in DNS. Once the platform signs with d=yourcompany.com, DKIM aligns and DMARC passes no matter what the envelope sender says.

There is a second reason to prefer DKIM, and it is the one that bites later: DKIM survives forwarding and SPF does not. The moment a message is forwarded, the forwarding server is not in your SPF record. Every mailing list and every user-configured forward becomes a DMARC failure if SPF alignment is all you have.

Optionally, also set a custom return-path. Some platforms let you point the envelope sender at a subdomain of yours — "custom return-path" or "custom bounce domain". You publish a CNAME, the envelope domain becomes bounce.yourcompany.com, and that aligns under relaxed. This fixes only the SPF half and still dies on forwarding, so do it as well as DKIM, not instead.

Before you enforce

This is the actual reason the p=none → quarantine → reject order exists.

Run at p=none with a reporting address and read the aggregate reports. They tell you which sources pass SPF and DKIM with alignment — a different and much smaller set than the sources that merely pass SPF. Move to p=quarantine only when that list matches the systems you expect to be there.

Skip it and you will find your misaligned senders the hard way: by having their mail rejected.

I maintain notspoofed — a free, no-signup checker for SPF, DKIM and DMARC. It has an in-browser header analyzer that does the three-way alignment comparison above and shows relaxed vs strict as a table; headers are parsed locally and never uploaded. It uses the Public Suffix List for organisational domains, because counting labels is wrong. Source is on GitHub under MIT.

If you have hit an alignment failure with a cause that is not on this list, I would like to hear it — those are the interesting ones.

Why your DMARC reports never arrive (and why Gmail can't be your rua address)

Jose Pollman — Sun, 02 Aug 2026 21:02:50 +0000

You published a DMARC record months ago. Every checker says it's valid. No reports have ever arrived, and at some point you stopped thinking about it and quietly concluded nobody's forging your domain.

You don't know that. You just can't see.

Two causes account for almost all of it, and both leave the DMARC record itself looking perfect.

1. Your reporting address never agreed to receive them

This is in the spec and almost nobody knows about it.

If your rua= address is on a different organisational domain from the domain publishing the record, RFC 7489 section 7.1 requires the destination to explicitly consent. The reason is obvious once you see it: otherwise anyone could point rua= at your mailbox and use the world's mail infrastructure as a free DDoS.

Consent is a DNS record, published by the receiving domain:

<your-domain>._report._dmarc.<their-domain>.  TXT  "v=DMARC1"

So if example.com sends reports to dmarc@reports.vendor.com, then vendor.com has to publish:

example.com._report._dmarc.reports.vendor.com.  TXT  "v=DMARC1"

Without it, conforming reporters send nothing at all. That includes Google, which is most of your report volume.

You can watch this working in production. PayPal sends aggregate reports to a third party, and the authorisation record exists:

paypal.com._report._dmarc.rua.agari.com.  TXT  "v=DMARC1;"

The practical consequence: not a Gmail address

You cannot put a Gmail address in rua=.

Google is not going to publish yourdomain.com._report._dmarc.gmail.com on your behalf, and you can't create records in their zone. Same for Outlook, Yahoo, or any address at a domain you don't control.

This is a common first move — publish DMARC, point reports at your personal inbox, wait. Nothing arrives, and nothing is wrong with the record.

If you use a commercial DMARC service they normally publish these records during onboarding, often via a wildcard. If reports never start after you sign up, check this before anything else.

When it doesn't apply: reporting to your own organisational domain needs no authorisation. example.com sending to dmarc@mail.example.com is fine.

2. There's no mail server behind the address

Subtler, and easy to create by accident on a domain that only serves a website.

You publish:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"```

Self-referential, so no authorisation needed. Correct in every way.

But if `example.com` has **no MX record**, senders fall back to its A record — the implicit MX rule in [RFC 5321 section 5.1](https://www.rfc-editor.org/rfc/rfc5321#section-5.1). On a web-only domain that A record points at a web server, which doesn't speak SMTP. Every report bounces.

The DMARC record is flawless. You just have no mailbox.

This bites hardest on marketing sites and defensive brand registrations — exactly the domains where you published DMARC as a hardening measure and are least likely to notice the silence.

The fix doesn't require running a mail server. A forwarding service will publish MX records for you and forward `dmarc@` somewhere you actually read.

## Checking both in about thirty seconds



```bash
# 1. What does your record actually say?
dig +short TXT _dmarc.example.com

# 2. If rua points off-domain, is it authorised?
dig +short TXT example.com._report._dmarc.THEIR-DOMAIN.com
#    Expect "v=DMARC1". Anything else means reports are refused.

# 3. If rua points at your own domain, can it receive mail?
dig +short MX example.com
#    Empty means every report bounces.

A third possibility, but rule the others out first

Some providers only send aggregate reports once they see meaningful volume from a domain. A domain sending almost nothing may legitimately get few reports, particularly from smaller receivers.

That's a real explanation, but it's also the comfortable one, so don't reach for it early. The two DNS causes above are deterministic and fixable. Google will typically report on any domain with real traffic within a day or two.

Why this matters more than it sounds

The entire value of p=none is the reporting. That's the whole point of the stage.

If you're sitting at p=none with broken reporting, you've done all the work of DMARC and got none of the benefit — no protection, because p=none blocks nothing, and no visibility either. You're paying the setup cost and collecting nothing.

Check it on the day you publish, not six months later when someone asks how the rollout is going.

I maintain notspoofed, a free checker that tests both of these — whether an external rua= is actually authorised, and whether the reporting address can receive mail at all. It's the failure mode I've seen most often and the one fewest tools look for. No signup, and checked domains aren't logged.

If you've had reports silently missing for months, I'd be curious which of the two it turned out to be.

Your SPF record can be valid, published, and completely ignored

Jose Pollman — Sun, 02 Aug 2026 20:55:09 +0000

There's a failure mode in SPF that produces no error anywhere you'd think to look.

Your record is syntactically valid. dig returns it. Your DNS provider is happy. Your own test mail arrives fine. And yet some of your mail is failing authentication at the receiver, and nothing in your infrastructure will tell you.

The cause is usually that you've gone past ten DNS lookups.

Ten is a hard ceiling, not a guideline

RFC 7208 section 4.6.4 requires evaluators to cap DNS-querying terms at ten. Go past it and the result is PermError — a permanent failure.

The important part: receivers don't degrade gracefully. They don't evaluate the first ten and shrug at the rest. They treat the entire record as unusable. You go from "SPF configured" to "SPF absent" in one step, and the only place that's visible is in DMARC aggregate reports, which most people aren't reading yet.

Six terms cost a lookup. Four are free.

Costs a lookup	Free
`include:`	`ip4:`
`a`	`ip6:`
`mx`	`all`
`ptr`	`exp=`
`exists:`
`redirect=`

The count isn't yours to control

This is what catches people out. The limit applies to the whole resolution tree, not just your record.

You publish four includes. One of those vendors publishes six includes of their own. You're at eleven, and your record lists four things.

Nothing changed on your side. A vendor updated their record and broke yours. There is no notification for this, from anyone, ever.

Counting it by hand

You can walk the tree with dig if you want to see it directly:

dig +short TXT example.com | grep spf1

Then for every include: you find, recurse:

dig +short TXT _spf.vendor.com | grep spf1

Keep going until you bottom out, counting every include:, a, mx, ptr, exists: and redirect= along the way.

It's tedious but instructive — you'll usually find one vendor accounting for half your budget.

Three traps that make tools lie to you

Doing this by hand or with a naive script, there are three places to go wrong. I've seen all three produce confidently incorrect output.

1. `redirect=` uses `=`, not `:`

It's a modifier, not a mechanism, and both humans and regexes skip it. Plenty of production domains are nothing but a redirect:

hubspot.com.  TXT  "v=spf1 redirect=_hspf.hubspot.com"

Miss that single term and you conclude the domain uses zero lookups — when in fact every include and every cost lives behind it. If a checker tells you a domain like this uses no lookups, the checker is broken.

2. Void lookups have a separate budget

A lookup that returns nothing is a void lookup, and RFC 7208 caps those at two.

So an include pointing at a vendor you stopped paying for last year, whose record no longer exists, hurts you twice: once against the ten, and once against the void limit. Dead includes aren't free just because they resolve to nothing.

3. TXT records arrive in pieces, joined with nothing

This is the one that bites anyone writing their own tooling.

DNS transmits TXT records as one or more character-strings of at most 255 bytes. A long SPF record arrives in several chunks, and RFC 7208 section 3.3 says they're concatenated with no separator.

Real records split mid-token. One production record ends a chunk with ...ip4 and starts the next with :161.38.192.0/20.

Join them correctly and you get ip4:161.38.192.0/20. Join them with a space — the obvious-looking thing to do — and you get ip4 :161.38.192.0/20, which isn't valid syntax.

If you're parsing SPF yourself, handle this first. If you're using someone else's tool and the output looks subtly mangled, this is usually why.

Fixing it, in the order worth trying

Remove senders you no longer use. The only fix with no downside, and it's almost always available. Most domains over the limit are carrying includes for tools nobody has logged into in years, and deleting one buys back its entire subtree. Get the include list in front of whoever owns marketing and billing and ask what's still live.

Ask the vendor for a narrower include. Some publish a broad include covering all their infrastructure plus a tighter one scoped to a product or region. This is rarely documented — you have to ask support.

Flatten, but as little as possible. Replacing include:vendor.com with the IPs it resolves to turns a five-lookup subtree into zero, because ip4: and ip6: are free.

The cost is permanent and easy to underestimate: you've taken on that vendor's maintenance burden. When they add a sending IP, their record updates and yours doesn't. Your mail from that provider starts failing SPF silently, and you find out when someone notices deliverability dropped a month ago.

If you flatten:

Only flatten enough to get under ten. Retiring the single most expensive include is often sufficient, and leaves everyone else free to rotate their own IPs.
Never flatten a provider using macros. A term like exists:%{i}._spf.example.com expands against the connecting IP. There's no fixed set of addresses to inline, and flattening it silently drops every sender it would have matched.
Re-check monthly, in a calendar, not in your head.

Worth knowing: large providers increasingly flatten their own records for this reason. _spf.google.com today contains only ip4: and ip6: entries with no nested includes, so include:_spf.google.com costs you exactly one lookup rather than four.

Don't aim for ten

Ten is legal. Ten is not a target.

A record sitting at exactly ten breaks the day someone in marketing signs up for one more tool, and nobody will connect those two events. Aim for seven or eight so there's headroom to add a sender without causing an outage.

I maintain notspoofed, a free checker that walks the whole include tree, follows redirect=, counts against the real ceiling, and generates a corrected record that flattens only what it has to. It handles all three traps above, because I got them wrong first. No signup, and the domains you check aren't logged.

If you've hit this in an interesting way — particularly a vendor whose record silently blew your budget — I'd like to hear about it.