What Germany's GMX, WEB.DE, and mail.com DMARC Enforcement Means for Your Email (And How to Fix It)

GMX, WEB.DE, and mail.com - three of Germany's largest consumer email providers, all operated by United Internet - have shifted to inbound DMARC enforcement. If you're sending email to German recipients on these platforms and your messages are suddenly failing DMARC checks, landing in spam, or getting rejected, here's what changed and exactly how to fix it.

What DMARC alignment actually means at these providers

DMARC has two ways to pass. One is SPF, which verifies the sending server is authorized. The other is DKIM, which verifies the message wasn't modified in transit and is signed by the right domain. Both have to pass *and* be aligned - meaning the domain in the SPF or DKIM signature must match the From address the recipient sees.

At GMX, WEB.DE, and mail.com, alignment means one of two things must be true:

• The envelope return path (the server that received the message) and the From header domain must match exactly (SPF alignment, mode=relaxed if the same org, mode=strict if different)
• The DKIM selector domain must match the From header domain

If either aligned SPF or aligned DKIM passes, DMARC passes. If neither passes alignment, the message fails DMARC - and now these providers act on that failure.

Why your mail is probably failing

The three most common failure patterns for senders hitting DMARC problems with German providers:

1. Marketing platforms and CRMs use a shared envelope domain. Your From address shows yourdomain.com, but the platform sends from something like mail.yourdomain.com or a completely different sending infrastructure. SPF passes because the sending server is authorized, but the domains don't align, so DMARC fails. This is the most common failure mode for non-technical senders hitting these filters.

2. Transactional tools sign DKIM with their own domain, not yours. Your SaaS vendor, billing platform, or support tool adds a DKIM signature using its own selector domain. The signature is valid, but it doesn't match your From address - so alignment fails. You typically won't see this as an error in your sending platform's UI; it only shows up in DMARC reports.

3. Forwarding broke the alignment chain. If a message passes through a forwarding service before reaching GMX or WEB.DE, the forwarding server may be the one sending to the final recipient, not your original server. SPF may pass from the forwarder's IP, but the From domain still belongs to you - and the forwarder's domain isn't yours, so alignment fails. This is especially common with legacy mailing list software and auto-forwarding rules.

None of these show up as obvious errors in standard SMTP tests. You need DMARC aggregate reports (RUAs) to see them clearly.

How to see what's actually failing

The only reliable way to know what's breaking at GMX, WEB.DE, and mail.com is to check your DMARC aggregate reports. These arrive at the RUA email address you specified in your DMARC record - usually something like rua@yourdomain.com or reports@yourdomain.com.

Look for failures where:

• The source IP is from a provider or platform you use (marketing tool, CRM, transactional service)
• The DKIM result shows "pass" but the alignment shows "fail" - this means DKIM is signing but not with your domain
• The SPF result shows "pass" but the alignment shows "fail" - this means the sending server is authorized but the return path domain doesn't match your From address

If you don't have a RUA configured yet, you need one before you can diagnose anything. If you have one but aren't receiving reports, check whether your DMARC record is correctly formatted and whether the receiving provider isn't blocking your reports at the firewall or spam filter level.

How to fix it

Step 1: Get your baseline. Check your DMARC record and find your RUA. Review a week's worth of aggregate reports before changing anything.

Step 2: Identify the misalignment sources. For each failing source, determine whether it's a platform you control (your own mail server) or a third party (marketing tool, transactional service, forwarding setup). Each has a different fix.

Step 3: Fix SPF alignment. If your own mail server is sending with a return path domain that doesn't match your From address, align your SPF record to use your actual From domain, not a shared or legacy sending domain. In most cases, this means updating your SPF include to reference the right mechanisms.

4: Fix DKIM alignment for third-party senders. Any platform that sends email on your behalf should be signing DKIM with *your* domain, not their own. This requires setting up a custom DKIM selector with the platform and publishing the record in your DNS. Many major platforms support custom DKIM - Salesforce, SendGrid, Mailchimp, HubSpot all have documentation for this. If a platform doesn't support custom DKIM signing, that's a vendor problem you need to escalate, because there is no good workaround.

Step 5: Review forwarding. If you have forwarding rules or services that repackage and resend your email, those are breaking alignment. Evaluate whether the forwarding is necessary or whether you can replace it with a different mechanism (like a redirect or a bcc approach that doesn't rewrite the envelope).

What DMARCFlow does here

DMARCFlow parses aggregate reports from all major receiving providers - including German ones like GMX, WEB.DE, and mail.com - and surfaces alignment failures organized by source domain and sending platform. You see which third-party tools are misaligned, which percentage of your total volume is affected, and which specific domains are failing, before a German recipient's IT department flags your domain or your mail lands in a quarantine folder without notification.

FAQ

Does this affect mail I receive from GMX users, or only mail I send to them?

Only mail you send to them. This is inbound enforcement - it applies to messages coming into these platforms, not messages they send out.

I'm using Google Workspace. Do I need to do anything?

Google Workspace typically signs DKIM with your domain automatically, and SPF is aligned by default. If you're still failing DMARC at these providers, the issue is likely a third-party tool or a secondary sending domain you're using for marketing or transactional mail that isn't properly aligned.

What if I'm using a shared marketing platform that doesn't support custom DKIM?

You have two options: find a platform that supports custom DKIM signing with your domain, or implement a subdomain strategy where your From address uses a subdomain that the platform is authorized to send from (and that subdomain has its own DMARC record). The second approach requires careful DNS configuration and still requires aligned DKIM from the platform.

Is p=reject too aggressive if I'm still fixing alignment issues?

Use p=quarantine while you're validating. Move to p=reject only after you've confirmed that your aligned SPF and DKIM are passing consistently for all legitimate sending sources and you've reviewed at least two weeks of aggregate reports with no unexpected failures.

How long does it take for fixes to take effect?

DNS changes for SPF, DKIM, and DMARC records typically take 24-48 hours to propagate fully due to TTL and caching at the receiving provider level. Don't expect instant results immediately after making changes.