function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
jhartjhart 

Email Services - "SPF validation failure" despite disabling Advanced Email Security

I have a test email service with the "Advanced Email Services" check disabled.

 

Nonetheless, I am getting an "SPF validation failure' response from SFDC's mail servers.

 

 

[220] 'mx1-sjl.mta.salesforce.com ESMTP'
> EHLO localhost
[250] 'mx1-sjl.mta.salesforce.com says EHLO to ...:61009'
[250] 'SIZE 20971520'
[250] 'STARTTLS'
[250] 'PIPELINING'
[250] 'ENHANCEDSTATUSCODES'
[250] '8BITMIME'
> MAIL FROM: <test@REDACTED.com>
[250] 'SPF validation failure'
...

 

This exact same pattern occurs regardless of whether the "Advanced Email Security" box is checked or not.

 

It's a requirement for our use case that Advanced Email Security not be enabled for this particular Email Service.

 

Anybody else seeing this?

Best Answer chosen by Admin (Salesforce Developers) 
jhartjhart

Update:

 

Actually, this problem is a chimera of my own making.

 

The email is actually getting processed by Email Services, regardless of the "250 SPF validation failure" responses.

 

I guess I should have gone back to good old RFC 2821 for the semantics of the "250" response.  It means "OK, proceed", and the human-readable text after the "250" can be ignored as a red herring. 

 

Sorry for the distraction; carry on ....

All Answers

jhartjhart

Some additional research reveals:

 

If either your SMTP "MAIL FROM" or your email content's "From:" header is from a domain that defines an SPF record, then your sending IP must be in that SPF record.  If not, SFDC rejects the message, regardless of the "Advanced Email Security" setting for the Email Service.

 

The above post shows a rejection per the "MAIL FROM" SMTP dialog domain.  Here's an SMTP dialog where the "MAIL FROM" is from a domain that defines no SPF record, but the "From:" header in the DATA chunk does:

 

> EHLO localhost
[250] 'mx1-sjl.mta.salesforce.com says EHLO to ...:61326'
[250] '8BITMIME'
[250] 'PIPELINING'
[250] 'ENHANCEDSTATUSCODES'
[250] 'SIZE 20971520'
[250] 'STARTTLS'
> MAIL FROM: <sys.admin@domain_with_no_spf_record.com>
[250] 'MAIL FROM accepted'
> RCPT TO: <test@redacted.7-jqpveac.7.apex.salesforce.com>
[250] 'RCPT TO accepted'
> DATA
[354] 'continue.  finished with "\r\n.\r\n"'
[250] 'SPF validation failure'

Note the "SPF validation failure" comes later in this dialog, after the DATA chunk.

 

If both addresses are from a domain without an SPF record defined, the email is accepted:

 

> EHLO localhost
[250] 'mx1-sjl.mta.salesforce.com says EHLO to ...:61326'
[250] '8BITMIME'
[250] 'PIPELINING'
[250] 'ENHANCEDSTATUSCODES'
[250] 'SIZE 20971520'
[250] 'STARTTLS'
> MAIL FROM: <sys.admin@domain_with_no_spf_record.com>
[250] 'MAIL FROM accepted'
> RCPT TO: <test@redacted.7-jqpveac.7.apex.salesforce.com>
[250] 'RCPT TO accepted'
> DATA
[354] 'continue.  finished with "\r\n.\r\n"'
[250] 'OK 6B/38-26914-43F45A05'
> QUIT
[221] 'mx1-sjl.mta.salesforce.com closing connection'

 

 

This seems like a bug.  People misconfigure their SPF records *all the time*.  With the current behavior, it is impossible to create an Email Service that actually accepts email from the widest possible swath of users.

 

In addition, if you have a forwarding rule configured - for example, you configure your mail server to forward inbound email to an Email Services address - then you will experience massive failure, as your forwarding mail server will never pass an SPF check against the original sender (as found in the "From:" header of the DATA chunk).

 

So, if you want to use a rule in Google Apps to forward mail to Email Services ... it won't work.

jhartjhart

Update:

 

Actually, this problem is a chimera of my own making.

 

The email is actually getting processed by Email Services, regardless of the "250 SPF validation failure" responses.

 

I guess I should have gone back to good old RFC 2821 for the semantics of the "250" response.  It means "OK, proceed", and the human-readable text after the "250" can be ignored as a red herring. 

 

Sorry for the distraction; carry on ....

This was selected as the best answer