I got this new security warning:
The domain lacks a DNS SPF policy record. SPF policies must to be
applied on every domain (including subdomains) having either an A,
AAAA or MX record. What can happen? An attacker will be able to spoof
emails originating from the domain, allowing for phishing attacks or
other scams.
I dont know about it and i tried nothing to fix it..
..Can anybody help me out to fix this issue?
Thank you :)
Patrick, just use this SPF Wizard to generate the DNS Records you need to bring your domain in compliance with that warning
Related
Hope to find a solution here.
I use lemlist to send automated e-mail, and it requires me to set up a DKIM, DMARC and SPF. My e-mail provider is 1and1.com (Ionos).
I did set up a DMARC and SPF record, but still can't make a DKIM, although I followed every guideline I could find on internet.
To sum it up : I created a public key and added a TXT record with the public key in it. DMARCLY can easily find the key and everything, but every time I refresh the DNS on lemlist, lemlist doesn't detect the DKIM, or should I say, there is no DKIM signature in my mails.
On some resources, I see a CNAME records, and it's not said to do so on the lemlist guideline.
Can anyone help me with that please ?
I tried possibly everything: TXT records, CNAME records, but none seems to work.
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'm scoring 9/10 on mail-tester.com. My -1 comes from this,
"You do not have a DMARC record"
In my DNS (cPanel>"Advanced DNS Zone Editor") I have this DMARC record
_dmarc.mycooldomain.com. 14400 IN TXT "v=DMARC1; p=none; sp=none; ruf=mailto:myaddy#gmail.com; rf=afrf; pct=100; ri=86400"
my domain is really the correct domain in the actual DMARC record, and
myaddy#gmail.com is really the email for the cPanel/WHM account(a gmail addy), not the sender domain in the SPF record (e.g. info#mycooldomain.com). Does that matter?
otalliance.org/resources/spf-dmarc-tools-record-validator
Returns green, which I presume is good.
So is the issue with mail-tester.com, or my DMARC record?
Obviously, mycooldomain is not really your domain, so it's hard to verify what you posted, but based on what you posted, your RUF field will cause it to fail DMARC. If you send an email to mailtest#unlocktheinbox.com they have a really good DMARC tester, but unfortunately the DMARC results are not free. But I'm 100% sure that you're not following the standard on page 28 of the Dmarc Specification
Which reads
For example, if a DMARC policy query for "blue.example.com" contained
"rua=mailto:reports#red.example.net", the host extracted from the
latter ("red.example.net") does not match "blue.example.com", so this
procedure is enacted. A TXT query for
"blue.example.com._report._dmarc.red.example.net" is issued. If a
single reply comes back containing a tag of "v=DMARC1", then the
relationship between the two is confirmed. Moreover,
"red.example.net" has the opportunity to override the report
destination requested by "blue.example.com" if needed.
Since you're using a gmail account - there is no way your going to convince them to add a record on your behalf. So you need to choose a different RUF email address. Most likely one like dmarc#Mycooldomain then set up a forwarder to your gmail account if that's where you want the reports to go.
DNS changes are not available instantly. It can take hours until a new record will be visible to other servers. The DMARC entry you have posted seems to be valid except the "ruf=" email address. Here you must provide an email address assigned to your own domain.
Fix, wait and try again.
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.