Third-party sender authentication

Treat a third-party sender as a new route into your domain. Identify the system, set its domain records, and check the identity it presents when mail arrives. Email authentication is a group of standards for identifying and preventing delivery of messages from forged senders.¹ One permission record is not enough. Messages sent by third-party services must be authenticated and pass SPF and DKIM checks.² Give each sender its own change record and clear domain boundary.

Build the sender inventory

Start with a complete inventory. You need to know every system that can send before deciding which records and policies it needs.

List every domain and sending service authorized to send for you, including marketing campaign platforms and invoice generators.³ Automatic email from Contact us forms belongs on the list too.⁴ Get missing sender details from the website administrator or the third-party service.⁵

Ask:

• Which systems send mail for this domain?
• Which domain does each system use in its visible sender address?
• Which system owns the sending configuration?
• Which workflows send automatically?

Move on when each sender has an identified service, sending domain, and reason for sending. An unknown sender is an unresolved change, so leave it out of the approval record until someone can explain it.

Choose the domain boundary

Give each sender a domain boundary before publishing records. This prevents an external service from sharing more authority than its job requires.

For services you do not control, use subdomains to protect the main domain's reputation and avoid exceeding the DNS lookup limit.⁶ Ask the service which domain it expects to authenticate and whether it supports the boundary you chose. Record that decision beside the sender in your inventory.

Move on when the sender has one clear domain to authenticate. If the service cannot tell you which domain it will use, resolve that with the service before adding DNS records.

Authorize the sending path

Give the sender permission to use the chosen domain. The record should describe the actual source the service uses to send.

SPF specifies the source email servers authorized to send mail for a domain.⁷ For an email marketing service, add its IP addresses to the SPF records and set up DKIM.⁸ An include tag identifies a third party as authorized to send on behalf of the domain.⁹

Ask the service:

• Which source servers or include does this sender require?
• Which SPF record or records should be published?
• Will the service send from the domain you assigned to it?

Use the sender's exact authorization details, then check that the domain record represents the service you approved. Move on when the SPF path matches the sender in your inventory.

Add the signing proof

Authorization identifies an allowed source. Signing gives the message a domain identity that can be checked after delivery.

DKIM uses a domain to digitally sign important message elements so the message can remain unaltered in transit.¹⁰ Contact each authorized domain or sending service, request DKIM configuration, and obtain its public key.¹¹ For a SaaS sender, add the TXT or CNAME records it provides to your DNS.¹²

Ask:

• Which DKIM records must be published?
• Which domain will the signature use?
• What public key belongs to this sender?

Keep the signing details with the sender record. Move on when you have the provider's records and know which sending service they belong to.

Connect the sender to domain policy

A sender can have a valid source and signature while still presenting a domain relationship you have not accounted for. Set the relationship you want the receiving system to evaluate.

Third-party senders often use their own domain as the Return-Path domain.¹³ For SPF alignment, add the sender's include to your SPF record and configure a custom Return-Path domain.¹⁴ For DKIM alignment, add the TXT or CNAME records the sender provides to your DNS.¹²

DMARC specifies what to do with messages that fail SPF or DKIM checks for senders in the domain and where to send the results.¹⁵ Decide which sender identity should align through SPF, which should align through DKIM, and where the results should go. Record those choices before approving the sender.

Move on when the sender's source, signature, Return-Path, and policy relationship are documented together. That record gives you something to check when the service changes its sending setup.

Verify the finished route

Verification compares the DNS configuration with the result of an actual message. Use that result as the gate for approval.

Send a message through the third-party service and inspect whether it passes SPF and DKIM. Approve the sender only after both checks pass.² Use the DMARC reporting destination to review results after the sender is live.¹⁵

If the result fails, trace it through the inventory, domain boundary, SPF path, signing records, and Return-Path. Change one part at a time so you can tell which configuration fixed the result.

Include the receiving route in that review when MX records lead through on-premises systems or third-party relays before Microsoft 365. Standard checks such as SPF hard-fail and strict DMARC enforcement may not apply correctly across those paths.¹⁶

What not to do

Keep these failure modes beside the approval checklist. Each one can leave a sender able to send without giving you a dependable authentication result.

• Do not give a scanner or web application a mailbox username and password for sending. Use an SMTP server.¹⁷
• Do not assume a dedicated sending mailbox has resolved authentication and security concerns.¹⁸
• When a relay uses a trusted sender setting, limit it to trusted senders and use an authentication method as well.¹⁹
• Do not assume complex MX routing will apply SPF hard-fail and strict DMARC checks correctly.¹⁶

Use the completed inventory and verification result as the approval record, with each sender attached to one domain boundary. When a sender changes its route or signing records, repeat the same check before allowing it to send.