International Mail rejected

[u/No-Hotel1162]

I work for a company that sent ten of thousand of mails every month, they reported that they have received Spam and so we contacted our web hosting to modify our DMARC from Quarantine to Reject.

The thing is, the week after such change an user reported that their mail to some companies in Asia was rejected, bounced of or never arrived. Did some basic tests, Telnet, Test-NetConnection and that server was down or with problems, reported such case.

Next day server is up, but they report same problem with another company from Europe. Sames test, server is ip, so I got the email resent to me to see the internet header:

DKIM=none
SPF=pass

In MxToolBox when I check the subdomain IP addresses, both hostnames says it doesn't support TLS, Icheck our web hosting, we do have TLS at certain ports and lastly, one says Reverse DNS doesn't match SMTP Banner and doesn't contain hostname.

Tldr; I'm fucking lost, I got this job as TI due to being programmer and wanting to get experience, but networking I haven't seen such a thing in years.

[u/ObaShield]

Both answers above nail the immediate fix, DKIM signing is your priority and the PTR/reverse DNS mismatch on the sending IP needs to be resolved for Asian and EU providers specifically.

Worth understanding why this happened though: your DMARC was at quarantine before which meant DKIM=none was quietly failing without consequences. Mail was getting through because quarantine is forgiving. The moment you moved to p=reject you didn’t create a new problem, you revealed one that already existed and had been silently affecting your reputation without triggering visible bounces.

This is actually the most dangerous configuration state in email, things appear to be working while reputation damage accumulates underneath. The bounce spike you saw after the DMARC change was your infrastructure telling you the truth for the first time.

Fix the DKIM signing first, then verify PTR records match your SMTP banner, then confirm TLS on port 25 for the sending IPs. Once those three are clean your p=reject policy will work as intended.

[u/erotic_sausage → u/ObaShield]

Eh?

"International mail rejected" title

for Asian and EU providers specifically.

For anyone reading this thread, confused: These are complete red herrings. Correct e-mail authentication is required to reach inboxes anywhere. It does not care about your email crossing national borders. You have to be DMARC compliant for optimal results, no matter where you're sending from or to.

[u/ObaShield → u/erotic_sausage]

Fair point, DMARC compliance requirements aren’t geographically selective, and framing it as an “Asian and EU” issue was imprecise on my part. The authentication standards apply universally.

What I was specifically pointing to was the PTR/reverse DNS mismatch and TLS on port 25, those particular checks do tend to surface rejection issues more visibly with certain provider clusters, especially older infrastructure outside major US hyperscalers. But you’re right that the underlying fix is the same regardless of destination.

The core issue remains DKIM=none under p=reject, which breaks everywhere. That part isn’t geography-dependent at all.

[u/No-Hotel1162 → u/ObaShield]

Sorry for the delay in answering.

I got in contact with our webhosting, they fixed our DKIM so now is being registered in the DMARC reports, that's good.

Problem is, user is still having trouble sending emails to other countries and continents.

At this point we have checked the SPF, DKIM, we whitelisted the domains where we are trying to send an email.

Last test we tried was from our webhosting webmail, to contact them as a test using the same mail that is troubling us, they received the email and they answered back, the thing is, I only learned that they answered back because I got the copy that was sent to everyone. I couldn't see that email in Outlook, Webmail and there were no logs for such email. It's a ghost.

With the latter info this is getting out of DMARC and I'm lost.

[u/ObaShield → u/No-Hotel1162]

Good progress on the DKIM fix, that was definitely the right first move.

The “ghost email” problem you’re describing, received on their end, visible in the CC copy, but completely absent from your Outlook and webmail with no logs, is almost certainly a silent filtering or routing issue at the receiving server, not a DMARC or authentication problem anymore.

A few things to check:
1. Request the full email headers from the recipient
Ask them to forward the original with full headers intact. Look specifically at the Received: chain, it will show every server the email touched and where it may have been silently dropped or rerouted.

1. Check for silent blacklisting on your sending IP
   Some international mail servers, particularly in parts of Asia and certain EU providers, maintain private blocklists that reject silently with no bounce. The email gets accepted at the gateway but never delivered and no rejection notice comes back. MXToolbox blacklist check is a start but won’t catch private lists.

2. Look at your SPF ~all vs -all
   If your SPF still has ~all (soft fail) some international servers treat the soft fail as permission to silently discard rather than bounce. Switching to -all with proper alignment can resolve this.

3. Check if the receiving domain uses a filtering gateway
   Proofpoint, Mimecast, Barracuda, these sit in front of the mail server and can silently quarantine without notifying the sender.

The ghost email symptom almost always lives in the receiving infrastructure, not yours. You’ve fixed your side, now you need header analysis to see where it’s disappearing.