Domain Governance Baseline Practice guide 03 · Email authority and public signals
From baseline to practice · Guide 03

Know who may send in the organisation's name and whether the public evidence matches that authority.

Govern email authority and public signals.

Establish a dependable record of authorised senders, authentication paths and public mail posture - then reconcile SPF, DKIM and DMARC evidence with what the organisation has actually approved.

For technology and risk generalists Eight practical steps Authorised-sender CSV Public-signal review record
Download sender-register CSV Download signal-review record Open the baseline
Outcome

Sending authority that can be named, evidenced and withdrawn

The organisation should be able to identify every approved sending domain and provider, explain the identities they use, show how SPF, DKIM and DMARC support that authority, review public evidence and remove authorisation when a service, supplier or campaign ends.

Scope

Separate internal authority from public evidence

Email authority spans business approval, sending platforms and published DNS signals. A record that passes a lookup may still authorise an unknown supplier, and a legitimate sender may fail because its identity paths are not aligned.

Organisational authority

Who approved the sender, what business purpose it serves and who is accountable for continuing or withdrawing that authority.

Sending-system authority

Which productivity, application, marketing, service or supplier platforms may originate mail using the organisation's domains.

Authentication authority

Which envelope-from and DKIM signing identities support SPF and DKIM alignment with the visible From domain used by recipients.

Public evidence

What MX, SPF, DKIM, DMARC and related DNS records show, and what DMARC reporting reveals about observed use and failure.

A passing signal is not the same as approved authority. Public records can show that a mechanism exists. Only an internal owner and authorised-sender record can establish whether a sending system is expected, accountable and still required.
Method

Establish email authority in eight practical steps

  1. 1

    Start from the domain register

    For each material domain and subdomain, state whether it sends mail, receives mail, does both or should do neither. Unknown email use should remain visible as a governance gap.

  2. 2

    Enumerate every approved sending system

    Include staff mail, transactional applications, customer platforms, marketing services, ticketing systems, suppliers and temporary campaigns. Do not assume the primary mail platform is the whole answer.

  3. 3

    Record the identities each sender uses

    Capture the visible From domain, envelope-from or return-path domain, DKIM signing domain and known selectors. These identities determine whether SPF or DKIM can align for DMARC.

  4. 4

    Assign ownership and a withdrawal path

    Name an accountable business owner and technical operator for every sender. Record how authority and DNS records will be removed when the supplier, application, campaign or business purpose ends.

  5. 5

    Govern SPF, DKIM and DMARC together

    Authorise only required sending paths, enable DKIM signing through approved domains, and maintain a DMARC policy and reporting destination. Treat changes as controlled changes to public authority.

  6. 6

    Make non-sending intent explicit

    For domains that should not send, publish and maintain an explicit non-sending posture appropriate to their receiving requirements. Confirm that no application or supplier relies on hidden or historical use before enforcement.

  7. 7

    Reconcile public signals and DMARC reports

    Compare observed SPF, known DKIM selectors, DMARC policy and reporting with the authorised-sender record. Investigate unexpected providers, unaligned legitimate traffic, obsolete records and repeated unauthorised use.

  8. 8

    Review change, suppliers and exceptions

    Review sending authority at least quarterly and after supplier onboarding, offboarding, platform migration, brand change, incident or material DMARC-policy change. Give every exception an owner and expiry.

Authorised-sender record

Record enough to explain who may send and how

Use one row for each material sending domain, subdomain or distinct provider path. The record is an authority map, not a mail-flow troubleshooting database or replacement for provider configuration.

Sending domain or subdomain
The identity whose authority is being governed.
Business purpose
Why sending is required and which organisational outcome it supports.
Accountable owner
The role answerable for continued use and approval.
Technical operator
The team or supplier that administers the sending path.
Sending system or provider
The productivity, application, campaign or supplier platform originating mail.
Message type or audience
Staff, transactional, customer, supporter, marketing, security or another material category.
Visible From domain
The domain recipients see in the From address.
Envelope-from or return-path domain
The domain used for SPF evaluation, bounce handling and alignment.
DKIM signing domain and selectors
The approved signing domain and known selectors used to validate the sender.
SPF authorisation and alignment
How the sender is authorised and whether the return path aligns with the visible From domain.
DMARC policy and report destination
The applicable policy plus the monitored destination for aggregate reporting.
Last evidenced
The date configuration and public signals were last confirmed.
Next review
The scheduled review date for continuing authority.
Exception or next action
The specific gap, exception owner, expiry or remediation required.
Portable authority record

Maintain the sender register where governance already lives

The blank CSV can be used in an approved spreadsheet, messaging register, CMDB, supplier record or control repository. The worked example illustrates staff, campaign and non-sending domains using reserved examples.

Blank sender CSV Worked example CSV
Public evidence

Review what is observable without overclaiming what it proves

Public observations are useful evidence because they show what recipients and external systems can see. They should be reconciled with approved internal authority, not interpreted as a score or a complete view of provider configuration.

Expected authority
The approved senders, identity domains and non-sending decisions from the internal register.
MX posture
The publicly visible receiving route and whether it matches the expected provider or no-receive decision.
SPF posture
The published policy, included providers and unexpected or overly broad authorisation paths.
Known DKIM selectors
The selectors supplied by approved systems. DKIM cannot be comprehensively assessed without knowing which selectors to query.
DMARC posture
The organisational policy, applicable subdomain policy, alignment settings and reporting destinations.
Aggregate report themes
Legitimate failure, unauthorised use, alignment gaps and unexpected sources requiring ownership or investigation.
Additional transport signals
MTA-STS, TLS-RPT or other public controls where the organisation has chosen to operate them.
Difference and decision
The gap between expected and observed authority, plus the owner and action required.
Use with existing review processes

Email public-signal review record

A plain Markdown record for a quarterly review, supplier check, change, incident or DMARC-policy decision. It performs no lookup and contains no workflow logic.

Download review record Observe current signals
Evidence and cadence

Know when email authority is genuinely governed

Evidence of practice

  • A current sender register covers material sending domains and providers.
  • Every sender has an accountable owner and withdrawal path.
  • Visible From, return-path and DKIM identities are known.
  • SPF, DKIM and DMARC posture matches approved authority.
  • DMARC aggregate reports have a monitored destination and review owner.
  • Non-sending domains have deliberate, evidenced treatment.
  • Recent supplier or platform offboarding removed obsolete authorisation.

Review it when

  • The scheduled quarterly or more frequent review falls due.
  • A sender, application, campaign or supplier is introduced or retired.
  • SPF, DKIM, DMARC, MX or related DNS records change.
  • A domain, brand, mail platform or return-path design changes.
  • DMARC reports show new, failing or unauthorised sources.
  • An email impersonation, deliverability or supplier incident occurs.
  • An exception or temporary sender reaches its expiry date.
Common failure modes

Authentication records can exist while authority remains unclear

Only the primary mail platform is recorded

Applications, CRM systems, marketing platforms and suppliers continue to send without appearing in the approved authority view.

SPF includes have no owner

A provider remains authorised because nobody can explain why it is present or whether any active service still depends on it.

DKIM is marked “enabled” without identity detail

The signing domain and selectors are unknown, so alignment and continuing provider authority cannot be evidenced.

DMARC reporting is collected but not reviewed

Reports arrive at a mailbox or service, but no accountable process turns repeated failures or unexpected sources into action.

Policy remains observational indefinitely

Temporary monitoring becomes permanent because legitimate senders were never fully identified or given owners and remediation dates.

Non-sending domains remain ambiguous

Defensive, redirect and legacy domains have no deliberate mail posture and may retain accidental or inherited sending authority.

Supplier offboarding leaves DNS authority behind

SPF includes, DKIM records, return paths and verification records remain after the business relationship has ended.

A clean lookup is treated as assurance

Published records appear healthy, but the organisation cannot show approved senders, owners, reporting review or withdrawal controls.

Return to the baseline

Email governance should make two answers demonstrably stronger

Revisit the questions about which domains are authorised to send and whether SPF, DKIM and DMARC are configured and reviewed. The organisation should now be able to name approved senders, evidence alignment and public posture, explain report ownership and withdraw obsolete authority.

Return to the baseline Review guide 02 Back to practical guidance