---
id: TST-PFM-NOT-058
title: provision sender identity
kind: integration
product_area: platform
module: notifications
revision: 1
status: draft
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
repository: services-platform
files:
  - >-
    modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js
implements:
  - ATS-PFM-NOT-020-09
  - ATS-PFM-NOT-020-10
  - ATS-PFM-NOT-020-11
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 5
isolation: >-
  Suite-owned records in the prepared integration workspaces; seeded workspace
  identities remain shared fixtures.
assertion_bindings:
  - scenario: ATS-PFM-NOT-020-09
    suite: TST-PFM-NOT-058
    assertions:
      - >-
        services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js#creates
        the domain identity and the address identity, in that order
      - >-
        services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js#stores
        the CNAME records the customer must publish, one per DKIM token
      - >-
        services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js#leaves
        the setting pending, because nothing it did proves the customer
        published anything
      - >-
        services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js#adopts
        the identities the first run made rather than failing on them
      - >-
        services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js#creates
        nothing in SES for it
  - scenario: ATS-PFM-NOT-020-10
    suite: TST-PFM-NOT-058
    assertions:
      - >-
        services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js#is
        verified as soon as any identity will send, because that is when SES
        accepts mail from the address
      - >-
        services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js#is
        pending while an identity is still waiting for the customer’s DNS
  - scenario: ATS-PFM-NOT-020-11
    suite: TST-PFM-NOT-058
    assertions:
      - >-
        services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js#deletes
        every identity the setting named
      - >-
        services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js#fails
        for an operator rather than reporting a sender gone that can still send
evidence:
  - >-
    services-platform:modules/communications/tests/integration/services/sender-identity/provision-sender-identity.integration.spec.js
  - The file and referenced assertion titles exist at the pinned commit.
dependency_evidence:
  - >-
    Real: PostgreSQL (the prepared integration database, row-level security on),
    the participant, the sender-identity
  - >-
    persistence service and the tenant-resource registry. Doubled: SES, at the
    one seam the deployed code reaches it through
  - >-
    Never doubled: the database, the resource registry, the participant's own
    decisions or the record's rules.
---

# provision sender identity

## Verification Boundary

This suite exercises the local services and prepared PostgreSQL database. API lifecycle cases use signed test contexts through the real route handler; they do not invoke the deployed gateway.

## What This Suite Proves

Its cases exercise provision or adopt the requested provider identities; preserve first verification through later provider states; remove scoped sender and stored communication data.

The registered scenario bindings identify the assertions this executable file contributes. They retain individual test references so that a composite scenario does not become a claim of complete execution by one file.

## What It Does Not Prove

Local outcomes do not prove deployed queues, external provider acceptance, production credentials or complete browser behavior. No fresh execution or conformance result is claimed.

## Real Dependencies and Test Doubles

The communication fixtures use real PostgreSQL and module logic. Shared support records queue and transport calls and stores objects in memory; sender provisioning substitutes a provider identity store. Signed API contexts replace the authorizer key in API suites.

## Must Not Be Doubled

Database constraints, workspace policy, state guards and the service operation under test must remain real. Recording a provider or queue call must not replace the submission, claim or outcome logic being checked.