Why Are GMX and Web.de Enforcing DKIM and DMARC in 2026?

You sent a message. It never landed. No bounce, no error — just silence. That's increasingly common with GMX and Web.de, two of Europe’s largest email providers. Why? Because they’re now enforcing DKIM and DMARC for inbound mail.

It’s not just policy — it’s survival. As spoofing and phishing grow more sophisticated, even trusted domains are under attack. GMX and Web.de are demanding proof: your email must carry a valid DKIM signature and follow a DMARC policy. Without either, your message gets blocked or marked as spam.

Key takeaways

  • GMX and Web.de now reject inbound messages that lack valid DKIM signatures or compliant DMARC policies.
  • This enforcement aligns with broader industry trends to combat phishing by requiring cryptographic authentication for trusted senders.
  • Messages failing DKIM or DMARC checks are either blocked or sent to spam folders, reducing inbox placement for non-compliant sources.

What Happens to Emails Without DKIM or DMARC from GMX/Web.de?

Messages sent without a valid DKIM signature or failing DMARC policy checks are routinely blocked or marked as spam by GMX and Web.de. These providers enforce strict authentication, so emails from domains without proper DKIM and DMARC alignment often end up rejected at the SMTP level or quarantined. Delivery rates for non-compliant domains can fall below 10%.

SMTP Rejection for Missing DKIM Signatures

GMX and Web.de validate inbound mail using SMTP-level checks. If a message lacks a valid DKIM signature, it is typically rejected during the handshake. This happens before any content is evaluated. You'll see a hard bounce with a message like "550 5.7.1 Message rejected due to missing or invalid DMARC/DKIM alignment."

DKIM ensures the email body and headers haven't been altered in transit. Without it, the receiving server has no way to confirm the sender's legitimacy. Even if the SPF check passes, a missing DKIM signature is often enough to trigger rejection. This is an industry-standard practice, and major providers including Google, Microsoft, and Yahoo enforce similar policies.

DMARC Policy Enforcement and Delivery Failure

When DMARC alignment fails—either because the DKIM or SPF check fails, or the policy is set to reject—Web.de and GMX will either bounce the email or route it to spam. If the policy is set to "quarantine," the message may land in a junk folder. If set to "reject," the sender gets a hard bounce.

DMARC policies are published in DNS records. A domain like example.com could specify policy=reject for unaligned messages. If your domain doesn’t authenticate properly, you're at the mercy of that policy. According to data from the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), enforcement of DMARC policies has grown steadily, with major providers applying them to over 80% of inbound messages in high-volume email environments.

These filters don’t just affect bulk senders. Even individual users can see their emails blocked if their domain lacks correct authentication. If you're sending from a domain without DKIM or DMARC, your delivery success rate on GMX and Web.de can drop below 10%—meaning over 90% of your emails will fail.

Use MailTester’s inbox placement tester to simulate delivery to these domains before you send. It checks for DKIM, DMARC, SPF, and inbox placement in a single test.

Test your email’s inbox placement on GMX, Web.de, and other major providers—before you send.

How GMX and Web.de Evaluate DKIM and DMARC Compliance

GMX and Web.de reject inbound emails that fail DKIM signature validation or DMARC alignment, regardless of SPF results. They enforce strict alignment between the From domain, SPF, and DKIM signatures. If any element is missing or misaligned, the message is blocked—no exceptions.

DKIM: Signature Validation Using Public Keys

When a message arrives, GMX and Web.de check the DKIM signature by retrieving the sender’s public key from DNS. If the signature doesn’t match or the key can’t be found, the message fails verification. This step confirms the email wasn’t altered in transit and comes from an authorized domain.

Even if SPF passes, a missing or invalid DKIM signature means the message won’t deliver. This is consistent with industry best practices outlined in RFC 6376. RFC 6376 defines DKIM’s role in email authentication and is widely adopted by major providers.

DMARC: Alignment Enforcement and Policy Enforcement

DMARC builds on SPF and DKIM by validating alignment between the From domain and the signing domains. If the domains don’t match, the email fails alignment—even if SPF and DKIM pass individually. GMX and Web.de apply their DMARC policy (usually “reject”) to such messages.

They enforce a strict “reject” policy for non-aligned or unsigned messages. SPF is not enough on its own. A message can pass SPF yet be rejected if DKIM fails or alignment is broken. This means your email infrastructure must support both DKIM signing and proper DMARC alignment.

Let’s be clear: if you’re sending to users on GMX or Web.de, you need to test inbound and outbound setups. Use tools like inbox placement testing to simulate real-world delivery conditions and see if your messages pass validation.

The best way to ensure compliance is to validate your authentication setup—especially if you’re using third-party senders or services. You can verify your own domains with bulk list verification to check alignment across multiple addresses or use the real-time API checker during integration testing. These tools help you catch issues before they impact your inbox placement or sender reputation.

Does GMX or Web.de Accept Catch-All Addresses?

No, neither GMX nor Web.de accepts emails sent to catch-all or role-based addresses like info@, sales@, or admin@ unless explicitly authorized. These providers block such addresses by default because they’re commonly abused in spam harvesting and phishing attempts. Even if a domain technically accepts all emails, GMX and Web.de treat unverified role addresses as high-risk and will reject them unless the sender has a proven reputation.

Why catch-alls are blocked

Mail providers like GMX and Web.de use DMARC and domain reputation systems to flag risky patterns. Catch-all addresses are frequently exploited by spammers to test email validity—sending to dozens of common roles to see which ones respond. This behavior is a red flag. According to the IETF’s RFC 5321 (the core SMTP standard), accepting all incoming mail without validation is considered a misconfiguration that enables abuse.

When a domain allows catch-alls, it increases the likelihood of being added to spam blacklists. Providers like Spamhaus and MxToolbox track these patterns and often rate-limit or reject mail from domains that use them. While not all catch-alls are bad, those used without strict filtering are consistently associated with poor deliverability and higher spam scores.

How domain reputation affects inbound mail

GMX and Web.de rely heavily on sender reputation. If your domain sends to role-based or catch-all addresses frequently, even if valid, it may trigger automated filters. The longer your sender profile has a clean record with consistent authentication (SPF, DKIM, DMARC), the better your chances of bypassing these checks.

Let’s be clear: you can’t rely on catch-alls to receive mail from these providers. If you want to ensure delivery to user addresses, you need accurate, up-to-date email data. You can test and verify your list in real time with MailTester’s email list verification tool.

Verify your list for free to catch invalid, catch-all, and role-based addresses before you send. With 98.9% accuracy, MailTester helps you avoid reputation damage and deliverability issues. If you're building systems that send to GMX or Web.de, use the real-time API to validate every address on the fly.

Real-Time Validation: How to Test If Your Domain Passes GMX/Web.de Rules

You can test whether your sender domain complies with GMX and Web.de’s inbound mail policies in seconds using MailTester’s real-time verification API. Input any email address from those domains, and instantly check if your DKIM, DMARC, and SPF alignment pass. This reveals whether your emails will be accepted or blocked before you send, based on real sender reputation and domain policy enforcement — no guesswork, no wasted sends.

Test Your Domain with Real-Time API Checks

  1. Send a verification request to the MailTester API with any target email from GMX or Web.de. The API checks your domain’s SPF, DKIM, and DMARC records in real time, aligned to current standards like RFC 7489 (DMARC).
  2. Validate authentication alignment. The system confirms whether your domain’s DKIM signature matches the domain in the From header. Misalignment is a common reason for rejection by GMX and Web.de, even with valid credentials.
  3. Check policy enforcement. The API detects if your domain has a DMARC policy set to reject, quarantine, or none. GMX and Web.de prioritize messages from domains with strict policies, so a none policy may result in delivery delays or filtering.
  4. Review the result. You receive a verdict — valid, invalid, catch-all, or risky — along with detailed diagnostics on why the message might be blocked.

Validate Before You Send, Not After

Let’s say you’re sending a campaign to a list that includes Web.de addresses. Instead of guessing whether those emails will land in the inbox, use MailTester to test at scale. Input the entire list into our bulk verification tool or automate checks with the real-time API. You avoid hard bounces, protect sender reputation, and improve inbox placement — especially crucial with email providers that enforce strict filtering.

GMX and Web.de are among the most aggressive providers when it comes to rejecting unauthenticated or poorly aligned messages. Their filtering systems rely heavily on DMARC enforcement. For every email you send, alignment must be exact — not just technically correct, but properly configured in DNS.

Use the inbox placement tester to simulate a real delivery path from your domain to GMX/Web.de. You’ll see if your message would reach the inbox, be quarantined, or blocked entirely — all based on current policies.

With MailTester, you get transparency, not assumptions. No magic, no vague reports. Just plain facts about your domain’s readiness to send to specific providers.

DMARC Policy Check: What You Need to Run on Your Domain

You need a DMARC record with a policy of p=none, p=quarantine, or p=reject. Start with p=none to monitor incoming mail, then move to p=quarantine or p=reject once you’ve validated your authentication setup. Include rua=mailto:[email protected] to receive aggregate reports, which help you track alignment and detect spoofing attempts. The more strict your policy, the better protection you get—but only if your legitimate senders are properly authenticated.

Set the Right DMARC Policy for Your Goals

  • Use p=none to start: it does nothing but let you collect data on incoming mail authentication. This is your safest first step.
  • Switch to p=quarantine once you’re confident that your authorized senders are properly signed with SPF and DKIM. This marks unauthenticated mail as suspicious, reducing inbox delivery.
  • Use p=reject only when you’re certain all valid mail is covered by SPF and DKIM. This blocks unauthenticated mail entirely—ideal for domains with strict inbound security requirements.
  • Always include rua=mailto:[email protected] (or a dedicated address) to get daily aggregate reports from DMARC-compliant receivers. These reports show sender alignment, failure reasons, and traffic volume.
  • Monitor these reports regularly—tools like dmarc.org and RFC 7483 define how they work and why they matter for domain security.

Validate Your DMARC Setup with Verified Tools

Don't rely on guesswork. Use tools that validate your DMARC record and test how it’s enforced in practice. For example, MailTester’s inbox placement tester simulates mail delivery to real inboxes—helping you verify if your policy is blocking or allowing traffic as intended. Use the real-time verification API to test individual addresses for validity and alignment. This helps you identify if third-party vendors or users with unauthenticated mail are being blocked.

To avoid delivering mail from unknown sources, enforce p=reject only once your authenticated senders are correctly set up.

Remember: the goal isn’t just to block bad mail—it’s to ensure your domain’s reputation stays clean. Tools like MailTester help detect dead or spoofed addresses before they damage sender reputation. Once you’ve confirmed your DMARC policy is correctly enforced, consider enabling p=reject in your plan to fully harden your inbound mail security.

DKIM Requirements for GMX and Web.de Inbound Mail

GMX and Web.de require valid DKIM signatures on inbound mail using a 2048-bit or higher key, published under a correct DNS selector (like default._domainkey.yourdomain.com). The signature must cover both header and body, and the selector must resolve properly—missing or misconfigured records cause failures. This is enforced consistently across their inbound filtering systems.

How DKIM Must Be Configured for GMX and Web.de

Let’s break it down: you must publish a DKIM public key in DNS using a selector that matches your signing configuration. For instance, if your system uses default, the record must be at default._domainkey.yourdomain.com. If you use a custom selector like mail, the record must be at mail._domainkey.yourdomain.com. No exceptions — incorrect or missing selectors lead to immediate rejection.

Validation happens against RFC 6376, the standard for DKIM. The keys must be 2048 bits or larger, which is an industry-standard minimum for modern email security. Smaller keys (like 1024-bit) are not accepted by GMX and Web.de, even if they're technically valid under older specs.

It’s not enough to sign email headers—GMX and Web.de require both header and body to be included in the canonicalization process. If your signing setup omits the body or applies improper canonicalization (relaxed vs. simple), the signature fails. This is especially common when using tools that default to header-only signing.

For developers and admins, RFC 6376 (https://tools.ietf.org/html/rfc6376) and the DMARC.org policy guide (https://www.dmarc.org) provide the foundational specs. These documents detail how verifiers validate DKIM signatures, including selector resolution, key size, and canonicalization rules. Following them ensures compliance with all major mail providers, including GMX and Web.de.

Testing and Monitoring

It’s easy to assume your DKIM setup is correct until you see bounces or delivery failures. That’s why testing inbound mail behavior early is critical. The best way to validate is to send test emails from verified domains and check the DKIM validation status in the headers.

If something’s off, use tools like MailTester’s inbox placement tester (https://mailtester.com/inbox-tester) to simulate delivery to GMX and Web.de. It checks whether DKIM signs correctly, whether the selector resolves, and if the signature is accepted. You get a report with actionable details—no guesswork.

Pro tip: Monitor your sender reputation. Even with valid DKIM, low reputation or high spam scores can lead to delivery failures, even if your cryptographic checks pass. Use MailTester’s bulk verification (https://mailtester.com/email-list-verify) to clean lists ahead of sending and reduce risk.

Finally, once you’ve verified the DKIM setup, ensure it’s consistent across all sending systems. A mismatched selector or expired key breaks validation instantly. Treat DKIM like any other authentication layer: it only works when it’s correct, complete, and consistently applied.

How to Verify That Your DKIM and DMARC Are Configured Correctly

You need to check your DNS TXT records, use a real inbox-placement test with MailTester, and send to actual GMX or Web.de addresses to confirm your DKIM and DMARC are working. Skipping verification means you’re guessing whether inbound mail gets through or lands in spam. Let’s walk through it.

Step 1: Validate Your DNS TXT Records

Start by checking your DNS records using a tool like MxToolbox or the command-line dig. Query your domain’s TXT records for both DKIM and DMARC. For DKIM, look for the selector-specific record (e.g., default._domainkey.yourdomain.com). For DMARC, check _dmarc.yourdomain.com.

Ensure the formats match the specifications in RFC 6376 (DKIM) and RFC 7483 (DMARC). A single syntax error—like missing quotes or incorrect tags—can break authentication. You can verify this with tools like RFC 6376 and RFC 7483 to double-check the structure.

Step 2: Test Delivery with Simulated Inbound Mail

Use MailTester’s inbox-placement tool to simulate a message from a GMX or Web.de address. It checks how your mail is handled by their spam filters, authentication, and delivery pipelines in real time.

This step reveals whether DMARC policies are applied correctly. If your messages are rejected or marked spam despite valid SPF, DKIM, and DMARC, it often points to misalignment in policies (e.g., a relaxed DMARC policy set to none allowing delivery of unauthorized messages).

Step 3: Confirm with Real Recipient Testing

Once DNS and simulation checks pass, send test messages using real GMX, Web.de, and other inbox addresses. These are the only tests that confirm actual inbox placement.

Check both spam and trash folders. If delivery fails, recheck DKIM’s signing domain, DMARC alignment (SPF vs. DKIM vs. From header), and whether your sender IP is blacklisted. Common issues include inconsistent alignment or expired DKIM keys.

  1. Query your domain’s TXT records for DKIM and DMARC using MxToolbox or dig.
  2. Use MailTester’s inbox-testing tool to simulate delivery from GMX or Web.de.
  3. Send test emails to live addresses and verify they land in the inbox.
  4. Check spam and trash folders—auth failures often result in silent rejection.
  5. Review and fix alignment issues in DMARC policy or DKIM signing domains.
  6. Re-test after each change to confirm the fix.

Many businesses miss the last step: real-user testing. Simulation is useful, but only real delivery confirms whether your inbound mail policy works in practice. If you’re managing large lists, bulk verification via MailTester’s list checker helps clean up invalid addresses before sending.

Common Misconfigurations That Break GMX/Web.de Deliverability

You're likely losing emails to GMX and Web.de because of basic DNS setup errors. DKIM without a matching DNS record, misaligned SPF and DKIM, or a DMARC policy set to p=none with no reporting—these mistakes prevent inbound mail from being trusted, even if your content is clean. Most of these issues are fixed with a few minutes of DNS review, not complicated rewrites.

DKIM and SPF Alignment Errors

  • DKIM selector missing from DNS: You might have signed your email with a selector like mail3, but no DNS record exists at mail3._domainkey.yourdomain.com. Without a published key, GMX/Web.de reject the signature. Check your DNS zone manually or use a tool like MXToolbox to confirm the record is published.
  • SPF and DKIM domain mismatch: SPF lets smtp.yourdomain.com send, but DKIM uses yourdomain.com. This misalignment breaks authentication. Align both records to use the same domain or adjust the SPF include to match the DKIM domain.
  • Multiple DKIM selectors without proper routing: If you’re using more than one selector, you must publish each one in DNS. Missing records cause validation failure. Use a consistent selector strategy and monitor DNS entries regularly.

DMARC and Reporting Gaps

  • DMARC policy set to p=none with no reporting: A policy of p=none means you’re not enforcing anything. Many senders use this accidentally, allowing spurious mail to arrive without detection. Even if you’re testing, you should at least enable rua or ruf to receive reports and track inbound traffic.
  • Malformed DMARC record syntax: A missing tag, incorrect format, or syntax error (like adkim=s instead of adkim=strict) can break the entire policy. Misconfigured syntax may lead to DMARC being ignored or cause inconsistent enforcement across receivers. Use the DMARC specification as a reference when building the record.
  • Missing or inactive reporting addresses: You might set rua=mailto:[email protected], but that address isn't monitored. Reports sit undelivered, so you never see failed deliveries. Verify that reporting destinations are configured, active, and receive messages.

These aren't edge cases. They're daily issues in real mail flows. The good news? You can validate every element before sending using an inbox placement test. Test how your messages land in GMX and Web.de with MailTester’s inbox placement tool. It checks SPF, DKIM, DMARC, and inbox filtering in real time—no guesswork.

Why Bulk Email Verification with MailTester Saves Time and Reduces Rejection

You can prevent rejection from GMX and Web.de by verifying your bulk email list before sending. MailTester checks 98.9% of addresses in real-time for validity, catch-all status, domain policies, role accounts, and disposable domains—cutting down on bounces, spam complaints, and ISP blocklists before they happen. It’s like running your list through a filter that speaks the language of SMTP, DKIM, and DMARC enforcement.

Check Your List Against GMX and Web.de Policies Before You Send

GMX and Web.de enforce strict inbound mail policies, including DMARC alignment and DKIM signature validation. Sending to addresses on these domains without proper authentication can result in silent rejection or delivery failure. MailTester identifies whether an address is valid, catch-all, or blocked by policy—right down to whether it’s a role account (like admin@ or postmaster@), which are often rejected outright.

Run your bulk list through the MailTester API to detect these issues at scale. The system evaluates real-time SMTP behavior, parses DNS records (like SPF, DKIM, DMARC), and flags domains with known restrictions—such as Web.de’s refusal to accept mail from IPs on certain blocklists.

Stop Waste Before It Starts

It’s easy to send to addresses that appear valid but are actually disposable, role-based, or hosted on domains with strict inbound filtering. These types of addresses rarely reach the inbox—and they can damage your sender reputation. MailTester detects these risks before you send, so you don’t waste credits or strain your sending infrastructure.

For example, many disposable email providers automatically block inbound mail from transactional senders, and some domains (including certain corporate or government ones) enforce strict authentication. By filtering them out during list hygiene, you reduce the number of hard bounces and improve long-term deliverability. This is especially important when sending to European markets, where GDPR and domain-based policies like DMARC are enforced more rigorously.

Use MailTester’s bulk verification to clean lists quickly, then test inbox placement with our inbox tester to confirm delivery. With no expiration on purchased credits and a 98.9% accuracy rate, you gain visibility into real-world domain behavior—without guesswork.

Learn more about email authentication standards at RFC 6376 (DKIM) and RFC 7489 (DMARC), the foundational specs behind how domains like GMX and Web.de evaluate sender trust.

Conclude: Ensure Deliverability by Complying with GMX and Web.de Inbound Standards

GMX and Web.de enforce DKIM and DMARC with strict precision. Messages without valid, aligned signatures are blocked—no exceptions.

Ensure your sending domains are verified, DKIM signatures are correctly configured, and DMARC policies are set to reject or quarantine non-compliant mail. This protects your sender reputation and maintains inbox placement.

Proactively test your setup before sending to high-risk domains. MailTester’s real-time verification tools expose flaws early—before bounces or blacklisting happen.

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Does GMX require DKIM for inbound email?

Yes—GMX enforces DKIM signatures on inbound mail. Messages without a valid DKIM signature are rejected.

What is Web.de’s DMARC handling policy?

Web.de applies strict DMARC enforcement. Messages failing alignment or authentication are rejected if the policy is set to 'reject'.

Can I send emails to GMX/Web.de addresses without DKIM?

No—GMX and Web.de require DKIM and DMARC compliance. Without them, inbound messages are rejected.

How do I test if my domain is compliant with GMX/Web.de?

Use MailTester’s inbox-placement testing to simulate delivery from a GMX or Web.de address and check authentication status.

What does 'catch-all' mean in the context of GMX and Web.de?

A catch-all address accepts all incoming mail, even for non-existent users. GMX and Web.de do not accept mail to such addresses unless explicitly allowed.

Can role-based email addresses like info@ or support@ be delivered to GMX/Web.de?

Only if the receiving domain specifically accepts them. Both GMX and Web.de typically reject mail to role-based addresses unless approved by their policy.

How often should I recheck my DKIM and DMARC configurations?

At least monthly, or after any change to email infrastructure, DNS records, or signing keys.

What happens if my DKIM signature fails validation from GMX?

The message is rejected at SMTP level with a permanent failure code, usually '550 5.7.1 Message rejected due to authentication failure'.

Can MailTester detect if an email address is on a disposable domain?

Yes—MailTester identifies disposable domains and marks them as invalid or risky, helping you avoid delivery issues.

What is the accuracy of Email Verification for GMX and Web.de domains?

MailTester’s verification accuracy is 98.9%, including detection of domain-level policies, catch-all status, and authentication requirements.

Do Web.de and GMX allow messages to be sent from non-approved subdomains?

No—only domains with valid SPF, DKIM, and DMARC policies that align with the sending source are allowed to deliver.

Is there a way to test deliverability without sending real emails?

Yes—MailTester offers inbox-placement testing that simulates delivery without sending outbound messages.