" Slowly, as time goes on we are getting more messages lost in spam filters that we are sending to clients.
I think it's because our SPF isn't set right."
Trouble shooting and error Reports:
I used the SPF wizard from:
http://www.spfwizard.net/
From kitterman.com:
http://www.kitterman.com/spf/validate.html
ISP used to block some info....
[The TXT records found for your domain are:
"v=spf1 mx a ip4:216.216.123.224.168/24 a:209.My outgoing WAN IP.2 include:cidc.telus.com ~all"
Checking to see if there is a valid SPF record.
No valid SPF record found of either type TXT or type SPF.]
Internally we send outgoing mail to 192.168.1.3, (it's a barracuda) it then sends to our ISP relay (smtp.ISP.net)
Our MX records seem fine. but the MX records are nto the senders of the outbound emails.
If I pull the header from a received email:
[Received: from smtp01.cidc.telus.com (smtp01.cidc.telus.com. [216.123.224.168])
by mx.google.com with ESMTP id rr4si1383765pac.48.2014.10.09.10.18.03
for <**"ME"**#gmail.com>;
Thu, 09 Oct 2014 10:18:04 -0700 (PDT)
Received-SPF: permerror (google.com: domain of **"ME"#"company"**.ca uses a mechanism not recognized by this client. unknown mechanisms: )) client-ip=216.123.224.168;
Authentication-Results: mx.google.com;
spf=permerror (google.com: domain of "ME"#"company".ca uses a mechanism not recognized by this client. unknown mechanisms: )) smtp.mail="ME"#"company".ca
Received: (qmail 25065 invoked from network); 9 Oct 2014 17:18:03 -0000
Received: from host2."WAN IP".209.in-addr.arpa (HELO smtp."company".ca) (209."WAN IP".2)]
Kinda Pulling my hair out on this.... Any ideas?
It appears that your SPF policy contains a syntax error. Such errors result in SPF "permerror", meaning the SPF evaluation fails. This alone should not cause your email to be blacklisted, but you may not receive a higher reputation score that might come with SPF "pass". In this sense, an invalid SPF policy may cause lower deliverability.
In any case, if your policy is anything like the one you posted
v=spf1 mx a ip4:216.216.123.224.168/24 a:<valid-ip> include:cidc.telus.com ~all"
then the issue is likely that the ip4 mechanism argument network-spec is invalid (216.216.123.224.168/24 should be just 216.123.224.168/24).
Also, the a mechanism argument must be a domain expression and not an IPv4 address, because the a mechanism verifies if the IP address being tested is among the IPs for the a mechanism argument domain.
If your actual SPF policy is different, please update your question with the current policy string and possibly the domain name to see how it is represented in DNS.
Related
I just setup our domain a couple weeks ago to use SPF and DMARC, but no DKIM atm. But every now an then I receive an DMARC Failure report from linkedin:
This is an email abuse report for an email message received from IP 213.160.4.146 on Tue, 16 Jul 2019 12:34:26 +0000.
The message below did not meet the sending domain's dmarc policy.
The message below could have been accepted or rejected depending on policy.
For more information about this format please see http://tools.ietf.org/html/rfc6591 .
Feedback-Type: auth-failure
User-Agent: Lua/1.0
Version: 1.0
Original-Mail-From:
Original-Rcpt-To: messages-noreply#linkedin.com
Arrival-Date: Tue, 16 Jul 2019 12:34:26 +0000
Message-ID: <5cd…8b2f#SR-EXC.biv.local>
Authentication-Results: dmarc=fail (p=none; dis=none) header.from=biv-ot.org
Source-IP: 213.160.4.146
Delivery-Result: delivered
Auth-Failure: dmarc
Reported-Domain: biv-ot.org
But I can't detect any error - the IP address and domain match our MX record which is included in the SPF entry. Also the referenced RFC 6591 doesn't include the auth faile "dmarc". I get this mail round about once a week and no other server send me ever an DKIM failure report. Any idea whats wrong?
DNS Entries:
biv-ot.org:
MX: mail.biv-ot.org
A: 148.251.171.224
SPF: v=spf1 a mx include:ot-live.zms.hosting a:mout.kundenserver.de ~all
DMARC: v=DMARC1; p=none; ruf=mailto:…; fo=s
mail.biv-ot.org:
A: 213.160.4.146
This behavior is often witnessed with automated responses, such as NDRs and Out of Office replies, from mail servers as described in the Simple Mail Transfer Protocol (SMTP) RFC, section 4.5.5
In these cases the smtp.mailfrom field is empty and in most SPF implementations the check falls back to checking the HELO identity (recommended), as described in the SPF RFC, section 2.4.
Even if you create an SPF record for the HELO identity, you may still fail DMARC (on SPF) because of misalignment, if the HELO identity does not share the organizational domain of Header.From address.
In your specific case, the HELO identity would be assumed as postmaster#firewall.biv-ot.org and the reported domain (Header.From) is set to: biv-ot.org. This means that publishing an SPF record for firewall.biv-ot.org would solve your issue.
Also note: You only publish a ruf= address in your DMARC policy. Almost no mailbox providers send forensic/failure reports, so it is not wise to rely on only these reports to judge whether or not your email authentication practices are in a good state.
These blogs by Dmarcian and Valimail outline why these forensic / failure reports are so scarce.
I run a mailserver off Postfix on an Ubuntu 16.04 Droplet on DigitalOcean. The mailserver is a (closed) SMTP relay that uses mail client interfaces like Gmail and Hotmail to send emails from my domain (let's call it example.com). It has SPF, DKIM and DMARC set up, so emails from my domain are not marked as spam by Hotmail and Gmail.
I've recently been receiving messages from my Postfix Mail Daemon that have smtp.mailfrom=double-bounce#mail.example.com headers. These emails have been failing SPF and DMARC tests.
A possible reason why these emails are failing tests might be because my SPF records only list SPF records for example.com. But why is it that Postfix Mailer Daemon sends emails as #mail.example.com instead of #example.com? In Postfix, my myorigin attribute is set as example.com, and the documentation says that the double-bounce address is set as double-bounce#$myorigin.
Is it possible that these emails from Mailer Daemon that I am receiving are spoofed? I would like some insight on why my SPF and DMARC headers failed. Included are the important parts of my mail header below.
P.S. 1.2.3.4 is my mailserver IP and the IP that has been whitelisted on my domain SPF record.
Received: from mail.example.com ([1.2.3.4])
by mx.google.com with ESMTPS id r25-v6si17553370pfk.83.2018.10.27.22.06.59
for <example#gmail.com>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 27 Oct 2018 22:06:59 -0700 (PDT)
Received-SPF: neutral (google.com: 1.2.3.4 is neither permitted nor denied by best guess record for domain of double-bounce#mail.example.com) client-ip=1.2.3.4;
Authentication-Results: mx.google.com;
spf=neutral (google.com: 1.2.3.4 is neither permitted nor denied by best guess record for domain of double-bounce#mail.example.com) smtp.mailfrom=double-bounce#mail.example.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com
Received: by mail.example.com (Postfix) id 7CDB5120787; Sun, 28 Oct 2018 13:06:58 +0800 (+08)
Date: Sun, 28 Oct 2018 13:06:58 +0800 (+08)
From: Mail Delivery System <MAILER-DAEMON#example.com>
It's not sending as mail.example.com, that's just the name of the host that's sending the message. As the headers say, it's using that as a "best guess". The hostname looks like it's fetched from the reverse lookup on your IP, which should match your SMTP EHLO host name - so make sure it does. Also check what the return path header ends up as on the receiver - if you're seeing <> in there, you know these are real bounces. I'd suggest inspecting the traffic on outbound from your mail server so you can be sure what's happening in SMTP.
Bounces commonly have an empty return-path (<>) and so the SPF result falls back to the check for the HELO name, as is described in sections 2.3 and 2.4 of RFC 7208. Adding an SPF record for your hosts, used in the HELO identity should change the result from "best guess" (usually in case of absence of a record) to an actual result.
Section 2.3:
It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
identity but also separately check the "HELO" identity[...]
and Section 2.4:
SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check
either has not been performed or has not reached a definitive policy
result by applying the check_host() function to the "MAIL FROM"
identity as the .
[RFC5321] allows the reverse-path to be null (see Section 4.5.5 in
[RFC5321]). In this case, there is no explicit sender mailbox, and
such a message can be assumed to be a notification message from the
mail system itself. When the reverse-path is null, this document
defines the "MAIL FROM" identity to be the mailbox composed of the
local-part "postmaster" and the "HELO" identity (which might or might
not have been checked separately before).
I have a VPS, where we have hosted multiple domains. We are facing problem with our email, as emails from few of our domains are always delivering in spam box in gmail. We have added DKIM and SPF for all of the domains. After failing to fix the issue from my end, I had tried to contact with my hosting provider too(Host IT Smart). They are also unable to find out any solution yet. Can you please suggest me to fix this issue. Below are the response from verifier.port25.com
This message is an automatic response from Port25's authentication verifier
service at verifier.port25.com. The service allows email senders to perform
a simple check of various sender authentication mechanisms. It is provided
free of charge, in the hope that it is useful to the email community. While
it is not officially supported, we welcome any feedback you may have at
<verifier-feedback#port25.com>.
Thank you for using the verifier,
The Port25 Solutions, Inc. team
==========================================================
Summary of Results
==========================================================
SPF check: pass
DomainKeys check: neutral
DKIM check: pass
Sender-ID check: pass
SpamAssassin check: ham
==========================================================
Details:
==========================================================
HELO hostname: vps.technowebs.in
Source IP: 23.236.190.220
mail-from: support#easyretail.in
----------------------------------------------------------
SPF check details:
----------------------------------------------------------
Result: pass
ID(s) verified: smtp.mailfrom=support#easyretail.in
DNS record(s):
easyretail.in. SPF (no records)
easyretail.in. 11089 IN TXT "v=spf1 +a +mx +23.236.190.220 ~all"
easyretail.in. 0 IN A 23.236.190.220
----------------------------------------------------------
DomainKeys check details:
----------------------------------------------------------
Result: neutral (message not signed)
ID(s) verified: header.From=support#easyretail.in
DNS record(s):
----------------------------------------------------------
DKIM check details:
----------------------------------------------------------
Result: pass (matches From: support#easyretail.in)
ID(s) verified: header.d=easyretail.in
Canonicalized Headers:
date:Fri,'20'26'20'Feb'20'2016'20'20:12:29'20'+0530'0D''0A'
from:support#easyretail.in'0D''0A'
to:<check-auth#verifier.port25.com>'0D''0A'
subject:t'0D''0A'
dkim-signature:v=1;'20'a=rsa-sha256;'20'c=relaxed/simple;'20'd=easyretail.in;'20's=default;'20't=1456497749;'20'bh=nosD6jtIMS+OOhW+x6qFyWo2Lid2rGvD39dKQAIrzIo=;'20'h=Date:From:To:Subject;'20'b=
Canonicalized Body:
t'0D''0A'
DNS record(s):
default._domainkey.easyretail.in. 14400 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsF6ZDVntzQYgh7niTVm4zEGxx3tpKuRDEtjj2lCNSGotO409tcZNAf2TZwsXCMRqOFmlgcRbbvGCI3Ze1l4EiW/msO2/KpFnf0mJ0iDQ4GH7zj7WBIql+yoZAaoYmyYsX7RWeVn9J+yYQcjSYL8/znm1nVZVwi8LLGRyB8+O4ZQIDAQAB"
Public key used for verification: default._domainkey.easyretail.in (1024 bits)
NOTE: DKIM checking has been performed based on the latest DKIM specs
(RFC 4871 or draft-ietf-dkim-base-10) and verification may fail for
older versions. If you are using Port25's PowerMTA, you need to use
version 3.2r11 or later to get a compatible version of DKIM.
----------------------------------------------------------
Sender-ID check details:
----------------------------------------------------------
Result: pass
ID(s) verified: header.From=support#easyretail.in
DNS record(s):
easyretail.in. SPF (no records)
easyretail.in. 11089 IN TXT "v=spf1 +a +mx +23.236.190.220 ~all"
easyretail.in. 0 IN A 23.236.190.220
----------------------------------------------------------
SpamAssassin check details:
----------------------------------------------------------
SpamAssassin v3.4.0 (2014-02-07)
Result: ham (-2.0 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.0 BODY_SINGLE_WORD Message body is only one word (no spaces)
==========================================================
Explanation of the possible results (from RFC 5451)
==========================================================
SPF and Sender-ID Results
=========================
"none"
No policy records were published at the sender's DNS domain.
"neutral"
The sender's ADMD has asserted that it cannot or does not
want to assert whether or not the sending IP address is authorized
to send mail using the sender's DNS domain.
"pass"
The client is authorized by the sender's ADMD to inject or
relay mail on behalf of the sender's DNS domain.
"policy"
The client is authorized to inject or relay mail on behalf
of the sender's DNS domain according to the authentication
method's algorithm, but local policy dictates that the result is
unacceptable.
"fail"
This client is explicitly not authorized to inject or
relay mail using the sender's DNS domain.
"softfail"
The sender's ADMD believes the client was not authorized
to inject or relay mail using the sender's DNS domain, but is
unwilling to make a strong assertion to that effect.
"temperror"
The message could not be verified due to some error that
is likely transient in nature, such as a temporary inability to
retrieve a policy record from DNS. A later attempt may produce a
final result.
"permerror"
The message could not be verified due to some error that
is unrecoverable, such as a required header field being absent or
a syntax error in a retrieved DNS TXT record. A later attempt is
unlikely to produce a final result.
DKIM and DomainKeys Results
===========================
"none"
The message was not signed.
"pass"
The message was signed, the signature or signatures were
acceptable to the verifier, and the signature(s) passed
verification tests.
"fail"
The message was signed and the signature or signatures were
acceptable to the verifier, but they failed the verification
test(s).
"policy"
The message was signed but the signature or signatures were
not acceptable to the verifier.
"neutral"
The message was signed but the signature or signatures
contained syntax errors or were not otherwise able to be
processed. This result SHOULD also be used for other
failures not covered elsewhere in this list.
"temperror"
The message could not be verified due to some error that
is likely transient in nature, such as a temporary inability
to retrieve a public key. A later attempt may produce a
final result.
"permerror"
The message could not be verified due to some error that
is unrecoverable, such as a required header field being
absent. A later attempt is unlikely to produce a final result.
==========================================================
Original Email
==========================================================
Return-Path: <support#easyretail.in>
Received: from vps.technowebs.in (23.236.190.220) by verifier.port25.com id hq1i5c20i3gi for <check-auth#verifier.port25.com>; Fri, 26 Feb 2016 09:42:30 -0500 (envelope-from <support#easyretail.in>)
Authentication-Results: verifier.port25.com; spf=pass smtp.mailfrom=support#easyretail.in
Authentication-Results: verifier.port25.com; domainkeys=neutral (message not signed) header.From=support#easyretail.in
Authentication-Results: verifier.port25.com; dkim=pass (matches From: support#easyretail.in) header.d=easyretail.in
Authentication-Results: verifier.port25.com; sender-id=pass header.From=support#easyretail.in
Received: from www.easyretail.in (localhost.localdomain [127.0.0.1])
by vps.technowebs.in (Postfix) with ESMTPA id 8C6093C2593
for <check-auth#verifier.port25.com>; Fri, 26 Feb 2016 20:12:29 +0530 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=easyretail.in;
s=default; t=1456497749;
bh=nosD6jtIMS+OOhW+x6qFyWo2Lid2rGvD39dKQAIrzIo=;
h=Date:From:To:Subject;
b=L/XoimrjmAdUbjHxyfObm/LTNlJ25vRQCV91JBE+lv82/WLMCOGSLP56LULw1DvWC
aDM9rpn3oIaS6Pw+Iqo120fFjvbhH1WotrmoknGEVDsqBPh1V0UYFoA7hVkLeUcoIi
y0ZVzMDvcDIjQxN0v+vcqdJ5K10WYUJ7uCOqZHO8=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 26 Feb 2016 20:12:29 +0530
From: support#easyretail.in
To: <check-auth#verifier.port25.com>
Subject: t
Message-ID: <f3def6547d7c92cb00e29668a7bf7ded#easyretail.in>
X-Sender: support#easyretail.in
User-Agent: Roundcube Webmail/0.8.5
Thanks in advance for your help.
Best Regards,
Rajib Deb
gmail has its own spam detection system, and your DNS/mail server configuration looks good and solid. From those facts I would assume that
- either you're sending (as a message subject/body) something that is considered as SPAM-related by gmail
- or your domain/ip address has a bad history with gmail (let's say during the process of configuration of your server you've tried to send some test emails with not properly configured mail domain too early). Gmail has recorded those bad attempts, and due to the past history considers them as spam.
I would suggest to send several emails to your own gmail account, and remove those emails from spam folder there (not a spam), that might tell the gmail spam detection engine to stop considering the emails coming from your domain as SPAM.
Gmail have now a postmaster tool you can check your domain/ip Reputation history, spam rate and in the "Authentication" area you can check DKIM/SPF/DMARC works correctly.
https://gmail.com/postmaster/
I recommend to use the CNAME record for authentication, if you are using the default TXT record also on SPF query this entry return.
We recently implemented a DMARC record for our domain:
"v=DMARC1; p=quarantine; pct=100; rua=mailto:me#mydomain.com"
(quarantine 100% of non-authenticated emails and send aggregate report to "me")
We use a third-party vendor to issue invites. The vendor sends email from invites#invites.vendordomain.com which is then sent through a mail relay "smtp3.mailrelaydomain.it". I also know that the mail relay uses a single ip address.
That address is included in our SPF record:
"v=spf1 ...[SNIP reference for other mail servers SNIP]... ip4:[ip address for the mail relay] ~all"
When I send an invite using the vendor's service, the message is quarantined.
When I view the aggregate DMARC report I see that the invite:
is recognized as being from an SPF-Authorized Server
passes raw SPF authentication for the sender's domain (invites#invites.vendordomain.com")
passes raw DKIM authentication for the mail relay domain (smtp3.mailrelaydomain.it)
Fails DMARC authentication for both DKIM and SPF for mydomain
Here is a sample headers from an invite.
BEGIN SAMPLE EMAIL HEADER
Delivered-To: someone#mydomain.com
Received: by 10.64.252.9 with SMTP id zo9csp100581iec;
Wed, 21 Oct 2015 11:40:13 -0700 (PDT)
X-Received: by 10.55.195.147 with SMTP id r19mr12995508qkl.12.1445452813709;
Wed, 21 Oct 2015 11:40:13 -0700 (PDT)
Return-Path: <invites#invites.vendordomain.com>
Received: from smtp3.mailrelaydomain.it (smtp3.mailrelaydomain.it. [ip for mail relay])
by mx.google.com with ESMTP id w15si9297939qha.131.2015.10.21.11.40.13
for <someone#mydomain.com>;
Wed, 21 Oct 2015 11:40:13 -0700 (PDT)
Received-SPF: pass (google.com: domain of invites#invites.vendordomain.com designates [mail relay ip] as permitted sender) client-ip=[mail relay ip];
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of invites#invites.vendordomain.com designates [mail relay ip] as permitted sender) smtp.mailfrom=invites#invites.vendordomain.com;
dkim=pass header.i=#mailrelaydomain.it;
dmarc=fail (p=QUARANTINE dis=QUARANTINE) header.from=mydomain.com
Received: from FS-S05.vendorparentdomain.com (unknown [vendor parent ip])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by smtp3.mailrelaydomain.it (Postfix) with ESMTPSA id 23387A0CBC
for <someone#mydomain.com>; Wed, 21 Oct 2015 15:07:35 -0400 (EDT)
DKIM-Signature: [DKIM Content]
Content-Type: multipart/alternative;
boundary="===============2166944298367943586=="
MIME-Version: 1.0
Subject: Please take our survey
From: Me <me#mydomain.com>
To: Someone Else <someone#mydomain.com>
Cc:
Date: Wed, 21 Oct 2015 18:39:48 -0000
Message-ID: <20151021183948.27448.90706#FS-S05.vendorparentdomain.com>
List-Unsubscribe: [unsubscribe link],
<mailto:invites#invites.vendordomain.com>
Reply-To: Me <me#mydomain.com>
X-Sender: invites#invites.vendordomain.com
I believe the issue is related to the from domain in the message not matching the domain for the message envelope; however, the vendor is unable to change their settings (i.e., envelope will always be from the vendor domain) so any chance of this working with DMARC will have to come from my end.
Knowing that the SPF record can (and does) identify the invite as being from an SPF-Authorized Server, are there any other settings or records I can add to also ensure DMARC authentication for invites from the vendor?
Having read several online articles and "DMARC -spf and DKIM record queries" I suspect I am out of luck, but need to ask the question plainly/specific to my situation just to be sure.
Thanks
You are correct, you are out of luck unless the vendor can change something. What is failing is Identifier Alignment - https://www.rfc-editor.org/rfc/rfc7489#section-3.1 - because what is being authenticated (invites.vendordomain.com via SPF) does not align to the domain the user sees (me#mydomain.com) and the message then, correctly, fails DMARC.
There are three options:
Stop sending with a From: header of your domain at the vendor; you can still use a Reply-To: header with your own address.
Have the vendor align the mail from to your domain. If they don't do this they can't pass DMARC, and at some point they will want to pass DMARC or people will find other solutions. You can have them send with an envelope from of vendorname.mydomain.com and you can set up an MX for that subdomain that points to them to support bounce processing. This has been BCP for a while.
Have the vendor sign with DKIM and us an aligned DKIM signature. This is also best common practice. You only need SPF or DKIM to pass, and DKIM passes are more valuable (because they survive forwarding in many cases) than SPF, so this is the option I would personally prioritize if I were you.
Back in like 2012 and 2013 a lot of vendors pushed back against both of these options, but I honestly haven't seen a vendor in a long time (I spend 100% of my day job on DMARC) that won't support at least aligned DKIM.
I've got a problem with Gmail.
It started after one of our trojan infected PCs sent spam for one day from our IP address.
We've fixed the problem, but we got into 3 black lists. We've fixed that, too. But still every time we send an email to Gmail the message is rejected:
So I've checked Google Bulk Sender's guide once again and found an error in our SPF record and fixed it. Google says everything should become fine after some time, but this doesn't happen. 3 weeks already passed but we still can't send emails to Gmail.
Our mail setup is a bit complex, but not too much. We have a domain name delo-company.com, it has it's own mail #delo-company.com (this one is fine, but the problems are with sub-domain name corp.delo-company.com).
Delo-company.com domain has several DNS records fro its subdomain:
corp A 82.209.198.147
corp MX 20 corp.delo-company.com
corp.delo-company.com TXT "v=spf1 ip4:82.209.198.147 ~all"
(I set ~all for testing purposes only, it was -all before that)
These records are for our corporate Exchange 2003 server at 82.209.198.147. Its LAN name is s2.corp.delo-company.com so its HELO/EHLO greetings are also s2.corp.delo-company.com.
To pass EHLO check we've also created some records in delo-company.com's DNS:
s2.corp A 82.209.198.147
s2.corp.delo-company.com TXT "v=spf1 ip4:82.209.198.147 ~all"
As I understand SPF verifications should be passed in this way:
Out server s2 connects to MX of the recepient (Rcp.MX): EHLO s2.corp.delo-company.com
Rcp.MX says Ok, and makes SPF check of HELO/EHLO. It does NSlookup for s2.corp.delo-company.com and gets the above DNS-records. TXT records says that s2.corp.delo-company.com should be only from IP 82.209.198.147. So it should be passed.
Then our s2 server says RCPT FROM: <supruniuk-p#corp.delo-company.com>
Rcp.MX` server checks it, too. The values are the same so they should also be positive.
Maybe there is also a rDNS check, but I'm not sure what is checked HELO or RCPT FROM.
Our PTR record for 82.209.198.147 is:
147.198.209.82.in-addr.arpa. 86400 IN PTR s2.corp.delo-company.com.
To me everything looks fine, but anyway all emails are rejected by Gmail.
So, I've checked MXtoolbox.com - it says everything is fine, I passed http://www.kitterman.com/spf/validate.html Python check, I did 25port.com email test. It's fine, too:
Return-Path: <supruniuk-p#corp.delo-company.com>
Received: from s2.corp.delo-company.com (82.209.198.147) by verifier.port25.com id ha45na11u9cs for <check-auth#verifier.port25.com>; Fri, 2 Mar 2012 13:03:21 -0500 (envelope-from <supruniuk-p#corp.delo-company.com>)
Authentication-Results: verifier.port25.com; spf=pass smtp.mailfrom=supruniuk-p#corp.delo-company.com
Authentication-Results: verifier.port25.com; domainkeys=neutral (message not signed) header.From=supruniuk-p#corp.delo-company.com
Authentication-Results: verifier.port25.com; dkim=neutral (message not signed)
Authentication-Results: verifier.port25.com; sender-id=pass header.From=supruniuk-p#corp.delo-company.com
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01CCF89E.BE02A069"
Subject: test
Date: Fri, 2 Mar 2012 21:03:15 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <4C9EB1DB67831A428B2E14052F4A418707E1FF#s2.corp.delo-company.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: test
Thread-Index: Acz4jS34oznvbyFQR4S5rXsNQFvTdg==
From: =?koi8-r?B?89XQ0tXOwMsg8MHXxcw=?= <supruniuk-p#corp.delo-company.com>
To: <check-auth#verifier.port25.com>
I also checked with spf-test#openspf.net, but it FAILs all the time, no matter which SPF records I make:
<s2.corp.delo-company.com #5.7.1 smtp;550 5.7.1 <spf-test#openspf.net>: Recipient address rejected: SPF Tests: Mail-From Result="softfail": Mail From="supruniuk-p#corp.delo-company.com" HELO name="s2.corp.delo-company.com" HELO Result="softfail" Remote IP="82.209.198.147">
I've filled Gmail form twice, but nothing happens.
We do not send spam, only emails for our clients. 2 or 3 times we did mass emails (like New Year Greetings and sales promos) from corp.delo-company.com addresses, but they where all complying to Gmail Bulk Sender's Guide (I mean SPF, Open Relays, Precedence: Bulk and Unsubscribe tags). So, this should be not a problem.
Please, help me. What am I doing wrong?
I've been having serious problems with gmail rejecting legitimate mail. Somewhere I read a suggestion to delete URLs from your signature file. To my amazement, this worked. (My mail client is Eudora, which some of you may dimly remember.)
Hope it helps.
Gmail have now a postmaster tool you can check your domain/ip reputation, spam rate and in the "Authentication" area you can check DKIM/SPF/DMARC works correctly.
https://gmail.com/postmaster/
I recommend to use the CNAME record for authentication, if you are using the default TXT record also on SPF query this entry return.