What is Reddit's opinion of
MxToolBox?
From 3.5 billion Reddit comments
➔ MxToolBox website
By popularity on Reddit, this Service is:
100 reviews of this app found across Reddit:
while not an answer as to a possible problem, use this to get an evulation and possible infos on problems
https://mxtoolbox.com/spf.aspx
btw: masking the spf records is pretty funny since it is public to anyone
Anti-fraud checklist:
- Are the billing and shipping address reasonably close to each other? (Most fraudsters do not have a CC with AVS information that's local to their pickup location)
- Is the telephone number provided with the order local to the billing and shipping addresses? (Run a search for the phone number and, if possible, confirm it's not Google Voice, Skype, etc)
- Are the shipping/billing addresses a residence or regular place of business? (If it's a mailbox or forwarding service, you'll likely find that out quickly by searching it)
- Did the customer place the order on your site? (If so, you should have the IP address associated with the order - check the ASN to see if it's a datacenter - huge red flag - or a legitimate ISP local to the shipping address)
- If everything looks good but the order is high value and you still want to confirm it, call the customer - this will confirm that the phone number provided actually works and provide you with an opportunity to thank them for their order, confirm their shipping address, and (if everything seems legitimate) offer them a "preferred customer" discount on their next order to encourage them to spend more with you in the future
> Even if it were from @youtube.com doesn't mean it's still real. You can fake the email address although it doesn't guarantee it goes to their inbox.
Actually, Google uses SPF to ensure that only legitimate senders are able to send from @youtube.com e-mail addresses. Of course, the receiving e-mail service doesn't have to honor SPF rules, but the screenshot from OP is a screenshot of Inbox, one of Google's apps for receiving Gmail (or G Suite) e-mail, which means that they are honoring SPF. If the above came from an @youtube.com address and it made it to a @gmail.com inbox, then it's legit.
I checked your domain's reputation on https://mxtoolbox.com (use the blacklist checker) and it comes up clean. The XYZ review process looks simple enough so just provide them with the results of your checks?
The site uses AWS who are on the list of advertisers to boycott. It's only been 12 hours so I get why they haven't switched yet, but equally, why would lefties use Amazon in the first place.
If you're blacklisted at Spamhouse, you're likely to be blacklisted other places as well.
You can use https://mxtoolbox.com/blacklists.aspx to figure out which ones. Make sure to search both by hostname and IP - I've occasionally seen different results coming up.
That'll help you figure out WHERE you are blacklisted. Some of these guys that have blacklisted you will have an automatic thing on their site that may tell you why you were blacklisted.
You can get hints on WHY you are blacklisted by using email-tester.com - it will give you a spamscore and some pointers on what to improve to make your emails look less like spam.
Good luck.
It would help to know a bit more about your setup.
- Is your IP address residential or otherwise blacklisted?
- Does your ISP/VPS have any restrictions or warnings about email hosting on their platform?
- Do you have your PTR records set up?
- Do you have DKIM keys/records set up?
- Do you have DMARC records set?
- Do you have SPF records set?
- Do your MX records point to an A or AAAA record as opposed to a CNAME?
- Which email applications did you end up using and/or guides did you follow?
- Have you used mxtoolbox.com to check for issues with your configuration?
I have been quite pleased with Poste.io on Scaleway. If you'd like to give that a shot, its very cheap.
Because I was bored, I checked their SPF record (main reason for deliveribility issues is a messed up record or lack there of).
It looks like they're using the SPF type instead of the TXT type.
What does this mean? Well it means your email provider likely rejected their email due to this invalid record.
https://mxtoolbox.com/SuperTool.aspx?action=spf:robertsspaceindustries.com
Someone should message them and get that fixed.
Brownie points if they manage to get a DKIM record in place as well.
It's a large set of multiple blacklists that most email servers are configured to use. If you wind up on one, it's basically time to fold up shop and close down, because no email servers will accept mail from you. It's extraordinarily difficult to remove yourself from them because there are a lot of them and they're all independently maintained, so you have to contact a whole shitload of different people if you get on one.
It's basically a community death penalty for spamming servers. One of the things you have to do if you run your own email (or if you run the email servers for a company that isn't using hosted email from O365 or GSuite or whatever) is keep regular tabs on the lists to make sure you're not on them. It's one of a thousand reasons why self-hosting email is a giant pain in the ass.
[](/nerdtwi) Derpibooru's IP address is 104.24.13.26^[1]. Unfortunately you can't enter it to your browser directly because of Cloudflare but you can make your computer resolve it locally without sending a DNS query.
If you use windows, the way you can do that is by launching notepad.exe in administrator mode, opening the file c:\windows\system32\drivers\etc\hosts, adding the line 104.24.13.26 derpibooru.org and then saving the file.^(see [2])
On Linux (or MacOS) the procedure is pretty much the same but the filename is /etc/hosts (/private/etc/hosts for Mac^[3]). (Oh and notepad.exe doesn't exist but if you don't use windows, you probably know how to use a text editor)
After you have done that, you should be able to access derpibooru again.
Edit: References
[1] https://mxtoolbox.com/SuperTool.aspx?action=a%3aderpibooru.org&run=toolpage
[2] http://www.howtogeek.com/howto/27350/beginner-geek-how-to-edit-your-hosts-file/
i dont get it...they claimed their host shut them down due to a C&D letter from "B".
yet they are still using OVH https://mxtoolbox.com/SuperTool.aspx?action=ptr%3a37.187.103.5&run=toolpage
I think "B" might get them again...lol
This won’t work for websites on shared hosting.
I’d test this before assuming it will work.
Shared hosting is more common for low end/low traffic sites but it’s entirely plausible for a larger website to have multiple services running on the same IP, in which case knowing the IP alone wouldn’t be enough.
You could also find this information without the use of a terminal.
https://mxtoolbox.com/SuperTool.aspx
Select ping and type in the website you want the IP for.
A pair of new Boot Nodes:
- Aceville PTE.LTD - https://mxtoolbox.com/SuperTool.aspx?action=arin%3a118.24.64.210&run=toolpage#
Seems to be an investment firm, subsidiary to Tencent.
General software/IT consulting firm.
ISP gives you IP address
IP address identifies you online
ISP rotates IPs sometimes because ISP stuff
Most people have a "dynamic IP address"
If you have a dynamic IP address, you do not have a permanent IP address
(Many ISPs allow you to request a "static IP" which does not change, probably with a fee)
That means that your IP may be changed by your ISP, and you get a "new" one
Because IPv4, the current IP system used, has a (relatively) limited pool of IP addresses, your new IP was likely in use at some point before you got it
If that IP was banned from anywhere, like Wikipedia, you are now IP banned from that place
There are tools online to check if your IP is blacklisted by services, such as this one. In most cases, you won't notice a few blacklists
It looks like the AWS DNS servers are returning 127.0.0.1 for textsecure-service.whispersystems.org.
Gmail has some black listed Servers as well. Found out from a G-Suite user (not a @gmail.com).
Can't imagine it being out of the question of people getting compromised and then spam e-mail sent from a legitimate account.
Eh I guess you could try ping the website and see what address you get back. Could be two websites on two different hosts
EDIT: Yeah seems to have 4 a records which could be it. Who knows why
What about for SPF? i.e: https://mxtoolbox.com/spf.aspx
Grab one of the sent emails and check the headers and makes 100% sure the origin listed in the headers isn't a subdomain or Outlook.com itself or anything like that and whatever it is has a valid SPF.
90% of the time when people post about this its Gmail auto throwing it to junk because it counts find a valid SPF for the actual message origin.
UDP port 53 is the assigned port for DNS queries. Both the IP addresses (37.59.40.15 and 139.99.96.146) are related to Parrot OS
They both resolve to subdomains of ParrotSec.org https://mxtoolbox.com/SuperTool.aspx?action=ptr%3a139.99.96.146&run=toolpage https://mxtoolbox.com/SuperTool.aspx?action=ptr%3a37.59.40.15&run=toolpage#
So I think it's unrelated to VeraCrypt.
I'm not familiar with ParrotOS personally - but it looks like a 'privacy feature' that they're overwriting the default DNS configuration from your router to use their DNS revolvers rather than your ISP default.
Why exactly sudo is doing a DNS lookup in the first place would be down to how that's configured.
I'd pop over to /r/ParrotOS and ask if I were you...
My first guess is that his router's public IP is blacklisted because somebody had (has?) malware in the office.
1) Find your public IP address
2) Look up your IP in MX Toolbox blacklist search
3) At this point really your network engineering team should know about if you have any hits on blacklists (RBL's). There's maybe 100 well known RBL's out there and they are all run independently and differently. Some just want an assurance that the malware problem is fixed, others have more difficult policies. If the IP is removed and the problem isn't fixed that triggered it, often RBL's will make the ban last longer or add the IP to a more serious list, so it's important that the network team take it from there.
As previously mentioned, outsource it immediately. You can cutover that size organization in a day. I thought O365 offers NPO reduced rates even, although I cannot remember.
From there, I would start with "Do the users need access to Email when not at work? Can they do it over VPN only?" If so, seal off all ports except for your SMTP receive port. If they do need Outlook anywhere and such, make sure those are the only ports open on your firewall. That's a good first step.
Hit up mxtoolbox.com to make sure you aren't an open relay or other major problem with your environment.
Get that DC role off your server. Because the Exchange Server must interact with the outside world, you are increasing the surface area of attack for your entire environment.
Make sure backups are working. You'll know sooner rather than later because if not backed up, the transaction logs don't flush and you end up with full drives.
Remember that Exchange 2010 goes end of life in about 18 months. At that point, they will not release new security updates for Exchange 2010. Now, Microsoft has been pretty decent about patching WannaCry on XP. If you want to run your mail server on a system where any new found vulnerabilities will not be patched, I'm afraid hardening your box is impossible.
/u/Special-Jay is correct to be suspicious of the URL. MSU sites have hostnames that end in ".msu.edu" and only MSU controls those sites, because that root is what gets registered with the domain name registrars. But in this URL, the hostname ends in ".swankmp.net", which could be controlled by anyone. "rha" and "msu" are in the subdomain part of the URL, which can be chosen by whoever controls "swankmp.net" to spoof or fake a MSU site.
For example, I could make a site at "reddit.omgdonerkebab.com" and dress it up to look like reddit, and convince some percentage of visitors to input their reddit usernames and passwords into my site. I could even have it proxy the actual reddit site, so the user has no idea I've seen their password. It's one of many classic phishing attacks.
Furthermore, the links I've seen on the RHA site point to http://movies.rha.msu.edu/, not a swankmp.net URL. I haven't been able to find a swankmp.net link on RHA's site.
That being said, when I google for "swankmp", I do find that there is a movie streaming service called Swank Motion Pictures. So it's possible that RHA is using Swank Motion Pictures to supply the movies. Indeed, when I check the DNS record for movies-rha-msu-edu.swankmp.net on this site, I find that it is an alias for movies.rha.msu.edu. So I think we're probably safe in this case. But if more people were suspicious like /u/Special-Jay, we would have less victims of phishing attacks.
You can verify this
This can be used to get the ips of each node https://mxtoolbox.com/SuperTool.aspx?action=srv%3a\_algobootstrap.\_tcp.mainnet.algorand.network+&run=toolpage
This can be used to geolocate them https://tools.keycdn.com/geo
Postfix is not set up by default to permit relaying. Open relays are why there is so much spam on the internet and pretty much everyone involved in good email hates it, so it's never default behavior. However - some setup scripts for Postfix (depending on your distro) may ask you some questions which if answered wrongly, would result in this behavior.
Glad you sought help. You messed up, but we all do. You'll get over it and hopefully learn. Might be worth giving your server a good long hard look in terms of general security too. (Just going on the basis that if one thing was open, something else might be and your server might be compromised - or vulnerable)
Downside is your IP address is almost certainly listed on a whole bunch of RBLs. But that's okay, we don't want you sending email again until you've learned a bit more about how to run a mail server - if you need to. If you don't need to, then don't. Same with every other service on an internet facing server; everything that's enabled is another security weakness.
When you feel you have learned enough, and have reconfigured your server and turned it on again, use something like https://mxtoolbox.com/diagnostic.aspx to test it to see if it's exploitable. That's a fairly basic test, but it's a start.
Adminning a server well is HARD. Making one secure is also hard. None of us get it right all the time, so feel a moment of shame, but move on and keep asking questions. It's how we all improve.
Send an email from your system to your gmail account and then examine the headers to see if there’s anything obvious with the spf or DKIM check
You could also try these free services out to see if they identify anything obvious:
DNS changes usually take a while to propagate. In top of that, you might have it cached in your browser or OS.
Use tools like https://mxtoolbox.com/DNSLookup.aspx to check where is the DNS actually pointing (but again, it might take a while to propagate).
Also, to check properly, delete the cache of your browser, and restart it just in case.
Experience - Was integrating surveymonkey a while back (which does an embarrassingly horrible job with SPF & DKIM) and went over our limit. Here's some backing info:
https://mxtoolbox.com/problem/spf/spf-included-lookups
According to RFC <em>7208</em>, 'SPF implementations MUST limit the number of mechanisms and modifiers that do DNS Lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier"'
> These servers are hosted by OpenDNS (which has now been purchased by Cisco)
Are you sure? OpenDNS only lists the following DNS servers on their website.
208.67.222.222 208.67.220.220
If you do an ARIN lookup on your IPs they are owned by Rackspace Hosting.
https://mxtoolbox.com/SuperTool.aspx?action=arin%3a23.253.163.53
https://mxtoolbox.com/SuperTool.aspx?action=arin%3a198.101.242.72
DNS means Domain Name System, basically when a developer says they're going to change the DNS configuration for a domain they mean they're going to change where the domain points. When you enter a domain in a browser, the first thing the browser does is resolve an IP address for the domain–an IP address of course being an address of which computer in the network to fetch a webpage from. Here's an example from an online tool, it shows what IP addresses wikileaks.org resolves to:
https://mxtoolbox.com/SuperTool.aspx?action=a%3awikileaks.org&run=toolpage
You can see the IP address /u/YeahButThatsNothing mentioned above is listed there as well (141.105.65.113).
I'll expand on "con centralization" because it is a big subject.
The governance is centralized, which is being addressed by moving towards governance by staking. Even with governance opening up the foundation has advantages over the man in the street holding Algo.
The distribution of algo is quite centralized with the foundation, relay node runners, and early backers holding many tokens.
The relay nodes are only run by 100 relay node runners. The public cannot yet run them. There is a pilot for a small number of 3rd parties to run relays.
The relay nodes are geographically NOT centralized. Some other coins all the block adding servers run in a small number of/single data centers. This is not the case for algo. This is the SRV record that transactions sent to Algorand goes to. The 100 endpoints can be resolved to IP addresses. These are verifiable with ip=>geo tracing to be worldwide distributed. Some of them can even be tied down institutions, many are at universities. https://mxtoolbox.com/SuperTool.aspx?action=srv%3a_algobootstrap._tcp.mainnet.algorand.network+&run=toolpage
There is only one implementation of the relay nodes (an assumption I am making from their git repos), so this is also centralized. I haven't seen exact requirements so they could be running on same technology stack too, I don't know. This could be a single point of failure as all relays could suffer the same security defect.
There is no dns record for the www subdomain. I checked both A and CNAME records from the site below. Without the www it can see the A record just fine.
https://mxtoolbox.com/SuperTool.aspx?action=cname%3awww.mcminnclinic.com&run=toolpage
Update: Thanks to a little help, the flow of illegitimate email has been halted. I was able to use https://mxtoolbox.com/diagnostic.aspx to verify that it's setup correctly now.
Unfortunately, I now have to personally answer two questions: 1. How did this happen after two years of running smoothly? 2. What's the long-term fallout?
I'm not too confident that I'm going to like the answers to either of those, but I should be able to figure it out on my own from here.
Thanks for all the help!
If you do a DNS lookup on the MX record you will see that it points to a Microsoft mail server.
https://mxtoolbox.com/SuperTool.aspx?action=mx&#37;3akent.com&run=toolpage#
BRB - gonna email martha.
I'm going to register websites, slap on Wordpress and some text, put ads on them, then put free sample offers on them. Then, submit them to freebie sites. Profit.
Sarcasm aside and nothing against OP but this smells fake. Why? EVOO is dark green. Looks identical to Intur travel agency fake. Ads on the page. Address is a residential location in Greece. No way to buy. Registered in June this year, expires next year: https://mxtoolbox.com/SuperTool.aspx?action=whois%3A%2F%2Fgreek-olive.com&run=networktools
It looks to be a problem their end as that source IP address (184.106.54.73) is blacklisted (on SORBS SPAM list): https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a184.106.54.73&run=toolpage
The mail provider they are using is Rackspace (doing a quick google of emailsrvr.com) - the company you work with should raise a support ticket with Rackspace and get them to look into this. Rackspace will likely ask for the IP to be removed from the spam list maintained by SORBS.
Whilst troubleshooting emails ending up in junk folders I would first run the headers through this tool:
https://mxtoolbox.com/EmailHeaders.aspx
And send a test email to:
After following these two steps, is there anything that stands out?
This may not be an issue with the server security, but an issue with the e-mail server/network setup. Your server can be completely secure, but if you're running an open SMTP server on it people can send whatever they want.
MX Toolbox tests may be able to tell you if your SMTP server is open to the world.
You can also try to connect to it from a computer outside your network via telnet and attempt to send e-mail.
Also, there is always the possibility that the e-mails are originating from another server and there's some type of phishing/spoofing going on.
The DNS uses a small TTL (600 seconds, it means it's easy to set up another IP for the same address) and it seems that the IP (owned by Nintendo) doesn't have some common ports open (https://mxtoolbox.com/SuperTool.aspx?action=scan%3a205.166.76.238&run=toolpage) (aka the "server" doesn't have any service up yet or the server is not UP, more likely the last)
I got this several hours ago, had a chuckle at what nonsense it was but was on my phone and couldn't check headers. Came home and finally checked the headers and it damn well looked like it came from the FBI itself. Although others have reported it failing verification, the message I received has full SPF, DMARC and DKIM verification. On mxtoolbox I get:
DMARC Compliant
SPF Alignment
SPF Authenticated
DKIM Alignment
DKIM Authenticated
Full report: https://mxtoolbox.com/Public/Tools/EmailHeaders.aspx?huid=9e1d10b6-cc6d-4cb3-bda7-9adaf9ea78b7
Remember, for full verification you need to paste both headers AND body despite the directions to only paste headers.
>They're probably using a cloud provider just like everyone else, and those providers absolutely have data retention policies that all but guarantee copies of these emails exist
It's not hard to figure out where their email is hosted. That said it's entirely up to the NFL's system administrators to configure what, if any, data retention settings or litigation hold settings to deploy.
I do a DNS Challenge request to get Let's Encrypt certificates. The certbot generates a unique key that you have to create a DNS TXT record for, wait for the TXT record to show up on something like https://mxtoolbox.com/DNSLookup.aspx, then proceed with certbot to verify the DNS TXT record. Doing a self-signed cert is such a hassle because you have to get that into every device you intend to connect to Vaultwarden with.
The only caveat is that I haven't found a way to automate this process, so it's a manual thing every few months before the cert expires. Obviously you need to own a domain name as well.
Not that I could find. All CNAMEs make their way via Azure domains to a single IP (though they use traffic manager which appears to be a "load balancer")
https://mxtoolbox.com/SuperTool.aspx?action=a%3aportal.cvms.vic.gov.au&run=toolpage
(Keep clicking the "canonical name")
It's not always DNS, but it's the place to start.
Check MX records for all your domains using a DNS query (not using your cpanel) to make sure DNS servers around the world have received the correct records - DNS can take up to 48 hours to propagate. You can lower TTL for the MX records to help speed up propagation but it's not guaranteed, 5 mins (300s) is reasonable.
dig {YOURDOMAINNAME) mx which will query the DNS server your device is using
dig @8.8.8.8 {YOURDOMAINNAME} mx which queries google's public DNS resolvers
literally... click the link, enter a server name or IP.
Example using google's DNS so I don't spam anyone else's IP in there: https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3a8.8.8.8&run=toolpage
https://postmaster.google.com/
Once you verify your domain here, you can see more information about how Google is classifying your domain. A good start to figuring out if anything else needs to be fixed.
Looking at mxtoolbox.com and their blacklist search your domain is in the clear, so it very well might just be a "wait it out" scenario for everyone to get the updated blacklist info spread around.
First you need the IP Address, you get them via the Resource Monitor: Task Manager -> Performance (I hope, that's how it's called in English) and then at the bottom there is the link to the Resource Monitor. Open the network tab, check BlackDesert64.exe. With the IP address you can do the reverse DNS with an online tool like https://mxtoolbox.com/ReverseLookup.aspx
From the DNS name you get the info, which service it is. For the location use any ip2location service.
I would absolutely suggest doing what other are saying of trying to get access to the DYNDNS account. It will be significantly easier.
If you can not gain access to the the DYNDNS account, using the tools on this site can help get you most of the DNS settings. This does more than just mail so browse all the settings. https://mxtoolbox.com
They modified the "reply to" address to go to you. Check the properties and look for the actual IP it originated from. Willing to bet it's an IP from somewhere like South Africa, India, etc. Paste the entire header here:
https://mxtoolbox.com/emailheaders.aspx
​
Even better if the originating IP has an obvious dns entry like "mail.whoaimfullofgarbage.in" or something.
​
Make sure you (or your users) haven't whitelisted the old domain. You might want to run the header through an analyzer like mxtoolbox to follow the hops too.
I've deleted my commend because my head was up my ass. I'm going to rewrite it.
If they're in the same country as you they could arrest the person for threatening people, that's against the law.
So I said you'll get googles oriognal address if you traced their IP. That may not be the case depending on how the send it, may even be spoofed which is a whole other thing.
Log into your gmail account and follow these instructions. This gives you the origonal email data. A lot of that is a foreign language to me and I do this for a living. But some of it might be intelligible. Copy the contents and put it in here which will break it down into a more easy to read format. See what you see there. But you're not going to get their house number or anything. Might just say an actual address it was sent from or a rough location (city/country).
But honestly, you aren't going to be able to do more than the police. If they're from another country the police more than like won't or can't do anything. But what are you going to do, argue with them? Send them threatening emails? They won't care.
um your domain is actually ccgs.nsw.edu.au not mail.ccgs.nsw.edu.au
Mail. is just one of your mailservers, defined as an A record or (cname for mail1) and referenced in mx.
check out https://mxtoolbox.com/SuperTool.aspx?action=mx%3accgs.nsw.edu.au&run=toolpage# and run the spf test next to your actual email domain, NOT the mailserver name.
To fix it, just replace "mail.ccgs.nsw.edu.au" in your spf record with the letters mx (you have two mx records and this covers both of them)
IP reptutation is the only real issue, IMO.
You'll have terrible luck delivering e-mail with a home connection, as most are on dns blacklists. Check here, you'll probably find you're on one.
And even if you rent a VPS or dedicated server, you'll still need to manage your reputation across the myriad of blacklists and other similar services. Many are public and easy to check (like the link above), but others like yahoo and MS (office365, hotmail, outlook.com) require you to sign up to get access. And sometimes they just drop your mail without reason. Be prepared for your users to blame you for this.
None of the above is hard, but it's time consuming.
I run my own mailservers, and my favourite part is knowing whats happening behind the scenes. Being able to grep logs to check on email deliverability, etc is nice. There is also a lot of fun to be had with tweaking settings and plugins etc.
Personally I'm a big fan of dovecot/postfix/rspamd on debian using maildirs. Here's a good guide:
https://workaround.org/ispmail
edit:
Another thing to note, is that if you use some packaged "mail in a box" type thing, be sure it has good support. You'll get no support from the dovecot or postfix communities if you don't follow their best practices and know how to configure the tools by hand. "It's stock easymail, why doesn't it work?" doesn't get you very far with them.
You need to regularly check the IP address you're going to use against a whole bunch of blocklists. If you're using an IP address that's part of an ISP's residential assignment block, you might be out of luck before you even start.
This will kill the project.
https://mxtoolbox.com/problem/smtp/smtp-reverse-dns-resolution
It is required and most home isp's will not cooperate with you and those who buy the device will not have a clue so most if not all the email will be rejected and the ip will be blocked.
Also most ISP's do not allow access to port 25 meaning you will have to have credentials on the server you are trying to deliver to.
I hate email and gave up email administration because of the hassles.
You can check the IP address of your potential host instance with this blacklist checker:
The issue would be that other sites would reject your emails. Mostly Gmail, which is known to lose mail due to general crappiness. You decide what you will accept.
Email will be queued up for four days. You don't have to worry about losing stuff for outages shorter than that.
Your could check here if the domain is the issue https://mxtoolbox.com/blacklists.aspx
If the domain is the issue it won't matter where you host it - then you have to clean up the domain reputation.
Not know the domain, makes it at bit harder to do tangible help, but also make sure SFP record is set correctly and set up DMARC
That improves email delivery...
We had one client where the email signature meant that mails were in spam on Hotmail recipients.. Nothing speciel, or alarming in the signature, but without the signature mails went through as they should..
Redid the Singapore a couple of times - never figured out what was the issue... But apparently some words were the trigger... Hotmail would not help at all..
>[Y]our browser began working as an RDP.
That's not how the Remote Desktop Protocol works. Nor does the sentence make sense. They clearly don't have a clue what they're talking about.
>[H]as a key logger which provided me with access to your display screen as well as webcam.
That's not how a key logger works, either. Its a key logger. It logs keystrokes. Again, they've no idea what they're talking about.
>[M]y software collected all of your contacts from Messenger, Facebook, and e-mail.
This is one hell of a leap. If they could really do this they wouldn't need to be blackmailing you in the first place.
>[G]enerated a double screen video
Another feeble attempt at scaring you using terminology they don't understand.
>I have taken steps to ensure this mail can't be linked returning to me
Given the nature of this email and the apparent lack of knowledge on the scammers behalf, I find this doubtful.
All emails are sent with with a 'header' that contains important technical information such as the path the email took, who it was sent from, the time is was sent, etc. Most email providers intentionally hide header information that is deemed 'useless' to the user, however, it's not difficult to view the entire thing. The process varies from provider to provider but you can read these guides for Outlook and Gmail to find out more. Once you have the header you can run it through an analyser that will sift through it for you and give you all the information you need.
Conclusion; this is most definitely a scam.
Good luck, OP.
There are lists actually: https://mxtoolbox.com/problem/blacklist/
Each of those on the left-hand sidebar are a public blacklist that you can ingest into a variety of anti-spam servers and services. But generally they only help to block the obvious items to reduce load on the other systems (heuristics, av scanners, DKIM & SPF checks, etc.)
You would be better off using an anti-spam service like Mimecast or something to pre-filter email before it hits your O365 tenant. I say this because every home-brew system or SpamAssassin setup I have ever seen fails spectacularly in this day and age.
https://whois.icann.org/en/lookup?name=teamviewer.us
Seems legit as it is a top level domain, it also pops up in any google search for team viewer.
https://mxtoolbox.com/SuperTool.aspx?action=mx%3ateamviewer.us&run=toolpage#
looks like an alternate for the teamviewer.com domain, for Exchange at least.
How are you sending these emails? The email server IP address is what is flagged as spam, not the domain.
You can check here - https://mxtoolbox.com/blacklists.aspx
Also, this has nothing to do with web design.
> Edit: I think they just overnight switched from free CDN to paid. The website you linked to is for their paid service.
It seems to be about free accounts for open source projects:
> We are committed to contributing to open source projects with free CDN accounts.
That being said, opensource.keycdn.com doesn't have a published DNS record currently, despite having one yesterday.
Whether that's intentional and they shut down the service, or accidental is anybody's guess.
If your ISP blocks outbound port 25 then you're going to be out of luck.
On top of that, a lot of providers will block traffic from residential IP ranges entirely and almost all of them will block traffic from servers without a valid reverse (PTR) DNS record.
Try this test to see if you've got the basics up and running.
0) If you're planning on doing this from a residential IP address, know that you're choosing to play on hard mode.
1) Check the IP address you intend to use against blackhole lists to make sure you're not screwed before you start. Often (but not always) residential IP addresses will be permanently blacklisted and there's nothing you can do about it, so be wary about hosting out of your house.
2) Host from a static IP address with correct reverse PTR records. This will hugely increase your likelihood of having mail accepted and not bounced outright from other email servers that do a reverse-lookup before accepting mail.
3) Configure your server (and your DNS zone file) with DMARC, DKIM signing, and SPF.
4) Don't make stupid configuration mistakes.
5) Don't make stupid security mistakes.
6) Keep it updated and watch the logs regularly for evidence of malicious behavior. An e-mail server is like a puppy. It's fun to play with but it's your responsibility to make sure it doesn't shit all over someone else's house.
edit -
> I don't particularly remember seeing anything about "building a reputation" in your article about running your own mailserver. Did you cover that?
Only briefly—that whole 4-part thing worked out to nearly 30k words and cramming in a discussion around sender reputation would have bloated it up even further. I just mentioned that there are lots of things beyond the actual technical set-up that you have to be mindful of :)
Take your domain and run it through SPF record lookup and take a screenshot. This explains what a SPF record is and this explains the syntax so you understand what your current settings are.
Since your getting multiple spoofed inbound emails I wouldn't be surprised if you didn't have a SPF record setup at all. If you do have a SPF record the qualifier should be softfail at minimum, hard fail if possible.
To further protect against malicious email look into third party spam filtering like Mimecast, DKIM and DMARC records too.
> i want to do an offline lookup - so i am looking for some information i can download, instead of API calls.
Stop and think about this. You're talking about downloading/storing the entire DNS library. Every single registered domain and the IP(s) they route to.
Do some more research on DNS to understand the protocol better before deciding on a solution.
When I have email issues, I start here to gain insights. I so use AWS for the public IP which big email providers trust after a while because they usually won't allow email from residential IP address CIDR's.
The copy I got passed all verifications. You can see the report for yourself: https://mxtoolbox.com/Public/Tools/EmailHeaders.aspx?huid=9e1d10b6-cc6d-4cb3-bda7-9adaf9ea78b7
schau mal in den header der mail was da drin steht, kannst den header auch mal hier z.B. reinkopieren und schau, ob da was zu SPF steht bzw was bei Absender steht
I'll refer you to an online DKIM checker — it's used for email signing. I've just setup a domain and can confirm Apple has not setup DKIM yet! So be careful to make sure you don't have a DMARC record in your DNS TXT section as it will likely cause your emails to be rejected if not configured correctly.
https://mxtoolbox.com/dkim.aspx
In here put your domain & the selector is "sig1". If it can't find a record, then receiving mail servers can't verify the signature if the message is signed.
Well, you have a lot to learn, so I would start google "how to warm up your email" and start from there.. I'm not an expert in this stuff so can't help you with the last bit. Figure out what blacklists you're on by checking at https://mxtoolbox.com/blacklists.aspx
Do a reverse dns lookup to your ip. (https://mxtoolbox.com/ReverseLookup.aspx)
If it's not properly set that might be the issue.
(http://wiki.junkemailfilter.com/index.php/Fixing_Reverse_DNS)
Make sure spf and dkim are well configured in your dns server.
110% for this!!
I mean... just look at Github... another MS acquisition... They were bought by Microsoft all the way back in 2018, and according to their MX record, they are still using Google GSuite!!
M&A is a very long process, especially for large and complex estates.
https://mxtoolbox.com/SuperTool.aspx?action=mx%3agithub.com&run=toolpage
In GoDaddy there will be an option to set the Name Servers. This can be either Go Daddy or another Nameserver. (Usually a primary and secondary are listed).
You need to know where the current nameservers are will then need access to that account to set the new A records.
You can check current nameservers using tools like mxtoolbox.com and use the dns checker
https://mxtoolbox.com/SuperTool.aspx?action=mx%3ayourdomainnamehere.com&run=toolpage
Your public IP that is sending email was probably blacklisted, the mxtoolbox.com site is good one to monitor your domain on. You will also want to confirm that the reverse DNS for your mail server is set properly with the ISP as that can cause deliverability issues with email. You will also want to confirm the SPF record for your email domain includes the public IP address of your mailserver.
An example is v=spf:ip4xxx.xxx.xxx.xxx -all
If you made changes to your SPF make sure you set the TTL low and wait for those changes to propagate across the internet.
It's not as bad as people make out, I've self hosted mail services for a long time now. But yes it does take a bit of work and mail is a tall stack of software. https://mxtoolbox.com has a lot of tools for making sure you're not getting blocked, and resolving blacklist issues.
If you're starting a new host these days you need to make sure your static IP is not on a blacklist, once you get your hands on a clean IP then you can move forwards.
Well, this message is coming from the recipients mail server, so you will have to contact their admins to obtain details about why they are deferring mail from your server.
In the mean time, verify your reverse DNS, SPF, DKIM, DMARC are in order, and check your IP against blacklists with a tool such as MXtoolbox.
According to this MX lookup tool you don’t have an MX record published so email doesn’t go sent to Google, at the moment all your inbound mail is bouncing back to the senders
https://mxtoolbox.com/SuperTool.aspx?action=mx%3aimportadora3gt.com&run=toolpage
Here’s the information you need to set the MX records up. As above you’ll need to do that on the DNS part of the website for whoever supplies your domain which according to the Whois for that domain is GoDaddy.
Here's the reverse dns lookup. Looks like the servers are both registered to baremetal.zare.com and are located in NL. Zare appears to be a dedi (dedicated server) provider with datacenters in London and Amsterdam. So qBT is attempting to connect to a peer that rents a dedi from Zare and uses it as a seedbox for torrenting. Why it's being flagged by MWB I don't know. False positive I'm pretty sure.
I've had much success with eliminating email for notifications. It has become quite difficult to set up a working mail host and onerous to keep it working; for me, email lacks the required reliability. Instead I log failures and generate a Web feed. (Try XML::Atom::SimpleFeed.) Interested parties can subscribe to it, I don't need to manage them, that's another advantage. Since it's on a Web server, I get authentication and confidentiality and access logging for free.
If you decide to not go this way, start debugging with https://mxtoolbox.com/ https://www.mail-tester.com/
You could use /28 or /29 depending on how many VMs will be in the subnet. I like using this calculator here to get a good idea: https://mxtoolbox.com/subnetcalculator.aspx
I've seen this happen because the SMTP server has no reverse DNS lookup established. Drop your server's IP address in here and see what it says, should get a domain listing. If you don't, $1 says that's your issue.
If it is running on a public domain-name use mxtoolbox.com to check the mx-record. MX-record should point to the filter appliance. If everything is behind the same public IP just change the NAT-rule in the firewall.
The filter-appliance should be configured with your domain and also to forward email to each of your exchange-servers
Yeah you have an open relay someone is connecting to. You can punch your mail server in here and it will run a diagnostics and tell you if you have one or not.
I helped a client resolve this issue previously - if it’s going to spam, it’s almost certainly one of:
- the content of the email has been flagged as spam.
- a change in infrastructure not managed by you has caused your DKIM/SPF settings (the “id card” to prove your domain is really yours) to become invalid, causing gmail to think emails coming from your domain are fraudulent.
- the domain has been blacklisted.
Email servers are complex and tedious to manage. Start by plugging your domain into something like mxtoolbox, and then armed with what it’s told you, find a consultant and pay him “fix this now or I lose my business” money.
Yes, I think headers would be key. You can see those by following these instructions: https://www.technipages.com/outlook-2016-view-message-headers/amp#referrer=https://www.google.com
I like to paste headers in https://mxtoolbox.com/EmailHeaders.aspx so they'll make more sense.
Second for mxtoolbox. I used it in one of my previous jobs when our mail started landing in spam and getting bounced back. Traced it back to a compromised user sending spam and it got our domain blacklisted for a while.
Dkimvalidator.com is a wonderful tool that will show you identity alignment and spam assassin scores. If you can grab one of the messages that ended up in the gmail junk folder to look at the headers of the message and digest it for legibility at https://mxtoolbox.com/EmailHeaders.aspx you can get more insight to the cause as well. Finally, I would play with Google postmaster tools and register the domain https://support.google.com/mail/answer/188131
That's really bad customer support. Can't believe they won't allow you to retrieve your account.
Also a stab in the dark: are you certain your domain isn't used for spam? Some of my clients had their email blacklisted because their website was hacked. Maybe that's causing your problem.
You can check sites like mxToolbox to see if your domain is flagged.
Ip-ul pe care e serverul de email e bagat in blacklist. Probabil nu esti singurul client si restul spameaza in draci, asa a ajuns.
https://mxtoolbox.com/blacklists.aspx un checker, dar nu are acces la toate listele.
Some tips and tricks from someone who used to handle email abuse for a GoDaddy competitor:
- Google search for your email app of choice + "show email headers"
- Identify the IP address of the sending email server (not to be confused with the IP address of the sender) by isolating the last line that starts with "Received from"
- Plug the IP into a WHOIS service (I personally prefer https://mxtoolbox.com/arin.aspx)
- Confirm on this screen that the IP is owned by Amazon.
- EX: I just pinged amazon.com and got 176.32.103.205. MX Toolbox's WHOIS confirms this IP is owned by Amazon Data Services Ireland
- It can be a little tricky to determine who owns what IP in this age of host reselling... I've talked to quite a few website owners who had no idea their provider was reselling, in fact. But since cloud services are a growing part of Amazon's portfolio it is actually safe to assume that there will be clearly stated Amazon ownership of all Amazon IPs
Well, I'm currently switching back to DigitalOcean from a different server provider after they had some unacceptable outages and after doing the math and figuring out DO is cheaper. But I had the exact same setup there with no problems (after sorting out the half-dozen IP bans some TOS-violating jerk had racked up before I was assigned his IP range, I hope he had no backups when they pulled the plug).
Make sure your droplet name (on the DigitalOcean control panel) matches the actual DNS name of the server (DO automatically sets up PTR records for you, which a lot of email providers verify), and check if your IP is on any blacklists (the last person it was assigned to might have sent spam or something). If anything bounces, most major email providers have a form to fill out and they'll unblock you, and as long as you don't spam their servers they'll keep you unblocked.
PTR records are basically reverse DNS. DNS translates domain names to IP addresses, PTR takes an IP and gives you a domain. Email providers often check if the IP of your server points to the domain you're sending from, and that the domain you're sending from resolves to the server IP address. It makes email spoofing a bit harder to pull off.
Something to keep in mind is that a lot of companies automatically block or junk anything from a brand-new domain (registered less than a week), so don't plan on really using your private server until you're taken off the "new domain" public block list.
A good thing to do is go to MxToolbox and run all the tests, make sure they don't give you any bad results.
> I'm a network engineer with 2 decades of professional experience
> Since OVH is a webhost and not an ISP, it seems incredibly improbably that someone decided to tunnel their traffic through a compromised or leased OVH server and far more probably that one of the OVH staff are responsible.
Background checks out. Zero practical experience on the administrative side of technology and the follow-up statement shows. You can VPN, you can write a script to brute-force login/passwords through a C&C node. It's not difficult. OVH owns 2.7 million IP addresses, so you are right on one thing, they aren't an ISP. They're bigger than many local ISPs.
Everybody talking about how you can’t stop someone from spoofing your email — that’s not the issue at all. The OP stated that he sees the emails in his server’s mail deliverability report! That’s the biggest issue.
Either someone has legit access to that email account or you have an open relay and need to close it ASAP. Once you do that, I’m confident this issue will clear.
Check Exim (if cPanel) for an open relay:
Go to MX Toolbox and perform an SMTP Test.
If you have an open relay and are on cPanel, run this script: /scripts/fixrelayd
Interesting, I had no idea that 0imgur.com was a thing. It appears to have a single ip. How is Imgur.com blocked, because it appears to have a different IP
If it's a simple as just using the different IP, /u/gaso suggestion of updating dnsmasq config to point to the IP. I think something like
# /etc/dnsmasq.d/imgur_redirect address=/imgur.com/104.28.22.248
Would do what you want. (don't forget the piehole -g)
Otherwise, to get more fancy, like, if you're looking to get imgur.com rewritten to 0imgur.com you could pass your traffic through a proxy and issue a 301 redirect which would cause your browser to actually load 0imgur.com. Or, you could transparently rewrite all requests to imgur.com to 0imgur.com.
Ok, so if mail queue is empty, that means that your mail was delivered (i.e. it's not sitting in the queue).
If your source is 127.0.0.1, you are perhaps compromised.
Some things to try:
(1) The good "Am I an open relay" test to run is here:
https://mxtoolbox.com/diagnostic.aspx
Assuming that it can see your IP address, it will tell you what the world sees when they look at your domain.
(2) Run 'netstat -tunap' or 'ss -tunap' as root to see which processes have opened TCP/UDP sockets on your system. If you see an unknown process talking to port 25 (either locally or remotely), that could be a likely culprit.
(3) Finally, run 'ps wx --forest' as root and try to see if anything looks weird in the process list.
Sorry for such shitty notes, but it is really hard to debug this without being at the console. It's hard to say what's off and what looks weird, in general.
Mail-in-a-Box is very easy to setup. Will handle all the crazy mail related DNS records for you and can be used as a nameserver for your existing domains.
If you're on a residential connection, then port 25 blocking is not your main problem. Most residential IP addresses are on a blacklist, so your outgoing emails will go to spam.
Check your IP address here. https://mxtoolbox.com/blacklists.aspx
My suggestion is to set up MIAB on a cloud host, point all your existing domains to your new MIAB nameserver, then give MIAB A records pointing to your exiting webhost IPs.
Start by reporting a delivery problem to Gmail (https://support.google.com/mail/contact/msgdelivery) With any luck they can fix it for you.
Your IP address or domain may be blacklisted by a third party reputation checker, if that is the case then mail to other systems than Gmail may be affected as well. MX toolbox has an online blacklist checker: https://mxtoolbox.com/blacklists.aspx that will let you test the reputation of IPs or domains. Once you determine which blacklists you are on you can contact the individual blacklist managers to remediate.
tl:dr You need a transactional email service like mailgun not a marketing email platform.
>Mailchimp tends to reject distribution list emails and we prefer to use distribution list emails for a lot of our customers.
They do this because of email laws. If you can't prove where a customer opted-in to your marketing email, you're at risk for monetary and legal actions against you and/or company.
>They also "clean" emails that have bounce backs. This has resulted in critical emails being removed from our lists, so notifications aren't delivered to customers who need them.
If the email is hard bouncing, they will never receive them, removed or not.
From a marketing standpoint you want the bad emails removed as it only hurts your domain reputation and could lead to spam reports from the recipient thus your domain/IP could be blacklisted, which further ensures your email wont be seen. Mailchimp is trying to protect itself from being blacklisted, damaging it's reputation with email providers.
What you are looking for is called a reverse lookup or reverse DNS. And yes there are tools that will take an IP address and provide the computer's domain name. This service, for example: https://mxtoolbox.com/ReverseLookup.aspx
On a Linux box you can also use the "host" command. For example, run "host 8.8.8.8" and it'll tell you the address is in the google.com domain.
There is a catch through. Since many servers host more than one domain, your reverse DNS query will usually only return the first match. So if a server hosts 100 domains, you might just get the first domain name. Keep in mind you may be getting an incomplete list of domain names.