SPF Alignment Failures for Programmatic Senders

SPF alignment failures are one of the most common causes of DMARC-triggered rejections for programmatic senders — and they almost always come from the gap between the domain in your From: header and the domain in your envelope sender. If your agent sends as agent@yourdomain.com but the mail infrastructure routes bounces through bounces@mailprovider.com, SPF will pass but DMARC alignment will fail. That distinction trips up even experienced engineers.

What SPF alignment actually means

SPF alignment checks whether the domain in the envelope From (the MAIL FROM in SMTP, visible as the Return-Path header) matches the domain in the From: header that recipients see. DMARC requires alignment — not just that SPF passes, but that SPF passes for the same organizational domain your From: header claims.

RFC 7489 (DMARC) defines two alignment modes:

• Relaxed (aspf=r): The organizational domain must match. So bounces.yourdomain.com aligns with yourdomain.com.
• Strict (aspf=s): The full domain must match exactly. bounces.yourdomain.com does not align with yourdomain.com.

Most _dmarc TXT records default to relaxed alignment, but strict alignment shows up in high-security setups. Get the mode wrong and you'll see dmarc=fail (SPF alignment failed) in your Authentication-Results headers even when SPF itself returns pass.

One thing many debugging guides miss: SPF passing is not enough. DMARC doesn't care that SPF passed for mailprovider.com. It cares whether SPF passed for a domain aligned with your From: header domain.

The shared domain problem

Shared sending infrastructure is the main source of alignment failures for programmatic senders. When you send through a platform that uses its own domain for the envelope sender — for bounce handling, reputation routing, or infrastructure reasons — the Return-Path will be on their domain, not yours.

A typical shared-domain setup looks like this:

From: agent@yourdomain.com
Return-Path: agent.yourworkspace@send.mailplatform.com
Received-SPF: pass (send.mailplatform.com is authorized)
Authentication-Results: dmarc=fail (SPF alignment: header From domain yourdomain.com
                         does not align with SPF domain send.mailplatform.com)

SPF passes for send.mailplatform.com. But DMARC checks alignment against yourdomain.com (the From: header domain). They don't match. DMARC fails.

For email infrastructure for AI agents, this is a real operational problem: agents often send from a platform-managed subdomain by default, and developers assume that "SPF passes" means "DMARC passes".

When alignment is saved by DKIM

DMARC requires that either SPF or DKIM aligns — not both. If your DKIM signature covers a key from yourdomain.com (or a subdomain of it), DMARC can pass on DKIM alignment even when SPF alignment fails.

This is why many programmatic senders appear to work fine on shared infrastructure without a custom domain: DKIM alignment is carrying them. But that's fragile. Forwarded email breaks DKIM signatures — forwarding rewrites the envelope but preserves headers, invalidating the DKIM bh= body hash. If a recipient uses email forwarding and your DKIM breaks, you're left with only SPF, which fails alignment. The result is DMARC failure on forwarded mail: mysterious deliverability drops that are hard to trace.

Diagnosing alignment failures step by step

Step 1: Read the Authentication-Results header

Every receiving MTA that implements DMARC adds an Authentication-Results header. This is your primary diagnostic tool. Send a test message to a Gmail or Outlook account and view the raw headers.

A failing result looks like:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@send.mailplatform.com header.s=key1;
  spf=pass (google.com: domain of agent.workspace@send.mailplatform.com
       designates 198.51.100.25 as permitted sender)
       smtp.mailfrom=agent.workspace@send.mailplatform.com;
  dmarc=fail (p=REJECT sp=REJECT) header.from=yourdomain.com

Notice: SPF passes for send.mailplatform.com. DKIM passes for send.mailplatform.com. Neither aligns with yourdomain.com. DMARC fails.

Step 2: Check your DMARC policy

Query your domain's DMARC record:

dig TXT _dmarc.yourdomain.com +short

Look for the p= tag (policy: none, quarantine, or reject) and aspf= (alignment mode). If p=none, alignment failures are reported but not enforced — mail still delivers. Move to quarantine or reject and alignment failures result in mail being filtered or bounced.

Many teams discover alignment failures only when they graduate their DMARC policy from none to quarantine. The alignment issue existed the whole time; p=none just masked it.

Step 3: Trace the envelope sender

If the Authentication-Results header isn't readable (some MTAs omit detail), check the Return-Path header directly. That's the envelope sender the receiving MTA used for the SPF lookup. If Return-Path is on a different domain than From:, you have an alignment issue.

Step 4: Verify SPF records on both domains

Check SPF on your sending infrastructure's domain:

dig TXT send.mailplatform.com +short

And on your own domain:

dig TXT yourdomain.com +short

If your domain's SPF record doesn't include the sending infrastructure's IPs or include mechanism, SPF won't pass even for your own domain.

Fixing SPF alignment: three approaches

Option 1: Add a custom sending domain

The cleanest fix. When you configure a custom domain (e.g., mail.yourdomain.com or yourdomain.com itself) as your sending domain with your email platform, the platform can use a subdomain of your domain for the envelope sender. For example:

From: agent@yourdomain.com
Return-Path: bounces.agent@mail.yourdomain.com

Now mail.yourdomain.com is a subdomain of yourdomain.com. Under relaxed alignment (aspf=r), these align. DMARC passes on SPF.

To set this up, you typically add DNS records the platform provides — usually a subdomain delegation or specific MX/TXT records. The exact records vary by platform. For example, when you add a custom domain via Mails.ai's API, POST /v1/domains returns the DNS records to add; once verified, the envelope sender uses your domain rather than the shared send.mails.ai domain.

Option 2: Rely on DKIM alignment (carefully)

If you can't use a custom sending domain right now, ensure your platform signs outgoing mail with a DKIM key on your domain. That requires adding a DKIM CNAME or TXT record to your DNS.

With proper DKIM alignment:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mailplatform;

DMARC passes via DKIM alignment even when SPF alignment fails. Valid configuration — but it has the forwarding fragility described above.

Option 3: Add the platform's IP range to your SPF record

This only works if the platform uses a fixed, enumerable set of IPs for your messages — common with dedicated IPs, less reliable with large shared pools.

yourdomain.com TXT "v=spf1 include:_spf.mailplatform.com ~all"

This doesn't fix alignment unless the platform also sets the envelope sender to your domain. Adding sending IPs to your SPF record authorizes those IPs to send for your domain, but the envelope sender still needs to be on your domain for alignment to work. SPF authorization and SPF alignment are two different checks.

Alignment in practice: a decision matrix

The forwarding edge case

Forwarding deserves its own callout. When a recipient's mailbox forwards to another address:

1. The forwarding MTA rewrites the envelope sender (standard behavior).
2. The forwarding MTA does not change the From: header.
3. The DKIM signature, which covers the body hash and specific headers, often breaks because the forwarder modifies the message (subject tag, body addition).
4. SPF is now checked against the forwarder's infrastructure, not yours — and it fails unless the forwarder added itself to your SPF record (it hasn't).

The fix is ARC (Authenticated Received Chain, RFC 8617). ARC lets the forwarding MTA vouch for the original authentication result. Receiving MTAs that implement ARC (Gmail does, as of 2019) can use the ARC seal to honor the original DMARC pass even through forwarding. You don't have to implement ARC yourself — you benefit from it when the forwarding MTA supports it. But you should know it exists, because it's why forwarding failures aren't universal.

sequenceDiagram
    participant Agent as Agent
    participant Platform as Sending Platform
    participant Receiver as Recipient MTA
    participant Forwarder as Forwarding MTA
    Agent->>Platform: send mail From agent@yourdomain.com
    Platform->>Receiver: MAIL FROM bounces@send.platform.com
    Receiver->>Receiver: SPF pass for send.platform.com
    Receiver->>Receiver: DMARC check alignment vs yourdomain.com
    Receiver->>Forwarder: deliver
    Forwarder->>Receiver: re-deliver with new envelope
    Receiver->>Receiver: SPF fails for forwarder IP
    Receiver->>Receiver: DKIM broken by forwarder rewrite
    Receiver->>Receiver: DMARC fail unless ARC seal present

Common mistakes to avoid

Confusing SPF pass with DMARC pass. These are separate checks. spf=pass in your Authentication-Results tells you nothing about alignment.

Setting strict alignment when your subdomain sends. If you send from mail.yourdomain.com as the envelope domain and have aspf=s in your DMARC record, mail.yourdomain.com does not strictly align with yourdomain.com. Use aspf=r (relaxed) unless you have a specific reason for strict.

Adding too many include: mechanisms to SPF. RFC 7208 limits DNS lookups to 10 during SPF evaluation. Each include: triggers more lookups. Exceeding 10 causes a permerror, which DMARC treats as SPF fail. Tools like dmarcian's SPF Surveyor show your lookup count.

Forgetting the +all trap. An SPF record ending in +all authorizes every IP on the internet to send as your domain. Always end with ~all (softfail) or -all (fail).

For agents that need solid deliverability foundations — including reputation monitoring tied to bounce and complaint rates — the sender reputation guide covers what metrics matter and when they become dangerous.

Frequently Asked Questions

Why does DMARC fail when SPF passes?

SPF and DMARC are separate checks. SPF checks whether the IP is authorized to send for the envelope From domain. DMARC checks whether that envelope From domain aligns with the header From domain. Both conditions must be satisfied, or DKIM alignment must pass instead. A shared-domain setup typically causes SPF to pass for the platform domain while DMARC fails because that platform domain doesn't match your From: header domain.

What's the difference between relaxed and strict SPF alignment?

Relaxed alignment (aspf=r) passes if the organizational domain matches — so bounces.yourdomain.com aligns with yourdomain.com. Strict alignment (aspf=s) requires the full domain to match exactly. Most DMARC records use relaxed alignment. Check your _dmarc TXT record for the aspf= tag; if it's absent, the default is relaxed.

Does adding a custom domain fix both SPF and DKIM alignment?

It can fix both, but only if the platform uses a subdomain of your domain for the envelope sender and signs with a DKIM key on your domain. Verify both after setup by sending a test message and reading the Authentication-Results header. You want to see dmarc=pass with alignment noted for both mechanisms.

How do I check SPF alignment without sending a real message?

Use a mail testing service like mail-tester.com or learndmarc.com — send a test message to their address and they'll show you the full authentication analysis. Alternatively, send to a Gmail address and use "Show original" to read the raw Authentication-Results header. For SPF record syntax validation, mxtoolbox.com's SPF checker and dmarcian's SPF Surveyor both show lookup counts and parse results.

What happens to mail that fails DMARC alignment?

It depends on the p= policy in your domain's _dmarc record. If your domain has p=none, failures are reported to your rua= address but mail still delivers. p=quarantine sends failing mail to spam. p=reject causes the receiving MTA to reject it outright with a 5xx error. Check your own DMARC record to see what policy you're publishing.

Is a dedicated IP required to fix SPF alignment?

No. A dedicated IP affects which IP addresses your mail comes from, which matters for reputation, but SPF alignment is about domain matching, not IP addresses. A custom sending domain fixes alignment regardless of whether you're on a shared or dedicated IP. That said, a dedicated IP combined with a custom domain gives you the strongest deliverability posture for high-volume programmatic sending.

Start sending with Mails.ai