GMX & WEB.DE Sender Requirements

GMX and WEB.DE are two of Germany’s largest consumer mailbox brands, both operated by United Internet (1&1 Mail & Media) on the same mail platform. Their postmaster guidance is published together, and the defining rule is unusual among major providers: a valid DKIM signature is mandatory, and DKIM is the minimum - SPF on its own is explicitly “not sufficient.” Most US providers accept “SPF or DKIM”; GMX inverts that emphasis and treats DKIM as the floor.

This page is built from GMX’s published postmaster page, the GMX Certified Senders Alliance page, and (for trustedDialog) United Internet Media’s own specification. Where the source is silent, that is flagged rather than assumed.

The 60-second version

• DKIM is mandatory and is the minimum. “We require DKIM as a minimum requirement; SPF alone is not sufficient.”
• DKIM must be aligned with the RFC 5322.From domain - at least in relaxed mode.
• SPF is recommended; DMARC is recommended. Neither replaces DKIM.
• Static IP, no dial-up ranges. Dynamic/dial-up addresses are not accepted.
• Individual, non-generic reverse DNS (PTR) that belongs to your own domain. Generic provider defaults “usually result in rejection.”
• Not listed on blocklists (Spamhaus and friends), valid MX/A records, valid HELO/EHLO FQDN.
• Bulk senders: double opt-in consent, M3AAWG and CSA standards, RFC 8058 one-click unsubscribe, send only to active addresses. CSA membership is recommended.

Checklist for successful delivery

Infrastructure

Requirement	GMX’s rule
Static IP	”The delivering server must have a static IP address.”
No dial-up	IPs “from dial-up ranges or dynamically assigned addresses are not accepted.”
Reverse DNS	Valid PTR-RR pointing to an FQDN that belongs to your own domain. Recommended form mail.yourdomain.tld. Generic entries such as 123-123-123-123-static.ihrprovider.tld “usually result in rejection.”
Blocklists	Neither the IP nor the domain should be on known block lists (Spamhaus is named)
MX/A records	The domain must have valid MX or A records so a reply is possible

SMTP compatibility

• HELO/EHLO must be a valid FQDN, e.g. host.yourdomain.tld.
• Headers must comply with RFC 5321 and RFC 5322. GMX introduces this with “This includes:” followed by specific header expectations; the exact enumerated sub-points are not reproduced in the machine-readable version of the page, so this page states the RFC 5321/5322 compliance requirement as published and does not invent the sub-list. For header fundamentals see email headers and the envelope.

Authentication and identity

DKIM (mandatory). “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.” GMX publishes the alignment matrix:

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

In other words, an exact match is strict alignment; sharing the organizational domain is relaxed; GMX accepts relaxed as the minimum.

SPF (recommended). “An SPF record in the DNS is recommended.” It defines which servers may send for the domain.

DMARC (recommended). “Support DMARC to prevent spoofing and phishing.” You can instruct receivers to quarantine or reject mail that is not really from you. GMX then restates the key point: “Please note that we require DKIM as a minimum requirement; SPF alone is not sufficient.”

The practical reading: publish all three, but understand that DKIM is the load-bearing requirement at GMX. A perfectly configured SPF record with no DKIM signature does not clear the bar. For how DKIM, SPF and DMARC fit together, see DMARC in 2026; for the alignment concept specifically, the same page covers relaxed vs strict.

Requirements for bulk senders

These apply in addition to the general guidelines, for newsletters and promotional mail. GMX is blunt about the baseline: messages that do not comply with recognized standards “such as those of the M3AAWG or the CSA are not automatically classified as desired. Delivery to the inbox only takes place if receipt is clearly desired.”

Bulk requirement	GMX’s rule
Consent	”Only send bulk emails to people who have expressly agreed.” Consent “should ideally be obtained via a double opt-in procedure.”
Standards	Follow M3AAWG and CSA guidelines (technical authentication, sending practices, formatting, unsubscribing)
CSA	”Participation in the CSA recommended” for deliverability and provider cooperation
Sender transparency	The sender must be clearly identifiable; any third party sending on their behalf must also be identifiable
Easy unsubscribe	Every email needs an accessible unsubscribe option; ideally compliant with RFC 8058 so a one-click unsubscribe button is shown. If not, a valid reply address must be provided
Active addresses only	Avoid invalid/inactive/outdated addresses and remove undeliverables regularly

Sending to dead addresses has a hard consequence

GMX states a real penalty for poor list hygiene: “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.” This is a stronger, explicitly-stated consequence than the usual “reputation hit” - treat invalid-address rates as a system-availability risk at GMX, not just a metric.

Certified Senders Alliance and trustedDialog

• Certified Senders Alliance (CSA). GMX recommends participating in the CSA, describing it on its dedicated postmaster page as a positive-list project by the Verband der deutschen Internetwirtschaft (eco) with the Deutscher Direktmarketing Verband (DDV). The pitch: a single positive list that “successful delivery is managed for multiple providers.” CSA is a recommendation, not a hard requirement.
• trustedDialog. Separately, United Internet Media operates trustedDialog, a DKIM-based sender program for its properties (WEB.DE, GMX, 1&1) that lets verified senders be recognized and privileged (for example, branded display). Per United Internet Media’s specification, trustedDialog “uses the domain-level authentication framework DKIM to assure the authenticity of e-mail senders,” so a DKIM signature on all referring domains is a prerequisite, and a dedicated subdomain (and ideally a dedicated IP) is recommended. trustedDialog is not part of the baseline requirements page; it is an opt-in commercial program layered on top.

What GMX’s page does not state

To stay honest about the source:

• No published volume threshold or warm-up schedule. GMX does not name a messages-per-day number for “bulk,” and it does not publish IP warm-up steps or a throttling formula. The page’s one explicit throttle is the temporary suspension tied to sending to unknown/deactivated addresses (above). Any claim that “throttling happens despite warm-up” is not stated by GMX and is not asserted here.
• No TLS version requirement. The page does not name TLS 1.2+ or any transport-security floor. (Still good practice - see encryption in transit.)
• The specific header sub-points that follow “This includes:” are not captured in the fetchable page text; only the RFC 5321/5322 compliance requirement itself is stated here.

“Not stated” means absent from GMX’s guidance, not “safe to skip.”

Common mistakes

• Relying on SPF alone. At GMX this fails by design - DKIM is the minimum, and SPF is explicitly “not sufficient.”
• DKIM that does not align. A valid signature on the wrong domain still fails GMX’s alignment requirement; align the DKIM d= domain with the From domain, at least in relaxed mode.
• Generic PTR records. A provider-default reverse DNS that looks like a raw IP “usually results in rejection.” Use a meaningful PTR under your own domain.
• Letting dead addresses accumulate. This can suspend your mailing system at GMX, not merely lower a score.
• Treating CSA or trustedDialog as the requirement. Both are optional programs; the mandatory bar is DKIM plus the infrastructure checklist.

Blocklist hygiene is part of the infrastructure bar here too - keep IP and domain off Spamhaus and similar lists, using the DNSBL directory to check and delist. To see where GMX/WEB.DE sit relative to other providers, use the provider rule tracker, and to decode rejection replies, the enhanced status codes reference.

What Egressif does

We send to GMX and WEB.DE from owned, static IP space with individual, non-generic reverse DNS under our own domain - the exact opposite of the dynamic-range and provider-default PTRs GMX rejects. Every message is DKIM-signed with the signing domain aligned to the From domain (relaxed at minimum), meeting GMX’s mandatory-and-minimum DKIM bar, with SPF and DMARC published alongside rather than in place of it. We monitor blocklists so an IP or domain listing surfaces before GMX acts on it, we hold to double opt-in consent and RFC 8058 one-click unsubscribe on bulk streams, and we keep lists clean so we never trip GMX’s temporary-suspension penalty for mailing dead addresses. Where CSA or trustedDialog participation helps a given program, we treat them as additive, not as a substitute for the technical baseline. We do not promise placement; these are the entry requirements, and consent and reputation decide the rest.