I have a domain set up on AWS Route53 and I use the GoogleApps for the administration of email accounts. I'm having trouble sending invite (Google Calendar/Hangout) to other domains. These invites are going in the SPAM box.
My DNS Configuration
$ dig -t any matheuscarino.com.br
;; ANSWER SECTION:
matheuscarino.com.br. 27 IN A 54.88.183.99
matheuscarino.com.br. 27 IN A 54.86.206.71
matheuscarino.com.br. 21567 IN NS ns-1324.awsdns-37.org.
matheuscarino.com.br. 21567 IN NS ns-1966.awsdns-53.co.uk.
matheuscarino.com.br. 21567 IN NS ns-691.awsdns-22.net.
matheuscarino.com.br. 21567 IN NS ns-7.awsdns-00.com.
matheuscarino.com.br. 867 IN SOA ns-1966.awsdns-53.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
matheuscarino.com.br. 267 IN MX 1 aspmx.l.google.com.
matheuscarino.com.br. 267 IN MX 10 alt3.aspmx.l.google.com.
matheuscarino.com.br. 267 IN MX 10 alt4.aspmx.l.google.com.
matheuscarino.com.br. 267 IN MX 5 alt1.aspmx.l.google.com.
matheuscarino.com.br. 267 IN MX 5 alt2.aspmx.l.google.com.
matheuscarino.com.br. 267 IN TXT "v=spf1 include:_spf.google.com ~all"
$ dig -t TXT _dmarc.matheuscarino.com.br
;; ANSWER SECTION:
_dmarc.matheuscarino.com.br. 299 IN TXT "v=DMARC1\; p=quarantine\; pct=100\; rua=mailto:webmaster#matheuscarino.com.br"
See how the messages are delivered.
spf=pass (google.com: domain of 3J4q7VQIUDdwCSK8RFCSQA8PGLM.AMK.9PK8RFCSQ.P8KMQL8RSC.AMK.9P#calendar-server.bounces.google.com designates 2607:f8b0:4002:c07::24a as permitted sender) smtp.mail=3J4q7VQIUDdwCSK8RFCSQA8PGLM.AMK.9PK8RFCSQ.P8KMQL8RSC.AMK.9P#calendar-server.bounces.google.com;
dkim=pass header.i=#google.com;
dmarc=fail (p=QUARANTINE dis=QUARANTINE) header.from=matheuscarino.com.br
Received: by ykdv124 with SMTP id v124so3562561ykd.1
for <matheus#XXXXX.com.br>; Fri, 31 Jul 2015 07:46:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
Thanks in advance.
So getting a Google Apps email system to be DMARC compliant requires that you enable domain-specific DKIM. Right now your email is being DKIM signed with a google.com signature, but the FROM header is an matheuscarino.com.br address. So the DKIM signature cannot be used for DMARC authentication, because the domains are not the same.
For most emails sent from your Google Apps account, this isn't a problem, because SPF authentication matches the FROM header domain. These emails have a Return Path address with a domain of matheuscarino.com.br, and your SPF record above authenticates them.
BUT, Calendar and Hangout messages use a different Return Path domain. So for these messages to authenticate you must enable DKIM for your Google Apps account. You can find instructions here - https://support.google.com/a/answer/174124?hl=en
Related
Trying to send out emails yet they end up in spam folders for some reason. So we tweaked and adjusted Dkim and Dmarc, now all records show passed within Gmail, yet still flags as spam.
Also tested via dkimvalidator , this results in all records pass and showing
SpamAssassin Score: -0.1
Message is NOT marked as spam
Now the breakdown of an email is shown below.
Sending IP has been changed for this post to 123.456.789.12
Sending domain has been changed to somedomain.net
sending email address has been changed to support#somedomain.net
Receiver email address has been changed to someuser#gmail.com
Original Message
Message ID <3164f55daebbc258d0a4846eda47142b#somedomain.net>
Created at: Fri, Mar 15, 2019 at 3:06 PM (Delivered after 1 second)
From: support#somedomain.net
To: someuser#gmail.com
Subject: Are you getting our emails?
SPF: PASS with IP 123.456.789.12Learn more
DKIM: 'PASS' with domain somedomain.netLearn more
DMARC: 'PASS' Learn more
Delivered-To: someuser#gmail.com
Received: by 2002:a05:6504:1158:0:0:0:0 with SMTP id r24csp952466ltn;
Fri, 15 Mar 2019 12:06:09 -0700 (PDT)
X-Google-Smtp-Source: APXvYqwbxqRfiq2UKjVTB57wP4g1MW2NvFWKdyYY9P4PITERpXVsMmcdriTP6Fp9rsf+DU2Ky1nQ
X-Received: by 2002:a1c:230e:: with SMTP id j14mr3316801wmj.9.1552676769338;
Fri, 15 Mar 2019 12:06:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1552676769; cv=none;
d=google.com; s=arc-20160816;
b=kI1D5Zd50f7UIVNtLYscVA3w9dhrAzg3YfuSMJWIIag6Le+YNqzYUpTxlQ11pK0Jvd
9bQ8KztlKnEwTWvC90bUrX7FvNTdKTEeatTQao5I5z77QxBG8q96cYYnbmzHVzsKxcS6
eBJYwO7gabkTsJzdGHYeYR9pYHPANr5vhtkpGYn4OSEAvrTokXHnI7Lma5MlI+QcJFhO
eGb6omkWY05TGfZZYMJ9ny/8WBhG6W3mpuT+x3Z0mv9IWnuxhhnDWgYGb+qEK/cUkCjl
CLHaxq+uRh8MXnjzoChWHXc4elm8yKo9CS3qqAppMThxQ3X/2kp9SVg+EPKut9R3OtG0
D+ng==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=message-id:user-agent:subject:to:from:date
:content-transfer-encoding:mime-version:dkim-signature;
bh=GrxIPJ9zPlbqzf38J/MOr7Lt7eP6CUv0wQxJqM2McmE=;
b=QgXB7YGir4NdgYnbt+2pORQCK5bMsOT+mHtSghj+CrTIORIqW04ie/3v8iWpMop2uc
ZYby4O/YD5TohP7VnYT1/lHGcQO8BCK+BCqXJaJb1JyzoRFyAM2aVMfJonRphm3VSfzH
JCGAAQjW3hTRsANmiU4Toh5IgXVgLvz2ZFSbOjY+xEopHJar1XXg9kN9N+A8kZMJWIIk
dVXrhwSDV/1Z0/8ObepuXI+KZNRpyKItMjMMDDyh1Py7cQl1MJXnoTzr53aCeDw3nWWg
yUDRjq3kDUK2Rm0X/O43DGHQvAHvk7gge4UaE5rDFjtBphLVYO0Zadto3bQAFwAMouR9
H9Qg==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=#esomedomain.net header.s=mail header.b="cLQsKmq/";
spf=pass (google.com: domain of support#somedomain.net designates 123.456.789.12 as permitted sender) smtp.mailfrom=support#somedomain.net;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=somedomain.net
Return-Path: <support#somedomain.net>
Received: from ms101.somedomain.net (vmi247326.someotherotherdomain.net. [123.456.789.12])
by mx.google.com with ESMTPS id k4si945224wmi.131.2019.03.15.12.06.09
for <someuser#gmail.com>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 15 Mar 2019 12:06:09 -0700 (PDT)
Received-SPF: pass (google.com: domain of support#somedomain.net designates 123.456.789.12 as permitted sender) client-ip=123.456.789.12;
Authentication-Results: mx.google.com;
dkim=pass header.i=#somedomain.net header.s=mail header.b="cLQsKmq/";
spf=pass (google.com: domain of support#somedomain.net designates 123.456.789.12 as permitted sender) smtp.mailfrom=support#somedomain.net;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=somedomain.net
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=somedomain.net; s=mail; h=Message-ID:Subject:To:From:Date: Content-Transfer-Encoding:Content-Type:MIME-Version:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
bh=GrxIPJ9zPlbqzf38J/MOr7Lt7eP6CUv0wQxJqM2McmE=; b=cLQsKmq/CfXyv0nzG9Fwi6cs4 Ei3zkeoZTgWBvLZfF303+EVPnwUdqgKKlXfLntlfW+8lp54rm3S/dI9p640dC6IIoGJrdkYwWUw+0 J0K6U9rSTs1yUJ8mM6kWdYURmUQ7eAMvbqFtCIXhcXPBBlKDgvFGCpwz5GnSark8zkU7c=;
Received: from localhost ([127.0.0.1] helo=ms101.somedomain.net) by vmi247326.someotherdomain.net with esmtp (Exim 4.91) (envelope-from <support#somedomain.net>) id 1h4s9g-0001pt-Nb for someuser#gmail.com; Fri, 15 Mar 2019 15:06:08 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 15 Mar 2019 15:06:08 -0400
From: suppor#somedomain.net
To: someuser#gmail.com
Subject: Are you getting our emails?
User-Agent: Roundcube Webmail/1.4-rc1
Message-ID: <3164f55daebbc258d0a4846eda47142b#somedomain.net>
X-Sender: support#somedomain.net
Currently running centos 7 --> VestaCP
Roundcube using postfix, yet don't mind switching to horde or 3rd party ESP if needed.
The only thing that I can think is the sending domain is a sub domain of the root yet we've added MX record with priority 1 within DNS on cloudflare to accept mail for root domain, yet the sub domain is hosted on same server and same IP.
The Message ID is being generated from somewhere, I am not sure. This may be the reason for spam flag as well.
Any help is greatly appreciated.
I worked in G Suite support a while back, spent a lot of time working with Gmail.
Some things to keep in mind,
1) Try to have your SPF with ~all instead of ?all (I can still see your domain in the return path, you may want to edit that out).
2) Your DKIM needs to be added into the domain listed in the return path. If the return-path is domaina.com, the DKIM needs to be from domaina.com
3) DMARC doesn't really help that much when sending email, is mostly used to prevent inbound spoofing against your domain, it's still good to have it nonetheless.
4) Try sending emails from a different server, sometimes specific servers have pretty bad rep, causing emails to be marked as spam (mail-tester.com tool helps get an idea of how spammy your emails are).
5) Try not to send marketing emails to people who have never heard from you. In case you're actually doing that, use a dedicated service (like Mailchimp) that maay help the delivery (also, avoid bccs).
Other than that, the tough answer, you can do everything good, but there is 0 guarantee that your email will never be marked as spam, sadly, it's half in your control, the other half is what others have reported from your domain, your server, your content, your actual username, links included, etc. Keep in mind that your reputaion varies per server, so if emails land in spam in Gmail, it doesn't necesarily mean that it'll land in spam in hotmail. Sometimes using a completely different domain/server/service helps, but if the reputation is already tainted, only marking emails as 'not spam' would eventually help the delivery (I know, it sucks when that happens).
Cheers!
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.
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.)
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.