Welcome to the Cloudflare Community.
Cloudflare doesn’t provide outbound email services. You will need to configure your email according to your provider’s instructions.
The following is the Gmail guide. Other providers may require different steps.
Ok, got it, so, what I suppose to do with the Cloudflare email provided, I mean, can I use it to set up maybe in Gmail or another one? if so, where is the password of that custom address?
Cloudflare doesn’t provide email. Are you referring to Cloudflare Email Routing? That is simply a forwarding service. If you had an existing mailbox at
[email protected] that you wanted to use with your new
example.com domain, you could create a Cloudflare email route to forward mail for
[email protected] to
There is no password for it beacuse there is no Cloudflare mailbox or email account. It is just an email forwarding service. This is why you need to use another provider to send email from that address.
If you configure your email service to send as your domain, you can. This was already covered. In the linked Google article in my first reply.
Using the set up like mentioned in the above link, you can send from your Gmail (e.g.
[email protected]), where it will still appear to other people’s mail client as if it was sent from (e.g.
Taking the set up from that link, or any of the other community provided examples and tutorials, e.g. Solved: How-To Use Gmail SMTP to Send FROM an Email Address which uses Cloudflare Email Routing
One thing to note, which all the other guides fail to mention is:
Google will still expose your
[email protected], as the SMTP MAIL FROM / Envelope From / Return-Path.
Google will send and say to other mail servers: “Hello, I’m <
→ Since Google still does this kind of initial presentation with your
@gmail.com address, and not
@mywebsite.net as in your example, both @jwds1978 's message in How-To Use Gmail SMTP to Send FROM an Email Address which uses Cloudflare Email Routing thread by @denvergeeks, and @i40west 's message in Outgoing Email from Gmail with Custom Domain, and likely other threads/posts too, is incorrect.
→ READ: Adding
include:_spf.google.com to your SPF is useless with this kind of set up, as Google does not present your message with an SMTP MAIL FROM address within your own domain.
You cannot get Google to DKIM sign your messages under your own domain either, when you are using this “Send as” trick with a free
Given all the above, you will therefore not have any proper authentication for messages you send out this way.
You can have as many DKIM passes and SPF passes in the chain of your messages, but due to #2 and #3 above, you will NEVER get the alignment towards your own domain, as DMARC requires.
As such, you will NEVER be able to pass DMARC with that kind of “trick” of using Google to send through your free
[email protected] using a custom domain.
Can that kind of “trick” be recommended? I would personally declare hit and miss, with the expectations of any (successful) deliveries this way.
For business use I would declare it a miss, especially when considering how inexpensively one can obtain an actual mailbox that is capable of DKIM signing.
If it is just for a hobby or learning project where reliability of email delivery is not critical, I’d still land it in maybe territory.
In the age DMARC, email forwarding is a mostly lost cause in all but certain very specific use cases. As a general purpose practice, the headache it creates exceeds any perceived financial savings.
I would however declare miss in either case.
If it does actually appear successful, I’d consider that extreme luck.
Not only regarding DMARC, but generally it seems providers are leaning more and more towards (strict) alignment requirements - even if no DMARC is not (directly) involved.
Both Deutsche Telekom (
t-mobile.de, etc.), and 1&1 (
/Mail.com`) have publicly discussed that they were leaning towards more strict settings in regards to DKIM as well as alignment.
Deutsche Telekom in a way that could appear that they are requiring DMARC’s strict alignment between header From: and SMTP MAIL FROM.
Gmail does actually seem to show signs that they appear to lean towards requiring proper alignment, too. The (proper) alignment thing would be the very first thing I would investigate, if you see the 550-5.7.26 error from Gmail.
Major point with the above message was to make sure that people are aware that the potential consequences … and that by taking this route, things are likely not going to be as expected.
I personally believe it is only a matter of (likely, very limited) time, before this Gmail “Send as” trick (and any similar ones) will be a 100% miss, where you cannot have a proper (strict) DKIM/SPF alignment.
Those are all issues that come from being in the age of DMARC.
Anyone who is quarantining on the basis of no alignment between RFC 5321 and RFC 5322 senders when there is valid DKIM needs to rethink that strategy or suffer the economic repercussions as any customers with options exercise them by fleeing such incompetence. Providers also should respect a domains published DMARC policy when it comes to making decisions based on strict versus relaxed alignment or face deserved backlash.
@dileandrog, were you able to configure the Send As option in your Gmail account?
Personally, I’m a 100% +1 on this.
However, the way I see it, it sounds like some of those companies claim, that while the thing they do look very similarly to DMARC, that it isn’t really depending on DMARC to be activated for your domain.
In other wards, to my understanding, some providers appear to say they are going to require alignment, even if you do not have a _dmarc record set.
I would also say, when I saw indicators in that direction between the two, I found it to be a bit overly strict.
As long as we have RFC 5322 From with proper alignment to (one of) the actual valid DKIM, RFC 5321 MailFrom shouldn’t really mean that much, any more.
Yes, I managed to setup the domain with my Google account, thanks for the support guys.
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.