iFastnet email SPF

When my WordPress installation sends my Gmail address WordPress update notification emails the emails fail SPF with permerror… The full errors follows:

ARC-Authentication-Results: i=1; mx.google.com;
       spf=permerror (google.com: permanent error in processing during lookup of [email protected]: ifastnet.org not found) [email protected];
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=example.me
Received-SPF: permerror (google.com: permanent error in processing during lookup of [email protected]: ifastnet.org not found) client-ip=185.27.134.28;
Authentication-Results: mx.google.com;
       spf=permerror (google.com: permanent error in processing during lookup of [email protected]: ifastnet.org not found) [email protected];
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=example.me

This IP address’ reverse DNS is ifastnet.org

My SPF record follows:

example.me. 299 IN TXT "v=spf1 include:zoho.com include:transmail.net include:ifastnet.org ~all"

Is this an error about iFastnet not having SPF data or is it an error in my configuration? I’m not sure. Emails sent normally (not by PHPMailer) pass SPF checks. I don’t really intend to use PHP mail for anything, but these notifications do get sent to my spam folder.

Can you please share the full message headers of this message (rather than just the few headers indicating the error)? That way we can retrace the message in our logs and see where this data came from.

1 Like

The full email including headers follows:

Delivered-To: [email protected]
Received: by 2002:ab3:68a:0:0:0:0:0 with SMTP id 10csp1464316lte;
        Wed, 18 Dec 2019 16:18:46 -0800 (PST)
X-Google-Smtp-Source: APXvYqx6aGnKad+BsLKsHDGCL/JJ+mvWT6tRVCV/NMy8zXrOcPOUkEe51pcTxih9+ok6pVkLLc0H
X-Received: by 2002:adf:c74f:: with SMTP id b15mr5843542wrh.272.1576714726131;
        Wed, 18 Dec 2019 16:18:46 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1576714726; cv=none;
        d=google.com; s=arc-20160816;
        b=nur4JpjMMR/nLCfvLCocT843u2vRsf8Pl4SrBo5/4Jnilu2SFz7mpip8qjamSKRfIu
         2KHNPn54bLZIQ+i9BDqCVVZox5/bce0HGi+4KjqFvQEP87qA2PY7h9wdA8QrYk2pYxMe
         IZX8+MUxSA0JUz88Xf50+WtmGAT/RPNt/cOFcnjDK+ZeespOd5jnxbKdZH9tHmHZo7bl
         NlwPvSQNKj1oOU9P9ZueRHrjDFH4tDt0WOjUuWnBYUynfVX1veOII6a63o8QLp89WFIb
         hGruta7mcHdXCo805ueL84p9//7XMxdSK1DS5+8sraVB4gaWjTonHDLzVYuY4JYm44YX
         UMNQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:mime-version:message-id:subject:from:to
         :date;
        bh=zIamCvQt/Ttg9DKZ4M5q2ePFgNWe0NbI6NnoBR5Cf7s=;
        b=BDbl496taSuVFR8BofaHvnrBux90JTtmsZf3k3jZejwZsV3MIWAv4I531Xt4tTFqXd
         76rxUFE9g7+Q6XHvTWAsTsh5houp/pjX4LDvLiliFg3AeFDFq6Dl51mZlJe63rQYIova
         A6En2AH2yS82EUru0PAXJlUKhgY74K5zNuT87WK7iffR+Rzr7nNVQks6bKmh/jEkR462
         PnQd9YyktCHgkpyZ2jc0FznTnVAC5LDmTaStM54sPafJLWISVHC/M/PPDQPFt4W+5zTv
         wG5arif4WA78i0g83KsVzexIG83CfemqSskodu3hxmDNaA0ZvjLEbGSC/hj4SaDLYCa7
         BdJA==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=permerror (google.com: permanent error in processing during lookup of [email protected]: ifastnet.org not found) [email protected];
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=example.me
Return-Path: <[email protected]>
Received: from sendmail.free.byetcluster.com (2813427185.ifastnet.org. [185.27.134.28])
        by mx.google.com with ESMTP id v5si3520138wmj.13.2019.12.18.16.18.45
        for <[email protected]>;
        Wed, 18 Dec 2019 16:18:46 -0800 (PST)
Received-SPF: permerror (google.com: permanent error in processing during lookup of [email protected]: ifastnet.org not found) client-ip=185.27.134.28;
Authentication-Results: mx.google.com;
       spf=permerror (google.com: permanent error in processing during lookup of [email protected]: ifastnet.org not found) [email protected];
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=example.me
Received: from localhost.localdomain (unknown [185.27.134.188]) by sendmail.free.byetcluster.com (Postfix) with ESMTP id 8B6863127BA6 for <[email protected]>; Thu, 19 Dec 2019 03:18:40 +0300 (MSK)
Date: Wed, 18 Dec 2019 19:18:40 -0500
To: [email protected]
From: WordPress <[email protected]>
Subject: [example's Personal Website] Your site has updated to WordPress 5.3.2
Message-ID: <[email protected]>
X-Priority: 3
X-Mailer: PHPMailer 5.2.1 (http://code.google.com/a/apache-extras.org/p/phpmailer/)
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8; charset="UTF-8"




Howdy! Your site at https://example.me has been updated automatically to WordPress 5.3.2.

No further action is needed on your part. For more on version 5.3.2, see the About WordPress screen:
https://example.me/wp-admin/about.php

If you experience any issues or need support, the volunteers in the WordPress.org support forums may be able to help.
https://wordpress.org/support/forums/

The WordPress Team


Get premium hosting from https://ifastnet.com, free domain name, unlimited disk space,,,, far too many features to list.





Spam Filtered (24837968)

This is probably the issue. Can you please double check your WordPress settings to verify the sending address is correct? This should probably something@your domain, not example.me.

Also, I think your SPF record might be incorrect. The free hosting mail server is 185.27.134.28, as you can see in the output. If you replace include:ifastnet.org with ip4:185.27.134.28, your messages should pass the SPF checks.

1 Like

example.me is just a redaction.

The IP already resolves to that ifastnet.org so changing the record to directly reference the IP won’t affect anything unless that changes.

I’m sorry, but what are you basing that on? ifastnet.org does not have an SPF record itself (so you can’t do the include) and the IP address it points to is not the email address your email messages are sent from.

So can you please make the change I suggested?

1 Like

To clarify, SPF works as follows:

  1. The recipient mail system reads the return-path domain, example.me
  2. The recipient mail system reads the SPF record for the domain example.me
  3. The recipient mail system checks whether or not the IP address of the sender mail system matches anything in the SPF record

The sender IP being checked in this example is 185.27.134.28 which has a reverse DNS of ifastnet.org. ifastnet.org is in the SPF record as an authorized sender.

One of the following things should happen:

  1. The SPF check fails because the IP address is not in the SPF record as an authorized sender
  2. The SPF check passes because the IP address is not in the SPF record as an authorized sender

Neither of these results is happening. Instead the recipient mail system is getting permanent error in processing during lookup of [email protected]: ifastnet.org not found which is not an error I understand.

I found the answer after re-reading one of your comments.

The reason the SPF check fails with permerror is because — as you pointed out — ifastnet.org has no SPF record and therefore the include: lookup fails on the recipient mail system’s side.

There are the following solutions from worst to best:

  1. Users can use ip4:185.27.134.28
  2. An A record can be created like ifmail.ifastnet.org pointing pointing to the IP address of the system you intend to send mail from and users can use a:ifmail.ifastnet.org
  3. An MX record can be created for ifastnet.org pointing to the IP address of the system you intend to send mail from and users can use mx:ifastnet.org
  4. A PTR record can be created for ifastnet.org pointing to the IP address you intend to send mail from and users can use ptr:ifastnet.org
  5. An SPF record can be created for ifastnet.org pointing to the IP address of the system you intend to send mail from and users can use include:ifastnet.org

The first solution is awful because if the IP address you send mail from every changes none of your users will know and their configurations will instantly break. The second and third solution are like holding something together with dental floss and duct tape; they work but they’re barely better than literal nothing. The third solution in particular requires you to allow your free hosting mailer to send mail for ifastnet.org which you might not want. The fourth solution is expensive on DNS infrastructure. The PTR record for 185.27.134.28 is 2813427185.ifastnet.org which is just the IP concatenated with ifastnet.org which doesn’t make a lot of sense. The fifth solution is standard practice and Just Works™ and should be used.

I’m glad you were able to figure it out: the include statement works a bit different from what you expected.

The hard coded IP address is how it’s supposed to work. The IP address doesn’t change very often, and when it does, we can easily update all SPF records in our own nameservers. Remember: the majority of people are using our nameservers, which is typically not the case with a specialized email provider. The hard coded IP address is what cPanel does as well, so what we do is no different from what the majority of hosting providers do.

For points 2-5, the domain freemail.byetcluster.com should fulfill those purposes. Or it did, until half a year ago, when the mail server IP was no longer 185.27.132.238. Since then, it appears to have become a bit of a mess. I can ask someone to go through this to clean it up.

1 Like

You expect to go through all of your customer’s SPF records and do a search-and-replace for the IP in the event that it changes? I can’t imagine a situation where that’s a good idea.

We’ve done that a couple of times in the past. It worked perfectly. A bulk replace for everyone who didn’t customize their SPF records, and a search/replace on all the custom ones. It’s not that difficult to script effectively.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.