Since it was released I've been using Google Apps FYD for stackednotion.com. All of the email I send goes through Google's servers and I use Gmail to view my email. I haven't had any issues before, however recently I've been seeing weird bouncebacks ending up in the catch all account. It looks like somebody is using my domain to send spam. I don't really want my domain getting marked with a bad reputation, so how can I stop this?
I have setup SPF, DMARC and DKIM on the domain by following the guides on Google Apps, here is my zone file:
; stackednotion.com [9548]
$TTL 86400
# IN SOA ns1.linode.com. luca.stackednotion.com. 2012072633 7200 7200 1209600 86400
# NS ns1.linode.com.
# NS ns2.linode.com.
# NS ns3.linode.com.
# NS ns4.linode.com.
# NS ns5.linode.com.
# MX 1 ASPMX.L.GOOGLE.COM.
# MX 5 ALT1.ASPMX.L.GOOGLE.COM.
# MX 5 ALT2.ASPMX.L.GOOGLE.COM.
# MX 10 ASPMX2.GOOGLEMAIL.COM.
# MX 10 ASPMX3.GOOGLEMAIL.COM.
# MX 30 ASPMX4.GOOGLEMAIL.COM.
# MX 30 ASPMX5.GOOGLEMAIL.COM.
# TXT "v=spf1 include:_spf.google.com ~all"
google._domainkey TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDi19ipSdqDEpnJEWrVF7MarSLnlzXi0wPOHws2BY6oMQInbY5OHzdw9LcFr1biVvipErm4odyJfjZAIp5s8r6z50ZxQdW5Uwdy9krA1A9HMPaqVN+fm2xpntU//uXn0wD8sGc9CljYQIl+MusxQ690PfVGnAz/QeLqaZFxpHHmmQIDAQAB"
_dmarc TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc#stackednotion.com"
# A 178.79.164.64
* A 178.79.164.64
_xmpp-server._tcp SRV 5 0 5269 xmpp-server.l.google.com.
_xmpp-server._tcp SRV 20 0 5269 alt1.xmpp-server.l.google.com.
Also here are the headers of a spam message (somebody tried to susbscribe me to a Zend mailing list, what kind of sick people are they?!?):
Return-Path: <F776387#stackednotion.com>
Received: (qmail 20117 invoked from network); 27 Jul 2012 06:51:01 -0000
Received: from exprod7mx200.postini.com (HELO psmtp.com) (64.18.2.92)
by rsmx2.zend.com with SMTP; 27 Jul 2012 06:51:01 -0000
Received: from source ([188.51.41.223]) by exprod7mx200.postini.com ([64.18.6.13]) with SMTP;
Fri, 27 Jul 2012 02:51:00 EDT
To: <fw-docs-subscribe#lists.zend.com>
Subject: Invoice #48469883494
From: "Order" <F776387#stackednotion.com>
Date: Sat, 28 Jul 2012 09:40:03 +0300
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: IPS PHP Mailer
MIME-Version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Message-ID: <20120728094003.9312B884F9D66F02CE7C#DELL-PC>
X-pstn-neptune: 500/484/0.97/100
X-pstn-levels: (S: 0.00346/89.11253 CV:99.9000 FC:95.5390 LC:95.5390 R:95.9108 P:95.9108 M:97.0282 C:98.6951 )
X-pstn-dkim: 0 skipp
At present, the way to reduce miscreants ability to send spam purportedly from your domain is to inform other mail servers what servers are allowed to send mail on your domains behalf. The mechanism is SPF and you already have a SPF record:
TXT "v=spf1 include:_spf.google.com ~all"
If blocking forgery attempts is your desire, this can be improved upon. Read the SPF Record Syntax page that describes what your SPF policy should be. If you have other mail servers sending mail on behalf of your domain, add them to the SPF record and change your policy to fail:
TXT "v=spf1 include:_spf.google.com -all"
Because SPF is so widely deployed, this will make a difference. But SPF has edge cases (forwards, email lists, etc.) where SPF policy fails, so most sites choose to be more liberal with SPF policy than you request. For example, if your policy is set to reject, and the message appears to be from an email list, most servers notate it somehow (the Authentication-Results header is defined for this purpose) and allow it to pass.
This is where DMARC comes in. You have already added a DMARC record:
_dmarc TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc#stackednotion.com"
Your policy is only to quarantine failing DMARC messages. If the DMARC reports do not indicate any valid messages being blocked, and/or you are willing to live with some edge cases where valid messages are rejected, then you can improve upon this with p=reject.
Not surprisingly, getting bounces from mail servers for spam purporting to be from one of my domains is exactly what compelled me to start DKIM signing my messages, so that I could deploy DMARC. DMARC is a policy mechanism that combines SPF and DKIM, so that domain owners can assert to other mail servers that, "If it's not from this list of IPs (SPF) and it's not DKIM signed, then [reject|quarantine|allow] it."
DMARC works brilliantly. Instead of getting bounce messages, now I get DMARC reports. I use Mail::DMARC to parse the reports and put the summaries into a database.
DMARC is still an IETF draft and it's not widely deployed. However, most large email providers have implemented it and coverage is surprisingly good. After deploying DMARC for my domain, I wrote a DMARC plugin for Qpsmtpd, so I could validate incoming messages against DMARC policy. I published some of my findings as a DMARC operator in a DMARC FAQ.
I mentioned edge cases earlier, so I feel compelled to share one.
Google handles misaligned messages (those that fail both SPF and DKIM alignment) by dropping them into the users Spam folder. I have become familiar with this because emails sent from my domain are generally treated well by gmail. The exception is for messages relayed through some email lists such as dmarc-discuss#dmarc.org. Messages I sent to that list get modified by the list processing software, invalidating my DKIM signature. When the message is forwarded to gmail recipients, those messages are marked as spam because a) I have published a reject DMARC policy, and b) that email list isn't a valid SPF sender of email from tnpi.net, and c) the DKIM signature bearing my domain fails validation.
There are workarounds, besides fixing the list software, such as adding the offending mailing list server to my SPF record. Some DMARC implementations will detect messages from mailing lists and reduce the policy severity (ie, Google quarantines my list messages rather than rejecting).
At present, there is no better way to inhibit phishing and spoofing attempts using your domain than a well implemented DMARC policy.
I've noticed an increase in this kind of spoofing in the last few weeks as well.
The Google support page on this issue notes:
"Because these messages originate outside of Gmail, we aren't able to stop spammers from spoofing your address. However, Google helps protect your Gmail address's reputation by designing our systems to authenticate all the mail that really comes from you. When another domain receives an unauthenticated message from Gmail, it can tell that you didn't really send the mail, and it is unlikely that your email address will be blocked. For our part, we are concerned about spoofing and bouncebacks. We ask you to report these messages by checking the box next to the unwanted message and clicking Report Spam at the top of your inbox, or by opening the message and clicking Report Spam at the top of the message."
"You can help stop spammers by also sending the full headers of these unlawful messages to the Federal Trade Commission at spam#uce.gov."
Afaik, it's supposed that DMARC will help you achieve that. According to the Google Apps Article about DMARC, you should start using a "conservative deployment cycle" like:
Monitor all.
Quarantine 1%.
Quarantine 5%.
Quarantine 10%.
Quarantine 25%.
Quarantine 50%.
Quarantine all.
Reject 1%.
Reject 5%.
Reject 10%.
Reject 25%.
Reject 50%.
Reject all.
So, my suggestion would be stop quaranting emails, monitor for a while and then start going up.
There could be possibility that your mails are getting bounce back. So if you are receiving mails on the same account from which you send. Try changing the authority of admin of domain control in your database.
Related
I'm looking for help in fixing the email delivery issues; as almost 50-70% of our emails are getting flagged as spam by Gmail's filters. Here's how I've configured my current setup -
Setup
I use 'Mailcoach' as my newsletter/campaign software hosted on crazyengineers.email. Mailcoach sends email via AWS-SES. However, the mails are sent from hello#crazyengineers.com (not the TLD: .com vs. email). Both email address and domain are verified in SES.
For the past several years, we've kept our bounces/complaints to < 0.4%; which I believe is healthy.
I started sending out newsletter after a long gap of ~3 years and discovered that majority of mails were getting marked as spam by Gmail (and few other service providers).
Troubleshooting Steps Performed
So far, I've setup DKIM, DMRAC and SPF records as directed by several articles and blogs on the internet: -
DMARC:
_dmarc.crazyengineers.com TXT Routing: SIMPLE
value: "v=DMARC1;p=reject;pct=25;rua=mailto:hello#crazyengineers.com;ruf=mailto:hello#crazyengineers.com"
SPF:
crazyengineers.com TXT Routing: Simple
value: "v=spf1 ip4:13.234.210.186 include:_spf.google.com include:amazonses.com ~all"
DKIM:
exsdzadw3bnymparqj7feo5mpfqk5kdv._domainkey.crazyengineers.com CNAME Simple -
exsdzadw3bnymparqj7feo5mpfqk5kdv.dkim.amazonses.com
j3qbw4sa5w4g2m4nt2padhxm6y6sxbt7._domainkey.crazyengineers.com CNAME Simple -
j3qbw4sa5w4g2m4nt2padhxm6y6sxbt7.dkim.amazonses.com
oqahpkio2yww2enbd34rvq6xts52gtrc._domainkey.crazyengineers.com CNAME Simple -
oqahpkio2yww2enbd34rvq6xts52gtrc.dkim.amazonses.com
Even after adding these records - Google DMARC XML shows failures (and not a single PASS!).
Can someone help me achieve a proper, healthy records for my domain? I'm willing to move away from .email domain and host the mailing software on my subdomain say - newsletter.crazyengineers.com
Thank you for your time.
So far my main.cf contained, primarily, two following lines:
local_recipient_maps =
luser_relay = mrjoe#mydomain.com
These settings are responsible for delivering all emails sent to any address in my domain like random_string#mydomain.com to my real account mrjoe#mydomain.com. This worked and I was receiving emails only from websites where I signed up with any of my unlimited aliases.
I realized that I don't want to receive all these emails, so I came up with an idea to discard emails sent to particular alias instead of blocking a particular sender. In this way, I can protect myself from any future unwanted email and somehow make this alias disabled.
To bring this idea to life I removed the previous two lines from main.cf and added the following one:
virtual_alias_maps = pcre:/etc/postfix/virtual_alias
The virtual_alias file has following content:
/^((?!^(blacklisted_address|another_blacklisted)#).)*$/ mrjoe#mydomain.com
This configuration redirects all emails sent to addresses other than blacklisted_address#mydomain.com and another_blclisted#mydomain.com to specified real address mrjoe#mydomain.com.
This works, emails sent to listed addresses are not delivered to my inbox. The problem is that now I started to receive hundreds of spam emails, none of which I received before.
Here is one example of such spam message:
From secretariat#solid-app-api.be Wed May 29 01:23:10 2019
Return-Path: <secretariat#solid-app-api.be>
X-Original-To: mrsnorah11#gmail.com
Delivered-To: mrjoe#mydomain.com
Content-Type: text/plain; charset="iso-8859-1"
Content-Description: Mail message body
Subject: 21.21.21.21 // my IP here
To: Recipients <secretariat#solid-app-api.be>
From: "Agent MacLeod" <secretariat#solid-app-api.be>
Date: Tue, 28 May 2019 16:23:10 -0700
X-UID: 1194
Content-Length: 3686
Status: RO
So the question is: why did I start to receive hundreds of spam messages after making changes described above? How is it possible that now messages with X-Original-To header different than #mydomain.com are delivered to my domain?
As for now, I brought back the previous configuration and I no longer receive spam messages. Clearly, this is not an acceptable solution.
In your old config, luser_relay delivered all "mail for unknown recipients in domains that match $mydestination, $inet_interfaces or $proxy_interfaces" (thus your domain) to your mailbox.
Your new configuration accepts mails for any recipient domain. The regex matches any email address except the blacklisted ones. All mails forwarded to your address mrjoe#mydomain.com, hence the X-Original-To header.
Spammers send mails with other repients (like gmail.com) to your server because your server accepts it. They think that you're running an open relay (which you probably don't).
I use dnsimple to host my DNS and have valid SPF, DKIM, and DMARC records to validate my emails sent from Zoho. However, Whenever I send emails to an #ucdavis.edu account I get an Undelivered Mail response
This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its recipients. This is a permanent error.
lsmiyashita#ucdavis.edu, ERROR_CODE :550, ERROR_CODE :5.7.1 <admin#study.space>... Access denied
Received:from mail.zoho.com by mx.zohomail.com
with SMTP id 1478675695600485.6815385213283; Tue, 8 Nov 2016 23:14:55 -0800 (PST)
Message-ID:<15847f087ed.112901d8e106580.9166398699723335101#study.space>
Date:Tue, 08 Nov 2016 23:14:55 -0800
From:Jacob Bevilacqua <admin#study.space>
User-Agent:Zoho Mail
To:"lsmiyashita" <lsmiyashita#ucdavis.edu>
Subject:Here's a little test for you.
Content-Type:multipart/alternative;
boundary="----=_Part_335760_1020694757.1478675695597"
I have tried several different hosts (GSuite, MailGun, & Zoho) and I get the same issue. I checked and I am not blacklisted on any sites. I ran a test at mail-tester.com and got a 10/10. Why won't my messages deliver.
I verified that the email address you are sending to is valid: Verified Email Address
So like #Synchro says, they just don't like you. It's always a challenge to figure out the exact reason, but contacting their admins is the right way to go. I have a feeling it's because of the .space domain ending, they probably haven't updated the list of domain endings they accept.
Anyway, if you wanted to do additional mail testing, use this Mail Tester.
You are under the unfortunate illusion that it's your fault. A 5.7.1 error means that they just don't like you, and they don't have to give a reason. Welcome to the world of deliverability, or lack thereof. Well-behaved mailers are often punished for no particular reason. If it's just this domain, your best bet might be to contact their admins.
Hello I own a website which uses 2 different ways to sent emails to users:
-gmail configured like support#example.com
-amazon SES
The problem is that the emails sent with SES goes allways into spam!
my SPF record looks like: "v=spf1 include:amazonses.com include:_spf.google.com ~all"
my TXT record looks like: "v=spf1 include:amazonses.com include:_spf.google.com ~all"
I have just changed this records as above, should I need to wait 48 hours or something similar?
Are this correct settings? if yes what could be the reason of my problem?
The first comment is actually not entirely correct!
Mechanisms can be prefixed with one of four qualifiers:
"+" Pass
"-" Fail
"~" SoftFail
"?" Neutral
SoftFail is usually the better choice than Fail because SPF has some flaws and a Fail could prevent some forwarded emails to not arrive at all instead of being flagged as possible spam. (I have experience with those problems since I have worked for several email providers)
Make sure to test your SPF records. You can use this website to test them:
http://spf.myisp.ch
First, as others noted, you are using SoftFail ~all. From openspf.org Record Syntax:
SoftFail: The SPF record has designated the host as NOT being allowed to send but is in transition
Intended action: accept but mark
You should use HardFail -all if you want the emails to be rejected when sent from an unauthorized server.
SPF protection is used to prevent spoofing. It's there to define the servers that are authorized to send emails for a certain domain. Generally, if the spf fail, the email will just be rejected and will not get into the spams.
There's a lot of possible reasons an email is getting into the spams, but it's generally because your email has been flagged as spam by a content analysis tool like SpamAssassin. You should contact whoever is managing the email filtering and ask them why exactly your email got in the spams.
I configured exim mail server to send email from my web application (Example recovers passwords).
Tests done by mail is always considered as spam.(i use gmail web client).
How do I configure exim so that the emails they send are not considered spam?
Header with SPF
Delivered-To: spidercloudfl#gmail.com
Received: by 10.194.81.69 with SMTP id y5csp12894wjx;
Wed, 22 May 2013 10:34:21 -0700 (PDT)
X-Received: by 10.15.107.77 with SMTP id ca53mr20828718eeb.40.1369244060917;
Wed, 22 May 2013 10:34:20 -0700 (PDT)
Return-Path: <info#wizardsnc.it>
Received: from 95.110.179.201 ([95.110.179.201])
by mx.google.com with ESMTPS id u46si3055346eeg.66.2013.05.22.10.34.20
for <spidercloudfl#gmail.com>
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Wed, 22 May 2013 10:34:20 -0700 (PDT)
Received-SPF: neutral (google.com: 95.110.179.201 is neither permitted nor denied by best guess record for domain of info#wizardsnc.it) client-ip=95.110.179.201;
Authentication-Results: mx.google.com;
spf=neutral (google.com: 95.110.179.201 is neither permitted nor denied by best guess record for domain of info#wizardsnc.it) smtp.mail=info#wizardsnc.it
Received: (qmail 25578 invoked from network); 22 May 2013 18:33:20 +0100
Received: from localhost (HELO 95.110.179.201) (127.0.0.1)
by localhost with ESMTPA; 22 May 2013 18:33:20 +0100
Date: Wed, 22 May 2013 18:33:20 +0100 (BST)
From: "Wizard s.n.c" <noreplay#wizardsnc.it>
To: "spidercloudfl#gmail.com" <spidercloudfl#gmail.com>
E-mail continue to be considered as spam :(.
thanks to all
Modern large webmail providers use a reputation system to score and determine placement of inbound emails. Your sending IP and domain name builds a reputation How those reputation systems work exactly is not something that we on the outside will know. But we can describe behaviors that seem to influence a sender's reputation.
If you have never sent an email from your IP, it has no reputation. Unfortunately for you, no reputation is essentially in the border of a bad reputation.
If your IP has ever sent spam that one or more Gmail users submitted as spam, it contributes negatively to your reputation.
If an IP from your /24 (or maybe from the /n BGP announcement containing your IP), it contributes negatively to your reputation. It is unknown if this is the same negativity as item #2.
If your domain does not have an SPF record, it contributes very negatively to your reputation. If it does, and it does not match, it contributes negatively. If it does have it and it does match, it contributes positively.
If your domain does not use DKIM to sign the emails, it contributes negatively to your reputation. If your domain does and the signature fails, it contributes negatively. If it does use DKIM and the signature passes, it contributes positively.
If your domain uses DMARC and it aligns, then it contributes positively to your reputation. I think it contributes LARGELY positive.
If your emails are being marked as spam due to detected URLs in various URIBL's, it contributes negatively to your reputation.
If your IP's mail volume changes drastically upward, it contributes negatively to your reputation. It tends to be changes of scale. So 0 to 5 may not be that big a deal, but 0 to 10 may be signs of abuse. Same process for 100 to 500 ok, but 100 to 1000 is signs of abuse.
If your IP's mail volume is consistently the same, it will contribute positively to your reputation.
If your IP is listed in any major RBL, it contributes negatively to your reputation.
If your emails have invalid or missing required headers, it can contribute negatively to your reputation.
If your emails don't fall afoul of any of these things, it can contribute positively to your reputation.
If your emails are marked as Not Spam by users who receive it, it will contribute positively to your reputation.
Basically there are lots of things that can be wrong that contribute negatively, and just a few things that work for positive reputation. There are more than these, but these are all I could think of off the top of my head.
Todd's answer is good, and when he's talking about reputation, he's hitting the nail on the head.
Generally, not having SPF/DKIM/DMARC records has very little impact to your IP or domains reputation, and by extension, very little or no impact upon a particular messages deliverability. Take a look at the most widely deployed mail filters (SpamAssassin, Amavis) and you'll find that having matching SPF records provides no score increase. The same goes for DKIM. The reason for this is simple, it's very easy for spammers to publish SPF records and by harnessing the power of bot nets, the CPU cost of DKIM signing messages is negligible.
Many spammers use throw-away domains (no reputation) they acquire for this very purpose, generally in TLDs that permit domain abuse like .info, .pw, .tw, and .biz. Just like Todd's points #2, and #3, if you happen to have a domain that is surrounded by spammers, it's just as bad as having an IP address or ASN with spammy neighbors.
SPF, DKIM, and DMARC are all authentication mechanisms. They serve only to validate that the domain in question is responsible for a particular message. The reason a domain owner with a good reputation should publish a SPF record and DKIM sign their messages is to prevent spammers from sending emails from their domain, and thereby sullying their good reputation.
Failing SPF, DKIM, and DMARC will definitely earn you negative points, in varying quantities.
I'm on a couple DMARC mailing lists and I run one of about 20 mail systems on the internet that do DMARC reporting. I don't know of anyone handing out extra ham points for DMARC aligned messages. That isn't to say DMARC is not helpful. If your domain has a good reputation, and you publish DMARC records and a particular message is aligned, then your good reputation extends to that message. If the message is not aligned, then we have to decide if the message really is from you, and how much of your domains reputation should be afforded it.
Another thing that's vitally important for a mail servers reputation is having properly configured DNS. Make absolutely certain your mail server's IP has matching forward and reverse DNS (FCrDNS), and that the hostname of the server is configured correctly, and that Exim is using the machines hostname.