Your Domain Is Fine. Why Are Your Vendor's Emails Getting Junked?

You just onboarded a shiny new sales automation tool. The demo was slick, the integration was smooth, but the first campaign's reports are a sea of red: bounces, delays, and outright rejections from major providers.

Your first instinct is to check your own domain's reputation. SPF, DKIM, DMARC—they're all solid. You haven't been blacklisted. So what's happening? You're looking in the wrong place.

The problem isn't your domain. It's the often-invisible sending infrastructure of the third-party service you're paying. Their reputation is now your problem, and you need to know how to diagnose it.

The Ghost in the Header: Finding the True Sender

Every email has two 'from' addresses. One is for show, and the other is for the servers. The one for show is the `From:` header, which is what your user sees in their email client. This is trivially easy to forge and is the source of endless confusion for non-practitioners.

The one that matters for deliverability is the envelope sender. This address, specified in the `MAIL FROM` command during the SMTP conversation, tells the receiving mail server where to send bounces and errors. After delivery, it gets recorded in the `Return-Path` header. This is the address that SPF checks are performed against.

Return-Path: <bounces-12345-xyz@email.newsaasapp.net>
From: "Your Sales Team" <sales@yourcompany.com>

Look at that header pair. The email *appears* to be from your company, but the actual mail transaction and bounce handling is managed by `email.newsaasapp.net`. This is the domain whose reputation is being judged by Google, Microsoft, and every other mail receiver. This is your target.

Running the Vitals on a Third-Party Domain

Once you've extracted the `Return-Path` domain, it's time to put it under the microscope. You're going to apply the same diagnostic rigor you'd use on a suspected phishing domain, because from a receiving mail server's perspective, there's not much difference.

Domain Age and Infrastructure Hygiene

First, check the domain's age. A `whois` lookup will tell you the creation date. A sending domain registered three weeks ago is a massive red flag. Mail providers view new domains with extreme suspicion because attackers frequently use them for spam and phishing campaigns. Legitimate senders must 'warm up' new domains and IP addresses by gradually increasing sending volume to build a positive reputation. A vendor that throws its customers' mail onto a cold domain is demonstrating profound operational incompetence.

Authentication Protocols: The Non-Negotiables

Authentication isn't just a checkbox; it's the foundation of sender identity. Dig into their DNS records. For SPF (RFC 7208), check the record on the `Return-Path` domain. Look for an overly permissive `+all` qualifier—a cardinal sin that tells the world to trust any IP address. Also watch for long, complex `include` chains that can lead to DNS lookup limits and trigger a `permerror`.

For DKIM (RFC 6376), check the `DKIM-Signature` header in the delivered email. What domain is in the `d=` tag? Does it align with the `From:` header domain? Many third-party senders sign with their own domain (`d=email.newsaasapp.net`), which passes DKIM authentication but fails DMARC alignment if the `From:` is `yourcompany.com`. This is a common failure mode, especially with systems that forward or rewrite content, like mailing lists or some security gateways.

Finally, inspect their DMARC (RFC 7489) record. A mature sending service should have a `p=reject` or at least a `p=quarantine` policy. A `p=none` policy on a high-volume sending domain signals a lack of confidence in their own configuration. It offers no protection and essentially tells receivers, 'We have no idea if our mail is authentic, so you figure it out.'

Case Study: The Brand-New Domain That M365 Hated

This isn't theoretical. A client recently rolled out a new HR benefits platform. Critical enrollment announcements were being sent from the platform, but employees weren't receiving them. A flood of tickets reported the emails were landing in spam folders or being outright quarantined by Microsoft 365 Defender for Office 365.

The `From:` address was the client's own, `hr@clientcorp.com`, so they naturally assumed their own domain was the issue. But a look at the full headers of a quarantined message told the real story. The `Authentication-Results` header showed an SPF pass, but it was for a domain we didn't recognize.

Received-SPF: pass (sender IP is 198.51.100.23) client-ip=198.51.100.23; envelope-from=tracking-abc@send.newhrplatform.io; helo=mta-4.send.newhrplatform.io;

The envelope sender was `send.newhrplatform.io`. A quick `whois` revealed the domain was registered just 22 days prior. Its sending IPs had zero history. Microsoft's mail filters, seeing messages claiming to be from a reputable corporate domain (`clientcorp.com`) but originating from a brand-new, unproven infrastructure, correctly assessed the risk as high and junked the mail. The vendor had failed to perform a basic IP/domain warm-up, and their customer paid the price in failed critical communications.

Your Vendor's Problem Is Your Problem: The Remediation Playbook

You've done the forensics and confirmed the third party's reputation is the root cause. You can't just flip a switch and fix their infrastructure, but you're not powerless. Now you transition from analyst to diplomat, armed with technical evidence.

The Questions to Ask Their Support Team

When you open a ticket, don't just say 'our emails are going to spam.' Present your findings. This elevates the conversation past first-line support and gets you to an engineer who understands SMTP.

Ask specific, pointed questions: 'Your sending domain, `send.newhrplatform.io`, was registered last month. What was your IP warm-up strategy for this new domain?' Or, 'Your DMARC policy is `p=none`. Is there a timeline for moving to `p=quarantine` to provide actual protection?' And, 'Can we be provisioned on a dedicated sending IP to isolate our reputation from your other customers?' Their answers (or lack thereof) will tell you everything you need to know about their operational maturity.

Pushing for DMARC Alignment

The long-term solution is to eliminate the vendor's domain from the authentication equation. The best SaaS providers offer features to achieve DMARC alignment. This typically involves you creating CNAME records in your DNS. One CNAME might handle the `Return-Path` (for SPF alignment), and another set will be for a custom DKIM signing domain. The end result is that mail sent by the third party on your behalf will have an SPF and/or DKIM domain that aligns with your `From:` address, satisfying DMARC. This puts the reputational control back where it belongs—with you.

Stop Inheriting Bad Reputations

Onboarding a new SaaS tool isn't just a software procurement decision; it's a security and reputation decision. You are delegating a portion of your brand's identity to a third party. If their sending hygiene is poor, it directly reflects on you, and your emails will end up in the junk folder.

Make this analysis part of your vendor vetting process. Before you sign the contract, ask for their sending domains. Run the checks. Ask about their DMARC policy and support for custom DKIM/Return-Path configurations. A vendor who takes email seriously will have impressive answers. One who doesn't will be a source of constant, painful deliverability headaches.

The takeaway

The `From:` header is a suggestion. The true identity of an email is written in the `Return-Path` and the `Authentication-Results` header. When you onboard a new service, you're not just buying software; you're inheriting the digital reputation of their mail servers. Vet their infrastructure with the same rigor you apply to your own.

Analyzing raw email headers to trace envelope senders and authentication chains is a core skill for any security analyst. Tools like MailSleuth.AI can accelerate this process, but the fundamental discipline is knowing where to look and what questions to ask. Don't let a vendor's sloppy email hygiene tarnish your domain's hard-won reputation.