Email policy

WEB.DE 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 WEB.DE 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) To ensure the security and confidentiality of your messages, the use of a DKIM signature is mandatory. An essential part of this is to ensure DKIM alignment. To achieve this, the DKIM domain must match your From domain (RFC 5322.From), at least in relaxed form. Below you will find examples that illustrate this requirement.
    • Example 1: (relaxed DKIM alignment)
      • DKIM domain = example.com
      • From domain(RFC 5322.From) = child.example.com
    • Example 2: (relaxed DKIM alignment)
      • DKIM domain = child.example.com
      • From domain(RFC 5322.From) = example.com
    • Example 3: (strict DKIM alignment)
      • DKIM domain = example.com
      • From domain(RFC 5322.From) = example.com
    • Example 4: (strict DKIM alignment)
      • DKIM domain = child.example.com
      • From domain(RFC 5322.From) = child.example.com
  • (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) Ensure the authenticity of your emails by signing them in accordance with the DMARC requirements. Please note that DKIM is the minimum requirement, especially if you send emails to our customers, as this is mandatory there. In this case, SPF alone is not sufficient. It is therefore advisable to implement both DKIM and SPF to ensure that your emails meet the necessary security standards.
    DMARC gives you the option of providing the receiving system clear instructions on how to deal with emails that were not sent by you and could therefore be forged. For example, you can specify that such emails are to be moved to quarantine or rejected directly. These measures make so-called "spoofing" of your domain considerably more difficult.
    It is also important that you do not use a domain as the sender information that you are not authorized to use. By following these practices, you will help to protect the integrity of your email communications and minimize the risk of unauthorized sending and spoofing.

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.
  • WEB.DE 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, WEB.DE 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.