top of page

GG-One and Email Sender Reputation


We no longer send email from a single mail server or even a handful of servers. Instead, most of us use cloud-based systems (GG-One’s iFastrack Cloud Software utilizes Twilio SendGrid’s cloud-based email services). This provides us with so much more flexibility—we can send email from anywhere in the world! But without the necessary precautions in place, this flexibility puts your brand at greater risk of phishing scams.

In fact, you’ve probably opened a phishing scam without even realizing it. Research from Barracuda showed that a whopping 82% of organizations faced an email-based security threat in 2019. These threats are costly to organizations, causing 25% to lose $100,000 or more. But it’s more than money—a phishing scam can also damage a sender’s reputation, identity, and brand, making it a lot harder to reach your customers in the inbox.

GG-One Software has been focused on implementing advanced email processing and security protocols to help you eliminate your emails from appearing as phishing, secure your domain, and boost your email performance.

In this introduction, we will discuss the two core components implemented in GG-One’s SenderRep and ReceiverRep: identity and reputation.

Learn how we optimize your sending practices and offer mailbox providers reliable cues to determine the legitimacy of your email. You’ll strengthen your sender identity and reputation so that your email is secure and makes it to its destination.


Software focused on the best practices for maintaining a trusted sender profile, securing and elevating the sender and their brand through email; this includes maintaining sending reputation and sender identity.


Software focused on the best practices by monitoring for a trusted receiver (email recipient) profile, protecting the sender and their brand through valid email. Monitoring receiver profiles prevents blocked, fake or invalid emails from being transmitted, minimizing (or reducing) the impact on the sender’s reputation (being both you and GG-One’s sender reputation). Continually sending to fake or invalid email addresses will affect yours and GG-One’s overall sending reputation, potentially minimizing your email’s reliability cues to mailbox providers.

Sending reputation:

Sending reputation is how mailbox providers evaluate you as a sender. Every time you send an email, mailbox providers collect valuable data that says whether or not you follow proper sending practices. Your sender reputation is determined by a wide variety of factors, including recipient engagement, email content, spam complaints, spam traps, invalid email addresses, deny lists, and domain reputation.

Sender identity:

Your sender identity is the mail sender information in the “From” field that includes server domain name, email username, and sometimes the name of the person or generic account that the sender ties to the account (e.g. “John Smith” or “Compliance Dept”).

Faking an email is surprisingly easy!

At the time of their creation, the Internet and email were only accessible to a handful of people, so there was no room for impersonation. The inventors of email didn’t know how popular and central to business email would become, so they didn’t include any way to verify an email sender’s identity. Because of this oversight, email headers, including the “From:” and “Reply-to:” fields, are remarkably easy to fake. This has resulted in a prominent and highly convincing type of email impersonation that is referred to as exact-domain spoofing.

With exact-domain spoofing, attackers appear as legitimate senders coming directly from the company’s email servers. In other words, they can put an actual *company email address in the “From” field of the phishing message. And for many domains, this will be delivered in exactly the same way a legitimate message is, regardless of where it was actually sent from. These exact-domain attacks can have a disastrous impact on a company’s SenderRep and brand when attackers use the organization’s domain for faking sender identity in “*outbound” messages that they send to the company’s business partners, customers, or random members of the public.

*Note: these emails don’t actually originate from the company’s infrastructure—the company’s servers or authorized cloud services are not used, but the email can still appear legitimate.

Impersonation Remains a Leader of Phishing Scams

83% of all email attacks focus on brand impersonation, and another 6% of attacks impersonate people, like your CEO, instead of the brand itself.

How is it that hackers can so easily manipulate the sender to appear to come from any brand they want? Until 2015, there was no mechanism in place to verify the “From” address. This allows any sender to put whatever email in the “From” address, even if it doesn’t match the actual sender.

From the perspective of your sending reputation, this can cause a lot of damage. Imagine a large number of recipients receive an email from this unauthorized sender using your domain and have never heard of your company. The email is immediately deleted or marked as spam by the recipients. With enough spam complaints, your brand could be blocked. However, this isn’t all bad. This setup is what allows us to use third-party cloud services like GG-One Software and have your emails sent by that platform (via Twilio Sendgrid) appear as if they were sent directly from your company.

SenderRep and ReceiverRep:

To better protect our user's SenderRep, GG-One Software's iFastrack Cloud Service will begin checking all outgoing email addresses, validating the receiver's email address (ReceiverRep)/statistics. Any receiver email address with a reputation of < 20 will automatically be converted to the printing method or not sent at all (depending on whether you are using the Cloud or On-Premises service). Since our Cloud service directly utilizes the Twilio Sendgrid infrastructure, we are able to evaluate recipient email address statistics to better determine it's chance of making it to it's intended destination.

On-Premise installations will strictly depend on their own email provider services, though iFastrack will automatically run an evaluation test on each receiver email address used, to determine if any failure statuses are returned (without actually sending an email, therefore protecting the SenderRep). This method is entirely a Pass or Fail process and will determine if it will proceed with transmitting the email. Failed tests are recorded then skipped.

*Sender Authentication - iFastrack Cloud Service:

Contact GG-One Software support (@ if you use our iFastrack Cloud Service, utilize sending your non-compliance letters via email and have not had your email service provider implement our “Sender Authentication” codes. This does not apply to iFastrack On-Premises users (iFastrack installed on your in-house computers).

An Overview of Email Authentication Protocols

Email authentication collectively refers to the open Internet standards that validate email senders.

*Protocols Available in iFastrack Cloud Service (Through User's Email Provider Implementation):

SPF (Sender Policy Framework) is the standard that pioneered the concept of domain-based email authentication. SPF lets domain owners publish a list of approved IP addresses. If a mail server with an IP address that’s not on the list tries to send email using that domain, it won’t pass SPF authentication.

DKIM (DomainKeys Identified Mail) uses public-key cryptography to authenticate individual email messages. If the contents of the signed headers and message are not altered, the DKIM signature will still work. With proper implementation, DKIM ensures that messages are not tampered with in transit.

DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM to stop exact-domain email spoofing by matching what is checked by SPF and DKIM with what the end-user actually sees—the “From” header field.

Additional Industry Authentication Protocols:

BIMI (Brand Indicators for Message Identification) allows brands to provide brand-specific imagery that appears alongside messages they send. However, In order to use BIMI, senders must be using DMARC with an enforcement policy.

ARC (Authenticated Received Chain) is a small percentage of messages that will still fail authentication after being forwarded or passed through a mailing list. This problem is addressed by implementing ARC. The Authenticated Received Chain protocol provides an authenticated “chain of custody” for a message. In simple terms: ARC allows receivers to make delivery decisions for email that has been complexly routed.

bottom of page