6

IP addresses can be spoofed. The Envelope-From and Header-From addresses can be spoofed as well. But is it possible to spoof all three at the same time to send a forged email that passes both SPF and SPF alignment in DMARC?

If it is possible, wouldn't this mean that a domain with only DKIM and DMARC set up would be more secure than a domain with SPF, DKIM, and DMARC set up?

5
  • 3
    IP spoofing is more difficult when a TCP handshake is required, as is necessary for SMTP. See security.stackexchange.com/questions/55279/…, security.stackexchange.com/questions/1009/… and security.stackexchange.com/questions/37481/… for some interesting reading on this subject.
    – mti2935
    Aug 15 at 14:46
  • @mti2935 Yes, but you'd only need to spoof the IP address in a TCP handshake when you're pretending to be the source IP of the email. But how about, say, a malicious MTA relay? Couldn't a malicious MTA relay just say: "Yeah, this email definitely came from this SPF-approved IP address." Aug 17 at 15:41
  • 1
    Normally, in an SMTP delivery, the sender's outgoing SMTP server (whose IP address is specified in the SPF for the sender's domain) looks up the MX record for the recipient's domain, then delivers the message directly to this MX. See security.stackexchange.com/questions/262112/… for more info. The recipient's MX then does the SPF check. I'm not sure how the malicious MTA relay that you mention would get between the sender's outgoing SMTP server and the recipient's MX.
    – mti2935
    Aug 17 at 16:45
  • @mti2935 Ah, I see. That clears it up for me. I had the impression email was sent from relay to relay based on geography, kind of like how IP packets are sent around based on geography. I had no idea the outgoing SMTP server connects directly to the recipient's MX. Thanks! Aug 18 at 14:39
  • 1
    Glad that helps. Just to clarify - emails can be (and often are) sent through multiple relays. But, the IP address of the the final relay on the sender's end (which hands off the message to the recipient's MX) should be in the SPF of the sender's domain. The recipient's MX sees the IP address (at the TCP layer) of the SMTP server that is handing off the message, and checks that this IP address is in the SPF of the purported sender's domain.
    – mti2935
    Aug 18 at 15:01

1 Answer 1

10

Yes. SPF can be spoofed, but it's not easy.

The only reliable ways to do it are with DNS hijacking (such as a MitM attack, which DNSSEC spoils) or with IP spoofing like BGP hijacking. Both of these are nontrivial.

In other instances, you can take advantage of overly-broad SPF implementations.

Some SPF records bless very large ranges of IP addresses. If you are able to obtain one of those, say because it's been rotated out of the domain's pool at a hosting company, you'd be able to spoof that domain's mail until the SPF record is updated. There's even recent news of an attacker bypassing SPF because that record permitted a /2 CIDR (1.1 billion addresses) instead of the /24 CIDR they probably intended (256 addresses).

When SPF employs the ptr mechanism, it says that any network claiming to match passes SPF*. This is problematic because any network operator can choose whatever they like as the PTR record for an IP they control.

(*Technically, the SPF spec requires verifying that PTR records actually point back to the same IP, aka FCrDNS. Because FCrDNS requires more DNS lookups and therefore more latency, RFC 7208 explicitly says "Use of the ptr mechanism and the %p macro has been strongly discouraged".)

Another way to forge mail is by using a cousin domain, such as stackexcharge.com in place of stackexchange.com. A more sophisticated example: stackexchаnge.com uses an IDN homograph: a Cyrillic а (can you tell which one I changed?). With custom domains under an attacker's control, they can set up and then pass their own SPF, DKIM, and DMARC. (In the real world, most cousin domains in phishing and BEC attacks use combosquatting, where extra words are added, like stackexchange-mail.com.)

I'd advocate for DKIM over SPF any day. It is indeed safer, though this mostly comes from the fact that SPF blesses entire hosts, and some hosts (like those of marketing partners) send mail for more than just the domain in question. If a sender can actually ensure they only send with valid and aligned DKIM, I'd recommend an SPF record of v=spf1 ?all (which says nothing passes SPF, though nothing fails it either), but this is likely too difficult for most deployments. Certainly do not consider that without a very thorough DMARC feedback loop to ensure you know what it'll do and you know when a problem arises.

6
  • 2
    with the SPF recommendation, I thought DMARC required both DKIM and SPF to pass for the email to pass DMARC?
    – coagmano
    Aug 16 at 1:42
  • 3
    @coagmano Not necessarily. It requires either SPF or DKIM to have validated a domain; and for that domain to be "aligned" with the From: header in the message. It's not entirely clear to me (skim-reading RFC 7489) what a DMARC processor should do if an SPF record exists but rejects the message (i.e. should it immediately reject, or check DKIM anyway); but it's certainly possible for DMARC to accept a message where no SPF record exists at all.
    – IMSoP
    Aug 16 at 13:38
  • 2
    @IMSoP & @​coagmano – DMARC only looks for whether SPF or DKIM pass. Failures aren't part of this logic and don't matter to DMARC, but anti-spam systems could add a negative weight for failing SPF or DKIM, so it's best not to trigger a failure. This is why I suggest the ? qualifier, which returns a NEUTRAL response, which is the same as if no SPF record existed, but with the added benefit of forcibly precluding nonstandard approaches like best-guess SPF.
    – Adam Katz
    Aug 16 at 15:04
  • @AdamKatz FWIW, I agree with psmears: the subject is the singular "use". Compare "soup of potatoes and lentils is filling" not *"soup of potatoes and lentils are filling" - the subject is the singular "soup", not the plural "potatoes and lentils". You might also say "The ptr mechanism and the %p macro is considered problematic. Their use has been strongly discouraged." I find the past tense the more surprising part - why is it not "is strongly discouraged"?
    – IMSoP
    Aug 16 at 15:11
  • 1
    Thanks both for the expanded explanation!
    – coagmano
    Aug 18 at 2:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.