e-mails getting rejected - Page 3

TenFour · 27 Mar 2023, 09:48 PM

Your domain is requesting these DMARC reports and apparently your email address is listed as the one to send the reports to.

Quote:

DMARC reports are usually sent once a day by email. They're sent to the email addresses you specify when you define your DMARC record. If reports are turned on with the rua DMARC record tag in your DMARC record, every server that receives mail from your domain sends a report.

https://support.google.com/a/answer/10032472?

TenFour · 27 Mar 2023, 10:12 PM

Use the MX Toolbox and select the DMARC tool to see what email addresses are set for the account.

https://mxtoolbox.com/SuperTool.aspx

DougLass · 27 Mar 2023, 10:17 PM

The issue isn't what e-mail is getting these messages. The issue is why these messages seem to be implying that my SPF is failing, when everyone else says my SPF is fine. Mxtoolbox says my DMARC Quarantine/Reject policy is not enabled, which I don't believe is a "fail" kind of fault. Everything else checks out. I should add that maybe I'm getting a report from Google because as of a week ago, my rua was set properly. It wasn't before.

DougLass · 27 Mar 2023, 11:01 PM

So here's a sigh-ful fact. When I do a blacklist check on my domain at mxtoolbox.com, it comes out entirely clean,in some twenty-odd lists EXCEPT for a listing at UCEPROTECT. I get on the line to Hostgator support (it's their domain), and they point me to https://www.inmotionhosting.com/supp...tect-rbl-scam/. So UCEPROTECT is crapola. Sheesh!

SideshowBob · 28 Mar 2023, 03:33 AM

Quote:

Originally Posted by DougLass

Um, some of my recipients have Comcast e-mails, which is why I might be getting this message from Comcast, but no, that doesn't have anything to do with an SPF failure. SPF is about authorization, and sending to Comcast doesn't invalidate anyone's authorization records.

It's not about the email you sent to Comcast, it's about the email that ended-up at Comcast after being sent elsewhere.

Have you actually established that: <source_ip>xxx.x.xxx.xxx</source_ip> in the Comcast report is in your SPF record?

DougLass · 28 Mar 2023, 05:11 AM

Quote:

Originally Posted by SideshowBob

Have you actually established that: <source_ip>xxx.x.xxx.xxx</source_ip> in the Comcast report is in your SPF record?

Good question. The xml from Comcast has my IP. Curiously, the xml from google does not. It has an IP I've never seen before, appears to be some scam IP, and might belong to Amazon.

DougLass · 28 Mar 2023, 10:51 PM

OK, the plot thickens. I have now just received four new DMAC reports (all xml, all unreadable in a modern browser). They are from
google (sent my dmarcsupport@google.com
aol.com (sent by dmarc.yahoo.com)
yahoo.com (sent by dmarc.yahoo.com)
verizon.com (sent by dmarc.yahoo.com)

All of them specifically refer to my domain, as well as the sendersrv.com website which is the host of my e-mail listserve provider (Sender) and also point to "source IP's" that are ones I've never heard of. My own IP is not listed anywhere in these.

Looking at thiese xml files in a terminal window, it's hard to translate them, but <spf>fail</spf> is seen frequently, and also a few passes. Everything else is a pass (dkim, stmp, etc.)

I'm pretty sure I'm getting all these because now my DKIM has a functional rua. It didn't before.

BUT I DON'T UNDERSTAND THEM! I don't know what they're trying to tell me! Are they reporting that everything is fine or are they trying to tell me what is wrong? These are DMARC Aggregate Feedback reports, but I'm not sure exactly what information I'm being fed.

TenFour · 28 Mar 2023, 11:04 PM

DMARC Report Analyzer. You can upload the XML file there. https://mxtoolbox.com/DmarcReportAnalyzer.aspx

DougLass · 28 Mar 2023, 11:14 PM

Now, this is interesting. I was told above to go to the "DMARC XML to Human Converter" which sounded intriguing. That didn't accept my original Comcast reports the other day. But it IS accepting these. I am told therin for all of these reports that my "SPF Alignment" is 0%. SPF Alignment error, they say, is where "the domain provided for SPF authentication must match the From header domain". I don't understand what that means. Up above, in post #14, I relayed my SPF. Both Hostgator and Sender say that SPF is exactly right. These reports are saying it isn't.

OK, I did the DMARC Report Analyzer, and it gives a table for each of the anonymous IPs referred to in these reports. For the Google report, my SPF and DKIM "passes" entirely for my own IP, 114 times. It fails like, once, for some of the other anonymous IPs. I get a "DMARC compliance" rating of 98.41%. But what am I supposed to do with this?

So confusing.

I am trying to understand why my Sender e-mails are getting Junked by many servers. How does this DMARC report analysis bear on that?

Avion · 28 Mar 2023, 11:30 PM

Look at it this way:

The correct DMARC should report that e-mails that you are sending meet all the criteria.

Anything else, and it should report as a failure as part or all of the criteria.

That means your DMARC record is working as intended.

DougLass · 28 Mar 2023, 11:38 PM

Thank you. So that means all of these reports are unrelated to my issue of non-deliverability for many e-mail servers. My suspicion, as I said before, is that my IP, as assigned to me by Sender, was ONCE a spam IP. It isn't blacklisted anymore. But Office 365 servers just haven't realized that yet.

TenFour · 29 Mar 2023, 12:09 AM

In my experience delivery to Outlook/Microsoft 365 addresses is always problematic. There appears to be no way to guarantee delivery.

DougLass · 29 Mar 2023, 12:12 AM

Yes, I think I've heard that. Unfortunately, many large companies and agencies rely on Outlook and deploy it throughout their organization, and are beholden to Office 365 spam police. The funny thing is, there appears to be NO WAY to communicate with those spam police. Escalation in the Office 365 Anti-Spam IP Delist Portal does NOTHING.

JeremyNicoll · 29 Mar 2023, 06:47 AM

Quote:

Originally Posted by DougLass

... The xml report from the Comcast DMARC Report Generator uploads to Dmarcian with an "Invalid XML File" error. For what it's worth, that xml file strangely can't be opened in a modern browser, because it doesn't have any style information associated with it. Somewhat of a defective file, I guess.

I don't think so. There doesn't have to be either style data or a definition of what is legitimate syntactically in an XML file (a DTD definition) for it to be useful.

It's irrelevant to your problem, but if I c&p one of your examples, eg

Code:

<row>
<source_ip>xxx.x.xxx.xxx</source_ip>
<count>3</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>

into a file then drag that into a Firefox browser tab, it displays as well as I'd expect, which is to say that it shows the nested aspect of the tags with indented lines, and uses colour to differentiate between tags like <dkim> and its ending tag </dkim>, and the value sandwiched between them.

I've done the same with some XML data files from various applications installed here and for some of them there's a little more colouring, eg when tags have named attributes like <section id="one"> then "id" is in a different colour from "section" and "one" is in a third colour,

I am curious what else you'd expect to see.

As far as I understand it, XML used like this is just a way for programmes to pass data around in a relatively-easily parsable manner; a program can ask for, for example, the contents of each "<row>" in a file, or the <dkim> element in the 17th <row> and it's up to the XML parsing code to return the right subset of the whole data.

It's different if you want to pass data that relates to some specific international programming standard around. Then there'd also be a DTD (and the XML file would - much as modern HTML pages usually do - start by saying which DTD it uses). The DTD describes to the parser which tags can appear inside which other tags; which ones are required, which optional, and what attributes they can contain. It also describes what sorts of values can be sandwiched between all these tags and what's valid for an attribute value - eg only integers, or a quoted name or eg a literal like "pass" or "fail" ... so that any parser anywhere can decide if a specific file is syntactically correct or not before allowing it to be used.

As far as I understand it, stylesheets are used to describe how data that's represented by an XML file might be manipulated (eg turning it into a more-readable PDF).

I don't think that having a browser tell you that a file contains no reference to a stylesheet means the file is invalid; I think it's just adjusting your expectations to what it is able to show you.

DougLass · 29 Mar 2023, 07:06 AM

Well, xml files are *supposed* to be openable in a modern browser. When you try to do that with these, what I reported is the complaint that you get from the browser. But of course, what you would see if you DID open it in a browser would be just a prettified version of what you see with a text editor. You wouldn't have any more information about what you're seeing. That's where the DMARC XML to Human Converter and DMARC Report Analyzer come into play. Those apps add some real detail to the problem.

27 Mar 2023, 10:17 PM	#33
DougLass Member Join Date: May 2014 Posts: 56	The issue isn't what e-mail is getting these messages. The issue is why these messages seem to be implying that my SPF is failing, when everyone else says my SPF is fine. Mxtoolbox says my DMARC Quarantine/Reject policy is not enabled, which I don't believe is a "fail" kind of fault. Everything else checks out. I should add that maybe I'm getting a report from Google because as of a week ago, my rua was set properly. It wasn't before. Last edited by DougLass : 27 Mar 2023 at 10:45 PM.

27 Mar 2023, 11:01 PM	#34
DougLass Member Join Date: May 2014 Posts: 56	So here's a sigh-ful fact. When I do a blacklist check on my domain at mxtoolbox.com, it comes out entirely clean,in some twenty-odd lists EXCEPT for a listing at UCEPROTECT. I get on the line to Hostgator support (it's their domain), and they point me to https://www.inmotionhosting.com/supp...tect-rbl-scam/. So UCEPROTECT is crapola. Sheesh! Last edited by DougLass : 28 Mar 2023 at 12:28 AM.

27 Mar 2023, 10:12 PM	#32
TenFour Master of the @ Join Date: Feb 2017 Location: USA Posts: 1,722	Use the MX Toolbox and select the DMARC tool to see what email addresses are set for the account. https://mxtoolbox.com/SuperTool.aspx

28 Mar 2023, 10:51 PM	#37
DougLass Member Join Date: May 2014 Posts: 56	OK, the plot thickens. I have now just received four new DMAC reports (all xml, all unreadable in a modern browser). They are from google (sent my dmarcsupport@google.com aol.com (sent by dmarc.yahoo.com) yahoo.com (sent by dmarc.yahoo.com) verizon.com (sent by dmarc.yahoo.com) All of them specifically refer to my domain, as well as the sendersrv.com website which is the host of my e-mail listserve provider (Sender) and also point to "source IP's" that are ones I've never heard of. My own IP is not listed anywhere in these. Looking at thiese xml files in a terminal window, it's hard to translate them, but <spf>fail</spf> is seen frequently, and also a few passes. Everything else is a pass (dkim, stmp, etc.) I'm pretty sure I'm getting all these because now my DKIM has a functional rua. It didn't before. BUT I DON'T UNDERSTAND THEM! I don't know what they're trying to tell me! Are they reporting that everything is fine or are they trying to tell me what is wrong? These are DMARC Aggregate Feedback reports, but I'm not sure exactly what information I'm being fed.

28 Mar 2023, 11:04 PM	#38
TenFour Master of the @ Join Date: Feb 2017 Location: USA Posts: 1,722	DMARC Report Analyzer. You can upload the XML file there. https://mxtoolbox.com/DmarcReportAnalyzer.aspx

28 Mar 2023, 11:14 PM	#39
DougLass Member Join Date: May 2014 Posts: 56	Now, this is interesting. I was told above to go to the "DMARC XML to Human Converter" which sounded intriguing. That didn't accept my original Comcast reports the other day. But it IS accepting these. I am told therin for all of these reports that my "SPF Alignment" is 0%. SPF Alignment error, they say, is where "the domain provided for SPF authentication must match the From header domain". I don't understand what that means. Up above, in post #14, I relayed my SPF. Both Hostgator and Sender say that SPF is exactly right. These reports are saying it isn't. OK, I did the DMARC Report Analyzer, and it gives a table for each of the anonymous IPs referred to in these reports. For the Google report, my SPF and DKIM "passes" entirely for my own IP, 114 times. It fails like, once, for some of the other anonymous IPs. I get a "DMARC compliance" rating of 98.41%. But what am I supposed to do with this? So confusing. I am trying to understand why my Sender e-mails are getting Junked by many servers. How does this DMARC report analysis bear on that?

28 Mar 2023, 11:30 PM	#40
Avion Member Join Date: Sep 2022 Posts: 67	Look at it this way: The correct DMARC should report that e-mails that you are sending meet all the criteria. Anything else, and it should report as a failure as part or all of the criteria. That means your DMARC record is working as intended.

28 Mar 2023, 11:38 PM	#41
DougLass Member Join Date: May 2014 Posts: 56	Thank you. So that means all of these reports are unrelated to my issue of non-deliverability for many e-mail servers. My suspicion, as I said before, is that my IP, as assigned to me by Sender, was ONCE a spam IP. It isn't blacklisted anymore. But Office 365 servers just haven't realized that yet.

29 Mar 2023, 12:09 AM	#42
TenFour Master of the @ Join Date: Feb 2017 Location: USA Posts: 1,722	In my experience delivery to Outlook/Microsoft 365 addresses is always problematic. There appears to be no way to guarantee delivery.

29 Mar 2023, 12:12 AM	#43
DougLass Member Join Date: May 2014 Posts: 56	Yes, I think I've heard that. Unfortunately, many large companies and agencies rely on Outlook and deploy it throughout their organization, and are beholden to Office 365 spam police. The funny thing is, there appears to be NO WAY to communicate with those spam police. Escalation in the Office 365 Anti-Spam IP Delist Portal does NOTHING.

29 Mar 2023, 07:06 AM	#45
DougLass Member Join Date: May 2014 Posts: 56	Well, xml files are supposed to be openable in a modern browser. When you try to do that with these, what I reported is the complaint that you get from the browser. But of course, what you would see if you DID open it in a browser would be just a prettified version of what you see with a text editor. You wouldn't have any more information about what you're seeing. That's where the DMARC XML to Human Converter and DMARC Report Analyzer come into play. Those apps add some real detail to the problem.