Almost none of the work in an authentication programme is DNS changes, and almost none of it belongs to the person running the programme. Committing to a date before mapping the dependencies is the most reliable way to miss it.
Who is on the critical path
| Party | What only they can do | Typical delay |
|---|---|---|
| DNS administrators | Every record change | Hours to a change window |
| Each platform owner | Configure a custom return-path or customer-domain DKIM | Weeks — they have their own backlog |
| The vendors themselves | Support alignment at all, on your contract tier | Weeks, or never |
| Finance or procurement | Identify platforms paid for on cards nobody tracks | One conversation, high value |
| Whoever owns the parked domains | Confirm they genuinely send nothing | Fast, and frequently nobody |
| The person who left | Explain the system nobody else knows about | Never. This is what the reports are for. |
The pattern that stalls programmes
You: "we need the marketing platform to sign as us" Owner: "I'll raise it with our account manager" Vendor: "that's available on the enterprise tier" Owner: "we're not renewing until March" Nothing is wrong. Nobody is obstructing. The programme is now gated on a contract renewal five months out, and the primary domain cannot reach enforcement until then.
This is the normal case, not the exception, and it is discoverable in week two by asking every platform owner one question: can this platform sign with our domain, and on our current plan? The answers determine the timeline far more than any technical work does.
What actually is yours
- Publishing records, and knowing which ones.
- Reading the reports and maintaining the sender inventory.
- Deciding when the evidence supports the next policy step.
- Chasing every party above, repeatedly, which is most of the calendar time.
- Saying no to a date the dependencies do not support.
Map the dependencies before the first status update
A programme plan that lists technical tasks against dates will be wrong, because none of the long poles are technical. Listing each sender against the party who must act and what they said when asked produces a plan that survives contact with reality — and makes visible, early, which single vendor is going to determine the end date.