E-Mail Spoofing without valid SPF entry

Question

is it actually possible to spoof an email if the sender domain has not a valid SPF-Entry without providing a Reply-To / Error-To / Return-Path field in the email metadata?

Answer 1

You need to look at the sending domain of the spoofed email very closely. It may be similar to but not exactly the same as your domain.

Spammers do not use your domain; they use their own email sender apparatus.

I see this frequently - mostly in Spam Folder, sometime as ordinary email.

Freight forwarders (DHL, FedEx) are victims of this. The email domain includes (say) dhl but is not actually coming from DHL. Spammers can make it look like you are sending the email.

So the fact that your reverse lookups do not function here does not affect the spammer's sending apparatus.

If the email is coming from your domain, check machines for viruses. Spammers can install bogus senders on your machines.

Answer 2

Yes – if the domain in question doesn't have SPF (and doesn't require DKIM signatures through DMARC), then any sender can directly connect to any recipient's incoming mail servers (according to MX records) and deliver any data they want. If you want to add a fake From:, just add a fake From:. If you don't want to add a Reply-To:, just don't add a Reply-To:.

"Return-Path:" is special; if it is missing, then the recipient's inbound server will itself add a Return-Path header according to what you specify in the SMTP MAIL FROM: command (i.e. Envelope-From) – but you can literally just put the spoofed domain in there, too, as there's no SPF to stop you.

The only thing that cannot be fully spoofed is the topmost "Received" header, which is also stamped by the recipient's server and will include the IP address of whoever submitted the message.

However, reading this header needs extra care – while the IP address is real, the "reverse-DNS" name included next to it might not be. The server's rDNS is often in control of the sender, who could use a similar-looking domain if they're doing this as a custom job. Even worse, it's usually shown right next to the SMTP 'HELO' domain name, which – again – the sender can just lie about.

(Note that depending on the recipient's mail system, it could stamp 2-3 headers, e.g. it's not uncommon for a mail server to accept a message; relay it over 'localhost' to an anti-malware scanner; then accept it again on a different port. The recipient should look at some legitimate messages to learn where the boundary between local/external "Received" headers is.)

The swaks tool is useful for testing/experimenting with SMTP. In its default mode (i.e. when "--to" is specified, but "--server" is not) it will directly look up MX records and deliver mail to the recipient without going through any relays. Classics like telnet <server> 25 can be used as well.