Two email providers on one domain without breaking auth

Step 4: DMARC, one policy covering both#

DMARC is a single record at _dmarc.example.com:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Start at p=none and read the aggregate reports. You want to see both providers' sending IPs appear, each with DKIM passing and aligned (and ideally SPF too). Once every legitimate source passes, move to p=quarantine and then p=reject.

Step 5: verify each stream separately#

Send a real message from each system to a mailbox you control and read the Authentication-Results header:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce.example.com;
  dkim=pass header.d=example.com header.s=pb1;
  dmarc=pass header.from=example.com

For a staff message you would expect smtp.mailfrom=example.com and header.s=pa1. If either stream shows dmarc=fail, check which identity failed and whether it aligned.

Common pitfalls#

• Two SPF records. Adding Provider B's record as a second v=spf1 TXT instead of merging produces a permerror for both.
• Unaligned DKIM. Provider B signs with its own domain; everything looks green until you enforce DMARC.
• Forgotten third and fourth senders. Support desks, CRMs, billing systems and form tools often send as your domain too. DMARC reports reveal them.
• Reusing selectors. If two systems publish keys at the same selector name, one overwrites the other.
• MX confusion. Adding a transactional provider never requires changing the root domain's MX records, which control inbound mail for your staff. Only a custom bounce subdomain needs its own MX.

Where each provider's bounces go#

Bounce handling follows the envelope sender. When Provider B uses bounce.example.com with an MX pointing to its infrastructure, bounces return to Provider B, which can suppress bad addresses and report them to you through its dashboard or webhooks. Staff mail continues to bounce back to Provider A through your root domain's MX records. Keeping that separation clean matters: if the application's bounces landed in a staff mailbox, nobody would process them, and your application would keep sending to dead addresses, which hurts reputation over time.

Reputation is shared, so coordinate#

Both providers send as example.com, which means receivers build a single picture of the domain from both streams. A spike in complaints from application mail can affect how staff mail is filtered, and the reverse. Separate envelope subdomains help a little, but the visible From domain is what many filters weigh most heavily. If one stream is riskier than the other, such as marketing compared with password resets, consider giving it its own From subdomain as well, so problems in one stream stay contained.

A short checklist#

• One SPF record per name, all senders using that name included, under ten lookups.
• A custom bounce subdomain for the transactional provider where supported.
• A distinct DKIM selector per provider, signing with d= aligned to your domain.
• A DMARC record with aggregate reporting, starting at p=none.
• Authentication-Results checked on a real message from each system.
• A move to enforcement only after reports show every legitimate source passing.

Bottom line#

Two providers on one domain work fine when you give each its own lane: a combined or separated SPF setup, an independent DKIM selector with aligned signing, and one DMARC policy watching both. Verify each mail stream on its own, and let aggregate reports tell you when it is safe to enforce.