SOLVED

FINAL NOTIFICATION: SPF Configuration Error

Go to solution
Highlighted
Anonymous
Not applicable

FINAL NOTIFICATION: SPF Configuration Error

Hi!

Yesterday i've received one notification with the title "FINAL NOTIFICATION: SPF Configuration Error". What this means?

SPF information for youlead.pt is not configured correctly in the domain's DNS record.

SPF status it's always saying "Pending Configuration" after several attempts to make it valid.

How can i validade it? What information should i enter to solve the error?

Thanks,

David Pereira

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

Re: FINAL NOTIFICATION: SPF Configuration Error

SPF should be setup for any domain that you are sending email through Marketo with. You do this by adding an SPF record to your domain's DNS record. This declares to the world that the domain owner has authorized Marketo's servers to send email on behalf of this domain. If you don't set it up, it doesn't mean that Marketo won't send out your email. It just means that recipient email services are more likely to immediately put your message in the SPAM folder.

Best practice is to have both DKIM and SPF setup for your domain:

  • SPF assure the recipient that the domain owner has authorized the sending server to send mail for the domain.
  • DKIM assures the recipient that the contents of the message were not altered during transit.

Full instructions can be found here: https://docs.marketo.com/display/DOCS/Set+up+SPF+and+DKIM+for+your+Email+Deliverability

View solution in original post

5 REPLIES 5
Highlighted
Level 10 - Community Moderator

Re: FINAL NOTIFICATION: SPF Configuration Error

If you're sending email from youlead.pt, best practice is to have an SPF TXT record, and you should indeed have one to protect person-to-person email (i.e. email sent via Outlook.com in your particular case). 

You don't need your SPF set up for Marketo-to-person mail, though.  So I'd just ignore it.  I see you do have the Marketo DKIM record M1._domainkey.youlead.pt set up, and if that's shown as validated in Marketo, that's far more important.

To set up your SPF record for youlead.pt, you need to account for all servers that may send with MAIL FROM: <*@youlead.pt>.  While this may only be Outlook.com, you must do a real inventory to be sure (for example, if you use another ESP or any other outbound mailserver, that must be listed as well).

Highlighted

Re: FINAL NOTIFICATION: SPF Configuration Error

SPF should be setup for any domain that you are sending email through Marketo with. You do this by adding an SPF record to your domain's DNS record. This declares to the world that the domain owner has authorized Marketo's servers to send email on behalf of this domain. If you don't set it up, it doesn't mean that Marketo won't send out your email. It just means that recipient email services are more likely to immediately put your message in the SPAM folder.

Best practice is to have both DKIM and SPF setup for your domain:

  • SPF assure the recipient that the domain owner has authorized the sending server to send mail for the domain.
  • DKIM assures the recipient that the contents of the message were not altered during transit.

Full instructions can be found here: https://docs.marketo.com/display/DOCS/Set+up+SPF+and+DKIM+for+your+Email+Deliverability

View solution in original post

Highlighted
Level 10 - Community Moderator

Re: FINAL NOTIFICATION: SPF Configuration Error

SPF governs the MAIL FROM (envelope sender).  Marketo uses MAIL FROM <*@mktomail.com>, so the SPF record for the customer domain isn't consulted.  It's easily verified that an SPF pass for Marketo-generated email is possible without any SPF record at all for the customer-operated domain, or with an ostensibly "failing" SPF record, since the record for mktomail.com is used.  (Unless there is some other type of subscription where you use the customer domain in the MAIL FROM.)

Highlighted

Re: FINAL NOTIFICATION: SPF Configuration Error

What Sanford said is technically true, but I would be careful. Email delivery is somewhat of an art, and there isn't really a "true" standard to follow. Here's what we see:

-Per Sanford's comments -> Almost all recipient email services check SPF against the domain found in the envelope_from header field of an email. Because this is generally an "mktomail.com" address, it should pass fine (Marketo has setup the DNS entry for "mktomail.com").

-However, many recipients and spam filters/traps will also check SPF against the domain found in the simple "From" address of the email. If there isn't SPF setup for that domain, they may not always completely block the mail from reaching the inbox, but it will negatively impact the "trust score" they assign to message. We do see a delivery rate % drop with customers when they don't have SPF setup for the domains they are sending from out of Marketo (which is why we really encourage all of our customers to have it setup). This is especially true if the domain already has SPF setup for a different outgoing mail server...if they find other records listed but not Marketo's, it makes the email seem much less legitimate.

The holy grail of email deliverability is to have the "Envelope From" match the domain found in the "From" address, plus have SPF & DKIM implemented correctly for the domain. Sanford is correct that Marketo emails will have the "mktomail.com" domain in the "Envelope From" unless you've purchased our "Branded Envelope From" product add-on that will give this to you. So, some customers do have subscriptions that are sending emails that have their own domain being used in the "Envelope From"

Highlighted
Level 10 - Community Moderator

Re: FINAL NOTIFICATION: SPF Configuration Error

Including the SPF for mktomail.com in an existing, time-tested record is harmless.  (We'll have to agree to disagree about any real-world effect on deliverability. Having worked with SPF since Meng was on the mailing list, I've seen no such significant behavior.)

But adding an SPF record for the first time without doing proper research into how a domain is used can be downright destructive to mission-critical services. It's doubtful that a non-IT person would be able to vouch for an SPF record's completeness.  All it takes is a server sending alerts from an outbound-only IP, or an SMTP gateway that doesn't whitelist auth'd users coming in over 4G, or a non-SRS forwarder to wreak havoc.  The cure is definitely worse than the disease in these cases.