mc8051 considers it its responsibility to provide its users with trustworthy and secure service. We therefore place the highest priority on the careful evaluation of incoming emails as well as on taking action against unsolicited messages.
To ensure that you do not experience a connection issue or a sending issue when trying to send emails to us, please adhere to the following policies and make sure your mail server’s configuration is adjusted accordingly.

Technical Guidelines:

  • (Static IP) The delivering server must have a static IP address.
  • (No Dialup) IP addresses that belong to a dial-up range / are dynamically assigned cannot send us any emails.
  • (rDNS) For your mail server’s IP address, there must be a valid reverse DNS entry in the DNS that points to your domain. The rDNS entry must be set to an individual, complete host name (FQDN).
    You can find information on reverse DNS records here, among other places: Wikipedia.org, Spamhaus.org
  • (rDNS-Policy) The reverse DNS record may not match the standard entry of your hoster/provider such as “123-123-123-123-static.yourprovider.tld”.
    Recommended format: “mail.yourdomain.tld”
  • (DNSBL) Make sure that your mail server’s IP address and your domain are not on a blocklist on Spamhaus.org.
  • (HELO) Your mail server must send a valid HELO/EHLO. It must be a fully qualified domain name (FQDN) such as “host.yourdomain.tld”.
    You can check the configuration of your HELO, e.g. via the following service: https://www.abuseat.org/helocheck.html
  • (MX, A Record) Correct MX or A records must be configured in the DNS for your domain. The following service offers an overview of your MX configuration: https://mxtoolbox.com/
    The following offers a more detailed overview of your DNS configuration: https://intodns.com/
  • (Header) When creating your emails, you must comply with the standards required in RFC 5321 and RFC 5322. Among other things, this includes the following points:
    • The following header fields must be included and be syntactically correct: Date, From, Message-ID. This also applies to the sender header, if it’s needed for your configuration.
    • The BCC, CC, Date, From, Sender, Subject, and To fields may not be included in the header more than once
    • Ensure that your server and client have the correct time configuration (date, time, time zone) to prevent any significant difference from the actual time appearing in the date header
  • (DKIM) Your messages should be signed per DKIM and therefore have at least one valid DKIM signature. At the same time, we strongly recommend that the DKIM signing domain matches the From domain (RFC 5322.From header), at least in relaxed form. In case you use an infrastructure that does not support this configuration by default, you should add another signature to have at least one DKIM signing domain which matches the RFC 5322.From header domain. In an optimum case, the same also applies for the MailFrom domain (RFC 5321.MailFrom).
  • (SPF) In addition to DKIM, you can also publish a SPF record in the DNS, which provides information on who (which systems) may send emails under your domain’s name and how to handle emails that do not fulfil the policy specified in the record.
  • (DMARC) Sign your emails via DKIM so that you can ensure the authenticity of your emails and/or if you have an SPF record for your domain, you should publish a DMARC policy in the DNS. By doing so, you give recipients a recommendation on how to handle emails that they have not sent and therefore were falsified. This can make it difficult to spoof your domain. Conversely, any domain that you do not have permission to use should not be used as a sender address.