weird dns error message after moving to cloudflare. - ORF Forums

weird dns error message after moving to cloudflare. RSS Back to forum


Error checking the SPF policy of domain "": The requested A/MX record was not found for "".

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) , , ,

I also used public spf checking tools and it locates my spf records correctly.

by christopher.low 4 years ago

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.

by christopher.low 4 years ago

@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 instead of company.local internal + external, etc.) the DNS server will act authoritative for the 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 and, both names should resolve to an IP using DNS A records. Our SPF Policy Tester can give you a detailed evaluation log (, 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 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.

by Péter Karsai (Vamsoft) 4 years ago
(in reply to this post)


yeah. the AD is (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 which is visible both external and internal.

the priority 20 one is one set for microsoft office 365. which is nonexistent. (i'm not sure why. a vendor set it up for me.) so it could be this record causing the error.

by christopher.low 4 years ago

@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.

by christopher.low 4 years ago
(in reply to this post)


@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.

by Péter Karsai (Vamsoft) 4 years ago
(in reply to this post)


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 "": The requested A/MX record was not found for "".

Does that mean spf is not checked at all for this guy?

there is a spf record
v=spf1 ip4: -all

with an A record for IN A

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 ?

by christopher.low 4 years ago

@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 "" 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.

by Péter Karsai (Vamsoft) 4 years ago
(in reply to this post)

New comment

Fill in the form below to add a new comment. All fields are required. If you are a registered user on our site, please sign in first.

It will not be published.
hnp1 | hnp2