SMTP error 451 4.7.26: temporary authentication-requirement deferral

SMTP error 451 4.7.26 is Google's temporary, retriable version of its bulk-sender

authentication requirement. The enhanced code 4.7.26 is the same family used by Google's

permanent 5.7.26 rejection and its connection-level 421 4.7.26 deferral, but at 451 it

appears mid-transaction on a specific recipient: the message failed to show properly aligned SPF

or DKIM authentication, and Google is deferring rather than permanently refusing it.

Fault: sender, specifically missing or misaligned SPF/DKIM, but the 4xx class means you

still have a retry window to fix it before it escalates.

Why it happens

• SPF record does not include the sending IP, or DKIM is not signing outbound mail from this

source at all.

• DKIM signs with a selector whose public key does not resolve, which Google treats the same

as "no DKIM" for alignment purposes.

• The `From:` domain and the SPF/DKIM-authenticated domain do not align, even though both

individually pass - DMARC-style alignment is part of what Google checks under its 2024 bulk

sender authentication requirements.

• A new or recently reconfigured sending domain where authentication records exist but have

not yet propagated everywhere, or were set up for one subdomain while mail sends from another.

• Sending through a third-party platform that signs with its own domain instead of yours,

which can pass SPF and DKIM individually while still failing the alignment check Google applies

under its bulk sender rules, since alignment specifically compares the authenticated domain

against the visible From: domain, not just whether authentication passed in isolation.

• A forwarding rule in the delivery path, such as a recipient's personal forward or an old

mailing-list relay, that rewrites headers in a way that breaks the original authentication

chain before the message reaches Google's own evaluation of it.

The transcript

$ swaks --to test@mailpilots.in --server aspmx.l.google.com --from sender@yourdomain.com
-> MAIL FROM:<sender@yourdomain.com>
<- 250 2.1.0 OK
-> RCPT TO:<test@mailpilots.in>
<- 451 4.7.26 Unauthenticated email is not accepted from this domain. Please see
<- 451 4.7.26  https://support.google.com/mail/?p=UnauthenticatedEmail for more information

How the big three word it

Diagnose it

$ dig +short TXT yourdomain.com | grep spf
"v=spf1 include:_spf.google.com ~all"

$ dig +short TXT selector1._domainkey.yourdomain.com
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."

$ dig +short TXT _dmarc.yourdomain.com
"v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

Confirm all three exist, that the SPF record actually includes your true sending infrastructure

(not just a provider you no longer use), and that the DKIM selector your outbound server signs

with matches a published key.

The fix, in order

1. Publish or correct SPF so it includes every system that sends mail as this domain,

removing any service you no longer use.

1. Enable DKIM signing on the actual sending path and confirm the selector in your outbound

headers matches a DNS TXT record that resolves.

1. Align the `From:` domain with the SPF/DKIM-authenticated domain. If you send through a

third party, make sure it is signing with your domain, not only its own.

1. Publish a DMARC record, even at p=none, so you can monitor alignment via aggregate

reports before enforcing anything stricter.

1. Resend after DNS has propagated, rather than retrying immediately - a 451 deferral will

keep recurring until the underlying record is actually live and resolvable from Google's

resolvers.

What not to do

• Do not treat this as a rate-limit problem. It is specifically about authentication, not

volume - more concurrency will not help and may make the pattern worse.

• Do not ignore it because it is "only" a `4xx`. Google's own guidance is that persistent

4.7.26 deferrals escalate to the permanent 5.7.26 rejection; fix it during the grace window.

• Do not add a DKIM selector without confirming the public key actually resolves. A broken

DKIM record is functionally identical to having none, for this check.

• Do not change your envelope-from domain to work around it instead of fixing authentication
• the new domain will fail the identical check with no history at all behind it.

MailPilot's Domain Health checks validate SPF, DKIM, and DMARC together and flag misalignment

before a bulk authentication requirement like this one turns a temporary deferral into a

permanent rejection.