Re: SPF Record Issue

> A user sends email with from: address as [email protected].  The
> domain.com doesn't have spf txt record.  The smtp server used to send
> this email is mx1.anotherdomai.com.  

First, not to sound Clintonian, but let's agree on the definition of
"is." My response applies when "is <hostname>" means "uses the
HELO/EHLO value <hostname>".

(That is, it _does not_ apply when "is" means "has a PTR pointing to
<hostname>" other possible meanings.)

> Are you saying spf checker on the destination smtp server is going to
> know to check the source smtp host for spf txt record?   

The smtp-sender is providing its hostname to the smtp-receiver using
the HELO command.

The SPF standard does not _require_ that an smtp-receiver that is
claimed to "support SPF" (or "honor SPF," whatever) do anything with
the HELO. The standard only requires that the domain of the envelope
sender be checked, but also _recommends_ that a receiver checks HELO.

Regardless, you must be prepared, if you as a sender claim to "use
SPF" (or "publish SPF," or whatever terminology that implies that you
think SPF is useful) to have your HELO hostname looked up. The HELO
lookup amounts to checking if postmaster@<hostname> would be allowed
to send from the sender IP.

> If so, what happens when there is clash between domain.com's spf txt record and
> that of mx1.anotherdomai.com where domain.com forbids the smtp host
> from sending the email and mx1.anotherdomai.com allows?  

In the case of "forbidding" (meaning hard fail) there isn't really any
such thing as a "clash." Hard fail on one would typically have veto
power, because that literally means "not allowed" -- what part of "not
allowed" would the sender not understand? :) It is very unlikely that
there would be any kind of early-exit/ short-circuit mechanism that
would allow the recommended HELO check to both *run and fail* and not
end up with the whole message being rejected; likewise, if the
required MAIL FROM runs and fails the whole message is doomed.
(Imagine, if this more familiar to you, a list of firewall rules where
any Deny causes the connection to be denied, whereas an Allow just
falls through to the next rule, rather than exiting the rules
checker.)

When it comes to softfail/neutral/none from each check, it's up to the
receiver to decide who "wins" after computing the weights of every
test (which may at that point include content checks on the body of
the message). It may be that an SPF softfail only on the HELO isn't
penalized as much as an SPF softfail on the MAIL FROM (for the the
simple reason that a lot of people don't know about SPF checking the
HELO, so the HELO results may be more coincidental than deliberate).
But this is all up to the receiver's logic/wizardry/halfassedness.

Ultimately, you can't *know* what someone will do with your message,
but you can try to get the fullest understanding of SPF as you roll it
out. You may temporarily screw up your SPF -- we all do at times, just
as with any DNS stuff -- and get unwanted results, and you need to
know how to handle that. If you don't feel ready to handle
troubleshooting it live, maybe you aren't ready to publish SPF yet.

By way of consolation/warning, I learned the other week that at my
previous employer, a sysadmin got the bright idea to create multiple
TXT records to "spread out" the SPF info. If he had come to this list
first, we could've set him straight, but alas, he put this in place
and no one there (IT staff of 20), including that guy, is officially
responsible for DNS. The marketing staff is being more professional
about it than the techs (not a common scenario) while mail gets
bitbucketed all the time and everybody in the IT bullpen says users
are imagining things... I digress, but the point is SPF isn't as
simple as people think, and you have to at least charge yourself with
getting into DNS + SPF for a few weeks/months, or it's just going to
create technical debt -- technology that's in production, but you
never really grokked and aren't ready to troubleshoot. As an
unexpected consequence, you may choose to believe that a problem
couldn't be with the thing you didn't understand, because that would
mean you'd have to learn how it works after all this time. You don't
want to get into that situation.

> which one is more preferred by the spf checker? spf txt record for
> domain.com or mx1.anotherdomai.com?

Well, you MUST have the record for the MAIL FROM if receivers are
going to think you "use SPF" in the real world. But (to put it mildly)
not every sender puts SPF records in their DNS. Of any kind. So, for
example, having a pass record for the HELO, yet not having a record at
all for the MAIL FROM is lame and you shouldn't say you use SPF, but
it happens... and you may get away with it because there are a lot of
senders out there who are ignoring SPF completely.

Look at this way: you have at least 4 responsibilities when operating
an smtp-sender: to keep your services running and available, to be
ethical when it comes to unsolicited mail, to be proactive in not
allowing your domain to be abused... and to be upright in only
deploying technologies that you know reasonably well so you don't let
customers/clients down when there's a problem (which is really just
part of the first responsibility, but obviously I felt like harping on
it!).

-- Sandy