Did you know? A mail-sending AI agent can negotiate an encrypted SMTP connection without proving that the server it reached is the intended mail exchanger. DANE TLSA is a protocol mechanism for binding a TLS service’s certificate or public-key information to DNSSEC-validated records. For inter-server SMTP, it can protect specified destinations against certificate impersonation and attempts to suppress STARTTLS. It is not an inbox receipt or an assertion that the recipient has opened the message.
The useful rule is to preserve four different DNS outcomes. A secure usable TLSA record requires TLS with the specified peer authentication. A secure nonempty set containing only unusable records signals a distinct encryption requirement. A properly established insecure answer or authenticated absence can allow legacy opportunistic behaviour under the RFC’s conditions, while a bogus, indeterminate or failed required lookup calls for skipping that destination and delaying when there is no valid alternative. The agent must not convert a validation problem into permission to downgrade.
This article explains those distinctions through real standards, then builds original and fully checked teaching cases, failure diagnosis and changed-context practice. It covers current real-world agent-managed SMTP systems. Artificial superintelligence remains hypothetical, and no live network checks, certificate matches or mail deliveries are claimed in the illustrative examples.
Contents
- First define the claim: transport authentication, not email arrival
- Why the email address does not give you a TLS hostname
- Read the TLSA fields as a complete certificate-matching contract
- Secure, insecure, bogus and indeterminate are not synonyms
- What certificate authentication verifies and what it leaves open
- Worked case: one hundred and twenty SMTP attempts
- When the numbers are green but the trust decision is wrong
- Certificate rotation without an accidental outage
- Build a test matrix rather than one happy-path demonstration
- Define what the AI agent may do
- Where the guarantee stops
- Changed-context problem: a second MX host changes the result
- Frequently asked questions
- Next reading and normative primary sources
First define the claim: transport authentication, not email arrival
An agent-managed email workflow crosses several boundaries. A user authorises a particular message; an application prepares it; a mail transfer agent chooses the next hop; the remote mail server may accept responsibility for the message; and further systems may filter, store or deliver it to an eventual mailbox. The security of one SMTP transport connection is distinct from all these later outcomes. A reliable report names the exact boundary that was observed.
DANE for SMTP is concerned with the identity of the selected server and the negotiated encrypted channel. In traditional opportunistic STARTTLS, a sending server can offer encryption without a strong authenticated requirement that every destination support it. An attacker on a vulnerable path may suppress the announcement of STARTTLS. DANE uses DNSSEC-protected discovery and TLSA association records to provide a stronger authenticated expectation where the protocol is deployed correctly.
The principal specification is RFC 7672: SMTP Security via Opportunistic DANE TLS. It describes a downgrade-resistant approach for MTA-to-MTA traffic, with conditions on TLSA responses and different treatment for unavailable or unsupported security information. It does not guarantee end-to-end email secrecy when a message passes through other relays, and it cannot establish whether a human trusted or read the contents.
Imagine a delivery report that says ‘encrypted’ without indicating the authenticated server. That report may be technically true but insufficient for a claim that mail was transferred to the right next hop. A second report that says ‘DANE authenticated’ when the client saw only a DNSSEC-insecure answer would be materially false. Evidence should include server identity, DNSSEC disposition, the TLSA association actually applicable and the observed TLS result.
An agent may help classify these outcomes, but the authoritative checks belong to the DNSSEC validator and the SMTP/TLS implementation. A generated sentence does not become proof of certificate ownership, and a copied record from a webpage does not substitute for a validated DNS answer.
Why the email address does not give you a TLS hostname
An email destination such as student@school.example identifies an envelope recipient domain. The outgoing MTA generally looks up mail exchange, or MX, records to identify the servers that handle mail for that domain. These servers may belong to a different organisation and can have names unrelated to the recipient address. The certificate identity therefore cannot be inferred simply from the visible address on the message.
Suppose the fictional domain school.example has an MX answer listing mx-a.mail.example at preference 10 and mx-b.mail.example at preference 20. A lower preference value usually means a host will be considered earlier under the SMTP routing convention, but the value is not a trust score. Each selected host still needs appropriate address resolution and DANE policy evaluation. An arbitrary replacement hostname obtained from untrusted text must not be treated as a legitimate MX target.
On ordinary MTA-to-MTA SMTP the service commonly uses port 25. For a server named mx-a.mail.example, the TLSA owner is constructed using the relevant service labels, such as _25._tcp.mx-a.mail.example, subject to the specification’s MX, alias and resolution rules. This is deliberately different from an HTTPS TLSA record for port 443. A parser that silently substitutes ports because both connections use TLS can choose the wrong authentication record.
DNSSEC authentication matters because MX records themselves can be a target for redirection. RFC 7672 describes how secure versus insecure MX discovery affects the chain of trust and what server names are used for TLSA lookups. Validated negative responses, usable TLSA records and lookup failures have distinct meanings. Merely reaching a resolver over an encrypted network channel is not the same as validating the DNSSEC security of the returned records.
An audit record should retain the original recipient domain, selected unexpanded MX hostname, chosen address, DNSSEC result and actual TLSA base domain. Logging only the final IP address loses the context needed to establish why the server was trusted. This principle also applies to systems other than email: the path by which an endpoint was selected belongs in its trust evidence.
Read the TLSA fields as a complete certificate-matching contract
A TLSA record contains a certificate usage value, a selector, a matching type and certificate association data. The first three values are discrete fields, not informal tags. The association data contains selected certificate material directly or a cryptographic digest of it. RFC 6698 defines the format, and the current IANA DANE parameters registry records their assignments.
Usage 3 means a DANE end-entity association. Usage 2 refers to a DANE trust-anchor association. They do not use the same validation and name-check rules. In opportunistic DANE SMTP, RFC 7672 recommends appropriate combinations such as DANE-EE with the SubjectPublicKeyInfo selector and SHA-256 digest; usage 0 and usage 1 have PKIX-related meanings in the general framework but are not the basis for the same recommended opportunistic SMTP protection.
Selector 0 chooses the full DER-encoded certificate; selector 1 chooses SubjectPublicKeyInfo, representing the public-key algorithm and associated public key information. Matching type 0 means a direct match, type 1 means SHA-256, and type 2 means SHA-512. The common three-number prefix 3 1 1 therefore means DANE-EE, SubjectPublicKeyInfo and SHA-256. Each field is necessary to know what bytes must actually be compared.
A SHA-256 digest contains 256 bits, or 32 bytes. When presented as a series of hexadecimal characters, that takes 64 hexadecimal digits because one byte is represented by two hex characters. This calculation tells us the expected size of the digest; it does not certify that the digest belongs to a genuine SMTP server. A fabricated 64-character string has the right shape but no cryptographic evidentiary value.
The certificate comparison must use the peer’s actual presented certificate or key representation under the chosen selector and usage. Hashing the human-readable subject string or certificate file name is not equivalent to hashing the required DER structure. An incorrect byte transformation can produce a mismatch even though a human looking at the certificate sees the expected hostname.
For usage 3 under the specified DANE-EE semantics, the name-check behaviour differs from the requirements of usage 2. A generic TLS code path that applies every certificate-name rule identically may reject a valid DANE-EE peer or accept an invalid trust-anchor case. Protocol-aware testing is more reliable than a generic ‘certificate matches’ checkbox.
Secure, insecure, bogus and indeterminate are not synonyms
A DNSSEC-aware resolver classifies the security status of relevant answers. A secure answer has a validated chain of DNSSEC trust for the applicable records. An insecure answer can be legitimate when the zone or chain is not protected in the relevant way. Bogus means validation failed, while indeterminate means the resolver cannot establish the state. These categories are operationally consequential; translating them all into ‘DNS succeeded’ destroys information.
RFC 7672 goes further and defines the outcome of the TLSA lookup. When a secure answer contains at least one usable TLSA record, any connection to that SMTP server has to use TLS and authenticate the server against the applicable association. A failure to authenticate is not permission to try cleartext with that server. Another valid destination may be available, but the original trust requirement must remain intact.
When a secure, nonempty TLSA record set contains only records unusable by the sender, the RFC describes a distinct condition: TLS encryption is required, but authentication under a usable association is not achieved. A system must not describe that condition as DANE-authenticated delivery. It also must not pretend there was no TLSA signal. The exact fallback depends on the specification rather than a universal ‘best effort’ toggle.
When TLSA records are properly absent under authenticated denial or are associated with an insecure response under the RFC’s applicable circumstances, pre-DANE opportunistic TLS behaviour may be used unless another transport policy is stricter. That can include a connection without authenticated TLS. This is a different security outcome, and the agent should disclose the distinction rather than place it in the same category as strong DANE authentication.
When required resolution produces a bogus or indeterminate response, a timeout, SERVFAIL or other failure that prevents trustworthy TLSA discovery, the sender must treat that candidate destination as unavailable under the specified rules. If no legitimate alternative can be used, the message remains deferred. A transient DNS problem does not become proof that authentication was unnecessary.
This taxonomy turns abstract security into a concrete implementation test. Four apparently similar logs saying ‘could not use DANE’ may demand different actions. The first useful debugging question is therefore not ‘Should we retry insecurely?’ but ‘What exactly was the resolver’s status, which records were present and what does the normative transition require?’
What certificate authentication verifies and what it leaves open
In the DANE-EE case, the association can match the expected server end-entity certificate or key material through a DNSSEC-secure record. For a record using selector 1 and SHA-256, the sender checks the actual SubjectPublicKeyInfo bytes and compares the computed digest with the published association. A successful match can authenticate that TLS service under the standard’s trust assumptions. It does not claim the application behind the service is honest.
In a DANE-TA case, the TLSA association identifies a trust anchor for a certificate chain and the verification procedure also includes the applicable name checks. The server must provide appropriate chain material. The same peer certificate can have different acceptance conditions under usage 2 and usage 3, which is why the usage value is not optional parser metadata.
Authenticated transport is also not a digital signature on the message body. SMTP forwards can modify some headers, and other intermediaries may access content. End-to-end cryptographic message protection and domain-level email authentication mechanisms answer different questions. An agent reporting ‘secured email’ should identify whether it means transport to the next MTA, signed content or a stronger end-to-end policy.
Even a correct certificate match says nothing about the user’s authorisation to send a message. The sender might have chosen the wrong recipient or inserted private content into a payload. A complete workflow binds an approved recipient and message to the outgoing action independently of DANE, then treats mail-transfer evidence as one later stage.
That separation mirrors the existing outbound email safety guide. DANE adds a precise server-authentication job, not a replacement for recipient binding, content review or observed final outcomes.
Worked case: one hundred and twenty SMTP attempts
Here is a completely fictional log summary. A service makes 120 independent SMTP transport attempts under a policy that records DANE state. Sixty encounters select a server with a secure usable TLSA record, complete authenticated TLS and receive acceptance from the next-hop MTA. Thirty-five receive remote MTA acceptance under a permitted legacy opportunistic path. Fifteen are deferred after a secure usable TLSA association fails peer matching, and ten are deferred because a required DNSSEC lookup fails. The category counts sum to 60+35+15+10=120.
The proven DANE-authenticated acceptance rate is 60/120=50%. The legacy-path next-hop acceptance rate is 35/120≈29.17%. Authentication-mismatch deferral accounts for 15/120=12.5%, while resolution-related deferral accounts for 10/120≈8.33%. Overall, 60+35=95 transport attempts were accepted, or 95/120≈79.17%. Exactly 25/120≈20.83% remain deferred in the fictional snapshot.
Those percentages do not say that 95 people read an email. One recipient may generate several transport attempts, accepted mail can later bounce and multiple copies can exist. If the business question concerns distinct recipients informed, the attempt count is the wrong denominator. A credible report preserves stable message identity and reconstructs actual recipient-level outcomes from more than one transport log.
Suppose an engineer notices that 25 attempts did not complete and proposes ‘retry all with encryption disabled’. That is unsafe. The fifteen DANE authentication mismatches cannot be turned into unauthenticated acceptance at the same destination without violating the authenticated policy. The ten failed required DNSSEC lookups likewise cannot be reclassified as valid absence. Correct remediation investigates certificate rollout, signatures, timeouts and any genuinely authorised alternative MX host.
Even within the thirty-five legacy path attempts, a further distinction is needed. In an invented extension, suppose twenty-seven negotiated TLS successfully while eight were accepted without encryption. The counts 27+8=35 are consistent, but none of those twenty-seven is automatically a DANE-authenticated connection. Merely using TLS and proving authenticated next-hop identity are different technical events.
To make the report independently reviewable, store a row per attempt with the message reference, selected MX, DNSSEC status, applicable TLSA condition, negotiated TLS state, certificate authentication result and actual SMTP response. A dashboard can then calculate the right denominator without inventing success at a stage never observed.
When the numbers are green but the trust decision is wrong
A dashboard may display ninety-five accepted transports in a reassuring green bar. Yet if it does not distinguish the authenticated-DANE category from legacy acceptance, a reader could conclude that the entire batch was secured to verified receivers. Colour is no substitute for the category definition. The security state must be visible in text and reconstructable from the source events.
Another trap is logging the first candidate server’s successful DNS lookup while sending through a different fallback server. Authentication is tied to the actual endpoint selected for that connection. A record validated for mx-a.example cannot be copied into a claimed authentication result for mx-b.example without its own appropriate association and name rules.
Operational records can also lose their meaning after an update. A TLSA record may change during certificate rotation, and a later DNS query may show a different set from the one an earlier transport attempt used. Keep timestamps, actual selected records or sufficiently stable evidence references and resolver status with each attempt. Do not rewrite the historical decision as though it always used the latest record.
A queued email can eventually be delivered on a later attempt. The correct audit keeps both the failed or deferred original attempt and the later successful attempt, tied to one business message. Deleting the earlier failure because the final result improved prevents the operator from understanding recurring security misconfiguration.
A strong diagnostic interface therefore answers five separate questions: which host was targeted, what trust evidence applied, what handshake actually occurred, what SMTP response was observed and what remained unknown. It should not require readers to infer all five from one overloaded status named sent.
Certificate rotation without an accidental outage
Key and certificate rotation must be coordinated with the records that authenticated the old key. If a TLSA association is bound to the SubjectPublicKeyInfo digest, deploying a different public key may require publishing a corresponding new association. In a suitable controlled transition, compatible old and new TLSA records can coexist while caches and servers move through the rollout. The precise safe procedure depends on certificate usages, TTLs, DNSSEC signing and the receiving MTA implementation.
A rotation plan should identify each actual MX server, its presented certificate chain or key, applicable TLSA records, expected cache lifetimes and rollback conditions. Moving two servers at different times can produce intermittent failures if only one host and one record are kept in sync. The operator needs per-host verification, not one domain-level green indicator.
DNSSEC has its own keys, signatures and trust-anchor management. Rotating a TLS certificate is not the same event as rotating a DNSSEC signing key. Mistaking the two can lead to misdiagnosis: a bogus DNSSEC answer may result from signature problems even when the TLS peer’s certificate is unchanged. Conversely, perfectly validating DNS records can still publish a TLSA digest that does not match the peer.
The relevant operational primary source is RFC 7671, DANE Operational Guidance. It provides publication and rollover considerations that need to be paired with RFC 7672’s SMTP-specific requirements. An AI assistant should consult those documents and the organisation’s real configuration before preparing any privileged change.
After rollout, confirm both sides of the identity binding: validated DNSSEC TLSA data and the actual peer TLS representation under the specified usage and selector. A successful DNS update is not evidence that every MTA has started presenting the intended certificate; a successful TLS handshake without the expected association is not the same DANE authentication guarantee.
Build a test matrix rather than one happy-path demonstration
A useful testing plan begins with the basic secure usable record case. Publish or simulate a valid association and verify authenticated TLS to the intended endpoint. Next deliberately use a mismatched presented key and confirm that the client does not send in cleartext to bypass authentication. A test that merely reports the connection failed cannot establish that the fallback policy is safe; the test should inspect whether any weaker transport was attempted.
Test secure nonempty but unsupported TLSA records separately. Verify that the applicable encryption requirement is respected without falsely reporting DANE peer authentication. Then test a securely authenticated absence and a legitimately insecure DNS response under the RFC’s rules. These categories can support different permitted actions; they must not be flattened into one mock outcome.
Test DNSSEC bogus and indeterminate responses, resolver timeout, address lookup problems, multiple MX hosts and server-specific certificate differences. A failure at the first host may be followed by an authorised attempt at another host, but only with the second host’s own valid trust evidence. Ensure that message queue state and attempt records survive retries without pretending an unaccepted message was delivered.
Finally test certificate rotation. Keep an old valid key and new valid key across a documented overlapping record set, check both, then remove the old key according to real cache and signing conditions. A simulated result should be labelled simulation; actual production approval should require independent real-world checks in the environment concerned.
Never weaken a production DNSSEC trust model just to make a test pass. Use controlled test domains, independent reference results and authorised environments. Failure injection is valuable only when it can be executed without exposing real users’ messages or teaching an agent to evade a security requirement.
An incident review begins with a timestamp and the exact message-transport attempt, not a speculation about whether someone read an email. The reviewer records the intended recipient domain, the MX answer used, which resolver validated it, and whether that answer was secure, insecure, bogus or indeterminate. A later re-query might return different records after a DNS update, so it cannot retroactively establish what an earlier sender knew. Preserve the original evidence needed to audit that earlier decision.
Next establish whether the TLSA record set was validly retrieved and usable under the SMTP specification. A certificate mismatch, unsupported parameter and DNSSEC-signature failure are three different incidents. Each points to a different repair team and a different security consequence. If the system reports only a generic transport error, responders should recover the underlying stage rather than press a retry button that might secretly change the required authentication level.
Check how long the mail has been queued and which recipient-level deadlines are actually relevant. A security deferral can prevent unsafe delivery but may also mean a time-sensitive message did not arrive before a meeting or approval deadline. The agent should report that operational consequence and suggest a separately approved communication path where appropriate. It must not invent a direct recipient acknowledgement or independently override the security policy because the message appears urgent.
When several MX hosts are present, examine the valid trust conditions for each host independently. One host’s successful association cannot authenticate a different host, and a successful message through the second host does not make the first host’s failed verification harmless. Maintain a per-attempt record so that the final accepted state and the earlier deferred state both remain visible. That history can reveal recurring misconfiguration even when most messages eventually move.
Close the incident with a narrow causal statement and a prospective regression test. For example, a mistakenly published digest might be repaired by deploying matching associations and confirming an authenticated peer handshake, while a DNSSEC validation failure may require an entirely different fix. The runbook should identify who approved the change, what was observed afterward, what remained unknown, and which future test will detect the same failure without sending unsafe mail.
Define what the AI agent may do
An agent can collect observations, classify evidence, propose changes and produce an audit ledger. It can help a human reason about why a particular attempt deferred. But changing transport security policy, DNS zones, certificates or message routing is a privileged operation. Each requires specific authorisation and a verifiable change record rather than a general instruction to ‘get the emails out’.
Distinguish technical evidence from natural-language interpretation. A trusted resolver can report a DNSSEC disposition; a TLS implementation can record a certificate-match result; an SMTP server can acknowledge acceptance. The model may explain their meaning but should not invent or overwrite them. Any summary that raises the evidence level above the strongest observed event is a reporting defect.
Tool outputs can also be adversarial or stale. A pasted DNS record in a support ticket might contain a malicious instruction unrelated to the user’s question, or an outdated key. Treat such text as diagnostic material, not as an authority to deploy it. Only an appropriately authenticated and authorised configuration source should direct a privileged write.
On ambiguous network failure, the sender should preserve the queued message and attempt history, reconcile what the underlying MTA actually did and use bounded retries under the same security policy. If a result is unknown, report it as unknown. Blindly resubmitting a new message could create a duplicate business event even when the original transport later succeeds.
These controls are part of ordinary present-day engineering. Greater language fluency or more elaborate agent plans do not eliminate the need for authentic DNSSEC validation, cryptographic comparison and a decision owner who accepts the consequences of an exception.
Where the guarantee stops
DANE SMTP protects transport connections under specific DNSSEC and TLSA conditions. It does not prove end-to-end confidentiality across every mail relay, identify the sender to the human reader or prevent a mailbox from being compromised. Stronger requirements can demand additional mechanisms and organisational controls.
Not all destination domains publish the necessary secure usable records. A sender may therefore encounter a mixture of DANE-secured and legacy opportunistic paths. The correct adoption figure depends on the observed destinations and denominator; it cannot be inferred from one successful authenticated connection.
MTA-STS defines a separate method for signalling SMTP transport security policy, using a different discovery and policy model. Its specification is RFC 8461. A system can support several controls, but it must follow each one’s actual semantics rather than blending them into an imaginary universal certificate check.
Security also depends on correct resolver validation and operational maintenance. A DNSSEC compromise, a mismanaged trust anchor, an unsupported TLSA parameter or an incorrectly rolled certificate may change the result. The presence of a policy cannot compensate for its incorrect implementation.
No real email, DNS record or TLS certificate was checked while preparing the examples in this article. The numbers are original teaching cases, and the normative technical claims are grounded in the linked standards. Actual deployment requires separate testing by authorised operators.
Changed-context problem: a second MX host changes the result
Imagine the fictional domain school.example has two MX hosts. Host A is normally preferred and publishes a secure usable TLSA record, but its server has been rotated to a key that does not match. Host B also publishes a secure usable TLSA record and presents its correctly matching key. A sender must not turn off certificate authentication to send through A. It can consider B if B is an authorised routing alternative and its own security checks pass.
Suppose forty queued messages first encounter A’s mismatch. Thirty-six are subsequently accepted via authenticated TLS to B; four remain deferred because B cannot be reached. The alternate-host acceptance rate is 36/40=90%, and the remaining deferred share is 4/40=10%. These counts refer to fictional transport attempts and do not prove that thirty-six individual readers opened mail.
Now alter the case so that B’s required TLSA lookup is DNSSEC-bogus. The client cannot treat the condition as a benign record absence. With A’s certificate mismatch and B’s unusable DNSSEC evidence, the stipulated sender must defer the affected messages rather than downgrade its transport. The previous 90% toy acceptance rate no longer applies under the changed trust evidence.
Change the second condition again: B instead has an authenticated denial of TLSA records under the applicable RFC rules, and no independent stricter policy applies. The sender’s permissible legacy opportunistic behaviour can differ from the bogus case. The correct answer depends on the evidence classification, not merely whether the words ‘no TLSA’ appear in a log.
This transfer exercise shows what understanding adds beyond memorising steps. The same application, queue and two hostnames produce different allowed actions when one trust premise changes. Reliable reasoning names that premise and explains why the outcome changes.
Frequently asked questions
What is DANE TLSA in simple terms? It is a DNSSEC-backed way to associate a TLS service with certificate or public-key material that a client can authenticate according to the applicable protocol rules.
Does DANE prove the email reached the reader? No. It authenticates transport to an applicable next hop; inbox delivery, reading and consent remain separate events.
What does TLSA 3 1 1 mean? It uses a DANE end-entity association, SubjectPublicKeyInfo selection and a SHA-256 digest comparison.
Can an agent simply disable TLS after a failed DANE match? No. When a secure usable TLSA record applies, a failed authenticated handshake is not permission to send in cleartext through that destination.
Is a bogus DNSSEC response the same as no record? No. Bogus or indeterminate validation prevents a trustworthy lookup and triggers different handling from authenticated absence.
Does DNS over HTTPS alone guarantee DNSSEC validity? No. Encrypted transport to the resolver and DNSSEC validation of the record chain are distinct claims.
What is the difference between DANE-EE and DANE-TA? They use different certificate association and chain/name-check rules. The certificate usage field determines which rules apply.
Can old and new TLSA associations overlap during rotation? Suitable coordinated overlap can be part of a controlled rollout, but timing must follow real TTL, DNSSEC and server conditions.
Are all SMTP connections DANE secured? No. Coverage depends on deployment and usable secure records, and legitimate other policy paths may operate differently.
Why can a securely deferred message be an acceptable outcome? Because preserving a required authentication guarantee can be more important than falsely reporting a weaker connection as success.
Next reading and normative primary sources
For developers, implement explicit states for MX selection, DNSSEC status, TLSA applicability, peer matching, next-hop SMTP acceptance and final business outcome. Maintain an event ledger that identifies the message and actual destination. Test safe failure as thoroughly as success. The linked agent email delivery-state guide explains later-stage bounce and DSN evidence.
For administrators, use independently authenticated DNSSEC and certificate diagnostics before altering records. Plan key changes with full MX coverage, record TTL consideration, validated rollback options and explicit approval. Do not treat a plain DNS lookup as the same proof as a verified TLSA association under the SMTP protocol.
For learners, reconstruct the 120-attempt case with the four security outcome categories and show what changes when a bogus reply is replaced by an authenticated absence. The exercise teaches the transferable distinction between missing evidence and evidence of absence.
Original specifications: RFC 7672, SMTP Security via Opportunistic DANE TLS; RFC 6698, TLSA Record Format; RFC 7671, DANE Operational Guidance; IANA TLSA Parameters; and RFC 8461, MTA-STS. See How Super Intelligence Works for adjacent systems engineering concepts.