Not able to recieve mails trough cloudflare

Problem is i dont know the webserver IP adress to make DNS records i am able to send emails tough,

i have a domain and mail hosting with a shitty company and am using Cloudflare for the domain, How do i setup proper DNS records for the email server if i dont know the IP also do i need to make ‘mail .mydomain .com’ myself ? as a subdomein any help is much appriciated thanks in advance ,
this are my current records,:

A     www                (IP OF WEBSERVER )   Proxied      AUTO 
A    mydomain.com        (IP OF WEBSERVER )   Proxied      AUTO 
MX mydomain.com          mail.mydomain.com    DNS ONLY     AUTO 
TXT mydomain.com         googlesiteverficatio DNS Only      1hr

Problem is i dont know the mailserver IP not the webserver*

You can try to ask the “shitty company” about the information, as they know it, and will be able to provide it to you.

For anyone here (or anywhere else, that isn’t the “shitty company”) to (try to) assist you, it would require more information, such as for example:

  1. Share your domain name

  2. Share the name of the “shitty company”.

As we do not (yet) know enough about your infrastructure/ setup, it will be hard, not to mention likely impossible for us to assist you, at least, without the above information.

Edit your current MX record to become this:

Type: MX
Name: @
Mail server: smtp.rzone.de.
TTL: Preferably set it to something like 12-24 hours, as MX records/mail related likely do not change that often.
Priority: 5

1 Like

Nice that did the trick in order to setup a SPF record and DMARC policy to avoid spoofing can i just use the Cloudflare wizard that automaticly adds the records or do i need to do some manuall stuff?

The wizards can get things started for you and may be sufficient. You well need to understand how the generated records work.

This Cloudflare article is a good starting point. What is a DNS SPF record? Be sure to follow the Learn more links at the end.

1 Like

The Cloudflare wizard is very simple, and the wizard is asking you a couple of questions in order to generate the desired record based on the options you select / input you provide, and once done, you can hit a Submit button and it’ll automatically add the final record for you.

There are however a couple of things I’d like to change with them, if I had the option to do so.

Anyway, since you did explicitly say “to avoid spoofing”, - do you actually have any desired policy in mind?

  1. Anyone trying to claim they are my domain should get immolated (e.g. rejected and never presented to the final recipient, e.g. similar to how a letter would be returned to sender if the destination address is invalid).
    → DMARC with a p=reject (eventually explicitly set sp=reject), and a SPF ending in “-all”.
  2. Anyone trying to claim they are my domain should get the message delivered, but just go to spam.
    → DMARC with a p=quarantine (most often sp=quarantine / sp=reject), and a SPF ending in “-all”.
  3. BUT, my provider is NOT DKIM signing my messages with a valid author signature matching my From: header.
    → DMARC (if added) should NOT be anything else than p=none. SPF still ending in “-all”.

But DMARC and SPF aren’t the only two things we should be looking at.

  • Are you only sending messages through Strato?
    • Yes
    • → Add a TXT record, with this information:
      Type: TXT
      Name: @
      Content: v=spf1 include:_spf.strato.com -all
      TTL: Preferably set it to something like 12-24 hours, as mail related records likely do not change that often.
    • No
    • → We would need to figure out what other providers you are using, so we can eventually include them too, if they are really necessary for your SPF record.

A lot of people out there misunderstand things such as SPF and DMARC.

According to the list above, and especially #3, I would suggest that you first look in to whether Strato (or any other provider you may use, if you also use other ones) is actually properly DKIM signing your messages, before adding any DMARC record.

Stuff like that can be tested with a couple of online “email testers” you can find Googling around, but the quality will vary (a lot) from site to site.

If you are open minded to sending emails away to third parties in order to test and determine, one destination you can try would be:

[email protected]

Within some seconds to a couple of minutes, you will receive a message back, and let’s assume that you sent the message from an email address called “[email protected]”, then you would be looking for something like this:

==========================================================
Summary of Results
==========================================================
SPF check:          pass
DKIM check:         pass
SpamAssassin check: ham
----------------------------------------------------------
SPF check details:
----------------------------------------------------------
Result:         pass
ID(s) verified: [email protected]
----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result:         pass (matches From: [email protected])
ID(s) verified: header.d=example.com
----------------------------------------------------------
SpamAssassin check details:
----------------------------------------------------------
SpamAssassin v3.4.0 (2014-02-07)

Result:         ham (-2.0 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
-1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                            [score: 0.0000]
[...]
-0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
-0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from author's
                            domain
-0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily valid

As you see all the data here is a match, e.g. in SPF we got [email protected], in DKIM we got both pass (matches From: [email protected]), and header.d=example.com, it literally all matches your From: address and there is proper alignment due to “@example.com” / “d=example.com” being identical (and passing).

If you see all this, I would say you are ready to add a DMARC record like the one I explained in #1 above, and together with the SPF record mentioned above, I’d would then say:

Add a TXT record, with this information:
Type: TXT
Name: _dmarc
Content: "v=DMARC1; p=reject; sp=reject;
TTL: Preferably set it to something like 12-24 hours, as mail related records likely do not change that often.

However, if you have 10 different providers sending mail on your behalf, you would have to conduct some testing like the above through all of your 10 different providers, and verify first.

NOTE → If just 1 of the 10 different providers is not doing exactly as expected, and you are adding that DMARC p=reject/sp=reject record, messages through that one provider will likely be rejected and returned to it’s sender, as mentioned in #1 above.

DMARC also allows for reporting (rua/ruf tags), the many of the larger ones like Google, Yahoo and so are sending aggregated (statistical like) reports to the rua tag, however, the majority of the larger ones ignore the ruf tag, that would otherwise send one single report per message failing authentication

The rua reports (and of course, also the limited ruf ones) can be used to determine whether you are ready to jump from various levels (none → quarantine → reject), if you’re worried about that.

But if you already know enough about your infrastructure / set up (e.g. like the “Are you only sending messages through Strato?” question above), that will definitely help a lot to determine what you are ready to do, or go for, right now.

What you can and can’t do right now, will always depend on the various variables available, and if any of those variables are actually changing, even just slightly, it can mean a lot.

1 Like

Or, @user7212, if you are not open minded to that kind of thing, I have opened this tagged address specifically for you, so you can send a test message to (and so we can dig deeper in to it):

[email protected]

1 Like

What would be the best setup what do you recoomend?

I really doubt anyone is gonna try and spoof my domain name to send emails, maybe i want to setup the records so the possiblity of my emails getting into the spam folder, so that emails land in the inbox instead,

what would you reconn?

==========================================================
Summary of Results
==========================================================
SPF check:          pass
"iprev" check:      pass
DKIM check:         none
Details:
==========================================================

HELO hostname:  mo4-p00-ob.smtp.rzone.de
Source IP:      85.215.255.21
mail-from:      [email protected]

SPF check details:
----------------------------------------------------------
Result:         pass
ID(s) verified: [email protected]

DNS record(s):
    zielaan.com. 300 IN TXT "v=spf1 include:_spf.strato.com -all"
    zielaan.com. 300 IN TXT "google-site-verification=SCDcEaketj0eCZBY2sf3qTN8qkMgobqaI7ugccArjIM"
    _spf.strato.com. 300 IN TXT "v=spf1 ip4:81.169.146.128/25 ip4:85.215.255.0/24 ip6:2a01:238:20a:202::0/64 ip6:2a01:238:400::0/48 ip4:81.169.144.153 ip6:2a01:238:20a:202:50ff::153 -all"
iprev" check details:
----------------------------------------------------------
Result:         pass (matches mo4-p00-ob.smtp.rzone.de)
ID(s) verified: policy.iprev=85.215.255.21

DNS record(s):
    21.255.215.85.in-addr.arpa. 300 IN PTR mo4-p00-ob.smtp.rzone.de.
    mo4-p00-ob.smtp.rzone.de. 300 IN A 81.169.146.163
    mo4-p00-ob.smtp.rzone.de. 300 IN A 81.169.146.216
    mo4-p00-ob.smtp.rzone.de. 300 IN A 81.169.146.217
    mo4-p00-ob.smtp.rzone.de. 300 IN A 81.169.146.218
    mo4-p00-ob.smtp.rzone.de. 300 IN A 81.169.146.219
    mo4-p00-ob.smtp.rzone.de. 300 IN A 81.169.146.220
    mo4-p00-ob.smtp.rzone.de. 300 IN A 81.169.146.221
    mo4-p00-ob.smtp.rzone.de. 300 IN A 85.215.255.20
    mo4-p00-ob.smtp.rzone.de. 300 IN A 85.215.255.21
    mo4-p00-ob.smtp.rzone.de. 300 IN A 85.215.255.22
    mo4-p00-ob.smtp.rzone.de. 300 IN A 85.215.255.23
    mo4-p00-ob.smtp.rzone.de. 300 IN A 85.215.255.24
    mo4-p00-ob.smtp.rzone.de. 300 IN A 85.215.255.25
    mo4-p00-ob.smtp.rzone.de. 300 IN A 85.215.255.26
    mo4-p00-ob.smtp.rzone.de. 300 IN A 85.215.255.27
    mo4-p00-ob.smtp.rzone.de. 300 IN A 85.215.255.28
    mo4-p00-ob.smtp.rzone.de. 300 IN A 85.215.255.29
    mo4-p00-ob.smtp.rzone.de. 300 IN A 81.169.146.160
    mo4-p00-ob.smtp.rzone.de. 300 IN A 81.169.146.161
    mo4-p00-ob.smtp.rzone.de. 300 IN A 81.169.146.162

DKIM check details:
----------------------------------------------------------
Result:         none (message not signed)
ID(s) verified: 

NOTE: DKIM checking has been performed based on the latest DKIM specs
(RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for
older versions.  If you are using Port25's PowerMTA, you need to use
version 3.2r11 or later to get a compatible version of DKIM.

==============================================================
Explanation of the possible results (based on RFCs 7601, 7208)
DKIM Results
============

none:  The message was not signed.

Does DNSSEC need to be enabled in my Cloudflare panel to? excuse my ignorance

It is (and has been) very common with e.g. throw away domains to deliver spam, so from time to time, it gives very give good / effective results with filtering recently registered domains away, and since your domain is les than 30 days old (apparently registered on 2023-01-17, and first spotted on 2023-01-19), that caused the rejection.

Usually, I would expect email deliveries to be a miracle if they succeed, for at least the first ~ 45 - 60 days of a domain’s registration, alone based on it’s age.

Jan 23 14:34:19 mail postfix/smtpd[1281579]: NOQUEUE: reject: RCPT from mo4-p00-ob.smtp.rzone.de[81.169.146.217]: 550 5.7.1 Service unavailable; Sender address [[email protected]] blocked using fresh30.spameatingmonkey.net; Domain first seen 2023-01-19, see https://spameatingmonkey.com/lookup/zielaan.com; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mo4-p00-ob.smtp.rzone.de>
Jan 23 14:42:58 mail postfix/smtpd[1281772]: NOQUEUE: reject: RCPT from mo4-p00-ob.smtp.rzone.de[81.169.146.216]: 550 5.7.1 Service unavailable; Sender address [[email protected]] blocked using fresh30.spameatingmonkey.net; Domain first seen 2023-01-19, see https://spameatingmonkey.com/lookup/zielaan.com; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mo4-p00-ob.smtp.rzone.de>

That’s a bit sad. :cry:

I would (… unfortunately) strongly recommend to either not add a DMARC record, or set it at a maximum of p=none, if you add one.

Are you expecting to be sending from sub-domains, such as e.g. [email protected], [email protected], or something similar to that?

If the answer is NO to this, a DMARC can be set to “p=none; sp=reject;”, so it holds the none (“do nothing”) policy at the parent/base/apex domain, but that e.g. billing and forums (and any other) sub-domains) would have the result of a reject policy.

No, it doesn’t need to be.

DNSSEC is sort of like doing to your DNS what DKIM is would be doing to your email, adding a cryptographically seal, that others can verify the authenticity with.

But they are two different things and not directly related to each other.

It does however not hurt to enable DNSSEC and configure it properly, and wherever possible, it would be something I would actually recommend too.

Configuring “properly” requires assistance from the domain registrar, which in your case, would be Strato. Assistance here could be as simple as having an option through their self service / control panels to do it, however, assuming that there hasn’t been any misunderstanding with this link, it doesn’t sound promising with Strato either:

https://www.reddit.com/r/selfhosted/comments/xltgm8/comment/ipp30td/

Yea the domain is new so i would have to wait a bit? I also noticed i cant move my domain yet cause its tp new

Even though I do thing the most strictest possible way myself, I must admit that I had the same kind of doubt myself, about such attempts for at least the majority of my domains.

But when I was digging deeper (e.g. using DMARC reports), it turned out that there was quite a few attempts every now and then, on several different domains (some of which wasn’t even used for email)…

Nothing you do (DKIM, SPF, DMARC) is ever going to guarantee you a delivery to the inbox, or even prevent you from getting to the spam folder.

But generally, what I see is that the more positive (e.g. the better your set up looks), the better the possibility of getting to the inbox is, - of course, that would always be with some sort of exceptions, such as for example, if you are actually spamming away with junk. :wink:

The very best set up that I can recommend, would be with a perfect DKIM, too, and then going to a DMARC record with p=reject.

(But unfortunately, right now, that isn’t an option, … at least not yet)

You could try to poke Strato, to hear if their outbound mail can sign with DKIM, and which kind of records you would need to set up for that.

If they respond that they cannot DKIM sign outbound messages at this time, you could always try again in a while to ask if there’s something new about it.

All I find with a quick Google is only Strato making suggestions on how to add DKIM records to your DNS; but that thing will be completely irrelevant, when/if their mail server does not the option to (properly) sign the outbound mails.

You saw a source IP of 85.215.255.21, and the two ones you tried to send my way had the source IPs 81.169.146.216 and 81.169.146.217, all of those IP addresses are already covered by include:_spf.strato.com that I provided earlier and that you have already added to your SPF record.

So as said above, if you only use Strato, it seems like you got a perfect SPF record now! :slight_smile:

A lot of block/welcome (f.k.a. black/white) lists is listing domains for the first while of their registration, if that specific thing seems to be the problem, it would be all about waiting.

(I disabled the age check on the test address I provided above, if you wish to try again though, but with the other results provided, it look necessary any more)

ICANN, which sets a lot of rules for the majority of domain names (except country codes like .DK, .NL, …), do not allow domain transfers for the first 60 days following the initial registration, as well as the first 60 days following another registrar transfer.

1 Like

I think i have it setup correctly now i appriciate your help and explanation aswel thank you very much

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.