SMTP 451 4.7.24: deferred for a DMARC policy failure

An enhanced status code of 4.7.24 means the receiving server evaluated DMARC for your message

and the result was a failure it chose to act on. The 4 matters enormously: this is a

deferral, not a bounce. The message is still queued at the sending side and will be retried,

which gives you a real window - typically a few days - to fix DNS before anything is permanently

lost. The permanent form of the same condition is 550 5.7.26, which several providers send

instead, and which does bounce immediately.

Why DMARC fails when SPF and DKIM "pass"

This is the part that wastes the most time. DMARC does not ask whether SPF or DKIM passed. It asks

whether **at least one of them passed *and* was aligned with the domain in the From: header**.

• SPF alignment compares the From: header domain with the MAIL FROM (envelope sender)

domain. If you send From: you@yourdomain.com through a platform whose envelope sender is

bounces@platform.example, SPF can pass perfectly for the platform's domain and still be

unaligned - so it contributes nothing to DMARC.

• DKIM alignment compares the From: header domain with the d= value in the DKIM signature.

A signature with d=platform.example passes DKIM and fails alignment for exactly the same

reason.

So the common failure is a message where both SPF and DKIM pass and DMARC fails. Adding another

include: to your SPF record does not help, because the problem was never the SPF result.

Read the headers

The receiver's own verdict is in the message, and it is unambiguous:

Authentication-Results: mx.example.com;
       dkim=pass header.i=@platform.example header.s=s1 header.b=A1b2C3d4;
       spf=pass (mx.example.com: domain of bounces@platform.example designates
            198.51.100.7 as permitted sender) smtp.mailfrom=platform.example;
       dmarc=fail (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

451 4.7.24 SPF validation and DKIM alignment failed for header.from domain

dkim=pass with header.i=@platform.example against header.from=yourdomain.com is the

diagnosis in one line: both mechanisms passed for the platform, neither aligned with you.

The checks, in order

1. Read `Authentication-Results` before touching DNS. It tells you which mechanism passed,

which aligned, and what policy was applied. Guessing from the error string alone is how people

end up rewriting a working SPF record.

1. Get DKIM signed with your own domain. This is the single most useful fix and it survives

forwarding, which SPF does not. Every reputable sending platform supports publishing a CNAME or

TXT selector under your domain so the signature carries d=yourdomain.com. Do this before

anything else.

1. Check your SPF record resolves within ten DNS lookups. The limit in RFC 7208 is ten, and

exceeding it is a permerror, which counts as a failure rather than as a soft pass. Nested

include: chains from several platforms blow past ten quickly, and the record can look

perfectly valid while failing.

1. Check the DMARC record itself parses. One malformed tag invalidates the whole record. Common

faults: a missing v=DMARC1 at the start, p spelled with a capital or given an invalid value,

a rua without the mailto: scheme, or two DMARC TXT records published at

_dmarc.yourdomain.com - which makes the policy undiscoverable rather than merged.

1. Check subdomain policy. sp= governs subdomains and inherits from p= when absent. Mail

from mail.yourdomain.com is judged by sp, so a strict p=reject with no sp applies to

every subdomain including ones you forgot about.

1. Check alignment mode. aspf=s and adkim=s require an exact domain match; the default

relaxed mode allows an organisational-domain match. If someone set strict mode, a subdomain

signature that would otherwise align now fails.

1. Confirm the fix with a real message to a real inbox and read the Authentication-Results

header again. dmarc=pass in a received message is the only evidence that counts.

Forwarding and mailing lists

DMARC failures on forwarded mail are expected and are not your configuration's fault. A forwarder

re-sends from its own IP, so SPF fails. A mailing list that rewrites the subject or appends a

footer breaks the DKIM signature. A properly DKIM-signed message that is forwarded unmodified

still passes DMARC, which is the practical argument for fixing DKIM rather than SPF: DKIM alignment

is the only mechanism that survives an indirect delivery path.

What not to do

• Do not treat a `451 4.7.24` as a bounce or suppress the recipient. It is a deferral. The

address is fine and the message is still queued.

• Do not relax your DMARC policy to make the error stop. Moving from p=reject to p=none

does stop the rejections, and it also stops the protection. The alignment problem stays, and

anyone can now spoof your domain. Fix alignment, keep the policy.

• Do not add `~all` or `+all` to SPF to "make it pass". +all authorises the entire internet

to send as you, which several receivers treat as a spam signal in itself.

• Do not publish a second DMARC record for a new platform. Receivers that find two TXT records

at _dmarc treat the policy as absent.

• Do not count SPF-only passing as DMARC compliance. It is unaligned in most third-party

sending setups, and it breaks on the first forward.

• Do not wait out the retry window. A 4xx becomes a permanent failure when the sending

server's retry timeout expires, usually after four to five days.

MailPilot checks SPF, DKIM and DMARC for every connected mailbox and flags alignment rather than

only presence, which is the distinction this error turns on. Because it also measures inbox

placement per provider through a seed-inbox network and tracks per-mailbox reputation daily, you

can confirm that a DNS fix actually changed how receivers treat your mail instead of assuming it

did.