SPF: fail (Exclaimer Mail Utilities: domain of domain.co.uk does not designate 194.xx.x.xx as permitted sender) client-ip=194.xx.x.xx; envelope-from=user#domain.co.uk; helo=smtp1.bt.net; ########
This is the bounce back that is being received, what does this mean and how can I go about resolving this issue?
we had something similar happen to us. I believe Mail Utilities checks the SPF record for your domain in DNS but this does not match the host address your email address is coming from. Because the two do not match the message has been classified as an SPF Fail and rejected. Try checking your SPF record in DNS for your domain. You might be able to find more info here http://www.openspf.org/.
Related
I tried to find the answer from google but all result is showing why SPF is important instead of explain the working mechanism and how mail server(gmail, microsoft, smartermail, etc) implement it, generally.
Below is the criteria in came out but could find the answer:
SPF record exist, labeled sender & mail server domain aren't same, mail server domain/IP included
SPF record exist, labeled sender & mail server domain aren't same, mail server domain/IP not included
SPF record exist, labeled sender & mail server domain are same, mail server domain/IP not included
SPF record not exist, labeled sender & mail server domain aren't same
SPF record not exist, labeled sender & mail server domain are same
I would like to know, generally, which criteria will mark as junk mail by mail server.
Thank you.
Edit 1:
Lets put the other factor apart, how mail server decide to increase/decrease the level of "points" by looking at SPF only?
SPF is only responsible for identifying sources of email, and has no opinion about content.
You're asking how receiving email servers decide what to do with messages that fail SPF checks. That's a good question, because it's something that a domain owner should be concerned about, and historically this has been undefined (as others have pointed out), and so varied wildly. Fortunately there's now a mechanism whereby the domain owner can say what a receiving server should do with messages that fail SPF checks: DMARC.
DMARC includes a p parameter that tells a receiver what to do with messages that fail checks. Its value can be none (do nothing, or whatever the receiver chooses), quarantine (put in spam or similar), or reject (bounce the message).
DMARC can apply these same policies to DKIM, and it also provides additional validation of the alignment between the SMTP envelope sender and the From message header.
If a domain lacks a DMARC record, you're back to guessing the outcome, and subject to the whims of receiving mail server admins' decisions.
I host a domain for a client; the domain's A records point to my IP address. When email arrives addressed to someone in his domain, he just wants to forward it to his ISP (charter.net). This works about 90-99% of the time, but a few times a day charter.net rejects the message with 'Service not available'. We tried forwarding to his gmail account instead, and same thing -- it usually works but sometimes gmail returns 'Service not available'. When this happens, my sendmail apparently gives up.
My suspicion is it is not the recipient's server uptime that is at issue; it rejects email that it sees as suspicious.
I have recently added SPF and DKIM records for my server's canonical name but I still get 'Service not available' from charter.net. Now sendmail DKIM-signs any mail that originates on my server, but it is not signing email that it forwards. I have not found a way to configure opendkim to do that. But I have seen that mandrillapp.com resigns email that it forwards; the headers include a DKIM-signature with d=originaldomain.com, and a 2nd DKIM-signature with d=mandrillapp.com.
So I guess my questions are,
1) Does anyone really know why my server gets 'Service not available' from ultimate recipient?
2) Can I configure opendkim to sign email that my server forwards?
3) Might it do any good to set up SPF and/or DKIM records for my client's domain?
Thanks,
Bob
ADDENDUM:
For forwarding, I have entries like this in /etc/mail/virtusertable:
a#clientdomain.com a#charter.net
For DKIM, I have this in my sendmail.mc:
INPUT_MAIL_FILTER(`opendkim', `S=inet:8891#127.0.0.1')
I also have clientdomain.com in /etc/mail/local-host-names, and as I said above clientdomain.com's A records resolve to the same IP as mydomain.com.
Classic sendmail redirects via aliases, ~/.forward file and virtusertable keep unchanged original envelope address (It is used in MAIL FROM command during SMTP session). It may make your forwards break restrictions set by SPF record of the original sender domain.
Possible fixes for "many addresses" redirect:
SRS
custom sendmail.cf fixes
For more details ask at more suited siter site serverfault.com.
I'm troubleshooting an issue involving duplication of emails sent from an SSRS server via office 365 to customers. During investigation I looked at the email headers from duplicated emails and found that they all indicate the following:
received-spf: Fail (protection.outlook.com: domain of myDomain.com does not designate XX.XXX.XXX.XX as permitted sender) receiver=protection.outlook.com; client-ip=XX.XXX.XXX.XX; helo=;
What would be the effect (if any) on emails from myDomain.com (which is our office365 domain name) to various customers considering the above spf Fail message? I do not recognize the ip address however the domain name and hostname are correct.
The effect would depend on whether you have set DMARC record for your domain or not. If YES then whether you are signing your outgoing mails with DKIM or not. If your mails fails the SPF check at least they should pass the DKIM verification.
Is it a problem if 127.0.0.1 appears in email headers?
Example: Received: from baobabsmail.baobab.fi ([127.0.0.1])
I ask because emails sent from my server to #outlook.com addresses end up in the spam folder and this is the last thing I can think of. I have properly configured HELO, DKIM, Reverse DNS, SenderID, SPF and DMARC. I don't send out mass emails. My IP is from AWS, but it isn't on any publicly available blacklists. I have verified that everything is set up correctly using DKIMvalidator, MxToolBox and mail-tester.
Edit: for what it's worth, I finally got rid of the 127.0.0.1's in my headers and it did not resolve the issue for me.
Unfortunately, it depends...
Mail systems vary in how they are configured, and it is perfectly legitimate for an MUA (e.g. Thunderbird) to send outgoing mail to an MTA / mail server (e.g. exim) running on the same machine using the localhost address. Unusual, these days, but not "bad by definition".
When you say 'end up in the spam folder', what is it that puts it there: are you using a local mail server? if so is it that server that junks the mail (on send) or outlook.com itself (on receipt). Either way, what error messages or other failure information have you found?
Some random thoughts:
DKIM is a pain to set up correctly. Try disabling it entirely and see if that changes things in interesting ways.
Ditto DMARC.
Have you got SPF set up separately? If so, disable SPF and retry.
Is IPv6 involved in the mix at all? Various things are subtly different if so.
If outlook.com were to do sender verify callbacks (i.e. on receipt, check that mail from address was an acceptable recipient to your server) would it pass?
Is your email system sending RFC-conformant mail: that is, does it have a From: address, To: or Sender: address, Message-ID:, Date: headers and, if using MIME, Content-* headers (and probably a couple I forget!).
If changing DKIM / DMARC / SPF changes things (and remembering DNS timeouts, leave it a while between attempts), re-add SPF first - it is the simplest to get right.
127.0.0.1 can be flagged by Spam filters because it fails to provide an identity trace of the sender. Most common e-mail systems will show the IP address or the host name. The next item will be the recipient e-mail server.
For example:
Received: from [127.0.0.1] (81.27.148.196) by TAE1.agent.com.pk
What is funny about this one is that the top-level domain says it is received initially by a domain in Pakistan, but the IP address is registered to an entity in St. Petersburg, Russia.
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.