Who Handles Email Authentication When Suppliers Share the Work?

Email authentication needs a clear handoff when an MSP, web agency and application supplier control different parts of the setup. Existing email and DNS support may already cover it. The useful question is who takes the request through to a working sending configuration, not whether every SPF change needs a separate process.

A client asks to connect a newsletter platform. The platform supplies account-specific records; the web agency holds the DNS login; the MSP supports the client's mailboxes. There may be no technical dispute. Someone just needs to know who will complete the request.

That is a reason to clarify a handoff, not automatically a reason for a new service or an elaborate approval process.

Start with the support arrangement already in place

If the MSP handles email and DNS changes, the existing ticket process may be enough. The request can contain the platform's instructions, the relevant domain and a contact who can send a test message.

Where another supplier controls DNS or the sending application, agree who will pass on the settings and who will confirm the result. The client should not have to guess which supplier to contact next.

ASD's guidance on external email providers recognises that business units can engage sending services directly. It supports making responsibilities clear; it does not establish that every small DNS change needs a new management workflow.

The application account matters as much as DNS access

The right records depend on how the sender is configured. Amazon SES, for example, supports a provider-owned MAIL FROM domain or a custom subdomain. A product name alone does not establish that the client's root SPF record needs editing.

The person with access to the application can supply the account's instructions. The DNS administrator can reconcile them with existing records. In a small business, that may be the same person.

After a relevant change, a test from that application can confirm the path being changed. That is more useful than assuming publication in DNS proves the application is using the intended settings. It is also a narrower claim than proving that every client email will reach an inbox.

Define the boundary only where it is unclear

An SPF change, a DMARC policy decision and an investigation into a missing email are different requests. DMARC evaluates authentication and alignment; it does not make an MSP responsible for every action of a recipient's mail system.

If those boundaries are causing repeated disputes, describe them in the service scope. If the existing arrangement already works, there is no need to invent an email-authentication workstream.

A clear handoff can reduce avoidable back-and-forth when a sender fails. That coordination consumes technical time whether support is included or billed separately. Our article on the support cost of SPF failures explains why the work can extend beyond the DNS edit.