weird dns error message after moving to cloudflare. RSS Back to forum
the email is a copy from a shared namespace domain split between office365 and self hosted. it originates from microsoft side then into my hosted exchange as a journal archive, which is why it goes through orf.
@christopher.low:
Hello,
Can you please contact us at and send us the domain name in question? This may help us to understand this issue.
In any case, here are a couple of things to check:
* Make sure that the DNS servers used by ORF see the same view of the DNS data as the external world. For instance, if your AD domain is the same as the external domain (e.g. both are company.com instead of company.local internal + company.com external, etc.) the DNS server will act authoritative for the company.com zone and may serve a different view for internal clients like ORF.
* For the MX mechanism, you not only need an MX record for the argument domain, but all of the MX names must have an A RR. For instance, if you have two MXs like mail1.company.com and mail2.company.com, both names should resolve to an IP using DNS A records. Our SPF Policy Tester can give you a detailed evaluation log (http://vamsoft.com/support/tools/spf-policy-tester), based on the external view of the DNS.
Also, this is unrelated to the above, but using Google Public DNS or ISP DNS servers for ORF is discouraged (see http://vamsoft.com/support/docs/how-tos/deployment-5.3#dns-compliance on DNS settings). This if for a number of reasons, but most importantly they aggregate traffic from many DNS clients and may get banned by DNSBL/SURBL operators for violating free use policies.
yeah. the AD is company.com (same as external) but both has identical spf records. in anycase, orf isn't using the internal .
for the mx records. I have 2. the priority 10 one points to mydomain.com.sg which is visible both external and internal.
the priority 20 one is one set for microsoft office 365. ms65233774.msv1.invalid.outlook.com which is nonexistent. (i'm not sure why. a vendor set it up for me.) so it could be this record causing the error.
@christopher.low:
I'm deleting that mx 20 record. it seems its only for domain ownership validation purposes during office 365 setup. its not necessary now. Let me see if the error persists after 24hours.
https://support.office.com/en-sg/article/Change-nameservers-to-set-up-Office-365-with-any-domain-registrar-a8b487a9-2a45-4581-9dc4-5d28a47010a2?ui=en-US&;rs=en-SG&ad=SG
@christopher.low: Thank you, it is very likely that it was the non-existent backup MX that caused the issue. Thank you for sharing the KB article on this.
ok. the check against my domain succeeds now. so it should be the case of the extra mx record
however, I notice this spammers domain have an error.
Error checking the SPF policy of domain "aventislearning.com.sg": The requested A/MX record was not found for "mail.aventislearning.com.sg".
Does that mean spf is not checked at all for this guy?
there is a spf record
v=spf1 ip4:113.197.37.61 mx:mail.aventislearning.com.sg -all
with an A record for
mail.aventislearning.com.sg IN A 113.197.37.61
and no extra mx records anywhere , so I'm not too sure what's going on
---
a) are you checking too strict spf rules for correctness then not performing the spf test if it doesn't have certain values? perhaps it should count a spf softfail ?
@christopher.low:
Hello,
The MX SPF mechanism matches if the IP address matches with any of the hosts listed in the MX record of the argument domain. The domain "mail.aventislearning.com.sg" lacks an MX record, so this statement cannot be evaluated and hence this error.
The original RFC draft implemented by ORF wasn't overly specific about error handling and we decided to treat any policy evaluation errors as cause for ignoring the policy. The argument was, and still is, is that nobody sets up a flawed policy intentionally, so making decisions based on such policy is guaranteed to lead to unexpected consequences, very likely against the intention of the policy publisher. "Garbage in and garbage out" situations are best avoided if we have to full means to validate the input data.
The latest SPF RFC (which ORF will implement in the next version) is very specific about error handling. DNS errors like this are allowed up to 2 times during the evaluation. Exceeding this limit will cause the evaluation to fail with PermError, which is pretty much the same as what ORF does currently.
Error checking the SPF policy of domain "mydomain.com": The requested A/MX record was not found for "mydomain.com".
this error happens for internal mail messages (ie: from ).
it however doesn't look like a "too many dns lookup" issue since other mails are just fine with spf checks
my local internal dns also has a txt entry that gives the right spf values.
I checked that orf is using dns servers (google + level 1 i think)
208.67.220.220 , 208.67.222.222 , 8.8.8.8 , 8.8.4.4
I also used public spf checking tools and it locates my spf records correctly.