The person who can edit DNS may not know which applications send email. That split makes even a small SPF change depend on several suppliers.
Changing an SPF record may take only a moment once the right change is known. Finding out what belongs in it can take longer when DNS access and email service settings sit with different people.
The web agency may control DNS. The IT provider may manage Microsoft 365. Someone in finance may administer the invoicing platform. Each has part of the answer.
DNS access is not the same as knowing the senders
The person editing DNS can publish a requested record without knowing whether it preserves every service the business uses.
An unfamiliar entry might be obsolete, or it might authorise an application that sends only occasionally. Removing it based on its name alone risks interrupting legitimate email.
The Australian Cyber Security Centre’s advice on external email providers reflects this division: authentication arrangements need to account for the services sending on the organisation’s behalf. Email marketing and filtering providers
The application settings determine which record matters
Amazon SES illustrates why the service name is not enough. By default, SES uses an Amazon-owned MAIL FROM domain, so Amazon supplies that domain’s SPF record.
A customer can instead configure a custom MAIL FROM domain. That choice requires the customer to publish the corresponding DNS records. The answer depends on the account’s configuration. Amazon SES documentation
The From address visible to the recipient does not settle this question. SPF checks the return-address domain, while DMARC considers whether a passing SPF or DKIM domain aligns with the visible From address. DMARC standard
A request the DNS administrator can act on
A useful handover describes the account configuration and the proposed change. For a fictional application using a custom return-address domain, the request might contain:
| Detail | Example |
|---|---|
| Application owner | Finance administers the invoice service. |
| Domain used for SPF | bounce.example.com, confirmed in the service settings and a test message. |
| Existing DNS value | Saved with the date and the original record. |
| Requested value | The exact value supplied for this account, reviewed alongside the existing policy. |
| Verification owner | The application owner sends a test; IT checks the received message. |
The email service discovery worksheet can hold that context. It helps the DNS administrator see what should change and which other senders must keep working.
A published record is one part of the change
A DNS check can confirm that a requested record is visible. A message from the application can show which return-address domain and sending infrastructure it actually uses.
Those checks answer different questions. Having the DNS editor and application owner work from the same information is what makes the change meaningful.
Sources and further reading
- ASD: Marketing and filtering email service providers
- Amazon SES: Using a custom MAIL FROM domain
- RFC 9989: DMARC
Sources reviewed 12 September 2026.