After searching for a while and reading a lot of examples, cases and/or answer on Google and Stackoverflow, I didn't find a solution for my problem. I'm more and more confused with the notion of SPF and relay, so I'm asking my question here hoping to receive a proper answer and understand once for ever !
In summary :
I have a current main server with a mailserver installed on it (postfix + dovecot + vimbadmin), on domain exampleA.com.
I have a new server for a new website, with a new domain exampleB.com.
My goal is that all the emails of the new website (XXXX[AT]exampleB.com) have to be sent & received using the main server.
Knowing that the mainserver has to send the emails of exampleB.com, I modified the SPF entry of exampleB.com to allow the main server to send emails of exampleB.com.
The mails are sent OK and I receive the emails OK, but when I look the original sources of email in Gmail :
Return-Path: <root#FQDN_NEW_SERVER>
Received: from mail.exampleA.com (FQDN_MAIN_SERVER [IP_MAIN_SERVER])
by mx.google.com with ESMTPS id f64si6392532wma.52.2016.05.20.04.59.06
for <xxxxxxx#gmail.com>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 20 May 2016 04:59:06 -0700 (PDT)
Received-SPF: neutral (google.com: IP_MAIN_SERVER is neither permitted nor denied by best guess record for domain of root#FQDN NEW SERVER) client-ip=IP MAIN SERVER;
Authentication-Results: mx.google.com;
spf=neutral (google.com: IP MAIN SERVER is neither permitted nor denied by best guess record for domain of root#FQDN NEW SERVER) smtp.mailfrom=root#IP MAIN SERVER
Received: from FQDN NEW SERVER (REVERSEDNS_NEW_SERVER [IP_NEW_SERVER])
by mail.exampleA.com (Postfix) with ESMTPA id 67C8C60421;
Fri, 20 May 2016 13:59:06 +0200 (CEST)
Received: by FQDN_NEW_SERVER (Postfix, from userid 0)
id A1949A07AB; Fri, 20 May 2016 13:58:57 +0200 (CEST)
I'm getting more and more confused which SPF I have to modify, and which MX is pointing to who..
Edit : It seems that I have a connection timed out when my main server tries to connect to my new server on port 25, but with telnet it seems ok..
Edit2 : I know that my DNS and my Reverse DNS are not the same.. My server is an instance in a public cloud, and I can't change my reverse since it's configured in the virtual router.
Edit3 : I have this error in the main server postfix logs :
May 20 16:25:40 ns33rgdrg4 postfix/smtpd[2956]: NOQUEUE: reject_warning: RCPT from csikxdqzdqzdqzdqzdqzress.com[IP_NEW_SERV]: 450 4.1.7 <root#FQDN_NEW_SERVER>: Sender address rejected: unverified address: connect to FQDN_NEW_SERV[IP_NEW_SERV]:25: Connection timed out; from=<root#FQDN_NEW_SERV> to=<myownmail#owndomain.com> proto=ESMTP helo=<FQDN_NEW_SERV>
Here is the current configuration of servers :
Server Main
Dovecot + Postfix configured
Domain : exampleA.com
DNS :
- exampleA.com. MX mail.exampleA.com
- mail.exampleA.com A IP_MAIN_SERVER
- exampleA.com. SPF "v=spf1 a mx ptr include:spf4.newsletterpartner.net ~all"
New server
Postfix installed, normally why relayhost = mail.exampleA.com
Domain : exampleB.com
DNS :
- exampleB.com. MX mail.exampleA.com
- exampleB.com. SPF "v=spf1 mx:mail.exampleA.com mx:exampleA.com include:mail.exampleA.com include:exampleA.com ~all"
The MX of my new domain is pointing to the MX of my main server (I don't know if it is the good thing to do)
Here is the a part of the new server /etc/postfix/main.cf :
myhostname = FQDN_NEW_SERVER
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
relayhost = mail.exampleA.com
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
We can see that the new server has his postfix relayhost pointing to the MX of my mainserver.
I don't know if the MX of my new server has to point to himself (knowing that its own postfix has a relayhost configured), or if it has to be configured directly to the main server which will send the emails.
NB : I have this error : No SPF records found for mail.exampleA.com when I check with a website looking for MX and SPF, but exampleA.com has a MX, not mail.exampleA.com
It's driving me crazy for days now... Thanks in advance for your little helps guys :)
Regards,
Julien Q.
Ok I think it is finally solved thanks to you #henry !
In the file /etc/postfix/main.cf, myorigin was /etc/mailname, which was my FQDN.
Since Google was checking, as he says, a "record for domain of root#FQDN_NEW_SERVER", I though he had to check root#DOMAIN, and not FQDN. Google was also saying "IP_MAIN_SERVER is neither permitted nor denied by guest" so instead of putting the MX main server in my new server SPF, I put the main server IP in IPV4.
I changed myorigin from FQDN_NEW_SERVER to DOMAIN_NEW_SERVER instead, and specified my relayhost IPV4 in my new server SPF. After checking with your method AND gmail, everything seems OK now !
So here is the final configuration of my infrastructure.
Main server, Relay SMTP
Dovecot + Postfix configured
Domain : exampleA.com
DNS :
- exampleA.com. MX mail.exampleA.com
- mail.exampleA.com A IP_MAIN_SERVER
- exampleA.com. SPF "v=spf1 a mx ptr include:spf4.newsletterpartner.net ~all"
New server, forwarding emails to the main server
Domain : exampleB.com
DNS :
- exampleB.com. MX mail.exampleA.com
- exampleB.com. SPF "v=spf1 ip4:IP_MAIN_SERVER -all"
New server /etc/postfix/main.cf
myhostname = FQDN_NEW_SERVER
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
#myorigin = /etc/mailname <-- OLD CONF with FQDN_NEW_SERVER in
myorigin = exampleB.com
mydestination =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
relayhost = mail.exampleA.com
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
Gmail original sources
Received: from MX_MAIN_SERVER (FQDN_MAIN_SERVER [IP_MAIN_SERVER])
by mx.google.com with ESMTPS id s5si18916426wme.105.2016.05.16.02.06.09
for <FROM_EMAIL_ADDRESS>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 16 May 2016 02:06:09 -0700 (PDT)
Received-SPF: pass (google.com: domain of RECEIVER_EMAIL_ADDRESS designates IP_MAIN_SERVER as permitted sender) client-ip=IP_MAIN_SERVER;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of RECEIVER_EMAIL_ADDRESS designates IP_MAIN_SERVER as permitted sender) smtp.mailfrom=FROM_EMAIL_ADDRESS
Hoping it can help someone else than me.
Thanks again guys !
Julien Q.
I think you made a typo, can you please confirm..
Domain : exampleB.com
DNS :
- exampleB.com. MX mail.exampleA.com
- exampleA.com. SPF "v=spf1 mx:mail.exampleA.com mx:exampleA.com include:mail.exampleA.com include:exampleA.com ~all"
On the bottom I think ExampleA.com. should read ExampleB.com.
And your SPF record should read
"v=spf1 mx ~all"
Since your MX record is mail.exampleA.com, that's all you have to specify in your SPF.
Your timeout issue I think might be related to DoveCot, DoveCot has a long connection time associated to it 18+ seconds. I'm not a linux person, so I really can't point you where to look for timeout settings.
Instead of testing with gmail you can test by sending an email to mailtest#unlockthienbox.com all basic authentication results are displayed (SPF, DKIM, Etc.)
Related
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'm using phpMailer on a Linode server. The DNS records are set to allow sending through the gmail mail server which is hosing my mail account membership#oiyc.org. I just added DKIM to try to get the SPF rating up. The DKIM apparently is fine but I still get SPF Neutral.
The sender set up is:
$mail = new PHPMailer();
$mail->isSMTP();
$mail->SMTPKeepAlive = true;
$mail->SMTPAuth = true;
$mail->SMTPSecure = "tls"; // sets the prefix to the server
$mail->Host = "smtp.gmail.com"; // sets GMAIL as the SMTP server
$mail->Port = 587; // set the SMTP port
$mail->Username = "membership#oiyc.org"; // GMAIL username
$mail->Password = "*******************"; // GMAIL password
$mail->isHTML(true); // send as HTML
$mail->WordWrap = 100; // set word wrap
$mail->Sender = "membership#oiyc.org";
$mail->addReplyTo($_SESSION['se-reply'],$_SESSION['se-from']);
$mail->setFrom($_SESSION['se-reply'],$_SESSION['se-from']);
$mail->DKIM_domain = "oiyc.org";
$mail->DKIM_private = "*********/rsa.private"; //path to file on the disk.
$mail->DKIM_selector = "mainkey";// change this to whatever you set during step 2
$mail->DKIM_passphrase = "";
$mail->DKIM_identity = $mail->Sender;
Here is the source received from an email sent through my linode server.
Delivered-To: ********#gmail.com
Received: by 10.46.25.85 with SMTP id p82csp1388830lje;
Sun, 4 Feb 2018 11:11:56 -0800 (PST)
X-Received: by 10.98.196.204 with SMTP id h73mr11556131pfk.143.1517771515865;
Sun, 04 Feb 2018 11:11:55 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1517771515; cv=none;
d=google.com; s=arc-20160816;
b=*****
qrIA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=content-transfer-encoding:mime-version:list-unsubscribe:message-id
:subject:reply-to:to:date:from:dkim-signature
:arc-authentication-results;
bh=ptVvqh2PiSco0+Kb7wjBXHUijnbEm43LU4E+zStVvb0=;
b=********
iuTg==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=#oiyc-org.20150623.gappssmtp.com header.s=20150623 header.b=ytsz7YWm;
spf=neutral (google.com: 209.85.220.41 is neither permitted nor denied by best guess record for domain of membership#oiyc.org) smtp.mailfrom=membership#oiyc.org
Return-Path: <membership#oiyc.org>
Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41])
by mx.google.com with SMTPS id i3sor1037208pgs.91.2018.02.04.11.11.55
for <********#gmail.com>
(Google Transport Security);
Sun, 04 Feb 2018 11:11:55 -0800 (PST)
Received-SPF: neutral (google.com: 209.85.220.41 is neither permitted nor denied by best guess record for domain of membership#oiyc.org) client-ip=209.85.220.41;
Authentication-Results: mx.google.com;
dkim=pass header.i=#oiyc-org.20150623.gappssmtp.com header.s=20150623 header.b=ytsz7YWm;
spf=neutral (google.com: 209.85.220.41 is neither permitted nor denied by best guess record for domain of membership#oiyc.org) smtp.mailfrom=membership#oiyc.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=oiyc-org.20150623.gappssmtp.com; s=20150623;
h=from:date:to:reply-to:subject:message-id:list-unsubscribe
:mime-version:content-transfer-encoding;
bh=ptVvqh2PiSco0+Kb7wjBXHUijnbEm43LU4E+zStVvb0=;
b=*********
SsBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:date:to:reply-to:subject:message-id
:list-unsubscribe:mime-version:content-transfer-encoding;
bh=ptVvqh2PiSco0+Kb7wjBXHUijnbEm43LU4E+zStVvb0=;
b=*************
r+zA==
X-Gm-Message-State: AKwxytcQCxD/95gmJfS/DyCC4XOh8K3K+Jj9QONeHmVyCH5ebJDtxvIl tQwyBjpS9etVQopYODbtnZZ2Kw0k1Pc=
X-Google-Smtp-Source: AH8x227kdTn+9Ee7QoJFUYDPq/ax7LmKHzsDAtCNr/5cL0MidmAB3GWuEw4RU28Zb3jl8Kx0uAnegw==
X-Received: by 10.99.96.80 with SMTP id u77mr6305435pgb.401.1517771515191;
Sun, 04 Feb 2018 11:11:55 -0800 (PST)
Return-Path: <membership#oiyc.org>
Received: from oiyc.org ([2600:3c01::f03c:91ff:fe56:5129])
by smtp.gmail.com with ESMTPSA id m65sm14046167pfc.150.2018.02.04.11.11.54
for <********#gmail.com>
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Sun, 04 Feb 2018 11:11:54 -0800 (PST)
From: Bob Brunius <membership#oiyc.org>
X-Google-Original-From: Bob Brunius <********#gmail.com>
Date: Sun, 4 Feb 2018 11:11:53 -0800
To: ********#gmail.com
Reply-To: Bob Brunius <********#gmail.com>
Subject: A different sort of test 123d
Message-ID: <MR3sDgtyN4siuc2vYCZLxL34VuLFlexvK0WbbcEH7FA#oiyc.org>
X-Mailer: PHPMailer 6.0.3 (https://github.com/PHPMailer/PHPMailer)
List-Unsubscribe: <information#oiyc.org>, <https://oiyc.org/membershipDatabaseForms/unsubscribe.php?email=********#gmail.com&member=242>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_MR3sDgtyN4siuc2vYCZLxL34VuLFlexvK0WbbcEH7FA"
Content-Transfer-Encoding: 8bit
--b1_MR3sDgtyN4siuc2vYCZLxL34VuLFlexvK0WbbcEH7FA
Content-Type: text/plain; charset=us-ascii
Hello 12345678-abcd
--b1_MR3sDgtyN4siuc2vYCZLxL34VuLFlexvK0WbbcEH7FA
Content-Type: text/html; charset=us-ascii
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<body>
Hello 12345678-abcd
</body>
</html>
--b1_MR3sDgtyN4siuc2vYCZLxL34VuLFlexvK0WbbcEH7FA--
Currently your SPF record is published in your DNS as...
"v=spf1 include:_spf.google.com include:oiyc.org ~all"
which has an include:oiyc.org recursively referencing itself. This is technically incorrect, but strangely may work if the preceding mechanism include:_spf.google.com is satisfied and returns a result to the SPF query. Therafter the include:oiyc.org mechanism will cause the lookup to fail, so the ~all mechanism would never be processed.
The include: mechanism is intended to reference an externally published set of SPF details, usually at a different domain.
I suspect that you intended to reference the IP address of your own domain, presumably defined in DNS as an A record for the bare domain name, in which case you would us the mechanism a:oiyc.org which can itself be shortened to just a
So your resulting TXT record might be something like...
"v=spf1 include:_spf.google.com a ~all"
There is no connection between using DKIM and SPF.
From the log:
Received-SPF: neutral (google.com: 209.85.220.41 is neither permitted nor denied by best guess record for domain of membership#oiyc.org) client-ip=209.85.220.41;
When checking for the SPF record, this happens:
$ host -t TXT oiyc.org
oiyc.org has no TXT record
This means, you haven't set up any SPF rules. Therefore, there cannot be a SPF check. As the message states, there is no reason to have anything other than neutral.
This also applies to ARC-Authentication-Results and Authentication-Results headers.
The SPF that was supposed to add for the current IP listed is
# TXT "v=spf1 a ip4:209.85.220.41 ~all"
visit this link to create and the SPF : https://mxtoolbox.com/SPFRecordGenerator.aspx
It has been a while since this post. But in case this helps anyone. If you already have your MX record set as Google you don't need to repeat it in your SPF. So this will be sufficient: v=spf1 mx ~all.
But then I received a softfail error: softfail (google.com: domain of transitioning a#d.c does not designate xxx.xx.xx.xx as permitted sender)
Adding the ip4 addresses to the TXT record fixed that error too and I received a pass. These were the 2 Google IPs that appeared on my errors, so I added them to the permitted list.
v=spf1 mx ip4:209.85.220.41 ip4:209.85.220.65 ~all
P.S. If you already have a TXT record, the spf value can be added in a new line within the same TXT record.
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.
" 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.
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.