SPF valid, DMARC failing: the alignment misunderstanding

9 min read

You published your SPF record. You checked it with three different tools, and all three told you the syntax is correct and your servers are properly authorized. Your DMARC reports still tell you that 40% of your messages are failing — and failing on SPF, of all things.

There is no bug and no configuration error here. You have just met alignment, the mechanism that gives DMARC all of its value and that almost nobody explains properly.

An email has two senders, and your recipients only see one

That is the starting point, and everything else follows from it.

When a message travels, it carries two distinct sender addresses, written in two different places.

The first is the envelope address. It is announced by the sending server during the SMTP conversation, before the message itself is even transmitted. It exists for routing and for bounces, which is why you find it again in the Return-Path header. No user ever sees it.

The second is the displayed address, the one in the From header. That is what your customer reads in their mail client, and what they base their trust on.

The postal comparison holds up well. The envelope carries an address for the postal worker and for returns. The letter inside carries a heading meant for the reader. Nothing forces the two to match.

SPF checks the envelope. The envelope only. It looks at the sending server's IP address, compares it against the list published by the envelope domain, and answers yes or no.

You can see the hole immediately. A fraudster can publish an impeccable SPF record on fraudster-server.com, use it as the envelope domain, and write accounting@yourcompany.com in the From header. SPF passes, perfectly. Your customer receives an authenticated fraudulent message. For fifteen years, spoofing worked in exactly that way.

What DMARC actually checks

DMARC closes that hole with one additional requirement, and only one: the authenticated domain must match the displayed domain.

A message is DMARC compliant when at least one of these two conditions is met:

SPF passes, and the envelope domain aligns with the From header domain.

DKIM passes, and the signature domain — the d= field — aligns with the From header domain.

Hold on to the exact wording, because that is where everyone goes wrong. It is not "SPF passes" but "SPF passes and is aligned". Successful authentication on a domain that is not yours brings you nothing at all. It is, in fact, precisely what a fraudster does.

Two routes to compliance, and one is enough

Good news, and it is the one that unblocks most situations: the two conditions are not cumulative. A message whose DKIM signature is valid and aligned passes DMARC even if its SPF fails miserably.

That rule has an immediate practical consequence. When a sender is causing trouble and you cannot get its SPF aligned, do not dig in. Have it sign with DKIM using your domain, and the problem disappears.

Strict or relaxed: what adkim and aspf change

That leaves us to define what "align" means. DMARC offers two definitions, which you select with the aspf tag for SPF and adkim for DKIM.

In relaxed mode, the default, two domains align if they share the same organizational domain. In practice, bounce.yourcompany.com aligns with yourcompany.com. A subdomain and its parent domain are treated as the same entity.

In strict mode, set with aspf=s or adkim=s, the two domains have to be identical, character for character. bounce.yourcompany.com is then no longer aligned with yourcompany.com.

Always start in relaxed mode. Strict mode is only justified in tightly compartmentalized setups, and it breaks legitimate flows without adding any security in the vast majority of cases.

A May 2026 change to how the organizational domain is worked out

The notion of an organizational domain has just changed mechanics, and that matters if you are reading older documentation.

Until DMARCbis was published in May 2026, receivers determined the organizational domain by consulting the Public Suffix List, an external, community-maintained list of every public suffix in the world. That list had two problems: it lived outside the DNS, and it handled nested domain structures badly.

The new standard, carried by RFC 9989, replaces it with a walk up the DNS. The receiver queries the DNS directly, climbing from parent domain to parent domain until it finds a valid DMARC record. The result is more consistent and no longer depends on an external registry.

In practice, nothing changes in how you write your record. But if your subdomains show alignment behavior you cannot explain, be aware that the calculation rule is no longer the one described in articles written before 2026.

The case behind nine failures out of ten

Here is the typical situation, the one you are going to find in your own reports.

You use an invoicing tool, a CRM or a newsletter platform. You configured your sender address: billing@yourcompany.com. The provider sends your messages from its servers, with its own envelope address, something like bounce-42871@mail.provider.com.

Let us walk through what the receiver sees.

SPF is checked on mail.provider.com. The record exists, the IP is authorized, SPF passes. The provider did its job properly.

Alignment is checked next. mail.provider.com against yourcompany.com. Those two domains share no organizational domain. Alignment fails, relaxed mode included.

Result: SPF passes and DMARC fails anyway. Your SPF record is perfect; it is simply useless in this flow, because it is never consulted. The provider's record is the one that was.

The fix is not to add the provider to your SPF, which would change nothing since its envelope domain remains its own. The fix is to have it sign with DKIM using your domain. Every serious provider offers that setup, usually as two or three CNAME records for you to publish. Once it is in place, d=yourcompany.com appears in the signature, DKIM alignment succeeds, and the flow becomes compliant.

Why DKIM is your best ally

Beyond that case, DKIM has a structural advantage SPF will never have: it survives forwarding.

When a recipient forwards your message to another address, the relaying server is obviously not in your SPF record. So SPF fails systematically on every forwarded message, and there is nothing you can do about it.

The DKIM signature, on the other hand, travels with the message. As long as the signed content is not altered, it stays valid after one or several forwards.

If you take away one action from this article: make sure every one of your senders signs with DKIM using your domain. It is the only route that holds up over time.

The four possible situations

SPF aligned and valid DKIM aligned and valid DMARC result
Yes Yes Compliant, the ideal case
Yes No Compliant, but fragile to forwarding
No Yes Compliant and robust
No No Failure, the message is handled according to your policy

The third row deserves your attention. A sender whose SPF is not aligned is not a problem as long as its DKIM is. Plenty of administrators lose weeks trying to align an SPF that does not need to be.

Finding all this in your reports

Your DMARC reports contain exactly this information, but they present it in a way that misleads anyone reading them for the first time. They show two sets of results for SPF and DKIM: the raw authentication results, and the results evaluated after alignment. The two do not say the same thing, and mistaking one for the other produces statistics that are wrong but entirely credible.

That is the subject of the next article: reading a DMARC aggregate report, line by line.

Frequently asked questions

Why does my DMARC fail when my SPF is valid? Because DMARC does not stop at checking that SPF passes. It also requires the domain authenticated by SPF to match the domain displayed to your recipient. A provider sending with its own envelope address makes SPF pass without ever aligning it with your domain.

Do SPF and DKIM both have to be aligned? No, one is enough. A message with a valid, aligned DKIM signature passes DMARC even if SPF fails completely.

What is the difference between strict and relaxed alignment? In relaxed mode, the default, two domains align if they share the same organizational domain. In strict mode, they have to be identical, character for character.

Should I add my providers to my SPF record? Rarely, and it does not solve alignment. If the provider sends with its own envelope address, your SPF is never consulted. Have it sign with DKIM using your domain instead.

How many senders does a company usually have? Far more than it thinks. Between five and twenty for a small or mid-sized business, counting mailboxes, CRM, invoicing, marketing, support and the website. That is the subject of our article on taking a sender inventory.


Want to see the alignment of your own senders rather than an example's? Alignmarc reads your reports and tells you, in plain English, which of your tools is not aligned and why. The first domain is free.

Read next