Anatomy of a DMARC Failure: The Third-Party Sender Trap

The alert lands at 8 AM. A critical marketing campaign, sent via your company's Salesforce Marketing Cloud, is tanking. The open rate is abysmal, and replies are trickling in from confused recipients saying they found it in their spam folder, if they got it at all. Your CMO is on Slack, and their avatar is not smiling. This isn't a server outage; it's a deliverability crisis, and you suspect an authentication problem.

This scenario is a rite of passage for anyone managing email infrastructure. You onboard a trusted, expensive third-party service to send email on your company's behalf. You follow their documentation, adding their IP ranges or `include` mechanisms to your SPF record. You press 'go'. And then it all falls apart.

The root cause is almost never the service itself. It’s a fundamental, and often misunderstood, principle of modern email authentication: alignment. Your email failed not because it wasn't authenticated, but because it wasn't authenticated by the right entity. Let's pull the headers from a failed message and see why.

First Triage: What the DNS Record Says

Before diving into a specific email's headers, the first reflex is to check your public-facing policy. You run a quick query on your domain's DMARC record, expecting to find a typo or a misconfiguration.

The TXT record for `_dmarc.yourcompany.com` looks perfectly standard: `v=DMARC1; p=quarantine; rua=mailto:aggrep@dmarc.yourcompany.com; fo=1;`. This tells receiving mail servers to quarantine messages that fail the DMARC check and send aggregate reports to your specified address. The policy is active and correctly formatted. So, the instructions you're giving the world are clear. The problem is in the messages themselves.

Waiting for DMARC aggregate reports (`rua`) to arrive is too slow for an active incident. Those reports are forensic tools for analyzing trends, not real-time debuggers. You need to get your hands on the full headers of a single, failed message. You ask the marketing team to forward you a raw `.eml` file of one of the emails that landed in spam.

Down the Rabbit Hole: Decoding the Authentication-Results

This is where the real investigation begins. The `Authentication-Results` header, inserted by the first-hop mail server (like Microsoft s or Google's), is the official scorecard for email authentication. It’s the ground truth.

Authentication-Results: mx.google.com;
spf=softfail (sender IP is 161.71.x.x) smtp.mailfrom=bounce.sfdc.net;
dkim=pass header.i=@yourcompany.com header.s=s1 header.b=somehash;
dkim=pass header.i=@sfdc.net header.s=sfdc header.b=anotherhash;
dmarc=fail (p=QUARANTINE) header.from=yourcompany.com;

At a glance, this is deeply confusing. You see a `softfail` for SPF, a `pass` for DKIM, and yet the final verdict is a big, red `dmarc=fail`. This is the crux of the entire issue, and it requires breaking down each component.

SPF's Predictable Failure

The SPF result is `softfail`. This happens because the server sending the email has an IP address (e.g., `161.71.x.x`) that belongs to Salesforce, not your company. According to RFC 7208, SPF checks the domain found in the SMTP envelope's `MAIL FROM` command—often called the `Return-Path` or `bounce address`. For this email, that address is `bounce.sfdc.net`, a Salesforce domain used to manage bounces. The receiving server checks the SPF record for `sfdc.net`, sees that `161.71.x.x` is a valid sender for them, but it doesn't match the `header.from` domain (`yourcompany.com`). So DMARC sees this as a misaligned SPF check. Even if you included Salesforce in your own SPF record, it often wouldn't change this outcome, as the `MAIL FROM` domain is what's being evaluated for alignment.

DKIM's Deceptive Pass

This is the real trap. The header shows `dkim=pass`. So, the message's integrity is verified. A cryptographic signature was applied, and it hasn't been tampered with. But look closer at what follows: `header.i=@sfdc.net`. RFC 6376 defines the `i=` tag in the DKIM signature as the identity of the signer. The signature that passed was one applied by Salesforce (`sfdc.net`) to protect their own reputation. There may be another signature for your domain, but the one DMARC used for its evaluation was the one from the third-party infrastructure. This signature is valid, but it attests to the authenticity of a Salesforce email, not a `yourcompany.com` email. This is a passing grade on the wrong test.

The Alignment Gap: DMARC's Core Mandate

DMARC, defined in RFC 7489, doesn't just ask, 'Is this email authenticated?'. It asks a much more important question: 'Is this email authenticated *as the domain it claims to be from*?' This is the concept of identifier alignment.

For a DMARC check to pass, at least one of two conditions must be met:

1. SPF must produce a `pass` verdict, AND the domain in the `smtp.mailfrom` (the bounce address) must align with the domain in the `header.from` (what the user sees).

2. DKIM must produce a `pass` verdict, AND the domain in the DKIM signature's `d=` tag must align with the domain in the `header.from`.

In our incident, SPF failed to align because `bounce.sfdc.net` does not match `yourcompany.com`. The passing DKIM signature also failed to align because its signing domain (`sfdc.net`) does not match `yourcompany.com`. Since neither authentication method produced an aligned pass, DMARC failed, and the receiver dutifully followed your `p=quarantine` policy.

Strict vs. Relaxed Alignment

DMARC allows for two modes: relaxed (`adkim=r`, `aspf=r`) and strict (`adkim=s`, `aspf=s`). Relaxed alignment, the default, allows subdomains to align with an organizational domain. For example, a DKIM signature from `mktg.yourcompany.com` would align with a `header.from` of `yourcompany.com`. Strict requires an exact match. Our problem is more fundamental. `sfdc.net` and `yourcompany.com` are entirely different organizational domains, so they would fail alignment under both relaxed and strict modes.

Climbing Out: Reconfiguring the Sender for Alignment

The common but incorrect reaction is to double down on SPF. An engineer might say, 'We just need to authorize their IPs!' and try to cram more `include:` statements into the SPF record. This not only fails to solve the alignment problem but also pushes you closer to the 10 DNS lookup limit, which can cause SPF to fail entirely for legitimate senders.

The correct fix lies within your third-party provider's dashboard, usually under a section named 'Sender Authentication,' 'Domain Branding,' or 'White-Labeling.' The goal is to enable aligned DKIM signing.

This process typically involves the provider asking you to publish several CNAME records in your DNS. For example, Salesforce might ask you to create `s1._domainkey.yourcompany.com` as a CNAME pointing to `s1._domainkey.sfdc.net`. By doing this, you are delegating authority. You are telling the world, 'Anyone looking for the DKIM public key for the selector `s1` for my domain should actually go ask Salesforce.' This enables Salesforce to apply a DKIM signature to your emails using a key that is valid for *your* domain. The resulting signature will have a `d=yourcompany.com` tag.

When the receiving mail server sees an email from `yourcompany.com` signed by `d=yourcompany.com`, the DKIM check passes and, crucially, aligns. DMARC now has what it needs. One aligned pass is enough, and the DMARC check succeeds.

Verification, Not Hope

After adding the CNAME records and waiting for DNS to propagate, do not simply assume the problem is solved. You must verify.

Use the third-party platform to send another test email to an inbox you control (or to a dedicated email analysis tool). Grab the headers again. This time, the `Authentication-Results` should tell a very different story.

Authentication-Results: mx.google.com;
spf=softfail (sender IP is 161.71.x.x) smtp.mailfrom=bounce.sfdc.net;
dkim=pass header.i=@yourcompany.com header.s=s1 header.b=newhash;
dmarc=pass (p=QUARANTINE) header.from=yourcompany.com;

Notice the change. SPF still fails to align, and that’s perfectly fine. We don't need it. The DKIM signature now passes with a signing domain (`header.i` or `header.d`) of `yourcompany.com`. Because DKIM passes and aligns, the `dmarc` verdict is finally `pass`. Your emails will now be treated as authentic, and deliverability will be restored. The crisis is over.

The takeaway

The central lesson is that DMARC is a protocol about identity, not just about passing a cryptographic check. A 'pass' verdict in an `Authentication-Results` header is meaningless without context. A pass for whom? Aligned with what? This is why BEC attackers use lookalike domains and why unaligned third-party senders, however legitimate, can inadvertently trash your domain's reputation.

Third-party senders are an extension of your security perimeter. Audit them as you would any internal system. Before onboarding a new service that sends email on your behalf, make aligned DKIM a mandatory technical requirement. Never trust a vendor that only supports SPF includes. Proactively analyzing your email headers for these alignment gaps, using tools like MailSleuth.AI or manual inspection, is the difference between a smooth campaign and a Monday morning fire drill.