SPF records - for all A records?
-
I'm reading up on SPF/DKIM/DMARC and ran across several posts where people indicate they create SPF records for all all A records in their DNS (not sure why they would skip C Names?)
Is this really necessary? Does anyone else here do that?
Here is one such comment
It is a best practice to have a "does not send" SPF record (i.e. "v=spf1 -all") on every HOST within a domain that doesn't otherwise have a different SPF record -- as well as for the domain itself plus any non-host label in the domain that has MX or SMTP-service-SRV records. The idea is to permit detection that the host-part of a sending mailbox is forged, and for those idiots that don't check others' SPF records, that you have protected all possible labels in your domain that could be backscatter targets.
-
@dashrender said in SPF records - for all A records?:
I'm reading up on SPF/DKIM/DMARC and ran across several posts where people indicate they create SPF records for all all A records in their DNS (not sure why they would skip C Names?)
Because people are stupid? Nothing in SPF prevents any bad actor from doing anything with any domain or sub domain.
Sure, for the systems that listen to SPF, it will drop the inbound mail. But it still has to process the inbound mail to check the SPF before it decides to not deliver it. So there is no help in slowing what hits your system.
Today, most systems also will flag anything without valid SPF as high risk of SPAM already, so there is really not much difference.
-
@jaredbusch Thanks - I figured it was really unnecessary work that really probably doesn't provide any real benefit.
Obviously you want to protect your mailing domain, and you might as well be a good net-i-zen and create empty SPF records for your non -mailing domains, but all the hosts? nah.
-
@dashrender said in SPF records - for all A records?:
@jaredbusch Thanks - I figured it was really unnecessary work that really probably doesn't provide any real benefit.
Obviously you want to protect your mailing domain, and you might as well be a good net-i-zen and create empty SPF records for your non -mailing domains, but all the hosts? nah.
The reasoning is for backscatter. But no system deployed correctly has a problem with it anyway.
-
@dashrender said in SPF records - for all A records?:
I'm reading up on SPF/DKIM/DMARC and ran across several posts where people indicate they create SPF records for all all A records in their DNS (not sure why they would skip C Names?)
Is this really necessary? Does anyone else here do that?
Here is one such comment
It is a best practice to have a "does not send" SPF record (i.e. "v=spf1 -all") on every HOST within a domain that doesn't otherwise have a different SPF record -- as well as for the domain itself plus any non-host label in the domain that has MX or SMTP-service-SRV records. The idea is to permit detection that the host-part of a sending mailbox is forged, and for those idiots that don't check others' SPF records, that you have protected all possible labels in your domain that could be backscatter targets.
It's indeed best practice to do so.
http://www.open-spf.org/FAQ/Common_mistakes/#all-domainsI haven't bothered though. But I have DKIM and DMARC also setup. If both SPF and DKIM fails, the DMARC policy instructs the receiver to completely reject the email.
Just using SPF isn't an effective measure against spoofed emails. DKIM adds a secure signature to each mail and DMARC is the policy on what the receiving end should do.
From received DMARC reports you can see when servers are trying to spoof your domain's email addresses.
BTW you only need to add an SPF for the A record because that is where the IP address is. CNAME is just a pointer to another A record.
Use something like this to check you SPF records:
https://www.dmarcanalyzer.com/spf/checker/
On this one you'll see how SPF records are resolved to IP addresses, sometimes in multiple levels. -
This site is pretty good also for checking the whole mailing stack
https://www.checktls.com/TestReceiver -
@dashrender said in SPF records - for all A records?:
This site is pretty good also for checking the whole mailing stack
https://www.checktls.com/TestReceiverThat one was new to me. I'm going to check it out.
Another awesome resource, one that can test your own email from the receiving end is https://www.learndmarc.com/
It just great and will explain what happens.It's made by uriports. We just started to evaluate their DMARC report monitoring service. Looking good so far.
