Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Junk/spam is far more complex than that. That alone will not be an issue almost certainly.

HOWEVER, there are many issues with this site that will cause messages to get marked as spam with a high frequency (including my innocuous test message to a gmail address).

1) There's no recommendation to setup SPF for your domain. This is the big one. SPF is a big deal, and not having any spf will give you a higher spam score.

2) The creator of this service did not setup a reverse dns entry for the ip to the mx domain. There's no reverse dns at all (even though he's hosted with ramnode and ramnode supports rdns).

3) The creator does not allow you to add dkim signing keys; you can't dkim sign your messages.

The above factors ensure that google has a high chance of marking you as spam, as well as any other sufficiently strict spam software. amavisd did not mark it as spam for me, giving it only a spam score of a little over 2, though I have mine configured at a high threshold compared to many people.

Because of the above reasons, I wouldn't consider using this. The lack of a rdns entry is especially unforgivable because it's so easy and helps with your spam rating so much. The other factors are all additional complexity because the owner of the domain (user) would have to do additional work beyond the dns record, but those should also be there.

Perhaps the creator will see this and improve these problems.



sort by: page size:

Set the spf fields in DNS and you should be fine. It's not really that hard unless you do send out spammy mails.

Wonder how it works for you... I've been running my own mail infrastructure for 10+ years. hosting tens of domains with hundreds of thousands of messages daily.

That's said, most of my spam senders match SPF and have proper DKIM records. Only few absolutely outrageous spammers ignore it.

Setting DKIM and SPF is not a rocket science and I'd be extremely surprised if spammers wouldn't do that.


I see, thanks. I had the experience of having some mails ending in gmail spam box until we added SPF, but we were a young company (and thus, domain name), and it was in 2014. I wouldn't feel confident recommending not using SPF to anyone, though :)

Nonsense.

You have a weird idea of what information SMTP servers care about when determining spamminess. DNS is vitally important to getting your mail delivered...but what CNAME is in your MX record is completely and utterly unimportant (it's like worrying about what the name of your mailman is...George or Franny...when the important thing is your address and zip code).

Get your DNS RFC compliant, get your SPF records correctly configured for the servers that will send mail for your domain, make sure your sending SMTP server(s) are not in any RBLs, and you'll be fine. MX records are irrelevant.


If it's demonstrably not true, why is it then that multiple reports of mail going into SPAM folder stop coming in, once I setup SPF and DKIM? While it's true that reverse DNS is probably a bigger factor. Not having these 2 setup is going to increase your odds of ending up in the SPAM mailbox.

SPF/DKIM are not intended to prevent people from sending spam.

They are intended to let a domain owner tell other email providers what servers have the right to send email from that domain (and sign email).

I can send email all day from joboffers@google.com. But most email providers will check SPF and see that my VPS IP is not authorized by google.com to send email, and it will go to spam.

Those standards wouldn't keep me from registering example.com, setting up SPF correctly, and then spamming. There are other techniques to filter out that kind of behavior.


From my experience, Gmail will send to spam everything from a small server that has no SPF (even when DKIM is on and OK -- which is strange because it basically has SPF built-in) and when the sender is not in the address book -- this is pretty enough for massive issues.

It's somewhat true. DKIM checks the authenticity of a email domain. So it definitly helps. SPF does barely the same. that's why you got into spam if you not set RDNS OR DKIM OR SPF. Since the other server can't be sure if the server is allowed to send mails with the provided domain.

Mailservers are simple, basically you can send with every domain available, however that won't work since other servers will handle that via SPF, RDNS or DKIM.


You'd be surprised at how many sending domains do not have SPF configured correctly. When you look at DKIM and DMARC, it get worse...

How is spam related to SPF and DKIM? Those prevent forgery, but if a spammer actually owns a domain, they can send you whatever they want. That's where the majority of spam comes from, so it's far from a solved problem.

They kind of solve a different problem though - verifying that the email sender is really authorized for that domain.

Nothing prevents spammers from setting up their own domain with valid spf, dkim, dmarc.


Its inaccurate to say that SPF, DMARC and DKIM setup this way is a "misconfiguration", It still allows anybody you are mailing to verify that email is from your mail server, and your domain, which is good enough for anti-spam purposes.

Setting SPF to neutral (or softfail) and DMARC to none just ensures stuff like mailing lists forwarding mail from your domain aren't automatically marked as spam.

In my experience it does not matter if you have very strict SPF and DMARC policies, with a good reputation IP address, and an old domain, both of which have never sent spam.

GMail will absolutely still spambox you.


SPF, DKIM and DMARC?

I jumped down the rabbit hole and set up my own mail server about a year ago. With postfix configured to look at the above I get zero spam. Looking at logs, I do get lots of connection attempts from random IPs in China and such, but my postfix unilaterally rejects anyone that doesn't have good DNS settings.


Some of the things it doesn't contain, though -- like Message-ID and Content-Type headers -- are likely to contribute to its spam score.

If your domain has SPF headers which don't permit mail from the (residential?) IP you're connecting from, that'll be a major factor as well.


Sorry, but your advice have been detached from reality for a long time.

SPF is not a "should" anymore, it is a must. Many major e-mail providers will outright reject your e-mail at SMTP level, unless you have correct SPF record. Rest will move SPF-less e-mail to spam on automatic basis. In this sense SPF does help you to get delivered, and avoid getting into spam bin, but your chances can only go from "100% spam" to "90% likely spam", not "0% likehood of being spam".

DKIM is not a major consideration for Gmail (or anyone, as far as I know) and have never been one. You will not magically avoid spam bin by using DKIM. Instead DKIM provides a great opportunity to botch your reputation with mail servers: as soon as you forward a e-mail (between providers or within the same provider) it will lose it's DKIM validity, and thus may get classified as spam (!!) on the basis of invalid DKIM signature. Boom! you are a spammer now.

Valid SSL cert and valid SPF are the only things, that have noticeable impact on Gmail's treatment of your email. DKIM and DMARK and largely useless and can only get you in extra trouble.

As for bulk email, it is going to be classified as spam until your domain and IP gain sufficient reputation. The only way to gain that reputation is to send slowly increasing amount of email for long time without being marked as spam. Being a rich business, Google's client, hanging on Google's forums, using Gmail as your mail server and having at least dozen contacts among Google's employees also helps.


None. SPF, DKIM and DMARC only affect outgoing mail.

Incoming mail is handled entirely by your mail server which is pointed to by your MX record.

This is actually where a lot of the confusion comes from. When you buy a domain, it doesn't go anywhere until you point it to specific web servers by adding A or CNAME records in your DNS. Same thing with your incoming email, nobody knows where to send a message until you setup your MX records. You can setup a web server that will serve any domain you want, but until the DNS points to it there's not an easy way for people to find it.

Outgoing mail had no such check though. Any server could send a message claiming it was from your domain unless you took the time to specify where your mail is coming from.

And no, this won't hurt you at all. All it does is tell the receiving mail servers that for an email from the domain to be valid, it must pass a DMARC check. If you subsequently setup something like Google for your domain's email, you'd just update the record by following the instructions Google will give you. For example:

"v=spf1 include:_spf.google.com ~all"

This let's Google manage the set of IP addresses. Google will likely also give you instructions to setup DKIM by adding a couple of additional records. This will ensure anything sent by Google for you domain will pass both SPF and DKIM, allowing it to be properly validated and delivered.

You'll notice that "~all" instead of "-all" as well. When you're actually sending email from the domain, it's best to use "~all" instead of "-all". The "-all" can sometimes be over zealously strict and by using "~all" instead it will be enforced but let you defer to the DMARC policy for the enforcement of failures (such as forwarding or list serves that DKIM would still survive but SPF wouldn't).


I haven't had any particular issues getting past spam filters, it certainly takes some time to build IP reputation but in general with nothing more than SPF and RDNS properly configured my mails get through. I really should get DKIM/DMARC working eventually, but my current email solution (GroupWise) doesn't support it natively so I'll have to do some nonsense for that..

I recently set up my own self-hosted email solution again and made sure to do all of these things:

    * Proper A and MX record set up in DNS per SMTP standards
    * Proper SPF record in DNS
    * Proper DMARC record in DNS
    * Proper DKIM record in DNS
    * SMTP server (postfix) is not configured as an open relay
    * SMTP server is configured with a DKIM milter to sign outgoing messages
I used basic guides for the DMARC/DKIM stuff since that was new to me and tested with a Gmail account. The first few messages were marked as spam but I was able to unmark them. Once I was able to verify a correct SMTP setup, after two or three unmarkings, all messages were just delivered normally and no longer marked as spam. Google will even email you a report to help debug issues if your DMARC record is set up for it.

As far as I know this is about the best you can do. Everything else is pretty much getting your mail server IP addresses removed from various blacklists which can be easy to impossible depending on the service. The other option would be to forward to another service that allows relaying and has IP addresses with better spam scores but I personally prefer to avoid that.


Only if you using it for spam-like email marketing. With correct SPF and DKIM config, also dedicated IP, it would be no problems at all.
next

Legal | privacy