GMX / WEB.DE (United Internet) — Postmaster Requirements

GMX, WEB.DE and mail.com are operated by United Internet (1&1) and share one postmaster policy, published in parallel at postmaster.gmx.net, postmaster.web.de, and postmaster.mail.com. They dominate the German consumer mailbox market, so any list with European recipients hits these rules. United Internet is notably stricter than most providers on two points: DKIM is mandatory (SPF alone is not sufficient) and generic reverse DNS is rejected outright.

Infrastructure and DNS requirements

Requirement	Detail
Static IP	The delivering server must have a static IP. IPs from dial-up or dynamically assigned ranges are not accepted
Reverse DNS (PTR)	Must resolve to an FQDN belonging to the sender's own domain. Generic provider defaults (e.g. 123-123-123-123-static.ihrprovider.tld) "usually result in rejection"
Forward DNS	The sending domain must have valid MX or A records
HELO/EHLO	Must be a valid FQDN
Blocklists	Neither the IP nor the domain may be listed on known blocklists (they suggest checking via dnsbl.info)

Message-format requirements (RFC 5321/5322)

• Headers must comply with RFC 5321 and RFC 5322.
• Required header fields: Date, From, Message-ID (and Sender if applicable).
• Each of BCC, CC, Date, From, Sender, Subject, To may appear only once.
• The Date (date, time, time zone) must be correct and must not deviate significantly from actual send time.

Authentication: DKIM mandatory, aligned

• DKIM is mandatory — "the use of a valid DKIM signature is mandatory."
• SPF is only recommended; explicitly: "We require DKIM as a minimum requirement; SPF alone is not sufficient."
• DMARC is recommended for spoofing/phishing prevention.
• The DKIM d= domain must align with the RFC5322.From domain, at least in relaxed mode:

DKIM domain (d=)	From domain	Mode
example.com	child.example.com	relaxed (accepted)
child.example.com	example.com	relaxed (accepted)
example.com	example.com	strict
child.example.com	child.example.com	strict

This is the same alignment concept DMARC uses — see DMARC — but United Internet enforces DKIM alignment as an acceptance condition even without a DMARC policy.

Bulk-sender requirements

• Explicit consent only, ideally via double opt-in.
• Follow M3AAWG and CSA guidelines; CSA participation is recommended (below).
• Unsubscribe: every email must contain an easily accessible, understandable unsubscribe option. Preferred: RFC 8058 one-click List-Unsubscribe — if compliant, GMX/WEB.DE display an unsubscribe button in the UI. If RFC 8058 is not met, a valid reply address must be provided as the fallback.
• List hygiene: avoid invalid, inactive, or outdated addresses; regularly remove undeliverables. "If many messages are sent to unknown or deactivated addresses, this can lead to temporary suspension" of acceptance.
• Sender identity: the sender must be clearly and unambiguously identifiable; content must be relevant and frequency appropriate.
• Warm-up caveat: for mass mailings, "our system may throttle delivery despite IP warm-up" — expect tempfails on new IPs even with a proper ramp (see IP Warm-Up).

Error messages

United Internet documents the structure of its SMTP errors rather than an exhaustive code table:

• 5xx = permanent errors, 4xx = temporary errors.
• Every rejection contains an SMTP status code, a problem description, and a URL with diagnostic parameters pointing at the matching postmaster page (https://postmaster.gmx.net/..., postmaster.web.de, or postmaster.mail.com) with explanations and solutions. Always follow that URL — it identifies the exact block reason.
• Example: 554 gmx.net (mxgmx104) Nemesis ESMTP Service not available / No SMTP service / IP address is block listed. — the connecting IP is on a blocklist; the embedded URL explains remediation.

Filtering behavior, allowlisting, feedback loop

• No allowlist: "GMX does not offer this service" — following the requirements is stated to make allowlisting unnecessary.
• Greylisting-like behavior: they delay or reject mail from servers showing "unmistakable characteristics that indicate a spamming server."
• Filtering is both IP-based and content-based. For misclassifications, submit the message's extended headers via their contact form (https://postmaster.gmx.net/en/contact).
• No public in-house FBL. Complaint feedback for GMX/WEB.DE is available in practice through the CSA (certified senders receive complaint data as part of the certification ecosystem); the postmaster site itself directs bulk senders toward CSA rather than offering a direct FBL signup.

Certified Senders Alliance (CSA) and trustedDialog

• CSA — a positive-list project of eco (Verband der deutschen Internetwirtschaft) with the DDV. Certification is checked by GMX/WEB.DE and multiple other European providers; United Internet recommends participation for newsletter/advertising senders. Info: certified-senders.org.
• trustedDialog — United Internet Media's paid brand-protection standard: sender authentication plus content-integrity verification, yielding a seal and brand logo in the inbox, higher sender-authenticity confidence, and (per their claims) improved open/click rates. Relevant mostly for large consumer brands mailing German users.

GMX outbound servers (for receivers / verification)

Mail genuinely from GMX arrives from these published hosts:

Role	Hostname	IPs
Outbound	mout.gmx.net	212.227.15.15, 212.227.15.18, 212.227.15.19, 212.227.17.20, 212.227.17.21, 212.227.17.22
Bounce handling	mout-bounce.gmx.net	212.227.15.44–46, 212.227.17.26, 212.227.17.28, 212.227.17.29
Lower-reputation (customer-forwarded)	mout-xforward.gmx.net	82.165.159.12–14, 82.165.159.40–42

If GMX blocks you

1. Read the bounce — it contains the exact reason and a postmaster URL.
2. Fix root cause against the requirements above (the delisting form will not help if PTR/DKIM/consent problems persist).
3. Contact the abuse team via the postmaster contact form, providing: your email address, contact address, name, date of the attempted send, recipient domain, and the exact error message / mailer-daemon text. Note: bounces from full inboxes or recipient misconfiguration are not "blocklisting" and don't belong on that form.