Requirements and Recommendations

Requirements for senders

WEB.DE is committed to secure, reliable, and trustworthy email communication. To ensure this, certain technical, organizational, and content guidelines apply when sending emails to WEB.DE.

These guidelines, as well as further recommendations, are aimed at the administration and operation of mail servers.


Checklist for successful delivery

  • Static IP address
  • rDNS entry (individual, not generic)
  • No listing on DNSBLs
  • Correct MX or A records
  • Valid HELO/EHLO (FQDN)
  • RFC-compliant headers
  • Correct time stamps
  • DKIM signature with valid alignment
  • SPF record available (recommended)
  • DMARC policy implemented (recommended)

Infrastructure requirements

Static IP address

The delivering server must have a static IP address.

No dial-up connections

IP addresses from dial-up ranges or dynamically assigned addresses are not accepted.

Reverse DNS

The IP address of the mail server must have a valid reverse DNS entry (PTR-RR) that refers to a fully qualified domain name (FQDN). Which should belong to your own domain.

Recommended: mail.yourdomain.tld

Generic default entries (e.g. 123-123-123-123-static.ihrprovider.tld) usually result in rejection.

DNS block lists

Make sure that neither the IP address nor the domain is listed on known block lists (e.g. Spamhaus.org).

MX/A resource record

The domain must have valid MX or A resource records in the DNS that specify email servers for receiving, in order to enable an email response.


SMTP compatibility

HELO/EHLO command

The mail server must send a valid HELO/EHLO when establishing a connection - as an FQDN, e.g. host.yourdomain.tld.

Email header

Emails must comply with the standards set out in RFC 5321 and RFC 5322. This includes:

  • The Date, From, Message-ID (and Sender, if applicable) fields must be present and formatted correctly.
  • Each of the fields BCC, CC, Date, From, Sender, Subject, To may only appear once in the header.
  • The time information (date, time, time zone) must be correct and must not deviate significantly from the actual time.

Authentication & Identity

DKIM (DomainKeys Identified Mail)

To ensure the security and confidentiality of messages, the use of a valid DKIM signature is mandatory. An essential component is DKIM alignment. The DKIM domain must match the sender domain (RFC 5322.From) - at least in “relaxed” mode.

Examples of valid DKIM alignment:

DKIM domain From domain Modus
example.com child.example.com relaxed
child.example.com example.com relaxed
example.com example.com strict
child.example.com child.example.com strict


SPF (Sender Policy Framework)

An SPF record in the DNS is recommended. It defines which servers are allowed to send emails on behalf of the domain.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

Support DMARC to prevent spoofing and phishing of your domain and to maintain the authenticity of your emails.

DMARC enables you to give the receiving system clear instructions on how to handle emails that were not sent by you and could therefore be fake. For example, you can specify that such emails should be moved to quarantine or rejected outright.

Make the necessary DNS entries and sign your emails in accordance with DMARC requirements. Please note that we require DKIM as a minimum requirement; SPF alone is not sufficient.

Only use domains for which you are authorized as the sender. This will help you protect the integrity of your email communications overall.


Requirements for bulk senders

In order to protect inboxes from unwanted bulk communications, additional requirements apply to the sending of newsletters and promotional emails. These apply in addition to the general guidelines for senders.

Emails that do not comply with recognized standards such as those of the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) or the Certified Senders Alliance (CSA) are not automatically classified as desired. Delivery to the inbox only takes place if receipt is clearly desired.

Basic requirements

Consent required

Only send bulk emails to people who have expressly agreed to receive them. Consent should ideally be obtained via a double opt-in procedure.

Comply with standards

Follow the guidelines of the M3AAWG and the CSA. These contain best practices for technical authentication, sending practices, formatting, and unsubscribing.

Participation in the CSA recommended

The Certified Senders Alliance offers advantages in terms of deliverability and cooperation with email providers. For more information, visit the CSA Webiste.

Ensure sender transparency

The sender must be clearly and unambiguously identifiable. Service providers or third parties who handle sending on behalf of the sender must also be clearly identifiable to the recipient group.

Enable easy unsubscribing

Every email must contain an easily accessible and understandable unsubscribe option. Ideally, the newsletter should comply with the RFC 8058. standard. If this is the case, an unsubscribe button can be displayed automatically. If the standard is not met, a valid reply address must be provided as an alternative for unsubscribing.


Delivery quality and reputation

Only send to active addresses

Avoid sending to invalid, inactive, or outdated addresses. Regularly remove undeliverable contacts. If many messages are sent to unknown or deactivated addresses, this can lead to the temporary suspension of the mailing system. In severe cases, we reserve the right to permanently reject the system.

Avoid spam complaints

Ensure that your content is relevant and that your sending frequency is appropriate. This will help you avoid complaints and protect your domain reputation.


Problems with delivery despite following our recommendations

  • If your email delivery attempts to us are rejected despite following all requirements and recommendations, our mail system will issue a multi-line error message. This provides information about the cause of the rejection and whether the postmaster team needs to be contacted to resolve the issue. An example of this is that your IP address or domain is on an internal block list or there is a policy violation.
  • In addition, in the case of mass mailings, our system may throttle delivery despite IP warm-up. In this case, too, you can contact us via the corresponding error message.
  • Further information: General information about our error messages..

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.
  6. The Messaging, Malware and Mobile Anti-Abuse Working Group is an international association consisting of internet service providers, anti-spam and anti-virus technology producers as well as other interested parties. The association offers a member forum for the exchange around the topic security in telecommunications: https://www.m3aawg.org/
  7. RFC Indicates documents that describe the technical or organizational guidelines for the internet.
  8. Opt-in describes a procedure in which a consumer explicitly consents to be contacted for advertising purposes. In addition, the Double-Opt-In procedure makes sure that the email address provided really belongs to the consumer. In order to do that, usually a verification link will be sent to the email address. This verification link has to be accessed once before getting added to a distribution list. That way, it is possible to prevent unauthorized third parties from adding email addresses to distribution lists.