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.
Related
v=spf1 include:spf.falconide.com include:sendgrid.net include:_spf.google.com ip4:xx.xxx.xxx.x ~all
Above is my SPF record for my domain, I am using an external tool to get open-source threat intelligence, in the tool it says my SPF config is not secure. Support is unavailable at the moment.
Does anything look insecure about the config?
No, this looks ok. The only thing I would change is to put the ip4 mechanism first.
You don’t provide any specifics of the actual error report, but it would not surprise me if it is misreporting thé ~all as a problem, even though it’s very unlikely to be. We would need to see your DMARC config to tell.
Maybe it just doesn't want you to use the soft fail?
If possible, try changing ~all to -all
Check the fail policy and qualifiers items of SPF records in Wikipedia:
https://en.wikipedia.org/wiki/Sender_Policy_Framework#FAIL_and_forwarding
https://en.wikipedia.org/wiki/Sender_Policy_Framework#Qualifiers
Use softfail (~all) as hardfail is NOT at all reliably enforced and can act in unexpected and seemingly random ways (suddenly a hosting company or mailbox provider stops or starts honoring hardfails).
Only a few mailbox providers reject based on just an SPF hard fail, and that's a moving target. For this reason, ~ALL is a best practice.
It’s DMARC that more reliably rejects if you want to tell mailbox providers to reject mail that fails DMARC. To to pass DMARC, either SPF or DKIM must fail and the domains in alignment. In. relaxed mode (by far the most common), alignment means the same organizational domain so example.com aligns with foo.example.com.
Always start with a p=none, a reporting only policy in DMARC and only VERY cautiously ramp up to a more aggressive DMARC policy such as p=reject or p=quarantine, as they can break legit mail if there’s legit mail that fails DMARC.
Delay deploying a more aggressive DMARC policy until you're sure all your legit mail's accounted for and authenticated. That way, only mail that's not authorized by you or flat out domain spoofing email (spammers and phishers) will fail DMARC.
Also, note that many ESPs by default have you use your own donain as the header from and use a domain of their own as the Envelope From.
If you request and setup a custom mail from domain, you can often get a subdomain of your domain set up the Envelope FROM (example.example.com) and the header from example.com (that recipients actually see).
If your envelope from isn’t example.com itself but instead foo.example.com then having the SPF set in your organizational domain uses as the header from won’t be useful. SFP is useful in the envelope from not the header FROM.
DKIM is signed by the header from domain (usually your organizational domain, example.com) and SPF is relevant in the envelope FROM domain only (e.g.,foo.example.com).
Also, keep in mind that an SPF record only allows 10 DNS lookups to be valid so check with a couple validation tools to makes sure it’s 10 or under. The above SPF you set uses 6/10 DNS lookups and is valid.
The SPF you have in your organizational domain isn't going to help, unless your Envelope From Domain is example.com.
And again ~ALL isn’t a problem. You can confirm this by doing some web searches on the risks and benefits of setting a softfail vs. a hardfail in SPF.
Some ESPs use their own domain as the envelope from meaning you need to explicitly work with your ESP to configure foo.example.com as the envelope from to get domain alignment with example.com, your organizational domain, and DKIM signing domain.
A complication is that many ESPs use a domain of there own for your Envelope From Domain and offer services/features such as a "custom sending domain," enabling you to use a subdomain of your own domain as the Envelope From Domain. Given that alignment policies have recently become more strict, it's a good idea to use a subdomain of your own domain as the Envelope From Domain rather than an ESP domain. For example, Microsoft recently enacted a policy whereby domain mis-alignment by itself causing either SPF or DKIM to fail is in itself enough to route email to spam. Other mailbox providers have been moving toward this sort of measure to try to get a handle on domain spoofing and the phishing and spamming that comes along with it.
Envelope FROM domain: Recipients do not see this domain.
Header FROM domain: Recipients can see this in the visible FROM line.
I just found out my domain's emails have been going to the spam folder of gmail recipients. I did some research and I put the following in my DNS records for my domain name:
TXT - "v=spf1 include:_spf.google.com ~all"
I'm not sure if I have to put anything before the spf like my server's IP address or a or mx in some configurations I see. I mainly use my google apps domain email by using my plain gmail account and set "Send As" to send from the domain specific emails.
Is there something else I am missing or overlooking that I need to do to resolve this issue?
If you're only using google apps to send emails then that's the correct SPF record.
If you want to be sure, the best thing you can do is send an email to
mailtest#unlocktheinbox.com
check-auth#verifier.port25.com
They are know as reflectors and will auto-respond with your configuration, letting you know if you have your SPF set up correctly.
If you're unsure of what you need just use an SPF Wizard, but I think based on your description you're 100% fine. The MX and A just tells the receiving mail server that if the mail comes from you MX or A of your domain, then it's a good email, but you're sending from google, so you wouldn't need it.
Also with GMAIL in-boxing takes time and SPF isn't the magic cure, but it helps.
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 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
From the definition of SPF, SPF only authorizes IP address. For one of our domain name, we have created an SPF record to allow only A and MX IPs as genuine sender. This domain is hosted in a shared-hosting environment along with many other customers.
In such setup, owners of other domains on same host can spoof my emails easily. Is there any way SPF still work?
(correct me if my understanding abt SPF is wrong)
Yes they can spoof them but it would be very very unlikly.
If you are concerned about your personal mails that you send out or automatic mails from any system you provide on said host, you might consider signing them cryptographicaly to enable recipients to check if they are genuine.
I think there techniquies implemented in some mailservers to sign mails automaticly AND there is of course DNS signatures but what the status there is is bejond my knowledge.