7

I have a domain whose SPF record looks like this: "v=spf1 mx ip4:6.7.8.9 -all". The record is valid, and to my understanding implies that allow mails only from:

  • The server that is MX record for the domain.
  • said ipv4 address: 6.7.8.9

Hard fail on all other mails.

When I send an email to a gmail account, using an ip which is not either of these- the email still reaches my inbox. When I look at the headers, it turns out that google did manage to read my SPF record as I intended it to be, and knew it should have failed, and yet it didn't

fail (google.com: domain of me@example.com does not designate 99.9.9.99 as permitted sender) client-ip=99.9.9.99

Would somebody know what I'm missing here?

0fnt
  • 274
  • 5
  • 12
  • 4
    What were you expecting? – Michael Hampton Apr 05 '15 at 19:13
  • 3
    You cannot control what a receiving mail entity does with your mail. Just play around with it. Maybe adding a DMARC record with `p=reject` would send it to the spam folder. Or maybe Google thinks that you (and only you) want all mails from example.com to arrive in your inbox. – Paul Apr 05 '15 at 19:39
  • 1
    SPF doesn't prescribe any action to be taken by an MTA in the event of a failure, soft or hard, or a success either. That is entirely at the discretion of the receiving end, both MTAs and MUAs (your mail client, IMAP rules and filters, etc.). – dartonw Apr 05 '15 at 20:07
  • 1
    Well that's disappointing. It means that anyone can spoof my domain, despite my explicitly noting that only such and such ip addresses are allowed to send email on the domains behalf – 0fnt Apr 06 '15 at 05:00
  • 1
    @user46472 At least you have done what you can. Recipient servers that are SPF aware can be expected to take the failed SPF result into account even if they don't necessarily act based solely on that. – Håkan Lindqvist Apr 06 '15 at 12:09

2 Answers2

6

The behavior on SPF mismatch is entirely up to the receiving end, and considering how frequently SPF is configured incorrectly (or out of date) a lot of providers won't reject based on a mismatch (even with -all instead of ~all). It is common to see the spam score bumped because of a mismatch, and maybe even a match receiving a spam score decrease, but even these aren't always the case either. While the behavior of the receiving end may not always be reliable, it's definitely worth having there in case the receiving end does respect SPF in some way.

Vile Brigandier
  • 418
  • 3
  • 8
  • 1
    Thanks, I think the point about spam score makes sense. Maybe gmail bumps up the spam score to dangerous levels, but the email itself is so harmless that it decides to send it across.. – 0fnt Apr 07 '15 at 04:13
  • 1
    @0fnt you can thank Microsoft for this one, they tell their O365 customers to setup these SPF records. https://technet.microsoft.com/en-us/library/Dn789058(v=EXCHG.150).aspx – Jacob Evans Sep 15 '15 at 18:51
  • @JacobEvans Sorry, could you explain please? Are you suggesting Microsoft tells them to do it incorrectly causing SPF to break? – 0fnt Sep 16 '15 at 11:51
  • 2
    No, I'm telling you since o365, more people have misconfiguration spf records. Usually blocking web contact forms, newsletters, bulk mailers, and other alerting services. I work for an MSP and do about 100K messages per day, I reject SPF -all and have had people tell me my spam filter is broken because I respect their record..... TLDR: -all isn't respected to patch ignorance. – Jacob Evans Sep 16 '15 at 12:00
  • It’s so sad. If GMail rejected `-all`, people would fix things. Just like how people stopped using flash because Apple banned external web plugins from iOS. Sorry for the spam comment :'( – binki Dec 14 '21 at 19:49
4

To the original question: Gmail is DMARC compliant, and so if you want to enforce policy, you should publish a DMARC record with p=reject or p=quarantine and Gmail will then apply your policy when SPF and DKIM fail.

MC78
  • 145
  • 8