Run a free testFree test

DMARC Alignment Failed: Why SPF and DKIM Pass but DMARC Fails

SPF and DKIM can pass while DMARC fails. Learn how domain alignment works, identify the cause, and fix common authentication failures.

You open the headers of a test message and see three results that look contradictory:

spf=pass
dkim=pass
dmarc=fail

They are not contradictory. SPF confirmed that an IP address was allowed to send mail for one domain. DKIM confirmed that a message was signed by another domain. DMARC then checked whether either authenticated domain was connected to the domain in the visible From: address. Neither was.

This often happens when an application sends through a third-party provider. The provider authenticates its own infrastructure correctly, but the message still uses your domain in the From: header.

The repair is usually in the sender's domain authentication settings, not in the DMARC policy.

An email that passes SPF and DKIM but fails DMARC

Imagine an invoicing service sending as billing@example.com. It submits a message through an external email provider. The receiving server records these results:

From: Billing <billing@example.com>
Return-Path: <bounce-123@bounces.example.net>

Authentication-Results: mx.receiver.example;
    spf=pass smtp.mailfrom=bounces.example.net;
    dkim=pass header.d=example.net header.s=s1;
    dmarc=fail header.from=example.com

Illustrative header excerpt. The authentication results shown are the receiving server's findings, not proof that these DNS records exist for the example domains.

Here are the three identities being compared:

Check Authenticated domain Result
Visible sender (From:) example.com The identity DMARC protects
SPF (smtp.mailfrom) bounces.example.net SPF passes, but the domain does not align
DKIM (header.d) example.net Signature passes, but the signing domain does not align

The message is authenticated as mail associated with the provider's domain, not as mail authorized by example.com. That distinction is exactly why DMARC exists. Otherwise, any sender could obtain a valid SPF or DKIM result for a domain they control and use it to justify a forged From: address.

The key rule is simple: DMARC passes if at least one mechanism passes authentication and aligns with the visible From domain. SPF and DKIM do not both have to pass. A passing but unaligned result does not count. See RFC 9989, Sections 4.4 and 5.3.5.

The domains that matter

For DMARC troubleshooting, focus on three fields rather than the sender's display name or the IP address alone.

From: — the author domain. This is the domain in the message's RFC 5322 From header, generally visible to the recipient. In our example it is example.com.

smtp.mailfrom — the SPF domain. This is the envelope sender used in the SMTP MAIL FROM command, often reflected in the delivered Return-Path: header. Providers commonly use a bounce-processing subdomain here. The receiving server validates SPF for that identity. DMARC uses SPF validation of the MAIL FROM identity, not a passing HELO check as a substitute.

header.d — the DKIM signing domain. The d= value in a verified DKIM signature identifies the domain responsible for that signature. The s= value identifies the selector used to locate the corresponding public key. A correct signature for example.net does not, by itself, authorize example.com.

If those fields are not present in a condensed header view, open the full message source. Look for Authentication-Results, DKIM-Signature, From and Return-Path. Authentication results should be interpreted from a receiving system you trust, not blindly from headers that an untrusted sender could have added.

Relaxed and strict alignment

Alignment is a domain comparison. It is not the same thing as passing SPF or validating the DKIM cryptographic signature.

With relaxed alignment, the authenticated domain and the From domain must share the same Organizational Domain. For common setups, this means a signing or bounce subdomain such as mail.example.com can align with example.com.

With strict alignment, the two domains must be identical.

Visible From domain Authenticated domain Relaxed Strict
example.com example.com Pass Pass
example.com mail.example.com Pass Fail
news.example.com mail.example.com Pass Fail
example.com example.net Fail Fail

These examples assume the domains have the expected organizational relationship and authentication has already passed. Under RFC 9989, Organizational Domain discovery uses DMARC's DNS Tree Walk rather than simply assuming every apparent parent and child share an organizational boundary.

The DMARC policy can specify the two alignment modes separately:

_dmarc.example.com. TXT "v=DMARC1; p=none; adkim=r; aspf=r; rua=mailto:dmarc-reports@example.com"

adkim controls DKIM alignment; aspf controls SPF alignment. r is relaxed, s is strict, and relaxed is the default if a tag is absent. p=none requests monitoring rather than quarantine or rejection; it does not make a DMARC authentication failure become a pass. For the other policy settings, see the DMARC tags and policy reference.

Strict alignment can be appropriate for a deliberate domain security policy, but do not switch it on just because it sounds stronger. First confirm that each legitimate sending service can use an exactly matching domain.

How to fix alignment without weakening DMARC

1. Identify which service actually sent the message

Start with the source IP, Return-Path, DKIM d= domain and the receiving server's Authentication-Results. Compare those with your inventory of services: transactional email, customer support, CRM, invoices, marketing and any self-hosted MTA.

A message may be arriving through a service nobody remembers configuring. Do not add an unknown sender to your SPF record just because it appears in a report; first verify that it is authorized.

2. Configure an aligned DKIM signing domain

In many third-party email platforms, the most dependable fix is to enable domain authentication or domain verification for the domain you send from.

For example, change the outgoing DKIM signing identity from the provider's example.net to example.com or an appropriate subdomain under it. The provider may ask you to publish DKIM CNAME records or a TXT public key, depending on how it manages signing. Use the exact selector names and DNS values supplied by that provider.

Once the configuration is active, send a new message and check the actual header.d in its verified DKIM result. Publishing DKIM keys does not prove the outgoing service has started using them.

A single valid, aligned DKIM signature is enough for DMARC to pass even if SPF remains unaligned. A message can also have more than one DKIM signature; DMARC only needs one that both verifies and aligns. If the signature itself fails to verify, use the DKIM signature verification troubleshooting guide before changing alignment settings.

3. Configure a custom MAIL FROM / bounce domain when supported

Some providers allow you to replace their default envelope sender domain with a subdomain you control, such as bounce.example.com. That can make SPF alignment possible while preserving the provider's bounce handling.

Use the provider's documented setup. Depending on the service, it may require an MX record, SPF TXT record, CNAME records or a combination. Those records belong at the hostname specified for the custom MAIL FROM service, not automatically at your domain's apex.

After publishing the records, test a fresh message. Confirm both spf=pass and that the smtp.mailfrom domain aligns with the visible From: domain. Do not assume that adding the provider to the apex SPF record fixes DMARC alignment: SPF is evaluated against the envelope sender domain actually used by the SMTP transaction. If SPF returns permerror, start with the SPF 10-lookup limit troubleshooting guide instead of adding more include mechanisms.

4. Check strict alignment settings before changing them

If your visible sender is example.com, DKIM signs with mail.example.com and SPF uses bounce.example.com, both mechanisms can align in relaxed mode. Under adkim=s or aspf=s, those subdomain identities will not align with example.com for the corresponding mechanism.

If strict alignment is intentional, make the provider use an exact-match identity wherever possible. If it was enabled by accident, assess whether relaxed mode matches your security policy. Changing adkim=s to adkim=r may solve that particular mismatch, but it is not a substitute for configuring an unrelated third-party signing domain.

5. Retest the message, then review ongoing reports

A DNS record lookup answers what is published. It does not tell you which domain a particular message was signed with or which MAIL FROM identity the sending service actually used.

Send a new message through the affected service and inspect the receiving server's authentication results. A successful repair should show at least one aligned authentication pass and dmarc=pass.

You can use the DeliverSight DMARC checker to inspect the published policy and a free DeliverSight email test to examine authentication results for a message you send. A single test does not establish your domain's success rate across every sender. Aggregate DMARC reports help reveal which services still fail over time.

If DMARC still fails

The error message often points to the next step more clearly than another DNS change:

What you see Likely issue Next check
spf=pass, dkim=pass, dmarc=fail Neither passing identity aligns Compare smtp.mailfrom, header.d and header.from
spf=pass, dkim=fail, dmarc=fail SPF is unaligned and DKIM did not verify Investigate DKIM verification, then SPF alignment
spf=fail, dkim=pass, dmarc=fail DKIM signature verifies for an unaligned domain Enable aligned DKIM signing
spf=pass, dkim=none, dmarc=pass SPF passed and aligned No DKIM signature was needed for this DMARC pass, though DKIM remains recommended
DMARC works directly but fails after forwarding Forwarding may break SPF; message modification may also break DKIM Inspect authentication at the final receiver and intermediary behavior

Also inspect which receiver produced the header. If a message passed DMARC at one hop but failed at another, the difference may be the route the message took and whether an intermediary modified it. Do not assume a result observed at one test mailbox is universal.

Two mistakes that prolong the problem

Adding every provider to your SPF record. A provider's SPF include may be necessary for a specific MAIL FROM setup, but it does not by itself align a provider-owned bounce domain with your visible From address. Unnecessary additions also consume SPF's limited DNS-lookup budget.

Changing p=reject to p=none and calling it fixed. A weaker policy may change how some receivers handle failing mail, but the underlying authentication result is still a failure. If legitimate mail is being rejected, coordinate a temporary mitigation with the domain owner while you repair the sender's authentication. Review the impact and keep aggregate reporting active.

What to verify before you move on

You should be able to identify the sending service, the visible From domain, the SPF MAIL FROM domain, and the verified DKIM d= domain. At least one authenticated identity must align under the policy in force. Verify the result on a newly sent message, then watch DMARC aggregate reports to catch other senders using the same domain.

The important distinction is not whether the email has two green authentication checks. It is which domain each green check actually authenticated.

Technical references