I have a domain registered at domains.google.com that I use with a G Suite account and also to send email from SES and mailchimp.
My DNS records look correct to me (Mailchimp instructions):
# TXT "v=spf1 include:_spf.google.com include:amazonses.com include:servers.mcsv.net ~all"
_dmarc TXT "v=DMARC1; p=none; pct=100; rua=mailto:re+aml1ryadtn7#dmarc.postmarkapp.com; sp=none; aspf=r;"
I use postmark's nifty service to get a weekly DMARC digest, and they report this error for mailchimp emails:
mcsv.net is authorized to send on behalf of mydomain.com, however it looks like SPF is still failing DMARC’s alignment test. DMARC looks at the Return-Path of a message to make sure the domain there matches the domain in your From address. If the Return-Path path doesn’t match your From address, those messages will fail DMARC’s SPF alignment test. Check with this source because you may need to set up a custom Return-Path.
Here are relevant headers from a mailchimp email:
Return-Path: <bounce-mc.us17_88978185.265251-recipient=patentbots.com#mail125.suw11.mcdlv.net>
From: me#mydomain.com
Do I have an error in setup (either DNS or Mailchimp) that causes SPF DMARC alignment to fail? Or is this something that isn't supported by Mailchimp?
Mailchimp does not support SPF as it uses its own domain in the bounce address. Their domain authentication verification tool requires including Mailchimp, though. Mailchimp always fails DMARC's SPF alignment test because the Return-Path path doesn’t match the From address. MailChimp doesn't support custom Return-Path (even though Mandrill, which is owned by Mailchimp, does). This makes it impossible to be 100% SPF-compliant under DMARC rules with Mailchimp.
I'm not 100% sure, but I'd guess that if the domains for return-path and from header have to match, you would need to have a CNAME DNS record in your own domain pointing at MC, so that the domains could match, something like:
mc CNAME mail125.suw11.mcdlv.net
Then your return path might become <bounce-mc.us17_88978185.265251-recipient=patentbots.com#mc.mydomain.com>.
I don't know if a subdomain match like this is sufficient, i.e. whether DMARC considers mc.mydomain.com and mydomain.com to be sufficiently aligned.
I can see the management of this being a little tricky if you have lots of domains.
Related
I have a forwarding domain (forwardingdomain.org > actual-website.org) for which I have email forwarders set up. To reduce spamming/spoofing of my email forwarders, I would like to set up a correct SPF TXT record in the domain’s DNS.
I have an SPF TXT record set up in the DNS, however, recently I’ve received scam/ransomware/spam emails that appear to be coming from email forwarders of the forwarding domain. So, that SPF record may not be working. I’ve successfully set up SPF TXT record for domains that have a website associated with them (i.e., I can use a server IP in the SPF record). For this domain, however, since it’s forwarding, it’s not clear what IP I should use.
Here’s the current SPF record (I don’t remember adding this myself; it may have gotten generated by itself):
Type: TXT
Host: #
Value: v=spf1 a mx include:sendgrid.net ~all
Expected result: No more scam/spam/ransomware emails should be coming in that appear as if they were sent from my email forwarders.
Actual result: Scam/spam/ransomware emails are coming in, appearing to be sent from my email forwarders.
Firstly I would recommend adding an include mechanism to pull in IPs from your forwarding domain.
Next, you have a ~all default mechanism, which means that forged messages will not be rejected, just marked as non-compliant (softfail). This is the correct setting if you are still testing your configuration or you are using DMARC.
With DMARC, the softfail can be turned into a full rejection, and this is generally considered better than using -all because it retains DMARC’s other semantics.
I have a client that have a spf record i don't understand.
The record is like this:
"v=spf1 a:domain.tld -a:gmail.com -a:googlemail.com -ip4:xx1.yy1.zz1.xx -ip4:xx2.yy2.zz2.xx include:spf.mandrillapp.com include:servers.mcsv.net ?all"
I have changed the ip's to x y and z, but it is real ips and the domain i also real and not domain.tld.
What does the minus in -a: and -ip4: do? does it have a function or is it wrongly setup?
I would like to clean up - can I just remove them? They use mailchimp, so I will just keep the 2 includes.
The relevant bits of the RFC are 4.6.2 and 5.3. Roughly
- means 'fail', i.e. reject any sender that matches this rule
a: means 'all IP addresses that this hostname resolves to'
So the intention of the rule appears to be to prevent anyone using gmail to send email from this domain, presumably because they used Google G-Suite for email at one time but have then stopped.
However I don't think that will work: Google's SPF configuration is more complicated than that and uses 'include:' to pick up lists of addresses specified by Google. I'd be surprised if all of their mailservers hosted the gmail web app too. So my guess would be that this doesn't actually work as-is, and so can be safely deleted.
Ditto the -ipv4 means don't allow this IP address to send email for your customer's domain. Chances are that's OK to go too, but you should verify what the IP address represents e.g. starting with a WHOIS lookup to see who (or which ISP) it's registered to.
I am in the process of migrating our staff's email client from Window's Live Mail to Gmail. I have gone through the process of connecting each staff's email from our domain to their respective Gmail accounts (so each staff has two valid email addresses, e.g. bob.our_domain#gmail.com and bob#our_domain.com). I am able to receive and send mail from the linked account, but emails sent from bob#our_domain.com are tagged with an alarming red question mark and read "Gmail could not verify that our_domain.com actually sent this message (and not a spammer) ". I understand that this is an error with SPF configuration but for the life of me cannot figure out what the correct configuration looks like.
The domain in questions is evergreensupplyonline.com.
Step 1 - Ensure SPF is enabled.
Our server is managed through cPanel, so I navigate to the authentication tab and enable both DKIM and SPF. The default SPF record is
v=spf1 +a +mx +ip4:166.62.38.87 ~all
Sending email with this configuration generates the error: SOFTFAIL with IP 208.109.80.60. Seems reasonable enough, the IP isn't listed and the ~all specifies a soft fail for unknown IPs (as far as I am aware)
Step 2 - Add the sender's IP to the SPF record
I add 208.109.80.60 to the record and my SPF record becomes
v=spf1 +a +mx +ip4:166.62.38.87 +ip4:208.109.80.60 ~all
Sending email with this configuration still generates a SOFTFAIL error but with a different IP (208.109.80.60). Based on this change I assume I won't be able to add a static IP for all of google's mail servers - not too much of a surprise.
Step 3 - Add Google's _spf domain
Following the instructions from https://support.google.com/a/answer/33786?hl=en
I removed 208.109.80.60 and instead include _spf.google.com domain. My SPF record now looks like
v=spf1 +a +mx +ip4:166.62.38.87 +include:_spf.google.com ~all
If I run my domain through https://toolbox.googleapps.com/apps/checkmx/ I get some some non-critical errors but everything relating to the _spf.google.com domain seems to check out. If I send an email with this configuration I still get a SOFTFAIL error.
I'm not sure where to go from here - I've tried all that my preliminary understanding of SPF will permit. Any suggestions, observations, or tricks are greatly welcomed. Cheers,
This does all look correct, apart from one thing. I looked up both the IPs you mentioned (using whois) and they belong to... GoDaddy, not Google, which entirely explains your problem. It's quite likely that GoDaddy is redirecting your outbound email traffic since they don't allow direct SMTP sending, so you may need to add GoDaddy's SPF as well, or move to a more enlightened hosting provider.
A minor thing: put the ip4 mechanism first as it's fastest to match for receivers (it requires no extra lookups), and you don't need the + qualifiers because that's the default action.
So I have the following SPF record for the domain hojio.com:
The TXT records found for your domain are:
v=spf1 ip4:194.150.114.22 ip4:194.150.114.0/24
include:support.zendesk.com include:smtp.zendesk.com ~all
The domain is on the ip 194.150.114.22 and a reverse dns lookup on that ip gives hojio.com
Gmail says:
neutral (google.com: 194.150.114.22 is neither permitted nor denied by
best guess record for domain of www-data#ksenikovweb01.dandomain.net)
client-ip=194.150.114.22;
As if its not finding any SPF record? This is strange, since I can use various online SPF record checker tools, that all give me the correct one. What am I doing wrong?
Are you sure that hojio.com is being used in the Return-Path? SPF works off the Return-Path, not the From address. So it doesn't matter if the From address is from a user at hojio.com, unless the Return-Path is the same.
From the Gmail message it looks like the Return-Path is www-data#ksenikovweb01.dandomain.net. The domain ksenikovweb01.dandomain.net does not have an SPF record, so that would explain the 'neutral' SPF rating.
Right now, I'd like to use zoho mail for manual mailing from my domain and PHPMail from my server to handle automated messages.
Problem is, when my server sends out an email it hits spam filter. I get the following error:
deemstars#server.deemstars.com does not designate permitted sender hosts) smtp.mail=deemstars#server.deemstars.com
My txt record is the following (I Use Cloudflare):
v=spf1 mx ptr ip4:207.244.68.190 a:server.deemstars.com include:zoho.com ?all
207.244.68.190 being my server IP. I also added multiple domains to the txt record to make sure it gets whitelisted. I also included zoho.com, which zohomail sends an email out just fine with no spam filter, and it doesn't get the "not permitted sender" error.
So I think the problem is that your return path address has a domain of server.deemstars.com and your SPF record is defined only on the apex domain. SPF does not check parent domains.
So add the following record to server.deemstars.com
v=spf1 ip4:207.244.68.190 a:server.deemstars.com include:zoho.com mx ptr ?all
and see if that addresses the issue. I've also rearranged the SPF directives to move the cheaper to evaluate, more likely to match ones to the front.