How to Audit Third-Party Senders Authorized to Use Your Domain

When this control is useful

Third-party platforms often send legitimate messages on behalf of a business, but old vendor authorizations can remain in DNS long after a contract ends. An authorization audit should determine which vendors still send, which domains they use, and which authentication mechanisms they require.

Implementation procedure

Export the current SPF record and all DKIM selectors for each sending domain. Compare them with a vendor register containing service name, business owner, purpose, From domain, return-path domain, DKIM selector, last-used date, and contract status. Ask application owners to confirm periodic or transactional systems that may not appear in marketing-team records.

Worked scenario

Use DMARC aggregate reports and provider logs to identify actual sending sources. Confirm uncertain sources with the vendor before changing DNS. Remove one obsolete authorization at a time, respecting SPF lookup limits and avoiding removal of shared services still in use by another department.

How to verify the result

After each change, validate DNS syntax and lookup count, send controlled messages from each remaining service, and inspect SPF, DKIM, and DMARC results in the received headers. Record the change and the owner who approved it.

Failure modes and safeguards

Do not delete an unfamiliar DKIM selector solely because it looks old; it may support a rarely used system. Avoid exceeding SPF DNS lookup limits while consolidating includes. A DNS authorization list is not a substitute for reviewing account access and vendor offboarding.

Implementation checklist

• Assign a technical owner and record the affected domain or service.
• Save the current configuration before making a change.
• Make one controlled change at a time and document the reason.
• Verify behavior using DNS results, message headers, or provider telemetry as appropriate.
• Record exceptions, rollback criteria, and the date of the next review.

Questions to resolve before deployment

Who owns the affected sending system? Which production messages depend on it? What evidence will demonstrate success? Who will respond if the change causes a delivery problem? Answer these questions before enforcing the configuration.