TL;DR - Based on your calculations you are considered a high volume sender and would be a candidate for a dedicated IP address in AWS SES I was unable to find a source where AWS specifically enumerates what they consider to be high volume e-mail sending. Other sources vary (or are vague) about what they consider high volumes (see references below). From those sources I think you can safely say 100k e-mails a month is the high volume threshold. Note that there are several pros and cons to using a dedicated IP address that you should consider as well. Pros Good for high volume senders Your reputation will be your own Your IP is more likely to be safe-listed by ISP's You can isolate your reputation by e-mail type, recipient, etc. The IP address will never change Cons It requires additional setup and time to build reputation (and keep it) You manage your own reputation Not good for unpredictable sending patterns Additional monthly cost Your dedicated IP address needs to warm up before it will be accepted. You'll also need to keep a steady volume to maintain that reputation. For each ISP with which you want to cultivate a reputation, you should send several hundred emails within a 24-hour period at least once per month. Finally a couple of caveats I saw in the AWS SES Developers Guide: If you don't plan to send large volumes of email on a regular and predictable basis, we recommend that you use shared IP addresses. If you use dedicated IP addresses in situations where you're sending low volumes of mail, or if your sending patterns are highly irregular, you might experience deliverability issues. And: Although there's no minimum commitment, we recommend that you lease more than one dedicated IP address in each AWS Region where you use Amazon SES....When you lease more than one dedicated IP address, we distribute those addresses as evenly as possible across the Availability Zones in the AWS Region that you specified in your request. Distributing your dedicated IP addresses across Availability Zones in this way increases the availability and redundancy of your dedicated IP addresses. References https://docs.aws.amazon.com/ses/latest/dg/ses-dg.pdf#Welcome https://www.shiftparadigm.com/insights/dedicated-vs-shared-ip-how-they-affect-email-deliverability/ https://sendgrid.com/resource/how-to-send-high-volume-email-sendgrids-smart-scaling-guide-2/ https://www.litmus.com/blog/dedicated-vs-shared-email-ip/

I think you're referring to the https://essenceofemail.com/blog/email-subject-line-and-preheader/ In brief, a preheader is a text that comes after the subject line when an email is viewed in your inbox. It’s often used to give your email list a taste of what’s inside the body of your email. Here's an example of a hidden pre-header once you open the email from the article:

I believe the proper way to handle this is option 1. I would definitely recommend sending an email to old address to confirm that it is indeed the same user asking for the change. Once the change is confirmed, the user should be prompted to create a new account/passord using the new email address (for security). Also, consider to disable/remove the old account at some point. Here is a reference to a similar case that may be helpful: https://ux.stackexchange.com/questions/1581/when-a-users-login-email-has-been-changed-what-should-happen?rq=1

It's an email marketing tool right? If so I would choose B. Assuming there are 5 recipients in the list and I want to check the email status. Sending is a real short-time action and it will not appear at the same time with sending ,so i would consider sending=sent, unless it failed but it will turn to a different color, so it doesn't matter. In that way, you can differentiate sending/sent and active. (I suppose active would show near the sending/sent). So B is better.

The standard method for remotely accessing Maildir inboxes is IMAP. Set up an IMAP server on your remote machine (e.g. Dovecot/Cyrus/Courier), then install an IMAP-capable Android mail app (e.g. K-9 or Gmail). Practically all such mail apps support HTML body parts.

As the user requested hourly updates, they'd probably be confused if notifications from previous updates were included. Of course, the text has to be modified: 1 new notification since last update. A proposal for giving full information: 1 new notification since last update, in total 4 notifications unread.

If email notifications are enabled, sending them only to the primary email is a sufficient option. It is more concise and requires less maintenance. The secondary email most common use is for access recovery only. Sending notifications that are not relevant to the access control to the secondary email seems like an overcomplication. If a user wants a different email for the regular notifications, he or she can make it the primary one at any time.

If the user needs to read the full lengths of the email you only have 3 choices: wrap the text disclose the value or redesign the element to accommodate more space In the disclosure option, it's possible to limit the number of chars. displayed for each email address and apply an ellipses. When the user needs to read the full email address, they can focus or hover on the object, and the system can display a tool-tip for the full string value.

utm_ is not a start since that's too common to use as a differentiator. And you have not provided nearly enough detail to determine which tool might have been used to create the emails. The simplest method is to search the Subject field for "LinkedIn" and compare it to the sender domain. If the subject mentions "LinkedIn" and the sender is not LinkedIn, then block. Same for Reddit and shipping companies. But frankly, it sounds like you need to get a commercial email security tool. There are lots of factors to consider, and you will end up trying to reinvent the wheel if you do it on your own. I don't normally suggest that people should just buy their way to a solution, but having designed my own email security filters, and having procured commercial solutions, this is one area where you will end up saving a ton of time, avoiding headaches, and ultimately getting a better outcome if you go commercial.

The reason it looks off is that it's a tracking link (as indicated by /track). This is not entirely uncommon. You can sometimes see it in marketing emails, where every link is automatically rewritten to point to some tracking server (which tracks the opening of the link and then redirects to the real target). Just based on these being tracking links, we can't answer if it's safe to click on or not. In addition to any other link you receive via email - which could be safe or unsafe - there are a couple additional things to consider: your click will be tracked. Tracked info will likely include: when you clicked the link, which link you clicked, the email the link was in, your PII (from the looks of it at least your email address), probably your IP, etc. the target of the link is obfuscated. So you can't hover over it to see the target domain to decide if you want to click on it or not. So you should take the usual precautions when clicking on an unknown link from a semi-trusted (I assume) source: if you are worried about drive-by-download issue (malware, browser exploits etc), don't click the link. Or at least use a dedicated VM or similar. if you are worried about downloaded files (viruses, etc), don't download anything (esp. no malicious files; executables, doc/docm and other macro formats, etc). Or at least use a dedicated VM or similar. if you are worried about client-side attacks (XSS, CORS, CSRF, etc), open the links in a dedicated browser profile to separate them from your authenticated sessions on relevant websites. if you are worried about phishing, don't enter any personal information on the linked sites.

You can check the https://www.gstatic.com/ipranges/goog.json that Google advertises to the internet. The list does include 209.85.128.0/17 which corresponds to all addresses between 209.85.128.0 and 209.85.255.255. So yes, the IPs you list do belong to Google. Do note that simply checking if the IP belongs to Google using a IP whois lookup is not enough, as that would include IPs from Google Cloud, which can be used by customers and may potentially even be malicious.

1. How did it pass SPF, DKIM and DMARC? It doesn't. From the snippet you provide, SPF, DMARC and DKIM are either not present or fail. The email address has just been spoofed. Authentication-Results: spf=fail (sender IP is 31.192.237.146) smtp.mailfrom=facebookmail.com; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=facebookmail.com;compauth=fail reason=000 Received-SPF: Fail (protection.outlook.com: domain of facebookmail.com does not designate 31.192.237.146 as permitted sender) 2. How does this scam work? My best guess is that they are hoping you have a facebook account on this email, and will try to report the activity by sending an email to them. Then they will try to phish credentials from you by asking you for your password for "verification purposes" or something. Of course, a savvy user will recognize this as phishing, but unknowing users might think it is legitimate, and fall for it.

DMARC requires passing either SPF or DKIM. Passing requires domain alignment. While this message does have valid DKIM (for d=myprivategym.ae), it does not align with your domain (contoso.com). Anybody can set up their own DKIM for their own domain, so this is not a useful signal unless it claims to be your domain, in which case they'd have to obtain a DNS entry to be valid. That's why https://en.wikipedia.org/wiki/DMARC#Alignment is so important. Since it doesn't pass SPF and doesn't have aligned DKIM, DMARC failed and your prescribed policy of quarantine triggered. However, your mail server likely isn't configured to do anything useful with DMARC p=quarantine. That's probably a good thing, it's not a strong signal. Incorporating it as one of many features in a larger anti-spam system (like giving it some points in SpamAssassin) makes sense, as does actually quarantining it (assuming you have a useful quarantine system, say that rescans its content after some time delay). Even in the best circumstances, it's easy for a quarantine action to be insufficient to block spoofed messages. When you've finished vetting the aggregate DMARC reports after some window of time, you can decide that it's safe to upgrade to p=reject, at which point you can configure your MX records to reject or delete such violations, but many admins have sadly concluded that even DMARC p=reject is not a strong enough signal, so it again must be combined with other threat indicators and a clever campaign can still sneak through.

Perhaps you have credentials saved in the credential cache? BleachBit might not touch that. Check in Credential Manager (which you should be able to find in Control Panel or just search for it from the start menu). You might also check the Mail dialog in Control Panel, as that will likely have your email address configured, and may be part of your Windows identity that can be supplied to a website.

It depends on what risks you consider. Think, who can be interested in getting information about your taxes and what benefits will they get after getting such information. How much money are they ready to spend to get your information? If a lot, then it will be very hard to protect the information: They may intercept your paper post, install spying devices in your home, in your car etc. How big is probability that somebody is ready to spend such amount of money to get information about your taxes? If you want to protect only against occasional accessing this information, then (arguably) the solutions may look as follows: Paper post. Encrypted PDF: Encryption with AES-256 is sufficiently strong, PDF readers are normally preinstalled on the most PCs, tablets, smartphones, so the receiver will no need to install any additional software. Encrypted ZIP: Encryption with AES-256 is sufficiently strong, but unzip tools are not as often preinstalled as PDF readers. Thus, depending on skills of the receiver, it may be more difficult to the receiver to unpack your ZIP.

Short answer: no. Just as you can't determine anyone's identity behind an email address. Long answer: if there is enough correlating public data that would allow you to connect this address to a person or company, then you can create a connection. If not, then you can't. Report the email to your email provider and cloud. They know who it is.

If one of your business accounts were compromised and that account had access to personal email addresses, like in their contacts, then the attackers could have harvested those email addresses. But there are no details in your question to make a determination about what happened or how the personal email addresses were discovered. No, you can't block senders to 3rd party email accounts, which is what your employee personal email accounts are. If you could, then you would have the power to block people from sending emails to me, for instance. Always report spam and phishing emails to your email provider.

someone claims that with given email address he can check if this address communicate ever with other company's emails addresses Without access to any part of the communication (mails, mail server ...) this is not possible ​(way to check if it's in this company whitelist or black list) Checking white and blacklist is mainly unrelated to checking if two parties have ever communicated with each other. While in some setups partners from established communications might be white listed, this is not a standard setup. And even if they are white listed there might be additional requirements for the white listing, like specific source IP addresses. Similar it will not blacklist all other recipients. The nearest which comes to what the claim might be here is an anti-spam technology called https://en.wikipedia.org/wiki/Greylisting_(email) which is employed by some (but not all) mail servers. It will return temporary errors for previously unseen combinations of sender and recipient in the hope that proper mail servers will retry while spammer botnets will not. But Greylisting usually not only takes the senders email in account but also the senders IP address. This means it cannot be used to query the established communication relations from arbitrary IP addresses. Moreover it sometimes is used to whitelist a complete sender domain, not a single sender.

This problem seems to be introduced by mail forwarding. It looks like the original mail was sent to the customers domain hosted by strato.com and from there automatically forwarded to a gmail.com address. While the original SMTP sender of business.com was aligned with the From header in the mail, this alignment got lost due to a change of the SMTP sender during mail forwarding. Breaking SPF in one way or another is a known problem with mail forwarding and there is no way to fix it. Instead DKIM should be used for cryptographic proof that the mail was send using a mail server responsible for the sender domain business.com. DKIM signatures will still be valid after forwarding, as long as the mail is not changed significantly. Since DMARC will pass if either SPF or DKIM passes a valid and aligned DKIM signature will make the non-aligned SPF irrelevant. Adding DKIM must be done at the outgoing mail server responsible for business.com. In addition a special DNS entry within the domain must be setup which contains the public key needed to validate the DKIM signature.

This is a https://support.google.com/mail/thread/16878288/gmail-is-opening-and-caching-urls-within-emails-without-user-intervention-how-and-why?hl=en in gmail, and https://who.is/whois-ip/ip-address/94.101.43.5 seems to be associated with Google. Google probably does this to check URLs for scammyness and malware, so they can provide more reliable spam and phishing filtering to their users. There's no way to have your e-mail hosted with Google and at the same time avoid Google reading your e-mails. It's also worth remembering that encryption for SMTP ( https://en.wikipedia.org/wiki/Opportunistic_TLS ) only encrypts the content in transit between e-mail servers. It does not hide the content while stored in queues on the mail server.