I purchased my domain through Google Domains. It's awesome because you get up and running with almost everything pre-configured for you.
Until you want to change a few things!
I'm using AWS SES to send emails from my platform through this domain. This means I need to tell DNS to allow SES to send emails on behalf of this domain by adding an SPF record.
According to RFC4408 a domain cannot have multiple SPF records. And this is where things get complicated.
Out of the box, Google Domains gives you pre-configured Synthetic Records, SPF being one of them:
There is no way to edit these pre-configured Synthetic Records and clicking on the Delete button feels intimidating.
There is a section to add Customer DNS Records but that would mean that RFC4408 would be violated.
How do you resolve this?
I don't think you have any choice; you need to scrap what they provide and build your own set manually. It shouldn't take you long – there are not many records there. You can probably drop the SPF-type record safely, leaving just the TXT one.
The RFC violation is a factor, but the practical reality is that no receiver will check for more than one SPF record (because of the RFC), so it wouldn't help even if you did add multiple SPF records.
Most important though – keep an accurate record of exactly how it was originally configured so that you can get back to it easily!
Related
I train customers how to use Emarketing tools. One important thing I tell them they have to do is have their IT set their Email domain DNS to allow the emarketing domains to send on their behalf via an SPF record and I give them most all the settings. Until this one current client where their IT is refusing to create one. My understanding is if they don’t, at minimum, all their Emarketing emails will basically all go to junk/spam or even get them blacklisted in places. So... is there a potential downside to making an SPF record that would make this person so adamantly against creating one?
The main downside of making an SPF record that actually helps deliverability (by confining mail sources) is that you have to know and limit the sources from which email may be sent, and that's not necessarily easy.
Say your domain is example.com and you want to send email from that domain using your gmail account (though gmail is not used to handle your domains email); your SPF would need to include gmail's SPF, and it therefore means that anyone on gmail gets to be able to send in your domain's name from gmail (other measures notwithstanding). Now imagine you're a big company and you have a long history of having employees routinely send email from company addresses using their local ISP. Your SPF needs to become very large, or very dumb, and includes so many email sources it becomes ineffective as a countermeasure.
Reluctance to have to deal with user complaints when you say that all outbound mail must go through company mail servers (when you have a long history of not requiring that) would be painful for a lazy IT support department. I have no sympathy for this policy - you reap what you sow.
You can of course have an SPF record "in name only" by having it set to something useless like +all - that would get a technical SPF "pass" for all sources, but in all other respects it's completely useless, marking fraudulent, spam & phishing messages as equally valid as legit email.
Any IT department that wilfully ignores the benefits of SPF is eventually going to have a major problem with deliverability and phishing, so you can reasonably argue they are failing to do their job, and I'd recommend reporting them to higher management.
After noticing that our emails are being delivered to the spam folder on Gmail, even though it only happens with gmail, we are investigating any possible issue.
Now, we are looking into the SPF record, which look like this after a cleanup:
v=spf1 a include:sendgrid.com include:_spf.google.com -all
Tests we run on http://www.kitterman.com/spf/validate.html result in a "Too many DNS lookups in an SPF record" error.
As far as I know, the SPF record there has only 2 dns lookups... and I checked other SPF records, such as Sendgrid's and they have far more lookups and still their test return "Passed".
My SPF record is published both as an SPF and TXT. Am I missing something?
Domain is fulltraffic.net
The sample SPF record has three mechanisms which may require DNS lookups: the "a" mechanism and two "include" mechanisms. This is well below the limit of 10 defined by the latest RFC7208 version (see https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4 and this limitation was already present in RFC4408).
The culprit here is that "include" triggers a recursive evaluation of the included policy, but the limit is for the complete evaluation (as opposed to per policy). In your case, the included policies define 7 further includes, which in turn define further includes, in overall exceeding the 10 DNS-based term limit.
You will need to find a way to reduce the number of DNS-based terms, like replacing your "a" mechanism with an "ip4" mechanism.
I have 2 Windows 2008 R2 boxes running in Microsoft Azure. My ASP.NET 4.0 site (let's imagine it's running at "example.com") has a standard Contact Us form.
When a user sends a Contact Us message, I use System.Net.Mail and SmtpDeliveryMethod.Network to deliver mail to an IIS6 SMTP server running on each box, which sends the mail to a Google Apps "enquiries#example.com" account, using the email address the user entered into the Contact Us form as the "From" address.
This was working beautifully for a year until I checked it today, and found this error in a .BDP file in the \Badmail folder:
550-5.7.1 Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been blocked. Please visit http://www.google.com/mail/help/bulk_mail.html to review our Bulk Email Senders Guidelines.
Obviously Google upped their anti-spam strategies in the last 6 months - last time it worked was Feb 2013 (yeah, we don't get much mail luckily... yet).
I've read the Bulk Senders Guidelines linked above, but they're not really suited to my use case. My case is not sending emails from our server to users of our site (I simply use the Gmail API and send from our enquiries#example.com for that), but rather to collect users' enquiries so that we can easily respond by clicking Reply in that inbox.
I am looking for the easiest solution here. In response to the ones in Google's Bulk Senders Guidelines:
Use a consistent IP address to send bulk mail: I already do, doesn't seem to help
Reverse DNS: Godaddy, my domain and DNS provider doesn't seem to support them: http://support.godaddy.com/groups/domains-management-and-services/forum/topic/how-do-i-setup-reverse-dns/ Anyone know if there's a way?
Use the same address in the 'From:' header on every bulk mail you send: This is totally not my use case. I'll have different From headers in every email
SPF record: I think this only works if I am sending From ...#example.com every time. Is that right? My feeling is SPF doesn't help me here. Would love someone to enlighten me.
DKIM: This looks hellishly complicated, but I'll pursue it if someone thinks it can work in this case. Specifically is it OK that the From address doesn't match the "signing domain"? Anyone got any good "how to" links? And will this be sufficient for Google to un-blacklist me?
Sendgrid: Azure's preferred mail sending app. This means signing up, code changes, testing, and unknowns like "does Sendgrid allow any From address? It's non-trivial, and I'd like to avoid this, but again, will go there if it's what people think is the sanest option.
As a general answer to your questions, sending email on behalf of many different domains from one IP (e.g. example.net, example.org, and ex.co from 10.0.0.1) is generally seen as spammy behavior (and therefor not recommended).
Your points 1-5 only apply if you're sending from one domain. rDNS, SPF, and DKIM only improve delivery for one IP to one domain (in a generally 1:1) relationship.
Generally, the best way to avoid getting marked as spam in a situation like this is to set the From email as a consistent one that you actually control (e.g. enquery-sender#example.com), and then setting the Reply-To as the entered address (e.g. enquirer#someprovider.com). This way you consistently send from one domain, while still getting the benefit of replies going to the message originator (for example LinkedIn does it this way). Doing this will allow you to setup rDNS, SPF, and DKIM with benefit.
That said, if you decide that you don't want to use the recommended Reply-To method, you can use SendGrid to send from any arbitrary domain. It should not require any significant code change (just switching your current SMTP credentials to SendGrid's).
Disclaimer: I am a SendGrid employee.
I'm using node.js's dns.resolve function to find NS and CNAME records for a given domain. I also would like to get TXT and SPF records now. If I do that all separately - it's four requests. Is there any way to get all four record types in one request?
Also, is the SPF information always in TXT record type or it can have its own?
I'm no Nodejs expert, but just from looking, it appears you're going to have to do four different requests.
Also, is there any way to query SPF record with this function at all
or should I use something else?
Well according to Wikipedia, SPF is:
Sender Policy Framework (SPF) is an email validation system designed
to prevent email spam by detecting email spoofing, a common
vulnerability, by verifying sender IP addresses. SPF allows
administrators to specify which hosts are allowed to send mail from a
given domain by creating a specific SPF record (or TXT record) in the
Domain Name System (DNS). Mail exchangers use the DNS to check that
mail from a given domain is being sent by a host sanctioned by that
domain's administrators.
You could code your own, probably by querying the TXT record and then doing a check to see whether it is valid.
Again, I have very minimal Nodejs knowledge.
Before I begin, I guess this may not be strictly programming related but I think it's definitely related to web programming.
I'm after a domain for a startup project and I notice that it is currently on "clientHold" registrar status. From the research I've done this suggests that it is in dispute either due to an ownership dispute, a payment dispute or someone has suggested the domain is used by spammers/scammers. The whois data seems similar to other spammer details I've seen posted, and at the very least is largely anonymous.
The domain is registed with XIN NET who appear to be notorious for supporting spammer domains. I'd love to just contact the registrar but their site copyright is 2006 and I can't find any appropriate contact path. Even then, they are probably too large to actually deal with and my Chinese skills are limited to Google Translate.
One thing to note is that the expiry date for the domain isn't for a few months.
My questions are:
Is there any rule on how long a domain can be held in clientHold status?
Does the "last updated" whois data indicate when the domain was initially put
on clientHold?
If the site is put up for deletion, will it enter a pending deletion status
for some time or is it likely to just drop instantly?
Any details on how this stuff works would be appreciated.
your best bet if you really want it is to use a backordering system like godaddy has. If after a few months it still hasnt become available, you can move your backorder to another domain.
In my expirience, rarely will you ever see a domain in this status become available.
clientHold just means the domain won't resolve.
You can find now at https://icann.org/epp an explanation of all possible statuses, tailored for end users. It is mostly ok but applies only to gTLDs. ccTLDs may use the same statuses, or others, or with different semantics so it all depends on which TLD you are in.
So back to your questions:
Is there any rule on how long a domain can be held in clientHold status?
No. clientHold is under control of the registrar sponsoring currently the domain name, and which should be put on behalf possibly of end client. So a domain can be in perpetuity in this state for various reasons. There could be also serverHold which has the same consequences but is solely under control of the registry and can be used during disputes or domains confiscation.
Does the "last updated" whois data indicate when the domain was initially put on clientHold?
Maybe, maybe not. There could have been any other updates on the domain (change of contacts, change of nameservers, etc.) so the date really shows the last update without knowing what that update was.
If the site is put up for deletion,
This is unrelated to clientHold, except in the sense that some registrar can put a domain under this status at, or after expiration, as a last attempt to get attention from the registrant that it has to renew the domain at the registrar or else loose it. Make it temporarily not resolvable anymore has, from experience, the consequence of having some registrants, who did get already multiple email notifications of the impending expiration, suddenly realise they do have something to act on quickly.
For the way gTLDs are deleted/expired, refer to ICANN gTLD lifecycle at https://archive.icann.org/en/registrars/gtld-lifecycle.jpg
It is similar, but not identical, in ccTLDs, so again it depends on the TLD you are in.
will it enter a pending deletion status for some time or is it likely to just drop instantly?
Again, depends on the TLD. But in gTLD it is redemptionPeriod (typically 30 days) after the registrar sends the delete command to registry, and then pendingDelete (typically 5 days) after that before the registry really deletes it finally from its database, after which it should come back as generally available for a new registration.