Demo
Demo

Knowledge base

PMTA knowledge base›Block <source>›Directive§ 3.3.7.69

reject-spf-check-temperror

<source>

Whether to reject a message when the check could not be performed
in the configuration this is a linereject-spf-check-temperror trueinside the block <source>
The network is to blame, not the sender

A temporary error means that the check could not be performed: the resolver did not respond, the query did not get through, the sender domain’s name server is unavailable. It has nothing to do with the message itself.

The refusal here is temporary too — the only one of the three. The sender is invited to try again later rather than refused permanently. The default is to reject.

The cause is often on your side. The node’s own resolver does not always respond; SPF checking loads it more than anything else, because one record can pull a dozen queries along with it.

The main trap is that your own resolver becomes a point of failure for receiving. While the check is off, its unavailability does not prevent accepting mail. With the check on and refusal on a temporary error, the node starts rejecting messages every time the resolver lags — and the sender is not to blame for that.
What the Hub does. It does not write it: inbound checking is not enabled. If it gets enabled, this outcome is worth keeping on deliberately: a temporary refusal is more honest than accepting a message about which nothing was established.
Recommended values

The default is defensible. A temporary refusal does not lose the message — the sender will retry.

But look at the resolver first. If it responds intermittently, the enabled check will turn that into receiving refusals.

Count the share of such outcomes. Its growth is a sign of a malfunction on your side, not the senders’.

Pointing to the resolver as a point of failure is ours. From the manual here come the default, the temporary refusal code and an example cause: DNS records could not be retrieved.
Example configuration
# a temporary refusal does not lose the message — the sender will retry
<source 0/0>
    check-spf-inbound true
    reject-spf-check-temperror true</source>
Before keeping the default, make sure your own resolver responds reliably: otherwise the refusals will be yours, not the sender’s.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends1 mistake▶

Enabling the check with an unstable resolver

our experience

What it costsEvery hiccup of the resolver turns into receiving refusals. Senders see temporary refusals and retry, the load grows, and the cause is inside your node.
How to spot itBursts of temporary refusals coincide with delays of your own resolver.
How to do it rightFirst make name resolution stable, then enable the check.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
reject-spf-check-temperror <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
true § 3.3.7.69
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<source>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value is set in a <source> block and applies to mail submitted through a matching source; with several matching blocks the most specific wins. It triggers only with check-spf-inbound enabled. It is picked up by pmta reload.
⇄

Related directives

2 relations

Does not work without

check-spf-inbound<source>The line does not trigger until inbound checking is enabled. § 3.3.7.69

Affects

Two inbound report processors and what to do with themA message rejected on input never reaches the processors. § 3.3.7.69

How to check on the node
The value is set in the source configuration; the resolver’s stability is checked separately:
grep -n reject-spf-check-temperror /etc/pmta/config
grep -ci 'temperror' /var/log/pmta/pmta.log
A growing number of such outcomes almost always points to your own resolver, not to the senders. The Hub does not write this line.
◇

What else to read

3 articles

◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.◇What to do with an accepted messageWhat the node does with an accepted inbound message: forwards it, writes it to a file, discards it, passes it to a program or parses it as a bounce or complaint.◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.

In the Hub
Cost of a mistake
dangerous: effects outlast a rollback
Scenarios
Bounce classification · Receiving inbound mail
Neighboring settings of the block <source>:reject-spf-check-permerrorreject-spf-check-failcheck-spf-inboundcheck-dkim-inboundprocess-x-dkim-optionsAll 74 directives of the block →