Skip to main content
Valimail SPF Records
Updated over 5 months ago

Valimail's customers utilize SPF records which contain macros. The records allow our customers to leverage Valimail's patented technology to directly address the the 10 lookup limit in SPF. Valimail's patented instant SPF response returns only the specific and targeted response needed for a given email sending service that has been enabled by the customer to send on their behalf.

SPF Macros are defined in the SPF spec. Read more here.

The record also provides security from prying eyes trying to find out who you have as an allowed sender in your SPF record.

Examples and More Detail

The SPF record for the domain 'defendmy.email' is listed here:

v=spf1 include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email ~all

The components of that record are:


%{i} - IP address
%{h} - EHLO (if unknown, the word "unknown" can be submitted in place of an EHLO name)
%{d} - domain to query against (defendmy.email)

~all: ~all is used instead of -all (dash all), in order to provide better deliverability and backwards compatibility to older receivers. In reality, -all or ~all do not matter when it comes to DMARC. Both SPF failure result types will result in an equal failure from a DMARC perspective. We let the DMARC policy state what should be done if there is no alignment. (Read more here about Soft and Hard Fail)

Testing an SPF response

You can perform an SPF query against Valimail's SPF record to check whether you're receiving the correct response from Valimail for a given service.

An Example SPF query for Marketo on that Domain (defendmy.email)

Marketo NOT ENABLED in Valimail for the domain defendmy.email

dig 199.15.214.45._ip.em-sj-45.mktomail.com._ehlo.defendmy.email._spf.vali.email TXT +short

Response:

"v=spf1 ~all"

Marketo ENABLED in Valimail for the domain defendmy.email

dig 199.15.214.45._ip.em-sj-45.mktomail.com._ehlo.defendmy.email._spf.vali.email TXT +short

Response:

"v=spf1 include:mktomail.com ~all"

Note: Performing these direct queries against the include directive will show you a -all (dash all) response, but due to how SPF works, if a -all or ~all is received as part of an include directive, it will be ignored and the ~all of the domain's SPF record takes precedent. That's why when analyzing headers for mail sent from your domain with our SPF record, you'll see SPF resulting in a softfail.

Did this answer your question?