Knowledge base

check-spf-outbound

<domain>

Whether to check SPF of your own mail before sending to this receiver
in the configuration this is a linecheck-spf-outbound falseinside the block <domain>
Bounce it here so as not to ruin your reputation at the receiver

Enables an SPF check of your own outgoing mail for messages to this receiver. The node checks the address it is about to send from against the SPF record of the return address domain — exactly as the receiving server will.

The outcomes are strict. Pass — delivery continues. TempError — the message goes back to the queue and is retried. Any other result is a bounce; the message does not go out.

It works only with an explicitly set sending address. smtp-source-host or smtp-proxy-source-host is needed — at the node or stream level. Without them there is nothing to check, and the node behaves as on a temporary error: messages pile up in the queue.

The main trap is enabling it for everything at once, the bounce domain included. An error in its SPF record turns incoming bounces into outgoing ones that bounce too — the manual calls this a double bounce. You stop getting feedback and find out about it later than anyone.
What the Hub does. It does not write it. A candidate for enabling: the Hub sets sending addresses itself and publishes SPF records itself — it has both halves of the mechanism. It should be enabled with an explicit exception for the bounce domain.
Recommended values

The bounce domain gets no, everyone else yes. This is the manual’s direct recommendation, not caution.

First the sending address, then the check. Without an explicitly set address, enabling it leads not to bounces but to a stuck queue.

Check by hand before enabling. The pmta check spf command gives the same result but bounces nothing.

The “first the address, then the check” order is ours. From the manual here are the default, all three outcomes, the requirement for a set sending address and the recommendation to exclude the bounce domain.
Example configuration
# no for the bounce domain, yes for everyone else
<domain yourbouncedomain.com>
    check-spf-outbound no
</domain>

<domain *>
    check-spf-outbound yes</domain>
Without the first block, an error in the bounce domain’s SPF record will take away your feedback entirely.
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 ends3 mistakes▶

Enabling it for the bounce domain

§ 10.2

What it costsWith an error in its SPF record, bounces arriving at this domain bounce themselves. Feedback disappears entirely, and you find out about it later than about anything else.
How to spot itThe bounce flow dropped almost to zero with no changes in sending.
How to do it rightTurn the check off for the bounce domain in a separate block.

Enabling it without a set sending address

§ 10.2

What it costsThere is nothing to run the check with. The node writes an error to the log and keeps messages in the queue as on a temporary failure — until their lifetime expires.
How to spot itThe queue grows, there are no deliveries, and the log has check errors.
How to do it rightSet smtp-source-host and make sure it is visible in the settings.

Enabling it without checking the SPF record by hand

our experience

What it costsAn error in your own record turns into bounces of your own mail. The receiving server will not see it at all — the messages will not get there.
How to spot itA sharp rise in bounces right after a configuration edit.
How to do it rightRun pmta check spf for every sending address before enabling.
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
check-spf-outbound <boolean>
Values
yes or no; true and false are accepted on a par with them
Default
false § 3.3.10.2
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<domain>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The value merges across <domain> blocks from general to specific: the best-matching block wins, not the last one in the file. A <domain> block can be nested inside <virtual-mta>. It is picked up by pmta reload; for messages in the queue it takes effect from the next attempt — the check runs at sending.
How to check on the node
The queue settings command prints the effective value; the same result can be obtained by hand, bouncing nothing:
pmta show settings gmail.com/vmta1 | grep -i check-spf-outbound
pmta check spf 203.0.113.10 mail.example.com sender@example.com
The second command gives the same verdict as the enabled check, but without consequences for mail. The Hub does not write this line yet.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Troubleshoot deliverability · Message signing and authentication