Third-party sender authentication

Treat a third-party sender as a new path into your domain's identity. Map who sends, choose the domain boundary, collect the required records, publish them, and verify the path. A service you do not control can affect your main domain's reputation and consume DNS lookups.¹ Follow that order so an unknown sender does not become a delivery problem.

Map every sender

Start with a sender map. You cannot authorize a service you have not identified, so include automated mail as well as obvious campaign traffic.

Create a list of every domain and sending service authorized to send email on your behalf. Include marketing campaign platforms and invoice generators, which are also referred to as ESPs.² Add automatic senders such as Contact us forms.³

For each entry, ask:

• Which service sends the message?
• Which domain appears in the From address?
• Does the service provide SPF details, DKIM records, or a custom Return-Path domain?
• Who can change the service configuration and who controls DNS?

You may need to obtain sender information from the website administrator or the third-party service itself.⁴ Continue when every sender has a clear domain, service, and record requirement.

Choose the sending boundary

Decide the domain boundary before publishing anything. It determines how much control one external service has over the identity used by the others.

Give an email service you do not control its own sending subdomain. Record that decision with the sender inventory. This gives you a separate place to manage the service, protects the main domain's reputation, and helps you stay within the DNS lookup limit described for external services.¹

For every new sender, ask whether it belongs on the main domain or needs a separate sending identity. Write down the answer before collecting records.

Collect the sender's records

Ask the service for its exact authentication requirements. Copy the provider's record names and values into your working notes before changing DNS.

Contact each authorized domain or sending service and request DKIM configuration together with a copy of the public key.⁵ For an email marketing service, add the IP addresses it supplies to the SPF record and set up DKIM.⁶

For DKIM alignment, add the TXT or CNAME records the sender provides to DNS.⁷ For SPF alignment, add the sender's include to the SPF record and configure a custom Return-Path domain.⁸

Before publishing, ask:

• Which SPF mechanism should represent this sender?
• Which DKIM record type and public key should appear in DNS?
• Can the sender use a custom Return-Path domain?
• Which domain will appear in the authenticated result?

Proceed when the service has supplied the records and you know which sending path each one belongs to.

Publish the records and policy

Handle SPF, DKIM, and DMARC as separate jobs. Each answers a different question about the message, so a third-party sender needs the parts that apply to its path.

SPF specifies the source email servers authorized to send mail for the domain.⁹ DKIM uses the domain to digitally sign important message elements so the message can remain unaltered in transit.¹⁰ DMARC specifies what to do with messages that fail SPF or DKIM checks and where to send the resulting reports.¹¹

Publish the sender's SPF and DKIM configuration, then set the DMARC policy and reporting destination for the domain. Third-party messages must be authenticated and pass SPF and DKIM checks.¹²

Keep the records tied to the sender map. The SPF entry should represent the source that actually sends, the DKIM record should match the signing setup, and the Return-Path should match the alignment plan. If any detail points to a different sender, stop and resolve the mismatch before validating the domain.

Verify the sender path

After publishing the DNS records, check the provider's domain status and confirm that the sending system recognizes the configured identity.

Use the service's validation flow. In Amazon's domain verification flow, successful verification triggers an email notification.¹³ Where the sending system provides a Mail Failures screen, use it to check whether the sender is registered as a valid Email Delivery Mail Sender.¹⁴

Check each sending path separately. A successful campaign sender does not prove that a contact form or invoice system has the same authentication setup. Keep the verified domain, sending service, and record set together in the inventory so a later DNS change has a clear owner.

What not to do

Review these failure modes whenever a service asks for permission to send.

• Review any complex mail path before allowing it. When MX records lead through on-premises systems or third-party relays before Microsoft 365, SPF hard-fail and strict DMARC checks may not apply correctly.¹⁵
• A sender name does not prove the message's origin. Attackers can change the sender name while setting the From field to a valid internal email address.¹⁶
• For a scanner or web application, use an SMTP server that sends the mail for you instead of a mailbox with a username and password.¹⁷

You can then approve external sending with a record of what is authorized and a clear check for whether the path is working.