RFC conformance

69 of 74 catalogued requirements — 93%.

The denominator is our reading of which normative statements apply to a verifier: something that inspects a domain's records and reports on them. It is not a percentage of an RFC's text, which is not a computable number — most of RFC 7208 instructs senders and receiving MTAs, and none of that is ours to implement. Requirements that do not apply are listed below with a reason and excluded from the denominator, so cataloguing more of what an MTA does cannot improve the figure.

Every requirement marked yes names a test that must exist and must assert it. The build fails otherwise, so the number is checkable rather than claimed.

What we do not do

The part of this page worth reading first.

RFC 4035 §5
Validating the DNSSEC chain of trust for an answer
We rely on the resolver we query, and read the AD bit it sets. Validating the chain ourselves would mean shipping a trust anchor and a validator, which is Phase 2 work at the earliest — the fixture tier already carries signed, bogus and insecure-island zones for it.
RFC 7208 §5.5
Evaluating whether a ptr mechanism matches a given client
Deciding one needs a reverse lookup of the connecting address and a forward confirmation of every name it returns. We report the term as undetermined for a specific sender rather than guessing, which is visible as SPF_IP_UNDETERMINED.
RFC 7208 §6.2
Fetching and macro-expanding exp= text on a fail
exp= text is fetched only to build a rejection message after the outcome is already decided, so it changes no verdict. Parsing the modifier is implemented; retrieving and expanding the explanation string is not.
RFC 7208 §7.3
Expanding the %{p} macro
It is the validated domain name of the connecting address, which needs the same reverse lookup and forward confirmation as the ptr mechanism. §7.3 advises against publishing it. Reported as unevaluable rather than guessed.
RFC 8659 §5
A CA must consider the DNSSEC validation state of the RRset
The DNSSEC state of the CAA RRset is what a CA must consider. We rely on the resolver's validation rather than validating ourselves — see the DNSSEC entries.

RFC 1034

Domain names — concepts and facilities

4 / 4 implemented

§4.1
A zone should be served by at least two nameservers
yes
§4.2.2
Every nameserver a zone is delegated to must be authoritative for it
yes
§4.2.2
The parent's delegation and the zone's own NS RRset should agree
yes
§4.3.5
Authoritative servers for a zone serve the same version of it
yes

RFC 1035

Domain names — implementation and specification

5 / 5 implemented

§4.1.4
Name compression: a pointer refers to a prior occurrence of the name
yes
§3.3.14
TXT rdata is a sequence of character-strings, each at most 255 octets
yes
§2.3.4
A label is at most 63 octets and a name at most 255
yes
§3.3.14
The character-strings of one TXT rdata concatenate with no separator between them
yes
§4.2.2
A truncated answer is retried over TCP rather than used as received
yes

RFC 2181

Clarifications to the DNS specification

2 / 2 implemented

§10.3
An MX exchange must not point at an alias
yes
§5.2
Every record in an RRset carries the same TTL
yes

RFC 2308

Negative caching of DNS queries

2 / 2 implemented

§5
A negative answer is remembered for the lesser of the SOA minimum and the SOA TTL
yes
§2
NODATA and NXDOMAIN are distinct: one says the type is absent, the other that the name is
yes

RFC 4035

Protocol modifications for DNSSEC

0 / 1 implemented

§5
Validating the DNSSEC chain of trust for an answer
We rely on the resolver we query, and read the AD bit it sets. Validating the chain ourselves would mean shipping a trust anchor and a validator, which is Phase 2 work at the earliest — the fixture tier already carries signed, bogus and insecure-island zones for it.
no

RFC 4343

Domain name system case insensitivity clarification

1 / 1 implemented

§3
Domain name comparison is case-insensitive
yes

RFC 5321

Simple Mail Transfer Protocol

1 / 1 implemented

§5.1
With no MX, the domain's address record is the implicit mail exchange
yes

RFC 6376

DomainKeys Identified Mail (DKIM) signatures

10 / 10 implemented · 2 not applicable

§3.6.1
v= must be the first tag when present
yes
§3.6.1
A version other than DKIM1 makes the record unusable
yes
§3.6.1
k= defaults to rsa when absent
yes
§3.6.1
An empty p= means the key has been revoked
yes
§3.6.1
A record with no p= tag is malformed
yes
§3.6.1
t=y marks the domain as testing, so receivers must not act on failures
yes
§3.2
A duplicated tag makes the record unusable
yes
§3.6.1
p= is a DER SubjectPublicKeyInfo, base64 encoded
yes
§2.10
Folding whitespace is permitted at arbitrary places inside a base64 value
yes
§3.2
Tag values are case-sensitive unless a tag says otherwise, so base64 key material is compared exactly
yes
§6.1
Verifying a DKIM-Signature header against a message body
Verifying a signature needs the message, which a records check does not have. We check that the published key is present, parseable, of a usable algorithm and length, and is the key that was issued.
n/a
§3.4
Header and body canonicalisation
Canonicalisation applies to a message being signed or verified, not to a key record.
n/a

RFC 6891

Extension mechanisms for DNS (EDNS(0))

2 / 2 implemented

§6.2.3
A requestor advertises its receive buffer size in the OPT record, and 512 octets applies when no OPT is sent
yes
§6.2.4
A response larger than the advertised buffer is truncated with TC set rather than sent whole
yes

RFC 7208

Sender Policy Framework (SPF)

25 / 28 implemented · 2 not applicable

§4.5
Records not beginning with v=spf1 are discarded before any are counted
yes
§4.5
More than one SPF record is a permanent error
yes
§4.6.2
A mechanism with no qualifier is treated as +
yes
§4.6.4
At most ten terms causing DNS queries, across the whole include tree
yes
§4.6.4
At most two void lookups
yes
§4.6.4
An mx mechanism must not expand to more than ten names
yes
§4.6.4
Address lookups behind an mx mechanism are outside the ten-term limit
yes
§4.3
An empty MAIL FROM is treated as postmaster at the HELO domain
yes
§5.2
An include: target with no SPF record is a permanent error
yes
§5.2
An include: matches only when the recursive evaluation returns pass
yes
§5.5
ptr is valid syntax and SHOULD NOT be published
yes
§5.5
Evaluating whether a ptr mechanism matches a given client
Deciding one needs a reverse lookup of the connecting address and a forward confirmation of every name it returns. We report the term as undetermined for a specific sender rather than guessing, which is visible as SPF_IP_UNDETERMINED.
no
§5.6
ip4 matches only IPv4 clients and ip6 only IPv6 clients
yes
§4.6.2
The result is the qualifier of the first matching mechanism
yes
§6
redirect= and exp= must not appear more than once
yes
§6.1
redirect= is ignored when the record contains an all mechanism
yes
§6.1
A redirect's result is the record's result, unlike an include
yes
§6.2
Fetching and macro-expanding exp= text on a fail
exp= text is fetched only to build a rejection message after the outcome is already decided, so it changes no verdict. Parsing the modifier is implemented; retrieving and expanding the explanation string is not.
no
§7.1
Macro grammar: letters, transformers, delimiters, and the %% %_ %- escapes
yes
§7.2
The c, r and t macros are valid only inside exp= text
yes
§7.3
Expanding the %{p} macro
It is the validated domain name of the connecting address, which needs the same reverse lookup and forward confirmation as the ptr mechanism. §7.3 advises against publishing it. Reported as unevaluable rather than guessed.
no
§7.3
Transformers apply in order: split, reverse, then keep the rightmost N
yes
§7.3
An uppercase macro letter URL-escapes its expansion
yes
§7.3
An expansion longer than 253 characters loses leading labels rather than being rejected
yes
§7.3
%{i} is dot-separated nibbles for IPv6, and %{v} is ip6 rather than in-addr
yes
§4.4
A DNS failure during evaluation is temperror, distinct from permerror
yes
§4.6.4
The total time spent evaluating a record is bounded, not only the number of lookups
yes
§4.7
A record that matches nothing and has no all evaluates to neutral
yes
§9.1
Receivers prepend a Received-SPF header
We audit the record rather than serving a message, so there is no reply to insert a header into.
n/a
§2.3
Checking HELO identity in addition to MAIL FROM
A property of the sending MTA's configuration, not of the domain's records.
n/a

RFC 7489

Domain-based Message Authentication, Reporting and Conformance (DMARC)

8 / 8 implemented · 2 not applicable

§6.6.3
Query the exact name first, then the organizational domain, and no further
yes
§6.6.3
Records not beginning with v=DMARC1 are discarded before counting
yes
§6.6.3
More than one DMARC record means no policy is applied
yes
§6.3
v= must be the first tag
yes
§6.3
adkim and aspf default to relaxed; pct defaults to 100 and is 0–100
yes
§6.3
p= is none, quarantine or reject
yes
§6.3
sp= governs subdomains only when the policy came from the organizational domain
yes
§7.1
An external report destination must publish <source>._report._dmarc.<destination>
yes
§6.6.4
Applying the policy to a failing message, including pct sampling
Applying a policy needs a message that failed authentication. We report what the policy would do, which is what a domain owner can act on before any mail is sent.
n/a
§7.2
Producing aggregate and failure reports
Generating aggregate reports is a receiver's job. We check that the addresses they would be sent to are authorised to receive them, which is the part domain owners get wrong.
n/a

RFC 7505

A null MX resource record

2 / 2 implemented

§3
A null MX (preference 0, exchange root) means the domain accepts no mail
yes
§3
A null MX must be the only MX record
yes

RFC 8463

Ed25519 signatures for DKIM

1 / 1 implemented

§3
k=ed25519 keys are a raw 32-byte public key, base64 encoded
yes

RFC 8659

DNS Certification Authority Authorization (CAA)

6 / 7 implemented · 1 not applicable

§3
The search climbs from the name up to, but not including, the root
yes
§3
The nearest ancestor with a CAA RRset governs; policies are not merged
yes
§3
The climb crosses zone cuts
yes
§4.1
An unrecognised property with the critical bit forbids issuance entirely
yes
§4.2
issue/issuewild values are a CA domain with optional ;key=value parameters; empty means deny all
yes
§4.3
issuewild governs wildcard issuance exclusively when present
yes
§4.4
Reporting a rejected issuance to the iodef address
iodef addresses are parsed and reported. Sending a report is an authority's job at issuance time, not a checker's.
n/a
§5
A CA must consider the DNSSEC validation state of the RRset
The DNSSEC state of the CAA RRset is what a CA must consider. We rely on the resolver's validation rather than validating ourselves — see the DNSSEC entries.
no