Email Delivery

[AllenS81]

Folks,

I run a global online community and we are finding some of our users are not getting emails, this seems to only be happening when the recipient is using Ciscos Secure Email Gateway solution. 
I have submitted a sample of our emails to the not_ads email address but is there anyone else who can help us figure out whats going on?

Our logs show the email gets sent to the email relay but the user either never receives it or it gets pushed to the quarantine.. How can I get some help to resolve this? 

[Ken Stieers]

Is your domain new (1st registered in the past 30 days)? If so, you just have to wait it out until the 30 days is up.

Go to talosintelligence.com, check the reputation of ips and domain. If bad fix what caused that (spam? Virus? Phisy mail?) and then put in a reputation ticket ( you need a Cisco.com account. Its free)

Do you have spf, dkim, dmarc in place?

[AllenS81]

Hi Ken,

Thanks we already checked talosintelligence and it says our domains are trusted and not blocked. Yes we have SPF and DKIM setup.

What is interesting is that the cisco community here uses the same community platform and also uses DKIMs so I am thinking someone in the admin team might have some clue here

Interesting our email is sent via this IP: 20.51.98.61 which has a neutral rating

[AllenS81]

So its looking like the source of our problem maybe because Cisco Secure Email Gateway is doing a domain lookup on the sender domain. Since the domain doesn't actually resolve (its only used to send email) there is no a record. So I think I need an MX record, which feels a bit odd since you can't actually email our community domain either.

Does this ring true with anyone? 

The MX Record - does it need to resolve to the IP of the sending server or the ip of the domain of the from address? (these are different)

[Ken Stieers]

Yes...

Typically the sending system would have a name on the interface/ip,.which it may use to announce itself when it connects. That name should have an A record and a PTR record that matched and a cert that matched the name.

It doesn't have to match the domain you're sending as, but it needs to be in your SPF record and signing with the right dkim cert / selector.

[AllenS81]

So for this community they have the same SPF we do:

Type	Domain Name	TTL	Record
TXT	community-email.cisco.com	600	v=spf1 include:us.khoros-mail.com -all

Obviously ours has our domain in the domain column, however neither cisco nor us have a PTR record or an a record on the domain.. But ours is being bounced by any Cisco Secure Email Gateway as with the error "Domain of sender address <sender email address> does not exist (in reply to MAIL FROM command)"

Now I am guessing the Cisco community team have resolved this as they wouldn't want their community email getting bounced and the only difference I can see is we don't have an MX Record, NS Record or a SOA Record (although I believe the SOA will pull from our parent domain when not specified on the sub-domain.

[charella]

AllenS81,

You wrote:
So for this community they have the same SPF we do:
Type
Domain Name
TTL
Record
TXT
community-email.cisco.com
600
v=spf1 include:us.khoros-mail.com -all
Obviously ours has our domain in the domain column, however neither cisco nor us have a PTR record or an a record on the domain.. But ours is being bounced by any Cisco Secure Email Gateway as with the error "Domain of sender address does not exist (in reply to MAIL FROM command)"
------------ checking the ptr thing…
Looking at a header from the cisco community mail, the ip has a ptr.
Received: from outbound-dkim.us.khoros-mail.com ([34.218.116.3])
by alln-inbound-g.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2024 08:02:15 +0000

dig -x 34.218.116.3
3.116.218.34.in-addr.arpa. 1800 IN PTR outbound-dkim.us.khoros-mail.com.

That is a big deal with Talos if we ever submit a question about why a customer is failing the first thing they check is ptr.

2nd thought, do you have Dmarc? dmarc is becoming more prevalent along with spf and dkim.
Gmail is the big boss in that area. They’ve started enforcing it causing the industry to join in… (opinion).

3rd thought – some destination domains may take actions based on the encrypted payload as it’s unscannable.

4th CRES Specific
if you reply to an encrypted message or if you compose an encrypted message from websafe , https://res.cisco.com/websafe . Then you you need to add res.cissco.com ip to your spf.
https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118689-technote-esa-00.html

This is a better explanation than the article link.

The encrypted email will come from the ESA. the ESA will encrypt the email, and connect to res.cisco.com via port 443 to share the token information with CRES. The recipient will receive a normal email, with an encrypted payload. When the recipient tries to open the email, the encrypted payload knows to reach out to CRES to retrieve the token the ESA shared with it, the 'key' if you will.



Once the recipient logs in to CRES, the systems will use the 'key' to unlock the email.



At this point, the recipient may choose to reply to the email. This email will NOT originate at the customer's network (even if they have an ESA). the email will be encrypted by CRES and delivered by CRES directly back to the original sender's domains.



Thank you,

Chris A

[AllenS81]

Hi all,

@charella Thanks yes we have DMARC already. Your question made me go back and check a few things through so let me share what I found:

• Not having a valid MX record was resulting in some Cisco Secure Email Gateway instances hard bouncing the mail due to being unable to resolve the sender domain, some instances were merely quarantining it.
• When reviewing the headers again, I discovered our email server was not setting a return path for our email which is clearly an issue as thats required by ITEF.

I think we have now solved this, even if no one answer above is 100% the right answer and I would like to thank everyone who contributed to the discussion!

[charella]

AllenS81
That’s great news! Narrowing down the ocean of possibilities to a bucket helps us find it better.
Kudos to the forum especially KEN S.