[ Business value ]

Estimate implementation effort from senders, domains and ownership complexity

Estimate rollout effort from the actual sender and ownership graph, not a domain count alone.

By the EmailAuth research team · 4 min read

[ Key points ]

  • Estimate rollout effort from the actual sender and ownership graph, not a domain count alone.
  • Separate active implementation work from waiting on access, owners and suppliers.
On this page
  1. Build the purpose and owner register
  2. Look for hidden work
  3. Work an explicit illustrative estimate
  4. Re-estimate after a representative pilot
  5. Synthetic purpose-and-owner register
  6. Separate schedule from effort at the gate
  7. Source scope

Ten domains with one controlled mail service can require less work than one domain used by many independent applications. Implementation effort follows dependencies: who controls DNS, who can change each sender, which workflows must be tested and how quickly owners can approve work. Count those dependencies before promising a schedule.

Build the purpose and owner register

For each domain and relevant subdomain, record legal controller, DNS administrator, sending purpose, receiving purpose, service owner and change authority. Keep sending and receiving decisions separate. A domain that no longer sends marketing mail may still receive invoices or password-reset replies. An acquisition may introduce an external DNS agency, a legacy application and an owner who cannot approve changes in the new organisation.

Map sending routes rather than assuming an IP identifies one application. Record the visible From domain, authorised service and available authentication evidence. RFC 9989 provides the protocol's alignment and policy model; it does not tell you which applications your organisation has authorised.

Look for hidden work

Ask finance about monthly invoices, HR about annual benefits notices, support about ticket systems and application teams about recovery messages. Review available reports alongside service inventories and controlled samples. RFC 9990 reporting is useful evidence from participating receivers, not a complete discovery guarantee. A missing report row does not prove a service never sends.

Classify each route as verified, needs service configuration, needs ownership resolution, or needs retirement decision. Record missing access as a dependency, not as productive engineering hours. A two-hour configuration task can wait weeks for a supplier approval; distinguish effort from elapsed time.

Work an explicit illustrative estimate

Suppose an invented estate contains six straightforward routes needing two hours each, three integration routes needing six hours each, and two disputed-owner routes requiring four hours of investigation each. Configuration and investigation total 38 hours. Add an explicitly assumed eight hours for controlled testing and four for change review: 50 hours. None of these durations is a benchmark. Replace them with measurements from your pilot, and show waiting time separately.

Use a low, central and high estimate only when you can explain what changes between them. For example, the high case might require supplier remediation for a signing limitation; it is not simply the central number multiplied by an unexplained percentage. Keep a dependency owner and next review date for each unresolved item.

Re-estimate after a representative pilot

Choose routes that expose the estate's complexity, including one third-party service and one infrequent flow. Record actual hands-on effort, handoffs, failed attempts and elapsed approval time. Update the estimate before expanding. The exit evidence should include accountable owners, observed route tests and an approved plan for remaining exceptions, not just a published DNS record.

Synthetic purpose-and-owner register

This is a synthetic worked artifact. Actual observations, approvals and commercial commitments are not supplied.

  • billing.example.test / invoices: Purpose and accountable roles: Sending: invoices; receiving: customer replies. Finance owner; DNS operations.; Hidden-flow check: Check monthly invoice job and reply routing; not executed; Sending / receiving decision: Remediate sending after test / retain inbound replies.
  • events.example.test / event notices: Purpose and accountable roles: Sending: seasonal invitations; receiving: attendee responses. Events owner; agency DNS dependency.; Hidden-flow check: Check annual event scheduler and old campaign tenant; not executed; Sending / receiving decision: Hold sending decision / retain response path.
  • recovery.example.test / password reset: Purpose and accountable roles: Sending: account recovery; receiving: help escalation. Identity owner; application team.; Hidden-flow check: Check dormant account recovery and disaster-recovery tenant; not executed; Sending / receiving decision: Verify both active and dormant sending / separately assess help route.
  • legacy.other.test / acquired app: Purpose and accountable roles: Sending purpose unresolved; receiving: possible supplier invoices. Acquisition lead; former DNS operator.; Hidden-flow check: Search acquisition inventory and ask AP owner; not executed; Sending / receiving decision: No retirement decision / no receiving shutdown.

The estimate links six straightforward routes to the finance-type pattern, three integration routes to the identity-type pattern and two disputed-owner routes to the acquired-domain pattern. These are illustrative classes, not a counted estate. Agency approval and legacy DNS access are waiting dependencies outside the fifty hands-on hours.

Separate schedule from effort at the gate

Suppose the two disputed-owner routes cannot be approved during the pilot. The illustrative 50-hour estimate is still a work estimate, not permission to make those changes or a completion date. Release only a separately approved, tested scope and keep the disputed routes as named dependencies. Parallel staff can reduce some elapsed time, but cannot eliminate a missing approver or safely divide a single unresolved ownership decision.

Source scope

RFC 9989 Sections 4.4, 5.3.5 and 5.4 distinguish alignment, message evaluation and receiver handling. RFC 9990 Sections 3.1, 7 and 8 describe aggregate evidence and privacy/security considerations. Neither specifies staffing hours, prices or commercial operating commitments. Work estimates, cost examples and evaluation gates here are original editorial guidance, not observed customer results or standards-mandated budgets.

[ Takeaway ]

Separate active implementation work from waiting on access, owners and suppliers.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Retain reproducible evidence

Map every business route and record the actual effort of representative changes.

Next steps

  1. Map each domain to sending and receiving purpose.
  2. Test infrequent and dormant workflows.
  3. Link estimates to actual route classes.

CISO / SecOps

Govern the residual responsibility

Resolve authority gaps and require separate approval for retiring sending or receiving functions.

Next steps

  1. Verify acquisition and agency change authority.
  2. Prevent receiving shutdown based only on sending retirement.
  3. Resolve disputed owners before restrictive changes.

Founder / Non-technical

Set the decision boundary

Ask for a dependency-backed range and separate elapsed time from labour.

Next steps

  1. Separate hands-on effort from approval waiting time.
  2. Fund a representative complexity pilot.
  3. Reforecast after ownership gaps emerge.

[ FAQs ]

Frequently asked questions

Is domain count enough for an estimate?

No. Sender diversity, access, ownership and testing requirements often drive the work.

Should inbound use be recorded?

Yes. Receiving services can remain important after sending stops.

Do reports find every sender?

No. Use reports with inventories, owner interviews and controlled tests.

How should missing access be estimated?

Record its owner and waiting dependency separately from hands-on work.

Are the fifty hours a benchmark?

No. They are explicitly invented inputs for a transparent calculation.

What makes a pilot representative?

Include the services and handoffs that create uncertainty, not only the easiest route.

Should failed attempts count?

Yes. They consume effort and reveal integration or ownership complexity.

When should the estimate change?

After pilot evidence, newly discovered senders or changes in scope and ownership.

[ Sources ]

Sources

  1. RFC 9989: DMARC

    Sections §4.4 · §4.7 · §4.10.1 · §5.3.5 · §5.4

  2. RFC 9990: DMARC Aggregate Reporting

    Sections §3.1 · §7 · §8

[ Glossary ]

Glossary

Hands-on effort
Time spent actively performing implementation work.
Waiting dependency
A prerequisite or approval that delays progress without itself being active engineering time.
Hidden flow
An infrequent or overlooked business message route requiring discovery and validation.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base