Identify the authority before describing an obligation
A claim that Saudi Arabia requires a particular email setting is incomplete without the authority, covered population and control wording. A country label can hide differences between a regulatory control, a customer's contractual requirement and a receiving provider's delivery policy. The operator needs to know which of those relationships applies before deciding what evidence to collect or which change to propose. A familiar compliance abbreviation is not enough.
The accessible NCA-hosted Essential Cybersecurity Controls text, ECC 2:2024, supplies an authoritative starting point. Its English scope covers government agencies and affiliated entities inside and outside the Kingdom, plus private entities owning, operating or hosting Critical National Infrastructures. It encourages other entities to use the controls. The document makes Arabic the binding interpretation. These distinctions must survive any shorter explanation of the email requirement.
Preserve the source and its review boundary
Research on 8 November 2026 retained the official English PDF and relevant passages. The NCA landing page, email-verification service page and separate implementation-guide fetch timed out; they were stopped without retry or alternate retrieval. Their detailed current content has not been verified. The article therefore identifies the exact accessible edition, rather than claiming a complete survey of every current Saudi circular, service procedure or sector-specific requirement.
A proposed authority record should retain the issuing body, document title, edition, language, relevant page, precise clause and source-review date. Add a field for the organisation's applicable effective date or transition arrangement, but do not populate it from a filename or a webpage publication date. Where a binding-language review or later source check is missing, mark that gap explicitly. A reviewer should be able to reproduce the route from the source to the proposed conclusion without relying on a sales presentation.
Translate the clause into separate evidence questions
Subcontrol 2.4.3.5 names SPF, DKIM and DMARC for validation of the entity's email service domains. The surrounding email-protection section separates approved requirements, implementation and periodic review. These are different kinds of evidence. A policy document can show an intended requirement while leaving the actual configuration unknown; a configuration screenshot can show a setting while leaving operation and oversight unproved.
The corresponding technical questions should be explicit. Which service is permitted to send using the relevant domain? Which signing domain and selector does it actually use? Does a receiving system observe the intended aligned authentication? Current DMARC defines alignment and policy behavior, while DKIM describes the signature and key relationship. Those protocol sources explain what to examine; they do not establish that the organisation has met the regulatory control.
Avoid adding a policy value that was not established
Do not replace the control's protocol names with an invented universal p=reject deadline, a guaranteed delivery outcome or an assumption that one vendor must be used. A particular organisation may have additional requirements, but each needs its own authoritative or contractual basis. Keep the original source wording separate from the implementation choice, the risk decision and the approval that supports that choice.
Likewise, the existence of an official verification service would not prove that a specific submission has been accepted or that all relevant routes work. No such service was used here. A domain record can be present while a third-party sender lacks alignment, and one successful route cannot establish coverage of every application. Avoid reducing the task to a single green status that omits service ownership, legitimate exceptions and the evidence period.
Work through a fictional supplier example
Consider a fictional supplier that serves a Saudi customer and sends invoices through two hosted platforms. Start by asking the appropriate reviewer what brings the supplier or service into scope. A customer location does not by itself prove the supplier owns critical infrastructure, is a government affiliate or has accepted a particular contractual clause. If the relevant basis is a contract, record that contract relationship instead of mislabelling it a universal national duty.
Then create separate rows for the invoice application, corporate mailbox service and any dormant domain. Each row should name the intended purpose, owner, identities, relevant control basis and missing operational evidence. Keep supplier statements distinct from observations made by an authorized operator. This example contains no actual organisation, customer contract, message or DNS result. It illustrates the reasoning required to avoid granting a broad approval to an unexamined service.
Prepare the specialist review without pre-empting it
Commissioning calls for this exact evidence: “An authority-to-control table reviewed by the appropriate regulatory or legal specialist.” Our accompanying map is a proposed structure, not that reviewed table. It contains no actual entity classification, approved applicability decision, binding-language interpretation, implementation result or acceptance signature. The exact commissioning requirement remains open, together with technical review and the source-currentness limitations already described.
Give the eventual reviewer a concise evidence bundle rather than an unsupported compliance conclusion. Separate what the primary text says, what the organisation has established about itself, what the operator has observed and what someone has authorized. Obtain approval before collecting sensitive operational records or sharing them with a provider or regulator. No DNS change, account access, credential action, external disclosure, service submission or publication occurred. The practical result is a traceable question set that can support a real review, not a certificate that the domain or organisation complies.