Help with SPF rejection
Question asked by Merle Wait - 3/29/2024 at 8:08 AM
We domain xyz  ... it is among about 50 other domains that we do processing for.
Only on xyz domain are we having this issue.

Issue: Rejecting at various receiving sites because of spf frame work.
Yes, we have checked to make sure the spf framework in our DNS matches.  It does

So what else could be causing this???  
I do notice that in the emails going out, for this client.. that their iP address is still there...
{but then that is true for all of other clients too}  could this be the cause?? I know there is some where in smartermail to exclude that. .but can not remember where... Other than that.. I am at a loss

Any and all suggestions are welcomed

8 Replies

Reply to Thread
John Quest Replied
Well, unless we can see the actual errors, it is hard to guess. Obviously, there is a problem with either the DNS records or how the emails are being sent. 
Douglas Foster Replied
SPF has nothing to do with the message body.  It uses the received SMTP Mail From domain to do a DNS query, then looks for the submitting IP address in the policy record 

Use mxtoolbox.com to check the SPF record.  Supertool syntax is 
SPF:domain name:ipaddress
Merle Wait Replied
Here is the spf: - which checks fine:domain=creativestitchesinc.com
v=spf1 ip4: ip4: ip4: ip4: ip4: mx:ebt.net mx:enter-link.net
Reject; message from receiving application: Remote Server returned: '550 5.7.0 Message rejected per SPF policy'

These are the Message headers we see... when we capture from a different receiving domain (not on our network).

Received: from XXXXXDesktop (2XXX-XXX-216-26.static.logixcom.net 
[XXX.XXX.XXX.26]) by mail.ebt.net with SMTP;
   Fri, 29 Mar 2024 09:53:00 -0500

Received: from  (gateway.ebt.net. [])
Will get another set of headers - and send toay gmail account too
John Quest Replied
That domain name does not exist.
Merle Wait Replied
creativestitchesinc.com ?? maybe mis-type.. but certainly exists
Douglas Foster Replied
You will not get anywhere until you have log data from the rejecting organization.   You need to see what they saw when they rejected the message.

One possibility (most likely):
  • You allow users to enable automatic forwarding to an account outside your organization.
  • You have not enabled the option on your domain to "Enable SRS when Forwarding messages"
  • Therefore, messages that you forward are being blocked, not based on your domain, but based on the SPF policy of the originating domain.
If for some bizarre reason the problem really is your domain, change your SPF policy from -ALL to ?ALL, so that recipients will not reject on fail.

Preventing recurrence:
1) Enable DKIM signatures for each configured domain.
2) Publish a DMARC policy for each configured domain, including a reporting address, so that recipients look for and use the DKIM signature.
3) Look at the reports.   

When you have these preventive measures in place:
  • an SPF glitch will be forgiven because of the DKIM signature.   
  • A glitch with the DNS signature, such as DNS Temp Error, will be forgiven because of SPF PASS.    
  • Every day you will get reports from at least the major server farms, showing SPF and DKIM evaluation results from the previous day.   This can help you chase down the problem instead of flying blind.  (There are both free and paid services that can save you the trouble of building a report-processing environment.   I use the free service from PostmarkApp.com, which only provides summaries.   They have a paid service and an API for drill down, but I have built my own XML parsing tools.)
  • Aside from all of these benefits, Google and AOL/Yahoo have said that having a DMARC policy is pretty much mandatory if you want delivery to their environment, effective Feb 1, 2024.  For forwarded messages, you also need ARC, so you need to be on a recent release of SmarterMail that implements ARC.   I don't think they are enforcing that mandate 100%, but you don't want to fall victim.   
If you are hosting domains for customer organizations, you should be implementing DKIM signatures and DMARC policies as part of your standard setup.   This helps to keep your IP address from being block-listed, and since a block list entry affects all of  your domains, it should be avoided as much as possible. 

John Quest Replied
Sorry, apparently when I did the original copy it grabbed a space.

Your SPF record is technically incomplete and will cause problems.

There is no ending terminator. This is usually a (+,~,-,?)ALL or REDIRECT

NOTE: The only true actionable terminator is -ALL which means ONLY ACCEPT email per the listed paths.
Douglas Foster Replied
  • I don't see a syntax error in the SPF records.  Syntax errors should produce a result of PERMERROR, not FAIL
  • The lack of an ALL term should not be a problem, especially if one of the terms is going to produce a PASS result without exhausting the list.   If the list is exhausted, the default result should be "NEUTRAL", not "FAIL".
  • I also note that mx1.ebt.net is indirectly listed twice, because it is in both MX lists.  This should not be a problem either, but it is probably desirable to reconfigure somehow without the duplication.   My concern is that It opens the possibility that an excessively strict evaluator might object to the duplication.  However, this type of objection, if it occurs, should produce a result of PERMERROR, not FAIL.
Since you have no FAIL term in your SPF record, I still think the messages are being evaluated against a different domain than the one you are assuming.

Reply to Thread