Neil Anuskiewicz's questions

I helped someone migrate their email from a web hosting service because of deliverability issues. Anyway, the migration went well:

• Migrated email
• Set mx records
• Authenticated domain name (SPF and DKIM)
• Implemented DMARC (reporting only for now)
• Added accounts to their Apple Mail and mobile email client

Email sent from a PHP form that sends an email whenever a new order comes in arrives in both the account inbox but also a copy of it arrives in the subfolder for the account" user and the important user so it's three places for email. The email is basically an orders notification that summarizes the order so they know there's an order to be fulfilled (it's a physical product that needs to be shipped).

I helped them do a rule that said if To contains orders@ then move to orders folder and applied to existing email. It worked on existing email but the rule doesn't run on new orders coming in.

The rule wasn't meant as a permanent solution anyway, but as a stopgap, until I could find the root cause. Any ideas on why this rule doesn't work on new emails? And any ideas on the root cause of this and how to solve it so the email does not show up in 3 folders? It's a lot of clutter is the issue.

addendum

I've noticed that the form sends from [email protected] so maybe the reason this is happening is that is the same address as the account the form submits to. So google thinks that since the email is "From" the same account that's being sent to it thinks it must have sent it so it puts a copy in sent. I think that might be what's happening. Now, I'm wondering if there's a way to work around that so emails "from" the orders@ address are identified only as incoming emails for the inbox not as a sent email as well. Any ideas on a way to do this if my hypothesis makes sense as a possiblity?

I have a client where some of their emails, including some email from me bounce back with a smtp; 550 code. There doesn't seem to be any pattern on which emails bounce and which go through. One of their domains the email is hosted by the web host, and the other domain names the email's hosted by G Suite. The problem seems mostly limited to the domain hosted by the web hosting company, but I'm trying to get that clarified. The client is in another country so communication isn't always easy.

Message not delivered
There was a problem delivering your message to [email protected]. See the technical details below, or try resending in a few minutes.
The response was:
550 "The mail server detected your message as spam and has prevented delivery."


Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.0.0
Remote-MTA: dns; example.com. (192.0.2.20, the server for the
 domain example.com.)
Diagnostic-Code: smtp; 550 "The mail server detected your message as spam and has prevented delivery."
Last-Attempt-Date: Wed, 21 Mar 2018 00:32:19 -0700 (PDT)

They opened a ticket to their web host who responded back:

You may have Malicious scripts on your server as your server IP has sent emails to SPAM Traps at least twice in the last week. I have therefore asked the Cloud Support Administrators to verify if that is true.

If they do find so we will tell you that to correct this issue you will need to find a third-party service that specializes in cleaning sites of malware. We normally recommend a third party provider called Site Lock.

Why would something like this cause some INCOMING email (seemingly randomly as some email gets through some does not) to be marked as spam and bounced? I would think a problem such as the one described above would affect OUTGOING email. There's something I'm not understanding here.

They originally retained me to help them because OUTGOING emails were going to the spam folder. I noticed their ISP (not their email host but the IP addresses of the ISP showed in the headers) was on multiple blacklists. They said the ISP wasn't good and switched. That alone seems to have solved the outgoing email problem, but then this weird problem of emails sent to them bouncing back started happening.

I thought the ISP's bad IP addresses were affecting their deliverability, which makes sense but is also strange because you'd think the IPS, which just happens to be how someone is connected to the Internet would not affect email deliverability. The ISP was not hosting their email. I don't quite understand why the ISP would affect email deliverability but it seems like it does. Why would someone's ISP's IP address rep affect their deliverability if they host their email elsewhere and use the ISP just to connect to the Internet? It's a separate issue than the one above but still puzzling.

I don’t have much experience dealing with AOL. If someone on a shared IP address at a web hosting service got a bounce like this:

[email protected]
  host mailin-02.mx.aol.com [64.12.88.163]
  SMTP error from remote mail server after initial connection:
  554 mtaig-mcd04.mx.aol.com ESMTP not accepting connections

They opened a ticket to their web host who wrote back that they (the hosting service) isn’t responsible for the IP address, especially “after use,” which seems like a strange response because it’s a shared IP and obviously has been used a lot and still is being used a lot. Anyway, the hosting provider also said the solution was to get on AOL’s white list, sending a link to apply for it. My understanding was that in situations like this the host owns the IP address and just provisions it to one or more customers, and thus it would be the hosting company that would apply for the whitelist?

The IP address isn’t exactly in great shape. It’s on a few blacklists that don’t seem to be the most important blacklists but nevertheless, they’re evidence the IP address isn’t exactly clean: CASA CBL, OSPAM, and SORBS. Anyway, any thoughts on how to resolve this issue with AOL? Is filling out the whitelist form for this shared IP address the best approach as the hosting service’s tech support suggests?

I'm trying to help someone who uses Outlook for outgoing mail for their root domain, example.com, and then they set up mailgun for mg.example.com.

They made a bad judgment call and sent to an old list that hadn't been sent to in over a year, resulting in high bounces.

Now ALL the email they send from the root domain to gmail and G Suite users goes to the junk folder. They realize the bulk email send was a mistake and won't ever do it again. It's only two users using outlook for outgoing email and they now just need their ordinary email to work. They don't plan to do any more bulk sending.

They deleted mg.example.com then they submitted this Google Form to try to get the issue resolved with Google. It's been over 48 hours (the time Google indicates) yet the emails are still going to spam.

My hypothesis on why the problem isn't resolved is that they only submitted the root domain in the form to Google, not the mg.example.com. I think that perhaps they should re-create the mg.example.comand its mx records and submit the form again?

Also, they skipped one the fields in the form to submit to Google, which they said they skipped because it wasn't required. I'm not sure if that is part of the problem as well as maybe Google wants every field filled out. This is the question they skipped.

Are you able to ping any/all of the servers listed in the MX record? Please include the results of your ping tests. To ping servers listed in the MX record, use the command: 'ping gsmtp185.google.com' in all platforms. (Replace 'gsmtp185.google.com' with the results from the DNS MX lookup.)

What's the best way to resolve this problem and get their day-to-day email Inboxed as it was before the mistake they made? Thank you.

I'm trying to learn dns and bind on centos 7 at digital ocean. When I run named-checkzone I get the same errors. When I change around the white space I stop that error only to replace it with a 0 SOA and no NS error.

sudo named-checkzone example.com /etc/named/zones/example.com.zone
/etc/named/zones/example.com.zone:1: no current owner name
/etc/named/zones/example.com.zone:2: no current owner name
/etc/named/zones/example.com.zone:3: no current owner name
/etc/named/zones/example.com.zone:16: no current owner name
/etc/named/zones/example.com.zone:17: no current owner name
/etc/named/zones/example.com.zone:18: no current owner name
/etc/named/zones/example.com.zone:19: no current owner name
/etc/named/zones/example.com.zone:24: no current owner name
/etc/named/zones/example.com.zone:25: no current owner name
/etc/named/zones/example.com.zone:26: no current owner name
/etc/named/zones/example.com.zone:27: no current owner name
/etc/named/zones/example.com.zone:28: no current owner name
/etc/named/zones/example.com.zone:29: no current owner name  

$ORIGIN example.com.
$TTL 14400
@    IN    SOA    ns1.example.com.    hostmaster.example.com. (
2014071301 ; serial.  date.    today + increment
3600       ; refresh. seconds. frequency slave refreshes from master.
600        ; retry.   seconds. frequency slave retries master after failure.
604800     ; expire.  seconds. slave stops responding as authoritative.
86400      ; ttl.     seconds. Maximum caching time by resolver.
)

;------------------------------------------------------------------------------
; Special Records
;
; Note: SPF Records are limited to 10 DNS lookups recursively.
;
IN NS    ns1.example.com.
IN NS    ns2.example.com.
IN MX    10   mail.example.com.
IN TXT  "v=spf1 -ALL"

;------------------------------------------------------------------------------
; Main Records
;
@           IN A    192.0.2.1
*           IN A    192.0.2.1
ns1         IN A    192.0.2.2
ns2         IN A    192.0.2.3
mail        IN A    192.0.2.1
www         IN A   192.0.2.1

Same thing with the reverse called db.192.0

$ORIGIN  2.0.192.in-addr.arpa.
$TTL 86400

@      IN      SOA     ns1.example.com.        hostmaster.example.com. (
3 ; serial
21600      ; refresh after 6 hours
3600       ; retry after 1 hour
604800     ; expire after 1 week
86400 )    ; minimum TTL of 1 day

@  IN  NS     ns1.example.com.
2             IN      PTR     ns1.example.com.
3             IN      PTR     ns2.example.com.