SG not receiving e-mail

[notmysgusername1]

We have the thread about SG not being able to send e-mail to various providers here, and that seems unresolved.

I'm talking about a different delivery issue -- the remote party is not delivering to SG. I've been seeing this more and more recently. When I provide an @spamgourmet.com address to various services, I get nothing from them:
- nin-nin-game.com
- solarisjapan.com
- staples.com
- upsstore.com
- various airlines(!!!)
- wyz.com orders

Their support e-mails through Zendesk, when I'm asking them for information that I've missed, always arrive. It seems like another delivery issue with the Spamgourmet domains, and I never know if a SG address that I use now will be accepted or not. Note that this isn't "You've used all 20 e-mails and so they're being eaten" -- the address doesn't show up in the last-three-eaten list, and doesn't show up in my SG history at all if I search for it. It's not just @spamgourmet.com, but the other domains that I've tried as well.

Is DANE still a work-in-progress? I'm assuming that other mail hosts are requiring it even just to deliver e-mail. I really don't know.

[notmysgusername1]

Adding to that list, more companies that I'm not receiving e-mail from at spamgourmet,

- turtle-divers.com (via an @yahoo.com e-mail address, I think)
- padi.com (or whatever they use to send e-mail)
- airasia.com
- airwallet.com

there are others, I just haven't been writing them down.

[adb]

To make it clear:

Are you taking about not recieving emails from that domain
Or recieving answers to replys made on your spamgourmet-adresses?

I checked several of my email-providers:
1. Sending a mail from one of my provider-adreesses to one of my spamgourmet-adresses
2. The mail came in
3. I repy to that mail
4. I dont geht that repy to my Spamgourmet-adress. It seems that it never reached spamgourmet because the spamgourmet-counter is not updated.

[notmysgusername1]

It seems that it never reached spamgourmet because the spamgourmet-counter is not updated.

That sums it up. Another provider is the Steward Medical Group patient portal *support* system. I give them my e-mail, they accept it, and .... I never get a response. I call them, I verify the e-mail, they say that they sent a response, and nothing. The same with various online stores. Places that verify your identity in person, or while accepting payments, so they have no need to restrict where response e-mails go.

With a business card place, I placed an order, got the shopping cart e-mail, and thought that was that. Eventually time was running out for a deadline, and I e-mailed them (from my spamgourmet e-mail), and asked them to cancel the order. The order was cancelled, and I never got any response from them. E-mail *to* them obviously worked, and I think they e-mailed a question originally but got no response, suggesting that e-mail *from* them was getting caught in some problem communicating with spamgourmet.

In these cases, the alias is never even created in Spamgourmet, or if it exists, it doesn't decrement the remaining count. In one case, the upsstore address, e-mails stopped arriving in January 2023, with 16 remaining. I verified with them, in person, that the e-mail hadn't been changed in their system, and I did not receive any e-mails from them. I changed my e-mail to something else in July, and behold, I'm getting e-mails from their system again.

There are many services that don't/can't send e-mails to Spamgourmet addresses (any more), and I've been using temporary mail service providers to sign up to them, or even place orders. (Alternatively I can use another permanent webmail provider, like mail 2 world -- which I hope doesn't go offline soon..) I feel like this largely started happening around January 2023, when it started happening the other-way-around with Proton. For things like shopping carts, I haven't been able to get anyone to look at mail server logs - if even these places have their own mail servers. Calling Citi Bank, they won't accept a spamgourmet address - they say, in person, that it says it's "invalid". (I signed up with Citi using an SG address long ago, and around the start of 2023 they started sending me mail, "We sent you an e-mail and it was returned." Or similar.)

[notmysgusername1]

The simplest check, an MX server checker (https://mxtoolbox.com/SuperTool.aspx?ac ... n=toolpage) -- "No DMARC record found; no DMARC policy found" - suggests that _receiving_ e-mail sometimes requires DMARC as well.

[lwc]

The simplest check, an MX server checker (https://mxtoolbox.com/SuperTool.aspx?ac ... n=toolpage) -- "No DMARC record found; no DMARC policy found" - suggests that _receiving_ e-mail sometimes requires DMARC as well.

That belongs to DMARC brainstorming and already reported at GitHub.

[adb]

is there anything going on in development of spamgourmet at the moment?
The new things on github seems to be 2 years old ...

[notmysgusername1]

It seems like the problem isn't as straight-forward as simply DMARC.

Signing up for neokyo.com, I didn't get a sign-up e-mail at SG. No alias was even created for it.

However, signing up with neokyo@<user>.33mail.com, the sign-up e-mail came through.

Looking at mxtoolbox again,
- https://mxtoolbox.com/SuperTool.aspx?ac ... n=toolpage
- https://mxtoolbox.com/SuperTool.aspx?ac ... n=toolpage
(and my username.33mail.com), the DMARC status of Spamgourmet and 33mail are the same. So it seems to not be DMARC that's preventing e-mails from being received.