I have SPF and TXT record configured. When i check the SPF record syntax. It says PermError SPF Permanent Error: Too many DNS lookup.
v=spf1 include:_spf.google.com include:netcore.co.in ~all
And my emails are landed in SPAM as well.
1) I am on shared hosting, I dont have dedicated IP and DKIM configured. Actually I dont send emails with spam triggering words. Since I am on shared hosting. Is there any possibility of other's on the shared hosting sending the emails which resulted in my emails to land in SPAM.
2) I am using the netcore.co.in to send the mass mails. and google.com to send the mails from gmail.
And I have properly configured MX records as well. I have mentioned google MX records But not netcore.net MX records.
I am using sendgrid's free smtp server to send the emails from my java web app. which i am not mentioned in spf record.
Is SPF record causing the spam issues.
You should have a look at this question I answered a few weeks ago:
Too many DNS lookups in an SPF record
You only get 10 DNS lookups for SPF (that's part of the protocol). There are automatically two lookups to get your TXT records and the actual SPF record. Without doing the actual math (I'll leave that to you as an exercise), you're hovering in the neighborhood of 13-14 lookups. You need to either consolidate your SPF records into one, or drop one of those services. (For instance, SendGrid allows you to do both transactional and mass mail under one set of IPs, so you could drop netcore or gmail entirely).
As for your spam issue, you should contact SendGrid support (http://support.sendgrid.com), that shouldn't be happening to you and they will be able to help you troubleshoot and resolve the issue.
Another option is to use an SPF Proxy service like spfproxy.org. It masks all the lookups behind a proxy that does it in the background. Takes just a couple minutes to setup. =
This has nothing to do with shared hosting, dedicated IP, DKIM set up or not, or if your content looks spammy.
The only culprit here is that your SPF contains 10+ mechanisms and/or modifiers that do DNS lookups. The SPF spec imposes this limit to prevent DDoS attacks.
You can use an online SPF checker to check the DNS lookup count in your SPF record: Online SPF checker
When "SPF PermError: too many DNS lookups" is returned during an SPF check, DMARC treats that as fail since it's a permanent error, and all SPF permanent errors are interpreted as fail by DMARC. This can have a negative impact on your email deliverability and you should seek a solution to this problem.
I've written a post on this topic: SPF PermError: too many DNS lookups
Related
Our business emails are often considered as spam.
We are using gandi.net mails at the moment and send emails from our own mail clients using gandi smtp servers.
I've checked a few websites to test our email adresses for spam. I got the following report on one of them:
It offers me to add some SPF configuration and sign the message with DKIM.
Regarding SPF, I am offered to add a SPF record using the source server (which is the gandi mail relay server relay3-d.mail.gandi.net).
Problem is, there are many mail relay servers, and whenever I send a mail, i get one of those as the source server. They seem to be on the same IP range:
So what am I supposed to do?
add a spf record for each relay server?
like
v=spf1 a mx ip4:217.70.183.195 ~all
or maybe I can use the hostname for more readability?
v=spf1 mx a:relay3-d.mail.gandi.net ~all
Am I supposed to add the IP Range 217.70.183.193-217.70.183.201 ?
(got the IPs belows from https://www.ipaddressguide.com/cidr#range )
v=spf1 a mx ip4:217.70.183.193/32 ~all
v=spf1 a mx ip4:217.70.183.194/31 ~all
v=spf1 a mx ip4:217.70.183.196/30 ~all
v=spf1 a mx ip4:217.70.183.200/31 ~all
I am a bit concerned about screwing up our DNS configuration while doing that so please advise! I made a few changes on the DNS configuration, then I got a SPF check error on one of those spam check tools online so I reverted everything until I get more feedback.
This is exactly the purpose of include directives in SPF. You have no way of knowing what their pool of mail servers is, and it may change frequently; Include means that maintaining that list remains gandi's problem, not yours.
Their SPF support page (why didn't you look there before asking here?) says you should add include:_mailcust.gandi.net, and that record covers some large IP ranges, including those you've mentioned.
The thought occurred to me that if SPF records are not recursive, domain names may be vulnerable to email spoofing from subdomains. My research reveals this:
The Demon Question: What about subdomains?
If I get mail from pielovers.demon.co.uk, and there's no SPF data for
pielovers, should I go back one level and test SPF for demon.co.uk?
No. Each subdomain at Demon is a different customer, and each customer
might have their own policy. It wouldn't make sense for Demon's policy
to apply to all its customers by default; if Demon wants to do that,
it can set up SPF records for each subdomain.
So the advice to SPF publishers is this: you should add an SPF record
for each subdomain or hostname that has an A or MX record.
Sites with wildcard A or MX records should also have a wildcard SPF
record, of the form: * IN TXT "v=spf1 -all"
(Thanks to Stuart Cheshire.)
(emphasis mine)
Q1: Why don't you need to add a SPF record if the subdomain doesn't have a A/MX record?
As an example, I investigated support.google.com:
dig google.com txt:
google.com. 3599 IN TXT "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"
dig support.google.com txt:
support.google.com. 21599 IN CNAME www3.l.google.com.
dig www3.l.google.com txt:
www3.l.google.com. IN TXT
So..., no SPF record for support.google.com.
Q2: Wy don't Google (and many other sites) follow this advice?
Q3 (bonus): If this is a problem, and I'm not just being stupid, why is this not more documented?
The only related SE question I can find is this, but it doesn't say much more than the openspf.org FAQ above.
This is actually not terribly relevant advice in 2015, as the email landscape has evolved substantially since that post was made.
In practice SPF is an authentication protocol, not a policy enforcement mechanism. What I mean by that is that a particular message can pass, fail, or not check SPF based on the EHLO name or Return Path domain. But how a receiver should handle any SPF result is up to the receiver.
The email policy enforcement mechanism is DMARC, which specifies how a message that does not pass SPF or DKIM authentication should be handled by a receiver. Should it be rejected entirely? Quarantined (typically meaning directed to a spam folder)? Or treated as 'normal'?
DMARC, unlike SPF, does have subdomain inheritance. So, provided an explicit DMARC policy isn't defined on the subdomain, the policy defined on the organizational domain is used. So in the specific case you mention, the policy will be read from _dmarc.google.com. Which is:
v=DMARC1; p=quarantine; rua=mailto:mailauth-reports#google.com
So your hypothetical email sent on support.google.com will be treated as spam, even without an explicit SPF policy defined on support.google.com
So if you want to ensure against subdomain spoofing for a domain you manage, add a DMARC policy.
I am trying to help out a little non-profit organization, who has decided to let One.com host their domain, including website and e-mail. Now, my issue is that One.com does not add SPF-records or DKIM-keys to your domain and I believe that is the reason why a large number of mails sent from the domain, end up in spam.
I've been in touch with their support, who kindly answered:
You are already using our mail servers, there is no need to use SPF for that.
Our mail servers already have SPF installed, and if you are using our mail servers, SPF will not be question since domain is hosted here and it is using One.com's mail server. SPF will only be required if your domain is hosted here but is using a different MX record or mail server
I've tried to figure out if you can leave out SPF, but all I've been able to conclude is that proper SPF on each domain is definitely the proper way, instead of just the hosting companys main domain. I mean, if it was that simple, how come even Google Apps, Zoho, Rackspace etc. recommends adding SPF, if it worked just as well leaving it out - you'd be using their MX as well, so isn't that the same? And wouldn't leaving SPF out leave us with the same issues as before SPF, namedly that you'd have no way to validate if mail was truly being sent from the owners of the domain or just somebody imposing.
So what it comes down to: Can One.com really leave out SPF records on their clients domains, send mail on the clients behalfs and still expect mail to come through without ending up in spam more often?
Thank you very much for your time!
The short answer is "No, they can't". The longer answer is a little more complicated.
SPF uses either the EHLO domain of the sending server or the domain in the Return-Path to look up SPF records in DNS. Most systems that handle multiple domains do not use SPF records on the EHLO domains of the sending servers, so the SPF domain is taken from the email's Return-Path. You should take a look at the Return-Path for one of the emails that this non-profit has sent through One.com to determine whether the Return-Path is on a subdomain of one.com, or is using the non-profit's domain. The latter is definitely preferred.
If the Return-Path is on a subdomain of one.com, then that's the domain that will be used to look up SPF records. So adding SPF records to your non-profit's DNS won't do anything. While this may seem the easier path, it causes problems with DMARC and may cause the email to be flagged as spam even if it passes SPF, as the address in the 'From' header will have a domain that doesn't match the Return-Path
If the Return-Path is on a subdomain of your non-profit's domain, then you should definitely add an SPF record to your non-profit's DNS. Looking at one.com's current records, something like:
v=spf1 include:_spf.one.com ~all
should do it.
By the way, you should be able to see whether an email has been SPF or DKIM authorized by looking at the headers of the received email. That's the best way to understand the actual behavior.
Hello I own a website which uses 2 different ways to sent emails to users:
-gmail configured like support#example.com
-amazon SES
The problem is that the emails sent with SES goes allways into spam!
my SPF record looks like: "v=spf1 include:amazonses.com include:_spf.google.com ~all"
my TXT record looks like: "v=spf1 include:amazonses.com include:_spf.google.com ~all"
I have just changed this records as above, should I need to wait 48 hours or something similar?
Are this correct settings? if yes what could be the reason of my problem?
The first comment is actually not entirely correct!
Mechanisms can be prefixed with one of four qualifiers:
"+" Pass
"-" Fail
"~" SoftFail
"?" Neutral
SoftFail is usually the better choice than Fail because SPF has some flaws and a Fail could prevent some forwarded emails to not arrive at all instead of being flagged as possible spam. (I have experience with those problems since I have worked for several email providers)
Make sure to test your SPF records. You can use this website to test them:
http://spf.myisp.ch
First, as others noted, you are using SoftFail ~all. From openspf.org Record Syntax:
SoftFail: The SPF record has designated the host as NOT being allowed to send but is in transition
Intended action: accept but mark
You should use HardFail -all if you want the emails to be rejected when sent from an unauthorized server.
SPF protection is used to prevent spoofing. It's there to define the servers that are authorized to send emails for a certain domain. Generally, if the spf fail, the email will just be rejected and will not get into the spams.
There's a lot of possible reasons an email is getting into the spams, but it's generally because your email has been flagged as spam by a content analysis tool like SpamAssassin. You should contact whoever is managing the email filtering and ask them why exactly your email got in the spams.
I use a different server to send mail to my mailing list. I want to add an SPF record to my domain to show that the IP of the different server is authorized to send mail (as well as the default server).
The server sending email in the example is 1.2.3.4 with the main domain of test.co.uk.
So far I have v=spf1 mx a ip4:1.2.3.4/32 mx:test.co.uk ?all", would this work for what I want?
EDIT:
I would be sending mail using sendmail. The SPF record would be to increase % of mail going to inbox and also so we can enforce -all in the near future on SPF.
Try using an online tool like http://www.mtgsy.net/dns/spfwizard.php to generate the SPF record. If you Google for "SPF Record checker", you will find many websites which will even validate the SPF record for your domain.
Let's assume your domain is test.co.uk. This makes mx the same as mx:test.co.uk. Specifying an IP as ip4:1.2.3.4 is the same as ip4:1.2.3.4/32.
That would be enough:
v=spf1 mx a ip4:1.2.3.4 ?all
Make sure you verify your SPF records using a SPF checker. Try the following one.
http://spf.myisp.ch
It does some pretty extensive testing.