-2

One of the main reasons of putting your server behind CloudFlare is to hide your server's IP address so an attacker can't DDoS your IP and render CloudFlare obsolete. By putting your server behind CloudFlare their IPs are exposed to the outside world so your server's IP address is only known to you and nobody else.

The problem here is when you want to use a contact form on you website to receive mail from your visitors. By using the contact form, basically your original server's IP is sending emails to you or whichever address you want.

But now since the server is behind CloudFlare the following SPF record becomes a hindrance

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

because that letter a between v=spf1 and include:_spf.google.com tells that all IPs that have A record in DNS are permitted to send email. However, by using CloudFlare, the original server's IP is no longer visible, and CloudFlare's IP becomes identified as the one which is permitted to send emails, not your real server's IP. And as result, every email sent through PHP, from you server, is marked as spam because that IP is now basically not allowed to send email.

Of course you can add your real server's IP in your SPF record, as shown below, to allow it to send emails and solve the problem right there

v=spf1 a ip4:xxx.xx.xxx.xx include:_spf.google.com ~all

but that would defeat the purpose of using CloudFlare in the first place. They too explicitly tell you not to put your server's IP anywhere that can be publicly revealed including SPF and TXT entries.

When you want to send/receive emails directly by using Google Apps, there is of course no problem because you're using Google Servers to accomplish that (your SPF record says they're allowed to do so) but in the case above you're unable to use a simple contact form on your website if you want to use CloudFlare.

You can also change the last bit in the SPF record from ~all to ?all so all other IPs other than those specified in the SPF record can be treated as neutral, but that would not stop marking the emails from your contact form as spam.

Am I missing here something very obvious or if you want to use CloudFlare you should forget about using you server's IP at all?

4 Answers 4

2

A couple of possible solutions come to mind:

  • If you are only ever sending email to yourself, you may be able to whitelist your own server on the recipient side (not through SPF).

  • Having a contact form on your web site does not actually necessitate that it's your own web server that also delivers the email; there are plenty of service providers for transactional email. If you go this route you would simply follow the instructions from that service provider for what to include in your SPF record and send your outbound email through them.

To address the more general question:
If you are hiding your servers behind a proxy solution, as described in your question, you will indeed ruin that by publishing the addresses of your servers or even just making outbound connections to untrusted parties.

1
  • Both points are valid but I find the first one simpler. Although there's no option to whitelist an IP in a legacy free edition of Google Apps, there's a way through creating filter(s) to instruct Google Apps NOT to mark messages from certain senders as spam no matter what. So, as you said, since I'm only using my server to send emails to myself (even from root, fail2ban, www-data, etc.) this solution will do the trick. Of course those emails won't pass SPF, DKIM, and DMARC tests, but this solution, as a workaround, it is good enough. Thank you very much Lindqvist.
    – Vila
    May 14, 2016 at 2:15
0

I would like to see the code you're using on your contact form that sends the email. A lot of people use the "From" address of the person filling out the email.

When that happens, you open yourself up to a complete nightmare scenario when using Google. If the person sending the email has DMARC turned on. You're SPF might pass (but it won't be aligned).

You can read about this scenario here: DMARC and the Contact Us Form

The article recommends a workaround - but a more clever way I think would be to set the "reply-to" as the email address of the person filling out the contact us form.

If you send using your email address as the From and To and you authenticate to google, you are essentially emailing yourself and I think this skips authentication checks.

1
  • 1
    I've learned that lesson very long time ago. In the contact form I never put the visitor's email as FROM address, because the visitor in reality never sends that email, but the server, specifically the PHPmailer. The FROM address is always a server's custom email [email protected]. (server sends an email to itself). I put the visitor's address in REPLY-TO. So when the email arrives I can press the reply button in Google Apps and reply directly to the visitor, not to the server's custom email.
    – Vila
    May 14, 2016 at 19:58
0

I believe I found the most appropriate solution given all the caveats and constrains in this given scenario.

Lindqvist's solutions were fine but if you whitelist your own server on the recipient side (in Google Apps, not through SPF) and at the same time you set DMARC policy with p=reject the emails your server is sending to you will be rejected no matter the whitelisting with filters in Google Apps.

Also if you setup your contact form with a third party transnational email provider like Formspree you're still not good to go because if you DMARC policy is set to p=reject all those other emails that the server is sending to you (not through the contact form), but on reebot, fail2ban restart, etc. from root, www-data, fail2ban and other server users, they will be all rejected.

The solution is to setup a DKIM on your server so at least one of the conditions will be fulfilled. The emails from your server will still softfail on SPF (you don't have your server's IP there) but they will pass on DKIM and that's enough for DMARC to pass.

0

The TXT SPF record has to specify the IP of servers authorized to send mail on behalf of a given domain. The obvious solution is to use a different server to send email, not your web server.

The easiest way to do this is to use an external SMTP provider - in the past I've used AuthSMTP, but I'm sure there are many available.

In this scenario, if you have a contact form and it's emailing you and the submitter, your server creates the email but sends it using SMTP with your external provider. The TXT SPF record authorizes sending on behalf of your domain. The MX record pointing at Google Apps means email replies do not hit your server.

1
  • Another great approach. SendGrid is very popular and reliable option and it has a free plan.
    – Vila
    May 21, 2016 at 13:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .