Date
1 - 5 of 5
Google and SRV records
Pamela Means
We’ve been trying to support customers who’s mail is getting blocked by Google. No where can we find how they create the record. Do any of you have a link that would help? Thank you Pamela Means MTA Support Center
|
|
Peter Barclay PCNI
https://support.google.com/a/answer/168383?hl=en&ref_topic=1354753
That may help…
From: nuga@groups.io [mailto:nuga@groups.io] On Behalf Of
Pamela Means
Thank you Pamela Means MTA Support Center |
|
Andy Tibor
If that doesn't help, these might:
For standard Gmail users:
G Suite Email Logs:
|
|
JP
Do you have any headers to share or error messages? There isn't much to go on from your request.
I have seen GCI getting blocked by Google because they (GCI) was on a blacklist somewhere. In another case it was rate limiting. I have also seen it where MTA was intercepting (or blocking) port 25 and 587 but not 465 on one client a number of years ago. In every case it was discovered by looking closely at the headers. Google recently made some full tracing/tracking available through the console, so that might be of some help to the client: https://www.google.com/search?q=google+mail+trace On Fri, Nov 3, 2017 at 10:08 AM Pamela Means <meansp@...> wrote:
-- |
|
Chris Luth
I'm guessing you meant SPF records, not SRV records, in your subject line. (SRV records are typically used in many SIP server deployments, but not, AFAIK, commonly in email.) Some of the links sent previously touch on publishing SPF records. Lots more info on Google if you search for "How to publish SPF records" or similar, like this one: https://blog.returnpath.com/how-to-build-your-spf-record-in-5-simple-steps/ In your case, are they sending from their MTA email accounts and the MTA emails are being blocked, or are they sending from their own domains? MTA does appear to have an SPF record published: v=spf1 mx ip4:209.249.170.32 ip4:216.137.212.196 include:spf1.neonova.net ~all So if emails sent from their MTA email accounts and through MTA's servers are being blocked, someone in network admin at MTA needs to look at that SPF record and make sure it's correct and up-to-date. If they're sending from their own domains and through their own servers, then they would need to get in touch with whoever hosts their nameservers and publish their own SPF records that include the IPs of all their mail servers as well as all servers that send mail on behalf of that domain. We'd probably need some more concrete information about which emails are getting blocked and how they're being sent to help diagnose the solution--i.e. are they sending through a local mailserver on their premises but using their MTA email accounts as the sending address or some other situation like that? On Fri, Nov 3, 2017 at 2:35 PM, JP <jp@...> wrote:
|
|