Finally living spam-free. This is possible in the Gru.de only with a professional protection system, which analyses the mails and uses all available possibilities to prevent the abuse of your Domain to prevent the sending of spam.
This can be done with a spam protection gateway, for example.
Even today there are still numerous Providerthat do not protect the emails of your customer domains. Usually only the MX record of a domain is transferred to the Server so that the customer can also receive e-mails 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. One can eMail submit under any domain name. If the domain owner has not protected himself against this, someone else can send e-mails in his name. In the worst case, the replies will even go back to the domain owner.
It doesn't have to be. With just a few Clicks the domain is well protected against such things.
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 email server which are allowed to send e-mails from this domain.
At web hosting.de, for example, these are the mail servers entered in the TXT entry:
"v=spf1 mx a:spam protection.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.
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 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.
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. 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 holder can now make recommendations to the recipient server about what to do with the e-mail 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. In this context it is useful to define a reporting Service use. This also offers e.g. mxtoolbox or some other service. In the case of abuse of the email can then be acted very quickly.
The DMARC entry can be created with a DMARC Record Generator create ...to leave.
If everything is configured correctly you can set the mail usage to reject.
In this first example, the recommendation is applied to a Error of SPF or DKIM is set to none, 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