Knowledge base

Do not send what will fail the check at the receiver

critical

outbound SPF checking
Check yourself before the receiver does

A receiving server checks the address a message came from against the sender domain’s SPF record. If they do not match, the message is rejected or goes to spam, and the address’s reputation suffers. This mechanism moves the same check to our side: the node checks itself before sending.

Three outcomes. Pass — we send. TempError — we retry later. Everything else — we bounce, and the message does not go out at all.

The check requires knowing the sending address. It is taken from smtp-source-host or smtp-proxy-source-host; without them the node cannot perform the check.

The main trap is the bounce domain. If its mail also goes over SMTP and the check is on for it, then with an error in its SPF record the bounces themselves will start bouncing — the manual calls this a double bounce. Feedback is lost entirely, and it may not be noticed right away. For the bounce domain the check is turned off explicitly.
What the Hub does. It does not use it, but this is a direct candidate: the Hub knows the sending addresses and publishes SPF records itself, so it already has both halves. It should be enabled together with an explicit exception for the bounce domain.
Example configuration
# the check is off for the bounce domain and on for everyone else
<domain yourbouncedomain.com>
    check-spf-outbound no</domain>

<domain *>
    check-spf-outbound yes</domain>
The order of blocks does not matter: the best-matching one wins. What matters is that there is an exception for the bounce domain.
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 ends2 mistakes▶

Enabling it for the bounce domain

§ 10.2

What it costsAn error in its SPF record — and the bounces themselves start bouncing. Feedback is lost entirely, and the cause looks like “receivers stopped sending bounces.”
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 setting a sending address

§ 10.2

What it costsThere is nothing to run the check with. The node writes an error to the log and treats it as a temporary failure: messages sit in the queue until they expire and bounce on timeout.
How to spot itThe queue grows, and the log has SPF check errors.
How to do it rightSet smtp-source-host at the node or stream level.
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.
How to check on the node
You can also check by hand that mail will pass the check — with a node command, before enabling anything:
pmta check spf 203.0.113.10 mail.example.com sender@example.com
pmta show settings gmail.com/vmta1 | grep -i check-spf-outbound
The first command answers the same way a receiver would: by the address, the greeting name and the return address. The Hub does not use this mechanism yet.
In the Hub
Cost of a mistake
dangerous: effects outlast a rollback
Scenarios
Troubleshoot deliverability · Message signing and authentication
Priority
critical