Finally live without spam. This is basically only with a professional protection system that analyzes the mails and uses all available options to the abuse of their own Domain to prevent spam.
This goes, for example, with a spam protection gateway.
There are still many providers that do not protect the e-mails of your customer domains. As a rule, only the MX record of a domain is set on the server so that the customer can also receive e-mails via the domain.
That brings with it a lot of dangers. Because the eMialsystem can be manipulated very easily. It is possible to easily fake the sender's name. You can send an eMail under any domain name. If the domain owner has not protected himself, someone else can send e-mails in his name. In the worst case, the responses also go back to the domain owner.
That does not have to be. With a few clicks the domain is well protected from such things.
The Sender Policy Framework (SPF) is one of the methods used to protect the sender domain against counterfeiting. In the SPF entry of the name server the eMailserver are authenticated, which are allowed to send eMails from this domain.
At webhosting.de, for example, these mail servers were entered in the TXT entry:
"Sp = spf1 mx a: spamschutz.webhoster.de a: spamschutz2.webhoster.de a: spamschutz3.webhoster.de a: spamschutz4.webhoster.de -all"
It is hereby 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 sending.
Important: An SPF entry is through RFC 7208 become obsolete. The SPF entry is simply defined as a TXT entry in the domain.
With the -Alles we ban the shipping via other servers.
A provider checking the SPF record will not accept the email, or mark it as spam suspicious.
To check the authenticity of the email sender is an identification protocol such as DomainKeys required by Yahoo.
The e-mail itself is provided with a digital signature that the e-mail server of the recipient can check with a public key present in the DNS.
There are different ways to define the whole thing. This can either be done on the server. For Plesk, however, a script must be installed here, which stores the key locally, or you must use the Plesk DNS server.
If the control panel does not offer a possibility, you can simply use a spam protection gateway. Here you can also directly authenticate all authenticated outgoing emails with a signature.
In the case of ISTORE of the provider webhoster.de this goes like this:
In the Plesk menu just select the domain and click on ISTORE on the right.
Select matching domain for access to the iStore.
Now check the status of 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 turn right Manage in Spam filter Panel Click and manage the domain in the main menu.
In the main menu of the spam protection gateway you can now in the menu on the left side just in the section outgoing DKIM click 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, this can also be displayed.
As selector we use here default, That does not matter. Default is however used by most systems. In case of a change of the system then not everything has to be adjusted.
The public key is now displayed and can be easily 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 arbitrarily. As a rule, nothing changes so fast here. 400 seconds are fine.
DKIM Check with mxtoolbox
The now set entry can be well with mxtoolbox to verify. The program immediately shows if everything is OK.
As we can see, the DKIM entry is now available. however, it will be shown that there is no DMARC entry yet. Of course we want to change that as well and just add a suitable DMARC entry.
Add a DMARC entry
A third protection mechanism for emails. The Domain-based Message Authentication, Reporting and Conformance (DMARC) System.
This completes the already set SPF and DKIM entries. SPF is here to say which mail servers are allowed to send eMails of the domain. DKIM verifies that the mail comes from the sender. With DMARC, the domain owner can now make recommendations to the recipient server as to what should happen to the email if the SPF or DKIM is faulty. In general, of course, the e-mail then reject.
A nice side effect is the reporting. With the entry one can define an eMailadresse to which then the reports of the mail servers are sent. It makes sense to use a reporting service in this context. This offers eg. also mxtoolbox, or another service. In case of misuse of the email can then be traded very quickly.
The DMARC entry can be created with a DMARC Record Generator.
If everything was configured correctly you can then reject the use of mail.
In this first example, the recommendation for an SPF or DKIM error is set to none so that only reporting takes place. Since we always do everything right, the entry can then directly on reject be changed.
Final examination of domain settings
After optimizing the settings, we again use mxtoolbox to check the entries.