I am planing to use both Mandrill and MailChimp for my website, and I`m trying to set up the crazy SPF DKIM for both of them. At same time still keep my own email flowing In and Out :)
My current plan is :
SPF TXT Record
yourdomain.com
v=spf1 include:spf.mandrillapp.com include:servers.mcsv.net ?all
1 hour
And a DKIM Record (for only Mandrill)
mandrill._domainkey.yourdomain.com
k=rsa; p=*****
1 hour
Can anyone see any missing characters? And is MailChimp Domain still Valid?
Thanks for any help :)
you should be able to omit the Mandrill info from your SPF record, because it's already included by virtue of including the MailChimp one (that MailChimp record includes Mandrill, too). So you just need the include:servers.mcsv.net part.
Your SPF record might need some other info, too, though, depending on how you manage your regular mail, to specifically authorize your own servers to send the mail. For example, if you use Google Apps for your domain, you probably want to include the Google SPF information, too. That's going to be pretty dependent on your regular mail, so best to contact your email hosting provider for more details on how to handle it specific to them.
Related
Recently, emails being sent by my webapp are being marked as spam by Gmail. Possibly other providers as well. My webapp uses Sendgrid to send some system-related automated or user-triggered emails. When I first encountered this issue, I set up an SPF record within Amazon Route 53 that solved the problem.
About a week ago, these system emails started going into spam again. When I go to dmarcian.com and use their SPF Surveyor tool, the tool says that I do not have an SPF record for the domain.
I double-checked my dashboard in Sendgrid and the SPF records are verified on that end. I also set up link branding, added the requisite DNS records in Route 53, and verified them through Sendgrid. That did not fix the issue.
Here is the SPF record I have in Route 53:
v=spf1 mx a include:sendgrid.net -all
I have tweaked this from what is was previously in attempts to get this to work. It previously did not include the "mx a" tags but still provided the desired results.
I'm expecting these emails to show up in my regular inbox without a huge warning banner telling me they could be spam. Currently the emails arrive with that banner, or they just go straight to my spam folder and I have to mark them in both instances as not spam.
I'm a complete novice at this stuff, so if there's something I didn't include someone needs to see, please just let me know and I'll post whatever is needed.
I just found out my domain's emails have been going to the spam folder of gmail recipients. I did some research and I put the following in my DNS records for my domain name:
TXT - "v=spf1 include:_spf.google.com ~all"
I'm not sure if I have to put anything before the spf like my server's IP address or a or mx in some configurations I see. I mainly use my google apps domain email by using my plain gmail account and set "Send As" to send from the domain specific emails.
Is there something else I am missing or overlooking that I need to do to resolve this issue?
If you're only using google apps to send emails then that's the correct SPF record.
If you want to be sure, the best thing you can do is send an email to
mailtest#unlocktheinbox.com
check-auth#verifier.port25.com
They are know as reflectors and will auto-respond with your configuration, letting you know if you have your SPF set up correctly.
If you're unsure of what you need just use an SPF Wizard, but I think based on your description you're 100% fine. The MX and A just tells the receiving mail server that if the mail comes from you MX or A of your domain, then it's a good email, but you're sending from google, so you wouldn't need it.
Also with GMAIL in-boxing takes time and SPF isn't the magic cure, but it helps.
I am trying to help out a little non-profit organization, who has decided to let One.com host their domain, including website and e-mail. Now, my issue is that One.com does not add SPF-records or DKIM-keys to your domain and I believe that is the reason why a large number of mails sent from the domain, end up in spam.
I've been in touch with their support, who kindly answered:
You are already using our mail servers, there is no need to use SPF for that.
Our mail servers already have SPF installed, and if you are using our mail servers, SPF will not be question since domain is hosted here and it is using One.com's mail server. SPF will only be required if your domain is hosted here but is using a different MX record or mail server
I've tried to figure out if you can leave out SPF, but all I've been able to conclude is that proper SPF on each domain is definitely the proper way, instead of just the hosting companys main domain. I mean, if it was that simple, how come even Google Apps, Zoho, Rackspace etc. recommends adding SPF, if it worked just as well leaving it out - you'd be using their MX as well, so isn't that the same? And wouldn't leaving SPF out leave us with the same issues as before SPF, namedly that you'd have no way to validate if mail was truly being sent from the owners of the domain or just somebody imposing.
So what it comes down to: Can One.com really leave out SPF records on their clients domains, send mail on the clients behalfs and still expect mail to come through without ending up in spam more often?
Thank you very much for your time!
The short answer is "No, they can't". The longer answer is a little more complicated.
SPF uses either the EHLO domain of the sending server or the domain in the Return-Path to look up SPF records in DNS. Most systems that handle multiple domains do not use SPF records on the EHLO domains of the sending servers, so the SPF domain is taken from the email's Return-Path. You should take a look at the Return-Path for one of the emails that this non-profit has sent through One.com to determine whether the Return-Path is on a subdomain of one.com, or is using the non-profit's domain. The latter is definitely preferred.
If the Return-Path is on a subdomain of one.com, then that's the domain that will be used to look up SPF records. So adding SPF records to your non-profit's DNS won't do anything. While this may seem the easier path, it causes problems with DMARC and may cause the email to be flagged as spam even if it passes SPF, as the address in the 'From' header will have a domain that doesn't match the Return-Path
If the Return-Path is on a subdomain of your non-profit's domain, then you should definitely add an SPF record to your non-profit's DNS. Looking at one.com's current records, something like:
v=spf1 include:_spf.one.com ~all
should do it.
By the way, you should be able to see whether an email has been SPF or DKIM authorized by looking at the headers of the received email. That's the best way to understand the actual behavior.
We have a website where we allow you to reset your password (say if you forget your password). This is standard on many websites. Basically you enter your email address which you've used to register on our website, then we send you an email containing an email reset link.
This is all standard stuff. However, the problem is: Gmail somehow thinks this email we send to the user is spam, and puts it in the Spam folder.
The specific message Gmail shows is:
Be careful with this message. Our systems couldn't verify that this message
was really sent by xyz.com. You might want to avoid clicking links or replying
with personal information.
Let me explain how we send the email. We use the company sendgrid.com to deliver
the emails. xyz.com is a domain we control. (xyz is a pseudo-name here.)
The email's from address is: do-not-reply#xyz.com
We have changed xyz.com's SPF record to include "sendgrid.com" (and "sendgrid.net" "sendgrid.me").
There's no website associated with xyz.com, however.
My question is: what else can we do to make Gmail believe the email is from the domain xyz.com? So it doesn't put the email in the spam folder?
Thank you.
Did you end up publishing DKIM with Sendgrid? Also, I have a feeling your SPF record isn't quite right as generally there's one official entry per email provider. You mention adding several. I'd recommend looking at their docs for exactly what they recommend publishing in your SPF. Do this for any provider you use for any kind of email.
Since you mentioned Sendgrid as your ESP, here are Sendgrid's instructions. Once you've done the DNS you have to ask Sendgrid to "sign" it. Since DKIM uses cryptography you'll need them to do their side.
DKIM's less complicated than it sounds. The DNS records you have to add will take a few minutes then presumably open a ticket to Sendgrid to have them do their side.
Also, as an aside, could you post what you have for your SPF record here? I don't mean your domain but what the value is? It's not directly causing the problem but it's a key component of email authentication.
Once you've completed SPF and DKIM, it is critical you validate them both. Do a search for SPF validates and DKIM validator to find online tools.
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.