[1] Do you know of any FREE online tool where I could either create or retrieve the SPF, DKIM, and DMARC records? This would enable me to find and apply those records without having to bother the hosting company;
[2] Yesterday I added a DMARC record to one of my domain names at Cloudflare as follows:
It was accepted but there is an error message as you can see on the attached image. A DMARC online search for the domain in question reported as follows:
2 warnings detected
DMARC record is valid, but your domainâs None/Quarantine policy does not yet protect it against email spoofing and phishing.
DMARC record does not have email address provided by our system in âruaâ tag! If you want the platform to process and visualize aggregate reports, please sign up and let us manage your reports.
Do you have any idea of how to solve this issue?
[3] I noticed there is a fourth record linked to email which is called BIMI (Brand Indicator for Message Identification). I read some information about BIMI but it is not clear in mind how to create that record in order to add it at Cloudflare. My understanding is that BIMI provides a way by which people who receive an email from us can see the logo of our brand or company. I am not sure if this is really necessary because we can insert our logo in the signature below our message associated to our URL address like: https://www.example.com/logo.png. So, our message could be authenticated as genuine if people click on the image as they can see our URL address. However, to achieve this people will need to open our message. Having this in mind, I am wondering if BIMI could ensure our logo is shown âbeforeâ people open our emails.
DKIM has to come from your hosting provider, and itâs not something you can just âfindâ because it will be specific to your domain (you cannot just use a valid record from someone else using the same provider). They will create a key, and their mail server will be configured to sign your outgoing emails. So they have to give you the content of the record, which you can then add in the Cloudflare dashboard.
For SPF you can use the thingy in the Cloudflare dashboard to create it. You need to list the mail servers that are allowed to send mail from your domain. This, too, should come from your email hosting provider, but in this case it should be the same for everyone using that provider so you can probably find it on their website.
DMARC is a policy header; you can create it in the dashboard here, and you donât need your hosting provider for this. If you set rua to reject, that tells other mail systems that they should reject email that fails the other tests. This makes it more difficult for anyone to forge email from you in order to scam people, so having a restrictive DMARC policy, which basically says âonly this source of email from us is legitimate, donât trust it if it comes from anywhere elseâ, can make your real email more trustworthy and more likely to be accepted by providers like Gmail.
The DMARC report email address will receive automated reports from the large providers (Gmail, Yahoo, etc) about how many emails they received from your domain and whether they accepted them. These reports are not designed to be human-readable, so if youâre interested in them itâs best to have some service receive and aggregate them on your behalf. The message you pasted in is them trying to get you to pay them (presumably) for that service.
The BIMI thing will only work if you have all of the above set up. And some providers, notably Gmail, will only honor it if you have registered your logo as a trademark. So leave that for later.
Wow! I read your comments carefully and will highlight some issues in order to wrap the topic up. My apologies for the length of my comments but I would like to be comprehensive and clear.
BIMI: I agree with the fact that BIMI is a sort of ADDON that could be implemented at a later stage. Having said that, I assume an issue to be taken into consideration in relation to BIMI is the level of security and corporate image that might be required by our project or business. For instance, it is not the same thing selling pencil sharpeners online than providing health consultation online.
DMARC: Your comments hit the head of the nail. With regard to Aggregate and Failure reports, I believe what we can do at the time of generating a DMARC record is to refrain from writing any email address in the lines concerning reports. If applicable, I assume we could come back later and update the DMARC record in case we are happy to cope with the burden of reports. Apart from the Email Record Creator in the Cloudflare dashboard, a short while ago I found a DMARC generation wizard at SimpleDNS that I found quite user-friendly: Simple DNS Plus - DMARC record wizard
In relation to your comments about the screenshot I posted, after doing a search at SimpleDNS for the same domain name, I have an idea why the error message was generated. SimpleDNS provided the following DMARC record:
v=DMARC1; p=none; adkim=s; aspf=s;
Once I updated the DMARC record as quoted above the error message instantly disappeared. This was so because I chose âStrict Modeâ for DKIM and SPF as alignment. I believe the DMARC record we read on the screenshot should have been set at a âRelaxed Modeâ. The only catch to bear in mind is that in âStrict Modeâ an exact match is required between the domain name part of the âFromâ e-mail address and the signing domain (DKIM) / sender address domain (SPF). Simply put, the DMARC record on the screenshot can accept sub-domains. I chose the strict mode because at this stage I have no sub-domains to deal with. Therefore, any email sent from my domain name will be accepted at the other end only if they are written as â[email protected]â. An email like â[email protected]â will be rejected by the server of the receiver. Of course, if I add subdomains in the future I will have to update the DMARC record in case the sub-domain is given the authority to send and receive emails.
DKIM: The only point I would put into question regarding what you said about DKIM is that I have just found a few sites that offer free wizards to generate DKIM records. The one I liked is from EASYDMARC at: DKIM Record Generator - DKIM tools | EasyDMARC
What I cannot really understand is why EASYDMARC also generates the public and private keys for us. How could they offer us a supposedly «private key» if anyone can get it online by just writing in the domain box the letters of any domain name. EASYDMARC also has a useful tool to check all email records in one go: Domain Scanner - DMARC, SPF, DKIM tools | EasyDMARC
CONCLUSION: I find the topic of email records very relevant especially nowadays because our corporate clients just need to do a scanning online of our email records to get an idea if we are truly on track with regard to our email security policy. Just a few weeks ago, I had no idea about these records and even ignored they actually existed. Now it might become almost compulsory to put a DMARC policy in place which we could even be quoted as part of our marketing strategy.
ADDENDUM (List of Wizards Online to Generate and Check Email Records)
Apart from the email record generators provided by Cloudflare dashboard, today I discovered the ones quoted below that also seem to do the job. Please note that EASYMARC and DMARCLY offer tools to generate and check all of them (SPF, DKIM and DMARC). DNS Checker is also an impressive site: https://dnschecker.org
Well, you need to take that private key and install it on the mail server. Or rather, the administrator of the mail server needs to do that; if you are using a hosting provider, thatâs not you. So that exists for someone to use who is actually running the mail server and wants to generate the keys that way. Thereâs nothing you can do with those keys because youâre not running the mail server.
So if someone does run a mail server, but not for you, and they want to generate a DKIM key to try to pretend to be you, they can install the key on their mail server and try to send mail as youâbut they donât control your DNS, so their signatures will never verify. The idea is that you need to control every part of the âstackâ in order for it to work. For example, your current email provider controls the mail server and can generate a key and set it up to sign your emails, but even then, YOU control your DNS, so you can take that power away from them at any time, if you wanted to go elsewhere.
Very well written i40west. Please be ensured you donât waste your time with me as I read your comments word by word and fully understood your line of reasoning. Now I would like to share something with you. I have a few domain names parked at Cloudflare and their Roundcube webmail platform were not functioning at all (i.e. they never reached their destination and were being sent back as undelivered messages assumingly for being treated as SPAM). What I was doing was opening tickets with my hosting company to raise this issue and they were providing me with the email records needed to solve the problem.
Luckily, since I started creating DKIM records at the sites mentioned above that provide DKIM generator wizards, ALL mails started working smoothly, flawlessly, and happy. As an aside, I have taken the liberty to use the adjective âhappyâ to stress the joy I felt when I saw the emails working without needing to contact my hosting company. Besides, I have done tests and Gmail is accepting them without labelling them as SPAM. Conversely, I have sent emails in the opposite direction and Roundcube have been receiving emails without any incidents.
I have mentioned all this to you because it is in some way contradicting what you said in the sense that we cannot create DKIM at our end. Well, even if I am far from being knowledgeable in webhosting matters, I am tempted to infer this might be happening this way because the hosting company has likely configured the server â perhaps inadvertently - in such a way that it is enabling me to create DKIM records without their assistance. This case scenario would not necessarily challenge your opinion if we take into account the fact that all my domain names are allocated in the same parcel of their server. I suppose it is in cases like this that owing a dedicated IP address may be useful to avoid conflicts within the server. Strictly speaking, I donât see the point of paying for a dedicated IP address unless our business turnover and size of database have increased significantly in order to improve functionality.
Anyway, even if anyone in the planet could create DKIM online as they wish, at the end of the day they wonât be able to make any changes as they do not have access to my account at Cloudflare. Furthermore, neither they could add those records to another domain name of their own because I understand DKIM records are only linked to the domain name used to generate them.
ADDENDUM: By the way, to wrap things up I would like to share with you that some webhosting companies have asked me to have access to my Cloudflare account to solve issues I have queried with them. I am reluctant to do so especially because I have many domain names. It is not a mere issue of distrust, but a security safeguard as I donât know who is actually going to access my account. Unfortunately, hosting companies only provide us with their general email support without specifying the agent who would actually work on our Cloudflare account. I would have behaved differently if such a request is made on a one-off basis by an agent from Cloudflare who contacts me with a genuine Cloudflare email address in order to solve a problem. Of course, this is more likely to happen once I upgrade my Cloudflare account to a payable plan.
The abc320.hostguru.com segment in bold characters of that record refers to their ip4 address which is «122.18.45.938». However, I noticed that SPF wizards online only worked if I wrote their IP in numbers. If I write abc320.hostguru.com then the SPF is reported as INVALID.
Besides, today I read in some sites I was glancing over that the â+aâ and â+mxâ in italics are not indispensable and could be removed, but cause no harm if we leave them. Likewise, most SPF only report a unique âaâ instead of two as my hosting provider have suggested.
As I understand it, I think we should quote the â+aâ and â+mxâ as they have done to match the domain name. According to what I read somewhere, things should happen this way if we have A and MX records resolving to the senderâs email address, as per my case**.** In a nutshell, SPF wizards online have reported the SPF record in the following way:
PS: As a matter of courtesy, please note I have written dummy letters and numbers regarding ip4 as it is not my intention to damage the reputation of my webhosting provider.
When you find yourself in need of example IPs in the future, you can use the reserved values specified in RFC 5737. Similar reservations exist for example domain names in RFC 2606.
A DKIM signature would require that the private key you generated is installed on the mail server and set up to be used to sign outgoing emails with it. If you never provided the key to them, thatâs not possible.
Send an email from one of these domains to another account that has DKIM verification, and look at the headers to see what happened. What youâll almost certainly find is that the mail has no DKIM signature at all (your DKIM key is not being used in any meaningful way) but the message passed SPF. Passing SPF but not DKIM is still good enough for Gmail. Having both things set up but only passing one is enough to get your mail into Gmail.
This sounds silly, almost like it makes DKIM irrelevant, but you didnât actually set up DMARC for security; you set it up to get Gmail and Microsoft to accept your email, so just roll with it.
Thank you for your useful comments as I am totally new to this stuff of email records.
Today I discovered that the server of my hosting company (running PLESK) actually provides the names and TXTs to be added up at Cloudflare as DKIM records. I have attached a screenshot of the exact words it contains (only changed the domain name for EXAMPLE.COM as I am preparing a guideline for my own use to be applied later for different domain names).
As you can appreciate, they provide us with two types of DKIM records to be added. Names are written in red and TXT in blue. I have no idea what the second entry with the text âo=-â is all about. Also, I have checked some forums and realized people do not add the DOT at the end of the words â_domainkey.example.com.â They just write: _domainkey.example.com (without the dot at the end).
Anyway, as you see they do not ask us to add a private key in order to enable DKIM for spam protection of outgoing email messages.
COMMENT: I am wondering if the private domain key was automatically generated by the server at the time of creating the Letâs Encrypt SSL/TLS certificate. It is the only explanation I can figure out taking into account the names start with the words _domainkey
Apart from that, I went to the section of SSL/TLS certificate of the server and found what you see on the second attached screenshot. Perhaps it is here that I should upload the private key, but it doesnât look like because the private key is provided as TXT and not as a certificate (.crt file).
QUESTION: By the way, where can I find an email that has DKIM verification to ensure that DKIM is actually configured for my domain names? Now I am confused because when I do scanning tests at EASYDMARC (Domain Scanner - DMARC, SPF, DKIM tools | EasyDMARC) the DKIM records have been successfully treated as VALID. Just now realized that EASY DMARC has an email verification tool at Investigate Email Issues | EasyDMARC. I suppose here I will be able to identify how secured are the email accounts I manage to configure which in practice answers the question I have just asked.
ADDENDUM: I have included a third screenshot to give you an idea of the LETâS ENCRYPT SSL/TLS configuration as it is displayed in all the domain names I have hosted in the server. I do nothing about SSL/TLS certificates but I suppose a private domain key has been needed to create them. This is why I think the DKIM data provided by the server as above-mentioned was generated based on the private key already saved internally in the server.
Thank you. In that case I think I could disregard the second entry because when the hosting company has given me the DKIM text (before I learned where to find it by myself) they never mentioned that second entry.
On the above, it sounds like you may be confusing strict/relaxed alignment, with the actual DMARC policy:
That one, because of itâs âp=noneâ, will NOT be asking others to reject messages that are pretending (but not validating) to be from you.
You would have to change to âp=rejectâ for that.
Regarding your âemail security policyâ, I have a couple of things to add in:
Knowing, or even remembering the correct commands to use to generate key pairs can be tricky for some, and there, you could perhaps see these as a âquickâ tool you easily could access, and then just copy-paste the actual stuff in to your mail server.
I would personally say you have a pretty weak (email) security policy, if you can accept to retrieve private keys generated by third parties like this, and then choose to use it at some a different party.
On Google, to mention one example, they generate the key pair for you within their administration panel, and give you the public key to put in to your DNS. You wonât see the private key there.
Quite much in an identical way, to the second latest screenshot, âMail Settings for example.comâ, that you posted.
What you can attribute the magic success to, is likely the SPF that you also touched, that was then passing properly (which it likely didnât do before).
All the DKIM records you created on these wizards are literally useless, unless some mail server administrator is adding them to their mail servers, and start using them.
Youâre not willing to let your web hosting companies help you setting up your domain, ⊠but you are actually willing to accept âprivate keysâ from third parties like this?
Rather safe, than sorry?:
Try to imagine the scenario, that my âDKIM generator wizardâ web site that you used, were generating the âprivate keyâ server side.
Question is now, âŠ
⊠Did I only just display the keys to you?
⊠Did I also save a copy of the âprivate keyâ on my server(s)?
If weâre pretending it would actually be #2, you have just spoon-feeded me with a lot of details, where you did for example enter the DKIM selector âspaghettiâ:
Now, I can be checking every now and then, whether the DNS record of spaghetti._domainkey.example.com is existing, and if, does it actually match the public key I were showing to you?
Once I detect that the _domainkey record is matching what I provided you, I could in theory be flooding away with messages, that appear to be legitimately sent from your domain name.
Absolutely nothing of the stuff above is supposed to indicate that any of the mentioned tools cannot be trusted, or otherwise to be implying anything (negative) about them. â Iâm only just giving you something to consider, for your (email) security policy, as it sounds a bit strict in some situations, but possibly a bit weak in other situations.
Thank you very much DarkDevil. I have gone quickly through your message but promise to read it later again at a slower pace to figure out the next steps to be undertaken to improve security. Yes, you are right. As I am a neopohyte in these matters, I was delighted to see that Gmail and other email providers were accepting my messages without either blocking or labeling them as SPAM. Now I realise things are not so straightforward as I initially thought. Anyway, posts like yours explain why Cloudflare has no competitors all over the world. It has been the only community forum I have found valuable information about domain configuration, mail, and webhosting as a whole.
In the meantime, my only remark is that even if I get a private key for DKIM as the one we can obtain online at EASYDEMARC (DKIM Record Generator - DKIM tools | EasyDMARC), I have not found any option at my hosting company that could enable me to insert such a private key in order to create the DKIM text to be uploaded at Cloudflare. They just provide us with the DKIM text âready to useâ which supposedly was automatically generated. The latter would imply that their server (PLESK) would have instantly created an internal private key immediately after we add a new domain name. I cannot find another rationale to explain the way they operate as far as âprivate key for KDIM generationâ is concerned.
Needless to say, I fully agree, it sounds a weak security policy to accept private keys generated by third parties that could be easily retrieved by anyone, and then use such a private key in a totally different IT platform. It is just a matter of common sense, the less common of senses. On this matter, @i40west said something logical in the sense that those who could retrieve domain private keys could not make use of them as they do not have access to our server.
I am going to raise this issue with my hosting company as it seems there is something nebulous about all this. However, I am wondering if some webhosting companies operate in that way in order to avoid wasting time and resources in technical support because it is likely most users would not have any idea how to manage a private domain key even if it could be retrieved in our webhosting account. This is only a guess. Thank you again!
This one should actually be considered good for security, i.e., the sanest option possible.
A private key that is travelling around from here to there, I would generally consider compromised already.
A little bit of digging, hereâs the potential âpathsâ that your private key could take with the scenarios you have demonstrated, and the Google one that I explained above:
SparkPost seems to be generating the keys locally in your browser. I see no requests to any servers during the actual generation.
Your PC - Key generated locally in browser (can slow down your browser, e.g. on old/slower machines)
(The actual path between you and your hosting provider, while uploading the key to them)
Your hosting provider
EASYDMARC seems to be generating the keys on their servers, and then distribute it to your browser. Their servers can likely generate it much faster than e.g. your browser, especially if youâre running on a machine with limited resources.
EASYDMARC, as they generate it on their servers, and send it to your browser
(The actual path between EASYDMARC and your PC, while retrieving the key from them)
Your PC
(The actual path between you and your hosting provider, while uploading the key to them)
Your hosting provider
On a Google/Gmail/Workspace/[whatever they call it today, tommorow, or whenever] that I have set up DKIM on, Google generated the private keys for me, as I explained above, and I were only being shown the public key, that I should add on the {selector}._domainkey.example.comTXT record, but I NEVER saw the private key.
Google, as they generated the private key.
Your hosting provider('s PLESK), according screenshot you were showing with âMail Settings for example.comâ above, did the exact same as Google/Gmail.
Your hosting provider, as they generated the private key.
The fewer signs, and the shorter path, the better it will be, as it should hopefully reduce the likelihood of the private keys being exposed.
Several things are also way beyond your control, when the traffic travels through the public Internet (indicated with ).
That one is misunderstood. I donât actually need access to your server, to use your private keys.
I would just need any mail server, where it is possible to install the private key.
I can set up a mail server somewhere on a very inexpensive VPS, that signs outbound messages with your private key, and pretend to be from your domain.
It would obviously require that I have your private key, ⊠but the key point is:
How would you actually guarantee itâs safety, when it is actually travelling around the public Internet?
As the private key on the hosting provider is generated by them, and not by you, it hopefully hasnât travelled that much around, which I would say to.
I believe the criticism that it looks like I could have, should more be directed as criticism towards PLESK, than your hosting provider.
Iâm apparently not alone about that part:
Not only that, but also the phrasing from your screenshot âUse DKIM spam protection system to sign outgoing email messagesâ is a bit odd.
DKIM is NOT actually a âspam protection systemâ in the way you could possibly understand it to be, based on that phrase, which actually confuses many, but a way for you (well: your messages) to authenticate with your domain.