Define the banking entity before measuring its domain
A bank-domain study must distinguish a licensed institution, a holding company, a brand, a branch and a technology service provider. These units can share a website or operate different domains, and their relationships can change through mergers or rebranding. A DNS observation at a brand's public website does not automatically describe the entire legal institution's email estate. The entity-domain mapping is therefore part of the evidence, not a preliminary detail to discard.
This manuscript proposes a method without collecting a bank population or scanning domains. It makes no claim about a real institution's security, compliance, solvency or customer risk. The goal is to produce a reproducible mapping and a technically bounded result rather than a league table built from ambiguous brand names.
Use an authority appropriate to the selected jurisdiction
For a US insured-bank scope, FDIC BankFind API documentation distinguishes institution data from location or branch data. That is a useful official source structure, not a global list of all banks or financial services. A study covering another jurisdiction must retain the relevant authority and its coverage. Do not mix different regulatory populations under one unqualified banking denominator.
The FDIC documentation also states that primary internet addresses are reported by institutions and that linked sites are outside FDIC's control. Its disclaimer is important for interpretation: a listed website is a source-supported mapping clue, not an endorsement of every page or a comprehensive inventory of sender domains. Retain the field provenance and verification date rather than treating the website field as a complete security assertion.
Build a relationship model instead of a flat name list
Create separate identifiers for the institution, parent group where relevant, branch or location and public brand. Link each sampled domain to the specific entity and source supporting that relationship. Record effective dates for mergers, renamed brands and retired domains. A single row labeled with a familiar banking group can hide several licensed entities and different operational responsibilities.
Define how shared domains are weighted. Counting every branch as a separate authentication deployment can give a large branch network disproportionate influence. Counting only the parent domain can omit subsidiaries with independent sending arrangements. Neither approach is inherently the right answer for every question; the study must choose a unit and explain its consequences before calculating any metric.
Separate sampled websites from the sender estate
An institution may use distinct domains for employee mail, customer notices, card services, surveys, marketing, recruitment and outsourced communications. A public website sample usually does not identify all of them. Do not generate plausible subdomains or search for customer messages to fill that gap without an authorized research scope. The mapping should say whether a domain is a sampled website, an independently evidenced sender or an unresolved candidate.
RFC 7208 evaluates SPF using the relevant SMTP identity. RFC 9989 evaluates DMARC alignment to the visible From domain and defines policy discovery. These rules make the limitation concrete: publication at one web domain cannot establish the authentication of messages sent through another domain or a supplier-controlled route.
Preserve control and attribution uncertainty
Registration information can help document a domain relationship but should not be treated as proof of current operational control. RFC 9083 defines RDAP objects, roles and events; RFC 9537 describes redaction information where implemented. A privacy-protected or incomplete response should remain a visibility limit, not an allegation that a bank is hiding ownership.
Likewise, a shared DNS host or sending provider does not establish that the institutions share a security policy or administrative account. Record the observed dependency separately from inferred control. If ownership or sender attribution cannot be supported, mark the relationship unresolved and exclude it under a declared rule rather than asserting certainty from a familiar service name.
Design the DNS measurement independently
Freeze the mapped domain list and specify exact owner names, record types, resolver context, timestamps, retries and parser versions. Distinguish an exact-name lookup from current applicable-policy discovery. Retain raw answers and error categories so another analyst can reproduce the result. A failed query should not be described as a bank having no authentication without the relevant evidence and scope.
Keep authoritative and recursive observations separate where collected. Preserve multiple TXT records and strings before protocol selection. A classification should identify what was observed at the sampled name, not a whole-institution pass or fail. No DNS queries, SMTP probes or received-message samples were collected in this work.
Avoid consumer-risk and compliance inferences
DNS publication alone does not show whether customer financial information was exposed, whether fraud occurred or whether an institution complied with a legal requirement. Those conclusions require different evidence and qualified review. A missing or invalid policy observation can justify a technical finding within the study's scope without becoming a claim about the safety of the bank's services.
Do not rank institutions by a simplistic authentication score unless the measure, weighting and limitations are transparent and justified. A policy requesting enforcement does not prove that every legitimate stream is aligned or that all impersonation is prevented. The study should avoid implying that a lower observed setting directly predicts a customer's financial loss.
An entity-domain mapping worksheet
Create columns for jurisdiction, authority source, source date, institution identifier, entity type, parent relationship, brand, branch relationship and sampled domain. Add domain-link evidence, effective dates, mapping confidence, domain role, query plan and exclusions. Preserve a relationship table when one-to-many mappings cannot be represented faithfully in one row.
The release package should include the mapping, source provenance, normalized query inputs, raw observations and classification rules. A reviewer should be able to follow a published finding back to the institution and exact domain without guessing which brand or subsidiary was intended. Sensitive customer data, account details and private employee information are unnecessary for this method and must not be collected to embellish it.
Fictional diagnosis: a group website becomes every subsidiary
A fictional researcher selects a banking group's public website and reports its observed policy as the result for every subsidiary. The mapping review finds that the source list distinguishes several institutions, while the domain evidence supports only the group website. The proposed correction is to publish the narrower website observation and mark the wider sender estate unmeasured.
The team could later obtain authorized subsidiary-domain evidence and expand the scope under a revised dataset version. It should not fill the gaps with guessed names or imply a security defect because the mapping is incomplete. This scenario is fictional and contains no real bank, domain, scan or compliance allegation.
Release status
The catalogue requires publication of the entity-domain mapping and a distinction between sampled web domains and the wider sender estate. That original mapping remains open. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. This draft supplies a bank-specific research design, not a populated dataset or findings about institutions.