Email Authentication for Third-Party Senders

A legitimate email can still face delivery problems if the sending infrastructure cannot clearly prove that it is authorized to send on behalf of the domain in the visible From address.

This is a common challenge for third-party senders. Email service providers, CRMs, marketing platforms, and managed service providers often send email using infrastructure that differs from the customer’s primary mail infrastructure.

For example:

• The visible From address may use example.com
• The sending platform may operate its own servers
• The envelope sender may use another domain
• The sending IP may belong to the third-party provider

Without proper authentication and DMARC alignment, this setup can resemble unauthorized spoofing to receiving mailbox providers.

The solution is to configure SPF, DKIM, and DMARC so the third-party infrastructure is clearly authorized and properly aligned with the sender’s domain.

The Core Challenge: Delegation

Email authentication becomes more complicated when one organization sends email on behalf of another.

A company may own example.com but use a third-party platform to send:

• Marketing campaigns
• Transactional emails
• CRM notifications
• Product updates
• Invoices
• Application-generated messages

The domain owner controls the visible identity, while another provider may control the technical infrastructure.

The receiving mailbox provider needs to determine whether that third party is genuinely authorized to use the domain.

This is where SPF, DKIM, and DMARC work together.

SPF and Third-Party Sending

SPF authorizes servers to send email for a particular domain.

However, SPF checks the domain used in the SMTP envelope sender, commonly known as the Return-Path or MAIL FROM domain. It does not directly authenticate the visible From address that the recipient sees.

For example:

From:
Return-Path:

Even if SPF passes for mailer.example, that result may not align with example.com.

For DMARC purposes, SPF must pass and the authenticated SPF domain must align with the visible From domain.

A properly configured third-party setup may instead use a custom envelope sender such as:

From:
Return-Path:

If mail.example.com is authorized and properly configured, it can align with example.com under DMARC’s relaxed alignment rules.

The SPF Lookup Limit

SPF has an important technical limitation: an SPF evaluation cannot require more than 10 DNS-triggering lookups.

This can become a problem when a root domain includes multiple third-party services:

v=spf1 include:provider1.com include:provider2.com include:provider3.com include:provider4.com -all

Each included provider may trigger additional lookups. A complex configuration can eventually exceed the SPF lookup limit and result in an SPF permerror.

A useful approach is to separate different sending services using dedicated subdomains.

For example:

mail.example.com
transactional.example.com
marketing.example.com

Each subdomain can have an SPF configuration designed specifically for the infrastructure using it.

DKIM and Third-Party Sending

DKIM allows an email to be digitally signed.

The sending system uses a private key to generate the signature, while the corresponding public key is published in DNS.

A typical DKIM signature contains a domain identifier:

d=example.com

When the receiving server processes the message, it retrieves the public key from DNS and verifies the signature.

For third-party senders, DKIM is particularly important because the signature can identify the customer’s domain even when the sending infrastructure belongs to another provider.

A properly configured third-party platform should support custom DKIM signing for the customer’s domain or an appropriately aligned subdomain.

For example:

From:
DKIM d=example.com

This allows DKIM to pass and align with the visible From domain.

DMARC and Domain Alignment

DMARC builds on SPF and DKIM.

A message passes DMARC when at least one of the following conditions is met:

1. SPF passes and the SPF-authenticated domain aligns with the visible From domain.
2. DKIM passes and the DKIM signing domain aligns with the visible From domain.

This is the critical point for third-party senders.

Consider the following configuration:

From:
Return-Path:
DKIM d=mailer.io

SPF may pass for mailer.io.

DKIM may also pass for mailer.io.

However, neither authenticated domain aligns with example.com. As a result, the message can fail DMARC.

Now consider:

From:
Return-Path:
DKIM d=example.com

In this case, DKIM can align directly with the visible From domain, and SPF may also align depending on the DMARC alignment mode.

This is the type of configuration third-party senders should aim for.

Use Dedicated Sending Subdomains

A dedicated subdomain can simplify third-party authentication.

For example:

example.com Primary corporate domain
marketing.example.com Marketing platform
transactional.example.com Transactional email platform
mail.example.com Dedicated sending infrastructure

This approach separates different sending functions and reduces the need to place every provider inside a single root-domain SPF record.

A third-party sender can then be authorized specifically for the appropriate subdomain.

For example:

v=spf1 include:thirdparty.example.net -all

published on:

mail.example.com

The platform can also configure DKIM records for the customer’s delegated sending domain.

The exact DNS records depend on the sending platform and its authentication architecture.

Common Third-Party Authentication Mistakes

1. Relying Only on SPF

SPF alone is not sufficient for modern third-party email authentication.

SPF does not authenticate the visible From address unless the authenticated envelope domain also satisfies DMARC alignment requirements.

DKIM should be configured as an independent authentication mechanism.

2. Exceeding the SPF Lookup Limit

Adding multiple third-party services to a single SPF record can create a complex lookup chain.

Once the SPF evaluation exceeds the 10-lookup limit, SPF can return a permanent error.

Regular SPF validation is important, particularly when new providers are added.

3. Using the Provider’s DKIM Domain Without Alignment

A message can pass DKIM while still failing DMARC.

For example:

From:
DKIM d=thirdparty.com

The DKIM signature is technically valid, but thirdparty.com does not align with example.com.

The solution is to configure a custom DKIM signing domain that aligns with the visible From domain.

4. Poor DKIM Key Management

DKIM keys should be managed securely and rotated when necessary.

A proper DKIM architecture should include:

• Secure private key storage
• Unique key management for each domain or customer where appropriate
• Controlled selector naming
• Support for key rotation
• Monitoring for signing failures

When rotating keys, publishing a new selector before retiring the old key can help avoid authentication failures caused by DNS propagation or delayed mail delivery.

5. Ignoring DMARC Alignment

An SPF or DKIM pass does not automatically mean DMARC passes.

The authenticated domain must also align with the domain in the visible From address according to the domain’s DMARC alignment settings.

Always verify:

From domain
SPF authenticated domain
DKIM d= domain
DMARC alignment mode

A Practical Authentication Setup

A third-party sender can follow a layered approach.

Step 1: Configure a Dedicated Sending Domain or Subdomain

Separate third-party sending from other services where appropriate.

For example:

marketing.example.com

or:

mail.example.com

Step 2: Configure SPF

Authorize the infrastructure responsible for the envelope sender.

Keep the SPF lookup count within the technical limit.

Step 3: Configure Custom DKIM

Configure the third-party platform to sign with the customer’s domain or an appropriately aligned domain.

Use modern key sizes supported by the provider and receiving ecosystem.

Step 4: Configure DMARC

Begin with monitoring if the domain does not already have a mature DMARC deployment.

For example:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Analyze the resulting aggregate reports and identify legitimate sending sources.

Step 5: Progress Toward Enforcement

After all legitimate sending sources are authenticated and aligned, a domain can consider moving toward stronger enforcement.

The progression is commonly:

p=none

then:

p=quarantine

and eventually:

p=reject

The appropriate timeline depends on the complexity of the organization’s email infrastructure. Enforcement should only increase after legitimate traffic has been identified and authenticated correctly.

BIMI and Brand Trust

BIMI can provide an additional brand identity signal for organizations that meet the relevant requirements.

BIMI generally depends on a properly configured DMARC policy and additional requirements that may vary by mailbox provider and implementation.

It should not be considered a replacement for SPF, DKIM, or DMARC.

Authentication comes first.

Authentication Requirements for Bulk Senders

Major mailbox providers have increased their authentication requirements for bulk and high-volume senders.

Requirements and enforcement can vary by provider, recipient type, and sending volume, but SPF, DKIM, and DMARC have become fundamental components of modern email infrastructure.

Third-party senders therefore need to consider authentication as part of their core service architecture.

If a platform sends on behalf of multiple customers, it should provide a clear process for:

• Custom sending domains
• SPF configuration
• Custom DKIM signing
• DMARC alignment
• Return-Path configuration
• DNS verification
• Ongoing authentication monitoring

Key Takeaway

Third-party email sending creates a delegation problem.

The visible From domain belongs to one organization, while the infrastructure sending the email may belong to another. SPF, DKIM, and DMARC provide the mechanisms needed to prove that this delegation is authorized.

A strong setup should aim for:

• Authorized sending infrastructure
• Proper SPF configuration
• Aligned DKIM signatures
• DMARC alignment
• Dedicated sending subdomains where appropriate
• Controlled DKIM key management
• Ongoing DMARC monitoring

A message should not simply pass authentication. The authentication should clearly establish that the sending infrastructure is authorized to represent the domain visible to the recipient.