I have configured Postfix with SPF and DKIM but all emails are marked as spam.
Here is my domain.db (I use bind9) :
...
mail._domainkey IN TXT ( "v=DKIM1; k=rsa; p=ABCD" )
I verify with :
host -t TXT mail._domainkey.domain.com
I receive (OK) :
mail._domainkey.domain.com descriptive text "v=DKIM1\; k=rsa\; " "p=ABCD"
I've checked also what could be the problem on email-tester.com, and I get 10/10, DKIM seems also correctly installed.
But when I check the content of an email, I see :
...
dkim:pass
dkim:pass
SPF:pass
...
X-Spam-Report:
* -0.0 NO_RELAYS Informational: message was not relayed via SMTP
* -0.0 NO_RECEIVED Informational: message has no Received headers
* 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
X-Spam-Status: No, score=0.0 required=5.0 tests=NO_RECEIVED,NO_RELAYS,
T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.0
Any idea ?
----- UPDATE -------
After adding in master.cf :
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
Here is the new email content :
...
dkim:pass (now there is only one: OK)
spf:pass
...
X-Spam-Report:
* -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=ham
autolearn_force=no version=3.4.0
which seems better, but the email is still marked as spam, grrr
A working SPD DKIM config does not necessarily lead it to not beeing categorized as spam.
I had to find that out escpecially from virtual hosters or cloud server/mail providers the ip ranges of them have a generally bad reputation which means even without sending spam before from the url and fresh DKIM SPF ect. the mails still go directly to junk (for example in office 365 which have a very strict unforgetting spam filter) because the IP belongs to a range that is generally marked with a bad reputation, or some spammer used the IP in the past...
(I did my testing with a custom DigitalOcean server postfix/opendkim and a free Mailgun account, Mailgun seems to offer dedicated IPs hopefuly without a ba drep as it seems in some blog posts)
Of course this is very annoying but of course also Marketing mail from SPFed and DKIMed servers get marked as Spam therefore big providers seem to go to the IP level ... I also read that especially office365 has some system that takes user feedback into account and assigns the negative spam markts back down till the IP.
Here's what's going on with your SPF record.
Go to this link and change the DNS Server to `Google Public DNS (8.8.8.8)
https://www.unlocktheinbox.com/dnstools/spf/luckeo.fr/
The results of your SPF will be v=spf a mx ip4:176.58.101.240 ~all
Now change it to DNS Advantage (156.154.70.1)
The results of your SPF will be v=spf1 a mx ip4:176.58.101.240 ~all
Notice the difference v=spf vs v=spf1
So your DNS hasn't propagated yet and depending on how the receiving email server looks up your DNS Records you're running into issues. Wait 24 hours and if you're still having issues, reply back.
Related
I have a forwarding domain (forwardingdomain.org > actual-website.org) for which I have email forwarders set up. To reduce spamming/spoofing of my email forwarders, I would like to set up a correct SPF TXT record in the domain’s DNS.
I have an SPF TXT record set up in the DNS, however, recently I’ve received scam/ransomware/spam emails that appear to be coming from email forwarders of the forwarding domain. So, that SPF record may not be working. I’ve successfully set up SPF TXT record for domains that have a website associated with them (i.e., I can use a server IP in the SPF record). For this domain, however, since it’s forwarding, it’s not clear what IP I should use.
Here’s the current SPF record (I don’t remember adding this myself; it may have gotten generated by itself):
Type: TXT
Host: #
Value: v=spf1 a mx include:sendgrid.net ~all
Expected result: No more scam/spam/ransomware emails should be coming in that appear as if they were sent from my email forwarders.
Actual result: Scam/spam/ransomware emails are coming in, appearing to be sent from my email forwarders.
Firstly I would recommend adding an include mechanism to pull in IPs from your forwarding domain.
Next, you have a ~all default mechanism, which means that forged messages will not be rejected, just marked as non-compliant (softfail). This is the correct setting if you are still testing your configuration or you are using DMARC.
With DMARC, the softfail can be turned into a full rejection, and this is generally considered better than using -all because it retains DMARC’s other semantics.
I have a client that have a spf record i don't understand.
The record is like this:
"v=spf1 a:domain.tld -a:gmail.com -a:googlemail.com -ip4:xx1.yy1.zz1.xx -ip4:xx2.yy2.zz2.xx include:spf.mandrillapp.com include:servers.mcsv.net ?all"
I have changed the ip's to x y and z, but it is real ips and the domain i also real and not domain.tld.
What does the minus in -a: and -ip4: do? does it have a function or is it wrongly setup?
I would like to clean up - can I just remove them? They use mailchimp, so I will just keep the 2 includes.
The relevant bits of the RFC are 4.6.2 and 5.3. Roughly
- means 'fail', i.e. reject any sender that matches this rule
a: means 'all IP addresses that this hostname resolves to'
So the intention of the rule appears to be to prevent anyone using gmail to send email from this domain, presumably because they used Google G-Suite for email at one time but have then stopped.
However I don't think that will work: Google's SPF configuration is more complicated than that and uses 'include:' to pick up lists of addresses specified by Google. I'd be surprised if all of their mailservers hosted the gmail web app too. So my guess would be that this doesn't actually work as-is, and so can be safely deleted.
Ditto the -ipv4 means don't allow this IP address to send email for your customer's domain. Chances are that's OK to go too, but you should verify what the IP address represents e.g. starting with a WHOIS lookup to see who (or which ISP) it's registered to.
I am in the process of migrating our staff's email client from Window's Live Mail to Gmail. I have gone through the process of connecting each staff's email from our domain to their respective Gmail accounts (so each staff has two valid email addresses, e.g. bob.our_domain#gmail.com and bob#our_domain.com). I am able to receive and send mail from the linked account, but emails sent from bob#our_domain.com are tagged with an alarming red question mark and read "Gmail could not verify that our_domain.com actually sent this message (and not a spammer) ". I understand that this is an error with SPF configuration but for the life of me cannot figure out what the correct configuration looks like.
The domain in questions is evergreensupplyonline.com.
Step 1 - Ensure SPF is enabled.
Our server is managed through cPanel, so I navigate to the authentication tab and enable both DKIM and SPF. The default SPF record is
v=spf1 +a +mx +ip4:166.62.38.87 ~all
Sending email with this configuration generates the error: SOFTFAIL with IP 208.109.80.60. Seems reasonable enough, the IP isn't listed and the ~all specifies a soft fail for unknown IPs (as far as I am aware)
Step 2 - Add the sender's IP to the SPF record
I add 208.109.80.60 to the record and my SPF record becomes
v=spf1 +a +mx +ip4:166.62.38.87 +ip4:208.109.80.60 ~all
Sending email with this configuration still generates a SOFTFAIL error but with a different IP (208.109.80.60). Based on this change I assume I won't be able to add a static IP for all of google's mail servers - not too much of a surprise.
Step 3 - Add Google's _spf domain
Following the instructions from https://support.google.com/a/answer/33786?hl=en
I removed 208.109.80.60 and instead include _spf.google.com domain. My SPF record now looks like
v=spf1 +a +mx +ip4:166.62.38.87 +include:_spf.google.com ~all
If I run my domain through https://toolbox.googleapps.com/apps/checkmx/ I get some some non-critical errors but everything relating to the _spf.google.com domain seems to check out. If I send an email with this configuration I still get a SOFTFAIL error.
I'm not sure where to go from here - I've tried all that my preliminary understanding of SPF will permit. Any suggestions, observations, or tricks are greatly welcomed. Cheers,
This does all look correct, apart from one thing. I looked up both the IPs you mentioned (using whois) and they belong to... GoDaddy, not Google, which entirely explains your problem. It's quite likely that GoDaddy is redirecting your outbound email traffic since they don't allow direct SMTP sending, so you may need to add GoDaddy's SPF as well, or move to a more enlightened hosting provider.
A minor thing: put the ip4 mechanism first as it's fastest to match for receivers (it requires no extra lookups), and you don't need the + qualifiers because that's the default action.
We use gmail together with our own domain since 3 years and configured it once right, everything worked fine. Mostly.
But recently, some mails (< 2%) will sometimes being rejected of the destination mail server because of SPF-Issues:
Technical details of permanent failure: Google tried to deliver your
message, but it was rejected by the server for the recipient domain
xxxxxx.de by xxxxxxx.de. [xx.xxx.xxx.xxx].
The error that the other server returned was: 550 xxx.xxxx.xxx.xxxx is not
allowed to send mail from xxxxxx.com
This is the SPF-Record we have configured as TXT Record in DNS:
v=spf1 +a +mx -all
Is there something wrong? Last document changes in googles docs are speaking about slightly different settings:
v=spf1 include:_spf.google.com ~all
Instead of blind changes without any understanding around the more detailled topic i want to ask around, if our spf-record could be outdated or completely wrong?
Assuming you're only using Google Apps for Work to send email then yes - your SPF record is wrong. The correct SPF record for this case is:
v=spf1 include:_spf.google.com ~all
If you are also sending emails from your web server directly or from other third party services you will likely need to add additional directives to your SPF record.
I'm trying to get an SPF record set up on our domain, but it just seems to be get confused.
The domain is letterpart.com and the mail server is mail.letterpart.com. We send all of our emails from an Exchange Server at mail.letterpart.com, either directly or via Perl scripts that forward to the Exchange server. This is our only server and deals with incoming and outgoing mails.
We originally had
v=spf1 mx a:mail.letterpart.com a:cmail1.com ~all
which includes our mail server and that of Campaign Monitor which we sometimes use to send out marketing emails.
This, though, was giving us a soft fail:
Recipient address rejected: SPF Tests: Mail-From Result="softfail": Mail From="*****#letterpart.com" HELO name="mail.letterpart.com" HELO Result="none" Remote IP="94.72.251.210">
I spoke to our ISP, KCOM, and they came back with this reply:
I have checked the existing SPF record and found a possible cause of
your "softfail". The "all" mechanism was prefixed with a "~" which
gives a soft fail. I have changed the records "all" section to "-all"
which should produce a fail.
Now, when I send mail from Outlook, I get a hard fail:
spf-test#openspf.net on 22/06/2012 09:47
You do not have permission to send to this recipient. For assistance, contact your system administrator.
<mail.letterpart.com #5.7.1 smtp;550 5.7.1 <spf-test#openspf.net>: Recipient address rejected: SPF Tests: Mail-From Result="fail": Mail From="*****#letterpart.com" HELO name="mail.letterpart.com" HELO Result="none" Remote IP="94.72.251.210">
I went back to our ISP and said that the change they made had indeed changed our soft fail into a hard fail, so can they now change it so we don't fail at all.
His reply was that this record is correct and that it shows that emails not coming from our domain will fail. I pointed out that the test I am sending was coming from our domain, and he just sent me a reference to SPF Record Syntax which is the same site I am testing the spf-test#openspf.net email on.
Have I completely got the wrong end of the stick when it comes to these records? I thought the idea was not to fail at all when sending from our domain.
Now. Our MX record shows the following:
mail.letterpart.com 94.72.251.212
But the SPF test email is showing the IP address as 94.72.251.210, and when I look at a header of an email sent from letterpart.com, it does indeed show it as coming from .210:
for *****#digitalessence.net; Fri, 22 Jun 2012 11:03:06 +0100
Received: from [94.72.251.210] (helo=mail.letterpart.com)
94.72.251.210 is the Wan1 interface on our Firewall. Should I add an IP address to the SPF or a range?
I was looking over your SPF records. It's listed as
v=spf1 ip4:94.72.251.210 a:cmail1.com ~all
It should look something like:
v=spf1 mx a ip4:94.72.251.210 a:cmail1.com ~all
Which will mean all the MX and A records for the current domain are valid. I really don't understand why your have a PTR set up for 94.72.251.210 back to mail letterpart.com, when mail.letterpart.com points to 94.72.251.212.
Yes, it sounds like you answered your own question - you should add 94.72.251.210 to your SPF record if that is where your emails are sent from (as far the outside world is concerned).
That's the easy way. The harder solution is to figure out why your mail server winds up sending from that IP address and correct the firewall rules so that mail emerges from your network on the IP address associated with the mail server's name. This seems more correct and might have other benefits - your mail headers look "forged" if they use a name that's different from the actual IP address they come from.