SPF when configured properly makes for quick, efficient filtering of
spoofed domain spam. Our filters check the SPF first, and if the SPF
doesnt match, it doesnt even bother wasting any CPU cycles to check the
actual content of the message.(and throws it out)
The only downside is dealing with domain owners who don't understand
them who then complain when you cant/wont accept their email. I have to
deal with at least one person per month that is being blocked because
their domain's SPF is incorrect. I actually had one SSL certificate
reseller last week that didnt include the domain of the SSL provider so
we wouldnt accept their emails. (the SSL provider was sending on their
behalf and the reseller didnt include the provider's servers in their
record) And telling the reseller support rep why we werent getting the
messages resulted in confusion and got us nowhere. ("I dont know what
you are talking about. I'm just a CSR.")
On 8/31/2017 11:05 AM, Lewis Gardner wrote:
I'm struggling on how to set up these records for domains hosted on a
5209R server.
The SPF record looks fairly straightforward. Make a TXT DNS entry with
some test.
DKIM appears to need a 1024 bit RSA key. Where do I get this? I assume
there I need one per domain so a server may have several?
DMARC appears to be like SPF in that it is another TXT DNS entry.
Personally I think most of this is lipstick on a pig in that these
methods appear to be attempts to make something secure that is
inherently not. But I'm not in charge...
Any pointers?
_______________________________________________
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
_______________________________________________
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx