Finally living spam-free. This is basically only possible with a professional protection system that analyses the mails and uses all available options to prevent the abuse of your own domain for sending spam.
This can be done with a spam protection gateway, for example.
Even today there are still numerous providers who do not protect the emails of their customer domains. Usually only the MX record of a domain is put on the server so that the customer can receive emails via the domain.
There are some dangers involved. Because the eMialsystem can be manipulated very easily. It is possible to forge the sender's name easily. You can send an e-mail under any domain name. If the domain owner has not protected himself against it, someone else can send emails in his name. In the worst case, the replies will be sent back to the domain owner.
It doesn't have to be. With just a few clicks, the domain is well protected from such things.
SPF Record
The Sender Policy Framework (SPF) is one of the methods used to protect the sender domain against forgery. In the SPF entry of the name server, the e-mail servers that are allowed to send e-mails from this domain are authenticated.
At webhosting.de for example these mail servers would be the ones entered in the TXT entry:
"v=spf1 mx a:spamschutz.webhoster.de a:spamschutz2.webhoster.de a:spamschutz3.webhoster.de a:spamschutz4.webhoster.de -all"
Herewith it is allowed that the A Records of the servers spamschutz.webhoster.de etc. as well as the MX Record of the domain itself are authorized for the dispatch.
Important: An SPF entry is identified by RFC 7208 has become obsolete. The SPF entry is simply defined as a TXT entry in the domain.
With the -all we prohibit the dispatch via other servers.
A provider who checks the SPF record will not accept the email or mark it as spam.
DKIM record
In order to check the authenticity of the e-mail sender, an identification protocol such as DomainKeys required by Yahoo.
The e-mail itself is provided with a digital signature, which the recipient's e-mail server can verify with a public key available in the DNS.
There are now several ways to define the whole thing. This can either be done on the server. For Plesk you will need to install a script that stores the key locally or use the Plesk DNS server.
If the control panel does not offer any option, you can simply use an anti-spam gateway. Here you can also directly add a signature to all authenticated outgoing e-mails.
In case of ISTORE of the provider webhoster.com it goes like this:
In the Plesk menu simply select the appropriate domain and click on ISTORE on the right.
Select the appropriate domain for access to the iStore.
Now check the status whether the domain is protected by the spam protection gateway.
The status Protected confirms that the domain is available in the spam protection gateway. Now you can click right on Manage in Spam Filter Panel and manage the domain in the main menu.
In the main menu of the anti-spam gateway, you can now simply select the Outgoing at DKIM to start the generator for the entry.
With the DKIM entry, the key is stored in the spam protection gateway and the public key is displayed, which is then simply added to the name server as a TXT entry.
If the SPF entry is not yet set, it can also be displayed.
Generate DKIM
As selector we use here default. It doesn't really matter. Default is used by most systems. In case of a change of the system not everything has to be adjusted.
The public key is now displayed and can easily be added to the name server.
Set DNS entry
Important is the host entry default._domainkey.webhosting.de with the value generated by the system. The TTL time can be set as desired. Usually nothing changes here so quickly. 400 seconds are ok.
DKIM Testing with mxtoolbox
The entry that is now set can be easily deleted with mxtoolbox check. The program immediately shows whether everything is in order.
As we can see, the DKIM entry is now present. However, it is shown that there is no DMARC entry yet. Of course we want to change this and set a DMARC entry.
Add DMARC entry
A third protection mechanism for e-mails. The Domain-based Message Authentication, Reporting and Conformance (DMARC) system.
This completes the SPF and DKIM entries already set. SPF is there to tell which mail servers are allowed to send emails from the domain. DKIM verifies that the mail comes from the sender. With DMARC the domain owner can now give recommendations to the recipient server what to do with the email if the SPF or DKIM is incorrect. Usually, of course, the e-mail should then be rejected.
A nice side effect is the reporting. With the entry you can create a email address to which the mail server reports are then sent. It makes sense to use a reporting service in this context. This is also offered by mxtoolbox, for example, or another service. In the event of misuse of the e-mail, action can then be taken very quickly.
The DMARC entry can be created with a DMARC Record Generator.
If everything is configured correctly you can set the mail usage to reject.
In this first example, the recommendation is set to none in the event of an SPF or DKIM error, so that only reporting takes place. Since we always do everything correctly, the entry can then also be set directly to reject can be changed.
Final check of the domain settings
After optimizing the settings, we use mxtoolbox again to check the entries.
