Hot answers tagged spf
To defeat your enemy, you must know your enemy. What is spam? For our purposes, spam is any unsolicited bulk electronic message. Spam these days is intended to lure unsuspecting users into visiting a (usually shady) web site where they will be asked to buy products, or have malware delivered to their computers, or both. Some spam will deliver malware ...
v=spf1 include:_spf.google.com include:otherdomain.com ~all There's no restriction against including multiple names in a single entry; Hotmail, for instance, takes this to extremes. Note that multiple includes, or nested ones, need to stay under the limit of 10 total DNS lookups for the whole SPF check.
SPF records detail which servers are allowed to send mail for your domain. Questions 1-3 really summarise the whole point of SPF: You're supposed to be listing the addresses of all the servers that are authorised to send mail coming from your domain. If you don't have an exhaustive list at this time, it's generally not a good idea to set up an SPF record. ...
From RFC 4408: 3.1.2. Multiple DNS Records A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record. See Section 4.5 for the selection rules. I'm not entirely sure what you want to achieve by adding a second record, but if it is something like adding extra hosts/networks as ...
I had to wrap my SPF record in quotation marks for it to work. "v=spf1 include:_spf.google.com ~all"
You need to have separate SPF records for each subdomain you wish to send mail from. http://www.openspf.org/FAQ/The_demon_question This makes sense - a subdomain may very well be in a different geographical location which will have a very different SPF definition. EDIT - the 'include:' directive for SPF may be used to provide all subdomains with the same ...
I've managed over 100 separate mail environments over the years and have used numerous processes to reduce or help eliminate spam. Technology has evolved over time, so this answer will walk through some of the things I've tried in the past and detail the current state of affairs. A few thoughts about protection... You want to protect port 25 of your ...
All SPF mechanisms can be used multiple times, separated by spaces. include is not an exception. "v=spf1 include:_spf.google.com include:otherdomain.com -all" See SPF record syntax and RFC 4408.
Yes. I wouldn't call this subjective because there's a clear consensus; use SPF. Implementation is very easy and it's a good thing for the internet as a whole.
Partly, I endorse what others have said; partly, I don't. Spamassassin This works very well for me, but you need to spend some time training the Bayesian filter with both ham and spam. Greylisting ewwhite may feel its day has come and gone, but I can't agree. One of my clients asked how effective my various filters were, so here are approximate stats ...
I am using a number of techniques which reduce spam to acceptable levels. Delay accepting connections from incorrectly configured servers. A majority of the Spam I receive is from Spambots running on malware infected system. Almost all of these do not pass rDNS validation. Delaying for 30 seconds or so before each response causes most Spambots to give ...
TXT records were originally intended to provide an option to place arbitrary user-comments. Now, they are generally used for the SPF anti-spam system.
SPF is so badly configured by so many sites that receiving MTAs often count hardfail as advisory only, and merely factor it into their spam detection scores. In the end it's up to the MTA's administrator as to how SPF failures will be treated.
SPF Stands for Sender Policy Framework. What it allows an administrator to do is specify what servers or internet hosts are allowed to send mail originating from that domain. See this article for more information: http://en.wikipedia.org/wiki/Sender%5FPolicy%5FFramework
No you can't. That is not the correct SPF record, and it is not the correct address of Google's SPF record. Anyone with the control of a reverse DNS domain can make any IP have any name he/she wants, like "google.com", "whitehouse.gov", etc. Allowing reverse matches at all would be very wrong. The "include" feature of SPF works differently. It does a direct ...
You can only have one SPF record. You need to combine them like so: v=spf1 include:spf.mandrillapp.com include:spf.protection.outlook.com -all or v=spf1 include:spf.mandrillapp.com include:spf.protection.outlook.com ?all
The include directive ignores terminal alls of any kind, as the project's page on the record syntax makes (fairly) clear: In hindsight, the name "include" was poorly chosen. Only the evaluated result of the referenced SPF record is used, rather than acting as if the referenced SPF record was literally included in the first. For example, evaluating ...
That is not a MX record, it's a SPF record. Usually you would use a TXT record to store SPF information since most DNS servers haven't implemented the SPF RR Type yet. Your existing SPF record should probably just be updated to reflect the requirements in the invoicing system: v=spf1 a mx ptr include:mydomain.co.uk include:_spf.bidsketch.com ~all If the ...
I can't speak for you DKIM key, but your SPF record is set up wrong. You're specifying that the A record, MX record and PTR record are all permitted, and then the +all is saying that any address is valid. If you want to exclude other ip addresses then it needs to be a -all. You'll also want to declare the SPF record as a text record too, as not all mail ...
No. You are right. See RFC 4408, section 4.5. Records that do not begin with a version section of exactly "v=spf1" are discarded. Note that the version section is terminated either by an SP character or the end of the record. A record with a version section of "v=spf10" does not match and must be discarded. If any records of type ...
Your SPF record designates everyone in the world as an allowed sender: "v=spf1 mx:... +all" The +all is the important part, + means "allowed" and all really means "the whole internet". They didn't need to spoof anything, their mail is valid according to your SPF record. Try -all instead.
Pretty much what it says on the tin. In the first case, domain 2's SPF record is included in the SPF record for domain1, but can still be modified eg by adding another A host that isn't permitted for domain2.com: "v=spf1 include:domain2.com a:othermailhost.domain1.com -all" In the second case, domain2's SPF record is used as the complete SPF record for ...
If you are trying to add an SPF record in addition to the usual TXT record, the format is exactly the same. However, you need to use a version of BIND that supports SPF record types, i.e. 9.4.0 or later. If your DNS software lacks support for "true" SPF records, I wouldn't worry about it. This record type is fairly new and you certainly won't need it for ...
No spf records are NOT required if your domain doesn't send emails however for benefit of reducing the risk of spam mail coming from that domain setting the spf record of "v=spf1 -all" is good so that spf checking servers see this and automatically reject email from that domain
You don't strictly need to publish any SPF records at all, it is a voluntary system. That said, if you do publish an SPF record, you can: Help the Internet at large a tiny, tiny bit because it gives spammers one less domain to spoof. (Marginal benefit, but...) Help preserve your domains 'reputation' by making it less likely to be spoofed in spam. ...
Well, it was certainly not the intent of the specification for it to be used instead - softfail is intended as a transition mechanism, where you can have the messages marked without rejecting them outright. As you've found, failing messages outright tends to cause problems; some legitimate services, for example, will spoof your domain's addresses in order ...
Mailchimp have an excellent article on How To Avoid Spam Filters Update: Ok, seeing as I got slammed for just giving this link (to be fair its contents probably wouldn't solve your problem here), I've added more specific to what you're sending. I suspect its the text you're using. 'Please confirm your email address by clicking the link' - I think you ...
google [or anyone else] will validate spf agains the ip address they see connecting to them. in that case it'll be ip address of your postfix server; you cannot fix it - it's by design.... by design spf has an 'issue' with forwarding unless message is 'repackaged' and sender address rewritten to the one of forwarder.
Once DKIM was setup (for help, see this guide) and verified successfully on my domain I still had to enable it in the AWS console at SES -> Domains -> DKIM Once that was done mails to Gmail no longer show up with the via bounces address. You can see it still shows as mailed by: amazonses.com when you view details of the sender but that's OK ...
I can vouch for #2 (reverse PTR) being important, but not #4 (mail server domain matching "from"). We set up mail servers all the time, and most mail hosts don't really even care about #2. The main thorn is always AOL, and they list standards you can check off.
Only top voted, non community-wiki answers of a minimum length are eligible