11–20 of 63 posts
I've had great luck with my personal email servers thanks to this tool: https://www.mail-tester.com/ Gives you a score and suggestions on improving it to reduce the chance of hitting the spam filter.
You just send an email to the address at the bottom and it replies with a bunch of information regarding its SPF, DKIM and/or DMARC.
I wrote this a while ago. I have SPF, DMARC and DKIM all implemented on my mail domain and I still get put in the spam folder: http://penguindreams.org/blog/how-google-and-microsoft-made-... I think part of it might be that I use Linode, and there are other spammers in their data centre, so I could just be on a subnet bad list. But I think a lot of it has to do with Google/Microsoft's spam filters just being crazy ov…
Deliverability is a reputation game.
A few tips from setting up SPF/DMARC/DKIM for a SAAS service: * SPF: limit your record and all includes to 10 DNS lookups (e.g., "A MX include:_spf.google.com" is 3 DNS lookups plus all of the lookups inside the include. * DMARC: to see a strict reject policy, check out Yahoo: $ dig +short -t txt _dmarc.yahoo.com "v=DMARC1\; p=reject\; pct=100\; rua=mailto:dmarc_y_rua@yahoo.com\;" * Mail forwarding: if your app sends…
I wrote this a while ago. I have SPF, DMARC and DKIM all implemented on my mail domain and I still get put in the spam folder: http://penguindreams.org/blog/how-google-and-microsoft-made-... I think part of it might be that I use Linode, and there are other spammers in their data centre, so I could just be on a subnet bad list. But I think a lot of it has to do with Google/Microsoft's spam filters just being crazy ov…
There's very little that can be easily done about this other than moving your smtpd to an ipv4 address with an ISP that has never had an outgoing spam problem (such as for example a /24 that's been held by the same company for 8+ years, in ARIN/RIPE/APNIC/whatever space very tightly controlled by the network engineering team of a clueful local ISP where you know the staff).
There's a pretty direct inverse correlation between the cost of a hosting service ($5/mo VPS vs. minimum $200/mo colocation of a 1U server) and how much outgoing abuse traffic has been sent from the particular netblock assigned to the enduser customers. Cheap hosting company = poor IP space reputation.
I think it's pretty weak they're advertising the use of "~all" in their spf records. Either use "-all" or just don't use SPF I would say. If you can't make a decisive statement about your own domain then it won't be actionable for receivers that evaluate your records.
That's a totally fair point. I'm not entirely sure why most third parties are still using ~ in their documentation but it still seems to be the norm. I do like the definitive nature of -all.
I think it's pretty weak they're advertising the use of "~all" in their spf records. Either use "-all" or just don't use SPF I would say. If you can't make a decisive statement about your own domain then it won't be actionable for receivers that evaluate your records.
A few tips from setting up SPF/DMARC/DKIM for a SAAS service: * SPF: limit your record and all includes to 10 DNS lookups (e.g., "A MX include:_spf.google.com" is 3 DNS lookups plus all of the lookups inside the include. * DMARC: to see a strict reject policy, check out Yahoo: $ dig +short -t txt _dmarc.yahoo.com "v=DMARC1\; p=reject\; pct=100\; rua=mailto:dmarc_y_rua@yahoo.com\;" * Mail forwarding: if your app sends…
Since there is a 10 query limit on SPF, if you delegate your SPF to third-parties like Google then your SPF might blow up unexpectedly if they increase the number of records on their side. Dmarcian monitors that for example.
A few tips from setting up SPF/DMARC/DKIM for a SAAS service: * SPF: limit your record and all includes to 10 DNS lookups (e.g., "A MX include:_spf.google.com" is 3 DNS lookups plus all of the lookups inside the include. * DMARC: to see a strict reject policy, check out Yahoo: $ dig +short -t txt _dmarc.yahoo.com "v=DMARC1\; p=reject\; pct=100\; rua=mailto:dmarc_y_rua@yahoo.com\;" * Mail forwarding: if your app sends…
One minor downside of rmilter is that it will only sign the headers of mail sent by by authenticated users. This isn't a huge deal, but can be a bit of an irritation.
I think it's pretty weak they're advertising the use of "~all" in their spf records. Either use "-all" or just don't use SPF I would say. If you can't make a decisive statement about your own domain then it won't be actionable for receivers that evaluate your records.
That's a totally fair point. I'm not entirely sure why most third parties are still using ~ in their documentation but it still seems to be the norm. I do like the definitive nature of -all.
~all will result in your email being bounced around until accepted even if the IP doesn't match DNS records (more or less).
-all will result in hardfail if rejected by any TO mailserver.
My email is my username at my username dot org.