• Sp chevron_right

      Ask Al: SPF -all or ~all?

      pubsub.slavino.sk / spam_resource · Wednesday, 22 December, 2021 - 13:00 · 2 minutes

    Hey, Al! I was wondering if you could provide some guidance about SPF record format. Is it better to list the exact IP(s) in the SPF record? How about using the SPF dash (-all), or tilde (~all)? Which way is more common and better for deliverability?

    [spf image]

    SPF aka Sender Policy Framework is a form of email authentication. It's basically just a DNS record that you configure for your domain, and that DNS record usually just contains a list of the IP addresses of your mail servers (or somebody else's mail servers that are allowed to send mail on behalf of your domain). Wikipedia's the place to start if you want to dive into what SPF is in great detail. If you're reading on past this point, I'm going to assume that you know what an SPF record looks like .

    When you create an SPF record, the last bit of it ends in the "all" mechanism, with one of three "modifiers:" ~all, -all or ?all. Here's what each one does.

    • Using ?all means "neutral/no" policy defined. This is sort of useless. You might see an ISP do this to say, "I'm not sure what all of my IP addresses are, but here, at least you have these ones, you can perhaps choose to whitelist my mail based on these." Cranky nerd jerks who want to fight about whether or not SPF should even exist will sometimes use this, as well. (If you find a "+all" mechanism, then you've definitely found one of those.)
    • Using ~all means you're setting a "soft fail" policy. You see this most often. The sender is saying "I am pretty sure I've listed all of my IPs in my SPF record, but I'm hedging my bets slightly."
    • Using -all means you're setting a "hard fail" policy. The sender is saying "I've for sure gotten my SPF record right, this is all of my IPs." It implies that ISPs should treat mail harshly if it references that domain but fails SPF.

    For most senders, I recommend -all. Some folks recommend ~all, and that's okay, too, but historically there was an implied modest deliverability boost for using -all, so that's why I initially went that route, and why I still recommend it. For a lot of ESP send platforms, their use of a domain or subdomain is often pretty regimented and templated and the chances of sending mail through some other "weird way" that you didn't initially contemplate is very low. Meaning -all is generally going to be safe to use in that scenario.

    This can also go hand-in-hand with DMARC. DMARC (and a DMARC reporting tool) can help you monitor for mail that fails SPF, helping you to catch when you might have accidentally gotten your SPF record wrong (perhaps not including all IP addresses).

    For another point of view, EasyDMARC covers this on their site here . They recommend ~all instead of -all, but sometimes smart people can come up with different guidance, and I think that's okay.



    Značky: #Network, #spf

    • Sp chevron_right

      Comcast.net has new sending IP addresses

      pubsub.slavino.sk / spam_resource · Tuesday, 26 October, 2021 - 13:53 edit

    American multinational telecommunications conglomerate Comcast , most well-known to us Internet users here in the US as the provider of cable modem-based internet service Xfinity, has announced that they'll be sending outbound mail from subscribers via new (additional) IP addresses ranges.

    On the Mailop list, a representative from Comcast shared that the new IP ranges are as follows:

    • ip4:96.103.146.48/28 ip4:96.102.19.32/28 ip4:96.102.200.0/28
    • ip6:2001:558:fd01:2bb4::/64 ip6:2001:558:fd00:56::/64 ip6:2001:558:fd02:2446::/64

    These are indeed included in the comcast.net SPF record .


    Značky: #spf, #comcast, #Network

    • Sp chevron_right

      Ask Al: Help! I'm getting bounces for mail I didn't send

      pubsub.slavino.sk / spam_resource · Monday, 27 September, 2021 - 12:00 · 4 minutes

    help2.gif
    Help! I'm getting mail from MAILER-DAEMON@(various domains) with subject lines like: Delivery Status Notification (Failure), failure notice, Mail delivery failed: returning message to sender, Message Delivery Failure - Mail Delivery System, **Message you sent was blocked by our bulk email filter**, Recapito fallito, Returned mail: see transcript for details, Undelivered Mail Returned to Sender. These all seem to be bounces back from mail I didn't send. What is happening and how do I make it stop?

    In this case, my friend (the person experiencing this pain) owns their own domain name. What's happening here is that spammers are forging email addresses at their domain, using them as from addresses for their unwanted, garbage spam runs, so that bounces back from the spam come to them, because the spammer doesn't care about or want to process bounces.

    The good news is, as I mentioned all the way back in 2013 , is that spammers don't tend to fixate on one domain name or email address forever, so they'll probably move on to annoying somebody else shortly. But there are a few things you can do, as a domain owner, to help minimize the chances of having to receive these unwanted bounces:

    • Implement a Sender Policy Framework (SPF) DNS record for your domain name, specifying the IP addresses that are meant to send mail for your domain. Set it to " dash all " -- you want ISPs to know that they should be free to filter mail more harshly if it fails SPF validation checks.
    • Implement DKIM for your email sends. Even at the SMB level, most mail platforms provide instructions on how to configure things so that your email sends will all be authenticated via a DKIM signature. If you can't easily do this, SPF is quite likely "good enough" -- but if you can implement DKIM, you should. In some cases it's going to provide more robust email authentication compared to SPF. (I could spend another six pages diving into why I think that's the case, but in the interest of helping you move on with your life, I'll spare you.)
    • Implement DMARC . DMARC can be a bit scary in that you have to make sure all of the email you send legitimately is authenticated with SPF or DKIM. But, especially at the SMB level, you can do this. It's not hard, and don't let yourself be scared -- there are tools (like the colorful Mail Tester ) that will help you test your email authentication settings to make sure you've got it right. But the key here is that enabling DMARC, with a restrictive policy like p=reject, tells ISPs to block mail that purports to be from you, but doesn't pass SPF or DKIM. You don't HAVE to work with a DMARC monitoring partner to enable DMARC -- you can publish a TXT record for _dmarc.(your domain) that contains nothing more than "v=DMARC1; p=reject;" (without quotes) and that'd do it.

    DMARC is the key there. Turning that on means your domain name is no longer going to be useful to deliver spam to ISPs (like Gmail) that will block mail that fail DMARC. It makes your domain name much less palatable as an unauthorized spam sending domain.

    Bonus tip: If you own your own domain name and use it for email with something like Google Workspace, there's another setting you should look for and configure: The wildcard or catch-all email setting . It can be handy (and quite useful) to configure your email service to accept mail to any address at your domain -- for example, it can be used to create custom email addresses for different registration forms -- give irs@yourdomain to your accountant and bestbuy@yourdomain to the electronics retailer, so you can track usage and/or turn off an address later, if you want. Unfortunately, if you leave "catch-all" forwarding on, that means if a spammer makes up the address ihateyourguts@yourdomain and sends a bunch of spam, those bounces are going to come back to the "ihateyourguts" address and end up in your inbox. If you turn off the catch-all, that puts a stop to that. I know, it's a bummer to turn off the easy custom address ability, but it's something to consider -- weigh the plusses and minuses of being able to receive mail at any address at your domain, versus the unintended side effects of receiving unwanted "backscatter" bounces.

    I helped my friend implement all of these -- including disabling "catch-all" email forwarding (while helping them build a manual list of email aliases to continue forwarding to their main inbox) -- and we think it helped. It's not like we did a scientific study, but the bounces dropped off and disappeared pretty quickly. I think the spammers moved on to greener pastures.

    If you're new to all of this and wondering what SPF, DKIM and DMARC DNS records look like, here are the ones for spamresource.com: SPF , DKIM , DMARC . The SPF record contains the IP addresses of a couple of servers I own as well as an include showing that I utilize Google Workspace. The DKIM record (called a DKIM public key) is a DNS string provided by Google Workspace's DKIM configuration tool, and the DMARC record is just a very simple "tell ISPs to reject it if it doesn't pass authentication."


    Značky: #forgery, #help, #spam, #Network, #backscatter, #bounces, #spf, #dkim, #dmarc