Email policy

GMX 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 GMX customers, 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.

Requirements:

  • The email sender must respect the legal requirements of their own country, as long as they do not contradict the provisions stated here. For senders from the USA, this primarily refers to observing the provisions of the Can-Spam Act.
  • In addition to this, the operator is obliged to check the server at regular intervals to avoid unauthorized access.
  • The receipt of emails with malicious, immoral, or illegal content will be refused. This applies in particular to emails infected by viruses or trojans, or mails that refer to virus or trojan infected sites. Emails with seditious content, or that provoke illegal acts, or glorify violence, or emails that refer to sites that do this will be rejected instead of Emails with seditious content, or that provoke illegal acts, or glorify violence, or emails that refer to sites that do this.
  • GMX reserves the right to use external lists, such as IP lists (DNSBL/RBL lists) or hash lists to sort and reject emails. In addition to this, GMX reserves the right to seek legal action against users who infringe on this email policy, or to temporarily or permanently block email reception for such users.

Glossary

  1. The email header contains technical information on the process of sending an email. Most email programs and webmail interfaces hide the email header. In contrast to this, the email body (the text itself) is typically displaced. The body can be pure text or comprise multiple elements such as text and attachments.
  2. The HELO command is part of the SMTP protocol used for email delivery. With the help of this command, the email exchange between two servers gets initiated as the sending server transmits its full domain name. Analogous to that, a server indicates by means of the EHLO command that the extended SMTP protocol version (ESMTP) should be used.
  3. A Reverse DNS entry or FQDN (Fully Qualified Domain Name or PTR-RR) is the unique name of an internet host. The FQDN can be used to discover the host's IP address. The Reverse DNS entry should be used as the HELO when sending emails. You can find detailed information in the Digital Guide from IONOS.
  4. SPF (Sender Policy Framework) is a technology designed to make it more difficult to spoof sender addresses. It ascertains the IP addresses from which emails with a specific sender domain can be sent (or from which IP addresses mails may not be sent). To allow this to happen a TXT type (or SPF type if it exists) resource record is created in the DNS zone; it lists all the authorised IP addresses used as sending addresses in the domain. For more information on setting up an SPF record, see the Open-spf.org website.
    When an email is redirected, a receiving system that validates email reception against an SPF entry is unable to validate the sender's identity. Forwarding servers should use SRS to encapsulate the sending address in an envelope to prevent SPF validation returning incorrect results. For more information on SRS refer to the Open-spf.org site.
  5. An RBL list collects IP addresses. The list can be used to decide before establishing a connection if specific email senders are allowed to deliver to the receiving system, and to evaluate the spam probability with which emails are tagged. There are various types of lists of this kind. Some include IP addresses from which the owner is not prepared to receive and to which they are not prepared to send emails. Other lists include IP addresses which are known to be responsible for sending spam mail.